Skip to main content

Minutes interim-1992-iesg-23 1992-10-01 16:00
minutes-interim-1992-iesg-23-199210011600-00

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

minutes-interim-1992-iesg-23-199210011600-00
											
Minutes of the IESG Teleconferences

    IETF STEERING GROUP (IESG)

    REPORT FROM THE TELECONFERENCE

    October 1st, 1992

    Reported by: Greg Vaudreuil, IESG Secretary

    This report contains IESG meeting notes, positions and action items.
    For more information please contact the IESG Secretary.

    iesg-secretary@nri.reston.va.us

    ATTENDEES
    ---------

    Almquist, Philip / Consultant
    Borman, David / Cray Research
    Crocker, Dave / TBO
    Crocker, Steve / TIS
    Davin, Chuck / Bellcore
    Gross, Philip / ANS
    Hinden, Robert / SUN
    Hobby, Russ /UC-Davis
    Piscitello, Dave/ Bellcore
    Vaudreuil, Greg / CNRI

    Regrets
    Coya, Steve / CNRI
    Huizer, Erik / SURFnet
    Reynolds, Joyce / ISI
    Stockman, Bernard / SUNET/NORDUnet

    AGENDA

    1) Administivia
    o Role Call
    o Bash the Agenda
    o Approval of the Minutes
    o Next Meeting

    2) Protocol Actions

    o TCP/IP Header Compression
    o PPP Authentication
    o Generic Interface MIB
    o Token Ring MIB
    o Token Bus MIB
    o RIP Version 2
    o RIP Version 2 MIB
    o RIP Protocol Analysis
    o BGP Default Route Advertisement
    o OSPF AS
    o Ident MIB
    o Ident

    3) RFC Editor Actions

    o Sender Initiated File Transfer Protocol (SIFT)

    4) Working Group Actions

    o UPS MIB (upsmib)
    o P Internet Protocol (pip)
    o IPAE (ipae)

    5) Technical Management Issues

    o Feedback to SMTP Working Group
    o ROAD Activities

    MINUTES

    1) Administrivia

    o Bash the Agenda

    The agenda was approved as written.

    o Approval of the Minutes

    Review and approval of the minutes for the September 10th, 14th, and
    21st meetings was deferred.

    o Next Meeting

    The IESG set the next Teleconference time for October 8th, 12:00
    ET. The IESG discussed the necessity for weekly teleconferences and
    concluded that weekly meetings will be needed at least until the
    November IETF meeting.

    2) Protocol Actions

    With these minutes, only protocols currently awaiting specific IESG
    action will be listed. Protocols for which a last call has been
    issued but for which there is outstanding action items in the
    submitting Working Group will not be listed.

    o TCP/IP Header Compression

    The IESG has the list of textual changes requested to RFC 1144.
    There are two types of changes, edits to the sample code to fix
    known bugs, and additional clarifications and implementation
    advise. Small changes to the document are relatively easy, but
    because of the difficulty of generating an ASCII version,
    significant changes likely to affect pagination will take time the
    is not willing to invest. In the interest of getting this long
    delayed protocol advanced, the IESG decided to incorporate only the
    bug fixes to the sample code and encourage the writing of a separate
    document with clarifications and implementation advise.

    Continuing Action: Borman - Ensure that a new version of the TCP/IP
    Header Compression document is submitted to the IESG.

    o PPP Authentication

    The IESG received notice from the PPP extensions Working Group that
    this protocol has been reviewed and the changes requested by the IAB
    have been accepted by the Working Group. The IESG approved this
    document for submission to the IAB as a Proposed Standard.

    ACTION: Vaudreuil - Send a new recommendation to the IAB to elevate PPP
    Authentication to Proposed Standard.

    o Generic Interface MIB

    The IESG has received comments from the Last Call which identified
    the need to revise this MIB. Until this MIB is revised, the IESG is
    unable to act and so has decided to #put this document into
    suspended animation#.

    ACTION: Davin -- Notify the author of the Generic Interface MIB that it
    needs revision before the IESG can consider advancing it to Draft
    Standard. If necessary, conduct a review of this MIB to determine if
    the changes require a re-cycle at Proposed Standard or elevation as a
    Draft Standard.

    o Token Ring MIB

    There is insufficient information to date on implementation
    experience for this MIB. Additional information was requested from
    the IETF mailing list after the last call but no response was
    received. This protocol will remain on the IESG Agenda for further
    review.

    ACTION: Davin -- Conduct a review of implementation experience with the
    Token Ring MIB.

    o Token Bus MIB

    The IESG has reviewed the Token Bus MIB and has determined that
    there is insufficient implementation and operational experience for
    this MIB to be advanced to Draft Standard. Until this MIB is
    revised, the IESG is unable to act and so has decided to
    #put this document into suspended animation#.

    ACTION: Davin -- Review the Token Bus MIB and resubmit to the IESG when
    it has sufficient implementation experience.

    o Routing Information Protocol Version 2

    The review of RIP is still underway. No information to report.

    o BGP Default Route

    The IESG reviewed the BGP Default Route Advertisement document for
    Proposed Standard and approved the document for Proposed Standard
    pending the close of the last call period.

    ACTION: Vaudreuil -- Prepare a recommendation for BGP Default Route
    Advertisement and if there are no comments sent to the IESG or IETF
    mailing lists, send the recommendation to the IAB.

    o OSPF Applicability Statement

    The IESG reviewed and approved the IAB applicability statement for OSPF.

    ACTION: Vaudreuil - Prepare a recommendation to elevate the OSPF AD to
    Proposed Standard. Send this recommendation to the IESG for review
    prior to sending it to the IAB.

    o Identification Server
    o Ident MIB

    A new issue has surfaced since the last call has been issued for
    this protocols. The optional character set designation is not very
    clear and the mechanisms for registration are not documented. The
    IESG discussed this issue and recommends that the character set
    registry set up for MIME be used for registration. Ident currently
    lists a version of OCTET as the default character set. The IESG
    understands the potential utility for returning non-ascii
    transformations of the user data but is not aware of any current use
    of such and agrees with the IAB's architectural preference for ASCII
    as the default character set.

    The Ident MIB also contains a character set identifier, but it is
    encoded as a OID. The MIME registry does not include OIDs and will
    need to be expanded to handle these values. Wording changes to the
    Ident MIB are needed to reflect these changes.

    POSITION: In Internet Protocols, if the character set is unspecified,
    the default must be US-ASCII. To facilitate internationalization,
    future protocols should provide a means for explicity identifying the
    character set in use.

    ACTION: Greg Vaudreuil -- With the assistance of Chuck Davin and Steve
    Crocker, write a draft policy statement on the use of character sets
    in Internet Protocols.

    3) RFC Editor Actions

    o Sender Initiated File Transfer

    The IESG reviewed this submission for Experimental protocol and
    concluded that this protocol does not fit the current Architectural
    model, but is not harmful and acceptable as an experiment.

    ACTION: Vaudreuil -- Notify the RFC Editor that the SIFT protocol is
    acceptable to the IESG for publication as an Experimental RFC.

    4) Working Group Actions

    With the completion of the draft IESG ROAD Plan, the PIP and IPAE
    Working Groups can now be announced. The IESG expressed a
    preference for announcing the likely Working Groups together,
    including the TCP/UDP for Bigger Addresses Working Group if a
    charter can be prepared in the next day.

    ACTION: Vaudreuil -- Announce the PIP and IPAE Working Groups to the
    IETF Mailing List.

    ACTION: Vaudreuil -- Solicit an updated version of the TUBA charter,
    send it to the IESG-TECH mailing list and send it to the IETF list as
    soon as possible.

    o Uninterruptable Power Supply MIB (upsmib)

    The IESG reviewed and approved the formation of the UPS MIB Working
    Group.

    ACTION: Vaudreuil: Announce the UPS MIB Working Group to the IETF.

    5) Technical Management Issues

    o ROAD Work Plan

    The IESG reviewed the draft IESG ROAD work plan and agreed to post
    it as an Internet Draft. The document needs public review and comment
    but also needs the visability associated wqith publication as an RFC.
    If there are no objections to the document, the IESG expressed a
    desire to post the document as an Informational RFC.

    ACTION: Vaudreuil -- Finalize the formatting of the ROAD document and
    post it as an Internet Draft Friday Morning. Forward the announcement
    to the Big Internet Mailing Lists.

    ACTION: Vaudreuil -- Schedule discussion of the ROAD Plan at the next
    IESG Teleconference. If there is no objection, submit this document
    to the RFC Editor for publication as an Informational RFC.

    o Feedback to the SMTP Working Group

    The request by the IESG for additional review of the SMTP extensions
    protocol was interpreted as less than clear and additional guidance
    was sought by the Working Group Chairman. Several points were
    raised for clarification. 1) What if any technical changes does the
    IESG require from the document, 2) Does the IESG have a preference
    for eliminating the folklore and implementation advise, 3) Does the
    IESG have a preference for splitting the protocol into multiple
    documents, and 4) Was the Working Group within its charter to
    address "requirements" issues in SMTP as they relate to the proposed
    extensions.

    The IESG discussed these points and made the following conclusions.
    The Working Group was within its charter to do limited
    "requirements" work in addressing SMTP shortcomings. Towards this
    end, the recording of Folklore was seen as positive. The IESG does
    not have a position on whether the folklore is on the protocol
    document or in a separate informational RFC. There is also no IESG
    position on the choice of documenting the protocol a single
    comprehensive document of a series of related documents and leaves
    this choice to the Working Group. The IESG has asked for a
    technical review of specific technical complexities discussed during
    the last call period and would like these discussions reflected in
    the document.

    ACTION: Hobby -- Write a note to the SMTP Extensions Working Group
    reflecting the sense of the IESG. This note should be sent by the IESG
    Secretary noonish Friday.

    Appendix - Action Items
    --------

    ACTION: Vaudreuil - Send a new recommendation to the IAB to elevate PPP
    Authentication to Proposed Standard.

    ACTION: Davin -- Notify the author of the Generic Interface MIB that it
    needs revision before the IESG can consider advancing it to Draft
    Standard. If necessary, conduct a review of this MIB to determine if
    the changes require a re-cycle at Proposed Standard or elevation as a
    Draft Standard.

    ACTION: Davin -- Conduct a review of implementation experience with the
    Token Ring MIB.

    ACTION: Vaudreuil -- Prepare a recommendation for BGP Default Route
    Advertisement and if there are no comments sent to the IESG or IETF
    mailing lists, send the recommendation to the IAB.

    ACTION: Greg Vaudreuil -- With the assistance of Chuck Davin and Steve
    Crocker, write a draft policy statement on the use of character sets in
    Internet Protocols.

    Appendix - Positions Taken
    --------

    POSITION: In Internet Protocols, if the character set is unspecified,
    the default must be US-ASCII. To facilitate internationalization,
    future protocols should provide a means for explicity identifying the
    character set in use.