[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for September 18, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the September 18, 2003 IESG Teleconference
This agenda was generated at 15:58:1 EDT, September 17, 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 draft-ietf-iptel-trip-mib-08.txt
Management Information Base for Telephony Routing over IP (TRIP)
(Proposed Standard) - 1 of 6
Token: Jon Peterson
o Two-document ballot: - 2 of 6
- draft-ietf-sacred-framework-06.txt
Securely Available Credentials - Credential Server Framework
(Informational)
Note: Responsible: Responsible AD
- draft-ietf-sacred-protocol-bss-08.txt
Securely Available Credentials Protocol (Proposed Standard)
Token: Steve Bellovin
o draft-ietf-mobileip-aaa-nai-06.txt
AAA NAI for Mobile IPv4 Extension (Proposed Standard) - 3 of 6
Note: Ready for IESG review; Note that IETF LC ends on September 17.
Token: Thomas Narten
o draft-ietf-pkix-logotypes-11.txt
Internet X.509 Public Key Infrastructure: Logotypes in X.509
certificates (Proposed Standard) - 4 of 6
Note: Minor changes have been made while waiting on IESG action
Token: Steve Bellovin
o draft-iab-isocbot-00.txt
IETF ISOC Board of Trustee Appointment Procedures (BCP) - 5 of 6
Token: Harald Alvestrand
o Three-document ballot: - 6 of 6
- draft-ietf-mpls-ldp-mib-13.txt
Definitions of Managed Objects for the Multiprotocol Label
Switching, Label Distribution Protocol (LDP) (Proposed Standard)
- draft-ietf-mpls-ftn-mib-08.txt
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To
Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information
Base (Proposed Standard)
Note: Check with chairs on status
- draft-ietf-mpls-te-mib-12.txt
Multiprotocol Label Switching (MPLS) Traffic Engineering Management
Information Base (Proposed Standard)
Note: waiting for update. check with chairs
Token: Alex Zinin
2.1.2 Returning Item
o Five-document ballot: - 1 of 2
- draft-ietf-impp-cpim-msgfmt-08.txt
Common Presence and Instant Messaging: Message Format (Proposed
Standard)
- draft-ietf-impp-cpim-pidf-08.txt
Presence Information Data Format (PIDF) (Proposed Standard)
- draft-ietf-impp-pres-03.txt
Common Profile for Presence (CPP) (Proposed Standard)
- draft-ietf-impp-im-03.txt
Common Profile for Instant Messaging (CPIM) (Proposed Standard)
Note: See private comments for proposed RFC Editor note re: ABNF; no
SRV comments yet received, and other issues believed to be resolved
with doc updates.á On the agenda to flush out SRV comments or
progress.
- draft-ietf-impp-srv-03.txt
Address Resolution for Instant Messaging and Presence (Proposed
Standard)
Token: Ted Hardie
o draft-ietf-webdav-ordering-protocol-10.txt
WebDAV Ordered Collections Protocol (Proposed Standard) - 2 of 2
Note: Text added to clear Allison's issue with ordering semantics
Token: Ted Hardie
2.2 Individual Submissions
2.2.1 New Item
o draft-mrose-ietf-posting-03.txt
A Practice for Revoking Posting Rights to IETF mailing lists (BCP) - 1
of 1
Token: Steve Bellovin
2.2.2 Returning Item
o draft-zeilenga-ldap-user-schema-mr-00.txt
LDAP: Additional Matching Rules (Proposed Standard) - 1 of 1
Note: This is a proper subset of draft-zeilenga-ldap-user-schema, and
it is proposed that it be advanced while the other bits are
revised. Proposed RFC-editor note in comments.
Token: Ted Hardie
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-send-psreq-03.txt
IPv6 Neighbor Discovery trust models and threats (Informational) - 1 of
5
Token: Margaret Wasserman
o draft-ietf-ieprep-ets-telephony-06.txt
IP Telephony Requirements for Emergency Telecommunication Service
(Informational) - 2 of 5
Token: Jon Peterson
o draft-iesg-charter-03.txt
An IESG charter (Informational) - 3 of 5
Token: Steve Bellovin
o draft-ietf-pkix-warranty-extn-03.txt
Internet X.509 Public Key Infrastructure Warranty Certificate Extension
(Informational) - 4 of 5
Token: Steve Bellovin
o draft-ietf-tsvwg-highspeed-01.txt
HighSpeed TCP for Large Congestion Windows (Experimental) - 5 of 5
Token: Jon Peterson
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-rfc-editor-rfc2223bis-07.txt
Instructions to Request for Comments (RFC) Authors (Informational) - 1
of 2
Note: Responsible: Harald Alvestrand
Token: Harald Alvestrand
o draft-mealling-liberty-urn-00.txt
A URN Namespace For The Liberty Alliance Project (Informational) - 2 of
2
Token: Ted Hardie
3.2.2 Returning Item
o draft-siemborski-mupdate-04.txt
The MUPDATE Distributed Mailbox Database Protocol (Experimental) - 1 of
1
Note: On IESG agenda
Token: Ned Freed
3.2.3 To be assigned
o draft-baker-soap-media-reg-03.txt
The 'application/soap+xml' media type (Informational)
o draft-klensin-name-filters-03.txt
User Interface Evaluation and Filtering of Internet Addresses and
Locators -or- Syntaxes for Common Namespaces (Informational)
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-fleming-ldap-printer-schema-02.txt
Lightweight Directory Access Protocol (LDAP):Schema for Printer
Services (Informational) - 1 of 2
Token: Ted Hardie
o draft-touch-ipsec-vpn-05.txt
Use of IPsec Transport Mode for Dynamic Routing (Informational) - 2 of
2
Token: Russ Housley
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o MIPv6 Signaling and Handoff Optimization - 1 of 2
Token: Thomas
o Storage Transport - 2 of 2
Token: Margaret
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Common Control and Measurement Plane - 1 of 1
Token: Alex
4.2.2 Proposed for Approval
NONE
5. Agenda Working Group News
6. IAB News We can use
7. Management Issue
7.1 Appropriate Methods for getting Meeting Minutes from Chairs (Harald Alvestrand)
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
7.3 Nomcom - List of open positions and appoint a Liaison
7.4 Tony Hain appeal (Harald Alvestrand)
7.5 Todd Glassey appeal (Bert Wijnen)
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the September 18, 2003 IESG Teleconference
This package was generated at 15:58:2 EDT, September 17, 2003.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, September 18,
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---Regrets
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 September 4, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Randy Bush / IIJ
Michelle Cotton / ICANN
Bill Fenner / AT&T
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Thomas Narten / IBM
Jennifer Rodriguez / ICANN
Dinara Suleymanova / IETF Secretariat
Amy Vezza / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Leslie Daigle / Verisign (IAB)
Ned Freed / Sun Microsystems
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Margaret Wasserman / Wind River
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the August 21, 2003 Teleconference were approved.
The Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
NONE
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 Steve Bellovin to propose a different document classification
than the current info/proposed/etc.
o Alex Zinin to phrase a question to RTG and OPS Area. Directoriats
and IAB on PPVPN issue. Alex to summarize the results as a proposed
IESG consensus regarding the PPVPN issue to be given to the PPVPN
working group.
NEW:
o Thomas Narten will send his comments on Creating, Rechartering
and Closing a Working Group to the IESG mailing list.
o Harald Alvestrand will send a proposed authentication method for
Liaison Statement submission to the Secretariat.
o Steve Bellovin will draft a message to the RFC Editor regarding
the early assignment of an RFC number for draft-housley-ccm-mode.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
NONE
2.1.2 Returning Item
o Five-document ballot: - 1 of 2
- draft-ietf-secsh-architecture-14.txt
SSH Protocol Architecture (Proposed Standard)
- draft-ietf-secsh-connect-17.txt
SSH Connection Protocol (Proposed Standard)
- draft-ietf-secsh-transport-16.txt
SSH Transport Layer Protocol (Proposed Standard)
- draft-ietf-secsh-userauth-17.txt
SSH Authentication Protocol (Proposed Standard)
- draft-ietf-secsh-assignednumbers-04.txt
SSH Protocol Assigned Numbers (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order
to resolve points raised by Russ Housley.*
o draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt - 2 of 2
DNS Configuration Options for DHCPv6 (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order
to resolve points raised by Margaret Wasserman on behalf of
IANA.*
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-magma-snoop-09.txt - 1 of 2
Considerations for IGMP and MLD Snooping Switches (Informational)
Token: Margaret Wasserman
The document was defered to the next teleconference by Randy Bush.
o draft-ietf-ipv6-prefix-delegation-requirement-03.txt - 2 of 2
Requirements for IPv6 prefix delegation (Informational)
Token: Thomas Narten
The document remains under discussion by the IESG.*
3.1.2 Returning Item
o draft-ietf-manet-tbrpf-10.txt - 1 of 1
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Alex Zinin
The document remains under discussion by the IESG.*
3.2 Individual Submissions Via AD
3.2.1 New Item
NONE
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-hollenbeck-rfc2832bis-03.txt - 1 of 1
VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
(Informational)
Token: Ted Hardie
The IESG has no problem with the RFC editor publishing this
document. The Secretariat will send a standard "no problem"
message to the RFC Editor.
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Centralized Conferencing - 1 of 2
Token: Allison Mankin
The charter for the new working group was removed from
consideration by Allison Mankin at the beginning of the
teleconference.
o Mobility for IPv6 - 2 of 2
Token: Thomas Narten
The IESG has approved the creation of the working group pending
resubmission of the charter by Thomas Narten. The Secretariat
will send a WG Action Announcement with copies to the working
group chairs.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
7.1 Procedures for Creating, Rechartering and Closing a Working
Group (Harald Alvestrand)
This management issue was discussed.
7.2 Recording Retention Policy (Ted Hardie)
This management issue was discussed. It was decided that the
recording of each IESG teleconference would be kept only until
the beginning of the next IESG teleconference.
7.3 draft-baker-liaisons-00.txt (Bert Wijnen)
This management issue was discussed.
7.4 Early RFC number for draft-housley-ccm-mode (Steve Bellovin)
This management issue was discussed.
7.5 Tony Hain appeal (Harald Alvestrand)
This management issue was discussed. Rob Austein, Michelle
Cotton, and Jennifer Rodriguez left the teleconference prior to
the discussion. Thomas Narten remained since the discussion was
slated to be fact-finding only.
7.6 Todd Glassey appeal (Bert Wijnen)
This management issue was discussed. Harald Alvestrand, Steve
Bellovin, and Rob Austein left the teleconfernce prior to the
discussion.
----------------------------------------
* 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: September 8, 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 Steve Bellovin to propose a different document classification than the current
info/proposed/etc.
IP o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
IP o Thomas Narten will send his comments on Creating, Rechartering
and Closing a Working Group to the IESG mailing list.
IP o Harald Alvestrand will send a proposed authentication method for
Liaison Statement submission to the Secretariat.
IP o Steve Bellovin will draft a message to the RFC Editor regarding
the early assignment of an RFC number for draft-housley-ccm-mode.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 6
o draft-ietf-iptel-trip-mib-08.txt
Management Information Base for Telephony Routing over IP (TRIP)
(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-ietf-iptel-trip-mib -
Management Information Base for Telephony Routing over IP (TRIP)
--------
Last Call to expire on: 2003-09-16
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 [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ned Freed:
Comment:
General question: Is the use of RFC 2788 here (and probably elsewhere) going to
mean it needs to advance to draft at some point?
^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>, <iptel@ietf.org>
Subject: Protocol Action: 'Management Information Base for
Telephony Routing over IP (TRIP)' to Proposed Standard
The IESG has approved following document:
- 'Management Information Base for Telephony Routing over IP (TRIP) '
<draft-ietf-iptel-trip-mib-08.txt> as a Proposed Standard
This document is the product of the IP Telephony Working Group.
The IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
This memo defines a portion of the MIB (Management Information Base)
module for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects
that are used to manage for TRIP (Telephony Routing over IP)
devices. TRIP, which is modeled on BGP-4, is a protocol for
advertising application-layer routes for particular telephone
numbers (for example, those leading to gateways or other devices).
The telephony routing devices required for the use of TRIP have
significant management needs.
Working Group Summary
The IPTEL WG strongly supports this document, which has undergone
considerable refinement in the last year.
Protocol Quality
This document was reviewed for the IESG by Bert Wijnen, Dan
Romascanu, and Jon Peterson.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 2 of 6
o Two-document ballot:
- draft-ietf-sacred-protocol-bss-08.txt
Securely Available Credentials Protocol (Proposed Standard)
- draft-ietf-sacred-framework-06.txt
Securely Available Credentials - Credential Server Framework
(Informational)
Note: Responsible: Responsible AD
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-ietf-sacred-protocol-bss -
Securely Available Credentials Protocol
--------
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 [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <ietf-sacred@imc.org>
Subject: Protocol Action: 'Securely Available Credentials
Protocol' to Proposed Standard
The IESG has approved following documents:
- 'Securely Available Credentials Protocol'
<draft-ietf-sacred-protocol-bss-08.txt> as a Proposed Standard
- 'Securely Available Credentials - Credential Server Framework'
<draft-ietf-sacred-framework-06.txt> as an Informational RFC
These documents are products of the Securely Available Credentials Working Group.
The IESG contact persons are Steve Bellovin and Russ Housley.
Technical Summary
Certificates and other cryptographic credentials are ungainly things, not
suitable to human memorization. While smart cards and the like are one
possible solution, they're not widely deployed or used for general-purpose
computing. The SACRED protocol permits remote storage and retrieval of
such credentials.
Working Group Summary
There was working group consensus on this document.
Protocol Quality
This protocol was reviewed for the IESG by Steve Bellovin
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 6
o draft-ietf-mobileip-aaa-nai-06.txt
AAA NAI for Mobile IPv4 Extension (Proposed Standard)
Note: Ready for IESG review; Note that IETF LC ends on September 17.
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-mobileip-aaa-nai -
AAA NAI for Mobile IPv4 Extension
--------
Last Call to expire on: 2003-09-17
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 [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ XX] [ ] [ X ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Discuss:
The text says
"It is assumed that the Mobile IP
messages that would carry these extensions would be authenticated in
the manner that is described in [4], or any follow-on authentication
mechanisms."
That leaves the mandatory-to-implement status unclear. It should say
"The Mobile IP messages that carry this extension MUST be authenticated
as described in [4], unless other authentication methods have been agreed
upon." This can be fixed with an RFC Editor's Note, I suspect.
Ted Hardie:
Discuss:
2. Requirements terminology
<snip>
The Mobile IP related described in RFC 3344 [1] is used in this
document.
TH> Above statement seems to be a duplicate of that below, or is missing
a noun.
Section 4.
The Home Agent MUST provide this in the first Registration Reply sent
to the Mobile Node destined through the AAA infrastructure. The
extension only need to be included in subsequent Registration Replies
if the same extension is included in Registration Requests received
from the same Mobile Node.
****>Why is this a MUST? It looks like the choice to use this is
deployment specific.
A mobile node that recieves this extension in a registration reply
message MUST provide it in every registration request when re-
authentication is needed. If the mobile node requests a specific
home agent and it has the information available it MUST provide this
extension in its initial registration request.
****>This seems to imply there are no conditions under which the
mobile node would go back to the base state, which seems odd
(at the very least, a failure to reach the AAAH looks like it ought to
result in a reversion to base state)
Thomas Narten:
Comment:
testing of comments
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <mobile-ip@sunroof.eng.sun.com>
Subject: Protocol Action: 'AAA NAI for Mobile IPv4 Extension' to
Proposed Standard
The IESG has approved following document:
- 'AAA NAI for Mobile IPv4 Extension '
<draft-ietf-mobileip-aaa-nai-06.txt> as a Proposed Standard
This document is the product of the IP Routing for Wireless/Mobile Hosts
Working Group.
The IESG contact persons are Thomas Narten and Margaret Wasserman.
Technical Summary
When a mobile node moves from one foreign networks to another, it has
to be reauthenticated at the new foreign network. If the home network
has multiple AAA servers the reauthentication request may not be
directed to the same AAAH that processed previous authentication
requests. In order for the new Home AAA server to be able to forward
the request to the appropriate Home Agent, it has to know the identity
of the Home Agent the mobile node is using. This document defines an
extension that enables the HA to pass its identity to the mobile node
which can in turn pass it to the AAA server when changing point of
attachment. This document specifies a Mobile IP NAI extension that
can carry these NAIs.
Working Group Summary
There was consensus in the WG for this extension.
Protocol Quality
The specification has been reviewed for the IESG by Thomas Narten.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 6
o draft-ietf-pkix-logotypes-11.txt
Internet X.509 Public Key Infrastructure: Logotypes in X.509
certificates (Proposed Standard)
Note: Minor changes have been made while waiting on IESG action
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-ietf-pkix-logotypes -
Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates
--------
Last Call to expire on: 2003-06-19
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ X ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ X ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ ] [ R ]
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:
======================
Harald Alvestrand:
Discuss:
Image/JPEG, Image/GIF and Audio/MPEG are not included in references.
Image/JPEG is OK (registry refers to RFC 2046, which has a ref to the
JPEG spec), but Image/GIF doesn't have a good reference (the RFC 2046
reference in IANA's database is erroneous).
Audio/MPEG is OK, but needs to reference RFC 3003.
I also agree with Ned's comments about describing data.
Also, the spec uses an URI without specifying any usage guidelines for
it - in theory, one could validly insert an LDAP: URI or a mailto: URI -
it's unclear how an interpreter is supposed to interpret that.
Ned Freed:
Discuss:
It isn't clear whether the mimeType field is restricted to a MIME
type/subtype pair or whether it allows for specification of MIME
type parameters. I note that some audio types use parameters to
communicate information that's needed in order to play back the
audio stream correctly.
The restriction to subtypes of image and audio is... interesting. The rule
is that subtypes of image must be image formats and subtypes of audio must
be audio formats, but the converse -- that subtypes of other top-level types
cannot be used to describe images and audio -- is not true. For example,
application/postscript can be used for images. (It was placed under application
because it can be used for other things as well.)
There are also several problems with the definitions of the
LogotypeGrayScaleImageInfo, LogotypeColorImageInfo, and LogotypeAudioInfo fields:
(1) Images can be language-specific, so why can't they be tagged with a
langauge?
(2) It is perfectly reasonable to tag audio objects with a length but not all
audio formats employ a fixed number of sample per second. Yet samples per
second is a mandatory field in the LogotypeAudioInfo structure.
(3) I'm by no means an expert, but I'm fairly sure that not all image formats
are amenable to the number of colors/greyscale levels being specified as
a "number of bits". Yet these are also mandatory fields.
All this begs the question of why our existing media features facility wasn't
used here rather than defining what amounts to a new but limited feature tagging
facility.
Ted Hardie:
Discuss:
Section 1.
TH: I personally believe this whole line of reasoning is utterly bogus.
X.509 Certs are not human readable, and the idea that external reference
to human-readable symbols adds to their functionality doesn't fly. The
*best* we can hope for is that the inclusion doesn't preclude the correct
functioning of the automated checks, so that they don't allow for
trivial social engineering around the cryptographic assurance these
are meant to apply.
Section 3.
TH: Once again, this conflates URI with the protocol processing needed
to dereference a file. This should probably limited to a very restricted
set of agreed-on URI schemes. It also needs to think very carefully about the
content negotiation aspects of this, as they have forbidden the display
or annunciation of multiple variants, yet there is no pointer to how to
select among them. A ranked order system (like multipart-alternative)
or CONNEG style mechanism looks required.
Section 7>
draft: It is thus imperative that the representation of any
certificate that fails to validate is not enhanced in any way by
using the logotype graphic unless an appropriate warning is given to
the end user.
TH: No. No. No. No warning can overcome symbols where the naive
user has a strong reason to believe the symbol. Take, for example,
a user who has downloaded a site with a self-signed certificate
in which the authority claims to be "United States GAO" and presents
the symbol of the great seal of the United States. The *real*
site may have a VeriSign-issued cert, but the naive user is going
to believe it is reasonable for a sovereign nation to self-sign,
and providing a lifted logo is just going to make the social
engineering worse.
^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-pkix@imc.org>
Subject: Protocol Action: 'Internet X.509 Public Key
Infrastructure: Logotypes in X.509 certificates' to Proposed
Standard
The IESG has approved following document:
- 'Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates'
<draft-ietf-pkix-logotypes-11.txt> as a Proposed Standard
This document is the product of the Public-Key Infrastructure (X.509) Working Group.
The IESG contact persons are Steve Bellovin and Russ Housley.
Technical Summary
This document provides for a way to embed visual or audible logos within
X.509 certificates.
Working Group Summary
There was initially some controversy about whether or not these extensions
were reasonable. Eventually, the working group agreed that they were a good
ida.
Protocol Quality,
This specification has been reviewed for the IESG by Steve Bellovin.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 5 of 6
o draft-iab-isocbot-00.txt
IETF ISOC Board of Trustee Appointment Procedures (BCP)
Token: Harald Alvestrand
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-iab-isocbot -
IETF ISOC Board of Trustee Appointment Procedures
--------
Last Call to expire on: 2003-08-21
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'IETF ISOC Board of Trustee Appointment
Procedures' to BCP
The IESG has approved the Internet-Draft 'IETF ISOC Board of Trustee
Appointment Procedures' <draft-iab-isocbot-00.txt> as a BCP. This document
is the product of the Internet Architecture Board. The IESG contact person
is Harald Alvestrand.
Technical summary:
This document describes procedures whereby the IAB can select the members
of the board of the Internet Society that the ISOC bylaws say are selected
by the IETF.
Working Group Summary:
The document was developed by the IAB, and the IAB had consensus on the
document. There were no comments in IETF Last Call.
Protocol quality:
The document has been reviewed for the IESG by Harald Alvestrand.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 6 of 6
o Three-document ballot:
- draft-ietf-mpls-ldp-mib-13.txt
Definitions of Managed Objects for the Multiprotocol Label Switching,
Label Distribution Protocol (LDP) (Proposed Standard)
- draft-ietf-mpls-ftn-mib-08.txt
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To
Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information
Base (Proposed Standard)
Note: Check with chairs on status
- draft-ietf-mpls-te-mib-12.txt
Multiprotocol Label Switching (MPLS) Traffic Engineering Management
Information Base (Proposed Standard)
Note: waiting for update. check with chairs
Token: Alex Zinin
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-mpls-ldp-mib -
Definitions of Managed Objects for the Multiprotocol Label
Switching, Label Distribution Protocol (LDP)
--------
Last Call to expire on: 2003-09-09
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <mpls@uu.net>
Subject: Protocol Action: 'Definitions of Managed Objects for the
Multiprotocol Label Switching, Label Distribution Protocol (LDP)'
to Proposed Standard
The IESG has approved following documents:
- 'Definitions of Managed Objects for the Multiprotocol Label Switching,
Label Distribution Protocol (LDP) '
<draft-ietf-mpls-ldp-mib-13.txt> as a Proposed Standard
- 'Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To
Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information
Base '
<draft-ietf-mpls-ftn-mib-08.txt> as a Proposed Standard
- 'Multiprotocol Label Switching (MPLS) Traffic Engineering Management
Information Base '
<draft-ietf-mpls-te-mib-12.txt> as a Proposed Standard
These documents are products of the Multiprotocol Label Switching Working
Group.
The IESG contact persons are Alex Zinin and Bert Wijnen.
Technical Summary
The documents define MPLS-related MIB modules for use with network management
protocols in the Internet community. In particular, managed objects for the
Multiprotocol Label Switching, Label Distribution Protocol (LDP), Forwarding
Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings,
and objects for Multiprotocol Label Switching (MPLS) based traffic engineering
Working Group Summary
There was a concensus within the WG to advance these documents
Protocol Quality
The documents have been reviewed for the IESG by Bert Wijnen.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 2
o Five-document ballot:
- draft-ietf-impp-im-03.txt
Common Profile for Instant Messaging (CPIM) (Proposed Standard)
Note: See private comments for proposed RFC Editor note re: ABNF; no
SRV comments yet received, and other issues believed to be resolved
with doc updates.á On the agenda to flush out SRV comments or
progress.
- draft-ietf-impp-cpim-msgfmt-08.txt
Common Presence and Instant Messaging: Message Format (Proposed
Standard)
- draft-ietf-impp-cpim-pidf-08.txt
Presence Information Data Format (PIDF) (Proposed Standard)
- draft-ietf-impp-pres-03.txt
Common Profile for Presence (CPP) (Proposed Standard)
- draft-ietf-impp-srv-03.txt
Address Resolution for Instant Messaging and Presence (Proposed
Standard)
Token: Ted Hardie
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-impp-im -
Common Profile for Instant Messaging (CPIM)
--------
This Evaluation reflects positions for a set of five documents:
<draft-ietf-impp-im-03.txt> Common Profile for Instant Messaging (CPIM)
<draft-ietf-impp-srv-03.txt> Address Resolution for Instant Messaging and Presence
<draft-ietf-impp-cpim-msgfmt-08.txt> Common Presence and Instant Messaging: Message Format
<draft-ietf-impp-pres-03.txt> Common Profile for Presence (CPP)
<draft-ietf-impp-cpim-pidf-08.txt> Presence Information Data Format (PIDF)
Last Call to expire on: 2003-06-27
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ X ] [ ] [ ] [ R ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ X ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ X ] [ ]
Jon Peterson [ ] [ ] [ ] [ R ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
draft-ietf-impp-cpim-msgfmt
Why isn't it using S/MIME or CMS used? The problem statement
sounds about the same.
(I'd really like Russ to see these documents; he's the S/MIME
expert.)
draft-ietf-impp-pres-03.txt
draft-ietf-impp-im-03.txt
S/MIME AES has been published as an RFC. (Fixable with an
RFC editor note.)
Ted Hardie (Comments on Steve's Comments):
>draft-ietf-impp-cpim-msgfmt
> Why isn't it using S/MIME or CMS used? The problem statement
> sounds about the same.
>
> (I'd really like Russ to see these documents; he's the S/MIME
> expert.)
In section 4 of draft-ietf-impp-im, this covers the use of s/mime and
cms:
When end-to-end security is required, the message operation MUST use
MSGFMT, and MUST secure the MSGFMT MIME body with S/MIME [8], with
encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS
SignedData).
Is this needed in draft-ietf-impp-cpim-msgfmt as well, or is there something
else needed entirely?
>draft-ietf-impp-pres-03.txt
>draft-ietf-impp-im-03.txt
> S/MIME AES has been published as an RFC. (Fixable with an
> RFC editor note.)
Thanks for catching this.
Ted
Steve Bellovin (Reply to Ted Hardie's Comments):
In message <p06001a02bb57769c1417@[64.134.94.162]>, hardie@qualcomm.com writes:
>At 10:38 PM -0400 8/6/03, Steven M. Bellovin wrote:
>>In message <200307241803.OAA18923@ietf.org>, IESG Secretary writes:
>>>
>>>Last Call to expire on: 2003-06-27
>>>
>>> Please return the full line with your position.
>>>
>>> Yes No-Objection Discuss Abstain
>>>Steve Bellovin [ ] [ ] [ ] [ ]
>>
>>draft-ietf-impp-cpim-msgfmt
>> Why isn't it using S/MIME or CMS used? The problem statement
>> sounds about the same.
>>
>> (I'd really like Russ to see these documents; he's the S/MIME
>> expert.)
>
>In section 4 of draft-ietf-impp-im, this covers the use of s/mime and
>cms:
>
> When end-to-end security is required, the message operation MUST use
> MSGFMT, and MUST secure the MSGFMT MIME body with S/MIME [8], with
> encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS
> SignedData).
>
>Is this needed in draft-ietf-impp-cpim-msgfmt as well, or is there something
>else needed entirely?
The problem I have is that draft-ietf-impp-cpim-msgfmt lays out a
detailed set of requirements and explains how to use MIME. If S/MIME
is the right answer, much of the rationale can be omitted, except
perhaps a short statement that the environmental model is very much
like the one that email has. This is the message format RFC; it should
really point to the authoritative source for the desired encoding and
encapsulation. The rationale, if needed at all, should have been in
draft-ietf-impp-im, which is setting out the framework.
Beyond that, it isn't clear to me that they've said enough about how to
use CMS and S/MIME. There are lots of possible options and variations;
I don't know that all are useful or correct here. That's where I want
to defer to Russ.
Ted Hardie (Reply to Steve's Comments):
>
>Beyond that, it isn't clear to me that they've said enough about how to
>use CMS and S/MIME. There are lots of possible options and variations;
>I don't know that all are useful or correct here. That's where I want
>to defer to Russ.
A portion of this discussion came up in response to a review by
Sam Hartman. Sam raised two issues: how a certificate was checked
to be sure that it matched an instant inbox or presence. After discussion
with Jon, it was agreed that text was needed to explain how a certificate
would store the im: URI or pres: URI (subjectAltName was the proposal,
I believe). Jon said he would provide that text as part of the update post-IESG
review. The other question was whether the draft listed a
mandatory algorithm for CMS. The resolution there was that the
draft authors would have preferred AES, but given that it was not
at the time standardized, the draft inherited the defaults of CMS and
S/MIME. The other issue there was that supporting AES instead of
3DES was likely to lead to problems with some existing S/MIME
stacks and supporting both looked problematic in different ways.
After pointers to the text in the draft, Sam was convinced that it was
sufficiently specified. I did contact Russ during this exchange, but he
was in the middle of heading off for vacation, so we traded voice mails
but did not speak in person.
Bill Fenner (Discuss):
draft-ietf-impp-im-03.txt uses RFC 822 ABNF (#mailbox).
draft-ietf-impp-cpim-msgfmt-08.txt:
SEPARATORS uses '<">', which is imprecise where %x22 is precise.
NAMECHAR uses "%" where it means "%x" so is all syntax errors.
The first UCS-high uses non-ABNF syntax (ABNF only handles bytes,
so there is no way to represent %xffffffff)
It says that it is using a modified ABNF which is case-sensitive.
The SIP spec used %x syntax for case-sensitive fields, and I think
that's a good strategy. Someone who is just looking for the ABNF
may miss the statement that it's a modified ABNF so might think that
the fields are case-insensitive. If the unambiguous form is used then
this can't happen.
(extremely minor): The rule Lang-param is referred to as "lang-param" in
the "Subject-header" production. Rule names are case-insensitive so
this is valid, but could be confusing.
draft-ietf-impp-pres-03.txt ABNF is fine.
Jon Peterson (Comments on Bill Fenner's Discuss):
Thanks for the read Bill,
> Yes No-Objection Discuss Abstain
> Bill Fenner [ ] [ ] [ X ] [ ]
>
> draft-ietf-impp-im-03.txt uses RFC 822 ABNF (#mailbox).
>
Doh, someone caught this at the last minute in impp-pres-03, but I gather it
wasn't fixed in impp-im-03. I'm happy to chop off the #.
> draft-ietf-impp-cpim-msgfmt-08.txt:
> SEPARATORS uses '<">', which is imprecise where %x22 is precise.
> NAMECHAR uses "%" where it means "%x" so is all syntax errors.
> The first UCS-high uses non-ABNF syntax (ABNF only handles bytes,
> so there is no way to represent %xffffffff)
> It says that it is using a modified ABNF which is case-sensitive.
> The SIP spec used %x syntax for case-sensitive fields, and I think
> that's a good strategy. Someone who is just looking for the ABNF
> may miss the statement that it's a modified ABNF so might think that
> the fields are case-insensitive. If the unambiguous form is used then
> this can't happen.
> (extremely minor): The rule Lang-param is referred to as "lang-param" in
> the "Subject-header" production. Rule names are case-insensitive so
> this is valid, but could be confusing.
We'll have to get Graham to address these.
>
> draft-ietf-impp-pres-03.txt ABNF is fine.
- J
Margaret Wasserman:
Comment:
Hi Ted,
I have some comments/questions on this document set, although I
am not sure that they warrant a "discuss":
draft-ietf-impp-im-03.txt:
The abstract and first section both say that "Today...little
interperability...has been achieved." While that's probably
true _today_, is that really something that we want to say at
the top of a standard that will hopefully live for many years?
draft-ietf-impp-cpim-msgfmt-08.txt:
The TOC in this document doesn't have page numbers, so I am not
sure why it has been included. Would the RFC editor fix
something like this?
draft-ietf-impp-cpim-pidf-08.txt:
This doesn't seem like a well-formed reference:
[MIME] Multipurpose Internet Mail Extensions. See RFC 2045, RFC 2046,
RFC 2047, RFC 2048, and RFC 2049.
And, the indicated RFCs don't have references in this document.
draft-ietf-impp-pres-03.txt:
This document also talks about the status "today". This seems unwise
in a standard that will hopefully live for a long time.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <impp@iastate.edu>
Subject: Protocol Action: 'Common Profile for Instant Messaging
(CPIM)' to a Proposed Standard
------------------------
The IESG has approved the Internet-Drafts 'Common Profile for Instant
Messaging (CPIM)' <draft-ietf-impp-im-03.txt>, 'Address Resolution for
Instant Messaging and Presence' <draft-ietf-impp-srv-03.txt>, 'Common
Presence and Instant Messaging: Message Format'
<draft-ietf-impp-cpim-msgfmt-08.txt>, 'Common Profile for Presence
(CPP)' <draft-ietf-impp-pres-03.txt>, and 'Presence Information Data
Format (PIDF)' <draft-ietf-impp-cpim-pidf-08.txt>, each as
Proposed Standard.
These documents are the product of the Instant Messaging and Presence
Protocol Working Group.
The IESG contact persons are Ned Freed and Ted Hardie
Technical Summary
These documents form the basis for a mechanism by which multiple
distinct Instant Messaging applications may pass messages among
the different systems while retaining the ability to use end-to-end
encryption, integrity protection, and a shared framework for presence
information.
The work on PIDF (Presence Information Data Format) is already in
widespread usage by the SIP-based instant messaging community,
as is the message format described.
Working Group Summary
The IMPP working group was originally chartered to develop requirements
and then protocols which would provide an "Internet-scale end-user
presence awareness, notification and instant messaging system". The group
delivered RFCs 2778 and 2779 defining a model and requirements for
instant messaging, but it was unable to select among the candidate
protocols for this task even after setting up a nine-member design
and review team. After this impasse was reached, the work of
development was split to allow for multiple, interoperable transport protocols.
While the tasks assigned to those groups chartered after the split
are relatively clear in their charters, the work to be done by IMPP
was, regrettably, not defined in a new charter. As a result, the
task taken on by these documents represents the rough consensus
of the group as determined by the chairs; there remains, however,
a view that the group was chartered to define minimal gateway
semantics for the multiple IM systems, thus rendering end-to-end
encryption and data integrity out of scope, rather than the formats
and framework defined by these documents.
In evaluating these documents, the IESG has thus both needed to assess
whether the documents meet the needs of the work plan as the chairs
have understood it and whether the work plan itself was on target. The
IESG greatly regrets the necessity of this second task and its failure in
not updating the charter of IMPP. It does not, however, believe that refusing
to advance the documents on the basis of this failure is appropriate,
as it is contrary to the promotion of interoperability in this arena. Instead,
the IESG has been guided by the charters granted to the successor groups,
by the place end-to-end security normally holds in IETF protocol
analyses, and by a careful review of the mailing list and minutes of the
meetings subsequent to the split. The IESG has, through this review,
concluded that the work plan described by the chairs was on target
and has conducted their technical review of the documents solely on
the question of whether the documents meet the need outlined by that plan.
In its technical evaluation, the IESG noted that many of the formats and
discovery mechanisms described are already in use or replicate well-known
existing mechanism. They reflect that maturity in their description
and completeness.
The core document on CPIM, in contrast, represents a fairly abstract
description
of the service. The IESG believes that the documents are of sufficient quality
to be the basis of an interoperable service, but notes that it
expects the development of documents mapping CPIM to specific
protocols to show how to make the
abstract terms in CPIM concrete. Further, it expects that
interoperability reports
presented for the transition to draft standard would include multiple
protocols,
as well as the usual requirement that the implementations be independent.
Protocol Quality
The documents were reviewed for the IESG by Ted Hardie.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 2
o draft-ietf-webdav-ordering-protocol-10.txt
WebDAV Ordered Collections Protocol (Proposed Standard)
Note: Text added to clear Allison's issue with ordering semantics
Token: Ted Hardie
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-webdav-ordering-protocol -
WebDAV Ordered Collections Protocol
--------
Last Call to expire on: 2003-06-19
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Allison Mankin:
Discuss:
This may be a question of not finding the material easy going, but the
term "ordering semantics" needs a definition. For instance in the material
below, if the ORDERPATCH method has specified an ordering semantic, it's hard
to see why the server assigned positions may be based on arbitrary ordering
approaches by the server. What is the distinction of ordering and ordering
semantic? How does the URI for "ordering semantics" work? (As in:
In this example, after the request has been processed, the
collection's ordering semantics are identified by the URI http://
example.org/inorder.ord. The value of the collection's
DAV:ordering-type property has been set to this URI.)
I think there just needs to be a section early on with some definitions
and mechanics of these important concepts.
Changing a Collection Ordering: ORDERPATCH method
The ORDERPATCH method is used to change the ordering semantics of a
collection or to change the order of the collection's members in the
ordering or both.
The server MUST apply the changes in the order they appear in the
order XML element. The server MUST either apply all the changes or
apply none of them. If any error occurs during processing, all
executed changes MUST be undone and a proper error result returned.
If an ORDERPATCH request changes the ordering semantics, but does not
completely specify the order of the collection members, the server
MUST assign a position in the ordering to each collection member for
which a position was not specified. These server-assigned positions
MUST all follow the last one specified by the client. The result is
that all members for which the client specified a position are at the
beginning of the ordering, followed by any members for which the
server assigned positions. Note that the ordering of the
server-assigned positions is not defined by this document, therefore
servers can use whatever rule seems reasonable (for instance,
alphabetically or by creation date).
If an ORDERPATCH request does not change the ordering semantics, any
member positions not specified in the request MUST remain unchanged.
Editorial - this sentence has two spelling errors:
The following sequence of requests will rename a collection member
while preserving it's position, independantly of how the server
^^^^ ^^^^
implements the MOVE operation:
Ned Freed:
Nit: The security considerations section begins with:
This section is provided to make WebDAV applications aware of the
security implications of this protocol.
Unless applications have gotten a lot smarter while I wasn't looking,
this section doesn't make them aware of anythimg. Suggest changing
"applications" to "implementers".
Jon Peterson:
Comment:
Small questions - in Section 7.1, returning a "proper error result" to
ORDERPATCH failures is mentioned. Are there any new error conditions that
might arise from of the use of the ORDERPATCH method, that might need new
status codes? What sort of error results might implementers receive in
response to an ORDERPATCH? Does this need any further explanation?
- J
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, w3c-dist-auth@w3.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: WebDAV Ordered Collections Protocol to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'WebDAV Ordered Collections
Protocol' <draft-ietf-webdav-ordering-protocol-08.txt> as a Proposed
Standard.
This document is the product of the WWW Distributed Authoring and
Versioning Working Group.
The IESG contact persons are
Ned Freed
Ted Hardie
Technical Summary
The document extends the WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members, for use
when a client's use of the search protocol's ordering option would
not be appropriate or sufficient. It defines protocol elements that
permit clients to specify the position of each member of a collection
in an ordering. One common use case that has been discussed is
maintaining markers like page numbers.
Working Group Summary
The working group held a four week last call on the document and
comments received were generally positive. There was one set of
comments received during IETF last call, and the authors revised
the documents to handle the issues. The working group acknowledged
that problem it faced represented choices among several sets of
engineering trade offs, and it believes it has come to consensus on
those trade-offs.
Note that the document specifies methods of handling client-specified
but server-maintained orderings. The presumption of this work is
that a human will generally use a webdav client to create and maintain
these orderings. The working group aims to allow further extensions
to describe automatic, server-maintained orderings, but this document
does not specify those mechanisms.
Protocol Quality
Ted Hardie reviewed this document for the IESG
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 1 of 1
o draft-mrose-ietf-posting-03.txt
A Practice for Revoking Posting Rights to IETF mailing lists (BCP)
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-mrose-ietf-posting -
A Practice for Revoking Posting Rights to IETF mailing lists
--------
Last Call to expire on: 2003-06-13
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ R ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Harald Alvestrand:
Comment:
I'm recusing myself on this one.
I asked Marshall to write this originally, and shepherded it through the discussions on POISED and the IETF mailing lists.
So I feel I've spoken enough in favour of it, and others should evaluate.
Ted Hardie:
Comment:
I personally think the FAQ style questions and answers should be dropped as it moves to RFC,
but will go with whatever others think on that point.
^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: 'A Practice for Revoking Posting Rights
to IETF mailing lists' to BCP
The IESG has approved following document:
- 'A Practice for Revoking Posting Rights to IETF mailing lists'
<draft-mrose-ietf-posting-03.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 Steve Bellovin.
Technical Summary
For the last several years, the IESG has had occasion to bar disruptive
individuals from assorted mailing lists, using RFC 2418 as the basis for
such actions. This draft codifies and formalizes the practice. It also
provides a basis for barring a disruptive individual from all IETF mailing
lists, not just one at a time.
Working Group Summary
There was consensus within the IETF community on this draft.
Protocol Quality
Steve Bellovin has reviewed this draft for the IESG>
2. Protocol Actions
2.2 Individual Submissions
2.2.2 Returning Item - 1 of 1
o draft-zeilenga-ldap-user-schema-mr-00.txt
LDAP: Additional Matching Rules (Proposed Standard)
Note: This is a proper subset of draft-zeilenga-ldap-user-schema, and
it is proposed that it be advanced while the other bits are
revised. Proposed RFC-editor note in comments.
Token: Ted Hardie
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-zeilenga-ldap-user-schema - LDAPv3: A
Collection of User Schema to Proposed Standard
--------
It is proposed that this be approved for Proposed Standard with the
following IESG note:
This document contains useful and timely updates to RFC 2798. The IESG
expects that this document will be replaced or updated again once the
LDAP community has finished its work related to stringprep, and that
those updates will cause this document or its successors to recycle at
the Proposed Standard level.
Last Call to expire on: January 28, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ XX] [ D ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (10) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve: Does this depend on stringprep for comparisons? Should it?
Ned:
(1) There isn't a single example in this entire document. It would really
help to have some in LDIF format, especially for the more commonly used
attributes.
(2) Every attribute defined in this document is multivalued, yet the
descriptive text in almost every case implies the attribute is single
valued. In each case the descriptive text needs to be changed to make
it clear multiple values are possible.
This may sound like a trivial issue but in practice it is not. Consider the
uid attribute, which "specifies a computer system login name". The
implication that each user has a single uid had resulted in many
implementations only supporting single valued uid attributes. This then
causes major trouble when such implementations encounter multivalued uid
usage - which is perfectly legitimate and even useful.
(3) It would be enormously helpful if the object classes each attribute is
in were listed as part of the attribute description.
(4) Most of the matching rules used in this specification are not mentioned
in either section 2 or 6:
caseIgnoreIA5Match RFC 2252
caseIgnoreIA5SubstringMatch RFC 2798
distinguishedNameMatch RFC 2252
caseIgnoreMatch RFC 2252
caseIgnoreSubstringsMatch RFC 2252
telephoneNumberMatch RFC 2252
telephoneNumberSubstringsMatch RFC 2252
caseIgnoreListMatch RFC 2252
RFC 2252 is a normative reference, so a bit of text saying that these
matching rules are defined there would be sufficent. RFC 2798 is an
informative reference updated by this document, however, so the
specification of caseIgnoreIA5SubstringMatch probably needs to be added
to this specification.
(5) Conversely, only one of the matching rules specified in section 2
(caseIgnoreListSubstringMatch) is actually employed by any of the
attributes specified in this document! I guess this is OK on the
grounds that these matching rules can be considered "user schema
elements", but it seems a bit strange.
(6) The definition of associatedName probably should refer to RFC 1279 as
well as RFC 1274.
(7) The various document* attributes and object classes would normally be
associated with a document entry in the directory, not a user entry. This
specification clearly states it is describing user attributes. Either the
various document attributes and object classes should be removed
(preferable) or else the scope of the specification needs to be
expanded to include document as well as user schema.
(8) Assuming the documentLocation attribute is retained, the use of a
multivalued attribute to describe "the location of the document
original" seems a bit peculiar. Either (1) Make this attribute single
valued, (2) Remove the term "original", or (3) Make it clear that
all of the values must refer to the same actual location.
(9) The "homePhone" and "pager" attributes should refer to
draft-allocchio-gstn-04.txt as a source for a "preferred" syntax for
telephone numbers. This syntax should not be required, however.
(10) We have "homePhone" and "homePostalAddress" attributes but no "workPhone"
and "workPostalAddress" attributes. This also seems peculiar. It also
doesn't match up with vCard very well.
(11) The "host" attribute specifies "a host computer" in what context?
Perhaps where the user has an account?
(12) The "homePostalAddress" and "info" attributes can contain multiple lines.
The correct convention to use for line breaks needs to be described.
(13) Section 3.17 on the "mail" attribute should be changed to read:
3.17. mail
The mail (rfc822mailbox) attribute type holds an Internet mail
address conforming to the syntax of the Mailbox production
from [RFC2821] (e.g.: user@example.com). (Source: RFC 1274)
( 0.9.2342.19200300.100.1.3
NAME ( 'mail' 'rfc822Mailbox' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
It is noted that the directory will not ensure that values of this
attribute conform to the Mailbox production [RFC2821]. It is the
application's responsibility to ensure that the addresses
it stores in this attribute are appropriately represented.
Additionally, the directory will compare values per the matching
rules named in the above attribute type description. As these rules
differ from rules which normally apply to Mailbox comparisons,
operational issues may arise. For example, the assertion
(mail=joe@example.com) will match mail value JOE@example.com even
though the local parts differ. Also, where a user has two mailboxes
which whose addresses differ only by case of the local-part, both
cannot be listed as values of the user's mail attribute as they are
considered to be same by the mail attribute's equality matching rule.
This is a slightly edited variant of the replacement text Kurt
suggested. I did remove a reference to IDNA since I don't think
it is appropriate to refer to that prior to there being a
specification on how IDN is to be used in email.
(14) I question the utility of "otherMailbox" specified in section 3.21.
Without knowing the other mail system involved it is difficult to see
how this could be used in a consistent fashion. One way to solve this
would be to suggest that the original-receipient-address production
from RFC 3461 be used. This production includes an address type
label. Additional labels can be registered for "other" mail systems.
(A label and syntax is already registered for X.400, I believe.)
(15) It is probably too late to change, but it would definitely be
useful for "uniqueIdentifier" be single valued. (Failing that, a
single value "reallyUniqueIdentifier" attribute would be useful...)
(16) Section 3.28 "usage od this" -> "usage of this".
(17) The various object classes defined in section 4 refer to all sorts of
attributes that aren't defined in this document, e.g.
facsimileTelephoneNumber. Why weren't these attributes included in this
document? The rules for inclusion or exclusion of various attributes
seem obscure at best here.
(18) The "rFC822LocalPart" object class is incredibly poorly named.
(19) Is the "room" object class intended to specify an office location or
something similar? Or does it not belong in a user schema specification?
(20) Reference to RFC 822 should be changed to 2821.
COMMENTS:
=========
Ted:
Steve,
Kurt has suggested a tweak to this; here is his note:
> Ted, regarding this recently added note to the tracker:
> It is proposed that this be approved for Proposed Standard with
> the following IESG note: This document contains useful and timely
> updates to RFC 2798. The IESG expects that this document will be
> replaced or updated again once the LDAP community has finished its
> work related to stringprep, and that those updates will cause this
> document or its successors to recycle at the Proposed Standard level.
>
> The primary focus of the I-D is to update RFC 1274 (Proposed Standard)
> and to adapt additional X.520(93) schema for use in LDAP (such as
> the matching rules needed by Policy WG draft). Superceding portions
> of RFC 2798 (Informational) became necessary as it tried to fill some
> of the gaps.
>
> I would suggest the IESG note focus more on "useful and timely
> updates" to RFC 1274 (and filling gaps between X.520(93) and LDAP).
>
> Kurt
Based on that, I think we might want to change the text to say
"This document contains useful and timely updates of RFC
1274 and RFC 2798, as well as harmonizing certain aspects
of X.520(93) and LDAP. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates will
cause this document or its successors to recycle at the Proposed
Standard level"
Would this text still be okay with you?
Russ:
Section 3.25. Should we change "secretary" to "secretary or
administrative assistant" in the description of the attribute? I am
not proposing to change the name of the attribute.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: LDAPv3: A Collection of User Schema to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAPv3: A Collection of User
Schema' <draft-zeilenga-ldap-user-schema-06.txt> as a Proposed
Standard. This has been reviewed in the IETF but is not the product of
an IETF Working Group.
The IESG contact persons are Ned Freed and Patrik Faltstrom
Technical Summary
This document provides a collection of user schema elements for use
with LDAP (Lightweight Directory Access Protocol) from both ITU-T
Recommendations for the X.500 Directory and COSINE and Internet X.500
pilot projects.
Working Group Summary
This document is not a product of a working group. It has been
discussed on the LDAPBIS working group mailing list. There was
consensus for publication of a document specifying this schema.
Protocol Quality
The specification was reviewed for the IESG by Patrik Faltstrom.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 5
o draft-ietf-send-psreq-03.txt
IPv6 Neighbor Discovery trust models and threats (Informational)
Token: Margaret Wasserman
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 5
o draft-ietf-ieprep-ets-telephony-06.txt
IP Telephony Requirements for Emergency Telecommunication Service
(Informational)
Token: Jon Peterson
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ieprep-ets-telephony -
IP Telephony Requirements for Emergency Telecommunication Service
--------
Last Call to expire on:
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <ieprep@ietf.org>
Subject: Document Action: 'IP Telephony Requirements for Emergency
Telecommunication Service' to Informational RFC
The IESG has approved following document:
- 'IP Telephony Requirements for Emergency Telecommunication Service '
<draft-ietf-ieprep-ets-telephony-06.txt> as an Informational RFC
This document is the product of the Internet Emergency Preparedness Working
Group.
The IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within the context of IP telephony.
It is an extension to the general requirements previously developed
in the IEPREP WG. Solutions to these requirements are not presented
in this document.
Working Group Summary
The IEPREP Working Group supports the document.
Protocol Quality
This document was reviewed for the IESG by Jon Peterson.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 3 of 5
o draft-iesg-charter-03.txt
An IESG charter (Informational)
Token: Steve Bellovin
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 4 of 5
o draft-ietf-pkix-warranty-extn-03.txt
Internet X.509 Public Key Infrastructure Warranty Certificate Extension
(Informational)
Token: Steve Bellovin
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 5 of 5
o draft-ietf-tsvwg-highspeed-01.txt
HighSpeed TCP for Large Congestion Windows (Experimental)
Token: Jon Peterson
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-tsvwg-highspeed -
HighSpeed TCP for Large Congestion Windows
--------
Last Call to expire on: 2003-09-16
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 [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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:
======================
^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>, <tsvwg@ietf.org>
Subject: Document Action: 'HighSpeed TCP for Large Congestion
Windows' to Experimental RFC
The IESG has approved following document:
- 'HighSpeed TCP for Large Congestion Windows '
<draft-ietf-tsvwg-highspeed-01.txt> as an Experimental RFC
This document is the product of the Transport Area Working Group Working
Group.
The IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
HighSpeed TCP modifies the congestion control mechanisms of TCP to accommodate
large congestion windows tailored to high-speed networks. Standard TCP constrains
the congestion window that can be achieved by TCP in realistic multi-gigabit
environments. Accordingly, HighSpeed TCP adapts the congestion window much more
appropriately to achieve an optimal steady-state for very rapid data transfer,
and does so in a way that can co-exist with standard TCP deployments on the
Internet.
Working Group Summary
The TSVWG Working Group supports the advancement of this Experimental protocol.
Several proposals to address the use of TCP in high-speed networks have arisen
outside the IETF (largely in academic communities); it is believed that the
experimental deployment of HighSpeed TCP will aid significantly in determining
the direction of ongoing research in this area.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin and Jon Peterson.
3.1.2 Returning Item
NONE
3. Document Actions
3.2 Individual Submissions Via AD
3.2.1 New Item - 1 of 2
o draft-rfc-editor-rfc2223bis-07.txt
Instructions to Request for Comments (RFC) Authors (Informational)
Note: Responsible: Harald Alvestrand
Token: Harald Alvestrand
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-rfc-editor-rfc2223bis -
Instructions to Request for Comments (RFC) Authors
--------
Last Call to expire on: 2003-04-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Instructions to Request for Comments
(RFC) Authors' to Informational RFC
The IESG has approved following document:
- 'Instructions to Request for Comments (RFC) Authors '
<draft-rfc-editor-rfc2223bis-07.txt> as an Informational RFC
This document has been reviewed in the IETF but is not the product of an IETF Working Group.
The IESG contact person is Harald Alvestrand.
Technical summary:
Working group summary:
Protocol quality:
3. Document Actions
3.2 Individual Submissions Via AD
3.2.1 New Item - 2 of 2
o draft-mealling-liberty-urn-00.txt
A URN Namespace For The Liberty Alliance Project (Informational)
Token: Ted Hardie
3. Document Actions
3.2 Individual Submissions Via AD
3.2.2 Returning Item - 1 of 1
o draft-siemborski-mupdate-04.txt
The MUPDATE Distributed Mailbox Database Protocol (Experimental)
Note: On IESG agenda
Token: Ned Freed
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-siemborski-mupdate -
The MUPDATE Distributed Mailbox Database Protocol
--------
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Comment:
Turn off hyphenation.
In section 8.8, the protocol allows as list of authentication
mechanisms, even if TLS is not in use. Without the integrity provided by
TLS, an adversary can reorder the list of mechanisms. One solution would
be to limit the list to a single item when TLS is not in use.
How was port 2004 assigned?
Ned Freed:
>From: ned.freed@mrochek.com
>Subject: Re: Comments: draft-siemborski-mupdate-04
>To: Russ Housley <housley@vigilsec.com>
> Turn off hyphenation.
> In section 8.8, the protocol allows as list of authentication
> mechanisms, even if TLS is not in use. Without the integrity provided by
> TLS, an adversary can reorder the list of mechanisms. One solution would
> be to limit the list to a single item when TLS is not in use.
There's nothing in this draft, nor AFAIK in any other SASL-based protocol, that
says the order of the mechanism list is significant. The way SASL is supposed
to work is that the client examines the list of available and picks the most
appropriate one it supports. Authorization fails if that no appropriate
mechanisms are shared by the client and server.
Of course an active attacker can remove mechanisms from the list in an attempt
to trick the client into using inadequate security. This sort of downgrade
attack is dealt with either by using TLS (note that the capabilites must be
reacquired after TLS negotiation is done, and the draft, along with other
protocols that use SASL, specifies this) or by the client refusing to employ
inadequate mechanisms.
Attacks on the mechanism list are no different than in other application
protocols that employ SASL, including but not limited to IMAP4 itself. This
specific issue is described in the second paragraph of section 9 of RFC 2222,
the SASL specification.
I really don't see any problem here that needs to be addressed.
> How was port 2004 assigned?
AFAIK it wasn't. The document requests that IANA assign a new port for MUPDATE
to use. Once that is done the reference to 2004 can be removed.
Ned
Bert:
Comment:
There are a number of places where it uses things like:
Example:
S: * AUTH KERBEROS_V4 GSSAPI
S: * STARTTLS
S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)"
According to our NITS that probably should
be mupdate.andrew.example or some such?
Thanks,
Bert
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>
Subject: Document Action: 'The MUPDATE Distributed Mailbox
Database Protocol' to an Experimental RFC
------------------------
The IESG has no problem with the publication of the Internet-Draft 'The
MUPDATE Distributed Mailbox Database Protocol'
<draft-siemborski-mupdate-04.txt> as an Experimental RFC. This has been
reviewed in the IETF but is not the product of an IETF Working Group.
The IESG contact person is Freed, Ned.
3.2.3 To be assigned
o draft-baker-soap-media-reg-03.txt
The 'application/soap+xml' media type (Informational)
o draft-klensin-name-filters-03.txt
User Interface Evaluation and Filtering of Internet Addresses and
Locators -or- Syntaxes for Common Namespaces (Informational)
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 1 of 2
o draft-fleming-ldap-printer-schema-02.txt
Lightweight Directory Access Protocol (LDAP):Schema for Printer
Services (Informational)
Token: Ted Hardie
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 2 of 2
o draft-touch-ipsec-vpn-05.txt
Use of IPsec Transport Mode for Dynamic Routing (Informational)
Token: Russ Housley
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o MIPv6 Signaling and Handoff Optimization - 1 of 2
Token: Thomas
MIPv6 Signaling and Handoff Optimization (mipshop)
--------------------------------------------------
Last Modified: 2003-9-11
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. 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 since the mobile node no
longer has link connectivity with the old subnet. 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 signalling 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
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-fmipv6-xx.txt.
OCT 03 - Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt.
NOV 03 - Discuss Last Call comments at IETF 58.
DEC 03 - Working Group Last Call on draft-ietf-mipshop-80211fh-xx.txt
for Informational
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-fmipv6-xx.txt to IESG for consideration
of publication as Experimental.
JAN 04 - Submit draft-ietf-mipshop-hmip-xx.txt to IESG for consideration
of publication as Experimental.
MAR 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.1 Proposed for IETF Review
o Storage Transport - 2 of 2
Token: Margaret
Storage Transport (stwg)
------------------------
Last Modified: 2003-9-12
Current Status: Proposed Working Group
Chair(s):
Elizabeth Rodriguez <ElizabethRodriguez@ieee.org>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Margaret Wasserman <mrw@windriver.com>
Technical Advisor(s):
Keith McCloghrie <kzm@cisco.com>
David L. Black <black_david@emc.com>
Mailing Lists:
TBD, probably stwg@ietf.org
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 Storage Transport WG (stwg) 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:
Oct 03 Submit IPv6 over Fibre Channel draft to IESG for consideration
as Proposed Standard
??? Submit XXX MIB to IESG for consideration as Proposed Standard
??? Submit YYY MIB to IESG for consideration as Proposed Standard
??? Submit ZZZ MIB to IESG for consideration as Proposed Standard
Oct 04 Consult with Area Directors about what, if any, additional
work the WG should undertake.
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Common Control and Measurement Plane - 1 of 1
Token: Alex
Common Control and Measurement Plane (ccamp)
--------------------------------------------
Last Modified: 2003-9-11
Current Status: Active Working Group
Chair(s):
Ronald Bonica <ronald.p.bonica@mci.com>
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 ISP
and SP physical path and core tunneling technologies (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 requirements for signaling and routing for ASON not currently
met; 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
Feb 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
NONE
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 Appropriate Methods for getting Meeting Minutes from Chairs (Harald Alvestrand)
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
------------------------------------------------------------
Message #1 From Michael Richardson (in its entirety)
Subject: [57crew] IETF anchored interop testing
Date: Monday 28 July 2003 11:53
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: ietf-secretariat@ietf.org, Brett Thorson <bthorson@ietf.org>
Cc: hugh@xisp.net, martin.steimerling@ccrle.nec.de, Edward Lewis
<edlewis@arin.net>, Bill Manning <bmanning@ISI.EDU>, paul.hoffman@vpnc.org,
57crew@ietf.org, Sabine.Beauvois@etsi.org, Andrew McGregor
<andrew@indranet.co.nz>
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
various WGs have attempted to organize interop/plug testing either before
or after IETF sessions. Sometimes during. I am aware of IPsec, HIP, DNSSEC,
and DHCPv6 tests that have occured or been attempted in the past year.
I wanted to arrange a manner in which we might organize this kind of thing
in a more organized, less ad-hoc manner. I wanted to propose that a mailing
list be set up that included someone from the secretariat, as well as
interested parties.
Primarily, I am interesting in reducing the lead time for getting things
organized - in great part so that the cost to the participants of attending
such a plugtest is reduced into the noise level compared to IETF itself.
If we can do this @ietf.org, that would be great. If not, let me know,
and I will create a list elsewhere.
I will save conversation about my thoughts about logistics for the list itself.
------------------------------------------------------------
Message #2 From Bill Manning (excerpt)
(NOTE: In his message, Bill forwarded Message #1 from Michael Richardson,
and added one sentence. The excerpt contains the additional sentence.)
Envelope-to: bfuller@foretec.com
From: Bill Manning <bmanning@ISI.EDU>
Subject: Re: IETF anchored interop testing
To: mcr@sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu, 4 Sep 2003 02:59:28 -0700 (PDT)
Cc: ietf-secretariat@ietf.org, bthorson@ietf.org, hugh@xisp.net,
martin.steimerling@ccrle.nec.de, edlewis@arin.net, bmanning@ISI.EDU,
paul.hoffman@vpnc.org, 57crew@ietf.org, Sabine.Beauvois@etsi.org,
andrew@indranet.co.nz, bmanning@ep.net
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
There are some rumblings of doing another series of
testing in Korea prior to the IETF next spring.
--bill
------------------------------------------------------------
Message #3 From Kevin Almeroth (in its entirety, but without headers)
(NOTE: This message was forwarded to me by Brett Thorson who originally
received it. Kevin Almeroth is the head of the multicast group at the
University of Oregon that provides multicast support at the IETF meetings.)
On Tue, 26 Aug 2003, Kevin C. Almeroth wrote:
Brett, don't know if I have the right email for Jim, but I think I do. Okay...
So, we are planning a pretty interesting/aggressive project for the Minn
IETF and we wanted to get your feedback.
First, the "we" is me, Elizabeth Belding-Royer (a faculty member here who
is active with Charlie Perkins in the Ad hoc area), and our usual group of
students.
Second, we are building (soon to be "have built") a plug-in that allows a
laptop to run in true ad hoc mode. The idea is to use other such laptops
to build a "real" ad hoc network. My personal idea is to be able to use
these ad hoc nodes to extend connectivity into the upper floors of the
hotel. A better idea would be if there is an area that could use wireless
access, but for some reason (money, AP access, etc.) there won't be. Based
on what ya'll know about the layout, do you have any idea on whether Minn
will have this?
Third, we want to conduct a parallel experiment to start doing a better
job tracking and collecting stats about what is happening on the wireless
network. I wanted to do this in Vienna but the goobers couldn't figure out
how to do what I wanted. Basically, I'd like to periodically dump a variety
of SNMP data from the APs. The problems in Vienna seemed to be that they'd
already configured the APs to ONLY listen to one address and they'd also
configured them to ONLY do fault alarms... So, anyway we can set up to
collect decent information?
Thanks for your support. :-)
-Kevin
------------------------------------------------------------
Message #4 From Michael Richardson (almost in its entirety...extraneous sentence omitted)
(NOTE: Brett sent Michael Richardson and Kevin Almeroth a note asking
for more details about their testing plans for Minneapolis. He cc'd
the mailing list for his IETF "meeting crew" on the note. Message #4
is Michael Richardson's response to Brett's note.)
Subject: Re: Testing at the IETF
Date: Tuesday 09 September 2003 15:20
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: Brett Thorson <bthorson@foretec.com>
Cc: "Kevin C. Almeroth" <almeroth@cs.ucsb.edu>
>>>>> "Brett" == Brett Thorson <bthorson@foretec.com> writes:
Brett> Hi there Michael & Kevin.
Brett> It has come to my attention that both of you would like to do some
Brett> testing at the IETF meetings (and from what I understand, at the
Brett> Minneapolis IETF meeting). The Acting IETF Director has discussed
Brett> this idea with Harald (The IETF Chair) and he would like me to
Brett> collect from you a description of what you will be testing /
Brett> providing, and your goals.
I am not specifically interesting in doing it *at* IETF, but rather
immediately preceeding - Friday/Saturday.
My impression from being involved with network setup is that it is much
to be the guinea pigs as the network goes up, rather than try and get the
network to remain up after Friday.
And in general, I was hoping that this could become a tradition rather
than just an incidental occurance.
Brett> If you could get this to me by 1300 Eastern Time Thursday
Brett> 2003/11/09, I can then submit it for the weekly discussion.
The protocols that I have in mind are:
IPsec IKEv2
DNSSEC
I can not be certain at this time that there is sufficient interest in
either of them at this time, but I will attempt to determine this by
Thursday.
------------------------------------------------------------
Message #5 From Michael Richardson (in its entirety)
(NOTE: Chris Liljenstolpe, who is on the mailing list for Brett's
"meeting crew," responded to Brett's note with a question, and
Michael Richardson responded to Chris. Message #5 is Michael's
response to Chris's question.)
Subject: Re: [58crew] Testing at the IETF
Date: Tuesday 09 September 2003 15:29
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: Chris Liljenstolpe <cds@io.com>
Cc: Brett Thorson <bthorson@foretec.com>, "Kevin C. Almeroth"
<almeroth@cs.ucsb.edu>
>>>>> "Chris" == Chris Liljenstolpe <cds@io.com> writes:
Chris> What kind of testing?
I can't speak for Kevin, since I don't know what he is after.
In general, what we are looking for is a tradition of having some
room(s) with a network drop that becomes live on the IETF network
earlier, ideally Friday morning. With real IPv4 and IPv6 space alive.
Pretty much anyone who wants to do testing winds up needing some
amount of Internet, but we one 9 of reliability is probably enough.
What? DNSSEC, IPsec is what I do.
I think most groups could easily deal with bring hubs/switches, etc.
We would not bring wireless if asked not to.
----------------------------------------------------------------
Envelope-to: bfuller@foretec.com
From: Brett Thorson <bthorson@foretec.com>
To: "Barbara B. Fuller" <bfuller@foretec.com>
Subject: Testing @ IETF Meeting
Date: Thu, 11 Sep 2003 14:20:22 -0400
User-Agent: KMail/1.5
If the IESG decides to approve of the testing, they should be aware of the
added difficulties & cost that it adds to the host and/or Foretec.
>From some previous e-mails it reads that some of these testers were expecting
the network to be up and running when they got there (which would be before
the meeting). Trying to setup a network with "experiments" going on,
increases the level of stress while trying to get this network up and
running. On the back end, leaving the network run longer for testers is just
that many more days added onto a really long week (for the NOC Crew).
One of the considerations should also be the cost of this event. If we are
going to sanction testing before or after the meeting, some level of network
infrastructure will need to be setup before or remain after the meeting.
Even now, we have a hard time getting into these rooms before the meeting. The
hotel would rather sell them to a customer, rather than letting us in for
free before we have officially purchased the room. Also with the hotels now
adding more wiring to the buildings, and the IETF using that wiring, we also
incur the additional costs of using their infrastructure for these days. In
some cases (Such as Minneapolis) we have received gracious considerations
from both Onvoy and U of M in providing Internet circuits. Right now, they
are donating these to the IETF. Would we then need to offer some sort of fee
to them for using their networks beyond the official IETF meeting?
If we get into a hotel that doesn't mind us being there early, and lets us
leave the equipment there for as long as we want, or come in as early as we
want, then we still have the issue of people to set it up. (Hotel rooms,
meals, missed work, etc.)
All costs aside, it also encompasses a face to face issue. The relationship
that any host or secretariat has with the hotel is important. If you get a
good team at the hotel (and treat them right) the meeting is A LOT easier.
If these groups were to offer that they would show up at the hotel early, set
up their own equipment, I would also fear that these testers might not give
the hotel a good impression of the IETF. That would make our job (coming in
the week after, etc.) that much harder. The telecom guys especially, you
want to keep them happy, and starting off with a positive relationship is
VERY important.
Also take into consideration that the network quality expected at an IETF
meeting, is VERY different than the network expected at an Interop meeting.
People come to the IETF to work and attend meetings. I don't know a lot about
the Interop testing grounds, but I do know that they have a hot-stage event.
IETF usually does not. Most of our equipment (when Foretec has hosted the
meeting) is loaned and borrowed, and we usually don't get it until close to
meeting time. Making this hardware plug and play, with IETF expectations is
a different scenario then getting hardware early, hotstaging it, and finding
bugs and kinks early.
The possibility of a testing event is not out of our grasp. All the
challenges listed here have solutions. However, it doesn't appear that any
of the solutions are free. Nothing to say that it can't be done. I do think
having an open discussions about the costs & benefits of this event is worth
while.
Respectfully submitted,
Brett M. Thorson
---------------------------------------------------------------------------
On Monday 15 September 2003 13:13, Kevin C. Almeroth wrote:
> BTW, more info and a question. (I've CC'ed the person who will be running
> and coordinating the whole project: Krishan Ramachandran).
>
> Details on what we would like:
>
> 1. SNMP access (either from one of our UCSB machines or a
> machine we put at the IETF) to each wireless AP. From these
> APs we want to collect data from a variety of MIBs at intervals
> as short as one minute (or what load will allow without causing
> problems).
>
> 2. In conjunction with #1, we'd like to have access to all
> egress traffic so we can do a tcpdump of snaplen 60 bytes. We'll
> provide the machine, we just need a 100 Mbps Ethernet port.
>
> 3. We also want to set up a test network for supporting ad hoc
> networking. Basically, we'll set up 3-4 gateways at the edge
> of the IETF network and this will provide access to people with
> wireless cards who want to roam around using AODV. We'll
> eventualy be clearer about what our needs are from the IETF
> but this is the basic idea for now.
>
> The question: do you know what which vendors AP you'll be
> using? It makes a difference because each implements a
> different set of MIBs (related to #1).
>
> -Kevin
------------------------------------------------
7.3 Nomcom - List of open positions and appoint a Liaison
The new Nomcom is starting up.
The IESG needs to do two things:
- Send a list of open positions to be filled to the ExDir, for transmission to the NomCom
- Appoint a liaison to NomCom
I believe the people whose terms are expiring are (correct me if I'm wrong):
- Ned Freed
- Bert Wijnen
- Alex Zinin
- Steve Bellovin
- Allison Mankin
[it's only 5, because Erik was due to be up for reselection, and
Margaret replaced Erik early, and so got 2 1/2 years according to the rule]
I *think* the right thing to do at *this* time is to ask for straight
replacements. We haven't figured out anything else to ask for.
So the theoretically possible candidates for liaison to nomcom are:
- Harald Alvestrand
- Ted Hardie
- Thomas Narten
- Margaret Wasserman
- Randy Bush
- Bill Fenner
- Russ Housley
- Jon Peterson
7.4 Tony Hain appeal (Harald Alvestrand)
Background material: <http://www.ietf.org/IESG/Appeals.html>
Purpose of discussion:
- Evaluate what further information the IESG needs
- Assign a designated editor for an appeal response
7.5 Todd Glassey appeal (Bert Wijnen)
Background material:
1. From the IPR WG chairs (Steve and Rob)
http://www.machshav.com/~smb/tg/
2. From the responsible AD (Harald)
http://www.alvestrand.no/ietf/ipr/suspension/glassey.html
3. The original appeal
http://www.ietf.org/IESG/APPEALS/todd-glassey-appeal.txt
4. Some postings to the iesg-only list