Internet Standards/CD1.mdf/INET/IESG/94_10_20

Text File | 1994-11-18 | 7.3 KB | 181 lines

            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
<[e-mail]>.

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: [e-mail]
Subject: generic IESG comments
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: [phone]
Telefax: [phone]
Date: Fri, 04 Nov 1994 09:34:30 +0100
From: "Erik Huizer (SURFnet BV)" <[e-mail]>


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.