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
<[email protected]>.

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: [email protected]
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)" <[email protected]>


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.

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.