Minutes interim-1996-iesg-09 1996-06-06 15:30
minutes-interim-1996-iesg-09-199606061530-00

											
Minutes of the IESG Teleconferences

    INTERNET ENGINEERING STEERING GROUP (IESG)
    June 6, 1996

    Reported by: Steve Coya, IETF Executive Director

    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-9528103

    ATTENDEES
    ---------

    Alvestrand, Harald / Uninett
    Baker, Fred / cisco
    Bradner, Scott / Harvard
    Burgan, Jeff / Baynetworks
    Carpenter, Brian / CERN (IAB Liaison)
    Coya, Steve / CNRI
    Elz, Robert / U of Melbourne (IAB Liaison)
    Halpern, Joel / Newbridge Networks
    Kastenholz, Frank / FTP Software
    Kostick, Deirdre / AT&T Bell Labs
    Mankin, Allison / Information Sciences Institute
    Moore, Keith / U of Tennessee
    O'Dell, Mike / UUNET
    Reynolds, Joyce / ISI
    Schiller, Jeff / MIT

    Minutes
    -------

    1. The IESG approved the minutes of the May 23 teleconference. Steve
    to place in shadow directories.

    2. The IESG approved publication of SMTP Service Extension for Remote
    Message Queue Starting <draft-dewinter-queue-start-01.txt> as a
    Proposed Standard after deleting the following text from section 2,
    paragraph 1, sentence 2:

    "This is an attempt to fix the security problems with the TURN
    by creating a new command ETRN that places the emphasis
    on the server instead of the connection."

    Steve to incorporate into the announcement.

    3. The IESG felt that examples would greatly improve the quality of
    Uniform Resource Locators for Z39.50
    <draft-ietf-uri-url-irp-04.txt> and decided to return the document
    to the author for revision.

    4. The IESG approved the publication of Implications of Various
    Address Allocation Policies for Internet Routing
    <draft-ietf-cidrd-addr-ownership-07.txt> as a BCP Document.
    Consensus was as rough as can be defined, and the IESG Note to the
    RFC Editor was revised to read:

    The addressing constraints described in this document are
    largely the result of the interaction of existing router
    technology, address assignment, and architectural history.
    After extensive review and discussion, the authors of this
    document, the IETF working group that reviewed it and the IESG
    have concluded that there are no other currently deployable
    technologies available to overcome these limitations. In the
    event that routing or router technology develops to the point
    that adequate routing aggregation can be achieved by other
    means or that routers can deal with larger routing and more
    dynamic tables, it may be appropriate to review these
    constraints.

    Jeff Schiller was not happy with the issuance of this document, and
    does not believe it to be a good thing.

    5. The IESG approved publication of Definitions of Managed Objects for
    APPC <draft-ietf-snanau-appcmib-06.txt> as a Proposed Standard.
    Steve to send announcement.

    6. The IESG approved publication of The PPP Multilink Protocol (MP)
    <draft-ietf-pppext-multilink-12.txt> as a Draft Standard. There was
    one small typo that needs to be changed, at the top of page 2:

    The differences between the current PPP Multilink specification
    (RFC 1717) and this memo are explained in Section 10. Any system
    ^^^^^^^^^^^

    Section 10 should be Section 11.

    Steve to add to the Protocol Action writeup before sending the
    announcement.

    7. The IESG approved publication of PPP Link Quality Monitoring
    <draft-ietf-pppext-lqm-ds-00.txt> as a Draft Standard. Steve to
    send announcement.

    8. The IESG approved publication of PPP Challenge Handshake
    Authentication Protocol (CHAP) <draft-ietf-pppext-chap-ds.draft> as
    a Draft Standard, once Reference 4 was removed, and the text
    pointing to it modified. Joyce agreed that this was editorial in
    nature, and that a new Internet-Draft would not be required. Steve
    to incorporate these edit requests into the announcement.

    9. The IESG opted to split the two PGP documents apart, treating each
    one separately. Further action was to:

    a. Return MIME Security with Pretty Good Privacy (PGP) to the
    author with items to be added (definition of must, security
    considerations, and the authors contact information)

    b. Approved publication of PGP Message Exchange Formats
    <draft-atkins-pgpformat-01.txt> as an Informational RFC.

    10. The IESG approved publication of the following five Mobile IP
    Internet-Drafts as Proposed Standards:

    a. IP Mobility Support
    <draft-ietf-mobileip-protocol-17.txt>
    b. IP Encapsulation within IP
    <draft-ietf-mobileip-ip4inip4-03 .txt>
    c. Minimal Encapsulation within IP
    <draft-ietf-mobileip-minenc-02.txt>
    d. Applicability Statement for IP Mobility Support
    <draft-ietf-mobileip-appl-02.txt>
    e. The Definitions of Managed Objects for IP Mobility Support
    <draft-ietf-mobileip-mib-00.txt>

    Steve to send announcement.

    11. After a slight revision to the updated charter, the IESG approved
    the creation of the Electronic Data Interchange-Internet
    Integration (ediint) Working Group in the Applications Area. Steve
    to send announcement.

    12. The IESG approved publication of Catalogue of Network Training
    Materials <draft-ietf-trainmat-catalogue-06.txt> as an
    Informational RFC. Steve to send announcement.

    13. The IESG approved publication of The Nimrod Routing Architecture
    <draft-ietf-nimrod-routing-arch-01.txt> as an Informational RFC.
    Steve to send announcement.

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

    1. Incremental Zone Transfer in DNS <draft-ietf-dnsind-ixfr-07.txt>

    2. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
    <draft-ietf-dnsind-notify-08.txt>

    15. The IESG had no problem with the publication of Enhanced Trivial
    File Transfer Protocol (ETFTP) <draft-rfced-exp-polites-00.txt> as
    an Experimental Protocol, but request that the document title be
    changed to:

    Experiments with a Simple File Transfer Protocol for Radio Links

    16. The IESG has no problem with the publication of GPS-Based
    Addressing and Routing <draft-rfced-exp-navas-00.txt> as an
    Experimental Protocol.

    17. The IESG decided to ask that Ascend Tunnel Management Protocol -
    ATMP <draft-rfced-info-hamzeh-00.txt> not be published as this time
    as the will invite the author to submit his document to the PPPEXT
    working Group.

    18. The IESG felt that A Clarification of STATUS
    <draft-rfced-info-perkins-00.txt>, along with the latest set of
    documents submitted by Dave Perkins (one of which was an update to
    the STATUS submission), should not be published, but reviewed at
    the SMI BOF to be held during the Montreal IETF meeting.

    19. The set of documents submitted by Dan Bernstein were discussed, and
    the following responses defined:

    a. draft-bernstein-eplf-00.txt: do not publish. Author will be
    invited to participate in a new FTP Working Group. If author
    declines the invitation, the IESG will request the following
    note be added:

    This extension is certainly "legal" as an output format for LIST.
    However, it breaks compatibility with existing (UNIX) listings, is
    not negotiable or identifiable, and does not address the question of
    internationalization, which is another pressing need in FTP.

    b. draft-bernstein-hcmssc-00.txt: request document not be
    published. There is an competing proposal, and the IETF should
    review both.

    c. draft-bernstein-mail-loops-war-00.txt: request document not be
    published, author will be invited to bring work into the IETF.
    If author declines, the IESG will request the following note be
    added:

    This document has not been reviewed by any IETF working group. The
    IESG believes that it is not a complete protection against mail
    loops, and that some of its analysis is insufficiently detailed to
    ascertain its correctness.

    d. draft-bernstein-netstrings-00.txt: no problem with publication
    as an Informational document.

    e. draft-bernstein-nrudt-00.txt: do not publish. Plan is to invite
    author to submit to the RECEIPT WG. If the author declines the
    invitation, the IESG will request the following note be added:

    This document duplicates work presently being done in the IETF
    RECEIPT working group. The IESG believes that the format
    described here is insufficient for the purpose; in particular,
    its response format is not machine parsable.

    f. draft-bernstein-pirp-00.txt: No problem with publishing as an
    Informational Document (though some wondered who would consider
    implementing), but the IESG will request the following note be
    added:

    This document has not been reviewed in the IETF, nor is it a
    product of any IETF working group.

    g. draft-bernstein-qsbmf-00.txt: No problem with publication as an
    Informational Document, but the IESG will request the following
    note be added:

    This protocol defined in this document duplicates functionality of
    RFC 1892-1894, but is incompatible with those RFCs, and does not
    give a machine parsable format for error messages. Implementation
    will require that users and UAs be able to parse multiple new
    response formats, which will harm interoperability.

    20. The IESG had no problem with the publication of HP Patents
    <draft-mcanally-netmgt-frmwk-rights-00.txt> as an Informational
    document.

    21. The IESG felt that IP Clustering for Load Balancing and Fault
    Resilience <draft-rfced-info-chu-00.txt> should not be published as
    an RFC, as the author would be invited to hold a BOF in the Routing
    Area to determine the level of interest in forming a Working
    Group.

    22. Steve reported on a phone conversation with John Klensin who had
    noted that a number of WGs either do not announce (via the charter)
    the location of WG Email archives, or have invalid (i.e. old)
    locations. Steve mentioned that John said he'd be sending a list of
    "non-existent" archives at some point in the future.

    Steve pointed out that the archives take on new importance with the
    acceptance of the Poised95 documents as those archives are declared
    to be part of the official record (so they better exist and be
    accessible).

    An inconsiderate, il-timed suggestion was made that Steve check
    them all out. His response was lost due to loud interference on the
    line (which someone suggested sounded like paper being crushed
    right next to the phone - though no one knew who would use such a
    cowardly technique.

    23. A discussion on the topic of how to handle/process individual
    submissions was attempted, but as the teleconference had already
    exceeded the time allotment, and after Steve pointed out there was
    only ONE non-WG document that might be on next week's agenda, the
    discussion was deferred.