Skip to main content

Minutes interim-1991-iesg-01 1991-07-30 16:00
minutes-interim-1991-iesg-01-199107301600-00

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 1991-07-30 16:00
Title Minutes interim-1991-iesg-01 1991-07-30 16:00
State (None)
Other versions plain text
Last updated 2024-02-23

minutes-interim-1991-iesg-01-199107301600-00
IETF STEERING GROUP (IESG)

MINUTES OF THE IESG MEETINGS

DURING THE 21st IETF PLENARY

JULY 30 AND AUGUST 2ND.

Reported by:
Greg Vaudreuil, IESG Secretary

This report contains

- Meeting Agenda
- Meeting Attendees
- Meeting Notes
- Summary of Action Taken
- Summary of Positons Taken

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

LUNCH MEETING
-------------

The IESG met for lunch Tuesday, July 30th to discharge action items,
review the IETF meeting and plan for the upcoming open plenary.

Attendees
---------

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

Regrets
Crocker, Dave / DEC
Hinden, Robert / BBN

Agenda
------

1. Point to Point Protocol
2. SAAG report
3. Review of the OSI Area
4. Interaction between working groups and area directorates.

Minutes
-------

1. Point to Point Protocol

The Point to Point protocol working group met to discuss the future
directions of the working group. Noel Chiappa was pleased to announce
that Brian Lloyd will take a position as the new working group
chairman. A revised charter is currently being written.

2. SAAG Report

The Security Area Advisory Group met to discuss several outstanding
issues.

IP Security Option. The IPSO crowd agreed to agree to an arrangement
by September 30th. The IESG was a bit confused by this, but
recognized that this is at least a small step forward in resolving
this thorny issue.

Commercial IP Security Option. The SAAG was happy with this work in
general. There is more work needed, both to give the existing work
context, and to flesh out the protocol.

3. Review of the OSI Area

Ross Callon opened a discussion on the relative positioning of working
groups in the OSI area and in other IETF areas. Ross proposed that to
increase the attention given to OSI issues, and enhance OSI's
integration into the operational Internet by distributing some WG's to
other appropriate areas. For example, groups like ODA and X.500 are
clearly application level efforts designed to run as applications for
the TCP-IP suite of Internet protocols, and it would be appropriate to
move these group either to be in the Applications area, or to be joint
between the OSI and Applications areas.

I was pointed out that other efforts intended to foster the growth of
OSI network layer and full stack efforts clearly need the special
support of the OSI area. This special OSI support provides a focus
for identifying OSI specific problems and insuring that they receive
the management attention needed to resolve outstanding issues. It was
also pointed out that some Area Directors are overloaded and some WG's
are already not receiving the guidance and attention they need. Giving
AD's further OSI WG's may in many cases reduce the attention these
topics received, not enhance it.

The IESG discussed this idea for a while and did not reach any firm
conclusions but pledged to continue to investigate the integration of
OSI protocols into the IESG. It was agreed that where appropriate it
would make sense to move, or add joint responsibility, to some WG's,
for example those bringing new OSI applications up in the TCP/IP
stack. This discussion was given an element of immediacy by the recent
departure of Rob Hagens from the IESG. The current stack of working
groups and independent OSI engineering efforts is far to large for a
single area director.

4. Working group, Area Directorate interactions.

The Area Directorates of the IESG provide a level of essential
guidance and service to working groups that is now indispensable.
This system has been more or less formal across the full range of
directorates. In particular, both the SAAG, and the Network Management
Directorate provide direct expertise to working groups solving "real"
problems, enabling them to make good progress while considering the
full impact of their work on the security and network management
infrastructure. The User Services area Council and the Operations
area directorate are expected to provide a similar range of support in
the near future.

The IESG discussed this development, and attempted to formalize a
mechanism for working groups to begin a liaison. Two primary
mechanisms were identified.

1) All working group charters are reviewed by the full IESG prior to
their formal formation. At this time an area director can assign
resources or identify a need for future support.

2) Working groups engaged in writing a specific protocol may find a
lack of expertise in one of the "overarching" areas, Security, Network
Management, or Operations, and call in support.

ACTION: Coya -- Write up the mechanisms for Directorate support of
working groups in the IETF Handbook.

IESG DINNER
-----------

The IESG met for dinner Thursday, August 2nd to discharge action
items, review the open plenary session, and craft recommendations on
specific protocols.

Attendees
---------

Almquist, Philip / Consultant
Chiappa, Noel / Consultant
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

Regrets
Borman, David / CRAY
Callon, Ross / DEC
Crocker, Dave / DEC

Guests
Steve Kent/ BBN

Agenda
------

1. Review of Protocol Actions
- MIB II
- Concise MIB
- IP over Frame Relay
- Router Discovery
- Bridge MIB
- Remote Monitoring MIB
- FDDI MIB
- Decnet Phase IV MIB
2. Distinguished Names
3. RFC Editor Actions
- Finger revisions
4. IPLPDN and the IP routing model
5. Review results of the IP Addressing BOF
6. Next Meeting

Minutes
-------

1. Protocol Actions

1.1 MIB II To Full Standard

The IESG agreed to recommend the elevation of MIB II to Full Standard.
This will be the first Full Standard progressed entirely under the
modern standards system.

1.2 Concise MIB to Draft Standard

The IESG agreed to recommend this new format for MIB definitions as a
Draft Standards.

1.3 Network Time Protocol Version 3.

This IESG agreed to recommend the publication of this protocol as a
Proposed Standard. It was developed by David Mills and reviewed by a
technical review committee appointed by Craig Partridge.

Steve Kent pointed out that version 2 of this protocol is clearly
spoofable. The PSRG reviewed this protocol and concluded that any known
security mechanism would excessively burden the protocol. The analogy
used was that of delivering a letter by registered mail telling you
that it was six o'clock.

It is not clear whether version 3, the current version addresses the
security weakness, but it was suggested that this security weakness
should at least be noted in the document.

The IESG concluded that this protocol has been delayed excessively and
was unwilling to hold it up further. If security is not adequately
addressed in this document, it may be added in the Draft Standard.

1.4 IP over Frame Relay

The IESG agreed to recommend the publication of this protocol as a
proposed standard. The IESG discussed the implications of using both
the NLPID and the SNAP header for identification of the protocol being
carried, and agreed that it seemed a tad awkward, but agreed that it
would work and that the working group had good reason to specify the
protocol in this manner.

1.5 Router Discovery Protocol

The IESG agreed to recommend the publication of this protocol as a
proposed standard pending the clarification of one technical point.
The security issues raised previously have been addressed by adding
text to the document explaining the security limitations of this
protocol as well as a configuration flag to disable both use of this
protocol and processing of unsolicited packets. A concern was raised
by Steve Kent about the accepting of default router announcements
if the host has been configured.

ACTION: Chiappa -- Investigate the router discover protocol and
confirm that a configuration mechanism exists to turn off the
acceptance of default router announcements if the host is properly
configured.

1.6 IEEE 802 Bridge MIB, FDDI MIB, Remote Monitoring MIN, Decnet Phase IV MIB

These MIB's were reviewed by the Network Management directorate, and all
were found to be acceptable with a few editorial and syntactic
changes. Final versions will be posted to the Internet Drafts
directory and the IESG will consider them for proposed standard at
that time.

The letter to the IEEE explaining the IAB policy on external MIB's
needs to be sent when the protocol is approved for Proposed Standard.

2. Distinguished names.

The need for a distinguished name registry is becoming increasingly
important as PEM and the CAT groups near completion. The registry is
a necessary component of the deployment on many security services on
the Internet. The IESG did not have time to discuss this in detail,
but took an action to discuss it in the future.

ACTION: Greg Vaudreuil -- Schedule a discussion on distinguished names
at an upcoming IESG Teleconference.

3. RFC Editor Actions

3.1 Finger User Information Protocol

The RFC Editor has received a new version of the Finger document.
This new document makes several changes to the protocol to bring the
specification more closely into line with existing implementations of
this protocol. The RFC Editor requested the IESG investigate this
protocol to determine the correct course of action.

POSITION: If the revision to the Finger protocol amounts to a
technical bug fix, or clarifies the specification of the operation of
the protoco , the protocol may remain at Draft Standard, but if the
change introduces new functionality, or changes the behavior of the
protocol, it will need to be reissued as a proposed standard.

ACTION: Vaudreuil -- Send a note to the RFC Editor requesting that he
send the document to the IESG for review.

4. IPLPDN Working Group and the IP Model

The IP over Large Public Data Networks working group has begun
exploring novel ways to connect together different IP networks which
reside on a common SMDS network without using IP routers. The
triggered the IESG to review the IP routing model, to determine if
such a change to the architecture is reasonable.

The standard IP model holds among other points:
- IP networks (or IP subnets) are connected by an IP router
- a redirect is sent to the originating host by the first hop (i.e.
directly connected) router when the current first hop router is not the
best first hop router for that destination.
- hosts on one IP network (or IP subnet) can only communicate with hosts
on another IP network (" " ") by going through an IP router
- the process of turning an IP address into a local network address is
a completely separate step from picking the IP address of the next
hop; this former step is insulated entirely in the code which interfaces
IP to a given local network

The IPLDPN is considering several schemes to allow hosts (and routers)
on distinct "logical" IP networks which share a common SMDS physical
network to communicate directly without the necessaity of taking a
useless "extra hop" through an IP router. The details vary, but in
general they involve tighter integration of the local address
resolution process with IP level routing.

After reviewing these to points, the IESG agreed that the approach
currently being considered by the IPLPDN Working Group is not in
conformance with the current model, and without a compelling reason,
the IESG will not change the IP routing architecture.

These systems all require knowledge of the local address resolution scheme
to be propogated into the IP layer of hosts. In addition, the IP routing
architecture is about to go through a period of substantial stresss and
modification, and it is felt that this process will be easier if the
existing model is adhered to.

It was also pointed out that what these proposals effectively were was an
attempt at a "quick-and-dirty" SMDS (and IP) specific solution to the
problems of address resolution in a large WAN. It was the opinion of some
that this was not their understanding of what the WG's goal was when it was
set up; rather, it was thought that the group was to consider the issues of
address resolution and routing in large WAN's, and attempt to design or
adapt common mechanisms to handle these issues, much as ARP was a general
attack on the problem of address resolution in small broadcast LAN's.

ACTION: Chiappa and Hinden -- Investigate the specifics of the IPLPDN
working group's efforts both in address resolution and routing to
determine what direction the working group may need.

5. Results of the Address Hacks BOF

The IP address space BOF met as a 20 minute working group to discuss
the various proposals for increasing the number of IP network numbers
in a manner which will optimize the use of the remaining address space
without adversely affecting routing.

The proposal from the group involves the definition of a new class E
address with a 16 bit network number and a 12 bit rest. These
addresses will use all the currently unallocated portion of the
address space; i.e. that part with a '1111' prefix'. (The entire space
was allocated since the custom of making the prefix longer and longer
at each class is resulting in less useful spaces. A new reserved space
will be created from an unallocated portion of the class A space.) An
argument was made in the BOF session for using the back half of the
class C addresses. This latter approach would be nominally
interoperable with current routing software, but it causes 16 (2^4,
since there are 4 more bits in the 'rest' field of this class) routing
table entries for each new network installed. Given a problem with
scaling already present, this was after some consideration deprecated
as an impracticable idea.

Complete minutes of the meeting will be prepared and be included in
the proceeding for this IETF Meeting.

ACTION: Chiappa -- Write up the thoughts of the 20 minutes working
group as a proposal for a new class of IP addresses

6. Next Meeting

The Next IESG Teleconference was scheduled for August 8th, 12:00 PM
to 2 PM EST.

Summary of Actions
-------------------

ACTION: Coya -- Write up the mechanisms for Directorate support of
working groups in the IETF Handbook.

ACTION: Chiappa -- Investigate the router discover protocol as confirm
that a configuration mechanism exists to turn off the acceptance of
default router announcements after the host is properly configured.

ACTION: Greg Vaudreuil -- Schedule a discussion on distinguished names
at an upcoming IESG Teleconference.

ACTION: Vaudreuil -- Send a note to the RFC Editor requesting that he
send the document to the IESG for review.

ACTION: Chiappa and Hinden -- Investigate the specifics of the IPLPDN
working group's efforts both in address resolution and routing to
determine the what direction the working group may need.

ACTION: Chiappa -- Write up the thoughts of the 20 minutes working
group as a proposal for a new class of IP addresses

Summary of Positions
--------------------

POSITION: If the revision to the Finger protocol amounts to a
technical bug fix, the protocol may remain at Draft Standard, but if
the change introduces new functionality, or changes the behavior of
the protocol, it will need to be reissues as a proposed standard.