[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for October 16, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the October 16, 2003 IESG Teleconference
This agenda was generated at 15:24:54 EDT, October 15, 2003
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 Two-document ballot: - 1 of 6
- draft-ietf-ccamp-gmpls-routing-08.txt
Routing Extensions in Support of Generalized Multi-Protocol Label
Switching (Proposed Standard)
Note: Now on IESG agenda
- draft-ietf-ccamp-ospf-gmpls-extensions-11.txt
OSPF Extensions in Support of Generalized Multi-Protocol Label Switching
(Proposed Standard)
Note: Waiting for answers to IETF Last Call comments. (possibly need
revisions) Responsible: WG chairs and WG
Token: Bert Wijnen
o draft-vida-mld-v2-07.txt
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard)
- 2 of 6
Token: Margaret Wasserman
o draft-ietf-msec-mikey-07.txt
MIKEY: Multimedia Internet KEYing (Proposed Standard) - 3 of 6
Token: Russ Housley
o draft-ietf-secsh-auth-kbdinteract-05.txt
Generic Message Exchange Authentication For SSH (Proposed Standard) - 4 of 6
Token: Russ Housley
o draft-ietf-mboned-msdp-deploy-03.txt
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (BCP) - 5 of
6
Token: Randy Bush
o Two-document ballot: - 6 of 6
- draft-ietf-adslmib-hc-tc-06.txt
High Capacity Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals (Proposed Standard)
Note: Responsible: Bert Wijnen
- draft-ietf-adslmib-vdsl-12.txt
Definitions of Managed Objects for Very High Speed Digital Subscriber
Lines (VDSL) (Proposed Standard)
Note: Responsible: Bert Wijnen
Token: Bert Wijnen
2.1.2 Returning Item
o draft-ietf-pkix-pi-07.txt
Internet X.509 Public Key Infrastructure Permanent Identifier (Proposed
Standard) - 1 of 1
Token: Russ Housley
2.2 Individual Submissions
2.2.1 New Item
o draft-blumenthal-aes-usm-07.txt
The AES Cipher Algorithm in the SNMP's User-based Security Model (Proposed
Standard) - 1 of 3
Note: Responsible: Author
Token: Steve Bellovin
o draft-rajeshkumar-mmusic-gpmd-03.txt
SDP attribute for qualifying Media Formats with Generic Parameters (Proposed
Standard) - 2 of 3
Token: Jon Peterson
o draft-ymbk-6to4-arpa-delegation-00.txt
Delegation of 2.0.0.2.ip6.arpa (BCP) - 3 of 3
Token: Russ Housley
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-ipsec-dpd-03.txt
A Traffic-Based Method of Detecting Dead IKE Peers (Informational) - 1 of 2
Token: Russ Housley
o draft-ietf-ipsec-nat-reqts-05.txt
IPsec-NAT Compatibility Requirements (Informational) - 2 of 2
Token: Russ Housley
3.1.2 Returning Item
o draft-ietf-ipo-framework-05.txt
IP over Optical Networks: A Framework (Informational) - 1 of 2
Token: Alex Zinin
o draft-ietf-dhc-unused-optioncodes-07.txt
Unused DHCP Option Codes (Informational) - 2 of 2
Note: Already approved by IESG, pulled back to remove option codes that were
actually in use.á Back again for re-approval.
Token: Margaret Wasserman
3.2 Individual Submissions Via AD
3.2.1 New Item
NONE
3.2.2 Returning Item
o draft-gill-gtsh-04.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental) - 1 of 1
Token: Alex Zinin
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-bless-diffserv-pdb-le-01.txt
A Lower Effort Per-Domain Behavior for Differentiated Services
(Informational) - 1 of 3
Token: Jon Peterson
o draft-bless-diffserv-multicast-07.txt
IP Multicast in Differentiated Services Networks (Informational) - 2 of 3
Token: Bill Fenner
o draft-ogura-mapos-nsp-multiexp-02.txt
A Multicast Extension to MAPOS NSP (Node Switch Protocol) (Informational) -
3 of 3
Note: 2003-10-09: sent note to authors, needs better security
considerations. (no significant objection otherwise)
Token: Thomas Narten
3.3.2 Returning Item
NONE
3.3.3 To be assigned
o draft-aboulmagd-trtcm-inprofile-01.txt
Two Rate Three Color Marker for Differentiated Services (Informational)
4. Working Group Actions
4.1.1 Proposed for IETF Review
o Credential and Provisioning (enroll) - 1 of 2
Token: Russ
o IP over DVB (ipdvb) - 2 of 2
Token: Margaret
4.1.2 Proposed for Approval
o Long-Term Archive and Notary Services (ltans) - 1 of 3
Token: Russ
o MIPv6 Signaling and Handoff Optimization (mipshop) - 2 of 3
Token: Thomas
o Internet and Management Support for Storage (imss) - 3 of 3
Token: Margaret
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
o Multiprotocol Label Switching (mpls) - 1 of 3
Token: Alex
o Common Control and Measurement Plane (ccamp) - 2 of 3
Token: Alex
o Ethernet Interfaces and Hub MIB (hubmib) - 3 of 3
Token: Bert
5. Agenda Working Group News
6. IAB News We can use
7. Management Issue
7.1 EDU Team updated charter (Harald Alvestrand)
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the October 16, 2003 IESG Teleconference
This package was generated at 15:24:54 EDT, October 15, 2003.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, October 16,
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--- Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
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--- Will call in
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.
1.2 Bash the Agenda
1.3 Approval of the Minutes
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the October 2, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Thomas Narten / IBM
Jon Peterson / NeuStar, Inc.
Dinara Suleymanova / IETF Secretariat
Amy Vezza / IETF Secretariat
Margaret Wasserman / Nokia
Bert Wijnen / Lucent
REGRETS
------------
Steve Bellovin / AT&T
Michelle Cotton / ICANN
Joyce K. Reynolds / ISI (RFC Editor)
Alex Zinin / Alcatel
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the September 18, 2003 Teleconference were approved.
The Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Bill Fenner, Ted Hardie, and Thomas Narten to work out acceptable text
to resolve ABNF and SRV issues.
DELETED:
NONE
IN PROGRESS:
o Jon Peterson 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 Alex Zinin to phrase a question to RTG and OPS Area Directorats
and IAB on PPVPN issue. Alex to summarize the results as a proposed
IESG consensus regarding the PPVPN issue to be given to the PPVPN
working group.
o Randy Bush and Bill Fenner to generate a description of policy
about a) meetings using the network in conjunction with IETF meetings,
and b) putting experiments on the network during the IETF meeting.
NEW:
o Ted Hardie to take responsibility for initiating a discussion on
applications' expectations on the behaviour of the DNS system.
o Harald Alvestrand to discuss with Barbara Fuller the process of
listing the scribes for IETF Meetings on WG charter Web pages.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-disman-conditionmib-10.txt - 1 of 9
Alarm Reporting Control MIB (Proposed Standard)
Token: Bert Wijnen
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Bert Wijnen. The Secretariat will send a working group
submission Protocol Action announcement that includes the RFC Editor
Note.
o draft-ietf-rmonmib-apm-mib-11.txt - 2 of 9
Application Performance Measurement MIB (Proposed Standard)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Ted Hardie, and Russ Housley.*
o draft-ietf-ipsec-rfc2402bis-05.txt - 3 of 9
IP Authentication Header (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Jon Peterson, and Bert Wijnen.*
o draft-ietf-ipsec-esn-addendum-02.txt - 4 of 9
Extended Sequence Number Addendum to IPsec DOI for ISAKMP (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-ipsec-esp-v3-06.txt - 5 of 9
IP Encapsulating Security Payload (ESP) (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Jon Peterson, and Bert Wijnen.*
o draft-ietf-dnsext-keyrr-key-signing-flag-10.txt - 6 of 9
KEY RR Secure Entry Point Flag (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Ted Hardie, and Russ Housley.*
o draft-ietf-ldup-lcup-06.txt - 7 of 9
LDAP Client Update Protocol (Proposed Standard)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action announcement.
o draft-ietf-nomcom-rfc2727bis-07.txt - 8 of 9
IAB and IESG Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees (BCP)
Token: Harald Alvestrand
The document remains under discussion by the IESG in order to resolve
points raised by Thomas Narten and Margaret Wasserman.*
o draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt - 9 of 9
KDC Server Address Sub-option (Proposed Standard)
Token: Margaret Wasserman
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Margaret Wasserman. The Secretariat will send a
working group submission Protocol Action announcement that includes
the RFC Editor Note.
2.1.2 Returning Item
o draft-ietf-ftpext-mlst-16.txt - 1 of 3
Extensions to FTP (Proposed Standard)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action announcement.
o draft-ietf-dhc-isnsoption-10.txt - 2 of 3
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-avt-mpeg4-simple-08.txt - 3 of 3
RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed
Standard)
Token: Allison Mankin
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action announcement.
2.2 Individual Submissions
2.2.1 New Item
o draft-zeilenga-ldap-rfc2596-04.txt - 1 of 1
Language Tags and Ranges in LDAP (Proposed Standard)
Token: Ted Hardie
The document remains under discussion by the IESG in order to resolve
points raised by Ned Freed.*
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-isis-igp-p2p-over-lan-03.txt - 1 of 2
Point-to-point operation over LAN in link-state routing protocols
(Informational)
Token: Bill Fenner
The document remains under discussion by the IESG.*
o draft-ietf-magma-msf-api-05.txt - 2 of 2
Socket Interface Extensions for Multicast Source Filters (Informational)
Token: Margaret Wasserman
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Margaret Wasserman. The Secretariat will send a
working group submission Document Action announcement that includes
the RFC Editor Note.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-newton-ldap-whois-04.txt - 1 of 2
Domain Administrative Data in LDAP (Experimental)
Token: Ted Hardie
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Ted Hardie. The Secretariat will send an individual
submission Document Action announcement that includes the RFC Editor
Note.
o draft-gill-gtsh-01.txt - 2 of 2
The Generalized TTL Security Mechanism (GTSM) (Experimental)
Token: Alex Zinin
The document remains under discussion by the IESG.*
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-touch-ipsec-vpn-06.txt - 1 of 1
Use of IPsec Transport Mode for Dynamic Routing (Informational)
Token: Russ Housley
The document remains under discussion by the IESG.*
3.3.3 To be assigned
o draft-irtf-nsrg-report-10.txt
What's In A Name:Thoughts from the NSRG (Informational): IRTF document.
The document was assigned to Russ Housley.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Long-Term Archive and Notary Services (ltans) - 1 of 1
Token: Russ Housley
The IESG approved the draft working group charter for IETF review.
The Secretariat will send a WG Review announcement, with a copy to
new-work@ietf.org. The Secretariat will place the working group
on the agenda for the next IESG teleconference.
4.1.2 Proposed for Approval
o Centralized Conferencing (xcon) - 1 of 1
Token: Allison Mankin
The IESG approved the charter for the new working group. The
Secretariat will send a WG Action announcement.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Multiprotocol Label Switching (mpls) - 1 of 6
Token: Alex Zinin
The IESG decided to proceed with IETF review of the revised
charter. The Secretariat will send a WG Review: Recharter
announcement, with a copy to new-work@ietf.org, to include
additional text to be provided by Bert Wijnen. The Secretariat
will place the working group on the agenda for the next IESG
teleconference.
o Mobility for IPv4 (mip4) - 2 of 6
Token: Thomas Narten
The IESG approved the updated charter for the working group.
The Secretariat will send a WG Action: RECHARTER announcement
to include additional text to be provided by Thomas Narten.
o Audio/Video Transport (avt) - 3 of 6
Token: Allison Mankin
The IESG approved the updated charter for the working group.
The Secretariat will send a WG Action: RECHARTER announcement
o DNS Extensions (dnsext) - 4 of 6
Token: Thomas Narten
The IESG approved the updated charter for the working group pending
a revised charter to be provided by Thomas Narten. The Secretariat
will send a WG Action: RECHARTER announcement.
o Common Control and Measurement Plane (ccamp) - 5 of 6
Token: Alex Zinin
The IESG decided to proceed with IETF review of the revised charter.
The Secretariat will send a WG Review: Recharter announcement, with a
copy to new-work@ietf.org, to include additional text to be provided
by Bert Wijnen. The Secretariat will place the working group on the
agenda for the next IESG teleconference.
o Ethernet Interfaces and Hub MIB (hubmib) - 6 of 6
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 a
copy to new-work@ietf.org. The Secretariat will place the working group
on the agenda for the next IESG teleconference.
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
7.1 Appropriate Methods for getting Meeting Minutes from Chairs
(Harald Alvestrand)
This management issue was discussed.
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
This management issue was discussed.
7.3 Referral of draft-klensin-name-filters-03.txt to the IAB
(Ted Hardie)
This management issue was 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
1.4 Review of Action Items
OUTSTANDING TASKS
Last updated: October 6, 2003
IP o Jon Peterson 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 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 Randy Bush and Bill Fenner to generate a description of policy about
a) meetings using the network in conjunction with IETF meetings, and b)
putting experiments on the network during the IETF meeting.
IP o Ted Hardie to take responsibility for initiating a discussion on applications'
expectations on the behavior of the DNS system.
IP o Harald Alvestrand to discuss with Barbara Fuller the process of listing
the scribes for IETF Meetings on WG charter Web pages.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 6
o Two-document ballot:
- draft-ietf-ccamp-gmpls-routing-08.txt
Routing Extensions in Support of Generalized Multi-Protocol Label
Switching (Proposed Standard)
Note: Now on IESG agenda
- draft-ietf-ccamp-ospf-gmpls-extensions-11.txt
OSPF Extensions in Support of Generalized Multi-Protocol Label Switching
(Proposed Standard)
Note: Waiting for answers to IETF Last Call comments. (possibly need
revisions) Responsible: WG chairs and WG
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-ccamp-gmpls-routing-08.txt to Proposed Standard,
draft-ietf-ccamp-ospf-gmpls-extensions-11.txt to Proposed Standard
--------
Evaluation for draft-ietf-ccamp-gmpls-routing-08.txt,
draft-ietf-ccamp-ospf-gmpls-extensions-11.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7627&rfc_flag=0
Last Call to expire on: 2003-02-24
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ X ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Comment:
Why is draft-ietf-ccamp-gmpls-routing Proposed instead of Informational?
(It's clear why the other document in the ballot is Proposed.)
Ted Hardie:
Comment:
Reading through gmpls-routing-08, I kept feeling like something was
missing--essentially the
description of how the routing decisions get made in the presence of the new
data
about Shared Risk Link Groups, protection information, and interface switching
About
the only I thing that seemed to relate to that was the "if you're looking for
diverse paths,
choose links with different SRLGs" statement. I then decided it was probably
in the OSPF doc,
but it doesn't seem to be in OSPF-gmpls-extensions either. Is there some othe
doc that talks
about how implementors should consider the interactions among these pieces of
data?
For example, what should you do when one link is listed as protected, but in
the same SRLG,
where another link is a different SRLG but unprotected? Is deterministic
behavior on this not
something which is important?
Russ Housley:
Discuss:
DISCUSS on draft-ietf-ccamp-ospf-gmpls-extensions-11:
Need a normative reference for IEEE floating point format.
Comment:
COMMENT on draft-ietf-ccamp-gmpls-routing-08:
The Abstract is very weak. I propose:
This document specifies routing extensions in support of carrying
link state information for Generalized Multi-Protocol Label Switching
(GMPLS). This document enhances the routing extensions required to
support MPLS Traffic Engineering (TE).
Move the single paragraph in section 1 to the top of section 2. This
will turn section 2 into a very good introduction.
Spell out first use of SPF.
COMMENT on draft-ietf-ccamp-ospf-gmpls-extensions-11:
Move the single paragraph in section 1 to the top of section 2. This
will turn section 2 into a very good introduction.
^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>, <ccamp@ops.ietf.org>
Subject: Protocol Action: 'Routing Extensions in Support of Generalized
Multi-Protocol Label Switching' to Proposed Standard
The IESG has approved following documents:
- 'Routing Extensions in Support of Generalized Multi-Protocol Label Switching '
<draft-ietf-ccamp-gmpls-routing-08.txt> as a Proposed Standard
- 'OSPF Extensions in Support of Generalized Multi-Protocol Label Switching '
<draft-ietf-ccamp-ospf-gmpls-extensions-11.txt> as a Proposed Standard
These documents are products of the Common Control and Measurement Plane Working
Group.
The IESG contact persons are Bert Wijnen and Alex Zinin.
Technical Summary
<draft-ietf-ccamp-gmpls-routing-08.txt>
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).
<draft-ietf-ccamp-ospf-gmpls-extensions-11.txt>
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.
Working Group Summary
There is WG consensus to publish these documents as Proposed Standards.
Besides WG last call in CCAMP, the WG last call was also posted to the
the OSPF WG to make sure proper review would happen.
IETF Last Call caused some comments that resulted in fixes and new
revisions of the I-Ds.
Protocol Quality
The document was reviewed for the IESG by Bert Wijnen
RFC-Editor notes for <draft-ietf-ccamp-gmpls-routing-08.txt>:
In section 2.1, para 4 (Inheritable attributes) fix a typo
OLD:
exists for protection), then an OC-3c within that OC-192 (a higher
^^^^^
NEW:
exists for protection), then an STS-3c within that OC-192 (a higher
^^^^^^
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 2 of 6
o draft-vida-mld-v2-07.txt
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard)
Token: Margaret Wasserman
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-vida-mld-v2-07.txt to Proposed Standard
--------
Evaluation for draft-vida-mld-v2-07.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=6744&rfc_flag=0
Last Call to expire on: 2003-10-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Randy Bush:
Discuss:
ok, this is my first deep dive into MLDn, so
o some or all questions are likely silly
o many will be answered with "MLDv1 compatibility" (except
routers seem to be explicitly configured to be mldv1 or mldv2,
see 8.3.1)
but, for the moment, color me discuss
---
in general, this document is unusually well written. but i will be
picky anyway.
---
To cover the possibility of a State Change Report being missed by one
or more multicast routers, the report is retransmitted several times
by the node. The number of retransmissions depends on the so-called
Robustness Variable.
this seems a bit hit and miss, i.e., 'robustness' is not very apt.
perhaps 'improve the odds' would better describe it </sarcasm>.
---
in general, the protocol has hacks to deal with unreliability of
exchanges by use of various timers and by issuing queries and
responses multiple times. the S flag is a particularly 'cute' hack
on this multi-send hack. it would help if the general reliability
and timing model was explained.
e.g., sympathy for these hacks would be easier if the document
explained the assumptions behind why they are necessary and the
model of how good values of RV can be decided which will make the
transactions sufficiently reliable.
sometimes, the layers of kink get *really* kinky, e.g., in 6.1 when
changes to an interface happen before all the retransmissions of
the SCR for the last change have been completed.
---
the Querier sends a
Multicast Address and Source Specific Query to verify whether, for a
specified multicast address, there are nodes still listening to a
specific set of sources, or not. Both queries are only sent in
response to State Change Reports, never in response to Current State
Reports.
this seems to assume that a CSR will not surprise the querier,
i.e., not change the querier's knowledge of what the set of
listeners want. if this was not the case, should not a surprising
CSR cause the querier to send MA or SS queries? alternatively, if
CSRs can, ob definito, not be surprising, then why have them?
---
4.2. Interface State
it would clearer to call it "4.2 Per-Interface State"
---
5.1.8. QRV (Querier's Robustness Variable)
If non-zero, the QRV field contains the [Robustness Variable] value
used by the Querier. If the Querier's [Robustness Variable] exceeds
7 (the maximum value of the QRV field), the QRV field is set to zero.
Routers adopt the QRV value from the most recently received Query as
their own [Robustness Variable] value, unless that most recently
received QRV was zero, in which case they use the default [Robustness
Variable] value specified in section 9.1, or a statically configured
value.
what is the meaning of the square brackets in "[Robustness
Variable]?" the syntax needs to be explained.
same confusion about 5.1.9 "[Query Interval]"
---
in general, are values of MRC and QQIC expected to be so large that
the exponential notation hacks are needed as opposed to just making
the cardinal fields a bit larger?
---
syntax error in 6.1. in following text
To cover the possibility of the State Change Report being missed by
one or more multicast routers, [Robustness Variable] ? 1
retransmissions are scheduled, through a Retransmission Timer, at
intervals chosen at random from the range (0, [Unsolicited Report
Interval]).
---
7.6.2. Querier Election
has an explicit Querier state, but not a non-Querier state, though
all routers but one are probabilistically in non-Querier state.
E.g.,
When a router receives a query with a lower IPv6 address than its
own, it sets the Other Querier Present timer to Other Querier Present
Timeout; if it was previously in Querier state, it ceases to send
queries on the link.
could say it has entered non-Querier state
---
Ted Hardie:
Comment:
For the state change request, the draft says:
Besides this "soft leave" mechanism, there is also a "fast leave"
scheme in MLDv2; it is also based on the use of source timers. When
a node in INCLUDE mode expresses its desire to stop listening to a
specific source, all the multicast routers on the link lower their
timer for that source to a small interval of LLQT milliseconds. The
Querier then sends then a Multicast Address and Source Specific
Query, to verify whether there are other listeners for that source on
the link, or not. If a corresponding report is received before the
timer expires, all the multicast routers on the link update their
source timer. If not, the source is deleted from the Include List.
The handling of the Include List, according to the received reports,
is detailed in Tables 7.4.1 and 7.4.2.
In the Security Considerations, the draft notes some of the issues with this;
10.3. State Change Report messages
A forged State Change Report message will cause the Querier to send
out Multicast Address Specific or Multicast Address and Source
Specific Queries for the multicast address in question. This causes
extra processing on each router and on each listener of the multicast
address, but cannot cause loss of desired traffic.
It seems like the DoS aspects of this risk might be mitigated by allowing the
Querirer not to send out the Multicast Address Specific or Multicast Address
and Source specific queries when the State Change request related to a
multicast address for which the node was not a listener. It was not entirely
clear to me, however, whether the Querier would always have definitive
information
on this when there multiple queriers, but it does seem useful when there is
only
one on-link.
Russ Housley:
Comment:
I propose a revised Abstract:
This document updates RFC 2710, and it specifies Version 2 of the
Multicast Listener Discovery Protocol (MLDv2). MLD is used by an
IPv6 router to discover the presence of multicast listeners on
directly attached links, and to discover which multicast addresses
are of interest to those neighboring nodes. MLDv2 is designed to
be interoperable with MLDv1. MLDv2 adds the ability for a node to
report interest in listening to packets with a particular multicast
address only from specific source addresses or from all sources
except for specific source addresses.
In section 5.1.8, the document says:
If non-zero, the QRV field contains the [Robustness Variable] value
used by the Querier. If the Querier's [Robustness Variable] exceeds
7 (the maximum value of the QRV field), the QRV field is set to zero.
This is an unusual use of square brackets. This convention is used elsewhere
too. It should be explained in a manner similar to the use of asterisk.
^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>, <magma@ietf.org>
Subject: Protocol Action: 'Multicast Listener Discovery Version 2
(MLDv2) for IPv6' to Proposed Standard
The IESG has approved following document:
- 'Multicast Listener Discovery Version 2 (MLDv2) for IPv6 '
<draft-vida-mld-v2-07.txt> as a Proposed Standard
This document is the product of the Multicast & Anycast Group Membership
Working Group.
The IESG contact persons are Margaret Wasserman and Thomas Narten.
Technical Summary
This document defines IPv6 Multicast Listener Discovery version 2,
which corresponds to IGMPv3 for IPv4. In particular, it adds
support for source filtering.
Working Group Summary
This document document is a work item of the Multicast and Anycast
Group Membership (magma) WG. It passed a two week working group
last call, and has been updated based on AD comments.
Protocol Quality
This document was reviewed for the IESG by Margaret Wasserman,
and previously by Erik Nordmark.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 6
o draft-ietf-msec-mikey-07.txt
MIKEY: Multimedia Internet KEYing (Proposed Standard)
Token: Russ Housley
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-msec-mikey-07.txt to Proposed Standard
--------
Evaluation for draft-ietf-msec-mikey-07.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7881&rfc_flag=0
Last Call to expire on: 2003-07-31
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ted Hardie:
Discuss:
This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.
Essentially, I'm concerned about section 5.4, which describes the replay
protection mechanisms. The language in the draft is a bit hard to parse
in places, and there seem to be some assumptions
that we may not be able to meet. In particular, it cites as an assumption:
"* If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol is used."
Is there a solution available for this? NTP v3 is cited in the references (not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't seem to be done.
The Security Considerations Section (9.3) does discuss this briefly, but basically points back
to 5.4 and hints that practical experience with other protocols indicates that manual configuration
may be okay.
This language also seemed strange:
In a client-server scenario, servers may be the entities that will
have the highest workload. It is therefore RECOMMENDED that the
servers are the Initiators of MIKEY. This will result in that the
servers will not need to manage any significant replay cache as they
will refuse all incoming messages that are not a response to an
already (by the server) sent message.
as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol. In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large. This wasn't entirely clear, though,
and some tightened language might help.
In general, an editing pass through this section by a native speaker might
be a good idea.
^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>, <msec@securemulticast.org>
Subject: Protocol Action: 'MIKEY: Multimedia Internet KEYing' to
Proposed Standard
The IESG has approved following document:
- 'MIKEY: Multimedia Internet KEYing '
<draft-ietf-msec-mikey-07.txt> as a Proposed Standard
This document is the product of the Multicast Security Working Group.
The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
Security protocols for real-time multimedia applications have started
to appear, bringing forward the need for a key management solution to
support these security protocols. This document describes a key
management scheme that can be used with real-time applications, for
both peer-to-peer communication and group communication. The document
also shows how MIKEY might work with protocols such as SIP and RTSP.
In particular, it describes how MIKEY can provide keying material for
use with the Secure Real-time Transport Protocol.
Working Group Summary
The MSEC Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 6
o draft-ietf-secsh-auth-kbdinteract-05.txt
Generic Message Exchange Authentication For SSH (Proposed Standard)
Token: Russ Housley
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-secsh-auth-kbdinteract-05.txt to Proposed
Standard
--------
Evaluation for draft-ietf-secsh-auth-kbdinteract-05.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=4075&rfc_flag=0
Last Call to expire on: 2003-10-01
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Discuss:
This sentence:
The actual names of the submethods is something which the user and
the server needs to agree upon.
is unacceptable, since there can't be any standards-based interoperability of submethods. These need to be specified by RFC -- standards-track? -- and listed in an IANA registry.
Explain why the language tag in the SSH_MSG_USERAUTH_INFO_REQUEST is not deprecated, when they are deprecated in SSH_MSG_USERAUTH_REQUEST.
Ted Hardie:
Discuss:
Section 3.4 seems problematic. It says:
Note that the responses are encoded in ISO-10646 UTF-8. It is up to
the server how it interprets the responses and validates them.
However, if the client reads the responses in some other encoding
(e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
before transmitting.
If I read the author's intentions correctly, they mean to say that a server
might use an authentication method that was functionally similar to
case-insensitive passwords, and would thus treat the strings
like "aCEddd8" and "AceDdd8" (encoded in UTF-8) as equivalent. I don't think it
should be "up to the server" though, I think the method (or sub-method)
has to determine this; otherwise the interaction seems pretty hard to
debug.
There are also a lot of worms under the carpet of "if the client reads the
responses in some other encoding...it MUST convert the responses".
It is particularly problematic when you have the possibility of authentication
mechanisms that are not exact match, as the temptation is to increase
the set of matches rather than strongly define the conversion. There
are clear security concerns there.
The reference to UTF-8 should probably be updated.
Comment:
I find the whole User Interface section grating. It has two or three visual
models in
mind and ignores a plethora of other possibilities. I'd personally rather the
ripped
it out, but this is probably rank prejudice, so take it as such.
Margaret Wasserman:
Comment:
In the example section, the draft says:
"The second example is of a standard password authentication, in
this case the user's password is expired."
What does this mean? What about this case indicates that the
user's password is expired?
^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>, <ietf-ssh@netbsd.org>
Subject: Protocol Action: 'Generic Message Exchange Authentication
For SSH' to Proposed Standard
The IESG has approved following document:
- 'Generic Message Exchange Authentication For SSH '
<draft-ietf-secsh-auth-kbdinteract-05.txt> as a Proposed Standard
This document is the product of the Secure Shell Working Group.
The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
Secure Shell (SSH) is a protocol for secure remote login and other
secure network services over an insecure network. This document
describes a general purpose authentication method for the SSH
protocol, suitable for interactive authentications where the
authentication data should be entered via a keyboard. The major goal
of this method is to allow the SSH client to support a whole class of
authentication mechanisms without knowing the specifics of the actual
authentication mechanisms.
Working Group Summary
The SecSH Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 5 of 6
o draft-ietf-mboned-msdp-deploy-03.txt
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (BCP)
Token: Randy Bush
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-mboned-msdp-deploy-03.txt to BCP
--------
Evaluation for draft-ietf-mboned-msdp-deploy-03.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=8396&rfc_flag=0
Last Call to expire on: 2003-08-26
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 [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Comment:
The RFC 2119 boilerplate needs to be moved from the Status of this Document
into the body of the document.
Please place the Acknowledgements section after the IANA Considerations
section.
In section 6.2: s/SHOULD BE be/SHOULD be/
^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>, <mboned@ns.uoregon.edu>
Subject: Protocol Action: 'Multicast Source Discovery Protocol
(MSDP) Deployment Scenarios' to BCP
The IESG has approved the Internet-Draft 'Multicast Source Discovery
Protocol (MSDP) Deployment Scenarios'
<draft-ietf-mboned-msdp-deploy-03.txt> as a BCP. This document is the
product of the MBONE Deployment Working Group. The IESG contact persons are
Randy Bush and Bert Wijnen.
The IESG has approved the Internet-Draft ''Multicast Source Discovery Protocol (MSDP) Deployment Scenarios' <draft-ietf-mboned-msdp-deploy-03.txt>
as a Best Current Practice (BCP).
This document was the product of the mboned working group. The IESG contact people are Randy Bush and Bert Wijnen.
Technical Summary
This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
Working Group Summary
The document had working group consensus, and no technical issues were
raised in working group or IETF last call
Protocol Quality
This document was reviewed for the IESG by Randy Bush.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 6 of 6
o Two-document ballot:
- draft-ietf-adslmib-vdsl-12.txt
Definitions of Managed Objects for Very High Speed Digital Subscriber
Lines (VDSL) (Proposed Standard)
Note: Responsible: Bert Wijnen
- draft-ietf-adslmib-hc-tc-06.txt
High Capacity Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals (Proposed Standard)
Note: Responsible: Bert Wijnen
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-adslmib-hc-tc-06.txt to Proposed Standard,
draft-ietf-adslmib-vdsl-12.txt to Proposed Standard
--------
Evaluation for draft-ietf-adslmib-hc-tc-06.txt, draft-ietf-adslmib-vdsl-12.txt
can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7830&rfc_flag=0
Last Call to expire on: 2003-10-06
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ X ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Margaret Wasserman:
Discuss:
DISCUSS comments on draft-ietf-adslmib-hc-tc-06.txt:
> This document presents a set of High Capacity Textual Conventions
> for use in MIB modules which require performance history based upon
> 15 minute intervals. The Textual Conventions defined in this
> document extend the conventions presented in RFC 3593 to 64 bit
> resolution using the conventions presented in RFC 2856.
This isn't really true. This document takes an entirely
different approach from RFC 3593, which only specifies two
TCs, and provides a template for three variables that
every MIB must contain that uses the RFC 3593 TCs. I
believe that the 32-bit and 64-bit mechanisms for handling
15-minute counters should be consistent.
IMO, both this document and RFC 3593 are overly restrictive.
Why are "15 minutes" or "96 intervals" magic numbers? Do
they come from some telecommunications requirements?
> hcPerfHistTCMIB MODULE-IDENTITY
[...]
> In certain cases (e.g., in the case where the agent is a
> proxy) it is possible that some intervals are unavailable.
> In this case, this interval is the maximum interval number
> for which data is available."
There is no explanation for why the use of a proxy would
cause information for some intervals to be unavailable
and/or how the agent would know that a proxy was in use,
so that it could report a different value. Please explain.
EDITORIAL COMMENTS on draft-ietf-adslmib-hc-tc-06.txt:
>Since RFC 3593 was only published in Sept 2003, I wonder
>the authors of this document decided to depart so far from
>it.
>
> HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "The number of near end intervals for which no data is
The term "near end intervals" isn't meaningful to me. Is
this a technical term from another context? If so, a reference
might be helpful.
> This count represents a non-negative integer, which
> may increase or decrease, but shall never exceed 2^64-1
> (18446744073709551615 decimal), nor fall below 0.
It seems unnecessary to define the range that an unsigned
64-bit integer can assume, and it is especially wordy to
do this in three separate places in this MIB.
^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>, <adslmib@ietf.org>
Subject: Protocol Action: 'Definitions of Managed Objects for Very High
Speed Digital Subscriber Lines (VDSL)' to Proposed Standard
The IESG has approved following documents:
- 'High Capacity Textual Conventions for MIB Modules Using Performance History
Based on 15 Minute Intervals '
<draft-ietf-adslmib-hc-tc-06.txt> as a Proposed Standard
- 'Definitions of Managed Objects for Very High Speed Digital Subscriber Lines
(VDSL) '
<draft-ietf-adslmib-vdsl-12.txt> as a Proposed Standard
These documents are products of the ADSL MIB Working Group.
The IESG contact persons are Bert Wijnen and Randy Bush.
Technical Summary
- draft-ietf-adslmib-hc-tc-06.txt
This document presents a set of High Capacity Textual Conventions
for use in MIB modules which require performance history based upon
15 minute intervals. The Textual Conventions defined in this
document extend the conventions presented in RFC 3593 to 64 bit
resolution using the conventions presented in RFC 2856.
- draft-ietf-adslmib-vdsl-12.txt
This document defines a Management Information Base (MIB) module for
use with network management protocols in the Internet community. In
particular, it describes objects used for managing Very High Speed
Digital Subscriber Line (VDSL) interfaces.
Working Group Summary
The Working Group has consensus to publish these two documents as
Proposed Standards
Protocol Quality
These documents have been reviewed for the IESG by Randy Presuhn and
Bert Wijnen
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 1
o draft-ietf-pkix-pi-07.txt
Internet X.509 Public Key Infrastructure Permanent Identifier (Proposed
Standard)
Token: Russ Housley
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pkix-pi - Internet X.509 Public Key
Infrastructure Permanent Identifier to Proposed Standard
--------
Last Call to expire on: 2002-12-9
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ X ] [ ]
Steve Bellovin [ ] [ XX] [ 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:
========
Steve:
Permanent universally-unique names strike me as a singularly bad
idea in general, and even worse as specified here. A name can only
be guaranteed to be unique (even in theory) within the scope of a
single CA; there's no way to make any assumptions if different CAs
are involved. Sure, they're supposed to be URIs, but that's not
enforceable except by referring to the parent certificate, and if
you're going to do that why bother with a URI at all? The notion
of using permanent identifiers in ACLs is even worse.
Beyond that, the comparison rules for UTF8 strings look wrong --
I'm glad there's a matching rule specified, but from the little I
understand about such things there will be a lot of complaints
about the lack of more CJK-friendly matching rules.
Harald:
The matchingRule is an OID. When the OID is missing the
following matching rule SHALL be used:
The Alphanumeric Identifier Match rule compares for
equality a presented value with an attribute value of type
UTF8String or IA5String, which is interpreted as a series
of alphanumeric characters. The rules for matching are that
a working comparison value is constructed from each of the
two values by including only the digits and alphabetic
characters appearing in the value; and then the two
comparison values are compared using CaseIgnoreMatch. This
rule is intended for use only with identifiers in variants
of the Latin, Greek, and Cyrillic scripts.
1) as defined, this cannot be implemented interoperably, because the
definition of "alphabetic character" is not given.
If the document is amended to refer to (for instance) the Unicode
Alphabetic property (section 4.10 of the Unicode 3.0 standard), I'll
remove this DISCUSS. You REALLY, REALLY don't want to get into a
discussion about whether or not a HEBREW POINT RAFE or a GUJARATI SIGN
VISAGARA is an alphabetic character or not; let someone else do that.
(be careful. Even the restriction to Latin, Greek and Cyrillic isn't
enough for interoperability - what about GREEK NUMERAL SIGN or
COMBINING CYRILLIC TITLO? You REALLY want to use someone else's
definition.)
2) For greater general utility, I suggest that this document define an
OID for this matching rule. It can be "TBD by IANA", and I'm fine with
assuming it as a default - but leaving it unlabelled is Just Not Right.
Ted:
Discuss comments:
"An Assigner authority maybe a government, a government agency, a
corporation, or any other sort of organization. It MUST have a unique
identifier to distinguish it from any other such authority. In this
standard, that identifier MUST be an object identifier or be
representable as a URI"
"representable as a URI" is not particularly strong, and the rest of
the document's view of a "permanent URI" isn't a lot better. I *think*
what they mean here is that the Assigner Authority must have either an
IANA-assigned URN NID, or be sub-delegated space under such an
assignment. In other words, I think they are making a parallel between
the URN NID space and the OIDs assigned for ASN.1/enterprise numbers
assigned by IANA. If that is the case, this needs to be spelled out;
if that is not the case, and they really do mean that any URI should
be usable for this purpose, then they need a _lot_ more text on how.
It also strikes me that the mechanisms for using a Permanent
Identifier cross-CA don't handle some pretty likely issues. If an
attacker can read the Permanent Identifier for some entity out of its
certificate, the attacker can then create a CA and certificate that
purports to be about the same entity. Of course, no one should trust
that certificate just because it contains data supposedly also about
the same entity, but given that, it's not clear what the utility is
supposed to be to knowing that the two assertions are about the same
entity. If you're supposed to evaluate them independently, what is the
win?
Jon:
As far as I can tell, this document allows organizations with some
relationship to CAs (government or corporate are the suggested options)
to create linkability between different certificates associated with
an entity - while this is justified by the fact attributes of an entity
may change over time (necessitating changes in subjects of certificates
et al), it is also clearly meant to be applicable to multiple
certificates simultaneously held by the same entity.
In the absence of any model governing the inclusion of permanent
identifiers in certificates or the use of this information by relying
parties, this does not sound likely to be a privacy-enhancing
technology; however, I note that the string "privacy" (let alone any
privacy considerations) does not seem to appear in the document. At
least the document should include some caveat that this identifer
could be inflicted on purchasers of certificates without their consent
in order to bind their certs to a government SSN or DoubleClick-style
consumer profile that will be used by relying parties to track them
for potentially undesirable purposes.
COMMENTS:
=========
Steve Bellovin (Comment):
Please change me to a no-ob. However, I suggest that the text contain
a forward pointer to Appendix B -- this can be added by an rfc editor's
note.
Leslie Daigle:
Hmmm, well, just to play devil's advocate for a second (and
because the alternative is that I have to back to playing
with powerpoint tables)...
Steven M. Bellovin wrote:
> In message <200304101701.NAA26528@ietf.org>, IESG Secretary writes:
>
>>Last Call to expire on: 2002-12-9
>>
>> Please return the full line with your position.
>>
>> Yes No-Objection Discuss * Abstain
>>
>>
>>Steve Bellovin [ ] [ ] [ X ] [ ]
>
>
> Permanent universally-unique names strike me as a singularly bad
> idea in general, and even worse as specified here. A name can only
> be guaranteed to be unique (even in theory) within the scope of a
> single CA; there's no way to make any assumptions if different CAs
> are involved. Sure, they're supposed to be URIs, but that's not
> enforceable except by referring to the parent certificate, and if
> you're going to do that why bother with a URI at all? The notion
> of using permanent identifiers in ACLs is even worse.
Is it any more wrong than using, say, an e-mail address? (Which
is unique at any given moment in time). Then, each certificate
is a binding of: a DN (which is more or less an "address" for
the cert, in some way), a public key, the PI-as-data (e-mail address)
and the CA's signature on that public key. You can't trust this
binding any more than you trust the CA that signed it.
So, you shouldn't use PI's in ACLs, without the additional
enforcement of trusting the CA that signed the cert
(or else, as Ted pointed out when he & I were chatting on
the phone) you can self-sign a certificate with the requisite
PI and in you go...
>
> Beyond that, the comparison rules for UTF8 strings look wrong --
> I'm glad there's a matching rule specified, but from the little I
> understand about such things there will be a lot of complaints
> about the lack of more CJK-friendly matching rules.
Actually, they should not -- because URIs, as currently
defined, are strictly a subset of 0-127 ascii. If you
want anything else, you have to encode it (e.g., hex encoding).
Now, I'm not saying I think it's the best idea, and
certainly there's something left to be desired in the
implementation proposal -- e.g., they haven't defined how an
"Assignment Authority" should structure its strings such that there
won't be collisions across AA's in any given identifier
type.
Steve:
In message <3E9C7AED.1020503@thinkingcat.com>, Leslie Daigle writes:
>
>
>
>Hmmm, well, just to play devil's advocate for a second (and
>because the alternative is that I have to back to playing
>with powerpoint tables)...
Speaking of the devil....
>
>
>Steven M. Bellovin wrote:
>> In message <200304101701.NAA26528@ietf.org>, IESG Secretary writes:
>>
>>>Last Call to expire on: 2002-12-9
>>>
>>> Please return the full line with your position.
>>>
>>> Yes No-Objection Discuss * Abstain
>>>
>>>
>>>Steve Bellovin [ ] [ ] [ X ] [ ]
>>
>>
>> Permanent universally-unique names strike me as a singularly bad
>> idea in general, and even worse as specified here. A name can only
>> be guaranteed to be unique (even in theory) within the scope of a
>> single CA; there's no way to make any assumptions if different CAs
>> are involved. Sure, they're supposed to be URIs, but that's not
>> enforceable except by referring to the parent certificate, and if
>> you're going to do that why bother with a URI at all? The notion
>> of using permanent identifiers in ACLs is even worse.
>
>Is it any more wrong than using, say, an e-mail address? (Which
>is unique at any given moment in time). Then, each certificate
>is a binding of: a DN (which is more or less an "address" for
>the cert, in some way), a public key, the PI-as-data (e-mail address) and
>the CA's signature on that public key. You can't trust this
>binding any more than you trust the CA that signed it.
>
>So, you shouldn't use PI's in ACLs, without the additional
>enforcement of trusting the CA that signed the cert
>(or else, as Ted pointed out when he & I were chatting on
>the phone) you can self-sign a certificate with the requisite
>PI and in you go...
>
Precisely -- any sort of name, permanent or not, is useless outside of
the administrative context. That's why I think this is such a bad
idea, especially as specified here. Why, for example, does it need to
have the CA's name in the PI field, when you always have to carry the
CA name elsewhere in the certificate?
>>
>> Beyond that, the comparison rules for UTF8 strings look wrong --
>> I'm glad there's a matching rule specified, but from the little I
>> understand about such things there will be a lot of complaints
>> about the lack of more CJK-friendly matching rules.
>
>Actually, they should not -- because URIs, as currently
>defined, are strictly a subset of 0-127 ascii. If you
>want anything else, you have to encode it (e.g., hex encoding).
>
OK -- but in that case, why does the document say that the identifier
can be a UTV8 string?
Leslie:
Steven M. Bellovin wrote:
> Precisely -- any sort of name, permanent or not, is useless outside
> of the administrative context. That's why I think this is such a bad
> idea, especially as specified here. Why, for example, does it need
> to have the CA's name in the PI field, when you always have to carry
> the CA name elsewhere in the certificate?
Hmmm. I did not think the document said that. The Assignment
Authority is supposed to be represented in the Identifier
Type:
" The IdentifierType field, when present, identifies both the
Assigner Authority and the type of that field."
But the Assigner Authority doesn't have to be the CA.
The document is not clear enough about how you go about
creating IdentifierType's -- I think that goes to Ted's
points. There are some underlying assumptions (aka hand
waving) that need to be reviewed.
OTOH, if there is no "IdentifierType" field, then the AA is
assumed to be the CA, and it is essentially local to that
CA. But that's not the same as repeating the CA identifier.
>
>
>>>Beyond that, the comparison rules for UTF8 strings look wrong --
>>>I'm glad there's a matching rule specified, but from the little I
>>>understand about such things there will be a lot of complaints
>>>about the lack of more CJK-friendly matching rules.
>>
>>Actually, they should not -- because URIs, as currently
>>defined, are strictly a subset of 0-127 ascii. If you
>>want anything else, you have to encode it (e.g., hex encoding).
>>
>
> OK -- but in that case, why does the document say that the
> identifier can be a UTV8 string?
Probably 'cause most people don't realize that URIs are
ascii character strings :-) I.e., I only pointed out the
matching rules should work; that may be by accident.
So, I think there are some engineering issues, but I think
we've understood the proposal differently, and perhaps
buffing off some of the engineering burrs would yield something
rational.
Leslie.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Permanent Identifier to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure - Permanent Identifier' <draft-ietf-pkix-pi-06.txt> as
a Proposed Standard. This document is the product of the PKIX Working
Group. The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
This document define a new form of name, called permanent identifier,
that may be included in the subjectAltName extension of an X.509
version 3 public key certificate. The permanent identifier is an
optional feature that may be used by a Certification Authority (CA) to
indicate that the certificate relates to the same entity even if the
name or the affiliation of that entity stored in the subject or
another name form in the subjectAltName extension has changed. The
subject name, carried in the subject field, is only unique for each
subject entity certified by the one CA as identified by the issuer
name field. Also, the new name form can carry a name that is unique
for each subject entity certified by a CA.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller for the IESG.
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 1 of 3
o draft-blumenthal-aes-usm-07.txt
The AES Cipher Algorithm in the SNMP's User-based Security Model (Proposed
Standard)
Note: Responsible: Author
Token: Steve Bellovin
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-blumenthal-aes-usm-07.txt to Proposed Standard
--------
Evaluation for draft-blumenthal-aes-usm-07.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=6713&rfc_flag=0
Last Call to expire on: 2003-04-25
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ned Freed:
Comment:
It seems to me that the password entropy discussion in 1.3 applies regardless
of the symmetric cipher that's employed and really belonged in section 11.2
of RFC 3414 rather than in a document whose goal is only to define a new
symmetric
cipher for SNMP. But the way this section is worded (e.g. "functions specified
in this document") makes it sound like the need for strong passwords is someho
specific to AES. Perhaps this could be reworded to make it clear the need is
more
general.
Russ Housley:
Discuss:
I have three DISCUSS comments:
1. In section 1.1, a normative reference to the NIST FIPS that defines AES. I suggest:
The main goal of this memo is to provide a new privacy protocol for the
USM based on the Advanced Encryption Standard (AES) [FIPS-AES].
2. The first paragraph in section 4 says:
The security of the cryptographic functions defined in this document
lies both in the strength of the functions themselves against various
forms of attack, and also, perhaps more importantly, in the keying
material that is used with them. The recommendations done in Section
1.3 MUST be followed to ensure maximum entropy to the selected
passwords, and to protect the passwords while stored.
However, the referenced section 1.3 does not contain any MUST statements. Either change the statements in section 1.3 to MUST, or change the MUST in section 4 to SHOULD.
3. The second paragraph in section 4 says:
For information regarding the necessary use of random IV values, see
[CRYPTO-B].
The document properly requires unique IVs for each encryption. Given the mode that is being used, unique IVs ought to be discussed in this paragraph too.
Comment:
In section 3.1, please remove the dash at the front of each paragraph.
Alternatively, treat it as a bulleted list by adding an introduction sentence.
Margaret Wasserman:
Comment:
A minor editorial comment that can be ignored unless a document
update is needed for other reasons:
This document uses an unusual method for defining acronyms --
just using the full name at the beginning and the acronym later,
without associating the two. Here is one example:
"The main goal of this memo is to provide a new privacy protocol for the
USM based on the Advanced Encryption Standard.
[...]
For a given user, the AES-based privacy protocol..."
I would have preferred to see Advanced Encryption Standard (AES),
as this makes it easier to associate the acronym with the name
and is consistent with other RFCs.
^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>
Subject: Protocol Action: 'The AES Cipher Algorithm in the SNMP's
User-based Security Model' to Proposed Standard
The IESG has approved following document:
- 'The AES Cipher Algorithm in the SNMP's User-based Security Model'
<draft-blumenthal-aes-usm-06.txt> as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an IETF Working Group.
The IESG contact person is Steve Bellovin.
Technical Summary
The current SNMPv3 specifications describe use of DES for security. DES is not secure; it has been deprecated and replaced by AES. This document describes how to use AES with SNMPv3.
Working Group Summary
One obvious way to use AES would be to simply replace "DES" with "AES" and "8" (the block size) with "16". But that would expand the packet even more. This protocol uses CFB mode instead of CBC mode, to prevent packet expansion.
Protocol Quality
This protocol was reviewed for the IESG by Steve Bellovin and Bert Wijnen.
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 2 of 3
o draft-rajeshkumar-mmusic-gpmd-03.txt
SDP attribute for qualifying Media Formats with Generic Parameters (Proposed
Standard)
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-rajeshkumar-mmusic-gpmd-03.txt to Proposed Standard
--------
Evaluation for draft-rajeshkumar-mmusic-gpmd-03.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9338&rfc_flag=0
Last Call to expire on: 2003-07-03
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Discuss:
The IANA considerations should use the language from rfc 2434, I suspect. It's also a bit odd to require a standards track rfc here, when a mime subtype does not, but if the WG feels strongly about this I won't argue.
This is fixable with an RFC editor's note.
Randy Bush:
Discuss:
color me discuss, but expect me to be no-ob when my lack of
understanding is addressed. i.e., my issues are not fundamental.
---
what is the need/rationale for avoiding mime registration? if
there is a real need, and i assume there is, then the document
should make it clear.
---
2.2 Offer/Answer Support
...
A bilateral gpmd parameter ...
In all other cases, operation MUST be as if
the gpmd parameter had not been included in the first place. The
only exception to this rule is in the period between the offer being
issued and the answer being received; during that time, the offerer
MAY use the operation associated with the offered gpmd parameter for
any media received for that offer.
does this mean that O could make an offer with gpmd X, and send
data which assumes successful negotiation of X before answerer A
has a chance to say "no thanks?" therefore
Correct
operation of a given media stream MUST NOT depend on one or more
participants either supporting or not supporting a given gpmd
parameter.
must be true in a very absolute sense. how is that ensured?
or, put another way, during the negotiation gap, how is this
different from a unilateral gpmd?
---
6.2 Creation of New SDP Sub-Registry for "gpmd" Parameters
omits whether the parm is bi or unilateral, and it would seem to be
best if the iana registry contained that information.
Russ Housley:
Comment:
Spell out the first use of SPD, which is in the Abstract.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: all-ietf
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>
Subject: Protocol Action: SDP attribute for qualifying Media Formats with Generic Parameters to Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'SDP attribute for qualifying Media Formats with Generic Parameters' <draft-rajeshkumar-mmusic-gpmd-03.txt> as a Proposed Standard. This has been reviewed by the MMUSIC Working Group of the IETF.
The IESG contact person is Jon Peterson.
This document defines a new SDP attribute called general-purpose media descriptor (gpmd). The gpmd attribute allows the use of new informative parameters, gpmd parameters, to qualify existing media formats. These gpmd parameters are not part of the standard (e.g., MIME) definition of the media format and support for them with a given media format can not be assumed. Their use is therefore limited to cases where they provide information that may be of use to the other party in a session but is not critical to the use of the particular media format.
This document also defines a specific gpmd parameter, voice-band data, which can be used to describe a media format as carrying voice-band data. This enables the receiver to optimize its handling of the media received.
The MMUSIC Working Group supported the publication of this document.
This document was reviewed for the IESG by Jon Peterson.
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 3 of 3
o draft-ymbk-6to4-arpa-delegation-00.txt
Delegation of 2.0.0.2.ip6.arpa (BCP)
Token: Russ Housley
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-ymbk-6to4-arpa-delegation-00.txt to BCP
--------
Evaluation for draft-ymbk-6to4-arpa-delegation-00.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9935&rfc_flag=0
Last Call to expire on: 2003-10-12
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ R ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ X ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Margaret Wasserman:
Discuss:
> [I-D.moore-6to4-dns]
> Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
> in progress), October 2002.
The last version of this draft appears to have been -04, but it has
expired.
I don't have any problem with delegating the domain, but I don't
think that it is useful to include a rationale that primarily
consists of an informative reference to an expired draft.
^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>
Subject: Protocol Action: 'Delegation of 2.0.0.2.ip6.arpa' to BCP
The IESG has approved following document:
- 'Delegation of 2.0.0.2.ip6.arpa '
<draft-ymbk-6to4-arpa-delegation-00.txt> as a BCP
This document has been reviewed in the IETF but is not the product of an IETF Working Group.
The IESG contact person is Russ Housley.
Technical Summary
This document discusses the need for delegation of the
2.0.0.2.ip6.arpa DNS zone in order to enable reverse
lookups for 6to4 addresses.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 2
o draft-ietf-ipsec-dpd-03.txt
A Traffic-Based Method of Detecting Dead IKE Peers (Informational)
Token: Russ Housley
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ipsec-dpd-03.txt to Informational RFC
--------
Evaluation for draft-ietf-ipsec-dpd-03.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7244&rfc_flag=0
Last Call to expire on: 2003-09-28
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 [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Comment:
This is very close to a DISCUSS...
As I understand the situation, the document describes current practice,
rather than defining new protocol elements. This is not clear in the
text of the document. (It also uses numbers from the private range,
which would be exceedingly bad for a standards-track protocol.) The
fourth paragraph of the Introduction, which begins "To this end",
should start something like this:
To this end, a number of vendors have implemented their own
approach to dead peer detection. This document describes how
they detect peer liveliness without needing ...
The abstract (and perhaps the title) should probably have similar changes.
^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>, <ipsec@lists.tislabs.com>
Subject: Document Action: 'A Traffic-Based Method of Detecting
Dead IKE Peers' to Informational RFC
The IESG has approved following document:
- 'A Traffic-Based Method of Detecting Dead IKE Peers '
<draft-ietf-ipsec-dpd-03.txt> as an Informational RFC
This document is the product of the IP Security Protocol Working Group.
The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
This draft describes a method of detecting a dead IKE (Internet Key
Exchange) peer. The method, called Dead Peer Detection (DPD), uses
IPsec traffic patterns to limit the number of IKE messages sent. DPD,
like other keepalive mechanisms, is often necessary to perform IKE
peer failover, or to reclaim lost resources.
Working Group Summary
The IPsec Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
RFC Editor Note
Please replace the Abstract
OLD:
This draft describes a method of detecting a dead IKE peer. The
method, called Dead Peer Detection (DPD) uses IPSec traffic patterns
to limit the number of IKE messages sent. DPD, like other keepalive
mechanisms, is often necessary to perform IKE peer failover, or to
reclaim lost resources.
NEW:
This document describes the method detecting a dead IKE peer that is
presently in use by a number of vendors. The method, called Dead
Peer Detection (DPD) uses IPSec traffic patterns to minimize the
number of IKE messages that are needed to confirm liveness. DPD,
like other keepalive mechanisms, is needed to determine when to
perform IKE peer failover, and to reclaim lost resources.
Please replace the last two paragraphs of section 1.
OLD:
To this end, this draft proposes an approach to detect peer
liveliness without needing to send messages at regular intervals.
This scheme, called Dead Peer Detection (DPD), relies on IKE Notify
messages to query the liveliness of an IKE peer.
NEW:
To this end, a number of vendors have implemented their own
approach to detect peer liveliness without needing to send messages
at regular intervals. This informational document describes the
current practice of those implementations. This scheme, called Dead
Peer Detection (DPD), relies on IKE Notify messages to query the
liveliness of an IKE peer.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 2
o draft-ietf-ipsec-nat-reqts-05.txt
IPsec-NAT Compatibility Requirements (Informational)
Token: Russ Housley
Subject: Evaluation: draft-ietf-ipsec-nat-reqts
--------
Steve Bellovin (Comments):
Minor error: the text currently says
For example, there are security risks
relating to IP source routing that are precluded
by AH, but not by ESP with null encryption.
That's only true for IPv6. Per RFC 2402, source
routing options are zeroed before calculation the
AH ICV. I suggest changing "IP" to "IPv6" in that
sentence.
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 2
o draft-ietf-ipo-framework-05.txt
IP over Optical Networks: A Framework (Informational)
Token: Alex Zinin
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 2
o draft-ietf-dhc-unused-optioncodes-07.txt
Unused DHCP Option Codes (Informational)
Note: Already approved by IESG, pulled back to remove option codes that were
actually in use.á Back again for re-approval.
Token: Margaret Wasserman
3.2.1 New Item
NONE
3. Document Actions
3.2 Individual Submissions Via AD
3.2.2 Returning Item - 1 of 1
o draft-gill-gtsh-04.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental)
Token: Alex Zinin
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 1 of 3
o draft-bless-diffserv-pdb-le-01.txt
A Lower Effort Per-Domain Behavior for Differentiated Services
(Informational)
Token: Jon Peterson
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 2 of 3
o draft-bless-diffserv-multicast-07.txt
IP Multicast in Differentiated Services Networks (Informational)
Token: Bill Fenner
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 3 of 3
o draft-ogura-mapos-nsp-multiexp-02.txt
A Multicast Extension to MAPOS NSP (Node Switch Protocol) (Informational)
Note: 2003-10-09: sent note to authors, needs better security
considerations. (no significant objection otherwise)
Token: Thomas Narten
3.3.2 Returning Item
NONE
3.3.3 To be assigned
o draft-aboulmagd-trtcm-inprofile-01.txt
Two Rate Three Color Marker for Differentiated Services (Informational)
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Credential and Provisioning (enroll) - 1 of 2
Token: Russ
Credential and Provisioning (enroll)
------------------------------------
Last Modified: 2003-10-8
Current Status: Proposed Working Group
Chair(s):
Eric Rescorla <ekr@rtfm.com>
Paul Hoffman <phoffman@imc.org>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Mailing list: ietf-enroll@mit.edu
To Subscribe: mailman@mit.edu
In Body or Subject: subscribe
Archive:
Description:
There are many cases where a service consumer needs to contact a
service provider to get credentials that the consumer can use when
accessing the service; part of this initial contact may involve
the consumer and the provider mutually validating the other's identity.
This working group will look at some of the cases where cryptography
is used to provide authentication.
When doing enrollment of a service consumer against a service provider,
three pieces of information need to be provided or created in order to
support authentication of the service consumer to the service provider
(and visa versa) and to allow for additional security services to be
provided any information exchanged. These pieces of data are:
1. An identifier, within a namespace controlled by the service
provider, for the service consumer.
2. Keying information to be used for identity confirmation.
3. A set of service consumer permissions. These permissions
describe to the provider the services that the consumer
wants to access, and they describe to the consumer what
services offered by the provider will be accessable.
Each of these data items could be created by either the consumer or
provider at any point during the enrollment process.
This group will create a model to be used in describing enrollment
procedures and create a document for a framework how this is to be done.
The group will then produce three documents profiling the use of the
framework for the following types of keying material:
1. A shared secret key.
2. A bare asymmetric key.
3. A bound asymmetric key (such as an X.509 certificate).
As part of the validation of the framework, the group will examine how
other real world enrollment procedures could be profiled. For example,
credit card information might be part of the input to the enrollment
process.
Goals and Milestones:
Nov 2003 First draft of model
Feb 2004 Last call on model document
Feb 2004 First draft of Framework document
Jun 2004 Last call on module document
May 2004 First draft of secret key profile
May 2004 First draft of bare asymmetric key profile
May 2004 First draft of bound asymmetric key profile
Oct 2004 Last call on secret key profile
Oct 2004 Last call on bare asymmetric key profile
Oct 2004 Last call on bound asymmetric key profile
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o IP over DVB (ipdvb) - 2 of 2
Token: Margaret
IP over DVB (ipdvb)
-------------------
Last Modified: 2003-10-13
Current Status: Proposed Working Group
IETF Area: Internet Area
Chair(s): Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Responsible Area Director: Margaret Wasserman
Mailing Lists:
General Discussion:ip-dvb@erg.abdn.ac.uk
To subscribe: subscribe ip-dvb at majordomo@erg.abdn.ac.uk
Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive/
Description of Working Group:
The MPEG-2 Transport Stream provides a transmission network that has become
widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T.
These, and related standards, define a set of commercially available
components that are increasingly being used to provide a general-purpose
packet transmission network. MPEG-2 Transport networks are being used to
build IP networks to supplement broadcast TV/audio services and also provide
one-way and two-way IP-only subnetworks.
There is a need to define an efficient standardised encapsulation for IPv4
and IPv6 datagrams, and to recommend procedures for supporting protocols.
Examples include dynamic address resolution, multicast group membership
reporting and possibly management information tables and MIBs. Documents
will be defined that describe protocols required to build a complete
IPv4/IPv6 unicast/multicast services, and the mappings required to perform
dynamic address resolution. The primary purpose of this working group is to
develop a set of Internet Drafts and where appropriate to progress these as
either Internet Informational RFCs or Standards track RFCs.
The current list of work items is:
1. Issue an Internet Draft specifying Requirements and Framework for
supporting IP services via MPEG-2 transmission networks. Such requirements
should consider the range of platforms currently (or anticipated to be) in
use. This draft will be submitted to the IESG for possible publication as
an Informational RFC.
2. The working group will investigate and design an efficient encapsulation
method for IPv4/IPv6, and advance this via the IESG to a standards-track
RFC. The design needs to consider the need for MAC addresses, the potential
need for synchronisation between streams, support for IPv6 and multicast
services, and support for multiple gateways (feeds).
3. The working group will consider the options for unicast and multicast
address resolution. A working group Internet Draft will define a framework
and recommend appropriate address resolution mechanisms for IPv4 and IPv6
using both the existing Multi-Protocol Encapsulation and any new
encapsulation developed by the working group. Consideration will be paid to
existing standards, and the cases for IPv6 and IPv4 will be described. This
document will be submitted to the IESG for publication as an Informational
RFC.
4. A working group Internet Draft will be written to recommend a set of
dynamic address resolution procedures for IPv6. It will describe the
protocol and syntax of the information exchanged. This work may be based on
an extension to the Neighbor Discovery (ND) protocol to support MPEG-2
transmission, and include specific optimisations for broadcast networks.
This document will be submitted to the IESG for publication as a
standards-track RFC.
5. If there is a need for further supporting protocols, it will consider a
possible recharter under the guidance of the IESG. Examples in this area
include, the negotiation/association of IP QoS with MPEG-2 transport
streams, address resolution for IPv4, and the need for SNMP MIBs.
Goals and Milestones:
Nov 2003 Issue a working group Architecture ID
Nov 2003 Issue a working group Encapsulation ID
Mar 2004 Review Encapsulation ID
Mar 2004 Review Architecture ID
Mar 2004 Issue a working group Address Resolution (AR) Framework ID
Jun 2004 Submit Architecture ID to IESG for consideration as a INFO RFC
Jun 2004 Submit Encapsulation ID to IESG for consideration as a STD RFC
Jun 2004 Review Address Resolution Framework ID
Jun 2004 Issue a working group AR Protocol ID
Sep 2004 Review AR Protocol ID
Dec 2005 Submit Address Resolution Framework ID to IESG for
consideration as an INFO RFC.
Dec 2005 Submit the AR Protocol ID to IESG for consideration as
an INFO RFC.
Dec 2005 Progress STD RFCs along standards track process.
Dec 2005 Possible recharter to investigate MIBs,
and other protocol components (if required).
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Long-Term Archive and Notary Services (ltans) - 1 of 3
Token: Russ
Long-Term Archive and Notary Services (ltans)
---------------------------------------------
Last Modified: 2003-9-25
Current Status: Proposed Working Group
CHAIR(S):
Tobias Gondrom <tobias.gondrom@ixos.de>
Carl Wallace <cwallace@orionsec.com>
SECURITY AREA DIRECTORS:
Russ Housley <housley@vigilsec.com>
Steve Bellovin <smb@research.att.com>
SECURITY AREA ADVISOR:
Russ Housley <housley@vigilsec.com>
MAILING LIST:
General Discussion: ietf-ltans@imc.org
To Subscribe: subscribe-ietf-ltans@imc.org
In Body: subscribe
To Unsubscribe: unsubscribe-ietf-ltans@imc.org
Archive: http://www.imc.org/ietf-ltans
DESCRIPTION OF WORKING GROUP:
In many scenarios, users need to be able to ensure and prove the existence
and validity of data, especially digitally signed data, in a common and
reproducible way over a long and possibly undetermined period of time.
Cryptographic means are useful, but they do not provide the whole solution.
For example, digital signatures (generated with a particular key size) might
become weak over time due to improved computational capabilities, new
cryptanalytic attacks might "break" a digital signature algorithm, public
key certificates might be revoked or expire, and so on. Complementary
methods covering potential weaknesses are necessary.
Long-term non-repudiation of digitally signed data is an important aspect
of PKI-related standards. Standard mechanisms are needed to handle routine
events, such as expiry of signer's public key certificate and expiry of
trusted time stamp authority certificate. A single timestamp is not
sufficient for this purpose. Additionally, the reliable preservation of
content across change of formats, application of electronic notarizations,
and subsequent notary services require standard solutions.
The objective of the LTANS working group is to define requirements, data
structures and protocols for the secure usage of the necessary archive and
notary services. First, the requirements for the long-term archive will be
collected. Based on that information we will develop a protocol to access
archive services supplying long-term non-repudiation for signed documents
and define common data structures and formats. Upon completion of the
archive-related specifications, we will address 'notary services' in a
similar way. The term 'notary services' is not clearly defined. The working
group will determine which functions need standards, including transformation
of documents from one format to another without losing the value of evidence,
electronic notarization, and further verification of legal validity of signed
documents. We will determine the needs via the requirements paper and act
upon the results accordingly.
Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as
the basis to define those structures and protocols. For example, the
Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive
Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server
Protocols (DVCS)", contain applicable concepts.
GOALS AND MILESTONES
Nov 03 Initial requirements for long-term archive I-D
Dec 03 Revised requirements for long-term archive I-D
Dec 03 Initial data structures for long-term archive I-D
Dec 03 Initial protocol for long-term archive I-D
Feb 04 Last call requirements for long-term archive I-D
Mar 04 Submit requirements for long-term archive to IESG as informational
Mar 04 Revised data structures for long-term archive I-D
Mar 04 Revised protocol for long-term archive I-D
Apr 04 Last call data structures for long-term archive I-D
Apr 04 Last call protocol for long-term archive I-D
May 04 Submit data structures for long-term archive to IESG as proposed standard
May 04 Submit protocol for long-term archive to IESG as proposed standard
Jul 04 Initial requirements for notary services I-D
Sep 04 Revised requirements for notary services I-D
Nov 04 Last call requirements for notary services I-D
Dec 04 Submit requirements for notary services to IESG as proposed standard
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o MIPv6 Signaling and Handoff Optimization (mipshop) - 2 of 3
Token: Thomas
MIPv6 Signaling and Handoff Optimization (mipshop)
--------------------------------------------------
Last Modified: 2003-10-06
Current Status: Proposed Working Group
Chair(s):
Gabriel Montenegro <gab@sun.com>
One more TBD
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:mipshop@ietf.org
To Subscribe: mipshop-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mipshop
Description of Working Group
Mobile IPv6 specifies routing support to permit IP hosts using IPv6 to
move between IP subnetworks while maintaining session
continuity. Mobile IPv6 supports transparency above the IP layer,
including maintenance of active TCP connections and UDP port bindings.
To accomplish this, the mobile node notifies its home agent (and
potentially also its correspondent nodes) of the current binding between its
home address and its care of address. This binding allows a mobile node
to maintain connectivity with the Internet as it moves between
subnets.
Depending on what steps a mobile node must perform on a new subnet, the
lag between when the mobile node has layer 2 connectivity and when it
begins sending and receiving packets on the new link may be
substantial. A mobile node must first detect at layer 3 that its point
of attachment has changed, then it must perform configuration on the
new link, including router discovery and configuring a new care of
address. After that, the mobile node must perform binding updates with
the home address and any correspondent nodes. Since many layer 2
mobility technologies require that the mobile node drop its link
connectivity to the old subnet when moving, any packets between the
correspondent node and the mobile node sent or in-flight during this
time arrive at the old care of address, where they are dropped. Such
packet loss may have significant adverse effects.
The Mobile IP Working group had previously been developing two
technologies to address the issues of signaling overhead and handoff
latency/packet loss:
- Hierarchical Mobile IPv6 mobility management (HMIPv6)
HMIPv6 deals with reducing the amount and latency of signaling
between a MN, its Home Agent and one or more correspondents by
introducing the Mobility Anchor Point (MAP) (a special node located
in the network visited by the mobile node). The MAP acts somewhat
like a local home agent for the visiting mobile node by limiting
the amount of signaling required outside the MAP's domain.
- Fast Handovers for Mobile IPv6 (FMIPv6)
FMIPv6 reduces packet loss by providing fast IP connectivity as
soon as a new link is established. It does so by fixing up the
routing during link configuration and binding update, so that
packets delivered to the old care of address are forwarded to the
new. In addition, FMIPv6 provides support for preconfiguration of
link information (such as the subnet prefix) in the new subnet
while the mobile node is still attached to the old subnet. This
reduces the amount of preconfiguration time in the new subnet.
These two technologies can be used separately or together to reduce or
eliminate signaling overhead and packet loss due to handoff delays in
Mobile IPv6.
Scope of MIPSHOP:
The MIPSHOP Working Group will complete the FMIPv6 and HMIPv6 work
begun in the Mobile IP Working Group. Specifically, the WG will:
1) Complete the specification of HMIPv6 protocol.
2) Complete the specification of FMIPv6 protocol.
Because work (ongoing or originating) in other working groups may
suggest changes or alternative designs for HMIPv6 and FMIPv6, these
specifications will be advanced as Experimental RFCs until more
experience is obtained with IP mobility in IPv6.
3) Complete work on a set of requirements for "Localized Mobility
Management (LMM)", whereby a Mobile Node is able to continue
receiving packets in a new subnet before the corresponding changes
in either the Home Agent or Correspondent Node binding. It is the
intention that the requirements be consistent with the FMIPv6 and
HMIPv6 protocols; in the event that there are inconsistencies, they
will be documented.
4) Complete work on the applicability of FMIPv6 in the specific case
of 802.11 networks for advancement as Informational RFC.
There are security issues that arise because of the highly dynamic
nature of the security relationships between, say, a mobile node and
its mobility anchor points, or between a mobile node and its access
routers in a fast handover scenario. The working group is not required
to provide solutions to all these issues before publishing its
experimental and informational protocols. The working group will
document the security requirements and the shortcomings of the
solutions in the corresponding protocol specifications. This will
provide valuable feedback to other groups or subsequent efforts.
Schedule
--------
OCT 03 - Working Group Last Call on draft-ietf-mipshop-lmm-requirements-XX.txt
OCT 03 - Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt.
NOV 03 - Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt.
NOV 03 - Discuss Last Call comments and security analyses at IETF 58.
DEC 03 - Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt to IESG
for consideration of publication as Informational.
JAN 04 - Submit draft-ietf-mipshop-hmip-xx.txt to IESG for consideration
of publication as Experimental.
JAN 04 - Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for consideration
of publication as Experimental.
FEB 04 - Working Group Last Call on draft-ietf-mipshop-80211fh-xx.txt
for Informational
APR 04 - Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for
consideration of publication as Informational.
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Internet and Management Support for Storage (imss) - 3 of 3
Token: Margaret
Internet and Management Support for Storage (imss)
--------------------------------------------------
Last Modified: 2003-10-3
Current Status: Proposed Working Group
Chair(s):
Elizabeth Rodriguez <Elizabeth.Rodriguez@dothill.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Margaret Wasserman <margaret.wasserman@nokia.com>
Technical Advisor(s):
David L. Black <black_david@emc.com>
Keith McCloghrie <kzm@cisco.com>
Mailing Lists:
General Discussion: imss@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/imss
Archive: http://www1.ietf.org/mail-archive/working-groups/imss/
Description of Working Group:
Fibre Channel is a high speed network technology primarily used for
storage networking (i.e., Storage Area Networks [SANs]). Two
important aspects of Fibre Channel interact with the Internet:
- Fibre Channel can encapsulate and carry IP protocol traffic
- Fibre Channel devices can be managed via SNMP
The Internet and Management Support for Storage WG (imss) is chartered
to address two areas, specifically:
- IPv4 over Fibre Channel has been specified in RFC 2625. A
corresponding specification for IPv6 is needed.
- An initial Fibre Channel Management MIB has been developed by
the IP Storage (ips) WG; extensions are needed to encompass
management of additional aspects of Fibre Channel, such
as zoning.
In the future, other storage related MIBs for other storage transports
such as Serial Attached SCSI (SAS) or SCSI command specific MIBs may
be proposed.
As Fibre Channel standardization is handled by the INCITS T11 Technical
Committee (http://www.t11.org), a close working relationship with T11 is
essential to the WG's success. In particular:
- The IPv6 over Fibre Channel specification will be based on
draft-desanti-ipv6-over-fibre-channel-02.txt. This draft
was originally developed within a T11 study group and T11
has officially recommended this draft to the IETF.
- The WG will not standardize management of Fibre Channel features
ahead of their incorporation into appropriate T11 Fibre
Channel standards.
- The WG will work closely with T11, specifically Task Group T11.5,
on the functionality and structure of the MIBs it develops
for management of Fibre Channel.
Goals and Milestones:
Dec 03 Submit IPv6 over Fibre Channel draft to IESG for consideration
as Proposed Standard
WWW 04 Submit Extensions for Fibre Channel Interfaces MIB to IESG for
consideration as Proposed Standard
XXX 04 Submit Fibre Channel Domain Manager MIB to IESG for consideration
as Proposed Standard
YYY 04 Submit Fibre Channel Name Server MIB to IESG for consideration
as Proposed Standard
ZZZ 04 Work with T11.5 to determine what additional MIB modules are needed.
Dec 04 Review working group charter and determine what additional work,
if any, should be undertaken by working group.
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
4.2.2 Proposed for Approval
o Multiprotocol Label Switching (mpls) - 1 of 3
Token: Alex
Multiprotocol Label Switching (mpls)
-------------------------------------
Last Modified: 2003-10-02
Current Status: Active Working Group
Chair(s):
George Swallow <swallow@cisco.com>
Loa Andersson <loa@pi.se>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: mpls@uu.net
To Subscribe: mpls-request@uu.net
In Body: subscribe (unsubscribe)
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html
Description of Working Group:
The MPLS working group is responsible for standardizing a base
technology for using label switching and for the implementation of
label-switched paths over various packet based link-level
technologies, such as Packet-over-Sonet, Frame Relay, ATM, and
LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.).
This includes procedures and protocols for the distribution of
labels between routers and encapsulation.
The working group is also responsible for specifying the necessary
MIBs for the functionality specified in the base MPLS technology.
The first generation of the MPLS standards are largely complete,
and the current WG work items are:
- procedures and protocols for multicast protocol extensions for
point-to-multipoint TE, including soft-preemption
- Define requirements and mechanisms for MPLS OAM
- Define an overall OAM framework for MPLS applications
- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS
in cooperation with the CCAMP WG
- Determine (with CCAMP) what procedures are appropriate for evaluating
proposals to extend the MPLS and GMPLS protocols, and document these
The Working Group chairs tracking of the working group documents can be
viewed at http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm
Goals and Milestones:
Done Submit documents from original MPLS effort to IESG
Done Framework for IP multicast over label-switched paths ready for advancement.
Done LDP fault tolerance specification ready for advancement to Proposed Standard.
Done Specification for MPLS-specific recovery ready for advancement.
Done Submit Multiprotocol Label Switching (MPLS) Forward
Equivalency Class-To-Next Hop Label Forwarding Entry
Management Information Base to the IESG for publication as
Proposed Standards
Done Submit Definitions of Managed Objects for MultoiProtocol
Label Switching, Label Distribution Protocol (LDP) to the
IESG for publication as Proposed Standards
Done Submit Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR), Management Information Base to the IESG for
publication as Proposed Standards
Done Submit Multiprotocol Label Switching (MPLS) Management Overview
to the IESG for publication as Proposed Standards
Done Submit Definitions of Textual Conventions for Multiprotocol
Label Switching (MPLS) Management to the IESG for publication
as Proposed Standards
Done Submit Multiprotocol Label Switching (MPLS) Traffic
Engineering Management Information Base to the IESG for
publication as Proposed Standards
Oct 03 Advance the Label Distribution Protocol to Draft Standard.
Oct 03 Submit the Traffic Engineering Link MIB to the IESG for
as a Proposed Standard
Oct 03 Submit a specification on Encapsulations to carry MPLS over
IP and GRE to the IESG for as a Proposed Standard
Nov 03 Together with CCAMP complete and establish the (G)MPLS change
process
Apr 04 Advance MPLS Architecture and MPLS encapsulation to Draft
Standard
Apr 04 Submit a specification on Soft Pre-emption of LSP Tunnels to
the IESG for publication as a Proposed Standard
Nov 03 Submit specification on LSP Ping to the IESG for publication
as a Proposed Standard
Apr 04 Submit specification on LSR Self Test to the IESG for
publication as a Proposed Standard
Aug 04 Submit an OAM Framework Document to the IESG for publication
as an Informational RFC
Oct 04 Advance "Extension to RSVP for LSP Tunnels" to Draft
Standard
Nov 04 Submit a document defining the scope, requirements, and issues
to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)
Mar 04 Submit document(s) specifying protocol extensions, enhancements
and mechanisms for setup of P2MP TE LSPs
</charter>
FYI, removed or replaced milestones:
REMOVE Shepherd completed MPLS specifications through IESG review and RFC editor
processing
REMOVE MPLS-TE MIB ready for advancement to Proposed Standard
REMOVE Base MPLS Proposed Standard RFCs ready for advancement to Draft Standard.
REMOVE LDP end-to-end LSP authentication ready for advancement to Proposed Standard.
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
o Common Control and Measurement Plane (ccamp) - 2 of 3
Token: Alex
Common Control and Measurement Plane (ccamp)
--------------------------------------------
Last Modified: 2003-10-08
Current Status: Active Working Group
Chair(s):
Adrian Farrel <adrian@olddog.co.uk>
Kireeti Kompella <kireeti@juniper.net>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: http://ops.ietf.org/lists/ccamp
Description of Working Group:
Organizational Overview
The CCAMP working group coordinates the work within the IETF defining
a common control plane and a separate common measurement plane for
physical path and core tunneling technologies of Internet and telecom
service providers (ISPs and SPs), e.g. O-O and O-E-O optical
switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
with the MPLS WG. In this context, measurement refers to the
acquisition and distribution of attributes relevant to the setting up
of tunnels and paths.
CCAMP WG work scope includes:
- Definition of protocol-independent metrics and parameters
(measurement attributes) for describing links and paths that are
required for routing and signaling. These will be developed in
conjunction with requests and requirements from other WGs (e.g.
TEWG) to insure overall usefulness.
- Definition of protocol(s) and extensions to them required for
link and path attribute measurement. Link Management Protocol (LMP)
is included here.
- Functional specification of extensions for routing (OSPF, ISIS) and
signalling (RSVP-TE) required for path establishment. Protocol formats
and procedures that embody these extensions will be done jointly with
the WGs supervising those protocols.
- Definition of the mechanisms required to determine the route and
properties of an established path (tunnel tracing).
- Definition of MIB modules relevant to the protocols and extensions
specified within the WG.
CCAMP WG currently works on the following tasks:
- Define how the properties of network resources gathered by a
measurement protocol can be distributed in existing routing
protocols, such as OSPF and IS-IS. CCAMP defines the generic
description of the properties and how they are distributed in OSPF.
The specifics of distribution within IS-IS are being addressed in
the ISIS WG.
- Define signaling and routing mechanisms to make possible the creation
of paths that span multiple IGP areas, multiple ASes, and multiple
providers, including techniques for crankback.
- Define abstract link and path properties needed for link and path
protection. Specify signalling mechanisms for path protection,
diverse routing and fast path restoration. Ensure that multi-layer
path protection and restoration functions are achievable using the
defined signalling, routing, and measurement protocols, either
separately or in combination.
- Identify which requirements for signaling and routing for ASON are
not currently met by protocols defined in CCAMP; based on these,
define mechanisms to address these requirements.
- Define a protocol that can determine the actual route and other
properties of paths set up by CCAMP signaling protocols, as well
as other types of tunnels (tunnel tracing).
In doing this work, the WG will work closely with at least the following
other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
ITU-T.
Goals and Milestones:
Done Post strawman WG goals and charter
Done Identify and document a limited set of candidate solutions for signalling
and for measurement. Among candidate control solutions to be considered
are the existing GMPLS drafts
Done Build appropriate design teams
Done Submit WG document defining path setup portions of common control plane
protocol
Done Submit WG document defining common measurement plane protocol
Nov 03 Submit LMP MIB to IESG
Dec 03 Submit GMPLS MIBs to IESG
Dec 03 Submit protection & restoration documents to IESG
Dec 03 Submit ASON signaling requirements doc to IESG
Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
Jan 04 Submit ASON routing requirements doc to IESG
Mar 04 Submit revised charter and milestones to IESG for IESG consideration of
more detailed deliverables and determination of usefulness of
continuation of WG
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
o Ethernet Interfaces and Hub MIB (hubmib) - 3 of 3
Token: Bert
Ethernet Interfaces and Hub MIB (hubmib)
----------------------------------------
Last Modified: 2003-9-24
Current Status: Active Working Group
Chair(s):
Dan Romascanu <dromasca@avaya.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: hubmib@ietf.org
To Subscribe: hubmib-request@ietf.org
In Body: subscribe your_email_address
Archive: www.ietf.org/mail-archive/working-groups/hubmib/current/maillist
Description of Working Group:
The Ethernet Interfaces and Hub MIB WG is Chartered to define
a set of managed objects that instrument devices, MAUs and
interfaces that conform to the IEEE 802.3 standard for Ethernet.
This set of objects should be largely compliant with, and even
draw from IEEE 802.3, although there is no requirement that any
specific object be present or absent.
Close coordination with hardware standards development in
IEEE 802.3 will be followed. The WG chair will support the
communication with IEEE 802.3. When objects are added that
require hardware support, IEEE 802.3 shall be informed,
so that they consider to add them to their draft/standard.
The MIB object definitions produced will be for use by SNMP and
will be adequately consistent with other SNMP objects, standards
and conventions.
The working group will work on the following MIB modules
for the IEEE 802.3ah (Ethernet First Mile) interfaces and
devices:
- Ethernet First Mile (EFM) MIB
common attributes, OAM operations and statistics
- Copper EFM MIB
- Ethernet Passive Optical Networks (EPON) MIB
The base for the definition of the managed objects in these
MIB modules will be the management-related clauses in IEEE
802.3ah specification. The working group will also take
into consideration management objects defined by other
Working Groups in the IETF (ADSL MIB for example), or other
standard bodies (G.983.2), will avoid work duplication,
and describe the relationship with these specifications.
Goals and Milstones
< keep complete list of DONE work items for archival reasons >
Oct 2003 - Individual submissions for the EFM MIB modules
Dec 2003 - First round of WG Internet-Drafts for the
EFM MIB modules
Apr 2004 - Working Group Last Call
Jun 2004 - Submit the Internet-Drafts to the IESG for
consideration as Proposed Standards
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
7.1 EDU Team updated charter (Harald Alvestrand)
Suggested procedure:
- The IESG sends this charter to the community for review.
Cover note:
The IESG is considering creation of a formalized "education team" to manage
the IETF education efforts, which have so far been managed informally.
This is a new type of entity in the IETF, and community feedback is
therefore sought both on the specific charter and on the concept of having
"teams" with documented charters as part of the IETF's activities.
Please respond to the IESG (iesg@ietf.org) no later than October 29.
Note: The mailing lists mentioned in the charter are already operational.
Feel free to subscribe, contribute or browse their archives.
---------- Team charter ----------
Education Team Charter
======================
[Draft Version: 05]
OVERVIEW:
The education team manages the internal education efforts of the IETF,
primarily focused on role and process education for IETF participants
and leaders.
STRUCTURE:
This effort is managed by a core education team, consisting of a team
leader and several members. The team leader is appointed by the
General Area Director, and the members of the team are chosen by the
team leader, with the approval of the General Area Director.
In order to allow for community visibility and input into our
educational activities:
- The education team will maintain a web site linked to from
the IETF web pages, which will include the latest educational
infromation and materials.
- The web site will also include:
> The members of the education team.
> A detailed action plan describing the plans and
schedule for education team activities.
> Minutes from all education team meetings.
- The archives of the education team mailing list will be publicly
available, and accessible from the web site.
- The education team will hold occasional open meetings at IETF
meetings (approximately one per year) to receive community input
and feedback.
- A public discussion mailing list will be maintained, for open
discussion of our internal education efforts.
CURRENT RESPONSIBILITIES (As of Sept 2003):
The education team is responsible for maintaining and enhancing our
current education efforts, including:
- Newcomer's training
- Security tutorial
- Introductory WG Chairs training
- Ongoing WG Chairs training (topical)
- Sessions for ongoing participants (topical)
This includes scheduling and logistical planning for these sessions,
deciding what will be presented by whom at topical sessions, managing
the development and review of training materials, and maintaining an
archive of the training materials and session minutes on the education
team web site.
In addition to formal training sessions, this group may consider
other approaches to meeting our educational goals, such as
mentoring/buddy programs, web-based training tutorials, and/or the
publication of educational documents as Informational RFCs.
FUTURE PLANS (Sept 2003-Sept 2004):
Over the next year, we will enhance and extend our current training
activities for participants and WG chairs, based on community
feedback and the judgement of the education team.
We will add a training session for current and aspiring document
editors.
We will also undertake educational efforts to help more non-North
Americans to be effective in the IETF. This is likely to include
education for North Americans regarding ways to make our meetings more
accessible to non-native English speakers, as well as new and/or
translated training sessions or educational resources for non-North
American participants.
CONTACT INFORMATION:
Team Leader:
Margaret Wasserman <margaret.wasserman@nokia.com>
General Area Director:
Harald Alvestrand <harald@alvestrand.no>
Mailing Lists:
Education Team: edu-team@ietf.org
Archive: https://www.ietf.org/mailman/listinfo/edu-team
General Discussion: edu-discuss@ietf.org
Subscribe/Archive: https://www.ietf.org/mailman/listinfo/edu-discuss
--==========FC842F3D049EB74BBD88==========
[Enclosed message/rfc822 [edu-team]]
------_=_NextPart_001_01C386CE.A866D3AA
Here is a new version of the charter that addresses Harald's
comment and updates my contact information. Harald, I think
that this should be ready for IESG discussion...
Margaret
------_=_NextPart_001_01C386CE.A866D3AA
Education Team Charter
======================
[Draft Version: 05]
OVERVIEW:
The education team manages the internal education efforts of the IETF,
primarily focused on role and process education for IETF participants
and leaders.
STRUCTURE:
This effort is managed by a core education team, consisting of a team
leader and several members. The team leader is appointed by the
General Area Director, and the members of the team are chosen by the
team leader, with the approval of the General Area Director.
In order to allow for community visibility and input into our
educational activities:
- The education team will maintain a web site linked to from
the IETF web pages, which will include the latest educational
infromation and materials.
- The web site will also include:
> The members of the education team.
> A detailed action plan describing the plans and
schedule for education team activities.
> Minutes from all education team meetings.
- The archives of the education team mailing list will be publicly
available, and accessible from the web site.
- The education team will hold occasional open meetings at IETF
meetings (approximately one per year) to receive community input
and feedback.
- A public discussion mailing list will be maintained, for open
discussion of our internal education efforts.
CURRENT RESPONSIBILITIES (As of Sept 2003):
The education team is responsible for maintaining and enhancing our
current education efforts, including:
- Newcomer's training
- Security tutorial
- Introductory WG Chairs training
- Ongoing WG Chairs training (topical)
- Sessions for ongoing participants (topical)
This includes scheduling and logistical planning for these sessions,
deciding what will be presented by whom at topical sessions, managing
the development and review of training materials, and maintaining an
archive of the training materials and session minutes on the education
team web site.
In addition to formal training sessions, this group may consider
other approaches to meeting our educational goals, such as
mentoring/buddy programs, web-based training tutorials, and/or the
publication of educational documents as Informational RFCs.
FUTURE PLANS (Sept 2003-Sept 2004):
Over the next year, we will enhance and extend our current training
activities for participants and WG chairs, based on community
feedback and the judgement of the education team.
We will add a training session for current and aspiring document
editors.
We will also undertake educational efforts to help more non-North
Americans to be effective in the IETF. This is likely to include
education for North Americans regarding ways to make our meetings more
accessible to non-native English speakers, as well as new and/or
translated training sessions or educational resources for non-North
American participants.
CONTACT INFORMATION:
Team Leader:
Margaret Wasserman <margaret.wasserman@nokia.com>
General Area Director:
Harald Alvestrand <harald@alvestrand.no>
Mailing Lists:
Education Team: edu-team@ietf.org
Archive: https://www.ietf.org/mailman/listinfo/edu-team
General Discussion: edu-discuss@ietf.org
Subscribe/Archive: https://www.ietf.org/mailman/listinfo/edu-discuss
------_=_NextPart_001_01C386CE.A866D3AA--
_______________________________________________
edu-team mailing list
edu-team@ietf.org
https://www1.ietf.org/mailman/listinfo/edu-team
--==========FC842F3D049EB74BBD88==========--