IETF STEERING GROUP (IESG)

                 REPORT FROM THE IETF MEETING

                      March 8th, 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
---------

   Almquist, Philip / Consultant
   Crocker, Dave / SGI
   Crocker, Steve / TIS
   Coya, Steve / CNRI
   Gross, Philip / ANS
   Hinden, Robert / SUN
   Hobby, Russ / UC-DAVIS
   Huizer, Erik / SURFnet
   Knowles, Stev / FTP Software
   Stockman, Bernard / SUNET/NORDUnet
   Vaudreuil, Greg / CNRI

IAB Liaison
   Chapin, Lyman / BBN
   Christian Huitema / INRIA

Regrets

   Borman, David / Cray Research
   Reynolds, Joyce / ISI
   Piscitello, Dave/ Bellcore


AGENDA
------
1) Administrivia
  o Role Call
  o Bash the Agenda
  o Approval of the Minutes
       - February 22, 1993
       - March 8th

2) Protocol Actions
  o Path MTU Discovery <Draft>
  o IESG Advice from Experience with Path
       MTU Discovery <Informational RFC>
  o RFC 1327 tutorial <informational RFC>
  o IEEE 802.5 Token Ring MIB <Draft>
  o IEEE 802.4 Token Bus MIB <historic>

3) Management Issues
  o Query sent to SNMP Working Group members
  o SNMP Security/v2
  o Router Requirements
  o The US Domain, Farnet, and NWnet
  o MIBs in Waiting

4) Working Group Actions
  o Authorization and Access Control (aac)

5) Tasked Items
  o Summarize the New IP Discussions
  o New IPLPDN charter & milestones
  o Secure FTP


MINUTES
-------

1) Administriva

o Approval of the Minutes

  Discussion and approval of the minutes of both the March 1st and the
  February 22nd teleconferences was deferred.

o Next Meeting

  The next IESG teleconference was scheduled for Thursday, March 18th,
  from 11:30 to 1:30 ET.

2) Protocol Actions

o MTU Discovery

  The IESG reviewed the MTU Discovery Protocol as documented in
  RFC1191.  This protocol is widely implemented and is in use in the
  operational Internet.  A known operational problem is documented in
  a companion document "IESG Advice from Experience with Path MTU
  Discovery".  The IESG approved this protocol for elevation to Draft
  Standard and the companion document was recommended for publication
  as an Informational RFC.

ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
Protocol as a Draft Standard.

o RFC 1327 Tutorial

  This document is a tutorial on the X.400 <=> RFC 822 mail gateway.
  Consideration was deferred until the next IESG meeting to review the
  document.

o Token Ring MIB

  The IESG discussed the urgency of considering the Token Ring MIB in
  the absence of a Network Management Area Director.  This protocol
  has been a proposed standard for over two years and requires review,
  but there is not strong pressure to elevate it immediately.  The
  IESG agreed to put a review of this protocol on hold pending
  appointment of a new Area Director.

o Token Bus MIB

  The IESG agreed that the Token Bus MIB could be moved to Historic
  without having an Network Management Area Director.

ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
Bus MIB to Historic.


3) Management

o SNMP Working Group Query

  Erik Huizer sent out a query to the SNMP Version 2 and SNMP Security
  Working Groups soliciting comments on the process by which these
  proposals were submitted and reviewed.  Specific comments were made
  about the steering group management, the split of security into a
  separate working group, and the compressed timeline, but the
  comments were generally positive and indicated that the current
  process should continue.  A full summary of this query is included
  as an Appendix.

  Until the SNMP working groups submit the protocols to the IESG,
  there is no further action for the IESG.

o Working Group Management

  Well defined procedures for working groups to follow will help
  answer specific questions about the standardization process.  Erik
  Huizer has posted an initial document with these procedures and will
  incorporate lessons learned from the SNMP Evolution process.

ACTION: Huizer - Revise the draft of the Working Group guidelines
document in light of the SNMP Evolution process and incorporating
revisions suggested by Gross and DCrocker.

o US Domain

  Issues about the management of the .us domain were taken off the
  agenda and will be discussed within the Operations Area.  It is not
  clear there are issues needing IESG attention.

o Router Requirements

  The editor of the Router Requirements documents was contacted and
  gave a brief status update.  The documents are under significant
  revision, including the splitting of the main document into four and
  incorporating changes necessary due to the passing of time.  There
  are a few technical details still to work out and it is not expected
  that this work will be concluded in the next few weeks.  The IESG
  explored options of posting the current documents again as Internet
  Drafts but reached no firm conclusions about whether the documents
  which are almost ready should be posted immediately or whether the
  documents should all be posted as a set.  Discussion will continue
  at the next meeting.

o Many Mibs

  There are several MIBs which have been submitted to the IESG for
  consideration as Proposed Standard but for which the Area Director
  review has not been completed.  The IESG agreed that advancing these
  MIBS can be put on hold until a new Network Management Area Director
  is appointed.

4) Working Group Actions

o Authentication and Access Control (aac)

  The charter was not received by the IESG and needs to be resent
  before it can be considered.

ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
consideration as a Working Group.

5) Tasked Items

o New IP Status Check

  The list of New IP contenders has risen to five with the inclusion
  of Robert Ullmann's IPv7 proposal.  The feedback from the IETF
  suggests that the list of contenders should not be artificially
  pruned, but that the proposals be evaluated based on some metric of
  progress.  The immediate question facing the IESG is the allocation
  of presentation time at the March IETF meeting.  Rather than give
  time for open discussion, the IESG agreed that the presentations
  should present specific information on the progress made since the
  last meeting.  This progress would include information such as new
  specifications written, implementations tested, and Internet
  integration and deployment examined.  Dave Crocker notified the IESG
  that the SIP and IPAE Working Groups should now be considered a
  single effort.

ACTION: Knowles -- Query each of the New IP contenders for their
current status in anticipation of making presentation time allotments.

o IPLPDN

  There is a lively discussion of the IPLPDN Working Group charter.
  The negotiations between the Working Group and the IESG continue
  over limiting the scope of the Charter.

o Secure FTP.

   Preliminary inquiries indicate that Common Authentication
   Technology may be the proper technology for securing FTP.  It
   appears that the application of CAT to FTP can be done by the CAT
   Working Group.

ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
to explore the incorporation of CAT to FTP.


Appendix - Summary of Action Items Assigned

ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
Protocol as a Draft Standard.

ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
Bus MIB to Historic.

ACTION: Huizer - Revise the draft of the Working Group guidelines
document in light of the SNMP Evolution process and incorporating
revisions suggested by Gross and DCrocker.

ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
consideration as a Working Group.

ACTION: Knowles -- Query each of the New IP contenders for their
current status in anticipation of making presentation time allotments.

ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
to explore the incorporation of CAT to FTP.


Appendix - Results of the SNMP Community Survey


                     IESG report on SNMPv2 Process Inquiry
                                 Erik Huizer
                                10-March-1993


Introduction
------------

In the Network Management and Security Area of the IETF, two working
groups have been working hard to define a new and secure version of
SNMP, called SNMPv2. These Working groups are the SNMPv2 Working Group
and the SNMP Security Working Group. These WGs have by early 1993
produced 12 Internet Drafts, which they will soon submit to the IESG
for advancement to proposed standard status. Recently, from a variety
of channels and to more than one member, complaints have reached the
IESG which call into question the process by which SNMPv2 has
advanced. SNMP is too important and the persistence of background
discomfort too significant for the IESG to ignore. Therefore the IESG
found it necessary to establish if the complaints are unfounded or
not, with the intention of putting matters of the WG's process to
rest.

To achieve this the IESG through one of its uninvolved members (the
author) held an E-mail inquiry amongst the members of the Working
Groups, asking for their comments on the process followed in the
creation of the SNMPv2 documents.  It must be stated that there have
been no official complaints made to the IESG, and as such this inquiry
is unprecedented, therefore the inquiry included a request for
comments on the inquiry itself.

This report summarises the results from the inquiry.


The Inquiry
-----------

The following text was send by E-mail to the
distribution lists of the two Working Groups on the 2nd March 1993:

"The SNMPv2 process is drawing near to a conclusion with the
submission of 12 documents to the IESG. The IESG is working to process
these documents as soon as possible.

Recently, from a variety of channels and to more than one member,
complaints have reached the IESG which call into question the process
by which SNMPv2 has advanced. The entire IETF is accountable for the
standards it produces, and the IESG is obliged to investigate these
complaints to determine whether the process has remained fair and open
throughout. The IESG realizes the importance of a broad acceptance of
SNMPv2 and finds it necessary to establish that the complaints are
unfounded. The IESG has charged me, a non-partisan in the NM area, to
approach the community most directly involved with SNMPv2 for input.

Therefore I send you this message, and ask each and everyone of you
who has comments on the process that led to the creation of SNMPv2 to
send me a PERSONAL note. It should present your candid and
confidential assessment of the chronology of events leading to the
request to advance SNMPv2 to proposed standard, from the original call
for contributions through the most recent postings to the mailing
list.  Since it is equally important to the IESG to hear from those
who view the process as having succeeded as not, I urge you to
respond.  Please rest assured that your correspondence will remain
entirely confidential; I will report back to the IESG in a summary
fashion.

The IESG does not wish this "process checkpoint" to further delay the
advancement of these standards. You thus have until monday 8 march 9
am EST to react. This will give me enough time to summarise before the
IESG meeting later that day.

So if you want to send me a personal note on this subject, do it now,
and make sure that it has the same subject line as above, preceded by
"re:".

I apologise to everyone who feels offended by this note, or by the
query.  The IESG recognizes that requests of this nature are highly
unusual, and deeply regrets having to proceed in this fashion. Indeed,
if you find this action to be contrary to the best interests of the
community, the IESG is interested in this feedback as well. We are
trying to do what is best from the community, and taking the question
to the community seems to be our best alternative in this matter."



The inquiry was aimed at the process followed, and not at he technical
contents of the WGs ofr the documents produced. For comments on the
technical contents of documents the IESG will use the normal "Last
Call" mechanism. Therefore remarks regarding technical contents of the
documents in response to the inquiry have been ignored.

The response
------------

The WG on SNMP Security distribution list contained 258 entries at the
moment the inquiry was sent. The SNMPv2 distribution list contained
459 entries. Only 37 people responded to the inquiry before the
deadline, 27 of them have E-mail addresses that indicate a commercial
background.

By far the majority of the people who responded (84%) claimed to be
passive listeners. I.e. they were interested participants, but did not
contribute any new ideas, nor participated actively in discussions on
the WG lists.

Although it is impossible to draw a unanimous conclusion from the 37
responses, the following observations are supported by at least 75% of
the responding people:

1- On the whole the process leading to the 12 Internet Drafts has been
 as fair as possible and not much different from other IETF WG
 processes; The current set of documents is cetainly the best that
 could have been produced in such a short time, and is believed to be
 the only one to get the majority consensus from the WGs.

2- There has been too much haste in getting the SNMPv2 proposal out;
 There was no need for the IESG and the Working Groups to set such a
 sharp deadline (december 1992). This deadline, and the pressure it
 created made various contributors feel that their proposals did not
 get the proper attention.  Especially a final WG meeting in March
 (Columbus) would have been a good thing.

3- The WG chairs have acted correctly, and they have done a wonderfull
 job of making sure that the documents were ready on time; All this
 within the limited timeframe, and with little leeway to have lengthy
 discussions on alternative proposals.

4- The authors of the original SMP documents should have been more
 restrained in their reactions; It was suggested that the original
 authors should not have been the editors of the final documents,
 although this clearly would have delayed the WGs. The amount of work
 put in by the authors is very much appreciated and they are generally
 acknowledged as THE authorities with respect to SNMP. However, the
 original SMP authors had too much of a headstart in thinking along the
 proposed SNMPv2 lines. This made them react (too) fast to alternative
 proposals, which thus gave the (false) impression of not being
 considered seriously. The authors also repeatedly used the argument
 that their proposal was supported by working implementations, while
 the alternatives were not. This is not a proper argument to be used in
 a working group when working on a new protocol.

5- The decision to split the work over two Working Groups was
 unfortunate.  The two IESG Area Directors appointed to the process
 were either too involved, or not involved enough. This lead to
 miscommunication between the WGs and the IESG.

6- There was no objection against, but also no real necessity for the
  IESG to do this inquiry.

7- Due to time pressure the security aspects that have been introduced
 did not get the necessary attention/discussion

8- The concept of a design team going off and preparing an initial
 working document is applauded. However there should be regular
 feedback from a design team into the WGs. The current situation where
 the result of the design team was heralded into the world through
 the press has been found very counter-productive.


The Conclusions and recommendations
-----------------------------------
The SNMPv2 documents have been produced according to the normal IETF
process with the two involved WGs operating much in the same way as
other Working Groups. If there are any remarks to be made about the
process they can be traced back to two main errors:
- The IESG has failed to manage the SNMPv2 process properly; The main
 error being that the deadlines put onto the WGs were unnecessary
 tight.
- The authors of the original SMP proposal have chosen an unfortunate
 way of presenting their proposals 'out of the blue' and defending
 them.

Despite these shortcomings the WG chairs, the authors and other WG
members succeeded in getting the documents ready within the agreed
deadlines. The "Last Call" mechanism will have to show whether there
are still technical issues unresolved that prohibit moving the
documents to Proposed Standard and reviewing the results of this
before moving them to Draft Standard.

The inquiry performed by the IESG was usefull although not perceived
to be necessary, and the amount of responses seems to confirm the
latter. The IESG should therefore in future refrain from these kind of
inquiries unless there are official complaints.