Please contact IESG Secretary Greg Vaudreuil for more information.
Attendees
---------
Almquist, Philip / Consultant
Borman, David / Cray Research
Chiappa, Noel
Crocker, Dave / TBO
Crocker, Steve / TIS
Coya, Steve / CNRI
Estrada, Susan / CERFnet
Gross, Philip / ANS
Hinden, Robert / BBN
Hobby, Russ / UC-DAVIS
Huizer, Erik / SURFnet
Piscitello, Dave/ Bellcore
Vaudreuil, Greg / CNRI
Regrets
Davin, Chuck / MIT
Reynolds, Joyce / ISI
Stockman, Bernard / SUNET/NORDUnet
1. Administrivia
1.1 Bash the Agenda
1.2 Approval of the Minutes
1.2.1 February 20th
1.2.2 March 5th
1.3 Next Meeting
2. Review of Action Items
3. Protocol Actions
3.1 The PPP Authentication Protocols
3.2 PPP Link Quality Monitoring
3.3 SNMP Authentication
3.4 BGP NEXT-HOP-SNPA Attribute
3.5 Interdomain Policy Routing
3.6 MD2, MD5 Documents
3.7 Multipurpose Internet Mail Extensions
4. RFC Editor Actions
4.1 HYBRID NETBIOS END-NODES
5. Working Group Actions
5.1 Network Access Server Requirements (nasreq)
6. Technical Management Issues
6.1 ROAD Follow-on
6.4 IDRP over IP
MINUTES
1. Administrivia
1.1 Bash the Agenda
The agenda was approved as written.
1.2 Approval of the Minutes
1.2.1 February 20th
The IESG approved the Minutes of the February 20th teleconference
for public distribution.
1.2.2 March 3rd
The IESG deferred approval of the March 5th minutes.
1.3 Next Meeting
Eric Huizer has asked that the IESG consider moving its
teleconference time so that it no longer conflicts Thursday Evenings
with personal obligations. The IESG was open to the suggestion, and
tasked Steve Coya to juggle schedules to find a new meeting time.
ACTION: Coya -- Poll the IESG and determine if there is a meeting time
available for teleconferences other than Thursday 12-2 EST.
The next IESG teleconference was scheduled for Thursday April 2nd
from 12-2 PM EST. This meeting will be a single topic meeting to
resolve the outstanding administrative issues relating to the
creation of IETF work items for making progress with Routing and
Addressing.
2. Review of Action Items
The actions items were not reviewed during this meeting.
3) Protocol Actions
3.1 The PPP Authentication Protocols
The IESG reviewed the PPP Authentication protocols document. This
document describes a framework and specific protocols for simple
password and more rigorous challange-response authentication.
The IESG approved this document pending two events. The document
itself needs work editorial work in several places to improve the
clarity and the document required the publication of the MD5 Message
Digest algorithm as an RFC before it can be referenced by this
document.
ACTION: Vaudreuil -- Send a recommendation to elevate the PPP
authentication protocols to Proposed Standard as soon as 1) The MD 5
message digest algorithm document is submitted to be published as an
RFC, and 2) A new version of the Authentication Protocols document is
submitted clarifying several editorial points.
3.2 PPP Link Quality Monitoring
The PPP Link Quality Monitoring document reflects a significant
redesign of the original mechanism outlined in RFC 1171. This new
mechanism has been implemented and texted and reflects lessons
learned and has been tested and implmented.
The IESG approved this document for Proposed Standard.
ACTION: Vaudreuil -- Send a recommendation to elevate the PPP Link
Quality Monitoring document to Proposed Standard.
3.3 SNMP Authentication
The IAB has discussed the SNMP Authentication documents and has
asked the IESG for further discussion. Two issues were raised.
First were some relatively minor technical errors which can be
easily corrected, and second, the documents do not appear to meet
the IAB's normal standard for quality writing.
The IESG discussed both of these points. On the first point; The
specific technical points were not clearly communicated to the IESG,
however the IESG expressed dismay at hearing these objections at
this late time, after a through public review and a last call
period. The IAB is working directly with the authors to resolve
these points.
The harder question for the IESG was the document writing style
itself. The IESG recognizes the the quality of documents is quite
variable. The IESG has had the practice of approving proposed
standard documents if there are no glaring technical errors, and the
document meets the requirements for formatting and gramatical
correctness. Reviewing documents for writing style and clarity is
difficult.
POSITION: As long as a Proposed Standard document is technically
acceptable, the writing is readable to the extent necessary to
implement from. and the document reflects a best effort given the
limited resources of the IETF, the IESG will approve such a document.
3.4 BGP NEXT HOP SNPA Attribute
The IAB has discussed the BGP Next Hop SNPA Attribute and has asked
the IESG for clarifications on several points.
The specific question the IAB raised concerns the behavior of the
attribute across different networking technologies, especially
across multi-media bridges. The IESG discussed and agreed to ask
the working group to re-examine the intended scope of this
protocol. The IESG also discussed the implications of operating a
protocol like the SNPA attribute across a multi-media bridge, and
concluded that this is not a real concern at this time. Multi-media
bridges have not yet been architected into the system and many
protocols break across them, not just this one.
ACTION: Hinden -- Begin a dialogue with the the BGP working group to
explore the intended scope of the BGP Next Hop SNMP Attribute.
3.5 Interdomain Policy Routing
The Interdomain Policy Routing Working Group has asked the IESG to
consider IDPR for Proposed Standard. The IESG agreed that it is
appropriate to standardize IDPR according to the proceedures
documented in RFC 1264.
A last call will be issued once the final version of the protocol,
as well as the required reports are submitted to the Internet Drafts
directories. One of the reports that IESG has asked for is a
discussion on the interworking of IDPR with BGP in the Internet.
ACTION: Vaudreuil -- Send a last call for IDPR once the final version
is posted as an Internet Draft.
ACTION: Hinden -- Communicate with the IDPR Working Group the need for
updated documents and reports before approval for Proposed Standard.
3.6 MD2, MD5 Documents
Several Security related protocols reference the MD2 and MD5 Message
Digest Algorithms. These algorithms are documented in Internet
Drafts that should be published as informational RFC's. There is
new text for both of these documents.
ACTION: Vaudreuil -- After new text is submitted to the Internet
Drafts, send a notification to the RFC Editor that the documents are
ready to be published as RFC's.
3.7 MIME
The Internet Mail Extensions Working Group has submitted a revised
version of MIME to the Internet Drafts directory and has asked the
IESG to consider it for Proposed Standard. The new version reflects
the changes requested by the IESG. The IESG has received an
objection from EUnet, a network con sortium analagous to UUnet.
They object to the separation of the Mnemonic character set proposal
from the main MIME standard. The IESG discussed this objection,
but concluded that the specific objections could not be accommodated
in the current document due to rules for citations, but that the
functionality requested could still be achieved via registration of
the mnemonic character set with IANA.
ACTION: Hobby -- Send an IESG response to the EUnet objections.
The IESG discussed the changes, and approved MIME for Proposed
Standard, providing that a second last call is issued and no new
serious issues are uncovered.
ACTION: Vaudreuil -- Send a second last call to the IETF list for MIME
soliciting any objections to the changes in the current draft.
4.0 RFC Editor Action
4.1 NETBIOS over TCP
Fredrick Noon was contacted by the IESG Secretary and was asked to
clarify the intended status for the protocol. He has responded that
he would like the document to be entered on the standards track.
ACTION: Vaudreuil -- Send note to Postel taking the Netbios document
into the standards process.
The IESG discussed the need for community review, but was not able
to resolve the question of whether an IETF Working Group would be
the best place to review this proposal.
ACTION: Borman -- Do some intellegence gathering, determine the
constituency, and determine whether a working group or a one-shot BOF
is necessary for review of the Netbios over TCP document. Determine if
Noon is willing to chair a working group or BOF to review this
protocol.
5.0 Working Group Actiosn
5.1 Network Access Server Requirements
The IESG has reviewed the nasreq working group. Steve Kent raised a
question of overlap between this group and others with similar
sounding charters which pointed out that the scope of the group is
not well defined. A new charter which more clearly specifies the
work to be accomplished is needed.
ACTION; Hobby -- Work with the prospective chairman of the nasreq
working group to refine the scope of the Working Group and generate a
new charter.
6.0 Technical Management Issues
6.1 Routing and Addressing
The ROAD group, chartered by the IAB has given its recommendations
to the IETF for future work in Routing and Addressing. The IESG
began discussions on a workplan to solve the routing and addressing
issues facing the Internet.
6.1.1 Class B Number Assignment
The Class B numbers are being consumed at a high rate. It is clear
that they will run out in the near future. While the IETF works on
a plan for extending the class B address space, policies for the
assignment of network addresses need to be made.
This IESG discussed several ideas including charging for the cost of
assigning and routing IP addresses, but did not reach resolution.
There was a clear sense that the IETF "ownes" this problem and that
work should begin on formulating assignment guidelines.
6.1.2 Short Term Addressing
There are two proposals on the table for resolution of the Class B
depletion problem, C-Sharp (C#), a creation of additional Class B
numbers, and CIDR, Classless Interdomain Routing. Both proposals
appear to address the short term needs, but have relative advantages
and dis-advantages. C# mostly solves the C# of B address problem
but does not address the aggragation of addresses necessary to
contain the routing table explosion. The immediate need to work on
a single solution requires a choice of one of these proposals to
pursue.
The decision on the choice of Cider vs C# depends on projections on
when the addresses will run out. These numbers have not been made
available to the IESG. The numbers used by the ROAD group in
crafting their recommenation for CIDR are statistically sensitive
projections and as such there is a reluctance to release the numbers
to a wider community.
The IESG discussed the tension between the need to move forward
rapidly on this issue and the demands for openess. This tension
results from the dual responsiblity of the IESG for both the
operational stability of the Internet and the need for complete and
accepted standards.
The IESG will continue this discussion in a single topic
teleconference April 2nd.
6.4 Dual IDRP
An effort to begin work on Dual IDRP (ISO BGP) has begun in the noop
Working Group. This work needs to procede in the Routing area, but
is not clear whether is should be in the IS-IS working group or a
new Dual IDRP Working Group.
ACTION: Hinden -- Find a home for the Dual IDRP work in the Routing Area.
