[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for August 21, 2003 Telechat, 2nd Draft
-----------------------------------------------------------------------------------------
Dear IESG Members:
The Secretariat, after conversing with Harald, thinks that the "alternate"
agenda and package are developed enough that the old-style agenda and
package does not have any additional value. Unless someone objects
strenuously, only the "alternate" version will be sent out for the
forthcoming telechat. Needless to say, your comments and suggestions for
improving the "alternate" agenda and package are always welcome.
Regards
The IETF Secretariat
------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the August 21, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
o Review of Action Items
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-dnsext-delegation-signer-15.txt
Delegation Signer Resource Record (Proposed Standard) - 1 of 3
Note: Please start last call.
Token: Thomas Narten
o draft-ietf-ospf-dc-06.txt
Detecting Inactive Neighbors over OSPF Demand Circuits (Proposed
Standard) - 2 of 3
Note: Note to IESG: some editorial comments are already noted in the
tracker in my 2003-07-02 comment; I put this on the agenda to flush out
IESG opinion so that there's only one rev needed.
Token: Bill Fenner
o draft-ietf-hubmib-power-ethernet-mib-08.txt
Power Ethernet MIB (Proposed Standard) - 3 of 3
Note: Responsible: Bert
Token: Bert Wijnen
2.1.2 Returning Item
o draft-ietf-sigtran-sctp-mib-10.txt
Stream Control Transmission Protocol Management Information Base
(Proposed Standard) - 1 of 2
Note: DISCUSSes believed to be cleared
Token: Jon Peterson
o draft-ietf-sigtran-security-03.txt
Security Considerations for SIGTRAN Protocols (Proposed Standard) - 2
of 2
Note: DISCUSSes believed to be cleared.
Token: Jon Peterson
2.2 Individual Submissions
2.2.1 New Item
o draft-rharrison-ldap-intermediate-resp-01.txt
The Lightweight Directory Access Protocol (LDAP) Intermediate Response
Message (Proposed Standard) - 1 of 1
Token: Hardie, Ted
2.2.2 Returning Item
o draft-vaudreuil-mdnbis-05.txt
Message Disposition Notification (Draft Standard) - 1 of 1
Note: Responsible: freed
Token: Ned Freed
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-forces-framework-08.txt
Forwarding and Control Element Separation (ForCES) Framework
(Informational) - 1 of 1
Token: Alex Zinin
3.1.2 Returning Item
o draft-ietf-isis-traffic-05.txt
IS-IS extensions for Traffic Engineering (Informational) - 1 of 2
Note: Responsible: Author
Token: Alex Zinin
o draft-ietf-forces-requirements-10.txt
Requirements for Separation of IP Control and Forwarding
(Informational) - 2 of 2
Note: Responsible: AD
Token: Alex Zinin
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-weltman-ldapv3-auth-response-09.txt
LDAP Authorization Identity Request and Response Controls
(Informational) - 1 of 1
Token: Ted Hardie
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
o draft-foster-mgcp-returncodes-03.txt
Media Gateway Control Protocol (MGCP) Return Code Usage (Informational)
- 1 of 1
Token: Jon Peterson
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Mobility for IPv6 - 1 of 1
Token: Thomas
4.1.2 Proposed for Approval
o Mobility for IPv4 - 1 of 2
Token: Thomas
o Centralized Conferencing - 2 of 2
Token: Allison
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o ADSL MIB - 1 of 1
Token: Bert
4.2.2 Proposed for Approval
o IP over Cable Data Network - 1 of 1
Token: Bert
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the August 21, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, August 21, 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
Steve Bellovin---Will call in
Randy Bush---Regrets
Michelle Cotton---Will call in
Leslie Daigle---Regrets
Bill Fenner---Will call in
Ned Freed---Regrets
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
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Dinara Suleymanova---Regrets
Amy Vezza---Will call in
Margaret Wasserman---Will call in
Bert Wijnen---Will call in
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 participants 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
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the August 7, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Michelle Cotton / ICANN
Bill Fenner / AT&T
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Thomas Narten / IBM
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Natalia Syracuse / IETF Secretariat
Amy Vezza / IETF Secretariat
Margaret Wasserman / Wind River
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Marcia Beaulieu / IETF Secretariat
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Ned Freed / Sun Microsystems
Jacqueline Hargest / IETF Secretariat
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Dinara Suleymanova / IETF Secretariat
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the July 10, 2003 Teleconference were approved. The
Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Bert Wijnen to document process of how the IESG goes about asking
architectural questions of the IAB.
o Ted Hardie to send the Secretariat a message to forward to the RFC
Editor indicating that the Do Not Publish note that was originally
created for draft-paskin-doi-uri-03.txt also applies to
draft-paskin-doi-uri-04.txt.
DELETED:
NONE
IN PROGRESS:
o Allison Mankin to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Thomas Narten to write (or cause to be written) a draft on "how to
get to Draft."
o Thomas Narten to contact Cablelabs to discuss formal relationship
with IAB.
o Steve Bellovin to write RFC re: TCP MD5 option.
o Randy Bush and Ned Freed to finish ID on Clarifying when Standards
Track Documents may Refer Normatively to Documents at a Lower Level.
o Alex Zinin to send proposal and justification for interim document
review.
o Steve Bellovin to propose a different document classification than
the current info/proposed/etc.
o Alex Zinin to phrase a question to RTG and OPS Area Directorates
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:
o Harald Alvestrand to send text of Tony Hain appeal to the IETF
Secretariat. The Secretariat will post the appeal on the "Appeals
submitted to the IESG" Web page.
o Bert Wijnen will send the document on how the IESG goes about asking
architectural questions of the IAB to the Secretariat. The Secretariat
will post the document on the IETF Web site, and will create a link to
the document on the internal IESG Web page.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-pkix-wlan-extns-04.txt - 1 of 9
Certificate Extensions and Attributes Supporting Authentication in PPP
and Wireless LAN (Proposed Standard)
Token: Steve Bellovin
The document remains under discussion by the IESG in order to resolve
points raised by Ted Hardie.*
o Set of five documents - 2 of 9
- draft-ietf-impp-im-03.txt
Common Profile for Instant Messaging (CPIM) (Proposed Standard)
- draft-ietf-impp-cpim-msgfmt-08.txt
Common Presence and Instant Messaging: Message Format (Proposed
Standard)
- draft-ietf-impp-cpim-pidf-08.txt
Presence Information Data Format (PIDF) (Proposed Standard)
- draft-ietf-impp-pres-03.txt
Common Profile for Presence (CPP) (Proposed Standard)
- draft-ietf-impp-srv-03.txt
Address Resolution for Instant Messaging and Presence (Proposed
Standard)
Token: Ted Hardie
The documents remain under discussion by the IESG in order to resolve
points raised by Bill Fenner and Thomas Narten.*
o draft-ietf-dhc-isnsoption-08.txt - 3 of 9
The IPv4 DHCP Options for the Internet Storage Name Service
(Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin and Alex Zinin.*
o draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt - 4 of 9
IPv6 Prefix Options for DHCPv6 (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to resolve
points raised by Thomas Narten.*
o draft-ietf-secsh-dns-04.txt - 5 of 9
Using DNS to securely publish SSH key fingerprints (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve
points raised by Randy Bush and Thomas Narten.*
o draft-ietf-ipsec-ciph-aes-ctr-05.txt- 6 of 9
Using AES Counter Mode With IPsec ESP (Proposed Standard)
Token: Steve Bellovin
The document was approved by the IESG. The Secretariat will
send a working group submission Protocol Action Announcement.
o draft-ietf-smime-camellia-04.txt - 7 of 9
Use of the Camellia Encryption Algorithm in CMS (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve
points raised by Bert Wijnen.*
o draft-ietf-ipv6-flow-label-07.txt - 8 of 9
IPv6 Flow Label Specification (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to resolve
points raised by Jon Peterson and Alex Zinin.*
o draft-schryver-pppext-iana-01.txt - 9 of 9
IANA Considerations for the Point-to-Point Protocol (PPP) (BCP)
Token: Thomas Narten
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
2.1.2 Returning Item
o draft-ietf-policy-qos-device-info-model-10.txt - 1 of 4
Information Model for Describing Network Device QoS Datapath Mechanisms
(Proposed Standard)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve
points raised by Allison Mankin.*
o draft-ietf-policy-qos-info-model-05.txt - 2 of 4
Policy QoS Information Model (Proposed Standard)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve
points raised by Russ Housley.*
o draft-ietf-kink-kink-05.txt - 3 of 4
Kerberized Internet Negotiation of Keys (KINK) (Proposed Standard)
Token: Steve Bellovin
The document remains under discussion by the IESG in order to resolve
points raised by Randy Bush.*
o Set of two documents - 4 of 4
- draft-ietf-ips-fcip-slp-07.txt
Finding FCIP Entities Using SLPv2 (Proposed Standard)
- draft-ietf-ips-iscsi-slp-06.txt
Finding iSCSI Targets and Name Servers Using SLP (Proposed
Standard)
Token: Allison Mankin
The documents remain under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Ted Hardie, and Thomas Narten.*
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o draft-mealling-iana-xmlns-registry-05.txt - 1 of 3
The IETF XML Registry (BCP)
Token: Ted Hardie
The document remains under discussion by the IESG in order to
resolve points raised by Russ Housley and Thomas Narten.*
o Set of four documents - 2 of 3
- draft-zeilenga-ldap-collective-08.txt
Collective Attributes in LDAP (Proposed Standard)
- draft-zeilenga-ldap-subentry-07.txt
Subentries in LDAP (Proposed Standard)
- draft-legg-ldap-gser-abnf-07.txt
Common Elements of GSER Encodings (Informational)
- draft-legg-ldap-gser-04.txt
Generic String Encoding Rules for ASN.1 Types (Proposed Standard)
Token: Ted Hardie
The documents were approved by the IESG. The Secretariat will send
an individual submission Protocol Action Announcement.
o draft-yergeau-rfc2279bis-05.txt - 3 of 3
UTF-8, a transformation format of ISO 10646 (Standard)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send
an individual submission Protocol Action Announcement.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt - 1 of 4
An analysis of IPv6 anycast (Informational)
Token: Thomas Narten
The document remains under discussion by the IESG.*
o draft-ietf-ieprep-ets-general-03.txt - 2 of 4
General Requirements for Emergency Telecommunication Service
(Informational)
Token: Jon Peterson
The document remains under discussion by the IESG.*
o draft-ietf-xmldsig-xpf2-00.txt - 3 of 4
XML-Signature XPath Filter 2.0 (Informational)
Token: Russ Housley
The document remains under discussion by the IESG.*
o draft-ietf-dhc-unused-optioncodes-05.txt - 4 of 4
Unused DHCP Option Codes (Informational)
Token: Thomas Narten
The document was approved by the IESG pending an RFC Editor
Note to be prepared by Thomas Narten. The Secretariat will send
a working group submission Document Action Announcement that
includes the RFC Editor Note.
3.1.2 Returning Item
o draft-ietf-xmldsig-xc14n-01.txt - 1 of 2
Exclusive XML Canonicalization, Version 1.0 (Informational)
Token: Russ Housley
The document remains under discussion by the IESG in order to
resolve points raised by Randy Bush and Russ Housley, who were
not present at the teleconference.
o draft-ietf-pkix-pr-tsa-05.txt - 2 of 2
Policy Requirements for Time-Stamping Authorities (Informational)
Token: Russ Housley
The document was approved by the IESG. The Secretariat will send
a working group submission Document Action Announcement.
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-fink-6bone-phaseout-04.txt - 1 of 1
6bone (IPv6 Testing Address Allocation) Phaseout (Informational)
Token: Randy Bush
The document was approved by the IESG pending confirmation from
the shepherding AD, Randy Bush, who was not present at the
teleconference.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
o draft-shah-extreme-eaps-03.txt - 1 of 1
Extreme Networks' Ethernet Automatic Protection Switching (EAPS),
Version 1 (Informational)
Token: Thomas Narten
The IESG has no problem with the RFC Editor publishing this
document. The Secretariat will send a standard "no problem"
message to the RFC Editor.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Mobility for IPv4 - 1 of 2
Token: Thomas Narten
The IESG approved the draft WG charter for IETF review. The
Secretariat will send a WG Review announcement, with copies to
new-work@ietf.org and to the proposed WG chairs. The Secretariat
will place the WG on the agenda for the next IESG teleconference.
o Centralized Conferencing - 2 of 2
Token: Allison Mankin
The IESG approved the draft WG charter for IETF review. The
Secretariat will send a WG Review announcement, with copies to
new-work@ietf.org and to the proposed WG chairs. The Secretariat
will place the WG on the agenda for the next IESG teleconference.
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Multicast Security - 1 of 3
Token: Russ Housley
The IESG approved the modifications to the charter. The Secretariat
will send a WG Action: RECHARTER announcement.
o IP over Cable Data Network - 2 of 3
Token: Bert Wijnen
The IESG decided to proceed with IETF review of the revised charter.
The Secretariat will send a WG Review: Recharter announcement, with
copies to new-work@ietf.org and to the WG chairs. The Secretariat
will place the WG on the agenda for the next IESG teleconference.
o AToM MIB - 3 of 3
Token: Bert Wijnen
The IESG approved the modifications to the charter. The Secretariat
will send a WG Action: RECHARTER announcement.
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
o Review of boxes and arrows (Bert Wijnen)
(discussed)
7. Management Issues
o IESG architechtural questions to IAB (Bert Wijnen)
(discussed)
o Procedures on DNP statements (Harald Alvestrand)
(discussed)
----------------------------------------
* Please see the ID Tracker
(https://datatracker.ietf.org/public/pidtracker.cgi) for details
on documents that are under discussion by the IESG.
1. Administrivia
o Review of Action Items
OUTSTANDING TASKS
Last updated: August 12, 2003
IP o Allison Mankin to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Thomas Narten to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas Narten to contact Cablelabs to discuss formal relationship with IAB
IP o Steve Bellovin to write RFC re: TCP MD5 option
IP o Randy Bush and Ned Freed to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex Zinin to send proposal and justification for interim document review.
IP o Steve Bellovin to propose a different document classification than the current
info/proposed/etc.
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 Harald Alvestrand to send text of Tony Hain appeal to the IETF Secretariat. The
Secretariat will post the appeal on the "Appeals submitted to the IESG" Web page.
IP o Bert Wijnen will send the document on how the IESG goes about asking architectural
questions of the IAB to the Secretariat. The Secretariat will post the document on the
internal IESG Web page.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 3
o draft-ietf-dnsext-delegation-signer-15.txt
Delegation Signer Resource Record (Proposed Standard)
Note: Please start last call.
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-delegation-signer -
Delegation Signer Resource Record
--------
Last Call to expire on: 2003-07-24
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <namedroppers@ops.ietf.org>
Subject: Protocol Action: 'Delegation Signer Resource Record' to
Proposed Standard
The IESG has approved the Internet-Draft 'Delegation Signer Resource
Record' <draft-ietf-dnsext-delegation-signer-15.txt> as a Proposed
Standard. This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Thomas Narten and Margaret Wasserman.
Technical Summary
This document defines the Delegation Signer resource record (RR),
which replaces the DNSSEC KEY record chain of trust defined in the
original RFC 2535 DNSSEC protocol. The DS RR resides only at the
parent and identifies (and signs) the key(s) that the child uses to
self-sign its own KEY RRset. In contrast, the previously-used method,
which relied on a DNSSEC KEY record chain of trust, had a number of
operational issues, including that the same data was located in
different places within the DNS (parent and child), which led to
inconsistencies in practice, difficulties in updating signatures in
some cases, and complexity in resolvers. The DS RR is an explicit
statement about the delegation, rather than relying on inference.
Delegation Signer changes the semantics of some previously defined
DNSSEC operations and is not backwards compatible with RFC 2535.
Working Group Summary
There was consensus in the WG for this document.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten and Erik
Nordmark.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 2 of 3
o draft-ietf-ospf-dc-06.txt
Detecting Inactive Neighbors over OSPF Demand Circuits (Proposed
Standard)
Note: Note to IESG: some editorial comments are already noted in the
tracker in my 2003-07-02 comment; I put this on the agenda to flush out
IESG opinion so that there's only one rev needed.
Token: Bill Fenner
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-ospf-dc -
Detecting Inactive Neighbors over OSPF Demand Circuits
--------
Last Call to expire on: 2003-06-10
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <OSPF@PEACH.EASE.LSOFT.COM>
Subject: Protocol Action: 'Detecting Inactive Neighbors over OSPF
Demand Circuits' to Proposed Standard
The IESG has approved the Internet-Draft 'Detecting Inactive Neighbors over
OSPF Demand Circuits' <draft-ietf-ospf-dc-06.txt> as a Proposed Standard.
This document is the product of the Open Shortest Path First IGP Working
Group.
The IESG contact persons are Bill Fenner and Alex Zinin.
Technical Summary
The Demand Circuit Extension for OSPF (RFC 1793) reduces routing protocol
overhead on demand circuit links by eliminating Hello messages over such
links. This prevents the link from being kept alive simply by routing
protocol traffic, but also prevents the detection of a dead neighbor over
a live demand circuit. Detecting Inactive Neighbors over OSPF Demand
Circuits introduces a mechanism which probes the liveness of the neighbor
on a demand circuit only when other traffic is flowing and/or with packets
that do not count towards keeping the link up. In this way, neighbor
liveness may be detected while retaining the on-demand nature of the
circuit.
Working Group Summary
There was consensus in the OSPF Working Group on this specification.
Protocol Quality
The protocol was reviewed for the IESG by Bill Fenner. There are
two implementations.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 3
o draft-ietf-hubmib-power-ethernet-mib-08.txt
Power Ethernet MIB (Proposed Standard)
Note: Responsible: Bert
Token: Bert Wijnen
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-hubmib-power-ethernet-mib -
Power Ethernet MIB
--------
Last Call to expire on: 2003-08-12
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 [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <hubmib@ietf.org>
Subject: Protocol Action: 'Power Ethernet MIB' to Proposed
Standard
The IESG has approved the Internet-Draft 'Power Ethernet MIB'
<draft-ietf-hubmib-power-ethernet-mib-08.txt> as a Proposed Standard.
This document is the product of the Ethernet Interfaces and Hub MIB
Working Group. The IESG contact persons are Randy Bush and Bert Wijnen.
Technical Summary
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
The document proposes an extension to the Ethernet-like Interfaces
MIB with a set of objects for managing a Power Source Equipment (PSE).
Working Group Summary
There is Working Group Consensus to publish the above document as a
Proposed Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen and
Mike Heard.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 2
o draft-ietf-sigtran-sctp-mib-10.txt
Stream Control Transmission Protocol Management Information Base
(Proposed Standard)
Note: DISCUSSes believed to be cleared
Token: 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-sigtran-sctp-mib - Stream Control
Transmission Protocol Management Information Base to Proposed
Standard
--------
Last Call to expire on: 2003-4-28
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ XX] [ ] [ X ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=========
Steve:
This is very close to being a DISCUSS. The read-sensitive objects also
have privacy implications, i.e., they disclose who is connecting to
what hosts. This is important from a perspective of preventing traffic
analysis, and also to protect individual privacy.
COMMENTS:
=========
Ted:
Notes:
The Status of the memo cites it as an individual submission,
but the document name implies it is a sigtran working group
submission.
3.1.2
Would it make sense to eliminate "other" as a valid
entry for the SCTP RTO mechanism (leaving only vanj),
and note that later specifications may define other
values? Leaving "other" for future use doesn't seem
very likely to work well; it is meaningless now and under-
specified in the future.
4 (page 20)
So, whatever DNS name is received at initialization
time is stored in sctpAssocRemHostName. First,
that notation (0..115) indicates a 255 octet field?
The authors might also want to review the recent
thread on namedroppers:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00964.html
and decide whether they need to describe more fully whether this
stored format is
the uncompressed wire format or some other format.
Russ:
Spell out first use of PSTN and SNMP.
^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: Stream Control Transmission Protocol
Management Information Base to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Stream Control Transmission
Protocol Management Information Base'
<draft-ietf-sigtran-sctp-mib-09.txt> as a Proposed Standard. This
document is the product of the Signaling Transport Working Group. The
IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connectionless packet
network such as IP. It is designed to transport PSTN signaling
messages over the connectionless packet network, but is capable of
broader applications.
This memo defines the Management Information Base (MIB) module which
describes the minimum set of objects needed to manage the
implementation of the SCTP.
There is one existing nit that we need to fix in an RFC-editor note -
namely that the SIZE restriction of 115 octets on the
sctpAssocRemHostName needs to be removed (should be 255).
Working Group Summary
The SIGTRAN WG and the TSVWG WG supported this document.
Protocol Quality
This specification was reviewed for the IESG by Bert Wijnen and Jon
Peterson. Further MIB review was performed by the participants of
the mreview mailing list.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 2
o draft-ietf-sigtran-security-03.txt
Security Considerations for SIGTRAN Protocols (Proposed Standard)
Note: DISCUSSes believed to be cleared.
Token: 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-sigtran-security - Security
Considerations for SIGTRAN Protocols to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ X ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Ted:
DISCUSS comment:
Section 6. on TLS usage notes that SIGTRAN protocols use the same
port number and payload protocol identifier when run over TLS, and
that a session upgrade procedure has to be used to initiate the TLS
based
communication. There are, however, no pointers to a specification for
this (even an example). I think _something_ is required here, because
the consequences of doing an upgrade here may not be obvious.
RFC 3436 notes in section 6.2, for example:
TLS requires that the underlying transport delivers TLS records
in strict sequence. Thus, the 'unordered delivery' feature of
SCTP MUST NOT be used on streams which are used for TLS based
user data transmission. For the same reason, TLS records
delivered to SCTP for transmission MUST NOT have limited
lifetimes.
If you UPGRADE, in other words, there are consequences to how you use
SCTP that you may need to take into account. If these don't apply to
SIGTRAN, great, but a worked example or additional text on the
UPGRADE scenario would really help.
Note:
Section 3., "Security in Telephone Networks" seems to report things
like "the trusted network principle" without any comment on how
valid these principles are. Purely as a personal note, I would find
some more cynicism here comforting. This does not, of course,
change the specification in any substantive way.
Russ:
Please make these changes throughout the document:
- change "man in the middle" to "man-in-the-middle"
- change "certificate authority" to "certification authority"
- change "IPSEC" to "IPsec"
- change "root CA" to "trust anchor"
Section 5, 3rd paragraph says: "These nodes MUST support IKE ..."
Are these nodes the ones that implement ESP, or just the ones that
implement ESP in tunnel mode. It needs to be clear which
implementations MUST support IKE.
Section 5, 5th paragraph says: "IKE negotiators SHOULD use
pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures." What are these
checks? At a minimum include a normative reference to RFC 3280. If
on-line checking is anticipated, then a reference to RFC 2560 may be
in order.
Section 5, 7th paragraph seems to use the terms security
association (SA), session, and connection interchangeably. I think
that security association is the proper term.
Bert:
> Yes No-Objection Discuss * Abstain
> Bert Wijnen [ ] [ ] [ X ] [ ]
On page 9 I read (2nd para):
Note that IPSec is considerably less flexible than TLS when it comes
to configuring root CAs. Since use of Port identifiers is prohibited
within IKE Phase 1, within IPSec it is not possible to uniquely
configure trusted root CAs for each application individually; the
>> same policy must be used for all applications. This implies, for
>> example, that a root CA trusted for use with a SIGTRAN protocol must
>> also be trusted to protect SNMP. These restrictions can be awkward at
best.
I have marked a few lines with >>
Can someone explain to me how it "implies" or "follows that the
SIGTRAN protocol must also be trusted to protect SNMP. I guess I cannot
find the proper context as to how SNMP plays a role here.
-----------------
Guess it would then be better to change:
This implies, for
example, that a root CA trusted for use with a SIGTRAN protocol must
also be trusted to protect SNMP.
Into something aka:
This implies that a
root CA trusted for use with a SIGTRAN protocol must also be trusted
to protect other protocols (for example SNMP or xxx).
My worry is that current text seems to imply (or at least can easily be
read) that SNMP is a specific issue here.
But if your explanatory text can somehow be added as well, it would
make it even more understandable for less-security-geeked people like
myself :-)
Can do that with RFC-Editor note as far as I cam concerned.
Bert
COMMENTS:
=========
Steve:
Nit: The correct spelling is IPsec, not IPSec.
Section 8 speaks of certificate authorities. Since SIGTRAN
connections are by prearrangement among parties with a pre-existing
business arrangement, there's no need for a CA. One party can issue
a certificate to the other, or each can use self-signed
certificates. Regardless of where the certificate comes from
(including a conventional CA), knowledge of the expected certificate
chain is a necessary part of the security provisioning.
Both of these can be fixed with an RFC editor's note.
Steve:
>> Bert Wijnen [ ] [ ] [ X ] [ ]
>
>On page 9 I read (2nd para):
> Note that IPSec is considerably less flexible than TLS when it comes
> to configuring root CAs. Since use of Port identifiers is prohibited
> within IKE Phase 1, within IPSec it is not possible to uniquely
> configure trusted root CAs for each application individually; the
>>> same policy must be used for all applications. This implies, for
>>> example, that a root CA trusted for use with a SIGTRAN protocol must
>>> also be trusted to protect SNMP. These restrictions can be awkward at
> best.
>
>I have marked a few lines with >>
>Can someone explain to me how it "implies" or "follows that the
>SIGTRAN protocol must also be trusted to protect SNMP. I guess I cannot
>find the proper context as to how SNMP plays a role here.
>
It's not SNMP per se, it's any service.
There are no port numbers specified in an IKE Phase 1 exchange, which
means that given a Phase 1 security association, you don't know what
it's trusted for. You can only grant trust based on secure
identification of the remote party, which is a <root CA,certificate>
pair. Suppose I want to talk secure SIGTRAN to you over IPsec, and
you're willing to permit this. We then negotiate a Phase 1 SA. I now
use that Phase 1 to negotiate a Phase 2 SA that specifies UDP port 161.
You don't know at this point that the Phase 1 SA was only for SIGTRAN.
Oops.
^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.
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 1 of 1
o draft-rharrison-ldap-intermediate-resp-01.txt
The Lightweight Directory Access Protocol (LDAP) Intermediate Response
Message (Proposed Standard)
Token: Hardie, Ted
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-rharrison-ldap-intermediate-resp - The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message to Proposed Standard
--------
Last Call to expire on: 2003-6-27
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 [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
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>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The Lightweight
Directory Access Protocol (LDAP) Intermediate Response Message'
<draft-rharrison-ldap-intermediate-resp-01.txt> as a Proposed Standard.
This document is an individual submission.
The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
This document defines and describes the IntermediateResponse
message, a general mechanism for defining single-request/multiple-response
operations in LDAP. The IntermediateResponse message is
defined in a way that maintains the protocol behavior of existing
LDAP operations. This message is intended to be used in conjunction
with the LDAP ExtendedRequest and ExtendedResponse to define new
single-request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that
requires them to return intermediate response information.
Working Group Summary
This was an individual submission.
Protocol Quality
This was reviewed by the LDAP directorate and Ted Hardie for the IESG.
2. Protocol Actions
2.2 Individual Submissions
2.2.2 Returning Item - 1 of 1
o draft-vaudreuil-mdnbis-05.txt
Message Disposition Notification (Draft Standard)
Note: Responsible: freed
Token: Ned Freed
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-vaudreuil-mdnbis - Message Disposition
Notification to Draft Standard
--------
Last Call to expire on: 2002-12-23
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ X ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Bill:
The "parameter" ABNF in the document body is missing a '"," value'
sequence (which is present in the collected grammar, but not in
the first definition.)
- parameter = attribute "=" importance *("," value)
+ parameter = attribute "=" importance "," value *("," value)
The "-" disease bit the mdn-gateway-field definition:
- mdn-gateway field = "MDN-Gateway" ":" mta-name-type ";" mta-name
+ mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
AFAIK, single-quotes are not quotes in ABNF. (This needs to get
fixed in both the document body and the collected ABNF).
disposition-field =
"Disposition" ":" disposition-mode ";"
disposition-type
- [ '/' disposition-modifier
+ [ "/" disposition-modifier
*( "," disposition-modifier ) ]
More "-" disease:
- should follow the "X-", (e.g. "X Foomail
+ should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").
The mdn-request-header definition in the collected ABNF says that the
mailbox list is seperated by periods; the definition in the document
body says commas. I selected commas because that is consistent with
the # notation from the original spec.
mdn-request-header =
"Disposition-Notification-To" ":"
- mailbox *("." mailbox)
+ mailbox *("," mailbox)
The disposition-type and disposition-modifier in the collected ABNF
disagree with the versions in the body of the document. I made them
the same as the definitions in the body, but this needs to be double-checked
by someone who knows the intent of the changes.
disposition-type = "displayed"
+ / "deleted"
/ "dispatched"
/ "processed"
- / "deleted"
- / "denied"
- / "failed"
- disposition-modifier = disposition-modifier-extension
+ disposition-modifier = "error" / disposition-modifier-extension
original-message-id-field got hit by "-" disease:
- original-message id
+ original-message-id-field = "Original-Message-ID" ":" msg-id
I may have missed some of the places where the editing damaged the original
RFC text. http://irg.attlabs.net/~fenner/2298bis.html might be useful in
trying to find other problems.
Steve:
>> This section:
>
>> The comparison of the addresses should be done using only the addr-
>> spec (local-part "@" domain) portion, excluding any phrase and route.
>> The comparison MUST be case-sensitive for the local-part and case-
>> insensitive for the domain part.
>
>> has security implications -- a source-routed address is not necessarily
>> the same as the absolute address with the same name.
>
>Um, well, actually, we have been saying that it is supposed to be the same,
>going back as far as RFC 1123. A source route is supposed to be merely a
>routing indicator that may or may not even be honored, it is not supposed to b
>e
>a namespace qualifier.
>
>While I've seen considerable unevenness in support for source routes over the
>years, I can't recall a case where I found one being used to qualify addresses
>as belonging to a separate namespace. (The same cannot be said of % hacks or !
>paths, of course -- they were commonly used for that. And don't get me started
>about X.400...)
From an architectural perspective, you're absolutely right. But I'm
talking about this from a security and privacy perspective, and the bad
guys break the rules. This is just one way to accomplish the privacy
violation described below.
>
>I guess I have no real problem with noting this as a possible issue, but
>I really think it is an entirely academic one at this point.
>
>> More generally, there are privacy issues with MDN -- the recipient may
>> not want the sender to know when he or she is receiving or reading
>> email. The draft implicitly recognizes that, in the rules requiring
>> explicit consent for MDNs. That broader issue isn't mentioned in the
>> Security Considerations, and should be -- my example is just one
>> instance of a privacy problem.
>
>OK, I'll if I can't work up some text.
>
> Ned
Russ:
In section 6.3, non-repudiation with proof of origin and non-repudiation
with proof of delivery are quite different. This section is trying to say
that non-repudiation with proof of delivery is not provided by MDN. I
think the section should open with an assertion to this fact. Further, a
pointer to a solution might help the reader. I suggest the signed receipt
feature described in RFC 2634.
Ted:
The change control section indicates that "denied" and
"failed" were deleted, but they are still in the collected
grammar in section 7.
original-message id
in the same section seems to be missing an operator.
Is the advice in section 8.3, paragraph 2 also applicable
to cases where a list rewrites the From: field?
Should we specify the code points allowed for section
9.1, c), or is "graphic US-ASCII characters" enough?
Are all references normative?
Notes:
the examples use non example.com style fqdns.
The risk of "mail bombing" is noted in 2.1, but not listed in the
security considerations.
Is the advice in 3.2.1 noting that the DNS name of the particular
instance of the MUA should be in the Reporting-UA field
still valid?
There is a missing closing paren on (e.g. "X Foomail
at the end of section 3.3.
Steve:
This section:
The comparison of the addresses should be done using only the addr-
spec (local-part "@" domain) portion, excluding any phrase and route.
The comparison MUST be case-sensitive for the local-part and case-
insensitive for the domain part.
has security implications -- a source-routed address is not necessarily
the same as the absolute address with the same name.
More generally, there are privacy issues with MDN -- the recipient may
not want the sender to know when he or she is receiving or reading
email. The draft implicitly recognizes that, in the rules requiring
explicit consent for MDNs. That broader issue isn't mentioned in the
Security Considerations, and should be -- my example is just one
instance of a privacy problem.
COMMENTS:
=========
Bert:
Oh well ... this ID-NITs byte us again:
- Many lines are beyond column 72, many pages are too long.
Summary:
-: 430 lines longer than 72 characters, max 76
-: 32 pages longer than 58 lines, max 61 lines
- Example on page 13:
Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
Should be something at example.com, no?
- Same for the example on page 27
- References not split in normative and informative
Other nits:
- bottom page 18. Is it just a closing ) that is missing, or more text?
It says: should follow the "X-", (e.g. "X Foomail
Ned:
> > Bert Wijnen [ ] [ X ] [ ] [ ]
> Oh well ... this ID-NITs byte us again:
> - Many lines are beyond column 72, many pages are too long.
> Summary:
> -: 430 lines longer than 72 characters, max 76
> -: 32 pages longer than 58 lines, max 61 lines
This I regard as being in the RFC Editor's baliwick.
> - Example on page 13:
> Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
> Should be something at example.com, no?
Yep. I'll fix them in an RFC Editor note.
> - Same for the example on page 27
> - References not split in normative and informative
They are all normative, so this is an easy fix. A couple of entry updates are
needed since three of them are now RFCs.
> Other nits:
> - bottom page 18. Is it just a closing ) that is missing, or more text?
> It says: should follow the "X-", (e.g. "X Foomail
It is supposed to read (e.g. "X-Foomail-fratzed"). This is unchanged from
RFC 2298.
Ned:
> >Steve Bellovin [ ] [ ] [ X ] [ ]
> This section:
> The comparison of the addresses should be done using only the addr-
> spec (local-part "@" domain) portion, excluding any phrase and route.
> The comparison MUST be case-sensitive for the local-part and case-
> insensitive for the domain part.
> has security implications -- a source-routed address is not necessarily
> the same as the absolute address with the same name.
Um, well, actually, we have been saying that it is supposed to be the same,
going back as far as RFC 1123. A source route is supposed to be merely a
routing indicator that may or may not even be honored, it is not supposed to be
a namespace qualifier.
While I've seen considerable unevenness in support for source routes over the
years, I can't recall a case where I found one being used to qualify addresses
as belonging to a separate namespace. (The same cannot be said of % hacks or !
paths, of course -- they were commonly used for that. And don't get me started
about X.400...)
I guess I have no real problem with noting this as a possible issue, but
I really think it is an entirely academic one at this point.
> More generally, there are privacy issues with MDN -- the recipient may
> not want the sender to know when he or she is receiving or reading
> email. The draft implicitly recognizes that, in the rules requiring
> explicit consent for MDNs. That broader issue isn't mentioned in the
> Security Considerations, and should be -- my example is just one
> instance of a privacy problem.
OK, I'll if I can't work up some text.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Message Disposition Notification to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'Message Disposition
Notification' <draft-vaudreuil-mdnbis-03.txt> as a Draft Standard,
obsoleting RFC2298.
This document has been reviewed in the IETF but is not the product of
an IETF Working Group. The IESG contact persons are Ned Freed and
Ted Hardie.
Technical Summary
This memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. This
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting the privacy concerns that have often been
expressed when such functions have been discussed in the past.
Working Group Summary
This document was originally the product of the RECEIPT working group.
Review of the revised version was conducted largely in the context
of the VPIM working group.
Implementation Report
The implementation report for this specification may be found at:
http://www.ietf.org/IESG/Implementations/Mail-DSP-Implementation.txt
Protocol Quality
Ned Freed reviewed the document for the IESG.
RFC Editor Note
The IPR boilerplate is missing from the draft and needs to be added
before publication.
The title of section 11 should be changed from "references" to
"normative references".
The following references in the bibliography should be updated to
read:
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[RFC-DSN-SMTP] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format
for Delivery Status Notifications, RFC 3464, January 2003.
The example Reporting-UA line in section 3.2.1 should be changed to read:
Reporting-UA: pc.example.com; Foomail 97.1
The last paragraph of section 3.3 should be changed to read:
If an application developer does not wish to register the meanings of
such extension fields, "X-" fields may be used for this purpose. To
avoid name collisions, the name of the application implementation
should follow the "X-" (e.g. "X-Foomail-fratzed").
The example in section 8.3 should be changed to read:
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/example.com"
--RAA14128.773615765/example.com
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
Recipient <Joe_Recipient@example.com> with subject "First draft of
report" has been displayed. This is no guarantee that the message has
been read or understood.
--RAA14128.773615765/example.com
Content-type: message/disposition-notification
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@example.com
Final-Recipient: rfc822;Joe_Recipient@example.com
Original-Message-ID: <199509192301.23456@example.org>
Disposition: manual-action/MDN-sent-manually; displayed
--RAA14128.773615765/example.com
content-type: message/rfc822
[original message optionally goes here]
--RAA14128.773615765/example.com--
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 1
o draft-ietf-forces-framework-08.txt
Forwarding and Control Element Separation (ForCES) Framework
(Informational)
Token: Alex Zinin
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 2
o draft-ietf-isis-traffic-05.txt
IS-IS extensions for Traffic Engineering (Informational)
Note: Responsible: Author
Token: Alex Zinin
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 2
o draft-ietf-forces-requirements-10.txt
Requirements for Separation of IP Control and Forwarding
(Informational)
Note: Responsible: AD
Token: Alex Zinin
3. Document Actions
3.2 Individual Submissions Via AD
3.2.1 New Item - 1 of 1
o draft-weltman-ldapv3-auth-response-09.txt
LDAP Authorization Identity Request and Response Controls
(Informational)
Token: Ted Hardie
3.2.2 Returning Item
NONE
3.3.1 New Item
NONE
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.2 Returning Item - 1 of 1
o draft-foster-mgcp-returncodes-03.txt
Media Gateway Control Protocol (MGCP) Return Code Usage (Informational)
Token: Jon Peterson
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Mobility for IPv6 - 1 of 1
Token: Thomas
Mobility for IPv6 (mip6)
--------------------
Charter
Last Modified: 2003-08-15
Current Status: Proposed Working Group
Chair(s):
Internet Area Director(s):
Thomas Narten (narten@us.ibm.com)
Margaret Wasserman (mrw@windriver.com)
Internet Area Advisor:
Thomas Narten (narten@us.ibm.com)
Mailing Lists:
General Discussion: mip6@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
In Body: put subscribe in subject
Archive:
www1.ietf.org/mail-archive/working-groups/mip6/current/
Description of Working Group:
Mobile IPv6 (MIPv6) specifies routing support to permit IPv6 hosts to
continue using its "permanent" home address as it moves around
the Internet. Mobile IPv6 supports transparency above the IP
layer, including maintenance of active TCP connections and UDP port
bindings. The specifications for these mechanisms consist of:
draft-ietf-mobileip-ipv6-24 and
draft-ietf-mobleip-mipv6-ha-ipsec-06
The protocol as specified in the above two documents can be considered as
the baseline or minimum protocol set for implementing IPv6
mobility. During the development phase of the base protocol, a few
additional features were identified as necessary to facilitate
deployment (described below).
The primary goal of the MIP6 working group is to improve the base
specification as a result of experience gained from implementation and
interop testing and to work on items that are deemed critical to getting
MIPv6 deployable on a large scale. Specifically, this includes:
1) Refining the base specifications based on experience of initial
implementations and interoperability testing.
2) Features such as renumbering of the home link, home agent discovery,
Route Optimization, which are currently a part of the base
specification can be specified more explicitly as separate
specifications. This will also enable modularizing the Mobile
IPv6 specification further into the minimal subset and add-on
features. Some of these specifications will be identified as
base mechanisims of Mobile IPv6.
3) A number of enhancements to basic IPv6 mobility were identified
during the development of the base specification. These
enhancements would be taken up in a phased manner depending on the
priority identified with each. Below are listed the work items to
be taken up by the WG:
- A bootstrap mechanism for setting up security associations
between the MN and HA that would enable easier deployment of
Mobile IPv6. This bootstrap mechanisim is intended to be used
when the device is turned on the very first time and activates
MIP. The WG should investigate and define the scope before
solving the problem.
- Improving home agent reliability: in the even of a home agent
crashing, this would allow another home agent to continue
providing service to a given mobile node.
- Support for the MN's changing addresses either because of
renumbering in its home network or because it periodically
changes addresses (perhaps via rfc3041)
- Route optimization will require security mechanisims for
trusting and updating the binding information. Return-routability
is the basic mechanism for route-optimization. Mechanisims using
a shared secret Key/Security Association will be considered.
Methods for establishing a security association between the mobile
node and the correspondent node are out of the scope of the WG.
- The working group will also document problem statements
associated with deploying Mobile IPv6 in the following areas:
a. Mobile IPv6 issues in the presence of firewalls
b. Mobile IPv6 deployment and transition issues in the presence
of IPv4/IPv6 networks
c. Multicast issues
It should be noted that there are potential optimizations that might
make mobile IP more attractive for use by certain applications (e.g.,
making handovers "faster"). The latter category of optimizations is
explicitly out-of-scope at this time; this WG will focus on issues
for which there is strong consensus that the work is needed to get
basic mobility deployable on a large scale.
Goals and Milestones:
Aug 03 Charter approval
Nov 03 Problem statement documents (to IESG)
- Issues with firewall
- Mobile IPv6 transition between v4/v6 networks
Nov 03 Bootstrapping problem statement to IESG
Feb 04 Submit MIPv6 MIB to IESG
Feb 04 Submit alternate security mechanisms for CN-MN to IESG
Mar 04 Submit alternate security mechanisms for HA-MN to IESG
Mar 04 Alternate Route Optimization scheme to IESG
May 04 Home agent reliability to IESG
Jul 04 Bootstrapping solution to IESG
Nov 04 Separate specs for HA Discovery, Route Optimization,
Renumbering to IESG
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Mobility for IPv4 - 1 of 2
Token: Thomas
Mobility for IPv4 (mip4)
-------------------------
Charter
Last Modified: 2003-07-30
Current Status: Proposed Working Group
Chair(s):
Henrik Levkowetz <henrik@levkowetz.com>
Pete McCann <mccap@lucent.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
DESCRIPTION:
Mailing list: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body or Subject: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mip4/current/maillist.html
IP mobility support for IPv4 nodes (hosts and routers) is specified in
RFC3344. RFC 3344 mobility allows a node to continue using its
"permanent" home address as it moves around the internet. The Mobile IP
protocols support transparency above the IP layer, including maintenance
of active TCP connections and UDP port bindings. Besides the basic
Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns
such as optimization, security, extensions, AAA support, and deployment
issues.
Mobile IPv4 is currently being deployed on a wide basis (e.g., in
cdma2000 networks). The scope of the deployment is on a fairly large
scale and accordingly, the MIP4 WG will focus on deployment issues and
on addressing known deficiencies and shortcomings in the protocol that
have come up as a result of deployment experience. Specifically, the
working group will complete the work items to facilitate interactions
with AAA environments, interactions with enterprise environments when
Mobile IPv4 is used therein, and updating existing protocol
specifications in accordance with deployment needs and advancing those
protocols that are on the standards track.
Work expected to be done by the MIP4 WG as proposed by this charter is
as follows:
1. MIPv4 has been a proposed standard for several years. It has been
adopted by other standard development organizations and has been
deployed commercially. One of the next steps for the WG is to advance
the protocol to draft standard status. As part of advancing base
Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be
progressed towards DS.
2. Key exchange using AAA infrastructures for setting up security
associations defined in RFC3344 will be completed.
3. The AAA WG, which is currently dealing with the Diameter Mobile IP
application, requires the AAA NAI for Mobile IPv4. This work will
be completed by the WG. The MIP4 WG will also work with the AAA WG
to ensure that the Diameter Mobile IP application is aligned with
WG requirements.
4. Home agent assignment at the time of mobile-ip registration, rather
than preconfigured for the mobile node, has been proposed in
draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will
take on the task of completing this. The ability to switch the home
agent assigned to a mobile node while registered will also be
considered as part of this task.
5. Work items that are pending from the previous Mobile IP WG, which will be
completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism),
low-latency handover draft to experimental status and the completion
of the MIB for the revised base Mobile IP specification (2006bis).
6. The MIP4 WG will also complete the work on Mobile IPv4 interactions
in VPN scenarios. This work will involve identifying the requirements
and a solution development for Mobile IPv4 operation in the presence
of IPsec VPN's.
Other potential work items may be identified in the future but will
require an appropriate recharter.
Milestones:
Aug 03 AAA Keys for MIPv4 to IESG
Sep 03 MIPv4 VPN interaction problem statement to IESG
Sep 03 Low latency handover to experimental
Oct 03 Revised MIPv4 Challenge/Response (3012bis) to IESG
Oct 03 Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard
Nov 03 Revised MIB for MIPv4 to IESG
Dec 03 Revised MIPv4 specification to IESG for Draft Standard
Jan 04 Dynamic Home Agent assignment protocol solution to IESG
Feb 04 MIPv4 VPN Solution to IESG
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Centralized Conferencing - 2 of 2
Token: Allison
Centralized Conferencing (xcon)
---------------------------------
Charter
Last Modified: 2003-08-04
Current Status: Proposed Working Group
CHAIRS: Alan Johnston (alan.johnston@mci.com)
Adam Roach (adam@dynamicsoft.com)
Mailing list: <http://www.softarmor.com/mailman/listinfo/xcon>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
Transport Area
Responsible Area Director: Allison Mankin
Description of Working Group
The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong security
and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization so they can enforce specific media and membership
relationships, and provide an accurate roster of participants. The media
mixing or combining function of a tightly-coupled conference need not be
performed centrally, however.
The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.
Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be completely invisible or to be visible but participate
anonymously with respect to some or all of the other participants.
Authorization rules allow for participants and non-participants to have
roles (ex: speaker, moderator, owner), and to be otherwise authorized to
perform membership and media manipulation for or on behalf of other
participants. In order to preserve these properties, the protocols used
will require implementation of channel security and authentication services.
Initially this combination of protocols will be specified with respect to
session setup with SIP. The solutions developed in XCON will not preclude
operation with other signaling protocols; however it is anticipated that
the use of other protocols would require modifications which are out of
scope for this working group.
None of the protocols defined by this group will be SIP, although the SIP
specific event notification framework will be used. The group will use the
high-level requirements and framework already described by documents
published by the SIPPING WG.
The deliverables for the group will be:
- - A mechanism for membership and authorization control
- - A mechanism to manipulate and describe media "mixing" or "topology" for
multiple media types (audio, video, text)
- - A mechanism for notification of conference related events/changes (for
example a floor change)
- - A basic floor control protocol
The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.
The following items are specifically out-of-scope:
- - Voting
- - Fully distributed conferences
- - Loosely-coupled conferences (no central point of control)
- - Far-end device control
- - Protocol used between the conference controller and the mixer(s)
- - Capabilities negotiation of the mixer(s)
- - Master-slave cascaded conferences
The working group will coordinate closely with the SIPPING and MMUSIC
working groups. In addition the working group will cooperate with other
groups as needed, including SIP, AVT, and the W3C SMIL working groups.
In addition, the working group will consider a number of existing drafts (a
non-exhaustive list is included below) as input to the working group.
Proposed Milestones
Oct 2003 Submit Requirements for Membership Manipulation for publication as
Informational
Oct 2003 Submit Requirements for Basic Floor Control for publication as
Informational
Nov 2003 Submit Conferencing Scenarios document for publication as
Informational
Nov 2003 Submit Use Cases for Media Topology Control for publication as
Informational
Dec 2003 Submit Requirements for Media Topology Control for publication as
Informational
Feb 2004 Submit Basic Floor Control Protocol for publication as PS
Mar 2004 Submit Notification Event package extension for conference related
events for publication as PS
May 2004 Submit Membership Manipulation Protocol for publication as PS
Jul 2004 Submit Protocol for Media Topology Control for publication as PS
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o ADSL MIB - 1 of 1
Token: Bert
ADSL MIB (adslmib)
------------------
Charter
Last Modified: 2002-10-17
Current Status: Active Working Group
Chair(s):
Michael Sneed <sneedmike@hotmail.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Randy Presuhn <randy_presuhn@mindspring.com>
Editor(s):
Faye Ly <fayely98@hotmail.com>
Greg Bathrick <greg.bathrick@nokia.com>
Bob Ray < rray@pesa.com>
Rajesh Abbi <Rajesh.Abbi@alcatel.com>
Mailing Lists:
General Discussion:adslmib@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/adslmib
Archive: https://www1.ietf.org/mailman/listinfo/adslmib
Description of Working Group:
The working group will define a set of managed objects to be used for
management of Very high speed Digital Subscriber Line (VDSL) services as
defined by T1E1.4/2000-009R2. It is a goal, though not a
requirement, that the resultant MIB be published as an extension to the
ADSLMIB. The MIB defined by this group will be generated using SMIv2,
will be consistent with the SNMP management framework, and will
describe the relationship of the objects defined to existing MIBs such
as those described by the current ADSLMIB and HDSL2/SHDSL MIB, the
interfaces MIB, and the AToM MIB.
The working group will also define two sets of line code specific (LCS)
managed objects to be used for management of Very high speed
Digital Subscriber Line (VDSL) services, one for Multiple Carrier
Modulation line coding (MCM), and one for Single Carrier Modulation
line coding (SCM).
The working group will consider the input of the DSL forum and the ITU
in the definition of this MIB.
(new) Goals and Milestones
Sep 2003 New WG I-Ds for the LCS MCM and SCM MIB modules
Nov 2003 New drafts addressing any issues from the Minneapolis
meeting and DSLF liason from Nov. meeting.
Dec 2003 WG Last Call for LCS MCM and SCM MIB documents
Dec 2003 Send LCS MCM and SCM MIB documnets to IESG for
consideration as PS.
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
o IP over Cable Data Network - 1 of 1
Token: Bert
IP over Cable Data Network (ipcdn)
----------------------------------
Charter
Last Modified: 2003-08-01
Current Status: Active Working Group
Chair(s):
Richard Woundy <Richard_Woundy@cable.comcast.com>
Jean-Francois Mule <jf.mule@cablelabs.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: ipcdn@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Description of Working Group:
The IETF IPCDN Working Group develops and standardizes MIBs
for IP-capable data-over-cable systems, for example cable
modems, multimedia terminal adapters and associated
cable-data equipment in a cable headend.
These MIBs cover not only cable data interfaces, but also
management of cable-data equipment and systems.
The WG mailing list may be used discussion of Internet-related
issues in data-over-cable equipment and systems. In the event
of a particular new Internet technology issue arising in the
cable-data context, the WG will identify whether that is best
handled within the IETF or is best handled by another standards
body. In the event that new IETF MIB work, the WG chairs can
discuss additional WG work items with the AD. Such additions
will have to go through normal re-charter process.
If non-MIB work gets identified, such items are not normal
work items for this IPCDN-MIB WG and must go through normal
IETF new WG chartering process.
Standardization of MIBs for DOCSIS, PacketCable and CableHome
systems are explicitly within the scope of the IPCDN Working
Group.
The IPCDN WG will also keep informed on what other groups in
the industry are doing as it relates to the efforts of this
working group.
The WG will align its specifications with IPv6 and SNMP STD.
Related groups:
CableLabs (http://www.cablelabs.com/) is structured into projects.
In its Cable Modem/DOCSIS project, CableLabs has produced three
generations of data over cable specifications: DOCSIS 1.0,
DOCSIS 1.1, and DOCSIS 2.0.
In its PacketCable project, CableLabs has produced one generation
of interface specifications for delivering real-time multimedia
services over DOCSIS (http://www.packetcable.com/specifications/).
Internationally, IPCablecom is the global name associated
with the extensions & global standardization of PacketCable
in ETSI & ITU-T SG9.
In its CableHome project, CableLabs has produced one generation
of interface specifications for extending manageability for
customer care to the residential gateway or home router device
connected to the Internet through a DOCSIS-compliant cable modem
(http://www.cablelabs.com/projects/cablehome/).
DOCSIS 1.0 includes specifications for a bidirectional
data-over-cable interface (RFI, or Radio Frequency Interface)
and a data privacy service (BPI, or Baseline Privacy Interface).
The key devices in a DOCSIS network are the Cable Modem (CM, the
device at the subscriber premise) and the Cable Modem Termination
System (CMTS, the device at the cable headend). For DOCSIS 1.0
systems, the IPCDN WG has published the Cable Device MIB
(RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline
Privacy MIB (RFC 3083).
DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support
better quality of service parameters (RFIv1.1), to enable
operation in European cable networks (EuroDOCSIS), and to
authenticate modems and firmware images (BPI+). The IPCDN WG
will update the Cable Device and Radio Frequency MIBs for
DOCSIS 1.1, and repair flaws discovered in operational use.
Other IPCDN WG documents will address the operational and
management issues for new DOCSIS 1.1 functional components
(e.g. BPI+), for subscriber device management, and for
uniform event notification.
DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the
physical layer, in particular to support two new physical
layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update
the Radio Frequency MIB for DOCSIS 2.0.
PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem
infrastructure and it includes a suite of interface
specifications covering multimedia terminal adapter (MTA)
device provisioning, voice over IP session signaling, QoS
signaling based on IETF standards. The key systems in a
PacketCable network are the multimedia terminal adapter (MTA),
a Call Management Server (CMS), a PacketCable-compliant
DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways
along with back-office systems. In ITU-T SG-9 and ETSI AT,
IPCableCom has standardized PacketCable to create a set of
international standards.
CableHome 1.0 is a set of specifications for residential
gateway or home router functionality standardizing methods
for implementing address acquisition, device configuration
and management, network address translation, event reporting,
remote connectivity diagnostics, secure software download,
firewall policy file download, firewall monitoring,
management parameter access control and other residential
gateway functionality. By standardizing these features,
CableHome 1.0 specifications enable cable operators to
deliver high-value, managed broadband services to their
high-speed data service subscribers, through a DOCSIS cable
modem.
Work items:
The IPCDN WG will address issues related to network management,
especially as they concern HFC access networks. It is expected
that other services (i.e. RSVP, IPSEC, etc.) will operate
mostly unmodified.
The specific work items include
-- DOCSIS,
- publish MIB documents for:
- subscriber device management on a DOCSIS 1.1 CMTS,
- managing the quality of service parameters for a
DOCSIS 1.1 device,
- managing the Baseline Privacy Plus system for a
DOCSIS 1.1 device,
- uniform event notification on a DOCSIS 1.1 device,
- revise MIB documents for:
- DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS
parameters and DOCSIS 2.0 physical layer management,
- the DOCSIS 1.0 Cable Device MIBs to address SNMPv3
and IPv6 compliance and interoperability issues,
-- IPCablecom & PacketCable
- publish MIB documents for:
- managing the device parameters of
PacketCable/IPCableCom MTA devices,
- managing the signaling parameters of
PacketCable/IPCableCom MTA devices,
- managing events for PacketCable/IPCablecom systems,
-- CableHome
- publish MIB documents for:
- managing attributes of a residential gateway or
home router device,
- managing private address-to-public address mappings
for a residential gateway or home router device,
- managing the address lease acquistion client and the
address lease server functionality of a residential
gateway or home router device,
- managing diagnostic utilities used to remotely test
the connectivity between a residential gateway and
privately-addressed LAN hosts,
- managing firewall attributes, monitoring firewall
attacks, and managing security certificates in a
residential gateway or home router device,
- managing QoS configuration in a residential
gateway or home router device.
Goals and Milestones:
Done Post final I-D on Baseline Privacy MIB; Last call
Done Post I-Ds revising RF and CM MIBs to support DOCSIS1.1
and for compliance with SNMPv3 and IPv6
Done Submit Baseline Privacy MIB to IESG for publication as
a Standards Track RFC
Aug 03 Submit DOCSIS Subscriber Management MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit DOCSIS 1.1 QoS MIB to IESG for consideration as a
Standards Track RFC
Sep 03 Submit DOCSIS BPI+ MIB to IESG for consideration as a
Standards Track RFC
Sep 03 Submit updated DOCSIS RF MIB to IESG for consideration
as a Standards Track RFC (Proposed Standard)
Sep 03 Submit updated DOCSIS Cable Device MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit DOCSIS Event Notification MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit PacketCable/IPCableCom MTA device MIB to IESG
for consideration as a Standards Track RFC
Sep 03 Submit PacketCable/IPCableCom MTA signaling MIB to IESG
for consideration as a Standards Track RFC
Nov 03 Submit PacketCable/IPCableCom MTA event MIB to IESG for
consideration as a Standards Track RFC
Nov 03 Submit Cablehome MIB for managing residential gateway or
home router device to IESG for consideration as
Standards Track RFC,
Nov 03 Submit Cablehome MIB for MIB for managing private
address-to-public address mappings for a residential
gateway or home router device to IESG for consideration
as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing the address lease
acquistion client and the address lease server
functionality of a residential gateway or home router
device to IESG for consideration as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing diagnostic utilities
used to remotely test the connectivity between a residential
gateway and privately-addressed LAN hosts to IESG for
consideration as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing firewall attributes,
monitoring firewall attacks, and managing security
certificates in a residential gateway or home router device
to IESG for consideration as Standards Track RFC,
Feb 04 Revaluate charter and milestones or conclude wg.
5. Working Group News We Can Use
Harald Alvestrand
Steve Bellovin
Randy Bush
Bill Fenner
Ned Freed
Ted Hardie
Russ Housley
Allison Mankin
Thomas Narten
Jon Peterson
Margaret Wasserman
Bert Wijnen
Alex Zinin
6. IAB News We Can Use
7. Management Issues