Minutes interim-1991-iesg-04 1991-08-29 16:00
minutes-interim-1991-iesg-04-199108291600-00

IETF STEERING GROUP (IESG)

REPORT FROM THE TELECONFERENCE

AUGUST 29TH, 1991

Reported by:
Greg Vaudreuil, IESG Secretary

This report contains

- Meeting Agenda
- Meeting Attendees
- Meeting Notes

Please contact IESG Secretary Greg Vaudreuil
/>(iesg-secretary@nri.reston.va.us) for more details on any particular topic.

Meeting Attendees
-----------------

Almquist, Philip / Consultant
Borman, David / CRAY
Callon, Ross / DEC
Chiappa, Noel
Crocker, Dave / DEC
Crocker, Steve / TIS
Coya, Steve / CNRI
Davin, Chuck / MIT
Estrada, Susan / CERFnet
Gross, Philip / ANS
Hobby, Russ / UC-DAVIS
Hinden, Robert / BBN
Reynolds, Joyce / ISI
Stockman, Bernard / SUNET/NORDUnet
Vaudreuil, Greg / CNRI

Agenda
------

1) Administrivia
- Bash the Agenda
- Review of the Minutes
- July 30th - Aug 2nd. (Pending Gross's review)
- August 8th (Pending Gross's review)
- August 15th (pending 15th)

2) Review of Action Items

3) Protocol Actions
- TCP Large Windows
- BGP
- IP Frame Relay
- Inverse Arp
- X.500 docs

4) RFC Editor Actions
- Message Send Protocol (OK?)

Minutes
-------

1. Administrivia

1.1 Agenda Bashing

The Agenda was approved as is.

1.2. Approval of Minutes

1.2.1 July 30th - Aug 2nd.

These minutes, the first to be release publicly have been approved by
the IESG pending a review by the Chairman.

1.2.2 August 8th

These minutes have been approved pending review by the Chairman,

1.2.3 August 15th

Review of these minutes was not undertaken.

2. Review of Action Items

A review of action items was conducted by E-mail. Actions were not
reviewed in this meeting.

3. Protocol Actions

3.1 TCP Extensions for High Delay, High Throughput Paths.

The IAB responded to a request from the IESG to outline the technical
objections to the TCP extensions. The IESG agreed that these issues
were important and decided by email prior to today's meeting to
withdrawing the recommendation made June 16th to collectively make
RFC-1072 and RFC-1185 collectively a Proposed Standard.

The IESG reviewed and approved the notice withdrawing the IESG
recommendation pending a final technical review by Dave Borman.

ACTION: Vaudreuil -- Send the notice withdrawing the IESG
recommendation elevating the TCP extensions to the IAB with a CC to
the IETF.

The IESG discussed and further affirmed the need for the IESG and IAB
to communicate openly, preferably by sending notices to the IETF
mailing list. In particular, in cases where technical deficiencies are
found, they should be noted and publicized. The specific mechanism for
this communication was the subject of preliminary debate, but due to
lack of time, further discussion of process was deferred.

3.2 BGP

The BGP protocol elevation is still pending the identification and
resolution of IAB concern. A teleconference is planned to give a
final opportunity to IAB members to raise specific concerns before the
IESG recommendation is publicly sent to the IAB. If this meeting
cannot be arranged before Interop, a face to face meeting will be
called for Wednesday evening for this discussion.

The revised BGP usage document resulting from the IESG editing session
August 15th is not yet available on-line.

ACTION: Gross -- Publish the latest draft of the BGP usage document as
an Internet-Draft

3.3 IP over Frame Relay

A discussion has begun between the IESG and the IAB about the
procedure for standardizing IP over Frame Relay. The IESG has
received a proposal from the IPLPDN working group which offers a
technically sound proposal. Because the Frame Relay standards lack a
mechanism for identifying the carried protocol, the working group was
compelled to specify a mechanism.

The sense the IESG gathered from the discussion was that the IETF
should be aware that standardizing protocols which are in the domain
of another standards body is a delicate matter. In the protocol
specifications it needs to be made clear that the IAB is not
standardizing a Frame Relay protocol, but is narrowly standardizing a
mechanism for running IP over Frame Relay.

The open issue is whether it is acceptable to specify a standard
mechanism for running multi-protocols over Frame Relay for the
"I"nternet. The mechanism and standard are needed now, and a
specification has been provided. Three approaches have been suggested
for dealing with this concern.

1) Publish the document as is, with a new title emphasizing the use of
the multi-protocol mechanism as "I"nternet specific. This focus is
aimed at reducing the perception that we are standardizing anything
about Frame Relay proper, but rather a profile for the use of Frame
Relay in the multi-protocol Internet.

2) Separate out the "Multi-protocol Interconnect" portion of the
document into an appendix, where the multi-protocol portion is not
strictly part of the standard, but is included for "information".

3) Publish two documents, one IP over Frame Relay as a Proposed
Standard, and the second Multi-protocol interconnect as informational.

Both Options 2 and 3 present the unfortunate situation where the IP
over FR standard depends on a non-standard informational document. It
is anticipated that this document would be sent to ANSI for
standardization, but in any event, the standardization of what is
likely a popular service will be delayed pending action of an external
body.

The IESG prefers option 1, which by limiting the scope of the
multi-protocol mechanism to Internet use allows the document to be
implemented, and advanced without time-delaying dependencies. If the
IAB objects to this approach, the IESG will re-consider option 2 and
3.

ACTION: Vaudreuil -- Send the IAB a query with this 3 step multiple
choice. If no objections are raised, send the recommendation with the
new title to the IAB Thursday the September 12th.

3.4 Inverse ARP

The IESG was not completely happy with the new motivations section.
The new text elaborates on the need for an mechanism for address
resolution, but did not include discussion of the rationale for the
decision to write Inverse ARP rather than use ARP, Reverse ARP, or some
IP specific mechanism.

ACTION: Vaudreuil -- Contact the author of the Inverse ARP document
and relate the specific comments of the IESG, encouraging the writing
of a more complete rationale section.

3.5 X.500 documents.

Ross Callon sent a comprehensive list of X.500 documents that are
ready for publication. These document include standards track,
experimental, and informational documents.

3.5.1 ``Replication Requirements to provide an Internet Directory
using X.500''

This document discusses the requirements for replication of X.500
information for use in the Internet. Some of these requirements are
general to X.500 (e.g.; we need replication and the OSI standard is
not done yet); some are specific to the Internet (the need to be able
to operate over RFC1006).

Callon suggested that this document be published as an informational
document. The IESG agreed.

Action: Vaudreuil -- Write a recommendation to publish
<draft-ietf-osids-replication-03> as an Informational document.

3.5.2 ``Replication and Distributed Operations extensions to provide
an Internet Directory using X.500''

This document outlines solutions to the replication requirements
discussed above. These solutions are based on the current QUIPU
implementation, with a few extensions.

It must be understood that the mechanisms specified in this document
are for INTERIM use only. In particular, it is anticipated that these
mechanisms will be replaced by work that is currently ongoing in
ISO. In addition, the mechanisms outlined in this paper, although
important for use in current X.500 pilots, are not likely to be
adequate for long term use.

There is an issue relating to the fact that although this document is
clearly interim, it is likely to be used for some time (the OSI work
on replication does not seem to be about to be finalized). Thus it
could be reasonably argued that this should be on the standards track.

The IESG agreed that this document should become a standard, with the
understanding that it will be superseded when the relevant ISO
standard is defined. The IESG discussed in depth the issues involved
with standardizing what is under development in other standards
bodies, but agreed that in this case a standard is clearly needed now.
There has been liaison between the FOX Directory Pilot and the RARE
Cosine work. With coordination and a clear statement of intention in
the status of the memo section, the IESG feels this should be a
proposed standard for Internet use.

POSITION: The IESG recognizes the need to make certain protocols
Internet specific standards in the Interim until a standard is
promulgated by an external standards body with the appropriate
jurisdiction.

ACTION: Vaudreuil -- Confirm that the FOX directory Pilot participants
have been kept involved in the IETF directory efforts.

ACTION: Vaudreuil -- Write a recommendation to publish
<draft-ietf-osids-replsoln-03> as a Proposed Standard.

3.5.3 ``An interim approach to use of Network Addresses''

There is a need, for operation of OSI applications (including the
directory service) over RFC 1006, to have a unique and unambiguous
means for identifying IP addresses in OSI NSAP address fields. This
document specifies a unique and easy to identify method for doing so.
This mechanism ensures that anyone who has a valid IP address,
"automatically" has a valid way to identify the IP address in an NSAP
address field. The fact that the mechanism employed utilizes a
relatively obscure part of the NSAP address space is not a problem,
and may in fact be considered to be a useful feature.

This document specifically applies to use of OSI applications over
X.25, or over TCP/IP using RFC 1006. (ED note: What was the issue
with this? A section needed renaming? why?)

ACTION: Callon -- Insure that the relevant section of ``An interim
approach to use of Network Addresses'' document referring to X.25
NSAP's be edited. (????)

ACTION: Vaudreuil -- Write a recommendation to publish
<draft-ucl-kille-networkaddresses-04> as a Proposed Standard.

3.5.4 ``A string encoding of Presentation Address''

This document provides a string encoding of OSI presentation
addresses, which is appropriate for use in human interactions, for
humans to write on paper, and for human to machine interfacing. It is
important to recognize that the encoding specified here is not
intended for internal storage inside the directory system.

Ross Callon and the author Steve Hardcastle-Kille agreed that this
should be a standards track document. A long discussion ensued about
the appropriateness of standardizing user interfaces and presentation
formats. The IESG was generally of the belief that a human exchange
format like RFC 822 addresses was needed, but it was not clear whether
they should be explicit standards or just common practice. The
specification of a single "common" format gained significant support,
but no consensus was reached.

Other groups are beginning to standardize presentation formats,
including the Operational statistics group, which is working on
standard maps and standards reports.

No resolution was reached on the status of this document.

ACTION: Vaudreuil -- Schedule a discussion on the appropriateness of
standardizing presentation formats.

3.5.5 ``Using the OSI Directory to achieve User Friendly Naming''

This document is of critical importance, and completes an important
part of the directory/naming service which is a serious hole in the
existing OSI standards. Solution to the problem of user friendly
naming is critical to wide-spread acceptance and use of OSI
Applications.

The IESG agreed that this should be a proposed standard, but the IESG
wanted a specific applicability statement which would designate this
format as a "common" Internet format, where other local formats are
acceptable.

ACTION: Gross -- Write an applicability statement for ``Using the OSI
Directory to achieve User Friendly Naming''

ACTION: Vaudreuil -- Write a recommendation to publish
<draft-ietf-osids-friendlynaming-02> as a Proposed Standard.

3.5.6 ``The COSINE and Internet X.500 Schema''

This provides an important list of defined types of information which
is to be stored in X.500 directories. Publication of an Internet
Standard for these types is important to allow commonality across
directories. For example, this is useful to avoid confusion, and is
essential for searches across multiple DSAs.

We understand that this document will grow and change over time as
the schema is upgraded and more types of information are added to the
directory. Nonetheless, this work is appropriate for standardization
(In this one limited sense, this document may be somewhat analogous
to the series of Internet Assigned Numbers RFCs). Also note that the
document (appropriately) contains duplication of some details from the
X.500 standard. This will also need to be updated in the future.

This document is a joint effort with the RARE Cosine project. There
was a question in the IESG about who has change control authority over
the document. While the specific answer was not clear, Callon assured
the IESG that an arrangement had been worked out between Postel,
Hardcastle-Kille, and the Cosine representatives.

The IESG approved this document for proposed standards status.

ACTION: Vaudreuil -- Write a recommendation to publish
<draft-ietf-osids-cosinex500-05> as a Proposed Standard.

3.5.7 ``X.500 and Domains''

This provides a description of a possible way to store Domain Name
Service information in an X.500 directory. This is very useful for
sites which have need for both X.500 directories, and for the Domain
Name Service, but which do not want to manage two independent name
services. This is also useful to allow searching the DNS data stored
in X.500.

The IESG approved this document as an experimental protocol

ACTION: Vaudreuil -- Write a recommendation to publish
<draft-ucl-kille-x500domains-03> as a Proposed Standard.

4. RFC Editor Actions

4.1 Message Send Protocol.

The RFC Editor sent a document to the IESG for a sanity check. This
protocol is an enhancement to RFC 1159. Hobby had no objections to
this document. S. Crocker pointed out that the protocol as defined
leaves a rather large hole for nuisance, denial of service, and
potentially file read and write access.

The IESG agreed that this document as an experiment should be
published, but that it should include a better description of the
security implications of the protocol with guidelines to implementors
on how to limit the security threat.

The IESG began a discussion on the requirement to address security.
Current practice is now for all protocols to include a discussion of
their security limitations. Now that security technology in the
Internet is maturing into a useful resource, the IESG will strive to
make all new protocols have "real" security built in.

POSITION: Specifications on the standards track must provide adequate
security and/or not undermine existing security. Specifications not
on the standards track should include a clear discussion of the
security implications of the protocol.

ACTION: Crocker -- Send a note to Postel and the author of the Message
Send Protocol pointing out the IESG concerns about security, and
include suggested text to satisfy the IESG.

4.2 Security Information Transfer Protocol

This was not discussed, but Crocker communicated with Postel. It
appears there is a constituency for this protocol and we have begun to
review the protocol to determine what technical and political issues
need to be dealt with.