[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for June 12, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the June 12, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- May 29, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: June 09, 2003
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking architectural
questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex to send proposal and justification for interim document review.
IP o Ted to write straw working group procedures for handling consensus-blocked
decisions
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the current
info/proposed/etc.
o Harald Alvestrand to talk to RFC Editor about independent submissions.
o Secretariat to include the following statement (line) before the draft
approval announcement that is part of a ballot.
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
o IESG to review IANA matrix data.
DONE o Alex to send RFC Editor Note for draft-ietf-ppvpn-framework-08.txt
addressing Bert's and Ted's concerns.
DONE o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
IP o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
DONE o IP Telephony (iptel). Secretariat to send a WG Action: RECHARTER
Announcement.
DONE o SIP for Instant Messaging and Presence Leveraging Extensions (simple).
Secretariat to send a WG Action: RECHARTER Announcement.
DONE o Content Distribution Internetworking (cdi). Ted Hardie to send a note for
the minutes documenting why the IESG chose to close the WG while some
documents are in RFC Editor's Queue. Ted to prepare the WG Action:
WG to Conclude Announcement for the Secretariat to send.
DONE o Developing High Quality SNMP Agents (Informational)
<draft-aromanov-snmp-hiqa-04.txt>. Secretariat to send a replacement
message to RFC Editor
DONE o RADIUS Support For Extensible Authentication Protocol (EAP)
(Informational) <draft-aboba-radius-rfc2869bis-22.txt>. Secretariat to send
Document Action Announcement.
DONE o IANA Charset MIB (Informational) <draft-mcdonald-iana-charset-mib-02.txt>.
Secretariat to send DA Announcement.
IP o Printer Finishing MIB (Informational) <draft-ietf-printmib-finishing-16.txt>
RFC Editor's Note to be prepared by Ned Freed. Secretariat to send
Document Action Announcement including RFC Editor's Note.
DONE o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-20.txt>. Secretariat to send Document Action
Announcement including RFC Editor's Note.
DONE o IS-IS Cryptographic Authentication (Informational)
<draft-ietf-isis-hmac-04.txt>
Secretariat to send Document Action Announcement.
IP o Collective Attributes in LDAP (Proposed Standard)
<draft-zeilenga-ldap-collective-08.txt>.
Under discussion by Steve Bellovin and Russ Housley.
DONE o Delegation of E.F.F.3.IP6.ARPA (BCP)
<draft-ymbk-6bone-arpa-delegation-01.txt>
Secretariat to send Protocol Action Announcement.
DONE o Printer MIB v2 (Proposed Standard) <draft-ietf-printmib-mib-info-15.txt>
Secretariat to send Protocol Action Announcement.
DONE o Textual Conventions for IPv6 Flow Label (Proposed Standard)
<draft-ietf-ops-ipv6-flowlabel-01.txt>
Secretariat to send Protocol Action Announcement.
DONE o Registration Revocation in Mobile IPv4 (Proposed Standard)
<draft-ietf-mobileip-reg-revok-07.txt>
Secretariat to send Protocol Action Announcement including RFC Editor's Note
DONE o RTCP attribute in SDP (Proposed Standard)
<draft-ietf-mmusic-sdp4nat-04.txt>
Secretariat to send Protocol Action Announcement including RFC Editor's Note
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Securing X.400 Content with S/MIME (Proposed Standard)
<draft-ietf-smime-x400wrap-06.txt>
Token: Housley, Russ
- Transporting S/MIME Objects in X.400 (Proposed Standard)
<draft-ietf-smime-x400transport-07.txt>
o Definitions of Managed Objects for the Ethernet-like Interface
Types (Proposed Standard)
<draft-ietf-hubmib-etherif-mib-v3-03.txt>
Token: Wijnen, Bert
Note: Requested to go on IESG agenda on June 12th.
Responsible: bwijnen/iesg
- Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs) (Proposed Standard)
<draft-ietf-hubmib-mau-mib-v3-04.txt>
- Definition of Managed Objects for the Ethernet WAN Interface
Sublayer (Proposed Standard)
<draft-ietf-hubmib-wis-mib-07.txt>
- Applicability Statement for Reclassification of RFC 1643 to
Historic Status (Informational)
<draft-ietf-hubmib-1643-to-historic-01.txt>
o Multi Protocol Label Switching Label Distribution Protocol
Query Message Description (Proposed Standard)
<draft-ietf-mpls-lsp-query-06.txt>
Token: Zinin, Alex
o The Secure Real-time Transport Protocol (Proposed Standard)
<draft-ietf-avt-srtp-08.txt>
Token: Mankin, Allison
Note: Ready for IESG review - last call comments found a few
concerns with the treatment of padding and index and these
were corrected in a new rev.
o An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing (Proposed Standard)
<draft-ietf-sip-symmetric-response-00.txt>
Token: Mankin, Allison
o Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework (BCP)
<draft-ietf-snmpv3-coex-v2-04.txt>
Token: Bush, Randy
o PacketCable Security Ticket Control Sub-option for the
CableLabs Client Configuration Option (Proposed Standard)
<draft-ietf-dhc-pktc-kerb-tckt-02.txt>
Token: Narten, Thomas
Note: 2003-04-22: sent small set of comments to list, but
started IETF LC.
o Remote Network Monitoring MIB Protocol Identifier Reference
(Draft Standard)
<rfc2895.txt>
Token: Wijnen, Bert
Note: On IESG agenda for June 12th. Responsible: bert/iesg
2.1.2 Returning Item
NONE
2.2 Individual Submissions
2.2.1 New Item
o Generating One-Time Passwords with SHA-256, SHA-384, and
SHA-512 (Proposed Standard)
<draft-nesser-otp-sha-256-384-512-02.txt>
Token: Housley, Russ
2.2.2 Returning Item
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Token: Freed, Ned
Note: Writeup submitted; asked to have on IESG agenda
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o OSPF Refresh and Flooding Reduction in Stable Topologies
(Informational)
<draft-pillay-esnault-ospf-flooding-05.txt>
Token: Fenner, Bill
o Introduction to the Remote Monitoring (RMON) Family of MIB
Modules (Informational)
<draft-ietf-rmonmib-framework-05.txt>
Token: Wijnen, Bert
Note: Now on IESG agenda for June 12th. Responsible: Bert/IESG
o Goals for IPv6 Site-Multihoming Architectures (Informational)
<draft-ietf-multi6-multihoming-requirements-06.txt>
Token: Bush, Randy
o Transition Scenarios for 3GPP Networks (Informational)
<draft-ietf-v6ops-3gpp-cases-03.txt>
Token: Bush, Randy
o Guidelines for Extending the Extensible Provisioning Protocol
(Informational)
<draft-ietf-provreg-epp-ext-03.txt>
Token: Hardie, Ted
o Border Gateway Multicast Protocol (BGMP): Protocol
Specification (Informational)
<draft-ietf-bgmp-spec-05.txt>
Token: Zinin, Alex
3.1.2 Returning Item
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-04.txt>
Token: Peterson, Jon
Note: Roadmap document explaining relation of various
extensions of SDP such as offer-answer and fid to the SDPng
work.
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o The QCP File Format and Associated Media Types (Informational)
<draft-gellens-qcp-01.txt>
Token: Mankin, Allison
Note: This documents a storage format for QCELP audio - it is
time-sensitive to 3GPP2, which needs it for the streaming
applications of the EVRC and SMV vocoders. It was discussed by
the AVT Working Group, which published its own storage format
for data from those vocoders, but agreed this one, with a
distinct name, was equally publishable.
3.2.2 Returning Item
NONE
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o Backtrace Messages for Label Switched Paths (Informational)
<draft-kishan-lsp-btrace-04.txt>
Token: Zinin, Alex
3.3.2 Returning Item
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-10.txt>
Token: Mankin, Allison
Note: This was on the agenda before and I held it because of
concerns over its use of IETF protocols - I want to clear it
and have it approved with an IESG note, having completed
review.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Layer 2 Virtual Private Networks
Token: Thomas
o Path Maximum Transmission Unit Discovery
Token: Allison
o Layer 3 Virtual Private Networks
Token: Thomas
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o review the mechanism for call-in.
Proposal: adjust system so that call
participants notify secretary of changes needed (different
number, not able to attend), but otherwise assume
steady state.
-Ted
INTERNET ENGINEERING STEERING GROUP (IESG)
May 29, 2003
Reported by: Dinara Suleymanova, IETF Secretariat
ATTENDEES
---------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Marcia Beaulieu / IETF Secretariat
Steve Bellovin / AT&T Labs
Randy Bush / IIJ
Michelle Cotton / ICANN
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Jon Peterson / NeuStar, Inc.
Dinara Suleymanova / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
---------
Jacqueline Hargest / IETF Secretariat
Thomas Narten / IBM
Erik Nordmark / Sun
Joyce K. Reynolds / ISI (RFC Editor)
Minutes
--------
1. The minutes of the May 15, 2003 teleconference were approved.
The Secretariat to place in public archives.
2. Review Action Items
DONE TASKS:
o Secretariat to send ldup WG Action/Re-charter announcement to IAB, IESG, WG Chairs.
If nothing happens, in one week Ted will ask Secretariat to announce.
o After netconf WG Chairs are approved, Bert will ask Secretariat to send WG Action
to ietf-announce, cc: WG Chairs.
o Secretariat to send mmusic charter (WG Re-charter) to ietf-announce and new-work.
o Secretariat to send IESG a list of groups with whom we need to avoid meeting conflicts
when scheduling IETF conferences.
o Alex to send RFC Editor Note for draft-ietf-ppvpn-framework-08.txt addressing
Bert's and Ted's concerns.
o Secretariat to include IESG note in announcement for draft-ogura-ipv6-mapos-02.txt
o Secretariat to include new RFC Editor Note in announcement for
draft-murchison-sieve-subaddress-06.txt
o Secretariat to send internal Working Group Review message for simple WG
o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to Secretariat to send
on behalf of IESG.
o Alex will notify Secretariat once ok to announce draft-ietf-ipo-framework-04.txt
(removed)
OUTSTANDING TASKS:
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking architectural
questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex to send proposal and justification for interim document review.
IP o Ted to write straw working group procedures for handling consensus-blocked decisions
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the current
info/proposed/etc.
NEW TASKS:
o Harald Alvestrand to talk to RFC Editor about independent submissions.
o Secretariat to include the following statement (line) before the draft approval
announcement that is part of a ballot.
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB on PPVPN issue.
Alex to summarize the results as a proposed IESG consensus regarding the PPVPN issue
to be given to the PPVPN working group.
o IESG to review IANA matrix data.
2. Protocol Actions
2.1. WG Submissions
2.1.1. New Item
o RTCP attribute in SDP (Proposed Standard)
<draft-ietf-mmusic-sdp4nat-04.txt>
Token: Peterson, Jon
Approved pending RFC Editor's Note to be prepared by
Jon Peterson with authors' permission.
Secretariat to send Protocol Action Announcement including RFC Editor's Note.
o Registration Revocation in Mobile IPv4 (Proposed Standard)
<draft-ietf-mobileip-reg-revok-07.txt>
Token: Narten, Thomas
Approved pending RFC Editor's Note to be prepared by Steve Bellovin.
Secretariat to send Protocol Action Announcement including RFC Editor's Note.
o Textual Conventions for IPv6 Flow Label (Proposed Standard)
<draft-ietf-ops-ipv6-flowlabel-01.txt>
Token: Bush, Randy
Approved.
Secretariat to send Protocol Action Announcement.
2.1.2. Returning Item
NONE
2.2. Individual Submissions
2.2.1. New Item
o Printer MIB v2 (Proposed Standard)
<draft-ietf-printmib-mib-info-15.txt>
Token: Freed, Ned
Approved.
Secretariat to send Protocol Action Announcement.
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Token: Freed, Ned
Deferred by Harald Alvestrand, Allison Mankin, Jon Peterson.
Secretariat to put on the agenda for the next telechat on June 12, 2003.
o Delegation of E.F.F.3.IP6.ARPA (BCP)
<draft-ymbk-6bone-arpa-delegation-01.txt>
Token: Narten, Thomas
Approved.
Secretariat to send Protocol Action Announcement.
2.2.2. Returning Item
o Collective Attributes in LDAP (Proposed Standard)
<draft-zeilenga-ldap-collective-08.txt>
Token: Hardie, Ted
Under discussion by Steve Bellovin and Russ Housley.
3. Document Actions
3.1. WG Submissions
3.1.1. New Item
o IS-IS Cryptographic Authentication (Informational)
<draft-ietf-isis-hmac-04.txt>
Token: Zinin, Alex
Note: Responsible: Author
Approved.
Secretariat to send Document Action Announcement.
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-20.txt>
Token: Zinin, Alex
Approved pending RFC Editor's Note to be prepared by Alex Zinin.
Secretariat to send Document Action Announcement including RFC Editor's Note.
3.1.2. Returning Item
NONE
3.2. Indiviual Submissions Via AD
3.2.1. New Item
o Printer Finishing MIB (Informational)
<draft-ietf-printmib-finishing-16.txt>
Token: Freed, Ned
Note: Four week last call requested
Approved pending RFC Editor's Note to be prepared by Ned Freed.
Secretariat to send Document Action Announcement including RFC Editor's Note.
o IANA Charset MIB (Informational)
<draft-mcdonald-iana-charset-mib-02.txt>
Token: Freed, Ned
Note: Four week last call requested
Under discussion by Ted Hardie (for Michelle Cotton).
Secretariat to put on the agenda for the next telechat on June 12, 2003,
if not approved prior to that date.
3.2.2. Returning Item
o RADIUS Support For Extensible Authentication Protocol (EAP) (Informational)
<draft-aboba-radius-rfc2869bis-22.txt>
Token: Bush, Randy
Approved.
Secretariat to send Document Action Announcement.
Randy Bush to prepare a note for the minutes regarding why this document
is not in the Standards Track.
NOTE: RFCs 1321 and 2104 define a cryptographic algorithms. We have agreed that
it is okay to reference such documents. So, only the 1st and 3rd bullets
seem relevant.
The document draft-aboba-radius-rfc2869bis-22.txt is informational
as opposed to standards track because
o a standards track document may not make normative reference
to a document at a 'lesser' status
o draft-aboba-radius-rfc2869bis-22.txt has normative references
to rfcs 1321 and 2104, both of which are informational
o it also makes inescapable normative reference to
draft-chiba-radius-dynamic-authorization-20.txt, which will
be informational.
3.3. Indiviual Submissions Via RFC Editor
3.3.1. New Item
o Developing High Quality SNMP Agents (Informational)
<draft-aromanov-snmp-hiqa-04.txt>
Token: Wijnen, Bert
Note: On IESG agenda for 29 May
The document is not in conflict with IETF work. Bert Wijnen to prepare
a replacement message for Secretariat to send to RFC Editor.
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1. WG Creation
4.1.1. Proposed for IETF Review
NONE
4.1.2. Proposed for Approval
NONE
4.2. WG Rechartering
4.2.1. Under evaluation for IETF Review
o Next Steps in Signaling
Token: Mankin, Allison
Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat.
Secretariat to send a WG Review Announcement with copy to new-work@ietf.org.
o SIP for Instant Messaging and Presence Leveraging Extensions
Token: Hardie, Ted
SIP for Instant Messaging and Presence Leveraging Extensions (simple)
Approved.
Secretariat to send a WG Action: RECHARTER Announcement.
4.2.2. Proposed for Approval
o IP Telephony
Token: Peterson, Jon
Note: under discussion
IP Telephony (iptel)
Approved.
Secretariat to send a WG Action: RECHARTER Announcement.
5. Working Group News We Can Use
5.1. WG Closing
o Content Distribution Internetworking (cdi)
Token: Hardie, Ted
Approved.
Ted Hardie to send a note for the minutes documenting why the IESG
chose to close the WG while some documents are in RFC Editor's Queue. Ted to prepare
the WG Action: WG to Conclude Announcement for the Secretariat to send.
NOTE: Ted Hardie, Area Advisor for the CDI working group, asked that
the IESG agree to close this group. Historically, working groups
have not closed while they have documents active in the RFC editor's
queue. This group does have two informational documents still
in the that queue. Ted asked for a variance from that
precedent in this case, as the working group has ceased to serve
as a viable forum for discussion of these issues; any issues raised
by the RFC editor will need to be handled by the editors. Further,
the documents at issue are not protocol standards, as they
provide a set of scenarios and an abstract model. The IESG agreed
to the closure of the group, pending a note drafting the reasoning for
this being included in the working group closure notice. Ted agreed
to draft that note and send it to the Secretariat for the closure notice.
Separately, the IESG agreed that a more definite set of procedures
for working group closure is needed. Allison and Ted
volunteered to send draft text to Harald for inclusion in his
procedures draft.
6. IAB News We Can Use
7. Management Issues
o DNP - Harald Alvestrand
(skipped)
o Review criteria for independent submissions - Harald Alvestrand
(discussed)
o Does ballot text need a change - Bert Wijnen
(discussed)
o PPVPN Issue - added by Alex Zinin
(discussed)
o IANA Matrix Data - added by Michelle Cotton
(discussed)
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-smime-x400wrap - Securing X.400 Content
with S/MIME to Proposed Standard
--------
Last Call to expire on: November 20, 2001
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
ietf-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Securing X.400 Content with S/MIME to
Proposed Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Securing X.400 Content with S/MIME
<draft-ietf-smime-x400wrap-06.txt>
o Transporting S/MIME Objects in X.400
<draft-ietf-smime-x400transport-07.txt>
These documents are the product of the S/MIME Working Group. The IESG
contact persons are Russell Housley and Steven Bellovin.
Technical Summary
These documents describe the use of the S/MIME security mechanisms in
an X.400 messaging environment.
"Securing X.400 Content with S/MIME" describes the use of the
Cryptographic Message Syntax (CMS) to digital signature and encryption
services to X.400 content.
"Transporting S/MIME Objects in X.400" describes protocol options for
conveying CMS-protected objects associated with S/MIME version 3 over
an X.400 message transfer system.
Working Group Summary
The S/MIME Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeff Schiller and Russell Housley for the IESG.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-hubmib-etherif-mib-v3 -
Definitions of Managed Objects for the Ethernet-like Interface
Types to Proposed Standard
--------
Last Call to expire on: 2003-6-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, hubmib@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Managed Objects for the Ethernet-like
Interface Types to Proposed Standard
-------------
The IESG has approved the following documents. These documents
are the product of the Ethernet Interfaces and Hub MIB Working
Group. The IESG contact persons are Randy Bush and Bert Wijnen
o Definitions of Managed Objects for the Ethernet-like Interface Types
<draft-ietf-hubmib-etherif-mib-v3-03.txt>
Proposed Standard
o Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
<draft-ietf-hubmib-mau-mib-v3-04.txt>
Proposed Standard
o Definition of Managed Objects for the Ethernet WAN Interface Sublayer
<draft-ietf-hubmib-wis-mib-07.txt>
Proposed Standard
o Applicability Statement for Reclassification of RFC 1643 to Historic Status
<draft-ietf-hubmib-1643-to-historic-01.txt>
Informational
At the same time, the IESG approved the re-classification of RFC1643
to Historic Status.
Technical Summary
o Definitions of Managed Objects for the Ethernet-like Interface Types.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Ethernet-like
interfaces.
This memo obsoletes RFC 2665. It updates that specification by
including management information useful for the management of 10
Gigabit per second (Gb/s) Ethernet interfaces.
o Definitions of Managed Objects for IEEE 802.3 Medium Attachment
Units (MAUs)
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing IEEE 802.3 Medium
Attachment Units (MAUs).
This memo obsoletes RFC 2668. This memo extends that specification
by including management information useful for the management of 10
gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.
o Definition of Managed Objects for the Ethernet WAN Interface Sublayer
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines objects for managing the
Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).
The MIB module defined in this memo is an extension of the SONET/SDH
Interface MIB and is implemented in conjunction with it and with the
Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB,
the Interfaces Group MIB, and the Inverted Stack Table MIB.
o Applicability Statement for Reclassification of RFC 1643 to Historic
Status
This memo recommends that RFC 1643 be reclassified as an Historic
document and provides the supporting motivation for that
recommendation.
Working Group Summary
There is Working Group Consensus on the above documents for Proposed
Standard and for reclassification of RFC1643 to Historic Status.
Protocol Quality
These documents have been reviewed for the IESG by Bert Wijnen.
RFC-Editor note:
In document draft-ietf-hubmib-mau-mib-v3-04.txt, pls remove an
extraneous "IANA. " on page 25.
CURRENT TEXT:
DESCRIPTION "This object identifies the MAU type. Values for
standard IEEE 802.3 MAU types are defined above.
IANA. If the MAU type is unknown, the object identifier
SHOULD BE:
DESCRIPTION "This object identifies the MAU type. Values for
standard IEEE 802.3 MAU types are defined above.
If the MAU type is unknown, the object identifier
Bert
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-mpls-lsp-query - Multi Protocol Label
Switching Label Distribution Protocol Query Message
Description to Proposed Standard
--------
Last Call to expire on: 2003-3-25
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mpls@uu.net
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Multi Protocol Label Switching Label
Distribution Protocol Query Message Description to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Multi Protocol Label
Switching Label Distribution Protocol Query Message Description'
<draft-ietf-mpls-lsp-query-06.txt> as a Proposed Standard. This
document is the product of the Multiprotocol Label Switching Working
Group. The IESG contact persons are Alex Zinin and Bert Wijnen.
Technical Summary
This document describes the encoding and procedures for three new
Label Distribution Protocol (LDP) messages: Query Message, Query-
Reply Message and Partial Query-Reply Message (the last one is almost
identical to the Query-Reply message; therefore all references to the
Query-Reply messages imply the Partial Query-Reply messages as well,
unless otherwise specified). A Lable Edge Router (LER) sends a Query
message when it needs to find out information about a Label Switched
Path (LSP). The Query message is sent for an established LSP. The
Query message can be used for LDP LSPs as well as for Constraint-
Based Label Switched Paths (CR-LSPs). The queried data is encoded
into the Query-Reply messages.
Working Group Summary
The document has been reviewed by the WG participants. The WG
supported advancement of the document.
Protocol Quality
The specification has been reviewed for the IESG by Scott Bradner
and Alex Zinin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-avt-srtp - The Secure Real-time
Transport Protocol to Proposed Standard
--------
Last Call to expire on: 2003-5-22
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Secure Real-time Transport Protocol to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The Secure Real-time
Transport Protocol' <draft-ietf-avt-srtp-08.txt> as a Proposed
Standard. This document is the product of the Audio/Video Transport
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
This specification defines a profile for the Real-time Transport Protocol
(RTP) and Real-time Transport Control Protocol (RTCP) called the Secure
Real-time Transport Protocol (SRTP).
The security goals for SRTP are to ensure:
* the confidentiality of the RTP and RTCP payloads, and
* the integrity of the entire RTP and RTCP packets, together with
protection against replayed packets.
These security services are optional and independent from each
other, except that SRTCP integrity protection is mandatory
(malicious or erroneous alteration of RTCP messages could disrupt
the processing of the RTP stream).
Other, functional, goals for the protocol are:
* a framework that permits upgrading with new cryptographic
transforms,
* low bandwidth cost, i.e., a framework preserving RTP header
compression efficiency,
The provision of integrity is strongly recommended for most applications
of SRTP. The mandatory to implement transform for this profile is AES
counter mode, and there are risks associated with not using cryptographic
integrity with it (see Section 9.5).
Working Group Summary
The initial drafts had a default in which integrity services were not
the norm and in which SRTCP did not have mandatory integrity protection.
There was a lengthy security review to ensure that the authentication tag
is recommended to most RTP recommendations.
Protocol Quality
The specification was reviewed for the IESG by Eric Rescorla and Allison
Mankin. Implementations that tested the specification were discussed by
the working group.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sip-symmetric-response - An Extension
to the Session Initiation Protocol (SIP) for Symmetric Response
Routing to Proposed Standard
--------
Last Call to expire on: 2002-12-9
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing'
<draft-ietf-sip-symmetric-response-00.txt> as a Proposed Standard.
This document is the product of the Session Initiation Protocol
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
The Session Initiation Protocol (SIP) operates over UDP and TCP. When
used with UDP, responses to requests are returned to the source
address the request came from, and to the port written into the
topmost Via header field value of the request. This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT). This extension defines a new
parameter for the Via header field, called "rport", that allows a
client to request that the server send the response back to the
source IP address and port where the request came from.
Working Group Summary
The Working Group supported the advancement of this document.
There were reviews by working group members.
Protocol Quality
The document includes an analysis of the work in the perspective
of the IAB's UNSAF Considerations. The review for the IESG was
carried out by Allison Mankin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-snmpv3-coex-v2 - Coexistence between
Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework to BCP
--------
Last Call to expire on: 2003-6-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ X ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ R ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, snmpv3@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Coexistence between Version 1, Version 2,
and Version 3 of the Internet-standard Network Management
Framework to BCP
-------------
The IESG has approved the Internet-Draft 'Coexistence between
Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework' <draft-ietf-snmpv3-coex-v2-04.txt> as
a BCP. This document is the product of the SNMP Version 3 Working
Group. The IESG contact people are Randy Bush and Bert Wijnen
Technical Summary
This document describes coexistence between version 3 of the
Internet-standard Network Management Framework, SNMPv3, version 2
of the Internet-standard Network Management Framework SNMPv2, and
the original Internet-standard Network Management Framework
SNMPv1. It also describes how to convert MIB modules from SMIv1
format to SMIv2 format. This document obsoletes RFC 2576.
Working Group Summary
There was WG consensus to publish this document as BCP.
Protocol Quality
The document has been reviewed for te IESG by Bert Wijnen and
Randy Bush
RFC-Editor note:
On page 39, pls make the following change:
OLD:
Changed the name of 'snmpCommunityGroup' to a name
conflict with the SNMPv2-MIB.
NEW:
Changed the name of 'snmpCommunityGroup' to
snmpCommunityTableGroup to avoid a name conflict
with the SNMPv2-MIB.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dhc-pktc-kerb-tckt - Security Ticket
Control Sub-option for the CableLabs Client Configuration
Option to Proposed Standard
--------
Last Call to expire on: 2003-5-6
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, dhcwg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Security Ticket Control Sub-option for the
CableLabs Client Configuration Option to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Security Ticket Control
Sub-option for the CableLabs Client Configuration Option'
<draft-ietf-dhc-pktc-kerb-tckt-01.txt> as a Proposed Standard. This
document is the product of the Dynamic Host Configuration Working
Group. The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
This document defines a new sub-option for the CableLabs Client
Configuration (CCC) Option. This new sub-option will be used to
direct CableLabs Client Devices (CCDs) to invalidate locally
persisted security tickets.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The specification has been reviewed for the IESG by Thomas Narten.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Ballot: Remote Network Monitoring MIB Protocol Identifier
Reference to Draft Standard
--------
Last Call to expire on: 2003-6-4
Please return the full line with the vote.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (10) Yes or No-Objection votes needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@iab.org>
Cc: rmonmib@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Remote Network Monitoring MIB Protocol Identifier
Reference to Draft Standard
-------------
The IESG has approved RFC2895, 'Remote Network Monitoring MIB
Protocol Identifier Reference' to advance to Draft Standard. This
document is the product of the Remote Network Monitoring
Working Group. The IESG contact persons are Bert Wijnen
and Randy Bush
Technical Summary
This memo defines a notation describing protocol layers in a protocol
encapsulation, specifically for use in encoding INDEX values for the
protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring
Management Information Base) (RFC2021). The definitions for the
standard protocol directory base layer identifiers are also included.
The first version of the RMON Protocol Identifiers Document (RFC2074)
has been split into a standards-track Reference portion (this
document), and an Informational document. The RMON Protocol
Identifier Macros document (RFC2896) now contains the non-normative
portion of that specification.
This document obsoletes RFC 2074.
Working Group Summary
The WG has consensus to advance this document to Draft Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
The implemenation report is at
http://www.ietf.org/IESG/Implementations/RFC2895-Implementation.txt
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-nesser-otp-sha-256-384-512 - AES Companion
Hash Definitions (SHA256, SHA384, SHA512) for OTP to Proposed
Standard
--------
Last Call to expire on: 2003-1-30
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: AES Companion Hash Definitions (SHA256,
SHA384, SHA512) for OTP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generating One-Time
Passwords with SHA-256, SHA-384, and SHA-512' <draft-nesser-otp-
sha-256-384-512-02.txt> as a Proposed Standard. The IESG contact
persons are Russell Housley and Steven Bellovin.
Technical Summary
This document describes the use of the new SHA-256, SHA-384 and
SHA-512 hash alogrithms, for use with the One Time Password (OTP)
system, as defined by RFC 2289.
Working Group Summary
This was not a the product of any IETF working group. No issues were
raised during the IETF Last Call.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-klyne-msghdr-registry - Registration procedures
for message header fields to BCP
--------
Last Call to expire on: 2002-12-4
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
"Defered" by Harald Alvestrand, Allison Mankin, Jon Peterson
COMMENTS:
========
Ted Hardie:
Two notes:
In section 3.2.1 "An header" should be "A header".
In section 3.4, the draft says:
Publication in an IESG-approved RFC or other form of Open Standard
document (per RFC 2026 [1], section 7) is sufficient grounds for
publication in the permanent registry.
Note that the text IESG-approved suggests a different test from
the one set out above--which would allow Experimental and
Informational RFCs which the IESG may choose to advise the RFC editor
on, but does not exactly "approve". To avoid the swamp, I'd suggest
the text here
be shifted to "published RFC" to be in accord with the text above.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Registration procedures for message header
fields to BCP
-------------
The IESG has approved the Internet-Draft 'Registration procedures for
message header fields' <draft-klyne-msghdr-registry-06.txt> as a BCP.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
This specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications.
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and widely-
used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
Working Group Summary
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
Protocol Quality
Ned Freed reviewed the document for the iESG.
RFC Editor note
The IPR boilerplate is missing from this document and needs to be added.
To: RFC Editor <rfc-editor@isi.edu>
Cc: iesg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Developing High Quality SNMP Agents
to Informational
The IESG has no problem with the publication of 'Developing High Quality
SNMP Agents' <draft-aromanov-snmp-hiqa-04> as an Informational RFC.
RFC-Editor Note:
The IESG would like to see an IESG note added on the front-page of
the document.
IESG Note
This document represents the opinions of the author. It has not
been widely reviewed in the IETF.
Publication of this document does not mean endorsement by the IESG
or the IETF (or SNMP) community.
And also FIX some problems:
- The suggestion on page 6, bullet (b) is questionable:
(b) an agent must return `inconsistentValue' if the complexity of
the SetRequest-PDU exceeds the agent's ability to perform consistency
checking: e.g. if the PDU contains any other variable. If an agent
Many people will think that a 'genErr' is more appropriate. The author
may have a defendable position. If so, it would be good to add that.
- Section 3.2 is believed to be conflicting with the RFC 3416 specification,
sect 4.2.5, specifically the text on page 22 towards the end of that
section 4.2.5.
Sect 3.2 of the internet-draft says:
Since the `commitFailed' error code does not convey any meaningful
information to NMS, an SNMP agent may substitute some meaningful
error code (e.g. `resourceNotAvailable') for such cases. An SNMP
agent should not ever find itself in the situation where it will
return `undoFailed'.
And so that recommendation should be taken out.
If the intention is to indicate that an SNMP agent should try its
utmost to first do as much checking as possible (rfc3416 says so too)
and if it concludes that committing the SET operation would fail,
that it then sends a 'resourceNotAvailable', then that is fine.
But that is not what it says.
And RFC3416 clearly states that IF a commit fails, then you MUST
return a commitFailed. And if an undo fails, then you MUST return
an undoFailed.
And that we have suggestions for changes as follows:
- Change the title from
Developing High Quality SNMP Agents
into something aka:
Considerations for SNMP agent developers
Justification:
- the doc itself is (in my view) not high quality itself.
- the doc discussus only a small part of the whole problem
space and the many tricky things in SNMP agent development
- one needs to be an SNMP expert to understand what is
being described.
- Change the "recommendations", i.e.
- The author often speaks like "It is recommended", where
it seems to make more sense to say "I recommend"
- References need to be made to the new SNMP STD documents (that
is in the 341x range instead of 257x range). We understand that
those were not yet RFCs when the I-D was submitted to RFC-Editor.
- Instead of talking about an "index string", we strongly recommend
to talk about an "index sequence". Otherwise people too easily
think about an ascii representation of OID components in the
dotted notation, and the author means an array (or sequence) of
unsigned integers that represent OID components (or sub-IDs).
- Same for "string of Object Identifiers"
- In many places, when the author talks about "OID" he really means
an OID component (i.e. one unsigned integer instead of a
sequence of unsigned integers).
- Bullet 3 on page 4 and 5. Strongly recommend to move the 1st
sentence of the last para (i.e.
This OID range checking must start at the end of index string and
progress towards its beginning.
to the beginning of bullet 3. Otherwise it is impossible to
understand what the steps mean.
- We suggest that the author explains what he means by non-implied
and explains that it is about INDEX objects that have the keyword
IMPLIED associated with it. SO it would then also be better to
us non-IMPLIED instead of "non-implied".
Layer 2 Virtual Private Networks (l2vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-09
Current Status: Proposed Working Group
Chair(s):
<under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: l2vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.html
Description of Working Group:
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).
The WG is responsible for standardization of the following solutions:
1. Virtual Private LAN Service--L2 service that emulates LAN
across an IP and an MPLS-enabled IP network, allowing standard
Ethernet devices communicate with each other as if they were
connected to a common LAN segment.
2. Virtual Private Wire Service--L2 service that provides L2
point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
point-to-point Ethernet) across an IP and an MPLS-enabled IP network.
3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
IP network, allowing standard IP devices to communicate with each
other as if they were connected to a common LAN segment or a point-
to-point circuit.
The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)
As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs.
The group will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
The WG will work on the following items. Adding new work items
will require rechartering.
1. Discovery of PEs participating in L2 service, and
topology of required connectivity
2. Signaling of l2vpn service parameters
3. Solution documents (providing the framework for a specific
solution, should include info on how discovery, signaling,
and encaps work together, include security, AS as a separate
document)
4. MIBs
5. L2VPN-specific OAM extensions--extensions to existing OAM
solutions for VPLS and VPWS.
6. Interworking of IP devices connected to an IP-only L2 VPN using
dissimilar attachment circuits. This topic will be explored only
after the basic L2VPN services (VPWS, VPLS, and IP L2VPN) are
defined.
Where necessary, the WG will coordinate its activities with IEEE 802.1
Milestones (optimistic):
JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC
JUL 2003 Submit L2 framework to IESG for publication as Informational RFC
JUL 2003 Identify VPLS and VPWS solutions for the WG
AUG 2003 Submit an I-D describing MIB for VPLS
AUG 2003 Submit an I-D describing MIB for VPWS
AUG 2003 Submit an I-D on OAM for VPLS
AUG 2003 Submit an I-D on OAM for VPWS
DEC 2003 Submit VPLS solution documents to IESG
DEC 2003 Submit VPWS solution documents to IESG
JAN 2004 Submit IP-only L2VPN solution documents to IESG
FEB 2004 Submit MIB for VPLS to IESG
FEB 2004 Submit MIB for VPWS to IESG
MAR 2004 Submit OAM for VPLS to IESG
MAR 2004 Submit OAM for VPWS to IESG
Path Maximum Transmission Unit Discovery (pmutd)
------------------------------------------------
Charter
Last Modified: 2003-06-06
Current Status: Proposed Working Group
Chair(s):
Matt Mathis <mathis@psc.edu>
TBD
Transport Area Directors(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing List (temporary):
General Discussion: mtu@psc.edu
Subscribe: majordomo@psc.edu with "subscribe mtu" in the body
Archive: http://www.psc.edu/~mathis/MTU/mbox.txt
(This is to be moved to the IETF as soon as chartered).
Description of Working Group:
The goal of the PMTUD working group is to specify a robust method for
determining the IP Maximum Transmission Unit supported over an
end-to-end path. This new method is expected to update most uses of
RFC1191 and RFC1981, the current standards track protocols for this
purpose. Various weakness in the current methods are documented in
RFC2923, and have proven to be a chronic impediment to the deployment
of new technologies that alter the path MTU, such as tunnels and new
types of link layers.
The proposed new method does not rely on ICMP or other messages from
the network. It finds the proper MTU by starting a connection using
relatively small packets (e.g. TCP segments) and searching upwards by
probing with progressively larger test packets (containing application
data). If a probe packet is successfully delivered, then the path MTU
is raised. The isolated loss of a probe packet (with or without an
ICMP can't fragment message) is treated as an indication of a MTU
limit, and not a congestion indicator.
The working group will specify the method for use in TCP, SCTP, and
will outline what is necessary to support the method in transports
such as DCCP. It will particularly describe the precise conditions
under which lost packets are not treated as congestion indications.
The work will pay particular attention to details that affect
robustness and security.
Path MTU discovery has the potential to interact with many other parts
of the Internet, including all link, transport, encapsulation and
tunnel protocols. Thereforethis working group will particularly
encourage input from a wide cross section of the IETF to help to
maximize the robustness of path MTU discovery in the presence of
pathological behaviors from other components.
Input draft:
Packetization Layer Path MTU Discovery
draft-mathis-plpmtud-00.txt
Goals and Milestones:
Jul 03 Reorganized Internet-Draft. Solicit implementation and field experience.
Dec 03 Update Internet-Draft incorporating implementers experience,
actively solicit input from stakeholders - all communities that might
be affected by changing PMTUD.
Feb 04 Submit completed Internet-draft and a PMTUD MIB draft for
Proposed Standard.
Layer 3 Virtual Private Networks (l3vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-09
Current Status: Proposed Working Group
Chair(s):
<under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: l3vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/maillist.html
Description of Working Group:
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
Layer-3 (routed) Virtual Private Networks (L3VPNs).
The WG is responsible for standardization of the following solutions:
1. BGP/MPLS IP VPNs (based on RFC 2547)
2. IP VPNs using Virtual Routers
3. CE-based VPNs using IPSEC
The following VPN deployment scenarios will be considered by the WG:
1. Internet-wide: VPN sites attached to arbitratry points in
the Internet
2. Single SP/single AS: VPN sites attached to the network of a
single provider within the scope of a single AS
3. Single SP/multiple AS'es: VPN sites attached to the network
of a single provider consisting of multiple AS'es
4. Cooperating SPs: VPN sites attached to networks of different
providers that cooperate with each other to provide VPN service
As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):
1. Requirements and framework for Layer 3 VPNs
2. Solution documents for each approach listed above (including
applicability statements)
3. MIB definitions for each approach
4. Security mechanisms for each approach
As a general rule, the WG will not create new protocols, but will provide
functional requirements for extensions of the existing protocols that will
be discussed in the protocol-specific WGs. The group will review proposed
protocol extensions for L3VPNs before they are recommended to appropriate
protocol-specific WGs.
Multicast and QoS support are excluded from the charter at this time.
They may be considered for inclusion in an updated charter
at a later time. Future work items may also include OAM support.
WG Milestones (optimistic):
Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit Generic Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info
(completed)
Dec 2003 Submit VPN Security Analysis to IESG for publication as Info
(draft-fang-ppvpn-security-framework-00)
Dec 2003 Submit BGP/MPLS VPNs specification and AS to IESG for
publication as PS
(draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
Dec 2003 Submit CE-based specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-ce-based-03)
(draft-declercq-ppvpn-ce-based-sol-00)
(draft-declercq-ppvpn-ce-based-as-01)
Dec 2003 Submit Virtual Router specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Jan 2004 Submit VPN MIB Textual Conventions to IESG for publication as PS
(draft-ietf-ppvpn-tc-mib-02)
Jan 2004 Submit MPLS/BGP VPN MIB to IESG for publication as PS
(draft-ietf-ppvpn-mpls-vpn-mib-05)
Jan 2004 Submit VR MIB to IESG for publication as PS
(draft-ietf-ppvpn-vr-mib-04)
Jan 2004 Submit BGP as an Auto-Discovery Mechanism for publication as PS.
(draft-ietf-ppvpn-bgpvpn-auto-05.txt)
March 2004 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-ipsec-2547-03)
March 2004 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-gre-ip-2547-02)
March 2004 Submit specification of CE Route Authentication to IESG for publication as PS
(draft-ietf-ppvpn-l3vpn-auth-03)
March 2004 Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication.
(draft-rosen-vpns-ospf-bgp-mpls-06.txt)