IETF STEERING GROUP (IESG)

                 REPORT FROM THE IETF MEETING

                      April 15th, 1993

        Reported by:  Greg Vaudreuil, IESG Secretary

This report contains IESG meeting notes, positions and action items.

These minutes were compiled by the IETF Secretariat which is supported
by the National Science Foundation under Grant No. NCR 8820945.

For more information please contact the IESG Secretary.
[email protected].



ATTENDEES
---------

   Bradner, Scott / Harvard
   Chapin, Lyman / BBN
   Coya, Steve / CNRI
   Crocker, Dave / SGI
   Crocker, Steve / TIS
   Gross, Phillip / ANS
   Hinden, Robert / SUN
   Kahle, Brewster / WAIS
   Knowles, Stev / FTP Software
   Piscitello, Dave/ Bellcore
   Rose, Marshall / DBC
   Vaudreuil, Greg / CNRI


Regrets
   Huizer, Erik / SURFnet
   Mankin, Allison / Locus
   Reynolds, Joyce / ISI
   Stockman, Bernhard / SUNET/NORDUnet

IAB Liaison
   Christian Huitema / INRIA



AGENDA
------

1. Administrivia

  o Roll Call
  o Bash the Agenda
  o Approval of minutes
    - April 8th

2. Protocol Actions

  o X.400 Routing Coordination
  o Distributed Authentication Security Service

3. Working Group Actions

  o Modem Management (modemmgt)
  o Character MIB (charmib)
  o DECnet Phase IV MIB (decnetiv)
  o AToM MIB (atommib)

4. Tasked Items

  o RIP A/S
  o Revised IPLPDN Working Group Charter

5. Management Issues

  o Alignment of the Working Groups
  o Informal operations review of Internet Drafts
  o Compressing TCP/IP Headers
  o DHC -- Status check
  o Requirements for Draft Standard -
    Implementation of the IESG policy



MINUTES
-------

1) Administrivia

o Approval of the Minutes

  With corrections, the minutes of the April 8th teleconference were
  approved.

o Next Meeting

  In an effort to reduce the time demands on IESG members, the next
  meeting was scheduled for April 29th.

2) Protocol Actions

o X.400 Routing Coordination

  In the absence of Eric Huizer, this document was not reviewed.

o Distributed Authentication Security Service

  The DASS work was submitted by the CAT work for consideration as an
  Experimental Protocol. This effort was initially intended to be on
  the standards track but the group has requested Experimental because
  the development effort lost funding.

  This work was originally developed within DEC and it is unclear
  whether there are still intellectual property claims on this work.
  Efforts were initiated to secure a letter of release but the current
  status is unknown.  As an experimental protocol a formal release is
  not needed, but the RFC should indicate any Intellectual Property
  rights claims on the content.

ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current
requirements for the intellectual property rights declaration on
non-standards track RFCs.

ACTION: SCrocker -- Clarify with the authors of the DASS document the
status of any intellectual property right claims.

3) Working Group Actions

o Modem Management (modemmgt)

  The IESG reviewed and approved the Modem Management Working Group
  charter. This group met at the Columbus IETF meeting as a BOF. The
  group intends to maintain liaisons with several external
  organizations but has been discouraged from operating a lock-step
  manner.

ACTION: Vaudreuil -- Announce the formation of the Modem Management
Working Group to the IETF list.

o Character MIB

  The new Character MIB Working Group charter was approved.  This
  Working Group was rechartered to review the current standardization
  status of the several character MIBs.

ACTION: Vaudreuil -- Announce the re-formation of the Character MIB
Working Group.

o DECNet Phase IV MIB

  The new DECNet Phase IV MIB Working Group charter was approved.
  This Working Group was rechartered to review the current
  standardization status of the several character MIBs.

ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV
MIB Working Group.

o ATM MIB (atommib)

  The IESG approved the charter for the ATM MIB Working Group.  This
  group is expected to be long lived given the evolving ATM standards
  the many layers of the ATM protocol.

ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working
Group.

  The ATM MIB is one of several MIBs based on the aging Interfaces
  group.  The Interfaces group was written with a bit of a simplistic
  model which does not work well with virtual circuit and tunneling
  technologies. A new Working Group is being formed to revisit the
  Interfaces group.  The work of the ATM MIB group will  be aligned
  with the resulting new model and MIB.

4) Tasked Items

o RIP A/S

  No progress to report.

o IPLPDN Charter.

  Discussions on the future scope of the IPLPDN Working Group are
  continuing.


5) Management Issues

o Alignment of Working Groups

  Due to limited time in the IESG meeting, a review will be conducted
  by email for approval of the current alignment of Working Groups
  into the re-staffed IESG areas.

ACTION: Vaudreuil -- Send out the current Working Group summary to
confirm the current Working Group and Area alignments.

o Operational Requirements Review of Internet Drafts

  An informal review of all Internet Draft is being conducted in the
  Operations Area.  This effort focus on evaluating the operational
  impact of new proposals and feeding comments back to the authors.
  This function is separate from but is expected to be included into
  the scope of the Operations Area Directorate when finalized.

  This review is being done on an experimental basis to gauge whether
  the comprehensive review of proposals will have a benefits worth the
  effort.  Suggestions were made to publish a list of operational
  criteria by which the proposals will be measured.  Other ideas
  included a dedicated section in the RFCs similar to the security
  considerations section identifying possible operational impacts.

  The IESG has discussed several "considerations" sections in the past
  and discussion of the proposed "operational considerations" section
  was deferred until a list of all such sections discussed by the IESG
  could be gathered.

ACTION: Vaudreuil -- Get all the IESG discussions on various
"considerations" sections together for review at a future
teleconference.

o Compressing IP headers

  Allison Mankin was not present to give a status update.

o Dynamic Host Configuration

  The Working Group has worked out a few bugs and the area director
  has pressed the group to get the current version out as a Proposed
  Standard.  The editing cycle is continuing too long. Revisions are
  possible as the proposals go to draft standard.

o Requirements for Draft Standard

  The IESG continued a discussion from the last meeting to refine the
  requirements for a protocol to be advanced to Draft Standard.  After
  a bit of discussion, the following requirements was made.

POSITION:  ALL protocols being considered for Draft Standard status
must have at least two implementations, each of which supports all
features and options and between which all features and options have
been tested.  Features and options which have been speicified for
future use but which have not been tested must be removed from the
specification prior to advancement to Draft Standard.

  The IESG earlier adopted a position that all protocols eligible for
  advancement to Draft Standard be presented to an IETF plenary.  With
  the growing number of protocols, the growing size of the IETF
  including mailing list only participants, the reduced frequency of
  meetings, and the use of the last call procedure, this requirement
  has been lifted.

POSITION: Unless requested by an Area Director, it is no longer
expected that a plenary presentation be made for each protocol under
consideration for Draft Standard.

  Currently it is possible to standardize multiple competing
  protocols.  The IESG discussed the cost to vendors and providers who
  must support each of the protocols and considered a proposal that
  only one protocol for a given function be allowed to reach Standard
  status.   The IESG did not agree on this idea but did affirm that
  the goal is to have one protocol per function.  It may be reasonable
  to have multiple protocols that perform a function such as a
  generalized protocol with many features and a limited protocol
  optimized for a particular situation.

o Wide Area Routing with RIP

  This may be a topic for the routing work the IPLPDN Working Group
  was originally chartered to do.  The Internet Area agreed to review
  the protocol analysis for assignment.

o Frame Relay Service MIB WG

  The Frame Relay Service MIB effort will be defining managed objects
  for service management, rather than device management--a new area
  for IETF standardization.  The IESG briefly discussed the proposed
  working group scope and management along with the Competing
  technical approaches that were being pursued.  There was also
  discussion on which area this effort should be placed under, who
  should be named chair.  The IESG agreed that the handling, to date,
  was acceptable, and further agreed that this effort should be placed
  in the Network Management area, with a neutral party named as
  chair.


Appendix -- Summary of Action Items Assigned

ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current
requirements for the intellectual property rights declaration on
non-standards track RFCs.

ACTION: SCrocker -- Clarify with the authors of the DASS document the
status of any intellectual property right claims.

ACTION: Vaudreuil -- Announce the formation of the Modem Management
Working Group to the IETF list.

ACTION: Vaudreuil -- Announce the re-formation of the Character MIB
Working Group.

ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV
MIB Working Group.

ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working
Group.

ACTION: Vaudreuil -- Send out the current Working Group summary to
confirm the current Working Group and Area alignments.

ACTION: Vaudreuil -- Get all the IESG discussions on various
"considerations" sections together for review at a future
teleconference.


Appendix -- Summary of Positions Taken

POSITION:  ALL protocols being considered for Draft Standard status
must have at least two implementations, each of which supports all
features and options and between which all features and options have
been tested.  Features and options which have been speicified for
future use but which have not been tested must be removed from the
specification prior to advancement to Draft Standard.

POSITION: Unless requested by an Area Director, it is no longer
expected that a plenary presentation be made for each protocol under
consideration for Draft Standard.