Skip to main content

Minutes interim-1998-iesg-05 1998-03-12 16:30
minutes-interim-1998-iesg-05-199803121630-00

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 1998-03-12 16:30
Title Minutes interim-1998-iesg-05 1998-03-12 16:30
State (None)
Other versions plain text
Last updated 2024-02-23

minutes-interim-1998-iesg-05-199803121630-00
											
Minutes of the IESG Teleconferences

    INTERNET ENGINEERING STEERING GROUP (IESG)
    March 12, 1998

    Reported by: Steve Coya, IETF Executive Director

    ATTENDEES
    ---------

    Baker, Fred / cisco
    Bradner, Scott / Harvard
    Burgan, Jeff / @home
    Carpenter, Brian / IBM (IAB Liaison)
    Coya, Steve / CNRI
    Curran, John / GTE Internetworking
    Elz, Robert / U of Melbourne (IAB Liaison)
    Halpern, Joel / Newbridge Networks
    Moore, Keith / U of Tennessee
    Narten, Thomas / IBM
    Reynolds, Joyce / ISI
    Romanow, Allyn / MCI
    Schiller, Jeff / MIT

    Sittin' In
    ----------
    Rob Coltun / Fore Systems
    Marcus Leech / Nortel
    April Marine / Sterling Software
    Vern Paxson / Lawrence Berkeley Laboratory

    Regrets
    -------
    Alvestrand, Harald / Maxware
    O'Dell, Mike / UUNET

    Minutes
    -------

    1. The minutes of the February 26, 1998 Teleconference were approved.
    Steve to place in public archives.

    2. The IESG tentatively publication of Protection of BGP Sessions via
    the TCP MD5 Signature Option <draft-heffernan-bgp-tcp-md5-01.txt> as
    a Proposed Standard (when announced). The new version is to include
    the following with the addition of the following:

    1. Add a Section titled "Key Configuration" to the document. The text
    of the section is:

    It should be noted that the key configuration mechanism of routers may
    restrict the possible keys that may be used between peers. Implementors
    should consider this issue in their design.

    2. Change the text of Security Consideratins to read:

    This document defines a weak but currently practiced security
    mechanism for BGP. It is anticipated that future work will provide
    different stronger mechanisms for dealing with these issues.

    3. Insert the following IESG Note:

    IESG Note: This document describes currrent existing practice for
    securing BGP against certain simple attacks. It is
    understood to have security weaknesses against concerted
    attacks.

    The author will submit a revised I-D with this text. Once announced,
    and both Keith and Harald state their concerns have been addressed,
    Steve to send announcement.

    3. The IESG tentatively approved publication of Definitions of Managed
    Objects for Classical IP and ARP Over ATM Using SMIv2
    <draft-ietf-ion-mib-07.txt> as a Proposed Standard, but an RFC note
    needs to be added:

    In Section 3.1.5, replace the first two paragraphs with the following:

    An entry in the ipoaVcTable is created after the InATMARP
    reply is successfully received for an ipoaConfigPvcEntry
    during its activation. InATMARP should return the IP
    Address of the other end of the PVC in order to have the
    needed indexes to create an ipNetToMediaEntry and an
    ipoaVcEntry.

    The corresponding ARP Cache entry SHOULD be deleted whenever
    a PVC becomes unusable.

    4. The IESG approved publication of OSPF Version 2
    <draft-ietf-ospf-vers2-03.txt> as a Standard.

    In the same action, the IESG approved publication of OSPF
    Standardization Report <draft-ietf-ospf-stdreport-04.txt> as an
    Informational RFC. Steve to send announcement

    5. The IESG tentatively approved publication of Virtual Router Redundancy
    Protocol <draft-ietf-vrrp-spec-05.txt> as a Proposed Standard, once the
    following is incorporated into the Protocol Action Announcement:

    section 5.3.6.2, add text at end saying: Note that there are
    security implications to using the choice for authentication,
    and one should see the Security Considerations section.

    In Security Considerations, 10.2, add: The user should be aware
    that this clear text password is sent frequently, and
    therefore should not be the same as any security significant
    password.

    Add an IESG Note pointing to the IPR Page.

    6. The IESG approved publication of IP Payload Compression Protocol
    (IPComp) <draft-ietf-ippcp-protocol-05.txt> as a Proposed Standard, but
    Steve is NOT to send a Protocol Action Announcement until the following
    two documents are approved:
    draft-ietf-ipsec-ipsec-doi-06.txt
    draft-ietf-ipsec-isakmp-08.txt

    7. The IESG approved publication of IP Version 6 over PPP
    <draft-ietf-ipngwg-ipv6-over-ppp-06.txt> as a Proposed Standard, but
    Steve is NOT to send a Protocol Action Announcement until the following
    are approved:
    draft-ietf-ipngwg-ipv6-spec-v2-01.txt
    draft-ietf-ipngwg-addrconf-v2-02.txt
    draft-ietf-ipngwg-addr-arch-v2-02.txt
    draft-narten-canonical-ordering-00.txt

    8. The IESG tentatively approved publication of IMAP4 Namespace
    <draft-gahrns-imap-namespace-07.txt> as a Proposed Standard, but
    only if the author clarifies what "MAY NOT" means (assumed to be
    MUST NOT). Keith to contact author and provide information to IESG.
    Steve will request RFC Editor to make change prior to publication.

    9. The IESG approved publication of the following Internet-Drafts as
    Proposed Standards:

    NBMA Next Hop Resolution Protocol (NHRP)
    <draft-ietf-rolc-nhrp-13.txt>
    NHRP Protocol Applicability Statement
    <draft-ietf-ion-nhrp-appl-02.txt>
    A Distributed NHRP Service Using SCSP
    <draft-ietf-ion-scsp-nhrp-04.txt>
    Server Cache Synchronization Protocol (SCSP)
    <draft-ietf-ion-scsp-03.txt>

    as well as the publication of Classical IP to NHRP Transition
    <draft-ietf-ion-transition-02.txt> as an Informational RFC. However,
    the following text needed to be added:

    The Security Considerations text in draft-ietf-ion-nhrp-appl-02.txt
    hould be replaced with the following:

    NHRP is an address resolution protocol, and SCSP is a database
    synchronization protocol. As such, they are possibly subject
    to server (for NHRP) or peer (for SCSP) spoofing and denial of
    service attacks. They both provide authentication mechanisms
    to allow their use in environments in which spoofing is a
    concern. Details can be found in sections 5.3.4 in [1] and
    B.3.1 in [8]. There are no additional security constraints or
    concerns raised in this document that are not already discussed
    in the referenced sections.

    The title of draft-ietf-ion-transition-02.txt be changed to:

    Classical IP and ARP over ATM to NHRP Transition

    Section C of draft-ietf-ion-scsp-05.txt be replaced with:

    Any and all requests for value assignment from the various number
    spaces described in this document require proper documentation.
    Possible forms of documentation include, but are not limited to, RFCs
    or the product of another cooperative standards body (e.g., the MPOA
    and LANE subworking group of the ATM Forum). Other requests may also
    be accepted, under the advice of a "designated expert" (Contact the
    IANA for the contact information of the current expert.)

    And add a note that the IANA designated expert as mentioned in Section
    C of draft-ietf-ion-scsp-05.txt is James V. Luciani
    <luciani@baynetworks.com>.

    10. The IESG approved creation of the IP Over the Vertical Blanking
    Interval (ipvbi) Working Group in the Internet Area of the IETF. Steve
    to send announcement.

    12. The IESG approved publication of Intra-LIS IP multicast among routers
    over ATM using Sparse Mode PIM
    <draft-ietf-ion-intralis-multicast-02.txt> as an Experimental Protocol.
    Steve to send announcement.

    13. The IESG approved publication of The Safe Response Header Field
    <draft-holtman-http-safe-03.txt> as an Informational RFC with the
    following change:

    Note to RFC Editor: the text in the 4th paragraph of section 3
    currently reads:

    they must be assumed unsafe by default. This document adds a
    mechanism to HTTP, the Save header field, for telling if a POST
    request is safe.

    the text should read

    they must be assumed unsafe by default. This document adds a
    mechanism to HTTP, the Safe header field, for telling if a POST
    request is safe (i.e. change Save to Safe).

    14. The IESG approved publication of IP Payload Compression Using DEFLATE
    <draft-ietf-ippcp-deflate-03.txt> as an Informational RFC, but Steve
    NOT to send announcement until draft-ietf-ippcp-protocol-xx is
    approved.

    15. The IESG approved publication of IP Payload Compression Using LZS
    <draft-ietf-ippcp-lzs-04.txt> as an Informational RFC, but Steve NOT to
    send announcement until the following are approved:

    draft-ietf-ippcp-protocol
    draft-ietf-ipsec-auth-header
    draft-ietf-ipsec-ipsec-doi-06

    16. The IESG approved publication of Framework for IP Performance Metrics
    <draft-ietf-ippm-framework-03.txt> as an Informational RFC.

    17. The IESG had no problem with the publication of Recommendations on
    Queue Management and Congestion Avoidance in the Internet
    <draft-irtf-e2e-queue-mgt-01.txt> as an Informational RFC. Steve to
    inform RFC Editor.

    18. The IESG had no problem with the publication of WAVE and AVI Codec
    Registries <draft-fleischman-codec-subtree-02.txt> as an Informational
    RFC. Steve to inform RFC Editor.

    19. The IESG felt that The IP Network Address Translator (NAT)
    <draft-rfced-info-srisuresh-04.txt> should be remanded to the NAT
    Working Group. Steve to inform RFC Editor.

    20. The IESG could find no reason to publish Domain names for part-time
    Internet hosts <draft-rfced-info-nelson-00.txt>, though a number of
    reasons NOT to publish were identified. Steve will so inform the RFC
    Editor.

    21. The IESG could find no reason to publish The Ted.Net protocol for
    messaging based business interchanges
    <draft-laroche-ted-net-protocol-00.txt>. Steve to inform the RFC
    Editor.

    22. The IESG had no problem with the publication of The text/css Media Type
    <draft-lie-text-css-00.txt> as an Informational RFC. Steve to inform
    RFC Editor.

    23. The IESG feels that publication of Layer Two Forwarding (Protocol) "L2F"
    draft-valencia-12f-00.txt would serve no real purpose, other than
    for history majors. IF the RFC Editor wishes to publish, the IESG
    recommends it be published as Historic, not as Informational (as
    submitted). Furthermore, the IESG will request that CISCO be the
    first word of the Title.

    This is the last Teleconference before the 41st IETF Meeting in LA.