[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FINAL: IESG Telechat Agenda and Package for April 17, 2003
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the April 17, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- April 3, 2003
o Review of Action Items
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.
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
RFC Editor. Auto-response to include the URL pointing to the
I-D Nits page.
o Secretariat to email Working Group Chairs a reminder after each
conference with pointer to I-D Nits. Secretariat to draft
reminder text and pass by IESG first.
o Ned to write an IESG note for draft-tegen-smqp (Informational)
o Steve Bellovin will write RFC for Automated Key Management
o Steve to write RFC re: TCP MD5 option
o Randy and Ned to finish ID on Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level
o Secretariat to send lemonade WG Action Announcement
DONE o Randy to send GROW new charter review message to Secretariat.
Secretariat to send to IAB, IESG and WG Chairs.
IP o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright
o Thomas will check with 3GPP2 about expediting RFC processing for
draft-koren-pppext-rfc2509bis-03.txt and
draft-ietf-avt-crtp-enhance. If ok, the IESG has already
approved that request.
2. Protocol Action
o LDAPv3: A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
Token: Hardie, Ted
Note: It is proposed that this be approved for Proposed Standard
with the following IESG note: This document contains useful and
timely updates to RFC 2798. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates
will cause this document or its successors to recycle at the
Proposed Standard level.
o Message Disposition Notification (Draft Standard)
<draft-vaudreuil-mdnbis-03.txt>
Token: Freed, Ned
Note: Responsible: freed
o Internet X.509 Public Key Infrastructure Permanent Identifier
(Proposed Standard)
<draft-ietf-pkix-pi-06.txt>
Token: Housley, Russ
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
Token: Wijnen, Bert
Note: IETF Last Call requested.
Responsible: Bert
o Use of the RSAES-OAEP Transport Algorithm in CMS (Proposed
Standard)
<draft-ietf-smime-cms-rsaes-oaep-07.txt>
Token: Bellovin, Steve
o Security Considerations for SIGTRAN Protocols (Proposed Standard)
<draft-ietf-sigtran-security-02.txt>
o The AES Cipher Algorithms and Their Use With IPsec (Proposed
Standard)
<draft-ietf-ipsec-ciph-aes-cbc-04.txt>
Token: Housley, Russ
Token: Peterson, Jon
o Use of the AES Encryption Algorithm in CMS (Proposed Standard)
<draft-ietf-smime-aes-alg-06.txt>
Token: Bellovin, Steve
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile
Nodes and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt>
Token: Narten, Thomas
o IANA Considerations for RADIUS (Proposed Standard)
<draft-aboba-radius-iana-05.txt>
Token: Bush, Randy
Note: FOUR WEEK last call, please, as it is PS
o IPv6 Global Unicast Address Format (Informational)
<draft-ietf-ipv6-unicast-aggr-v2-02.txt>
Token: Narten, Thomas
Note: An IETF LC call is needed, as this reclassifies RFC 2374
historic.; last call expires 2003-04-08.
3. Working Group Submissions
o Framework Policy Information Base for Usage Feedback
(Informational)
<draft-ietf-rap-feedback-fr-pib-06.txt>
Token: Wijnen, Bert
Note: Responsible: AD (Bert)
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
Token: Housley, Russ
Note: Responsible: Russ Housley
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
Token: Housley, Russ
4. Individual Submissions
o IEEE 802.1X RADIUS Usage Guidelines (Informational)
<draft-congdon-radius-8021x-26.txt>
Token: Bush, Randy
o Dynamic Authorization Extensions to Remote Authentication Dial-In
User Service (RADIUS) (Informational)
<draft-chiba-radius-dynamic-authorization-12.txt>
Token: Bush, Randy
Note: -10 addresses last call comments
o A URN Namespace for the Web3D Consortium (Web3D) (Informational)
<draft-walsh-urn-web3d-00.txt>
Token: Hardie, Ted
Note: Responsible: Ted
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-15.txt>
Token: Zinin, Alex
o Handle System Overview (Informational)
<draft-sun-handle-system-10.txt>
Token: Hardie, Ted
Note: It is suggested that these go forward with the following
IESG Note attached (originally drafted by Patrik):
IESG NOTE:
The IETF and IRTF have discussed the Handle system in the realm
of URI-related work. The IESG wishes to point out that there
is no IETF consensus on the current Handle system nor on
where it fits in the IETF architecture. The IESG is of the view
that the Handle system would be able to, with very small changes,
fit into the IETF architecture as a URN namespace. These
documents, however, contain information on the Handle system
without these changes.
o Tracing Requirements for Generic Tunnels (None)
<draft-ietf-ccamp-tracereq-01.txt>
Token: Wijnen, Bert
Note: New revision Addresses comments.
Now on IESG agenda for April 17th
Responsible: Bert
o Handle System Protocol (ver 2.1) Specification (Informational)
<draft-sun-handle-system-protocol-04.txt>
Token: Hardie, Ted
Note: It is suggested that these go forward with the following
IESG Note attached (originally drafted by Patrik):
IESG NOTE:
The IETF and IRTF have discussed the Handle system in the realm
of URI-related work. The IESG wishes to point out that there
is no IETF consensus on the current Handle system nor on
where it fits in the IETF architecture. The IESG is of the view that
the Handle system would be able to, with very small changes,
fit into the IETF architecture as a URN namespace. These documents,
however, contain information on the Handle system without these
changes.
o Handle System Namespace and Service Definition (Informational)
<draft-sun-handle-system-def-07.txt>
Token: Hardie, Ted
Note: It is suggested that these go forward with the following
IESG Note attached (originally drafted by Patrik):
IESG NOTE:
The IETF and IRTF have discussed the Handle system in the realm
of URI-related work. The IESG wishes to point out that there
is no IETF consensus on the current Handle system nor on
where it fits in the IETF architecture. The IESG is of the view that
the Handle system would be able to, with very small changes,
fit into the IETF architecture as a URN namespace. These documents,
however, contain information on the Handle system without these
changes.
5. Individual via RFC Editor
o Internet X.509 Public Key Infrastructure Certificate Management
Protocols (Proposed Standard)
<draft-ietf-pkix-rfc2510bis-08.txt>
Token: Housley, Russ
o Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)(Proposed Standard)
<draft-ietf-pkix-rfc2511bis-06.txt>
Token: Housley, Russ
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
Token: Hardie, Ted
6. Proposed Working Groups
o Application Exchange (apex)
Token: Hardie, Ted
o Network Configuration (netconf)
Token: Bert
o Reliable Multicast Transport (rmt)
Token: Allison
7. Working Group News we can use
8. IAB News we can use
9. Management Issues
o Proposed resolution of the AD-shepherded info/experimental
o Confirmation of IETF appointment to ISOC BoT
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
April 3, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Daigle, Leslie / Verisign (IAB)
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Fuller, Barbara / IETF
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Housley, Russ / Vigil Security, LLC
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
Minutes
-------
1. The minutes of the March 6, 2003 teleconference were approved.
Secretariat to place in public archives.
2. The following action items were reported as DONE:
DONE o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return to next telechat with discussion points.
DONE o Thomas and Bill to follow up on
draft-ietf-ipngwg-rfc2292bis-09.txt, and notify Secretariat when
it is ready to be announced.
DONE o Alex, Leslie and Harald to discuss announcement text for
draft-zinin-ietf-jtc1-aggr-01.txt. Harald to send note to IAB
and Alex to send announcement text to Secretariat, who will then
announce.
DONE o Secretariat to install paragraph into charter and fix milestone
dates in Network File System Version 4 charter.
DONE o Secretariat to send RMT WG Review Message (removing any personal
notes) to IAB and Working Group Chairs. Secretariat to make sure
that any private notes are not publicly visible.
DONE o Randy will suggest slight word change to Problem Statement
milestones. Secretariat to wait for go-ahead from Harald before
announcing.
DONE o Harald to draft an announcement about Alex becoming Sub-IP AD.
3. Prior to the April 3, 2003 teleconference, the following
document was APPROVED:
o Generalized Multiprotocol Label Switching Extensions for SONET and
SDH Control to Proposed Standard (Proposed Standard)
<draft-ietf-ccamp-gmpls-sonet-sdh-08.tx>
Note: The announcement has been sent.
4. Protocol Actions APPROVED:
The IESG has approved the Internet-Draft 'Enhanced Compressed RTP
(CRTP) for Links with High Delay, Packet Loss and Reordering'
<draft-ietf-avt-crtp-enhance-07.txt> as a Proposed Standard.
Secretariat to announce.
The IESG has approved the Internet-Draft 'Definitions of Managed
Objects for the Optical Interface Type'
<draft-ietf-atommib-opticalmib-08.txt> as a Proposed Standard.
Secretariat to announce.
The IESG has approved the Internet-Draft 'Signalling of Modem-On-Hold
status in Layer 2 Tunneling Protocol (L2TP)'
<draft-ietf-l2tpext-v92-moh-05.txt> as a Proposed Standard.
Secretariat to announce.
The IESG has approved the Internet-Draft 'IP Header Compression Over
PPP' <draft-koren-pppext-rfc2509bis-03.txt> as a Proposed Standard.
Secretariat to announce.
5. Protocol Actions TENTATIVELY APPROVED:
o On the Use of SCTP with IPsec (Proposed Standard)
<draft-ietf-ipsec-sctp-04.txt>
Note: Thomas will remove his discuss once IANA confirms it
is ok with the revised considerations section. Secretariat
to announce.
o Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals (Draft Standard)
<draft-ietf-atommib-rfc2493bis-01.txt>
Note: Erik will send RFC Editor Note to Secretariat. Secretariat
to announce.
o Definitions of Managed Objects for the SONET/SDH Interface
Type (Draft Standard)
<draft-ietf-atommib-rfc2558bis-01.txt>
Note: Erik to send note to Secretariat. Secretariat to announce.
6. Document Actions APPROVED:
o 'A URN Namespace for MACE' (Informational)
<draft-hazelton-mace-urn-namespace-02.txt>
Note: Secretariat to announce.
o 'Counter with CBC-MAC (CCM)' (Informational)
<draft-housley-ccm-mode-02.txt>
Note: Secretariat to announce.
7. Document Action TENTATIVELY APPROVED:
The IESG has tentatively approved the Internet-Draft 'Security
Requirements for Keys used with the TCP MD5 Signature Option'
<draft-ietf-idr-md5-keys-00.txt> as an Informational RFC.
Note: Bill to write RFC Editor Note and send to Secretariat.
Secretariat to announce.
8. Working Group Actions APPROVED:
o Enhancements to Internet email to support diverse
service environments (lemonade)
Note: Secretariat to send WG Action Announcement.
o Global Routing Operations (grow)
Note: Randy to send new charter review message to Secretariat.
Secretariat to send to IAB, IESG and authors.
9. The following documents are still UNDER DISCUSSION:
o Internet Printing Protocol (IPP): Event Notifications and
Subscriptions (Proposed Standard)
<draft-ietf-ipp-not-spec-11.txt>
o Finding Remote Directory Agents and Service Agents in the Service
Location Protocol via DNS SRV (Proposed Standard)
<draft-zhao-slp-remote-da-discovery-04.txt>
o Multihoming issues in the Stream Control Transmission Protocol
(Informational)
<draft-coene-sctp-multihome-03.txt>
o Registration Revocation in Mobile IPv4 (Proposed Standard)
<draft-ietf-mobileip-reg-revok-05.txt>
o L2TP Active Discovery Relay for PPPoE (Proposed Standard)
<draft-dasilva-l2tp-relaysvc-06.txt>
o The application/smil and application/smil+xml Media Types
(Informational)
<draft-hoschka-smil-media-type-11.txt>
o Security Mechanisms for the Internet (Informational)
<draft-iab-secmech-02.txt>
o Multicast Router Discovery (Proposed Standard)
<draft-ietf-idmr-igmp-mrdisc-10.txt>
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-21.txt>
o Traffic Engineering Extensions to OSPF Version 2 (Proposed
Standard)
<draft-katz-yeung-ospf-traffic-09.txt>
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile
Nodes and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt>
o Requirements for IP Flow Information Export (Informational)
<draft-ietf-ipfix-reqs-09.txt>
o Base Encodings of Data (Request)
<draft-josefsson-base-encoding-04.txt>
o The application/smil and application/smil+xml Media Types
(Informational)
<draft-hoschka-smil-media-type-11.txt>
10. The IESG agreed to the following plan regarding the disposition
of former IESGers' DISCUSS ballots:
- all the shepherding ADs check the documents to see if the
problems have been fixed, and ask to put them on the agenda if
that's the case
- the documents that have been fixed go back on the agenda with
the old DISCUSS vote removed and the new AD recorded with a blank
vote
- if there are unfixed problems, another AD raises a DISCUSS to
hold it; we can negotiate with the shepherding AD on who should
hold it
- we don't approve any of these documents without having them on
the agenda of a telechat (if we need to make exceptions, say so!)
11. NEW Action Items:
o Ned to write an IESG note for draft-tegen-smqp (Informational).
o Steve to write RFC for Automated Key Management.
o Steve to write RFC for TCP MD5 option.
o Randy and Ned to finish I-D on 'Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level'.
o Secretariat to send lemonade WG Action Announcement.
o Randy to send GROW new charter review message to Secretariat.
Secretariat to send to IAB, IESG and WG Chairs.
o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright.
o Thomas will check with 3GPP2 about expediting RFC processing for
draft-koren-pppext-rfc2509bis-03.txt and
draft-ietf-avt-crtp-enhance. If ok, the IESG has already
approved this request.
12. Outstanding Action Items:
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.
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
RFC Editor. Auto-response to include the URL pointing to the
I-D Nits page.
o Secretariat to email Working Group Chairs a reminder after each
conference with pointer to I-D Nits. Secretariat to draft
reminder text and pass by IESG first.
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-zeilenga-ldap-user-schema - LDAPv3: A
Collection of User Schema to Proposed Standard
--------
It is proposed that this be approved for Proposed Standard with the
following IESG note:
This document contains useful and timely updates to RFC 2798. The IESG
expects that this document will be replaced or updated again once the
LDAP community has finished its work related to stringprep, and that
those updates will cause this document or its successors to recycle at
the Proposed Standard level.
Last Call to expire on: January 28, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (10) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve: Does this depend on stringprep for comparisons? Should it?
COMMENTS:
=========
Ted:
Steve,
Kurt has suggested a tweak to this; here is his note:
> Ted, regarding this recently added note to the tracker:
> It is proposed that this be approved for Proposed Standard with
> the following IESG note: This document contains useful and timely
> updates to RFC 2798. The IESG expects that this document will be
> replaced or updated again once the LDAP community has finished its
> work related to stringprep, and that those updates will cause this
> document or its successors to recycle at the Proposed Standard level.
>
> The primary focus of the I-D is to update RFC 1274 (Proposed Standard)
> and to adapt additional X.520(93) schema for use in LDAP (such as
> the matching rules needed by Policy WG draft). Superceding portions
> of RFC 2798 (Informational) became necessary as it tried to fill some
> of the gaps.
>
> I would suggest the IESG note focus more on "useful and timely
> updates" to RFC 1274 (and filling gaps between X.520(93) and LDAP).
>
> Kurt
Based on that, I think we might want to change the text to say
"This document contains useful and timely updates of RFC
1274 and RFC 2798, as well as harmonizing certain aspects
of X.520(93) and LDAP. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates will
cause this document or its successors to recycle at the Proposed
Standard level"
Would this text still be okay with you?
Russ:
Section 3.25. Should we change "secretary" to "secretary or
administrative assistant" in the description of the attribute? I am
not proposing to change the name of the attribute.
^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: LDAPv3: A Collection of User Schema to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAPv3: A Collection of User
Schema' <draft-zeilenga-ldap-user-schema-06.txt> as a Proposed
Standard. 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 Patrik Faltstrom
Technical Summary
This document provides a collection of user schema elements for use
with LDAP (Lightweight Directory Access Protocol) from both ITU-T
Recommendations for the X.500 Directory and COSINE and Internet X.500
pilot projects.
Working Group Summary
This document is not a product of a working group. It has been
discussed on the LDAPBIS working group mailing list. There was
consensus for publication of a document specifying this schema.
Protocol Quality
The specification was reviewed for the IESG by Patrik Faltstrom.
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-vaudreuil-mdnbis - Message Disposition
Notification to Draft Standard
--------
Last Call to expire on: 2002-12-23
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
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>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Message Disposition Notification to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'Message Disposition
Notification' <draft-vaudreuil-mdnbis-03.txt> as a Draft Standard,
obsoleting RFC2298.
This document 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 memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. This
content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting the privacy concerns that have often been
expressed when such functions have been discussed in the past.
Working Group Summary
This document was originally the product of the RECEIPT working group.
Review of the revised version was conducted largely in the context
of the VPIM working group.
Protocol Quality
Ned Freed reviewed the document for the IESG.
RFC Editor Note
The IPR boilerplate is missing from the draft and needs to be added
before publication.
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-pkix-pi - Internet X.509 Public Key
Infrastructure Permanent Identifier 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 [ ] [ ] [ X ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
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'.
DISCUSS:
========
Steve:
Permanent universally-unique names strike me as a singularly bad
idea in general, and even worse as specified here. A name can only
be guaranteed to be unique (even in theory) within the scope of a
single CA; there's no way to make any assumptions if different CAs
are involved. Sure, they're supposed to be URIs, but that's not
enforceable except by referring to the parent certificate, and if
you're going to do that why bother with a URI at all? The notion
of using permanent identifiers in ACLs is even worse.
Beyond that, the comparison rules for UTF8 strings look wrong --
I'm glad there's a matching rule specified, but from the little I
understand about such things there will be a lot of complaints
about the lack of more CJK-friendly matching rules.
Harald:
The matchingRule is an OID. When the OID is missing the
following matching rule SHALL be used:
The Alphanumeric Identifier Match rule compares for
equality a presented value with an attribute value of type
UTF8String or IA5String, which is interpreted as a series
of alphanumeric characters. The rules for matching are that
a working comparison value is constructed from each of the
two values by including only the digits and alphabetic
characters appearing in the value; and then the two
comparison values are compared using CaseIgnoreMatch. This
rule is intended for use only with identifiers in variants
of the Latin, Greek, and Cyrillic scripts.
1) as defined, this cannot be implemented interoperably, because the
definition of "alphabetic character" is not given.
If the document is amended to refer to (for instance) the Unicode
Alphabetic property (section 4.10 of the Unicode 3.0 standard), I'll
remove this DISCUSS. You REALLY, REALLY don't want to get into a
discussion about whether or not a HEBREW POINT RAFE or a GUJARATI SIGN
VISAGARA is an alphabetic character or not; let someone else do that.
(be careful. Even the restriction to Latin, Greek and Cyrillic isn't
enough for interoperability - what about GREEK NUMERAL SIGN or
COMBINING CYRILLIC TITLO? You REALLY want to use someone else's
definition.)
2) For greater general utility, I suggest that this document define an
OID for this matching rule. It can be "TBD by IANA", and I'm fine with
assuming it as a default - but leaving it unlabelled is Just Not Right.
Ted:
Discuss comments:
"An Assigner authority maybe a government, a government agency, a
corporation, or any other sort of organization. It MUST have a unique
identifier to distinguish it from any other such authority. In this
standard, that identifier MUST be an object identifier or be
representable as a URI"
"representable as a URI" is not particularly strong, and the rest of
the document's view of a "permanent URI" isn't a lot better. I *think*
what they mean here is that the Assigner Authority must have either an
IANA-assigned URN NID, or be sub-delegated space under such an
assignment. In other words, I think they are making a parallel between
the URN NID space and the OIDs assigned for ASN.1/enterprise numbers
assigned by IANA. If that is the case, this needs to be spelled out;
if that is not the case, and they really do mean that any URI should
be usable for this purpose, then they need a _lot_ more text on how.
It also strikes me that the mechanisms for using a Permanent
Identifier cross-CA don't handle some pretty likely issues. If an
attacker can read the Permanent Identifier for some entity out of its
certificate, the attacker can then create a CA and certificate that
purports to be about the same entity. Of course, no one should trust
that certificate just because it contains data supposedly also about
the same entity, but given that, it's not clear what the utility is
supposed to be to knowing that the two assertions are about the same
entity. If you're supposed to evaluate them independently, what is the
win?
COMMENTS:
=========
Leslie Daigle:
Hmmm, well, just to play devil's advocate for a second (and
because the alternative is that I have to back to playing
with powerpoint tables)...
Steven M. Bellovin wrote:
> In message <200304101701.NAA26528@ietf.org>, IESG Secretary writes:
>
>>Last Call to expire on: 2002-12-9
>>
>> Please return the full line with your position.
>>
>> Yes No-Objection Discuss * Abstain
>>
>>
>>Steve Bellovin [ ] [ ] [ X ] [ ]
>
>
> Permanent universally-unique names strike me as a singularly bad
> idea in general, and even worse as specified here. A name can only
> be guaranteed to be unique (even in theory) within the scope of a
> single CA; there's no way to make any assumptions if different CAs
> are involved. Sure, they're supposed to be URIs, but that's not
> enforceable except by referring to the parent certificate, and if
> you're going to do that why bother with a URI at all? The notion
> of using permanent identifiers in ACLs is even worse.
Is it any more wrong than using, say, an e-mail address? (Which
is unique at any given moment in time). Then, each certificate
is a binding of: a DN (which is more or less an "address" for
the cert, in some way), a public key, the PI-as-data (e-mail address)
and the CA's signature on that public key. You can't trust this
binding any more than you trust the CA that signed it.
So, you shouldn't use PI's in ACLs, without the additional
enforcement of trusting the CA that signed the cert
(or else, as Ted pointed out when he & I were chatting on
the phone) you can self-sign a certificate with the requisite
PI and in you go...
>
> Beyond that, the comparison rules for UTF8 strings look wrong --
> I'm glad there's a matching rule specified, but from the little I
> understand about such things there will be a lot of complaints
> about the lack of more CJK-friendly matching rules.
Actually, they should not -- because URIs, as currently
defined, are strictly a subset of 0-127 ascii. If you
want anything else, you have to encode it (e.g., hex encoding).
Now, I'm not saying I think it's the best idea, and
certainly there's something left to be desired in the
implementation proposal -- e.g., they haven't defined how an
"Assignment Authority" should structure its strings such that there
won't be collisions across AA's in any given identifier
type.
Steve:
In message <3E9C7AED.1020503@thinkingcat.com>, Leslie Daigle writes:
>
>
>
>Hmmm, well, just to play devil's advocate for a second (and
>because the alternative is that I have to back to playing
>with powerpoint tables)...
Speaking of the devil....
>
>
>Steven M. Bellovin wrote:
>> In message <200304101701.NAA26528@ietf.org>, IESG Secretary writes:
>>
>>>Last Call to expire on: 2002-12-9
>>>
>>> Please return the full line with your position.
>>>
>>> Yes No-Objection Discuss * Abstain
>>>
>>>
>>>Steve Bellovin [ ] [ ] [ X ] [ ]
>>
>>
>> Permanent universally-unique names strike me as a singularly bad
>> idea in general, and even worse as specified here. A name can only
>> be guaranteed to be unique (even in theory) within the scope of a
>> single CA; there's no way to make any assumptions if different CAs
>> are involved. Sure, they're supposed to be URIs, but that's not
>> enforceable except by referring to the parent certificate, and if
>> you're going to do that why bother with a URI at all? The notion
>> of using permanent identifiers in ACLs is even worse.
>
>Is it any more wrong than using, say, an e-mail address? (Which
>is unique at any given moment in time). Then, each certificate
>is a binding of: a DN (which is more or less an "address" for
>the cert, in some way), a public key, the PI-as-data (e-mail address) and
>the CA's signature on that public key. You can't trust this
>binding any more than you trust the CA that signed it.
>
>So, you shouldn't use PI's in ACLs, without the additional
>enforcement of trusting the CA that signed the cert
>(or else, as Ted pointed out when he & I were chatting on
>the phone) you can self-sign a certificate with the requisite
>PI and in you go...
>
Precisely -- any sort of name, permanent or not, is useless outside of
the administrative context. That's why I think this is such a bad
idea, especially as specified here. Why, for example, does it need to
have the CA's name in the PI field, when you always have to carry the
CA name elsewhere in the certificate?
>>
>> Beyond that, the comparison rules for UTF8 strings look wrong --
>> I'm glad there's a matching rule specified, but from the little I
>> understand about such things there will be a lot of complaints
>> about the lack of more CJK-friendly matching rules.
>
>Actually, they should not -- because URIs, as currently
>defined, are strictly a subset of 0-127 ascii. If you
>want anything else, you have to encode it (e.g., hex encoding).
>
OK -- but in that case, why does the document say that the identifier
can be a UTV8 string?
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Permanent Identifier to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure - Permanent Identifier' <draft-ietf-pkix-pi-06.txt> as
a Proposed Standard. This document is the product of the PKIX Working
Group. The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
This document define a new form of name, called permanent identifier,
that may be included in the subjectAltName extension of an X.509
version 3 public key certificate. The permanent identifier is an
optional feature that may be used by a Certification Authority (CA) to
indicate that the certificate relates to the same entity even if the
name or the affiliation of that entity stored in the subject or
another name form in the subjectAltName extension has changed. The
subject name, carried in the subject field, is only unique for each
subject entity certified by the one CA as identified by the issuer
name field. Also, the new name form can carry a name that is unique
for each subject entity certified by a CA.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller 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-ccamp-gmpls-architecture - Generalized
Multi-Protocol Label Switching Architecture to Proposed
Standard
--------
Last Call to expire on: 2003-4-10
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ X ]
Russ Housley [ ] [ ] [ X ] [ ]
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'.
DISCUSS:
========
Russ:
Two minor comments:
1. Section 4.3, 4th paragraph says: "Forwarding Adjacencies (FA) are
further described in a separate section." It would be nice to say
which one.
2. Section 15, please change "IPSEC" to "IPsec."
Steve:
Nit: section 4 says
Re-using existing IP routing protocols allows for non-PSC layers
to take advantages of all the valuable developments that took
place since years for IP routing,
which isn't grammatically correct.
The Security Considerations section hints at, but doesn't follow
through with, the difference between authentication and authorization.
The requirement for cryptographic authentication or encryption
depends on the risk of attackers being able to inject and/or snoop
on traffic. This may or may not be correlated with intra-domain vs.
inter-domain GMPLS. The physical characteristics and exposure of the
link matter more; there may be additional exposure since it appears
that the control plane link may be more than one hop long.
The authorization question is what resources a given node may request
of another. This may indeed be differ for inter-domain and
intra-domain GMPLS. On the other hand, imposing such limits even
internally helps guard against spreading break-ins, and has useful
effects with regard to configuration errors.
The more important question raised by this latter point is whether or
not a security architecture is needed that specifies what sorts of
restrictions can be applied. I don't know the answer to that one;
clearly, though, implementors are going to have to decide.
COMMENTS:
=========
Ted:
This abstain falls under the category:
> I oppose this document for some philosophical reason but
> understand that others differ and am not going to stand
> in the way of the others
The philosophical reason here is that the document
has addressing fundamentally wrong. This almost
certainly isn't fixable now, so I will not stand in the way.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching
Architecture to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generalized Multi-Protocol
Label Switching Architecture'
<draft-ietf-ccamp-gmpls-architecture-05.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement
Plane Working Group. The IESG contact persons are Bert Wijnen and
Alex Zinin.
Technical Summary
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
Working Group Summary
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen 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-smime-cms-rsaes-oaep - Use of the
RSAES-OAEP Transport Algorithm in CMS to Proposed Standard
--------
Last Call to expire on: 2002-12-19
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ R ]
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: Use of the RSAES-OAEP Transport Algorithm in
CMS to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Use of the RSAES-OAEP
Transport Algorithm in CMS' <draft-ietf-smime-cms-rsaes-oaep-07.txt>
as a Proposed Standard. This document is the product of the S/MIME
Mail Security Working Group.
The IESG contact persons are Russ Housley and Steven Bellovin.
Technical Summary
The RSAES-OAEP Key Transport Algorithm uses a new version of
of PKCS #1 to counter the so-called Million Message Attack that
Version 1.5 was sometimes susceptible to. The document describes
how to embed such wrapped keys in Cryptographic Message Syntax (CMS)
bundles.
Working Group Summary
There were no significant issues.
Protocol Quality
Steve Bellovin has reviewed the spec 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-sigtran-security - Security
Considerations for SIGTRAN Protocols to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Ted:
DISCUSS comment:
Section 6. on TLS usage notes that SIGTRAN protocols use the same
port number and payload protocol identifier when run over TLS, and
that a session upgrade procedure has to be used to initiate the TLS
based
communication. There are, however, no pointers to a specification for
this (even an example). I think _something_ is required here, because
the consequences of doing an upgrade here may not be obvious.
RFC 3436 notes in section 6.2, for example:
TLS requires that the underlying transport delivers TLS records
in strict sequence. Thus, the 'unordered delivery' feature of
SCTP MUST NOT be used on streams which are used for TLS based
user data transmission. For the same reason, TLS records
delivered to SCTP for transmission MUST NOT have limited
lifetimes.
If you UPGRADE, in other words, there are consequences to how you use
SCTP that you may need to take into account. If these don't apply to
SIGTRAN, great, but a worked example or additional text on the
UPGRADE scenario would really help.
Note:
Section 3., "Security in Telephone Networks" seems to report things
like "the trusted network principle" without any comment on how
valid these principles are. Purely as a personal note, I would find
some more cynicism here comforting. This does not, of course,
change the specification in any substantive way.
Russ:
Please make these changes throughout the document:
- change "man in the middle" to "man-in-the-middle"
- change "certificate authority" to "certification authority"
- change "IPSEC" to "IPsec"
- change "root CA" to "trust anchor"
Section 5, 3rd paragraph says: "These nodes MUST support IKE ..."
Are these nodes the ones that implement ESP, or just the ones that
implement ESP in tunnel mode. It needs to be clear which
implementations MUST support IKE.
Section 5, 5th paragraph says: "IKE negotiators SHOULD use
pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures." What are these
checks? At a minimum include a normative reference to RFC 3280. If
on-line checking is anticipated, then a reference to RFC 2560 may be
in order.
Section 5, 7th paragraph seems to use the terms security
association (SA), session, and connection interchangeably. I think
that security association is the proper term.
COMMENTS:
=========
Steve:
Nit: The correct spelling is IPsec, not IPSec.
Section 8 speaks of certificate authorities. Since SIGTRAN
connections are by prearrangement among parties with a pre-existing
business arrangement, there's no need for a CA. One party can issue
a certificate to the other, or each can use self-signed
certificates. Regardless of where the certificate comes from
(including a conventional CA), knowledge of the expected certificate
chain is a necessary part of the security provisioning.
Both of these can be fixed with an RFC editor's note.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sigtran@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Security Considerations for SIGTRAN Protocols
to Proposed Standard
-------------
The IESG has approved the Internet-Draft "Security Considerations for
SIGTRAN Protocols" <draft-ietf-sigtran-security-02.txt> as a Proposed
Standard. This document is the product of the SIGTRAN working group.
It was given a two week Last Call. The IESG contact persons are
Allison Mankin and Jon Peterson.
Technical Summary
This document describes the use of security mechanisms, primarily
IPSec, for securing SIGTRAN (traditional telephony signaling over IP)
networks - this is not intended to be generic security for SCTP, but
rather for a set of telephony signaling services that run over SCTP.
It contains some rudimentary information about threats, but primarily
focuses on a security profile: a normative MUST for support of IPSec
for SIGTRAN elements, and a MAY for TLS. TLS usage is somewhat
underspecified, but TLS is only envisioned for unusual
configurations. To its credit, the document goes significantly beyond
"use IPSec" into quite a bit of implementation and conformance detail,
and notes both the strengths and limitations of its model.
IPSec seems to be a good fit for securing telephony signaling
protocols, which traditionally were employed primarily over closed
networks. There is a certain amount of consideration of
access-network signaling protocols (i.e. ISDN), and the implications
of sending SIGTRAN to a user-controlled node, but mostly this
document examines provider networks that communicate with one another
over the Internet, to which IPSec seems well suited.
Working Group Summary
The SIGTRAN working group supports the publication of this document.
Other WG documents (including draft-ietf-sigtran-v5ua) have
dependencies on this draft.
Protocol Quality/Review
This document was reviewed for the IESG by Jon Peterson.
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-ipsec-ciph-aes-cbc - The AES Cipher
Algorithms and Their Use With IPsec 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 [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
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'.
DISCUSS:
========
Steve:
In Section 2.5, we don't think we want to permit
a variable number of rounds for AES -- NIST explicitly declined to do
so because it interacts with the key schedule generation.
Beyond that, I don't see that 5.4.1 should exist at all.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ipsec@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The AES Cipher Algorithms and Their Use With
IPsec to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The AES Cipher Algorithm
and Its Use With IPsec' <draft-ietf-ipsec-ciph-aes-cbc-04.txt> as a
Proposed Standard. This document is the product of the IP Security
Working Group (IPSEC).
The IESG contact persons are Russ Housley and Steven Bellovin.
Technical Summary
Since IPsec was first developed, the U.S. National Institute of
Standards and Technology (NIST) has completed a process for selecting
the new Advanced Encryption Standard (AES). AES uses longer keys
than the original Data Encryption Standard (DES) that is used by IPsec
for confidentiality. AES also uses a larger encryption block size.
This document describes the use of the AES Cipher Algorithm in Cipher
Block Chaining (CBC) mode as a confidentiality mechanism within the
context of the IPsec Encapsulating Security Payload (ESP) protocol.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller 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-smime-aes-alg - Use of the AES
Encryption Algorithm in CMS to Proposed Standard
--------
Last Call to expire on: 2003-2-25
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
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: Use of the AES Encryption Algorithm in CMS
to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Use of the AES Encryption
Algorithm in CMS' <draft-ietf-smime-aes-alg-06.txt> as a Proposed
Standard. This document is the product of the S/MIME Mail Security
Working Group. The IESG contact persons are Steven Bellovin and
Russ Housley.
Technical Summary
This specification describes how to use the Advanced Encryption
Standard (AES) with the Cryptographic Message Syntax (CMS).
It gives the ASN.1 necessary when AES is used with each
recipient's public RSA key, with a Diffie-Hellman key exchange,
with a previously distributed symmetric key, and with a
key derived from a password.
Working Group Summary
There was no significant disagreement.
Protocol Quality
This specification was reviewed for the IESG by Steve Bellovin.
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-mobileip-mipv6-ha-ipsec - Using IPsec
to Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ XX] [ D ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ XX] [ D ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ D ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Randy:
ops-dir comment causes me to register a DISCUSS
randy
---
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue284.txt
and further
From: Greg O'Shea
I have been raising issues on the MobileIP list as I encounter them,
resulting in a number of mods to the spec of which my favourite was
removal of the S bit in binding updates. Of what remains I do not know
of anything that I think warrants delay.
IMHO what is needed most at this point is a stake in the ground (an
initial stable spec.) pending which everyone is sitting painfully
still and holding their breath. Once the base spec is approved I
expect the innovation and serious experimentation will begin afresh
around it.
I do think that the specification could have been simpler, although
this is not a show stopper and once the initial base spec is
approved there may be efforts in this direction. I believe that home
nets and therefore home addresses should be virtual nets e.g. on a
virtual IF on a HA. This means that random hosts cannot directly
attach to the net and interfere with address assignment. In turn this
means that HA need not run DAD before protecting a HoA, the HA need
not protect link-local addresses derived from HoA, NS code is simpler
and in some cases handoff latency is reduced by a second or two. This
idea was well received on the list but has been set aside as future
work.
I am somewhat dubious about the HA discovery and prefix discovery
stuff. At best I think it belongs in a separate doc. It doesn't
achieve much at all with manual keying. But again that is not a show
stopper.
Steve:
Per Steve Kent's comments (see his annotated version of the draft
at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm ),
there seems to be a serious mismatch between the semantics of IPsec
and what is needed by this spec. In particular, the spec demands
special matching and processing rules for input and output packets
that are seriously inconsistent with IPsec. In principle, IPsec might
be changeable in this regard, since the specs are currently undergoing
revision; in practice, I suspect that the changes needed are too great.
In any event, the changes will require the approval of the IPsec
working group.
Beyond that, this spec requires changes to the SPD as the mobile node
roams. That implies a deep coupling between the MobileIP layer and the
IPsec layer. Implementation might be problematic if outboard (i.e.,
NIC-resident) IPsec implementations are used. I would note that these
have been on the market for a couple of years at the least; they're
not hypothetical devices. I suspect that some of these issues might
be resolvable by using IKE and negotiating new Phase 2 associations.
This would rely on the existing API to IPsec, though admittedly it
might require a new interface to IKE.
Kent's much more detailed comments must be addressed, too.
Russ:
Comments:
In section 1, ESP does not provide in order delivery. The introduction
indicates that this service is needed. If this is correct, then
additional protocol mechanisms are needed.
In section 3, in each instance tell whether ESP is used in transport
mode or tunnel mode.
In section 4.1, the document requires support for manual security
association configuration. I think this should be clear that ESP SAs
are being configured, not IKE pre-shared keys. Also, the phrase
"IPsec protection" really means ESP enacpsulation in many different
places.
Steve Kent's comments on section 4.2, 4.3, 5.1, 5.2, and 5.3 need to be
addressed (see http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm
). Since RFC 2401 is being updated, there is an opportunity for
compromise, but the MobileIP and IPsec working groups need to work
together in this area.
In section 4.3, I suggest that all discussion of AH be removed.
In section 4.4, there seems to be confusion about ESP replay
detection. Why not just say that IKE must be used if replay protection
is needed?
COMMENTS:
=========
Ted:
A couple of editorial nits, and three notes, cc'ed only
to Thomas, so as not to clutter the IESG list with
efforts-to-educate-the-newcomer.
Nits:
The Introduction says it illustrates the use of IPsec
in securing control traffic; Section 3.4 describes the
use of IPsec in protecting payload packets tunneled to
the home agent. Since these can be "any protocol",
they are probably not limiting this to control traffic.
"It is important for the home agent to verify that the care-of
address has not been tampered." seems to be missing a with"
"Where <condition> is an boolean expression" should be
"a boolean expression".
Notes:
I was surprised that the manual configuration for security
associations were MUST and IKE only MAY. I assume that
there is lots of history here, and I don't want to draw anyone into
it, but I was surprised.
In section 4.3, I was surprised that the instructions on using
integrity protection with the manually configured SA did not
have a "as of this writing FOO would be the best choice", since
it was willing to toss DES. I'm guessing that this means
different folks have different flavor preferences here.
Section 7's implementation considerations on fragmentation
in the presence of certificates surprised me by recommending
replacing firewalls or routers, given that we're talking about
mobility. Replacing gear in someone else's network is a good
trick.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents'
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt> as a Proposed Standard.
This document is the product of the IP Routing for Wireless/Mobile
Hosts Working Group.
The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. The mobile IPv6 base document defines the
main requirements these nodes must follow. This document discusses
these requirements in more depth, illustrates the used packet
formats, describes suitable configuration procedures, and shows how
implementations can process the packets in the right order.
Working Group Summary
There was support for this document in the WG.
Protocol Quality
This document 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: Evaluation: draft-aboba-radius-iana - IANA Considerations
for RADIUS to Proposed Standard
--------
Last Call to expire on: 2003-3-21
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 [ ] [ 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: IANA Considerations for RADIUS to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'IANA Considerations for
RADIUS' <draft-aboba-radius-iana-05.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen.
Technical Summary
(What does this protocol do and why does the community need it)
Working Group Summary
(Was there any significant dissent? Was the choice obvious?)
Protocol Quality
(Who has reviewed the spec for the IESG? Are there implementations?)
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-ipv6-unicast-aggr-v2 - IPv6 Global
Unicast Address Format to Informational
--------
Last Call to expire on: 2003-4-8
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
Randy:
From: ops-dir
To: Randy Bush <randy@psg.com>,ops directorate <ops-dir@ops.ietf.org>
Subject: draft-ietf-ipv6-unicast-aggr-v2-02.txt
Date: Mon, 14 Apr 2003 16:58:52 -0400
At 09:23 PM 4/11/2003 -0400, Randy Bush wrote:
>***** o IPv6 Global Unicast Address Format (Informational)
> <draft-ietf-ipv6-unicast-aggr-v2-02.txt>
> Token: Narten, Thomas
> Note: An IETF LC call is needed, as this reclassifies RFC 2374
> historic.; last call expires 2003-04-08.
my concern with this note is that at the top of page 3
the diagram implies that there is a single global
routing prefix, followed by a subnet id.
the text says that the global-routing-prefix is
typically hierarchically structured, which implies
that it is not a single global routing prefix but
has some internal structure, with higher and lower
levels of prefix and so on and so forth. it _might_
be nice if the authors were to do a bit of text editing
and try and get the diagram to say the same thing (eliminating
the implication in the diagram that there is exactly 1 prefix).
also, the text and diagram sort of imply that there is one level
of 'subnet id' that would be available to a 'site'. this is
not completely true. my isp may allocate me a /32, leaving
me 32 bits to play with which i may in turn make hierarchical
allocations out of. again, some text twiddling might be nice
here.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, ipng@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: IPv6 Global Unicast Address Format to
Informational
-------------
The IESG has approved the Internet-Draft 'IPv6 Global Unicast
Address Format' <draft-ietf-ipv6-unicast-aggr-v2-02.txt> as an
Informational RFC. This document will replace RFC2374 and reclassify
RFC 2374 (and the TLA/NLA structure described there) as historic.
This document is the product of the IP Version 6 Working Group.
The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined
an IPv6 address allocation structure that includes TLA (Top Level
Aggregator) and NLA (Next Level Aggregator). This document replaces
RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
Working Group Summary
There was support for this in the WG; this document documents what
the WG decided quite some time ago.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
Application Exchange (apex)
---------------------------
Charter
Last Modified: 2003-3-25
Current Status: Active Working Group
Chair(s):
Resnick, Pete
Applications Area Director(s):
Freed, Ned
Hardie, Ted
Applications Area Advisor:
Hardie, Ted
Mailing Lists:
General Discussion: apexwg@lists.beepcore.org
To Subscribe: apexwg-request@lists.beepcore.org
Archive: http://lists.beepcore.org/mailman/listinfo/apexwg
Description of Working Group:
The APEX working group shall specify protocols and data formats that
define a relaying mesh service for loosely-coupled Internet
applications, along with specifying services to provide access
control and rendezvous-by-subscription. In addition, the working
group shall specify CPIM-compliant application services for
text-based instant messaging and for online presence, based on the
APEX service.
Instant messaging differs from email primarily by requiring
relatively short delivery latency guarantees and, typically, less
robust transport service. Presence information was readily
accessible on Internet-connected systems years ago; when a user had
an open session to a well-known multi-user system, friends and
colleagues could easily tell who was online. However there is no
standard way to make this information known to peers. Similarly a
number of messaging systems have operated over the Internet and
continue to do so, although none has focused on assuring very low
latency between posting and delivery.
The working group will use APEX (as described in draft-mrose-apex-*)
as the basis of the relay mesh, access control and rendezvous
specifications. The working group will use
draft-klyne-imxp-message-service and draft-klyne-message-rfc822-xml
as its starting points for defining the instant messaging and
presence conforming to RFC2779 and the interoperability details in the
final version of the CPIM specification (draft-ietf-impp-cpim).
BCP 41 will be the basis for working group consideration of the
transport implications of the APEX designs with respect to network
congestion, and the working group will coordinate on this with the
BEEP WG.
Although not encouraged, non-backwards-compatible changes to the basis
specifications will be acceptable if the working group determines that
the changes are required to meet the group's technical objectives and
the group clearly documents the reasons for making them.
Goals and Milestones:
Goals and Milestones:
Description
Expected Due Date
Done Date
Prepare initial draft of CPIM-compliant APEX Text Messaging and
Presence specifications
2001-3-31
Prepare updated specifications for APEX relay mesh, access and
rendezvous, reflecting issues and solutions identified by the working
group
2001-3-31
2001-3-31
Submit revised APEX specifications to the IESG for consideration as a
standards-track publication
2001-5-31
Submit revised Text Messaging and Presence specifications to the
IESG for consideration as a standards-track publication
Network Configuration WG (netconf)
-----------------------------------------------------
Status: Proposed new WG
Chair(s):
???
???
Operations and Management Area Directors:
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operation and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists: [ed. these will change to netconf*]
General Discussion: xmlconf@ops.ietf.org
To Subscribe: xmlconf-request@ops.ietf.org
in msg body: subscribe
Archive: http://ops.ietf.org/lists/xmlconf
Description of Working Group:
Configuration of networks of devices has become a critical requirement
for operators in today's highly interoperable networks. Operators from
large to small have developed or used vendor specific mechanisms to
transfer configuration data to and from a device, and for examining
device state information which may impact the configuration. Each of
these mechanisms may be different in various aspects, such as session
establishment, user authentication, configuration data exchange, and
error responses.
The Netconf Working Group is chartered to produce a protocol
suitable for network configuration, with the following
characteristics:
- Provides retrieval mechanisms which can differentiate between
configuration data and non-configuration data
- Is extensible enough that vendors will provide access
to all configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping
and formatting-related changes between releases)
- Uses a textual data representation, that can be easily
manipulated using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features
such as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications
The Netconf protocol will use XML for data encoding purposes,
because XML is a widely deployed standard which is supported
by a large number of applications. XML also supports
hierarchical data structures and multiple character sets.
The Netconf protocol should be independent of the data definition
language and data models used to describe configuration and
state data. However, the authorization model used in the protocol
is dependent on the data model. Although these issues must be
fully addressed to develop standard data models, only a small part
of this work will be initially addressed. This group will specify
requirements for standard data models in order to fully support the
Netconf protocol, such as:
- identification of principals, such as user names or
distinguished names
- mechanism to distinguish configuration from
non-configuration data
- XML namespace conventions
- XML usage guidelines
It should be possible to transport the Netconf protocol using
several different protocols. The group will select at least
one suitable transport mechanism, and define a mapping for
the selected protocol(s).
The initial work will be restricted to the following items:
- Netconf Protocol Specification, which defines the
operational model, protocol operations, transaction model,
data model requirements, security requirements, and
transport layer requirements.
- Netconf over <TBD> Specification, which defines how the
Netconf protocol is used with the transport protocol
selected by the group. There will be a document of
this type for each selected transport protocol.
The working group will base its work on the XMLCONF Configuration
Protocol <draft-enns-xmlconf-spec-00.txt>.
Goals and Milestones:
MAY 03 Working Group formed
JUL 03 Submit initial Netconf Protocol draft
AUG 03 Submit initial Netconf over <TBD> draft
DEC 03 Begin Working Group Last Call for the Netconf Protocol
draft
JAN 04 Begin Working Group Last Call for the Netconf over
<TBD> draft
MAR 04 Submit final version of the Netconf Protocol draft
to the IESG
APR 04 Submit final version of the Netconf over <TBD> draft
to the IESG
Internet Drafts
Request for Comments
Reliable Multicast Transport (rmt)
----------------------------------
Charter
Last Modified: 2003-03-06
Current Status: Active Working Group
Chair(s):
Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion:rmt@ietf.org
To Subscribe: rmt-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/rmt/current/maillist.html
The purpose of this WG is to standardize reliable multicast transport.
Initial efforts have focused solely on the standardization of the
one-to-many transport of large amounts of data. Due to the large
number of applications that fall into this category, and the sometimes
orthogonal requirements these applications exhibit, it is believed
that a "one size fits all" protocol will be unable to meet the
requirements of all applications. In recognition of this observation,
this working group will standardize two protocol instantiations,
initially as Experimental protocols, and then as warranted, in the
standards track, from the following families:
1) A NACK-based protocol.
2) An "Asynchronous Layered Coding protocol that uses Forward Error
Correction.
In addition, the rmt WG will have a sub-group for a different task.
This sub-group will develop a protocol for a simple unicast
replication service that is specifically designed to address the need
of very-small-scale multicast sessions. The goal of this protocol is
to provide a small-scale replication solution that does not require
per-session state in all parts of the network crossed by the session
traffic, unlike native IP multicast. The applicability of this
protocol is to situations where end-to-end unicast replication is not
appropriate due to bandwidth limitation in some part of the
network (usually last-mile links).
It should be noted that this simple unicast replication work is in a
sub-group because a strict interpretation of this service would
determine that it falls somewhat outside the transport domain (other
than congestion control) and has more routing issues than most of the
other work in rmt. Given that the bulk of the experts who would be
qualified to comment on this work item are already active participants
in the rmt WG, the Routing and Transport Area Directors have concluded
to make an exception and develop it in this working group's sub-group
instead of forming a new working group.
The WG will carry out protocol standardization in general by composing a
a set of RFCs that specify
- building blocks: A set of easily-separable coarse-grained modular
components that are common to multiple protocols along with abstract
APIs that define a building block's access methods and their
arguments.
- protocol instantiations: Specifications that define the necessary
gluing logic and minimal additional functionality required to realize
a working protocol from one or more building blocks. These
specifications will also include an abstract API that defines the
interface between the protocol implementation and an application.
The WG has previously completed work on three documents to assist in
the standardization process. RFC2887 describes the design-space in
which the one-to-many transport protocols will be developed. RFC3048
explains the concepts of building-blocks and protocol
instantiations. RFC3269 provides guidelines to authors of drafts that
specify building-blocks and protocol instantiations.
The WG will generate and submit for standardization drafts of the
following building-blocks for use in the construction of the two
protocols: congestion control, negative acknowledgments, forward error
correction, generic mechanisms for router assist, and to address the
RFC 2357 security requirements.
The WG will also standardize and generate RFCs for the following two
protocol instantiations: A NACK-based protocol, and an Asynchronous
Layered Coding (ALC) protocol that uses Forward Error Correction.
RFC 3450 is the Experimental RFC of the ALC protocol instantiation.
If new requirements are identified that cannot be satisfied with the
building-blocks and protocol instantiations described above, the Area
Directors in consultation with the IESG may add additional
building-blocks and protocol instantiations to the working group
deliverables.
This working group will work closely with the Internet Research Task
Force (IRTF) groups on Reliable Multicast (RMRG) and
Secure Multicast (SMUG), especially for meeting the congestion control
and security requirements mandated by RFC 2357. This working group may
work with the Area Directors to recharter to standardize reliable
multicast for additional scenarios beyond the one-to-many transport of
bulk data once they are sufficiently well understood.
MILESTONES
Done Submit design-space, building-blocks, and guidelines drafts for
publication as Informational RFCs
Done Initial Drafts for the following building blocks: negative
acknowledgments, forward error correction, a generic signaling
mechanism for router assist, and transport protection
Done Submit Initial Drafts for the three protocol instantiations.
Done Review drafts at the Adelaide IETF
Done Submit Initial Draft for Congestion Control
Done Complete building-block drafts WG Last-Call and submit for
publication as Proposed Standard
Done Complete building blocks and protocol instantiations for
ALC and submit for publication as Experimental
The following are tentative:
MAY 03 Submit TFMCC congestion control building block for
publication as Experimental
AUG 03 Submit WEBRC (congestion control for ALC) building
block for publication as Experimental
AUG 03 Submit NACK protocol instantiation for publication
as Experimental
AUG 03 Submission of simple unicast replication building block
including congestion control for publication as Experimental
DEC 03 ALC protocol instantiation and building blocks
submitted for publication as Proposed Standard.
DEC 03 TFMCC submitted for publication as Proposed
Standard.
DEC 03 Conclude working group, unless determined with Area Directors
that there is additional work for the charter
Management Issues:
Item name: AD-shepherded non-WG Info/Experimental documents
Writeup to be included in package:
RFC 2026 suggests that Info/Experimental non-WG documents "should"
come to the IESG via the RFC Editor. We've had some exceptions to
this; we need to describe what we do in such a way that the community
knows what to expect.
Suggested texts for a policy:
1)
When an AD decides that an Informational or
Experimental document is of particular importance to the
community, the AD may also choose to put it directly
before the IESG. This document will then be processed in
the same fashion as an Informational or Experimental
document from a working group.
2)
In some cases, an individual will ask an AD directly if they are
willing to shepherd a document through the IESG. This can happen,
for example, when an individual has already been discussing a
particular document with an AD because the topic of the document
naturally falls into a particular area. In such cases, the
document is processed in the same fashion as an Informational or
Experimental document from a working group.