Skip to main content

Minutes interim-1994-iesg-19 1994-10-20 15:30
minutes-interim-1994-iesg-19-199410201530-00

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 1994-10-20 15:30
Title Minutes interim-1994-iesg-19 1994-10-20 15:30
State (None)
Other versions plain text
Last updated 2024-02-23

minutes-interim-1994-iesg-19-199410201530-00
											
Minutes of the IESG Teleconferences

    INTERNET ENGINEERING STEERING GROUP (IESG)
    20 October 1994

    Reported by: John Stewart, 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 at
    <iesg-secretary@cnri.reston.va.us>.

    ATTENDEES
    ---------
    Bradner, Scott / Harvard
    Halpern, Joel / Newbridge Networks
    Klensin, John / MCI
    Knowles, Stev / FTP Software
    Mankin, Allison / NRL
    Mockapetris, Paul / ISI
    O'Dell, Mike / UUNET
    Rekhter, Yakov / IBM (IAB Liaison)
    Rose, Marshall / DBC
    Stewart, John / CNRI
    Topolcic, Claudio / BBN

    Regrets
    -------
    Coya, Steve / CNRI
    Huitema, Christian / INRIA (IAB Liaison)
    Huizer, Erik / SURFnet
    Reynolds, Joyce / ISI
    Schiller, Jeff / MIT

    1. The minutes of the 6 October IESG teleconference were approved.

    2. Protocol Actions

    o The IESG approved moving "Gateway Requirements" <RFC 1009> to
    Historic.

    o The IESG approved "BGP4/IDRP for IP---OSPF Interaction"
    <draft-ietf-idr-bgp4ospf-interact-08.txt> for the status of
    Proposed Standard.

    o Pending a modified protocol write-up by Erik Huizer, the IESG
    approved:

    - "Uniform Resource Locators (URL)"
    <draft-ietf-uri-url-08.txt>

    for the status of Proposed Standard. The IESG also recommends
    to the RFC Editor that:

    - "Functional Requirements for Internet Resource Locators"
    <draft-ietf-uri-irl-fun-req-01.txt>
    - "Requirements for Uniform Resource Names"
    <draft-ietf-uri-urn-req-01.txt>

    be published as Informational RFCs. The motivation behind
    modifying the write-up is so there is an official record for the
    community, including the working group and [a possibly different]
    IESG, of issues which need to be addressed before elevating the
    documents from Proposed to Draft Standard. The comments are
    attached to the end of these minutes.

    ACTION(Klensin): Contact Erik Huizer about adding some text to the
    protocol write-up.

    3. Management Issues

    o A request has been made to have a BOF in San Jose to review
    the current revision to the standards process (draft-iab-
    standards-processv3-00.txt). This is very relevant to POISED,
    so, as the responsible IESG member, Paul Mockapetris will
    approach the POISED Chairs about their time-table on reviewing
    the Internet-Draft. It was noted that a firm decision has not
    yet been made on the question of term lengths for interim
    appointees, and as long as POISED is being approached, they
    should be asked this question as well.

    ACTION(Mockapetris): Ask Steve Crocker and Mel Pleasant about their
    plans for (1) reviewing the current revision to the standards
    process and (2) deciding on the term-length question.

    o The IESG agreed that during the host requirements effort, the
    tradition of 'modularizing' the documents into upper and lower
    layers should be kept. It was noted that at the upper layers,
    there would probably be a separate document for each major
    application (e.g., FTP, 822/[E]SMTP/MIME, TELNET, etc.). In
    addition, the IESG agreed that the host requirements documents
    should contain clarification, explanation *and* A/S-directive
    material (i.e., as opposed to separating that material out into
    different documents).

    o The IESG agreed to the following clarification of procedures
    for Internet-Drafts:

    - Anyone may publish anything under their own name.
    - When a submission is made in the name of a working group,
    the Secretariat will forward the submission to the chair
    of the working group. The chair then has the right to
    prevent the Internet-Draft from being announced as a
    product of the working group (though the author may have
    it announced as an individual submission).
    - If a chair allows a document to be announced, but the
    responsible area director disagrees, the area director
    can have the document renamed to become an individual
    submission (not associated with the working group).

    Attachment: Issues UR* Documents Need to Address Before Elevation

    To: uri@bunyip.com
    Subject: generic IESG comments
    Organisation: SURFnet bv
    Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
    Phone: +31 30 310290
    Telefax: +31 30 340903
    Date: Fri, 04 Nov 1994 09:34:30 +0100
    From: "Erik Huizer (SURFnet BV)" <huizer@SURFnet.nl>


    While these documents represent major steps forward in the definition and
    standardization of information resource location and identification, they do
    not address at least two issues that will become increasingly important as
    the Internet continues to grow. The necessity for solving these problems is
    generally understood in the community and it is usually assumed that the
    solution lies in URNs/URCs, but the URN requirements document does not yet
    cover them. Resolution of the issues will be a precondition for moving of
    the standards-track documents to Draft Standard.

    The issues are:

    --> Scaling and replication.
    URLs point, or seem to point, to absolute locations on named hosts in
    the DNS. While a number of "proxy" and "caching" schemes have been
    proposed (and some have been deployed), Internet experience has been that
    these problems are best solved by having multiple places in which to look,
    not just caches of things found once already. Caches improve performance,
    but do nothing for robustness. A long-term solution that provides the
    ultimate client (or its proxy) multiple locations to look for the resource
    is a requirement, just as the ability to support multihomed hosts and
    multiple-preference MX records is a requirement for the DNS. Whether this
    should be done through a modified URL, some URN construction, or some other
    mechanism requires further definition and development.

    --> Protocol-dependence.
    The URL model involves a tuple of a protocol, a domain, and a
    protocol-and-domain-specific string. A given resource might reasonably be
    expected to be accessible via several protocols, and a server supporting
    several protocols for one resource might rationally construct the
    protocol-specific form of that resource on the fly during protocol negotiation.

    Such a server would then want to advertise as many different URLs for the
    same resource as the number of protocols it supported. This leads to
    rapidly growing
    aggregate record sizes for the information that might be returned in
    response to a query. Whether this represents a problem should be the
    subject of testing and examination while the documents are in Proposed
    Standard status.

    More important, the owner of the server might then make all resources on
    that server
    accessible via a new protocol simply by installing a handler/converter for
    it. But the model set forth in these documents provides no model by with
    existing records that point to the resource might be updated to the new
    protocol information. This may be a significant point of
    incompleteness in the model and proposed protocol. The mechanism for
    propagating a new retrieval method from a multi-method repository/server
    here must be resolved before the resource location documents move to Draft
    Standard.