[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UPDATED: 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
IP o Randy to send new charter review message to Secretariat.
Secretariat to send to ietf-announce, new-work, cc: 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 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 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 Security Considerations for SIGTRAN Protocols (Proposed Standard)
<draft-ietf-sigtran-security-02.txt>
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 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 Use of the RSAES-OAEP Transport Algorithm in CMS (Proposed Standard)
<draft-ietf-smime-cms-rsaes-oaep-07.txt>
Token: Bellovin, Steve
o The AES Cipher Algorithms and Their Use With IPsec (Proposed Standard)
<draft-ietf-ipsec-ciph-aes-cbc-04.txt>
Token: Housley, Russ
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. Proposed Working Groups
o Application Exchange (apex)
Token: Hardie, Ted
o Network Configuration (netconf)
Token: Bert
o Reliable Multicast Transport (rmt)
Token: Allison
6. Working Group News we can use
7. IAB News we can use
8. Management Issues
o Proposed resolution of the AD-shepherded info/experimental
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 new charter review message to Secretariat.
Secretariat to send to ietf-announce and new-work, cc: 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 [ ] [ ] [ X ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
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?
^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-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 [ ] [ ] [ ] [ ]
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>, 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 [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
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>, 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-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 [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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'.
^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-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 [ ] [ ] [ ] [ ]
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>, 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-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 [ ] [ ] [ ] [ ]
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 [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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'.
^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.