[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for June 26, 2003 Telechat (Final)
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the June 26, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, June 26, 2003
from 11:30-14:00 US-ET. If you are *unable* to participate in the
teleconference, or if you wish to change your usual procedures for
connecting to the call (as indicated in the list below), then please reply
to this message as follows:
o If you are unable to participate, then please write "Regrets" after your
name.
o If you normally call in, but will require operator assistance for this
teleconference, then please provide the telephone number where you can be
reached.
o If you are normally connected to the teleconference by an operator, but
will call in for this teleconference, then please write "Will call in" next
to your name in place of the telephone number.
Harald Alvestrand---Will call in
Rob Austein---Will call in
Marcia Beaulieu---Will call in
Steve Bellovin---Will call in
Randy Bush---Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Dinara Suleymanova---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Jacqueline Hargest---Regrets
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten---Will call in
Erik Nordmark---Call at +33 4 76 99 84 29
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Bert Wijnen---Regrets
Alex Zinin---Will call in
To join the teleconference, please call the appropriate dial-in number (see
below) at 11:30 AM ET. If you have requested operator assistance, then an
operator will call you and connect you to the call.
Participants inside the U.S. should use the toll-free number 888-315-1685.
Participants outside the U.S. should use either one of the toll-free
numbers listed at the end of this message, or the direct-dial number
703-788-0617. Participants using the direct-dial number will pay their own
long distance charges through their own carriers. Participants dialing the
toll-free number will not pay any charges for the conference as all
charges, including long distance, will be included on the invoice sent to
the company hosting the call. In some cases, participants from certain
international countries may only use a direct-dial number.
All participant should enter the passcode 235467 when prompted to do so.
The first person on the call will not hear anything until joined by other
participants. A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND
THUS INCUR CHARGES FROM THEIR OWN CARRIER.
o Bash the Agenda
o Approval of the Minutes
- June 12, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: June 20, 2003
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking architectural
questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex to send proposal and justification for interim document review.
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the current
info/proposed/etc.
IP o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
IP o Harald Alvestrand to talk to RFC Editor about independent submissions.
IP o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
IP o Secretariat to include teleconference bridge/call-in details in telechat
packages going forward.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-enum-rfc2916bis-06.txt
The E.164 to URI DDDS Application (ENUM) (Proposed Standard)
Token: Mankin, Allison
Note: Liaison statement was sent to SG-2 about Last Call.
o draft-ietf-mmusic-sdp-new-13.txt
SDP: Session Description Protocol (Proposed Standard)
Token: Peterson, Jon
o draft-ietf-avt-mpeg4-simple-07.txt
RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed
Standard)
Token: Mankin, Allison
Note: Nits: needs to cite rtp-new and abstract should mention the
MIME registration - can fix after Last Call and IESG review (but IANA
attention should be drawn to MIME reg).
2.1.2 Returning Item
o draft-ietf-avt-srtp-08.txt
The Secure Real-time Transport Protocol (Proposed Standard)
Token: Mankin, Allison
Note: Ready for IESG review - last call comments found a few concerns
with the treatment of padding and index and these were corrected in a
new rev.
o draft-ietf-sipping-overlap-04.txt
Mapping of of Integrated Services Digital Network (ISUP) Overlap
Signalling to the Session Initiation Protocol (Proposed Standard)
Token: Mankin, Allison
Note: New version needs review by the Discussants. One past revision
was unclear, but this revision looks good..
2.2 Individual Submissions
2.2.1 New Item
o draft-legg-ldapext-component-matching-10.txt
LDAP & X.500 Component Matching Rules (Proposed Standard)
Token: Hardie, Ted
Note: Depending on Subentry Specification for LDAP.
2.2.2 Returning Item
o draft-nesser-otp-sha-256-384-512-02.txt
Generating One-Time Passwords with SHA-256, SHA-384, and SHA-512
(Proposed Standard)
Token: Housley, Russ
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-speechsc-reqts-04.txt
Requirements for Distributed Control of ASR, SI/SV and TTS Resources
(Informational)
Token: Peterson, Jon
o draft-ietf-nsis-req-08.txt
Requirements for Signaling Protocols (Informational)
Token: Mankin, Allison
Note: Extensive review with WG and editor. Document was revised to
meet deadline of 6/26 agenda.
o draft-ietf-mpls-ldp-restart-applic-01.txt
Applicability Statement for Restart Mechanisms for the Label
Distribution Protocol (Informational)
Token: Zinin, Alex
Note: Responsible: WG chairs
o draft-ietf-manet-olsr-10.txt
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
o draft-ietf-rmt-bb-fec-supp-compact-01.txt
Compact Forward Error Correction (FEC) Schemes (Experimental)
Token: Mankin, Allison
o draft-ietf-crisp-requirements-05.txt
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
Token: Freed, Ned
Note: Asked to be added to IESG agenda
o draft-ietf-v6ops-unman-scenarios-02.txt
Unmanaged Networks IPv6 Transition Scenarios (Informational)
Token: Bush, Randy
3.1.2 Returning Item
o draft-ietf-multi6-multihoming-requirements-07.txt
Goals for IPv6 Site-Multihoming Architectures (Informational)
Token: Bush, Randy
o draft-ietf-nsis-qos-requirements-01.txt
Requirements of a QoS Solution for Mobile IP (Informational)
Token: Mankin, Allison
Note: This document is a renaming of
draft-ietf-mobileip-qos-requirements-03.txt (expired). That document
was reviewed by IESG already and was given a go, except for lacking a
Security Consideration section, which it now has (2003-06-19).
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o draft-lear-tftp-uri-06.txt
URI Scheme for the TFTP Protocol (Informational)
Token: Hardie, Ted
3.2.2 Returning Item
NONE
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o draft-paskin-doi-uri-03.txt
The 'doi' URI Scheme for Digital Object Identifier (DOI)
(Informational)
Token: Hardie, Ted
o draft-foster-mgcp-bulkaudits-09.txt
The Media Gateway Control Protocol (MGCP) Bulk Audit Package
(Informational)
Token: Peterson, Jon
o draft-eastlake-xxx-06.txt
.sex Considered Dangerous (Informational)
Token: Alvestrand, Harald
o draft-baker-slem-architecture-01.txt
Cisco Support for Lawful Intercept In IP Networks (Informational)
Token: Alvestrand, Harald
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Layer 3 Virtual Private Networks
Token: Thomas
o Path Maximum Transmission Unit Discovery
o Layer 2 Virtual Private Networks
Token: Thomas
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG) MINUTES
June 12, 2003 IESG Teleconference
Reported by: Jacqueline Hargest, IETF Secretariat
ATTENDEES
-----------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Randy Bush / IIJ
Michelle Cotton / ICANN
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Jacqueline Hargest / IETF Secretariat
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Erik Nordmark / Sun
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Dinara Suleymanova / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Steve Bellovin / AT&T Labs
Thomas Narten / IBM
Minutes
--------
1. The minutes of the May 29, 2003 teleconference were approved.
The Secretariat to place in public archives.
2. Review Action Items
DONE TASKS:
o Ted to write straw working group procedures for handling consensus-
blocked decisions
o Printer Finishing MIB (Informational) <draft-ietf-printmib-
finishing-16.txt> RFC Editor's Note to be prepared by Ned Freed.
Secretariat to send Document Action Announcement including RFC Editor's Note.
o Secretariat to include the following statement (line) before the
draft approval announcement that is part of a ballot.
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
o IESG to review IANA matrix data.
OUTSTANDING TASKS:
o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
o Thomas to write (or cause to be written) a draft on "how to get to Draft".
o Thomas to contact Cablelabs to discuss formal relationship with IAB
o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
o Ned to write an IESG note for draft-tegen-smqp (Informational)
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 Alex to send proposal and justification for interim document review.
o Steve to generate a summary of IESG views of the "problem"
o Steve to propose a different document classification than the current
info/proposed/etc.
o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
o Harald Alvestrand to talk to RFC Editor about independent submissions.
o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
NEW TASKS:
o Secretariat to include teleconference bridge/call-in details in telechat
packages going forward.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Securing X.400 Content with S/MIME (Proposed Standard)
<draft-ietf-smime-x400wrap-06.tx>
Under Discussion by Steve Bellovin - IESG Review - AD Follow Up
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-22.txt>
Under Discussion by Steve, Erik
o Definitions of Managed Objects for the Ethernet-like
Interface Types (Proposed Standard)
<draft-ietf-hubmib-etherif-mib-v3-03.tx>
Approved - Secretariat to announce, and include note
that as a result of this approval, RFC1643 has been
re-classified to Historic Status.
o Multi Protocol Label Switching Label Distribution Protocol
Query Message Description (Proposed Standard)
<draft-ietf-mpls-lsp-query-07.txt>
Under discussion by Harald, Steve and Russ
o The Secure Real-time Transport Protocol (Proposed Standard)
<draft-ietf-avt-srtp-08.tx>
Deferred to next telechat by Russ Housley, Jon Peterson
Discuss comments by Steve Bellovin
o An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing (Proposed Standard)
<draft-ietf-sip-symmetric-response-00.txt>
Under discussion by Ted, Erik
o Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework (BCP)
<draft-ietf-snmpv3-coex-v2-04.txt>
Approved - Point Raised
Secretariat to announce pending RFC Editor Note from Bert.
o PacketCable Security Ticket Control Sub-option for the
CableLabs Client Configuration Option (Proposed Standard)
<draft-ietf-dhc-pktc-kerb-tckt-02.txt>
Under Discussion - Point Raised by Harald
o Remote Network Monitoring MIB Protocol Identifier Reference
(Draft Standard)
<rfc2895.txt>
Under Discussion by Steve
2.1.2 Returning Item
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes
and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-05.txt>
Under Discussion by Steve, Randy and Russ
2.2 Individual Submissions
2.2.1 New Item
o Generating One-Time Passwords with SHA-256, SHA-384, and
SHA-512 (Proposed Standard)
<draft-nesser-otp-sha-256-384-512-02.txt>
Under Discussion by Harald, Steve, Randy and Russ
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Under Discussion by Allison, Jon
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o OSPF Refresh and Flooding Reduction in Stable Topologies
(Informational)
<draft-pillay-esnault-ospf-flooding-06.txt>
Removed per Bill Fenner
o Introduction to the Remote Monitoring (RMON) Family of MIB
Modules (Informational)
<draft-ietf-rmonmib-framework-05.txt>
Approved - Secretariat to announce
o Transition Scenarios for 3GPP Networks (Informational)
<draft-ietf-v6ops-3gpp-cases-03.txt>
Approved - Secretariat to announce
o Guidelines for Extending the Extensible Provisioning Protocol Informational)
<draft-ietf-provreg-epp-ext-03.txt>
Approved pending RFC Editor Note - Secretariat to announce
o Border Gateway Multicast Protocol (BGMP): Protocol
Specification (Informational)
<draft-ietf-bgmp-spec-05.txt>
Under discussion by Randy
3.1.2 Returning Item
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-04.txt>
Approved - Point raised - Pending RFC Editor Note, Secretariat to announce
3.2 Indivdiual Submissions Via AD
3.2.1 New Item
o The QCP File Format and Associated Media Types (Informational)
<draft-gellens-qcp-01.txt>
Approved - Secretariat to announce
Note: IESG may request expedited publication.
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o Backtrace Messages for Label Switched Paths (Informational)
<draft-kishan-lsp-btrace-04.txt>
Secretariat to send DNP message to RFC Editor per AlexÆs note.
o Guidelines for MPLS Load Balancing (Informational)
<draft-allan-mpls-loadbal-04.txt>
Secretariat to send DNP message to RFC Editor per AlexÆs note.
3.3.2 Returning Item
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-10.txt>
Approved - Point Raised. Secretariat to announce, incorporating
IESG note from Allison Mankin.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Layer 2 Virtual Private Networks
Token: Thomas
After Alex and Allison agree on Item 6, Alex will notify
Secretariat. Secretariat to send Working Group Review
Message to IETF and new-work simultaneously with L3VPN message.
o Path Maximum Transmission Unit Discovery
Token: Allison
Secretariat to send Working Group Review message to IETF
and new-work.
o Layer 3 Virtual Private Networks
Token: Thomas
After Alex and Allison agree on wording of Layer 2 Virtual
Private Networks, Alex will notify Secretariat. Secretariat
to send Working Group Review Message to IETF and new-work
simultaneously with L2VPN message.
Management Issues
o Review the mechanism for call-in Ted Hardie
(discussed)
NOTE: Going forward, it was agreed that IESG members need only
notify Secretariat if he/she is either unavailable for the
upcoming telechat, or there is a change in how he/she will
connect to the call. Otherwise it will be assumed that he or
she plans to join.
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-enum-rfc2916bis - The E.164 to URI DDDS
Application (ENUM) to Proposed Standard
--------
Last Call to expire on: 2003-6-23
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 [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, enum@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The E.164 to URI DDDS Application (ENUM) to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The E.164 to URI DDDS Application
(ENUM)' <draft-ietf-enum-rfc2916bis-06.txt> as a Proposed Standard.
This document is the product of the Telephone Number Mapping Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
This document specifies how DNS can be used for identifying available
services connected to one E.164 number. It specifically obsoletes RFC
2916 to bring it in line with the Dynamic Delegation Discovery System
(DDDS) Application specification found in RFC 3401 and its companion
RFCs.
Working Group Summary
The working group strongly supported advancement of the draft, after
careful technical review.
Protocol Quality
There are currently in prototype use several implementations of this
draft, and registries of services following the format here are under
active development. The document was reviewed for the IESG by Allison
Mankin
RFC Editor Note -
Change the first sentence of Section 3.1.4 Publication Requirements:
Old:
Proposals for Enumservices registered must be published as RFCs on
the Standards Track or as a BCP.
New:
Proposals for Enumservices registered must be published as RFCs.
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-mmusic-sdp-new - SDP: Session
Description Protocol to Proposed Standard
--------
Last Call to expire on: July 12, 2002
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 [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Russ:
Section 4.3 talks about private sessions. It says:
"The details of how encryption is performed are dependent on the
mechanism used to convey SDP - e.g. mechanisms are defined for SDP
transported using SAP [RFC2974] and SIP [RFC3261]."
Why aren't S/MIME for email and TLS for WWW included here?
In section 5, the discussion of encryption keys says:
"k=clear:<encryption key>
The encryption key is included untransformed in this key field.
This method MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure channel.
k=base64:<encoded encryption key>
The encryption key is included in this key field but has been
base64 encoded because it includes characters that are
prohibited in SDP. This method MUST NOT be used unless it can
be guaranteed that the SDP is conveyed over a secure channel."
These restrictions are necessary but not sufficient. You must also
ensure that the secure channel is with the party that is authorized to join
the session, not an intermediary. If a caching server is used, there ought
to be a way to keep the server from accessing the key.
Also, it is generally a good idea to indicate the algorithm that a
cryptographic key is intended to support. I suggest that the encryption
key type be revised to specify the key as well as the algorithm that the
key will be used with.
Finally, many security protocols require two keys, one for
confidentiality and another for integrity. This specification does not
support the transfer of two keys.
In section 6, the document says:
"Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated."
I agree. It would therefore be desirable for the "k=" field to support
two other alternatives. First, it would be nice to name the key without
actually including the key. In PEM (see RFC 1040), the Recipient-ID was
used to name key-encryption keys, and a similar scheme could be employed
here. Second, it would be nice to encrypt the session key in a key that is
not included in SDP. PEM also includes a mechanism for wrapped symmetric keys.
Ted:
In Section 5, for the description of u=<URI>
I'd suggest eliminating "as used by WWW clients." and adding a citation
to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this
definition seems to presume that all URIs used will be dereferencable,
which is not true for all URIs. If this is a limitation, then it should
be stated.
The k=<uri> also seems to presume that the URI is dereferencable.
If this is a limitation of the URI, it should be made explicit
which schemes
are appropriate here. Frankly, it seems to mean http:; if that is the
case, specifying it seems like a good idea. Even for dereferencable
URI schemes, not all will use MIME to mark the reply (think of an
ftp: URI, for example). When they do, the mime content-encoding
specifies the encoding of the _message_, so reusing the word
"encoding" here seems problematic. How would "For those URI
schemes which use MIME, the content-encoding and content-type
headers of the reply may provide guidance on the format of the key."
work?
On that same hobby horse, the ABNF in the appendix has:
; sub-rules of 'u='
uri = URI-reference; see RFC1630 and RFC2732
I think this should be a pointer to 2396 or the 2396bis draft.
For the a= inactive designation, we've discussed what addresses to use
for sessions which are being set up but for which addresses are
not yet known.
It was suggested apps use something like "sdp.inactive" so that
the .inactive
TLD could reinforce the a=inactive flag. In that instance,
would the presence
of that TLD be a condition under which the RTCP SHOULD is appropriately
not done, and no RTCP sent? If so, is mentioning that case
appropriate here?
In the IANA considerations, it looks the draft should specify that the
IANA must update the MIME media type registration to point to this
doc instead of RFC 2327.
Notes:
Having Section 5 contain so much without sub-headers made it hard to
give pointers to sections in the comments; that may be true for others
using the spec as well.
In section 5, in the section describing the first subfield of c=
Just as a query, has anyone considered using a specific marker of
private address realms for SDP? That is, using a network type other
than IN to indicate that the domain name or address given are
not globally unique/globally reachable?
In the Security considerations, "Many different protocols may be used
to distribute session description," looks like session description should
be plural.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mmusic@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: SDP: Session Description Protocol to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'SDP: Session Description Protocol'
<draft-ietf-mmusic-sdp-new-13.txt> as a Proposed Standard. This document is
the product of the Multiparty Multimedia Session Control Working Group. The
IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
This memo defines the Session Description Protocol (SDP). SDP is intended
for describing multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session initiation.
In particular, this document provides a new version of SDP that incorporates
fixes and extensions that have been designed in the MMUSIC WG since the
publication of the original SDP specification, RFC2327. This document is not
SDPng, which fundamentally re-examines the problem space of SDP and arrives
at a new solution. Rather, this document collects increment fixes to SDP
that are critical to its proper operation, and merit inclusion in the core
standard.
Working Group Summary
The MMUSIC working group supported publication of this document.
Protocol Quality
This document was reviewed by Allison Mankin and 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-avt-mpeg4-simple - RTP Payload Format for
Transport of MPEG-4 Elementary Streams to Proposed Standard
--------
Last Call to expire on: 2003-6-16
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 [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Payload Format for Transport of MPEG-4
Elementary Streams to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The RTP Payload Format for Transport
of MPEG-4 Elementary Streams <draft-ietf-avt-mpeg4-simple-07.txt> as a
Proposed Standard. This document is the product of the Audio Video Transport
Working Group. The IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
The MPEG-4 standard specifies compression of audio-visual data into
for example an audio or video elementary stream. In the MPEG-4
standard, these streams take the form of audio-visual objects that may
be arranged into an audio-visual scene by means of a scene
description. Each MPEG-4 elementary stream consists of a sequence of
Access Units; examples of an Access Unit (AU) are an audio frame and a
video picture.
This specification defines a general and configurable payload
structure to transport non-multiplexed MPEG-4 elementary streams, in
particular MPEG-4 audio (including speech) streams, MPEG-4 video
streams and also MPEG-4 systems streams, such as BIFS (BInary Format
for Scenes), OCI (Object Content Information), OD (Object Descriptor)
and IPMP (Intellectual Property Management and Protection) streams.
The RTP payload defined in this document is simple to implement and
reasonably efficient. It allows for optional interleaving of Access
Units (such as audio frames) to increase error resiliency in packet
loss.
This payload format is largely compatible with the video part
of RFC 3016, the RTP Payload Format for MPEG-4 Audio/Visual Streams, and
extends that format to effectively support other classes of media and also
MPEG-4 Systems streams.
The specification registers the MIME sub-types audio/mpeg4-generic,
video/mpeg4-generic and application/mpeg4-generic.
MPEG-4 Systems supports stream types including commands that are
executed on the terminal like OD commands, BIFS commands, etc. and
programmatic content like MPEG-J (Java(TM) Byte Code) and
CMAScript. The Security Considerations discuss risks associated with
these capabilities and ways to mitigate these risks.
Working Group Summary
This was a strenuous effort by the AVT Working group.
This payload format has been under development since the 39th IETF meeting
in Munich, August 1997. It is the result of collaboration between AVT, the
MPEG committee and the Internet Streaming Media Alliance. When the
consensus designs were achieved, there was a thorough Last Call review and
strong support for advancement.
Protocol Quality
The specification was reviewed for the IESG by Allison Mankin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-avt-srtp - The Secure Real-time
Transport Protocol to Proposed Standard
--------
Last Call to expire on: 2003-5-22
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ D ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ D ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
Discuss:
=======
Steve:
SSRC should be expanded in the text the first time it's used.
The IV definition in 4.1.1 has me a bit nervous. Right now, it's
(k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key,
ssrc is the 32-bit synchronization source, and i is the 48-bit packet
index. The low-order 16 bits are for the block number within the
packet, which is fine.
The problem I have is that given the mandated 0-padding, the high-order
32 bits of the IV are from k_s, unmodified by anything else. Furthermore
ssrc and i are known to the attacker, and the block count is obvious.
This means that the IV is a trivial function of most of the session key.
I don't *think* that that's a problem, but any extra use of keys makes me
nervous.
Russ:
I have six comments.
1. In section 1, spell out the first use of RTCP.
2. I find the structure of section 2 confusing. I had to read it twice to
understand it. I think that a second level of indenting would be one way
to fix it. I am sure there are others.
3. In section 3.1, in the paragraph after figure 1, please delete:
"It is exact for the pre-defined transforms."
This point is made more clearly later in the paragraph. Then, at the end
of the same paragraph, the document says:
"While it could seem more attractive to specify a fixed padding
scheme for all transforms, security and flexibility of transform
specifications REQUIRE that each transform specify a secure
padding method."
I disagree. IPsec and S/MIME both specify padding schemes that are
employed by all of the ciphers. Please reword. Do not use "REQUIRE" in
the replacement.
4. In section 3.2.1, the document says: "the master key(s), which MUST be
random and kept secret." This is quite a high bar. I suggest that
pseudo-random is sufficient. Please see the RFC 2828 definitions of
"random" and "pseudo-random." The document says that it is following these
terms. Also, see RFC 1750. Similarly, the requirement on the master salt
should also be reduced to pseudo-random.
5. The last paragraph is section 3.2.3 says:
"If no valid context can be found for a packet corresponding to a
certain context identifier, that packet MUST be discarded from
further SRTP processing."
Elsewhere, "discarded from further processing" is used. This seems better
to me. It is discarded, which seems different that no further SRTP
processing. Also, SRTCP should be covered by this statement.
6. In section 4.1.1, I am confused by the term "fixed key" in the following:
"For a fixed Counter Mode key, each IV value used as an input MUST be
distinct, in order to avoid the security exposure of a two-time pad
situation (Section 9.1). To satisfy this constraint, an
implementation MUST ensure that the values of the SRTP packet index
of ROC || SEQ, and the SSRC used in the construction of the IV are
distinct for any fixed key. The failure to ensure this uniqueness
could be catastrophic for Secure RTP. This is in contrast to the
situation for RTP itself, which may be able to tolerate such
failures. It is RECOMMENDED that, if a dedicated security module is
present, the RTP sequence numbers and SSRC either be generated or
checked by that module (i.e., sequence-number and SSRC processing in
an SRTP system needs to be protected as well as the key). "
I think that "fixed" means "any particular key" but I am not sure.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Secure Real-time Transport Protocol to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The Secure Real-time
Transport Protocol' <draft-ietf-avt-srtp-08.txt> as a Proposed
Standard. This document is the product of the Audio/Video Transport
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
This specification defines a profile for the Real-time Transport Protocol
(RTP) and Real-time Transport Control Protocol (RTCP) called the Secure
Real-time Transport Protocol (SRTP).
The security goals for SRTP are to ensure:
* the confidentiality of the RTP and RTCP payloads, and
* the integrity of the entire RTP and RTCP packets, together with
protection against replayed packets.
These security services are optional and independent from each
other, except that SRTCP integrity protection is mandatory
(malicious or erroneous alteration of RTCP messages could disrupt
the processing of the RTP stream).
Other, functional, goals for the protocol are:
* a framework that permits upgrading with new cryptographic
transforms,
* low bandwidth cost, i.e., a framework preserving RTP header
compression efficiency,
The provision of integrity is strongly recommended for most applications
of SRTP. The mandatory to implement transform for this profile is AES
counter mode, and there are risks associated with not using cryptographic
integrity with it (see Section 9.5).
Working Group Summary
The initial drafts had a default in which integrity services were not
the norm and in which SRTCP did not have mandatory integrity protection.
There was a lengthy security review to ensure that the authentication tag
is recommended to most RTP recommendations.
Protocol Quality
The specification was reviewed for the IESG by Eric Rescorla and Allison
Mankin. Implementations that tested the specification were discussed by
the working group.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sipping-overlap - Mapping of ISUP Overlap
Signaling to the Session Initiation Protocol to Proposed Standard
--------
Removed from draft-ietf-sipping-isup 26aug.
Last Call to expire on: August 5, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Steve: It says "encrypt and authenticate", but it doesn't say how. What is
mandatory to implement? More seriously, the first scenario (section 3)
describes communication from an arbitrary SIP phone to a gateway.
Since bad guys can purchase phone service as easily as good guys can
(more easily -- they can use fraudulent payment instruments...), what's
really needed is not just authentication, but authorization at the
level of individual protocol elements. Some analysis needs to be
performed about just what messages and parameters are dangerous, and I
suspect that this is the document to do it if there's no ISUP security
analysis document in ITU space. I'd be willing to accept a separate
security analysis document, but that would, I think, be a normative
reference from this document.
Section 4.4: Is [16] mandatory to implement? If not, what is?
4.5: Same sort of thing -- it says "MGCs should support ... [1]". Is
that a SHOULD? (2119 isn't invoked.) A MUST? If not, how is this
done?
draft-ietf-sipping-overlap-01.txt:
There are non-ASCII characters.
Is there any potential for denial of service from receipt of partial
numbers by either the GSTN or SIP gateways? Please clarify.
Randy: i should probably just piggyback on smb's
5. Security Considerations
No extra security risk outside these specified by [3] are
foreseen.
but [3], which refers to -02 not -04, says
In most respects, the information that is translated from ISUP
to SIP has no special security requirements. In order for
translated parameters to be used to route requests, they should
be legible to intermediaries; end-to-end confidentiality of this
data would be unnecessary and most likely detrimental. There are
also numerous circumstances under which intermediaries can
legimitately overwrite the values that have been provided by
translation, and hence integrity over these headers is similarly
not desirable.
so i am confused about the mitm situation when things are made even
more vulnerable by being chopped up in draft-ietf-sipping-overlap-01.txt
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: ISUP to SIP Mapping to Proposed Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Mapping of ISUP Overlap Signaling to the Session Initiation
Protocol <draft-ietf-sipping-overlap-01.txt>
This document is the product of the Session Initiation Proposal
Investigation Working Group. The IESG contact persons are Allison
Mankin and Scott Bradner.
Technical Summary
The "ISUP to SIP Mapping" document takes into consideration ISUP
en-bloc signalling, which means sending the complete telephone
number of the callee in the first signalling message. Although modern
switches always use en-bloc signalling, some parts of the PSTN still
use overlap signalling, and this is the subject of the second document,
"Mapping of ISUP Overlap Signaling to the Session Initial Protocol."
Overlap signalling consists of sending just some digits
of the callee's number in the first signalling message.
Further digits are sent in subsequent signalling messages.
Working Group Summary
The current version of the document reflects the issues raised during
the IETF Last Call.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-legg-ldapext-component-matching - LDAP &
X.500 Component Matching Rules to Proposed Standard
--------
Last Call to expire on: 2003-6-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 [ X ] [ ] [ ] [ ]
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: LDAP & X.500 Component Matching Rules to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAP & X.500 Component
Matching Rules' <draft-legg-ldapext-component-matching-11.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 Ted
Hardie and Ned Freed.
Technical Summary
The structure or data type of data held in an attribute of an LDAP
or X.500 directory is described by the attribute's
syntax. Attribute syntaxes range from simple data types, such as
text string, integer, or boolean, to complex data types, for example,
the syntaxes of the directory schema operational attributes.
In LDAP, the attribute syntaxes are usually described by ABNF
though there is an implied association between the LDAP attribute
syntaxes and the X.500 ASN.1 types. To a large extent, the data
types of attribute values in either an LDAP or X.500 directory are
described by ASN.1 types. This formal description can be exploited
to identify component parts of an attribute value for a variety of
purposes. This document addresses attribute value matching.
Working Group Summary
Though this work was brought to the LDAPEXT working group
during the group's lifetime, the draft was not forwarded by
the working group before it shut down. The author continued
to work on it as an individual submission.
Protocol Quality
This document was reviewed by the LDAP directorate; there were
also significant last call comments, resulting in a revision of the
document.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-nesser-otp-sha-256-384-512 - AES Companion
Hash Definitions (SHA256, SHA384, SHA512) for OTP to Proposed
Standard
--------
Last Call to expire on: 2003-1-30
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ X ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Allison:
Perhaps a bad idea to have the set of home-grown definitions of MAY, SHOULD,
MUST, rather than citing RFC 2119. The definitions aren't bad, but it's not
a great precedent?
Steve:
I do not believe it's correct to refer to the new hash functions as
"AES hashes".
I have doubts about whether or nor this should be a Proposed standard.
I don't really see the need, and the document itself expresses
concerns. A longer hash is useful if more of the output is being used,
but that's not the case here.
Randy:
ops-dir comment
> 2.2 Individual Submissions
> 2.2.1 New Item
> ** o Generating One-Time Passwords with SHA-256, SHA-384, and
> SHA-512 (Proposed Standard)
> <draft-nesser-otp-sha-256-384-512-02.txt>
> Token: Housley, Russ
==> doesn't have the IPR considerations section
1.0 ABSTRACT
==> abstract is numbered.
Although the SHA-256, SHA-384 and SHA-512 alogrithms are still in their
==> s/alog/algo/
8.0 Neccessity of Implementation
==> s/cc/c/
9.0 SECURITY CONSIDERATIONS
==> some sections appear to be all-uppercase, while some are not
3.0 REQUIREMENTS TERMINOLOGY
==> any particular reason not to use RFC2119 terminology?
12.0 REFERENCES
[FIPS 180-2] Secure Hash Standard: A Revision of FIPS 180-1, August 2002
==> not split to normative/informative
==> should have a normative reference to RFC2289, at the very least!
Harald:
The document uses C code fragments to specify its algorithms, but uses
libraries the functionality of which is not defined in the document (the
sha functions and structures).
This violates the IESG guidelines on use of formal languages:
<http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>
If the libraries are completely specified in the FIPS document referenced,
a sentence saying that is sufficient.
NOTE: The FIPS document is a normative reference.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: AES Companion Hash Definitions (SHA256,
SHA384, SHA512) for OTP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generating One-Time
Passwords with SHA-256, SHA-384, and SHA-512' <draft-nesser-otp-
sha-256-384-512-02.txt> as a Proposed Standard. The IESG contact
persons are Russell Housley and Steven Bellovin.
Technical Summary
This document describes the use of the new SHA-256, SHA-384 and
SHA-512 hash alogrithms, for use with the One Time Password (OTP)
system, as defined by RFC 2289.
Working Group Summary
This was not a the product of any IETF working group. No issues were
raised during the IETF Last Call.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
DNP note <draft-paskin-doi-03.txt>:
This document proposes a top-level URI scheme, doi, and contains
details about the usage of this identifier in a community of use
centered on the International DOI Foundation. After receiving this
draft from the RFC Editor, the IESG requested that the URI be
reviewed by the team at uri-review@ietf.org to see if it fit within
the guidelines established by RFC 2717/BCP35. Though the authors
and reviewers have had a productive discussion of the draft,
the IESG has concluded that this draft does not meet the requirements
of RFC 2717, section 3.2.
The IESG notes, however, that the original intention of those crafting
RFC 2717 was to set up registration trees outside the IETF tree, in order to
enable registrations by those whose community of use lay largely
outside the context
of IETF standards. After a long pause in the development of those registration
procedures, the responsible AD has asked Larry Masinter to take on editorship
of a proposed set of procedures for these registrations. The IESG encourages
the draft's authors to work with him on those guidelines and, when they
are complete, to register the doi scheme in the non-IETF tree that they will
set up.
Layer 3 Virtual Private Networks (l3vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-12
Current Status: Proposed Working Group
Chair(s):
<under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: l3vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/maillist.html
Description of Working Group:
Alex is the routing advisor.
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
Layer-3 (routed) Virtual Private Networks (L3VPNs).
The WG is responsible for standardization of the following solutions:
1. BGP/MPLS IP VPNs (based on RFC 2547)
2. IP VPNs using Virtual Routers
3. CE-based VPNs using IPSEC
The following VPN deployment scenarios will be considered by the WG:
1. Internet-wide: VPN sites attached to arbitratry points in
the Internet
2. Single SP/single AS: VPN sites attached to the network of a
single provider within the scope of a single AS
3. Single SP/multiple AS'es: VPN sites attached to the network
of a single provider consisting of multiple AS'es
4. Cooperating SPs: VPN sites attached to networks of different
providers that cooperate with each other to provide VPN service
As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):
1. Requirements and framework for Layer 3 VPNs
2. Solution documents for each approach listed above (including
applicability statements)
3. MIB definitions for each approach
4. Security mechanisms for each approach
As a general rule, the WG will not create new protocols, but will provide
functional requirements for extensions of the existing protocols that will
be discussed in the protocol-specific WGs. L3VPN WG will review proposed
protocol extensions for L3VPNs before they are recommended to appropriate
protocol-specific WGs.
Multicast and QoS support are excluded from the charter at this time.
They may be considered for inclusion in an updated charter
at a later time. Future work items may also include OAM support.
WG Milestones (optimistic):
Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit Generic Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info
(completed)
Dec 2003 Submit VPN Security Analysis to IESG for publication as Info
(draft-fang-ppvpn-security-framework-00)
Dec 2003 Submit BGP/MPLS VPNs specification and AS to IESG for
publication as PS
(draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
Dec 2003 Submit CE-based specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-ce-based-03)
(draft-declercq-ppvpn-ce-based-sol-00)
(draft-declercq-ppvpn-ce-based-as-01)
Dec 2003 Submit Virtual Router specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Jan 2004 Submit VPN MIB Textual Conventions to IESG for publication as PS
(draft-ietf-ppvpn-tc-mib-02)
Jan 2004 Submit MPLS/BGP VPN MIB to IESG for publication as PS
(draft-ietf-ppvpn-mpls-vpn-mib-05)
Jan 2004 Submit VR MIB to IESG for publication as PS
(draft-ietf-ppvpn-vr-mib-04)
Jan 2004 Submit BGP as an Auto-Discovery Mechanism for publication as PS.
(draft-ietf-ppvpn-bgpvpn-auto-05.txt)
March 2004 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-ipsec-2547-03)
March 2004 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-gre-ip-2547-02)
March 2004 Submit specification of BGP-MPLS VPN extension for IPv6 VPN to IESG for publication as PS
(draft-ietf-ppvpn-bgp-ipv6-vpn-03)
Path Maximum Transmission Unit Discovery (pmtud)
------------------------------------------------
Charter
Last Modified: 2003-06-06
Current Status: Proposed Working Group
Chair(s):
Matt Mathis <mathis@psc.edu>
TBD
Transport Area Directors(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing List (temporary):
General Discussion: mtu@psc.edu
Subscribe: majordomo@psc.edu with "subscribe mtu" in the body
Archive: http://www.psc.edu/~mathis/MTU/mbox.txt
(This is to be moved to the IETF as soon as chartered).
Description of Working Group:
The goal of the PMTUD working group is to specify a robust method for
determining the IP Maximum Transmission Unit supported over an
end-to-end path. This new method is expected to update most uses of
RFC1191 and RFC1981, the current standards track protocols for this
purpose. Various weakness in the current methods are documented in
RFC2923, and have proven to be a chronic impediment to the deployment
of new technologies that alter the path MTU, such as tunnels and new
types of link layers.
The proposed new method does not rely on ICMP or other messages from
the network. It finds the proper MTU by starting a connection using
relatively small packets (e.g. TCP segments) and searching upwards by
probing with progressively larger test packets (containing application
data). If a probe packet is successfully delivered, then the path MTU
is raised. The isolated loss of a probe packet (with or without an
ICMP can't fragment message) is treated as an indication of a MTU
limit, and not a congestion indicator.
The working group will specify the method for use in TCP, SCTP, and
will outline what is necessary to support the method in transports
such as DCCP. It will particularly describe the precise conditions
under which lost packets are not treated as congestion indications.
The work will pay particular attention to details that affect
robustness and security.
Path MTU discovery has the potential to interact with many other parts
of the Internet, including all link, transport, encapsulation and
tunnel protocols. Thereforethis working group will particularly
encourage input from a wide cross section of the IETF to help to
maximize the robustness of path MTU discovery in the presence of
pathological behaviors from other components.
Input draft:
Packetization Layer Path MTU Discovery
draft-mathis-plpmtud-00.txt
Goals and Milestones:
Jul 03 Reorganized Internet-Draft. Solicit implementation and field experience.
Dec 03 Update Internet-Draft incorporating implementers experience,
actively solicit input from stakeholders - all communities that might
be affected by changing PMTUD.
Feb 04 Submit completed Internet-draft and a PMTUD MIB draft for
Proposed Standard.
Layer 2 Virtual Private Networks (l2vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-17
Current Status: Proposed Working Group
Chairs: <under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Russ Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: l2vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.html
Description of Working Group:
Alex is the routing advisor.
Russ is the security advisor.
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).
The WG is responsible for standardization of the following solutions:
1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
across an IP and an MPLS-enabled IP network, allowing standard
Ethernet devices communicate with each other as if they were
connected to a common LAN segment.
2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
point-to-point Ethernet) across an IP and an MPLS-enabled IP network.
3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
IP network, allowing standard IP devices to communicate with each
other as if they were connected to a common LAN segment or a point-
to-point circuit.
The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)
As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
L2VPN WG will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.
The WG will work on the following items. Adding new work items
will require rechartering.
1. Discovery of PEs participating in L2 service, and
topology of required connectivity
2. Signaling of l2vpn related information for the purpose of
setup and maintenance of l2vpn circuits. As much as possible
PWE3 signaling procedures should be used
3. Solution documents (providing the framework for a specific
solution, should include info on how discovery, signaling,
and encaps work together, include security, AS as a separate
document)
4. MIBs
5. L2VPN-specific OAM extensions--extensions to existing OAM
solutions for VPLS, VPWS, and IP-only L2VPNs.
Where necessary, the WG will coordinate its activities with IEEE 802.1
Milestones (optimistic):
JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC
JUL 2003 Submit L2 framework to IESG for publication as Informational RFC
JUL 2003 Identify VPLS and VPWS solutions for the WG
AUG 2003 Submit an I-D describing MIB for VPLS
AUG 2003 Submit an I-D describing MIB for VPWS
AUG 2003 Submit an I-D on OAM for VPLS
AUG 2003 Submit an I-D on OAM for VPWS
DEC 2003 Submit VPLS solution documents to IESG
DEC 2003 Submit VPWS solution documents to IESG
JAN 2004 Submit IP-only L2VPN solution documents to IESG
FEB 2004 Submit MIB for VPLS to IESG
MAR 2004 Submit OAM for VPWS to IESG
APR 2004 Submit OAM for IP L2VPN to IESG