Skip to main content

Minutes interim-1992-iesg-08 1992-03-26 17:00
minutes-interim-1992-iesg-08-199203261700-00

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 1992-03-26 17:00
Title Minutes interim-1992-iesg-08 1992-03-26 17:00
State (None)
Other versions plain text
Last updated 2024-02-23

minutes-interim-1992-iesg-08-199203261700-00
    IETF STEERING GROUP (IESG)

    REPORT FROM THE TELECONFERENCE

    March 26th, 1992

    Reported by:
    Greg Vaudreuil, IESG Secretary

    This report contains

    - Meeting Agenda
    - Meeting Attendees
    - Meeting Notes

    Please contact IESG Secretary Greg Vaudreuil for more information.


    Attendees
    ---------

    Almquist, Philip / Consultant
    Borman, David / Cray Research
    Chiappa, Noel
    Crocker, Dave / TBO
    Crocker, Steve / TIS
    Coya, Steve / CNRI
    Estrada, Susan / CERFnet
    Gross, Philip / ANS
    Hinden, Robert / BBN
    Hobby, Russ / UC-DAVIS
    Huizer, Erik / SURFnet
    Piscitello, Dave/ Bellcore
    Vaudreuil, Greg / CNRI

    Regrets

    Davin, Chuck / MIT
    Reynolds, Joyce / ISI
    Stockman, Bernard / SUNET/NORDUnet

    1. Administrivia

    1.1 Bash the Agenda
    1.2 Approval of the Minutes
    1.2.1 February 20th
    1.2.2 March 5th
    1.3 Next Meeting

    2. Review of Action Items

    3. Protocol Actions

    3.1 The PPP Authentication Protocols
    3.2 PPP Link Quality Monitoring
    3.3 SNMP Authentication
    3.4 BGP NEXT-HOP-SNPA Attribute
    3.5 Interdomain Policy Routing
    3.6 MD2, MD5 Documents
    3.7 Multipurpose Internet Mail Extensions

    4. RFC Editor Actions

    4.1 HYBRID NETBIOS END-NODES

    5. Working Group Actions

    5.1 Network Access Server Requirements (nasreq)

    6. Technical Management Issues

    6.1 ROAD Follow-on
    6.4 IDRP over IP

    MINUTES

    1. Administrivia

    1.1 Bash the Agenda

    The agenda was approved as written.

    1.2 Approval of the Minutes

    1.2.1 February 20th

    The IESG approved the Minutes of the February 20th teleconference
    for public distribution.

    1.2.2 March 3rd

    The IESG deferred approval of the March 5th minutes.

    1.3 Next Meeting

    Eric Huizer has asked that the IESG consider moving its
    teleconference time so that it no longer conflicts Thursday Evenings
    with personal obligations. The IESG was open to the suggestion, and
    tasked Steve Coya to juggle schedules to find a new meeting time.

    ACTION: Coya -- Poll the IESG and determine if there is a meeting time
    available for teleconferences other than Thursday 12-2 EST.

    The next IESG teleconference was scheduled for Thursday April 2nd
    from 12-2 PM EST. This meeting will be a single topic meeting to
    resolve the outstanding administrative issues relating to the
    creation of IETF work items for making progress with Routing and
    Addressing.

    2. Review of Action Items

    The actions items were not reviewed during this meeting.

    3) Protocol Actions

    3.1 The PPP Authentication Protocols

    The IESG reviewed the PPP Authentication protocols document. This
    document describes a framework and specific protocols for simple
    password and more rigorous challange-response authentication.

    The IESG approved this document pending two events. The document
    itself needs work editorial work in several places to improve the
    clarity and the document required the publication of the MD5 Message
    Digest algorithm as an RFC before it can be referenced by this
    document.

    ACTION: Vaudreuil -- Send a recommendation to elevate the PPP
    authentication protocols to Proposed Standard as soon as 1) The MD 5
    message digest algorithm document is submitted to be published as an
    RFC, and 2) A new version of the Authentication Protocols document is
    submitted clarifying several editorial points.

    3.2 PPP Link Quality Monitoring

    The PPP Link Quality Monitoring document reflects a significant
    redesign of the original mechanism outlined in RFC 1171. This new
    mechanism has been implemented and texted and reflects lessons
    learned and has been tested and implmented.

    The IESG approved this document for Proposed Standard.

    ACTION: Vaudreuil -- Send a recommendation to elevate the PPP Link
    Quality Monitoring document to Proposed Standard.

    3.3 SNMP Authentication

    The IAB has discussed the SNMP Authentication documents and has
    asked the IESG for further discussion. Two issues were raised.
    First were some relatively minor technical errors which can be
    easily corrected, and second, the documents do not appear to meet
    the IAB's normal standard for quality writing.

    The IESG discussed both of these points. On the first point; The
    specific technical points were not clearly communicated to the IESG,
    however the IESG expressed dismay at hearing these objections at
    this late time, after a through public review and a last call
    period. The IAB is working directly with the authors to resolve
    these points.

    The harder question for the IESG was the document writing style
    itself. The IESG recognizes the the quality of documents is quite
    variable. The IESG has had the practice of approving proposed
    standard documents if there are no glaring technical errors, and the
    document meets the requirements for formatting and gramatical
    correctness. Reviewing documents for writing style and clarity is
    difficult.

    POSITION: As long as a Proposed Standard document is technically
    acceptable, the writing is readable to the extent necessary to
    implement from. and the document reflects a best effort given the
    limited resources of the IETF, the IESG will approve such a document.

    3.4 BGP NEXT HOP SNPA Attribute

    The IAB has discussed the BGP Next Hop SNPA Attribute and has asked
    the IESG for clarifications on several points.

    The specific question the IAB raised concerns the behavior of the
    attribute across different networking technologies, especially
    across multi-media bridges. The IESG discussed and agreed to ask
    the working group to re-examine the intended scope of this
    protocol. The IESG also discussed the implications of operating a
    protocol like the SNPA attribute across a multi-media bridge, and
    concluded that this is not a real concern at this time. Multi-media
    bridges have not yet been architected into the system and many
    protocols break across them, not just this one.

    ACTION: Hinden -- Begin a dialogue with the the BGP working group to
    explore the intended scope of the BGP Next Hop SNMP Attribute.

    3.5 Interdomain Policy Routing

    The Interdomain Policy Routing Working Group has asked the IESG to
    consider IDPR for Proposed Standard. The IESG agreed that it is
    appropriate to standardize IDPR according to the proceedures
    documented in RFC 1264.

    A last call will be issued once the final version of the protocol,
    as well as the required reports are submitted to the Internet Drafts
    directories. One of the reports that IESG has asked for is a
    discussion on the interworking of IDPR with BGP in the Internet.

    ACTION: Vaudreuil -- Send a last call for IDPR once the final version
    is posted as an Internet Draft.

    ACTION: Hinden -- Communicate with the IDPR Working Group the need for
    updated documents and reports before approval for Proposed Standard.

    3.6 MD2, MD5 Documents

    Several Security related protocols reference the MD2 and MD5 Message
    Digest Algorithms. These algorithms are documented in Internet
    Drafts that should be published as informational RFC's. There is
    new text for both of these documents.

    ACTION: Vaudreuil -- After new text is submitted to the Internet
    Drafts, send a notification to the RFC Editor that the documents are
    ready to be published as RFC's.

    3.7 MIME

    The Internet Mail Extensions Working Group has submitted a revised
    version of MIME to the Internet Drafts directory and has asked the
    IESG to consider it for Proposed Standard. The new version reflects
    the changes requested by the IESG. The IESG has received an
    objection from EUnet, a network con sortium analagous to UUnet.
    They object to the separation of the Mnemonic character set proposal
    from the main MIME standard. The IESG discussed this objection,
    but concluded that the specific objections could not be accommodated
    in the current document due to rules for citations, but that the
    functionality requested could still be achieved via registration of
    the mnemonic character set with IANA.

    ACTION: Hobby -- Send an IESG response to the EUnet objections.

    The IESG discussed the changes, and approved MIME for Proposed
    Standard, providing that a second last call is issued and no new
    serious issues are uncovered.

    ACTION: Vaudreuil -- Send a second last call to the IETF list for MIME
    soliciting any objections to the changes in the current draft.

    4.0 RFC Editor Action

    4.1 NETBIOS over TCP

    Fredrick Noon was contacted by the IESG Secretary and was asked to
    clarify the intended status for the protocol. He has responded that
    he would like the document to be entered on the standards track.

    ACTION: Vaudreuil -- Send note to Postel taking the Netbios document
    into the standards process.

    The IESG discussed the need for community review, but was not able
    to resolve the question of whether an IETF Working Group would be
    the best place to review this proposal.

    ACTION: Borman -- Do some intellegence gathering, determine the
    constituency, and determine whether a working group or a one-shot BOF
    is necessary for review of the Netbios over TCP document. Determine if
    Noon is willing to chair a working group or BOF to review this
    protocol.

    5.0 Working Group Actiosn

    5.1 Network Access Server Requirements

    The IESG has reviewed the nasreq working group. Steve Kent raised a
    question of overlap between this group and others with similar
    sounding charters which pointed out that the scope of the group is
    not well defined. A new charter which more clearly specifies the
    work to be accomplished is needed.

    ACTION; Hobby -- Work with the prospective chairman of the nasreq
    working group to refine the scope of the Working Group and generate a
    new charter.

    6.0 Technical Management Issues

    6.1 Routing and Addressing

    The ROAD group, chartered by the IAB has given its recommendations
    to the IETF for future work in Routing and Addressing. The IESG
    began discussions on a workplan to solve the routing and addressing
    issues facing the Internet.

    6.1.1 Class B Number Assignment

    The Class B numbers are being consumed at a high rate. It is clear
    that they will run out in the near future. While the IETF works on
    a plan for extending the class B address space, policies for the
    assignment of network addresses need to be made.

    This IESG discussed several ideas including charging for the cost of
    assigning and routing IP addresses, but did not reach resolution.
    There was a clear sense that the IETF "ownes" this problem and that
    work should begin on formulating assignment guidelines.

    6.1.2 Short Term Addressing

    There are two proposals on the table for resolution of the Class B
    depletion problem, C-Sharp (C#), a creation of additional Class B
    numbers, and CIDR, Classless Interdomain Routing. Both proposals
    appear to address the short term needs, but have relative advantages
    and dis-advantages. C# mostly solves the C# of B address problem
    but does not address the aggragation of addresses necessary to
    contain the routing table explosion. The immediate need to work on
    a single solution requires a choice of one of these proposals to
    pursue.

    The decision on the choice of Cider vs C# depends on projections on
    when the addresses will run out. These numbers have not been made
    available to the IESG. The numbers used by the ROAD group in
    crafting their recommenation for CIDR are statistically sensitive
    projections and as such there is a reluctance to release the numbers
    to a wider community.

    The IESG discussed the tension between the need to move forward
    rapidly on this issue and the demands for openess. This tension
    results from the dual responsiblity of the IESG for both the
    operational stability of the Internet and the need for complete and
    accepted standards.

    The IESG will continue this discussion in a single topic
    teleconference April 2nd.

    6.4 Dual IDRP

    An effort to begin work on Dual IDRP (ISO BGP) has begun in the noop
    Working Group. This work needs to procede in the Routing area, but
    is not clear whether is should be in the IS-IS working group or a
    new Dual IDRP Working Group.

    ACTION: Hinden -- Find a home for the Dual IDRP work in the Routing Area.