[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for October 30, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the October 30, 2003 IESG Teleconference
This agenda was generated at 17:18:56 EDT, October 24, 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-vrrp-spec-v2-09.txt
Virtual Router Redundancy Protocol (Draft Standard) - 1 of 9
Note: Implementation report available at.
http://www.ietf.org/IESG/Implementations/rfc-2338-implementation.txt
Token: Alex Zinin
o draft-ietf-aaa-diameter-nasreq-13.txt
Diameter Network Access Server Application (Proposed Standard) - 2 of 9
Token: Randy Bush
o draft-ietf-sigtran-v5ua-04.txt
V5.2-User Adaption Layer (V5UA) (Proposed Standard) - 3 of 9
Token: Jon Peterson
o Four-document ballot: - 4 of 9
- draft-ietf-msgtrk-mtqp-11.txt
Message Tracking Query Protocol (Proposed Standard)
Note: Needs to be revised per IESG comments
- draft-ietf-msgtrk-model-07.txt
Message Tracking Model and Requirements (Informational)
Note: Needs to be revised per IESG comments
- draft-ietf-msgtrk-smtpext-05.txt
SMTP Service Extension for Message Tracking (Proposed Standard)
Note: Added to IESG agenda to get remaining discuss cleared
- draft-ietf-msgtrk-trkstat-05.txt
An Extensible Message Format for Message Tracking Responses (Proposed
Standard)
Note: Needs to be revised per IESG comments
Token: Ned Freed
o draft-ietf-webdav-acl-12.txt
WebDAV Access Control Protocol (Proposed Standard) - 5 of 9
Note: IESGácommentsáreturnedátoáWGáatáAltantaámeeting
Token: Ted Hardie
o draft-dasilva-l2tp-relaysvc-07.txt
L2TP Active Discovery Relay for PPPoE (Proposed Standard) - 6 of 9
Note: 2003-10-23: This has been stuck for a while due to a normative
reference to an informational RFC problem. This is not permitted per RFC
2026. Proposed resolution: advance as informational for now, but when a
more general way forward is identified, reclassify as PS. See
draft-ymbk-downref-00.txt
Token: Thomas Narten
o Three-document ballot: - 7 of 9
- draft-ietf-ipr-submission-rights-08.txt
IETF Rights in Contributions (BCP)
- draft-ietf-ipr-technology-rights-12.txt
Intellectual Property Rights in IETF Technology (BCP)
- draft-ietf-ipr-wg-guidelines-05.txt
Guidelines for Working Groups on Intellectual Property Issues
(Informational)
Token: Harald Alvestrand
o draft-ietf-imapext-condstore-04.txt
IMAP Extension for Conditional STORE operation (Proposed Standard) - 8 of
9
Note: On IESG agenda 30-Oct-2003
Token: Ned Freed
o Three-document ballot: - 9 of 9
- draft-ietf-geopriv-reqs-04.txt
Geopriv requirements (Informational)
- draft-ietf-geopriv-threat-analysis-01.txt
Threat Analysis of the geopriv Protocol (Informational)
- draft-ietf-geopriv-dhcp-lci-option-02.txt
Dynamic Host Configuration Protocol Option for Location Configuration
Information for GEOPRIV (Proposed Standard)
Token: Ted Hardie
2.1.2 Returning Item
o draft-ietf-msec-mikey-07.txt
MIKEY: Multimedia Internet KEYing (Proposed Standard) - 1 of 1
Token: Russ Housley
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-sigtran-signalling-over-sctp-applic-09.txt
Telephony Signalling Transport over SCTP applicability statement
(Informational) - 1 of 3
Token: Jon Peterson
o draft-ietf-tsvwg-dsack-use-02.txt
Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious
Retransmissions (Experimental) - 2 of 3
Token: Jon Peterson
o draft-ietf-rpsec-routing-threats-03.txt
Generic Threats to Routing Protocols (Informational) - 3 of 3
Token: Alex Zinin
3.1.2 Returning Item
o draft-ietf-manet-tbrpf-11.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental) - 1 of 3
Token: Alex Zinin
o draft-ietf-dhc-unused-optioncodes-07.txt
Unused DHCP Option Codes (Informational) - 2 of 3
Note: Already approved by IESG, pulled back to remove option codes that
were actually in use. Back again for re-approval.
Token: Margaret Wasserman
o draft-ietf-crisp-requirements-06.txt
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational) - 3 of 3
Note: Revised based on comments from first run at ballot
Token: Ted Hardie
3.2 Individual Submissions Via AD
3.2.1 New Item
NONE
3.2.2 Returning Item
o draft-gill-gtsh-04.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental) - 1 of 1
Token: Alex Zinin
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-dfncis-netnews-admin-sys-06.txt
Netnews Administration System (NAS) (Experimental) - 1 of 2
Note: AD review comments not completely addressed but might as well get
feedback from the entire IESG at this point.
Token: Ned Freed
o draft-carroll-dynmobileip-cdma-01.txt
Dynamic Mobile IP Key Update for cdma2000(R) Networks (Informational) - 2
of 2
Token: Thomas Narten
3.3.2 Returning Item
NONE
3.3.3 To be assigned
o draft-jseng-idn-admin-05.txt
Internationalized Domain Names Registration and Administration Guideline
for Chinese, Japanese and Korean (Informational)
4. Working Group Actions
4.1.1 Proposed for IETF Review
o Access Link Intermediaries Assisting Services (alias) - 1 of 1
Token: Jon
4.1.2 Proposed for Approval
o Credential and Provisioning (enroll) - 1 of 2
Token: Russ
o IP over DVB (ipdvb) - 2 of 2
Token: Margaret
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Agenda Working Group News
6. IAB News We can use
7. Management Issue
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the October 30, 2003 IESG Teleconference
This package was generated at 17:18:56 EDT, October 24, 2003.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, October 30,
2003 from 11:30-14:00 US-ET. If you are *unable* to participate in the
teleconference, or if you wish to change your usual procedures for
connecting to the call (as indicated in the list below), then please reply
to this message as follows:
o If you are unable to participate, then please write "Regrets" after your
name.
o If you normally call in, but will require operator assistance for this
teleconference, then please provide the telephone number where you can be
reached.
o If you are normally connected to the teleconference by an operator, but
will call in for this teleconference, then please write "Will call in"
next to your name in place of the telephone number.
Harald Alvestrand---Will call in
Rob Austein---Will call in
Steve Bellovin---Will call in
Randy Bush--- Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten--- Will call in
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Dinara Suleymanova--- Will call in
Amy Vezza---Will call in
Margaret Wasserman---Will call in
Bert Wijnen---Will call in
Alex Zinin---Will call in
To join the teleconference, please call the appropriate dial-in number
(see below) at 11:30 AM ET. If you have requested operator assistance,
then an operator will call you and connect you to the call. Participants
inside the U.S. should use the toll-free number 888-315-1685.
Participants outside the U.S. should use either one of the toll-free
numbers listed at the end of this message, or the direct-dial number
703-788-0617. Participants using the direct-dial number will pay their own
long distance charges through their own carriers. Participants dialing the
toll-free number will not pay any charges for the conference, as all
charges, including long distance, will be included on the invoice sent to
the company hosting the call. In some cases, participants from certain
international countries may only use a direct-dial number.
All participants should enter the passcode 235467 when prompted to do so.
The first person on the call will not hear anything until joined by other
participants. A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND
THUS INCUR CHARGES FROM THEIR OWN CARRIER.
1.2 Bash the Agenda
1.3 Approval of the Minutes
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the October 16, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Thomas Narten / IBM
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Dinara Suleymanova / IETF Secretariat
Amy Vezza / IETF Secretariat
Margaret Wasserman / Nokia
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Michelle Cotton / ICANN
Ned Freed / Sun Microsystems
Allison Mankin / Bell Labs, Lucent
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the October 2, 2003 Teleconference were approved.
The Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Jon Peterson to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Alex Zinin to send proposal and justification for interim
document review.
o Alex Zinin to phrase a question to RTG and OPS Area Directorats
and IAB on PPVPN issue. Alex to summarize the results as a proposed
IESG consensus regarding the PPVPN issue to be given to the PPVPN
working group.
o Harald Alvestrand to discuss with Barbara Fuller the process of
listing the scribes for IETF Meetings on WG charter Web pages.
DELETED:
NONE
IN PROGRESS:
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 Randy Bush and Bill Fenner to generate a description of policy
about a) meetings using the network in conjunction with IETF meetings, and b) putting experiments on the network during the IETF meeting.
o Ted Hardie to take responsibility for initiating a discussion on
applications' expectations on the behaviour of the DNS system.
NEW:
o Secretariat to send the updated EDU Team charter to the IETF Announce list for IETF review.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Two-document ballot: - 1 of 6
- draft-ietf-ccamp-gmpls-routing-08.txt
Routing Extensions in Support of Generalized Multi-Protocol Label Switching (Proposed Standard)
- draft-ietf-ccamp-ospf-gmpls-extensions-11.txt
OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (Proposed Standard)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve points raised by Russ Housley.*
o draft-vida-mld-v2-07.txt - 2 of 6
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard)
Token: Margaret Wasserman
The document remains under discussion by the IESG in order to resolve points raised by Randy Bush.*
o draft-ietf-msec-mikey-07.txt - 3 of 6
MIKEY: Multimedia Internet KEYing (Proposed Standard)
Token: Russ Housley
The document was deferred to the next teleconference (10/30/03) by Jon Peterson.
o draft-ietf-secsh-auth-kbdinteract-05.txt - 4 of 6
Generic Message Exchange Authentication For SSH (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve points raised by Steve Bellovin, Ned Freed, and Ted Hardie.*
o draft-ietf-mboned-msdp-deploy-03.txt - 5 of 6
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (BCP)
Token: Randy Bush
The document remains under discussion by the IESG in order to resolve points raised by Thomas Narten.*
o Two-document ballot: - 6 of 6
- draft-ietf-adslmib-hc-tc-06.txt
High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals (Proposed Standard)
- draft-ietf-adslmib-vdsl-12.txt
Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) (Proposed Standard)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve points raised by Margaret Wasserman.*
2.1.2 Returning Item
o draft-ietf-pkix-pi-07.txt - 1 of 1
Internet X.509 Public Key Infrastructure Permanent Identifier (Proposed Standard)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve points raised by Harald Alvestrand, Randy Bush, Ted Hardie, and Jon Peterson.*
2.2 Individual Submissions
2.2.1 New Item
o draft-blumenthal-aes-usm-07.txt - 1 of 3
The AES Cipher Algorithm in the SNMP's User-based Security Model (Proposed Standard)
Token: Steve Bellovin
The document remains under discussion by the IESG in order to resolve points raised by Russ Housley.*
o draft-rajeshkumar-mmusic-gpmd-03.txt - 2 of 3
SDP attribute for qualifying Media Formats with Generic Parameters (Proposed Standard)
Token: Jon Peterson
The document remains under discussion by the IESG in order to resolve points raised by Randy Bush, Ned Freed and Ted Hardie.*
o draft-ymbk-6to4-arpa-delegation-00.txt - 3 of 3
Delegation of 2.0.0.2.ip6.arpa (BCP)
Token: Russ Housley
The document remains under discussion by the IESG in order to resolve points raised by Bert Wijnen.*
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-ipsec-dpd-03.txt - 1 of 2
A Traffic-Based Method of Detecting Dead IKE Peers (Informational)
Token: Russ Housley
The document remains under discussion by the IESG.*
o draft-ietf-ipsec-nat-reqts-05.txt - 2 of 2
IPsec-NAT Compatibility Requirements (Informational)
Token: Russ Housley
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Russ Housley. The Secretariat will send a working group submission Document Action announcement that includes the RFC Editor Note.
3.1.2 Returning Item
o draft-ietf-ipo-framework-05.txt - 1 of 2
IP over Optical Networks: A Framework (Informational)
Token: Alex Zinin
The document was removed from the agenda by Alex Zinin.
o draft-ietf-dhc-unused-optioncodes-07.txt
Unused DHCP Option Codes (Informational)
Token: Margaret Wasserman
The document was removed from the agenda by Margaret Wasserman. The Secretariat will place the document on the agenda for the next IESG teleconference (10/30/03).
3.2 Individual Submissions Via AD
3.2.1 New Item
NONE
3.2.2 Returning Item
o draft-gill-gtsh-04.txt - 1 of 1
The Generalized TTL Security Mechanism (GTSM) (Experimental)
Token: Alex Zinin
The document was removed from the agenda by Alex Zinin. The Secretariat will place the document on the agenda for the next IESG teleconference (10/30/03).
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-bless-diffserv-pdb-le-01.txt - 1 of 3
A Lower Effort Per-Domain Behavior for Differentiated Services (Informational)
Token: Jon Peterson
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.
o draft-bless-diffserv-multicast-07.txt - 2 of 3
IP Multicast in Differentiated Services Networks (Informational)
Token: Bill Fenner
The IESG has no problem with the RFC Editor publishing this document. The Secretariat will send a "no problem" message that includes an RFC Editor note to be prepared by Bill Fenner.
o draft-ogura-mapos-nsp-multiexp-02.txt - 3 of 3
A Multicast Extension to MAPOS NSP (Node Switch Protocol) (Informational)
Token: Thomas Narten
The IESG recommends that this document not be published as an Informational RFC. The Secretariat will send a "do not publish" message to the RFC Editor that includes an explanation of the decision to be prepared by Thomas Narten.
3.3.2 Returning Item
NONE
3.3.3 To Be Assigned
o draft-aboulmagd-trtcm-inprofile-01.txt - 1 of 1
The document was assigned to Jon Peterson.
4. Working Group Action
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Credential and Provisioning (enroll) - 1 of 2
Token: Russ Houlsey
The IESG approved the draft working group charter for IETF review.
The Secretariat will send a WG Review announcement, with a copy to
new-work@ietf.org. The Secretariat will place the working group
on the agenda for the next IESG teleconference (10/30/03).
o IP over DVB (ipdvb) - 2 of 2
Token: Margaret Wasserman
The IESG approved the draft working group charter for IETF review.
The Secretariat will send a WG Review announcement, with a copy to
new-work@ietf.org. The Secretariat will place the working group
on the agenda for the next IESG teleconference (10/30/03).
4.1.2 Proposed for Approval
o Long-Term Archive and Notary Services (ltans) - 1 of 3
Token: Russ Housley
The IESG approved the charter for the new working group. The
Secretariat will send a WG Action announcement.
o MIPv6 Signaling and Handoff Optimization (mipshop) - 2 of 3
Token: Thomas Narten
The IESG approved the charter for the new working group. The
Secretariat will send a WG Action announcement.
o Internet and Management Support for Storage (imss) - 3 of 3
Token: Margaret Wasserman
The IESG approved the charter for the new working group. The
Secretariat will send a WG Action announcement.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
o Multiprotocol Label Switching (mpls) - 1 of 3
Token: Alex Zinin
The IESG approved the revised charter for the working group. The Secretariat will send a WG Action: RECHARTER announcement, to include additional text to be provided by Alex Zinin.
o Common Control and Measurement Plane (ccamp) - 2 of 3
Token: Alex Zinin
The IESG approved the revised charter for the working group. The Secretariat will send a WG Action: RECHARTER announcement, to include additional text to be provided by Alex Zinin.
o Ethernet Interfaces and Hub MIB (hubmib) - 3 of 3
Token: Bert Wijnen
The IESG approved the revised charter for the working group. The Secretariat will send a WG Action: RECHARTER announcement.
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
7.1 EDU Team updated charter (Harald Alvestrand)
This management issue was discussed.
----------------------------------------
* Please see the ID Tracker
(https://datatracker.ietf.org/public/pidtracker.cgi) for details
on documents that are under discussion by the IESG.
1. Administrivia
1.4 Review of Action Items
OUTSTANDING TASKS
Last updated: October 20, 2003
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 Randy Bush and Bill Fenner to generate a description of policy about
a) meetings using the network in conjunction with IETF meetings, and b)
putting experiments on the network during the IETF meeting.
IP o Ted Hardie to take responsibility for initiating a discussion on applications'
expectations on the behavior of the DNS system.
IP o Secretariat to send the updated EDU Team charter to the IETF Announce list for IETF review.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 9
o draft-ietf-vrrp-spec-v2-09.txt
Virtual Router Redundancy Protocol (Draft Standard)
Note: Implementation report available at.
http://www.ietf.org/IESG/Implementations/rfc-2338-implementation.txt
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-vrrp-spec-v2-09.txt to Draft Standard
--------
Evaluation for draft-ietf-vrrp-spec-v2-09.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=3948&rfc_flag=0
Last Call to expire on: 2003-10-24
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 [ 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>, <vrrp@ietf.org>
Subject: Protocol Action: 'Virtual Router Redundancy Protocol' to Draft
Standard
The IESG has approved following document:
- 'Virtual Router Redundancy Protocol '
<draft-ietf-vrrp-spec-v2-09.txt> as a Draft Standard
This document is the product of the Virtual Router Redundancy Protocol
Working
Group.
The IESG contact persons are Alex Zinin and Bill Fenner.
Technical Summary
VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a
LAN. The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail over
in the forwarding responsibility should the Master become
unavailable. This allows any of the virtual router IP addresses on
the LAN to be used as the default first hop router by end-hosts. The
advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router
discovery protocols on every end-host.
Working Group Summary
There was a consensus within the WG on this document
Protocol Quality
The specification has been reviewed for the IESG by Alex Zinin and
Bill Fenner. The protocol has been widely implemented and deployed.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 2 of 9
o draft-ietf-aaa-diameter-nasreq-13.txt
Diameter Network Access Server Application (Proposed Standard)
Token: Randy Bush
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-aaa-diameter-nasreq-13.txt to Proposed
Standard
--------
Evaluation for draft-ietf-aaa-diameter-nasreq-13.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=6536&rfc_flag=0
Last Call to expire on: 2003-10-20
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 [ ] [ ] [ ] [ ]
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>, <aaa-wg@merit.edu>
Subject: Protocol Action: 'Diameter Network Access Server
Application' to Proposed Standard
The IESG has approved following document:
- 'Diameter Network Access Server Application '
<draft-ietf-aaa-diameter-nasreq-12.txt> as a Proposed Standard
This document is the product of the Authentication, Authorization and
Accounting Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen.
Technical Summary
This document describes the Diameter protocol application used for
Authentication, Authorization and Accounting (AAA) services in the
Network Access Server (NAS) environment. This application
specification, when combined with the Diameter Base protocol,
Transport Profile, and Extensible Authentication Protocol
specifications, satisfies typical network access services
requirements.
Initial deployments of the Diameter protocol are expected to include
legacy systems. Therefore, this application was carefully designed to
ease the burden of protocol conversion between RADIUS and Diameter.
This is achieved by including the RADIUS attribute space, and
eliminating the need to perform many attribute translations.
Working Group Summary
This document is the product of the aaa working group, and had wg
consensuus. Comments in IETF last call were addressed by the current
document.
Protocol Quality
This document was reviewed for the IESG by Randy Bush.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 9
o draft-ietf-sigtran-v5ua-04.txt
V5.2-User Adaption Layer (V5UA) (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-sigtran-v5ua - V5.2-User Adaption
Layer (V5UA) to Proposed Standard
--------
Last Call to expire on: July 2, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ X ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ X ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Steve: In Section 3, are the "recommended" clauses supposed to be
SHOULDs? There are similar issues in Section 4, i.e., the lower-case
"shall" in 4.1, 4.2, etc.
I'm confused about precisely what this document is specifying, as
opposed to what's already in V5.2. Section 4.3 is a good example,
since it speaks of V5 changes to IUA. I thought this was about V5UA.
Section 5.1 speaks of layer 1 and 2. Are those OSI layers or V5
layers? If the latter, what is the relationship to anything in SCTP?
Must wait for a revision of the base document security considerations.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sigtran@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: V5.2-User Adaption Layer (V5UA) to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'V5.2-User Adaption Layer
(V5UA)' <draft-ietf-sigtran-v5ua-03.txt> as a Proposed Standard.
This document is the product of the Signaling Transport Working Group.
The IESG contact persons are Allison Mankin and Scott Bradner.
Technical Summary
This document defines a mechanism for backhauling of ETSI digital
local exchange V5.2 messages over IP using the Stream control
Transmission Protocol (SCTP). This protocol can be used between a
Signaling Gateway (SG) and a Media Gateway controller (MGC). It is
assumed that the SG receives V5.2 signaling over a standard V5.2
interface.
This document builds on the ISDN User Adaptation Layer Protocol
(IUAP), defined in RFC 3057. This document defines all differences
to the IUAP needed for the V5.2 implementation.
Working Group Summary
The working group supported publication of this document.
Protocol Quality
This document was reviewed for the IESG by Scott Bradner.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 9
o Four-document ballot:
- draft-ietf-msgtrk-smtpext-05.txt
SMTP Service Extension for Message Tracking (Proposed Standard)
Note: Added to IESG agenda to get remaining discuss cleared
- draft-ietf-msgtrk-mtqp-11.txt
Message Tracking Query Protocol (Proposed Standard)
Note: Needs to be revised per IESG comments
- draft-ietf-msgtrk-model-07.txt
Message Tracking Model and Requirements (Informational)
Note: Needs to be revised per IESG comments
- draft-ietf-msgtrk-trkstat-05.txt
An Extensible Message Format for Message Tracking Responses (Proposed
Standard)
Note: Needs to be revised per IESG comments
Token: Ned Freed
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-msgtrk-smtpext - SMTP Service Extension
for Message Tracking to Proposed Standard
--------
Last Call to expire on: 2002-12-6
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ XX] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve:
In draft-ietf-msgtrk-mtqp-09.txt, it says that the hostname parameter
in the STARTTLS command is optional. I think it needs to be mandatory;
the client has no way of knowing if the server is handling several
domains, and the server has no other way of knowing which domain the
client wants.
It isn't clear to me why the server SHOULD abort the connection if
TLS negotiation fails, but is told to decide what to do if the
negotiated TLS is insufficiently secure. Isn't negotiation failure
just a very insecure case? Or is there some other protocol issue?
Section 6 implies that server support of TLS is optional:
If an MTQP server supports TLS, it MUST include
"STARTTLS" ...
Is that correct? Is that acceptable?
[This are minor matters; I'm not sure which side of the "send an RFC
editor's note" they fall on.]
COMMENTS:
=========
Bill:
ABNF issues:
draft-ietf-msgtrk-smtpext-04.txt:
- "base64" and "digit" are not defined.
draft-ietf-msgtrk-mtqp-09.txt:
- Fix comment characters (";", not "#")
- Remove trailing ) from identifier definition
draft-ietf-msgtrk-trkstat-04.txt:
- "arrival-date" should be "arrival-date-field"
Steve:
Here are some additional comments on draft-ietf-msgtrk-smtpext from ekr.
------- Forwarded Message
Delivered-To: smb@research.att.com
X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to ekr@rtfm.com using -f
To: Steve Bellovin <smb@research.att.com>
Subject: Re: Evaluation: draft-ietf-msgtrk-smtpext - SMTP Service Extension for Message (fwd)
In-reply-to: Your message of "Wed, 11 Dec 2002 22:59:41 EST."
<20021212035941.3D3DC7B6B@berkshire.research.att.com>
X-Mailer: mh-e 6.1; nmh 1.0.4; Emacs 21.1
Date: Wed, 11 Dec 2002 23:35:34 -0800
From: Eric Rescorla <ekr@rtfm.com>
Message-Id: <20021212073534.6F11B72C2@sierra.rtfm.com>
Content-Type: text
X-UIDL: 8bdc4865c146cf41da609b528024520b
X-Spam-Status: No, hits=-3.0 required=5.0
tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD
version=2.31
X-Spam-Level:
I pretty much agree with your comments. I also have some
additional ones:
S 4
It's not clear what good the "TLS required" error does you, seeing as
the secret has just been transmitted in the clear :)
S 6
"TLS [TLS] more commonly known as SSL" ... not quite.
If it were me I'd make TLS a SHOULD.
S 6.1
I'm not that comfortable with the fact that no real guidance is
provided about the peer identities. Is there some reason that they
shouldn't match the FQDN? At least if one is caching the peer's
use of STARTTLS you should cache the cert identity.
As a nit, these guys are using "privacy" when they really mean
"confidentiality"
You write:
> It isn't clear to me why the server SHOULD abort the connection if
> TLS negotiation fails, but is told to decide what to do if the
> negotiated TLS is insufficiently secure. Isn't negotiation failure
> just a very insecure case? Or is there some other protocol issue?
Not quite. The thing is that an attacker can forge a handshake
failure. He can't downgrade the connection--though he can forge
a bad certificate. So, this is a little subtle. I'm not sure
that your conclusion is wrong, though.
>Section 6 implies that server support of TLS is optional:
>
> If an MTQP server supports TLS, it MUST include
> "STARTTLS" ...
>
>Is that correct? Is that acceptable?
Wasn't this a problem with STARTTLS in SMTP? I.e. if you have
TLS compiled in but no cert, then you shouldn't be advertising
TLS, right? But you could be said to support it.
- -Ekr
Allison:
A comment to be recorded with the Discusses:
No further objection, but a suggestion when they fix the issues
that Steve Bellovin raised about their TLS use - the TLS is used
message by message with a full handshake each time.
I think there is likely a mode for users where there are multiple
queries and then TLS session resumption is useful instead of full
handshakes.
I like the IANA Considerations.
Steve and Ned:
>> >Steve Bellovin [ ] [ ] [ X ] [ ]
>
>> It isn't clear to me why the server SHOULD abort the connection if
>> TLS negotiation fails, but is told to decide what to do if the
>> negotiated TLS is insufficiently secure. Isn't negotiation failure
>> just a very insecure case? Or is there some other protocol issue?
>
>This is a TLS protocol issue. A TLS negotiation failure almost always
>leaves the connection in an unusable state. The only practical way to
>proceed is to abort.
>
>I wish I could say I only know about this anecdotally, but that isn't
>true...
That's what I was wondering about. No problem here...
>
>> Section 6 implies that server support of TLS is optional:
>
>> If an MTQP server supports TLS, it MUST include
>> "STARTTLS" ...
>
>> Is that correct? Is that acceptable?
>
>I believe the point here is to try and ban automatic port-based use
>of TLS. A very good idea IMO.
>
>As to whether or not server support of TLS is optional, it has to be.
>Remember, mandatory to implement != mandatory to use, and it is
>important that a server that implements TLS but isn't configured to
>actually support its use not present STARTTLS. Confusion about this
>particular point is what has killed opportunistic use of TLS with
>SMTP -- likely forever.
OK. In that case, perhaps a sentence clarifying that TLS is mandatory
to implement, but that administrators are free to disable it or that it
might be disabled if there's no certificate available.
Steve:
Let me add one more point based on ekr's comments. He observed,
correctly, that an error response of "insecure" from the server is too
late, in that the confidential information is already exposed. (Well,
the response isn't, but an eavesdropper can then request the response
itself.) That implies that a server that always wants TLS to be used
should indicate that at sign-on time, so that it doesn't get any
non-TLS queries.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-msgtrk@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: SMTP Service Extension for Message Tracking
to Proposed Standard
-------------
The IESG has approved the publication of the following three
Internet-Drafts as Proposed Standards:
o SMTP Service Extension for Message Tracking
<draft-ietf-msgtrk-smtpext-04.txt>
o An Extensible Message Format for Message Tracking Responses
<draft-ietf-msgtrk-trkstat-04.txt>
o Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-09.txt>
In addition, the IESG has also approved publication of Message
Tracking Model and Requirements <draft-ietf-msgtrk-model-07.txt>
as an Informational RFC.
These documents are the product of the Message Tracking Protocol
Working Group. The IESG contact persons are Ned Freed and Patrik
Faltstrom.
Technical Summary
Message tracking is the ability to find out the path that a
particular email message has taken through a messaging infrastructure
and the current routing status of that message. This set of documents
defines a model for message tracking, an SMTP extension used to control
tracking information, and a query protocol that can be used to
determine the current status of a specific message.
Working Group Summary
These documents are the product of the Message Tracking Protocol
Working Group.
Protocol Quality
Ned Freed reviewed these specifications for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 5 of 9
o draft-ietf-webdav-acl-12.txt
WebDAV Access Control Protocol (Proposed Standard)
Note: IESGácommentsáreturnedátoáWGáatáAltantaámeeting
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-ietf-webdav-acl - WebDAV Access Control
Protocol to Proposed Standard
--------
Last Call to expire on: 2002-11-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ X ]
Scott Bradner [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ ] [ X ] [ ]
Bert Wijnen [ ] [ XX] [ X ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
--------
Allison:
My Discuss is that the security for this draft all hinges on RFC 2617
(HTTP Digest) authentication of the principals as the mandatory to
implement. There's no integrity for the requests, because RFC 2617
offers only limited integrity protection - it does protect the login.
Given the number of operations that expose private data or could
be like a "root", the authentication is serious. HTTP Digest login is
probably an ok (universally implemented, MD5) login, but they have left
BASIC as an option, which is a plaintext password and this should
not be ok - this needs to be forbidden for WEBDAV use. (It is
explicitly allowed currently).
Not sure what the integrity fix can be: requirement of use of
TLS seems the likely choice. The main risk seems to be bid-down
attack on the ACL by an attacker, but this might be a problem.
Also, looking at this as a Web file system of sorts, the draft
should include an applicability considerations discussion that
covers issues of ACL sets and differences of capabilities that may
arise in implementation. Is there an implicit minimum subset buried in
here and should it be explicit? What is the extensibility model?
Finally, reflecting on SMB's well-taken point about the complexity,
there seem to be implementations (microsoft, xythos, others) - how about
asking for an early interop report to flush out what's used, what's
theoretical here?
Bert:
Actually I have not checked this one in detail.
But when going through it I did notice they use (for example,
this is not an extensive list):
Host: www.webdav.org
Host: www.foo.org
"users@foo.org"
Host: www.BigCorp.com
Etc...
Ned, if you want to include it with some other DISCUSS, that is fine too
Comment:
--------
Scott: I find it hard to think that a 66 page security doc will
add to security.
Steve: Nit: I don't think we want URLs in the abstract.
Some non-ASCII characters present.
Serious: this is hideously complex. The rules in Section 6 are
*scary* -- I have no confidence in either the implementors or
(especially) the folks administering such rules. Are they really
all necessary? I personally have a very strong bias for first
match. See ftp://ftp.cert.dfn.de/pub/firewalls/discussion/pkt_filtering.ps.gz
for one example of why.
7.4 is preposterous, as is 9.4.
The document is much too oriented towards GUIs: "It is envisioned
that a WebDAV ACL-aware administrative client would list the
supported privileges in a dialog box." What happens when a
script-driven program -- dare I say a Unix-like shell? -- wants to
perform operations on an entire forest of these ACLs? The same bias
is implicit in the Internationalization section.
Can 12.3 lead to race conditions?
I'm listing myself as "abstain" rather than "discuss", because I have
no suggested changes short of "go back and start over", and I don't
regard that as likely. But I'm not saying "no-ob" because I do think
this document is dangerous, especially Section 6.
Ned:
> In message <200211081733.MAA00600@ietf.org>, IESG Secretary writes:
> >
> >Last Call to expire on: 2002-11-5
> >
> > Please return the full line with your position.
> >
> > Yes No-Objection Discuss * Abstain
> >
> >
> >Steve Bellovin [ ] [ ] [ ] [ X ]
> Nit: I don't think we want URLs in the abstract.
> Some non-ASCII characters present.
> Serious: this is hideously complex. The rules in Section 6 are
> *scary* -- I have no confidence in either the implementors or
> (especially) the folks administering such rules. Are they really
> all necessary?
I pushed back on this. The response was that the WG believes all the
mechanisms are necessary and all will in fact be used.
> I personally have a very strong bias for first
> match. See ftp://ftp.cert.dfn.de/pub/firewalls/discussion/pkt_filtering.ps.gz
> for one example of why.
I'm more of a (sum positive) - (sum negative) person myself.
> 7.4 is preposterous, as is 9.4.
Yes, they are both ugly.
> The document is much too oriented towards GUIs: "It is envisioned
> that a WebDAV ACL-aware administrative client would list the
> supported privileges in a dialog box." What happens when a
> script-driven program -- dare I say a Unix-like shell? -- wants to
> perform operations on an entire forest of these ACLs? The same bias
> is implicit in the Internationalization section.
> Can 12.3 lead to race conditions?
I guess, but I doubt it is the only, let alone the major source of
such things in WebDAV.
> I'm listing myself as "abstain" rather than "discuss", because I have
> no suggested changes short of "go back and start over", and I don't
> regard that as likely. But I'm not saying "no-ob" because I do think
> this document is dangerous, especially Section 6.
Hopefully some of these can be dropped before moving to draft.
Ned
Steve:
>
>> Serious: this is hideously complex. The rules in Section 6 are
>> *scary* -- I have no confidence in either the implementors or
>> (especially) the folks administering such rules. Are they really
>> all necessary?
>
>I pushed back on this. The response was that the WG believes all the mechanism
>s
>are necessary and all will in fact be used.
>
>> I personally have a very strong bias for first
>> match. See ftp://ftp.cert.dfn.de/pub/firewalls/discussion/pkt_filtering.ps.
>gz
>> for one example of why.
>
>I'm more of a (sum positive) - (sum negative) person myself.
>
Purists about ACL theory don't even allow for negation in ACLs, because
then you can't prove certain things....
Ned:
> Yes No-Objection Discuss * Abstain
> Allison Mankin [ ] [ ] [ X ] [ ]
> My Discuss is that the security for this draft all hinges on RFC 2617
> (HTTP Digest) authentication of the principals as the mandatory to
> implement. There's no integrity for the requests, because RFC 2617
> offers only limited integrity protection - it does protect the login.
> Given the number of operations that expose private data or could
> be like a "root", the authentication is serious. HTTP Digest login is
> probably an ok (universally implemented, MD5) login, but they have left
> BASIC as an option, which is a plaintext password and this should
> not be ok - this needs to be forbidden for WEBDAV use. (It is
> explicitly allowed currently).
It is allowed, but only over a secure channel. Specifically, RFC 2518 says:
A password sent in the clear over an insecure channel is an inadequate means
for protecting the accessibility and integrity of a resource as the password
may be intercepted. Since Basic authentication for HTTP/1.1 performs
essentially clear text transmission of a password, Basic authentication MUST
NOT be used to authenticate a WebDAV client to a server unless the connection
is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication
credentials in a WWW-Authenticate header unless the connection is secure.
Examples of secure connections include a Transport Layer Security (TLS)
connection employing a strong cipher suite with mutual authentication of client
and server, or a connection over a network which is physically secure, for
example, an isolated network in a building with restricted access.
The current document relies on the base WEBDAV specification for the rules
about how authentication is done. It says:
This specification intentionally omits discussion of authentication, as the
HTTP protocol already has a number of authentication mechanisms [RFC2617].
Some authentication mechanism (such as HTTP Digest Authentication, which all
WebDAV compliant implementations are required to support) must be available to
validate the identity of a principal.
Now, perhaps the words in the preceeding paragraph should be changed to point
at RFC 2518 section 17.1. Nevertheless, I think you're seeing an issue that
isn't really there.
> Not sure what the integrity fix can be: requirement of use of
> TLS seems the likely choice. The main risk seems to be bid-down
> attack on the ACL by an attacker, but this might be a problem.
To the extent that unencrypted passwords are an issue I see them as an
issue with the base WEBDAV protocol, not with ACLs.
> Also, looking at this as a Web file system of sorts, the draft
> should include an applicability considerations discussion that
> covers issues of ACL sets and differences of capabilities that may
> arise in implementation. Is there an implicit minimum subset buried in
> here and should it be explicit? What is the extensibility model?
My reading is that servers have to support the whole thing. Progression to
draft standard will require demonstration of actual use of each feature. I
don't think it makes sense to ask for a minimum subset at this point -- indeed,
it seems to me that would open the door for bad behavior on the part of
implementations done by the more powerful players to omit useful stuff they
don't use themselves.
> Finally, reflecting on SMB's well-taken point about the complexity,
> there seem to be implementations (microsoft, xythos, others) - how about
> asking for an early interop report to flush out what's used, what's
> theoretical here?
I can ask, but I believe these folks do interop tests all the time. So this
is likely to produce a report listing everything. I don't think it is likely
to produce a list of stuff clients actually use in the real world. Only
real deployment and use will provide that.
Ned:
> > Bert Wijnen [ ] [ ] [ X ] [ ]
> Actually I have not checked this one in detail.
> But when going through it I did notice they use (for example,
> this is not an extensive list):
> Host: www.webdav.org
> Host: www.foo.org
> "users@foo.org"
> Host: www.BigCorp.com
> Etc...
> Ned, if you want to include it with some other DISCUSS, that is fine too
Here is what I have so far:
The DAV:all-grant-before-any-deny element defined in section 6.1.2. Either this
element is misnamed or the text description is in error. Specifically, the text
says (to me at least) that this element specifies a combinding rule where if
any ACE denies access the request fails. Ordering therefore has nothing to do
with it; the ACE that denies access can appear anywhere in the ACL. Assuming
the description is correct, it seems that the use of the word "before" in the
element name is a misnomer. Perhaps the name be changed to something like
any-deny-overrides-grant.
This document uses various domain names such as www.webdav.org, www.foo.org,
foo.org, and www.BigCorp.com. RFCs are supposed to use specific domains
in examples: example.com, example.net, etc.
The introduction states, in part:
This specification intentionally omits discussion of authentication, as the
HTTP protocol already has a number of authentication mechanisms [RFC2617].
Some authentication mechanism (such as HTTP Digest Authentication, which all
WebDAV compliant implementations are required to support) must be available
to validate the identity of a principal.
This should be changed to refer to the discussion of authentication in
RFC 2518 section 17.1. In particular, this document needs to refer to something
that makes it clear that BASIC authentication can only be used in conjunction
with some sort of security layer.
Ned
Ned
^L
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 Access Control Protocol to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'WebDAV Access Control
Protocol' <draft-ietf-webdav-acl-09.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 and Patrik Faltstrom.
Technical Summary
This document specifies a set of methods, headers, message bodies,
properties, and reports that define Access Control extensions to the
WebDAV Distributed Authoring Protocol. This protocol permits a client
to read and modify access control lists that instruct a server
whether to allow or deny operations upon a resource (such as
HyperText Transfer Protocol (HTTP) method invocations) by a given
principal. A lightweight representation of principals as Web
resources supports integration of a wide range of user management
repositories. Search operations allow discovery and manipulation of
principals using human names.
Working Group Summary
This document is a product of the Web Distributed Authoring and
Versioning (WebDAV) working group of the Internet Engineering Task
Force.
Protocol Quality
Ned Freed reviewed this document for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 6 of 9
o draft-dasilva-l2tp-relaysvc-07.txt
L2TP Active Discovery Relay for PPPoE (Proposed Standard)
Note: 2003-10-23: This has been stuck for a while due to a normative
reference to an informational RFC problem. This is not permitted per RFC
2026. Proposed resolution: advance as informational for now, but when a
more general way forward is identified, reclassify as PS. See
draft-ymbk-downref-00.txt
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-dasilva-l2tp-relaysvc - L2TP Active
Discovery Relay for PPPoE to Proposed Standard
--------
Last Call to expire on: 2003-1-29
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Randy:
yes, i know i used to be a no-ob. but an ops-dir reviewer wants
to point out the appended.
randy
---
Can you have a standards-track document based which in some sense
extends and support a protocol (PPPoE) that's documented as an
Informational RFC?
I'll repeat a comment I made on the L2TP list (I think) months (a
year?) ago about some other attempt to extend PPPoE. How about
someone work on L2TP on Ethernet MAC? It was the absense of this
particular combination which prompted the work to produce PPPoE in the
first place. I can see the irresistable urge to make use of the
extensibility of L2TP to make just about anything possible, but there
may be a more sound solution by just "doing" L2TP on Ethernet and
getting it out there starting adoption. A moderately clever
implementation could even support both protocol on the same port for
transition.
PPPoE was one of those 80%/20% sort of things; never intended to
solve all the worlds problems. This, of course, hasn't stopped people
from trying.
COMMENTS:
=========
Ted:
2 Nits, both in section 2.3: "is simply ensure" should probably
be "is simply to ensure" and "given that it is only the
source of the encrypted and data" seems to be missing a noun.
I'm also not generally in favor of the kind of overloading that 2.3
implies you might do with your "arbitrary data" (since it tends
to get a lot less arbitrary when you do so), but since they only
said someone might do it and didn't define a mechanism we
could actually check for corner cases, I don't think there's
anything we could do about it.
Thomas:
> 2 Nits, both in section 2.3: "is simply ensure" should probably
> be "is simply to ensure" and "given that it is only the
> source of the encrypted and data" seems to be missing a noun.
ack.
> I'm also not generally in favor of the kind of overloading that 2.3
> implies you might do with your "arbitrary data" (since it tends
> to get a lot less arbitrary when you do so), but since they only
> said someone might do it and didn't define a mechanism we
> could actually check for corner cases, I don't think there's
> anything we could do about it.
Can you expand? I don't understand the concern.
The basic idea here is that the "abitrary data" is internal state of
the sender. No one else uses that data (or parses it) it is simply
echoed back in the response traffic, allowing the relaying device to
insert state about the "request response pair" in the message and then
extract it from the response. This allows it to put the state in the
message rather than on the device (i.e, devices are more stateless).
Thomas:
Randy Bush <randy@psg.com> writes:
> Yes No-Objection Discuss * Abstain
> Randy Bush [ ] [ ] [ x ] [ ]
> yes, i know i used to be a no-ob. but an ops-dir reviewer wants
> to point out the appended.
> randy
> ---
> Can you have a standards-track document based which in some sense
> extends and support a protocol (PPPoE) that's documented as an
> Informational RFC?
Of course. Does anyone thing otherwise?
I.e., can DHCP carry options for proprietary things? Do routing
protocol also support non-standards track usages? Etc.
> I'll repeat a comment I made on the L2TP list (I think) months (a year?)
> ago about some other attempt to extend PPPoE. How about someone work
> on L2TP on Ethernet MAC? It was the absense of this particular combination
> which prompted the work to produce PPPoE in the first place. I can see
> the irresistable urge to make use of the extensibility of L2TP to make
> just about anything possible, but there may be a more sound solution
> by just "doing" L2TP on Ethernet and getting it out there starting
> adoption. A moderately clever implementation could even support both
> protocol on the same port for transition.
This document is about an extension to l2tp that solves a real
problem. I'm not sure what the above is getting at. We should drop
this work and do something else that is a better fix to pppoe? Been
there, tried that. pppoe is out there, and is broken. It can't be
fixed without a major overhaul that is not backwards compatable. I
detect no interest in doing this (some folks tried to have a BOF on
this general topic, but there really wasn't consensus/interest to do
this).
> PPPoE was one of those 80%/20% sort of things; never intended to solve
> all the worlds problems. This, of course, hasn't stopped people from
> trying.
So, I view the above as interesting commentary, but largely orthogonal
to whether this document should go forward.
Thomas
Bert:
> > Randy Bush [ ] [ ] [ x ] [ ]
>
> > yes, i know i used to be a no-ob. but an ops-dir reviewer wants
> > to point out the appended.
>
> > randy
>
> > ---
>
> > Can you have a standards-track document based which in some sense
> > extends and support a protocol (PPPoE) that's documented as an
> > Informational RFC?
>
> Of course. Does anyone thing otherwise?
>
Well, it would have to have the base doc as NORMATIVE ref and
a PS cannot rely on a info as a NORMATIVE ref can it?
Or we need to make an exception, don't we?
Bert
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, l2tpext@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: L2TP Active Discovery Relay for PPPoE to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'L2TP Active Discovery Relay
for PPPoE' <draft-dasilva-l2tp-relaysvc-06.txt> as a Proposed
Standard. This document is the product of the Layer Two Tunneling
Protocol Extensions Working Group. The IESG contact persons are
Thomas Narten and Erik Nordmark.
Technical Summary
PPPoE is often deployed in conjunction with L2TP to carry PPP frames
over a network beyond the reach of the local Ethernet network to
which a PPPoE Host is connected. For example, PPP frames tunneled
within PPPoE may be received by an L2TP Access Concentrator (LAC) and
then tunneled to any L2TP Network Server (LNS) reachable via an IP
network.
In addition to tunneling PPP over Ethernet, PPPoE defines a simple
method for discovering services offered by PPPoE Access Concentrators
(PPPoE AC) reachable via Ethernet from the PPPoE Host. Since the
packets used in this exchange are not carried over PPP, they are not
tunneled with the PPP packets over L2TP, thus the discovery
negotiation cannot extend past the LAC without adding functionality.
This document describes a simple method for relaying PPPoE Access
Discovery (PAD) messages over L2TP by extracting the PAD messages and
sending them over the L2TP control channel. After the completion of
setup through the processing of PAD messages, PPP packets arriving
via PPPoE are then tunneled over L2TP in the usual manner as defined
in L2TP [2]. Thus, there are no data plane changes required at the
LAC or LNS to support this feature. Also, by utilizing the L2TP
control channel, the PPPoE discovery mechanism is transported to the
LNS reliably, before creation of any L2TP sessions, and may take
advantage of any special treatment applied to control messages in
transit or upon receipt.
Working Group Summary
There was support for this document in the WG.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 7 of 9
o Three-document ballot:
- draft-ietf-ipr-submission-rights-08.txt
IETF Rights in Contributions (BCP)
- draft-ietf-ipr-technology-rights-12.txt
Intellectual Property Rights in IETF Technology (BCP)
- draft-ietf-ipr-wg-guidelines-05.txt
Guidelines for Working Groups on Intellectual Property Issues
(Informational)
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-ietf-ipr-submission-rights-08.txt to BCP,
draft-ietf-ipr-technology-rights-12.txt to BCP,
draft-ietf-ipr-wg-guidelines-05.txt to Informational RFC
--------
Evaluation for draft-ietf-ipr-submission-rights-08.txt,
draft-ietf-ipr-technology-rights-12.txt, draft-ietf-ipr-wg-guidelines-05.txt
can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9614&rfc_flag=0
Last Call to expire on: 2003-08-11
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ R ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
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:
======================
^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>, <ipr-wg@ietf.org>
Subject: Protocol Action: 'IETF Rights in Contributions' to BCP
The IESG has approved following documents:
- 'Guidelines for Working Groups on Intellectual Property Issues '
<draft-ietf-ipr-wg-guidelines-05.txt> as an Informational RFC
- 'IETF Rights in Contributions '
<draft-ietf-ipr-submission-rights-07.txt> as a BCP
- 'Intellectual Property Rights in IETF Technology '
<draft-ietf-ipr-technology-rights-11.txt> as a BCP
These documents are products of the Intellectual Property Rights Working
Group.
The IESG contact person is Harald Alvestrand.
Technical summary
This set of 3 documents replaces section 10 of RFC 2026, and provides
a much more detailed description of the considerations regarding
intellectual property that need to be taken into account when working
in the IETF.
Particular attention is paid to copyright issues and issues concerning
requirements for implementation, such as patent licensing.
The "Guidelines" document relates useful experience gathered when
working with IPR issues in the IETF.
Working Group summary
The working group was chartered to document existing IPR practice in
the IETF, and discuss whether updates were needed.
After a great deal of debate, a strong consensus emerged that the
fundamental IPR practice in the IETF should not be changed at this time.
The details of IPR practice were gone over in minute detail, and the
documents are believed to represent WG consensus on the practice that
the IETF should follow at present.
Protocol Quality
The documents were reviewed for the IESG by Harald Alvestrand.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 8 of 9
o draft-ietf-imapext-condstore-04.txt
IMAP Extension for Conditional STORE operation (Proposed Standard)
Note: On IESG agenda 30-Oct-2003
Token: Ned Freed
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-imapext-condstore-04.txt to Proposed Standard
--------
Evaluation for draft-ietf-imapext-condstore-04.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=10164&rfc_flag=0
Last Call to expire on: 2003-10-17
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 [ ] [ ] [ ] [ ]
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-imapext@imc.org>
Subject: Protocol Action: 'IMAP Extension for Conditional STORE
operation' to Proposed Standard
The IESG has approved following document:
- 'IMAP Extension for Conditional STORE operation '
<draft-ietf-imapext-condstore-04.txt> as a Proposed Standard
This document is the product of the Internet Message Access Protocol
Extension Working Group.
The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox. Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can
change
message state (e.g., message flags or annotations) at any time. An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism
for
message state information that can detect and resolve conflicts
between
multiple writing mail clients.
Working Group Summary
This document is a product of the imapext working group.
Protocol Quality
Ned Freed reviewed the specification for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 9 of 9
o Three-document ballot:
- draft-ietf-geopriv-dhcp-lci-option-02.txt
Dynamic Host Configuration Protocol Option for Location Configuration
Information for GEOPRIV (Proposed Standard)
- draft-ietf-geopriv-reqs-04.txt
Geopriv requirements (Informational)
- draft-ietf-geopriv-threat-analysis-01.txt
Threat Analysis of the geopriv Protocol (Informational)
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-ietf-geopriv-reqs-04.txt to Informational RFC,
draft-ietf-geopriv-threat-analysis-01.txt to Informational RFC,
draft-ietf-geopriv-dhcp-lci-option-02.txt to Proposed Standard
--------
Evaluation for draft-ietf-geopriv-reqs-04.txt,
draft-ietf-geopriv-threat-analysis-01.txt,
draft-ietf-geopriv-dhcp-lci-option-02.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=10284&rfc_flag=0
Last Call to expire on: 2003-10-28
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 [ ] [ ] [ ] [ ]
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>, <geopriv@ietf.org>
Subject: Protocol Action: 'Dynamic Host Configuration Protocol Option
for Location Configuration Information for GEOPRIV' to Proposed
Standard
The IESG has approved following document:
- 'Dynamic Host Configuration Protocol Option for Location Configuration
Information for GEOPRIV '
<draft-ietf-geopriv-dhcp-lci-option-02.txt> as a Proposed Standard
This document is the product of the Geographic Location/Privacy Working
Group.
The IESG contact persons are Ted Hardie and Ned Freed.
Technical Summary
This document specifies a Dynamic Host Configuration Protocol
Option for the geographic location of the client, to be provided by
the server. The goal of this option is to enable a wired Ethernet host
to provide its location (to an emergency responder, as one example).
Wireless hosts can utilize this option to gain knowledge of the
location of the radio access point used during host configuration,
but will need other mechanisms, such as GPS, to gain full knowledge
of their locations.
Working Group Summary
There was significant discussion within the working group about how
this work related to the privacy mechanisms proposed by geopriv's
requirements document.
This discussion eventually yielded consensus that this work was
inherently about populating a location object using dhcp, rather
than passing a location object with a using protocol. Once this
consensus was reached, working group discussion on the details
of the protocol and how it fit into the geopriv framework were
without significant dissent.
Protocol Quality
This document was reviewed for the IESG by Ted Hardie
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 1
o draft-ietf-msec-mikey-07.txt
MIKEY: Multimedia Internet KEYing (Proposed Standard)
Token: Russ Housley
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-msec-mikey-07.txt to Proposed Standard
--------
Evaluation for draft-ietf-msec-mikey-07.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7881&rfc_flag=0
Last Call to expire on: 2003-07-31
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Discuss:
4.1.3 says "let n = inkey_len / 512, rounded up to the nearest integer".
Is it rounded up, or to the nearest integer? If the division yields an
integral result, is it bumped by 1? The same comment applies to m.
Explain what relevance 512 has to SHA1, which externally takes messages
of any size. Are you referring to SHA1 internals? What should be used
for hash functions that don't have SHA1's internal 512-bit structure?
I suggest that you require than any new PRF be defined by its own RFC,
rather than trying to give guidance here.
4.2.2: what parameters corresponding to 512 and 160 should be used for
SHA-256, -384, or -512?
4.2.9: what process (per rfc 2434) is needed for new parameter
registration? How does this relate to Section 10?
5.4 suggests dropping messages from attacking peers. Of course, until
the message is authenticated you don't know whom it's from, which still
leaves the door open to a CPU DoS attack.
5.5: what is done to avoid congestion?
6.11 Cite RFC 1750? (Also cite it when discussing DH exponents.)
Ned Freed:
Comment:
Nits:
No copyright boilerplate
IANA considerations seem a bit incomplete - are the rules IANA needs to
follow fully specified here?
Ted Hardie:
Discuss:
This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.
Essentially, I'm concerned about section 5.4, which describes the replay
protection mechanisms. The language in the draft is a bit hard to parse
in places, and there seem to be some assumptions
that we may not be able to meet. In particular, it cites as an assumption:
"* If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol is used."
Is there a solution available for this? NTP v3 is cited in the references (not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't seem to be done.
The Security Considerations Section (9.3) does discuss this briefly, but basically points back
to 5.4 and hints that practical experience with other protocols indicates that manual configuration
may be okay.
This language also seemed strange:
In a client-server scenario, servers may be the entities that will
have the highest workload. It is therefore RECOMMENDED that the
servers are the Initiators of MIKEY. This will result in that the
servers will not need to manage any significant replay cache as they
will refuse all incoming messages that are not a response to an
already (by the server) sent message.
as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol. In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large. This wasn't entirely clear, though,
and some tightened language might help.
In general, an editing pass through this section by a native speaker might
be a good idea.
Bert Wijnen:
Comment:
NITS:
- citation in abstract not allowed
- page 32: figure has "Encr data len" while legend has "Encr len"
- missing IPR statement
- $ /bin/checkpage.awk <drafts/draft-ietf-msec-mikey-07.txt
Bad chars at 2230
Bad chars at 2568
Bad chars at 2602
Bad chars at 3262
Bad chars at 3298
-: 5 lines containing non-US-ASCII characters
- RFC2119 should probably be added to normative references and
be cited in ect 1.2
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <msec@securemulticast.org>
Subject: Protocol Action: 'MIKEY: Multimedia Internet KEYing' to
Proposed Standard
The IESG has approved following document:
- 'MIKEY: Multimedia Internet KEYing '
<draft-ietf-msec-mikey-07.txt> as a Proposed Standard
This document is the product of the Multicast Security Working Group.
The IESG contact persons are Russ Housley and Steve Bellovin.
Technical Summary
Security protocols for real-time multimedia applications have started
to appear, bringing forward the need for a key management solution to
support these security protocols. This document describes a key
management scheme that can be used with real-time applications, for
both peer-to-peer communication and group communication. The document
also shows how MIKEY might work with protocols such as SIP and RTSP.
In particular, it describes how MIKEY can provide keying material for
use with the Secure Real-time Transport Protocol.
Working Group Summary
The MSEC Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 3
o draft-ietf-sigtran-signalling-over-sctp-applic-09.txt
Telephony Signalling Transport over SCTP applicability statement
(Informational)
Token: Jon Peterson
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 3
o draft-ietf-tsvwg-dsack-use-02.txt
Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious
Retransmissions (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-dsack-use-02.txt to Experimental RFC
--------
Evaluation for draft-ietf-tsvwg-dsack-use-02.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=10544&rfc_flag=0
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 [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
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:
======================
Ned Freed:
Comment:
No copyright or IPR boilerplate
^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: 'Using TCP DSACKs and SCTP Duplicate
TSNs to Detect Spurious Retransmissions' to Experimental RFC
The IESG has approved the Internet-Draft 'Using TCP DSACKs and SCTP
Duplicate TSNs to Detect Spurious Retransmissions'
<draft-ietf-tsvwg-dsack-use-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
TCP and SCTP provide notification of duplicate segment receipt through
DSACK and Duplicate TSN notification, respectively. This document shows
conservative methods of using this information to identify unnecessary
retransmissions for various applications. This document does not, however
outline what a TCP or SCTP sender should do after a spurious
retransmission is detected. It is hoped that future work building on the
detection of spurious transmissions will make TCP and SCTP more robust
to reordererd packets.
Working Group Summary
The TSVWG supports this protocol going forward, and is investigating
several proposals that rely on the detection of spurious retransmissions
which might benefit from this work.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin and Jon Peterson.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 3 of 3
o draft-ietf-rpsec-routing-threats-03.txt
Generic Threats to Routing Protocols (Informational)
Token: Alex Zinin
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 3
o draft-ietf-manet-tbrpf-11.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Alex Zinin
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 3
o draft-ietf-dhc-unused-optioncodes-07.txt
Unused DHCP Option Codes (Informational)
Note: Already approved by IESG, pulled back to remove option codes that
were actually in use. Back again for re-approval.
Token: Margaret Wasserman
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 3 of 3
o draft-ietf-crisp-requirements-06.txt
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
Note: Revised based on comments from first run at ballot
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-crisp-requirements -
Cross Registry Internet Service Protocol (CRISP) Requirements
--------
DISCUSSES AND COMMENTS:
======================
>From: hardie@qualcomm.com
>To: Steve Bellovin <smb@research.att.com>, iesg-secretary@ietf.org
>Subject: Re: evaluation: draft-ietf-crisp-requirements
Steve,
This is meant to be covered by this text:
3.1.4.1 Protocol Requirement
The protocol MUST NOT prohibit an operator from granularly assigning
multiple types of access to data according to the policies of the
operator. The protocol MUST provide an authentication mechanism and
MUST NOT prohibit an operator from granting types of access based on
authentication.
The protocol MUST provide an anonymous access mechanism that may be
turned on or off based on the policy of an operator.
Since these protocol requirements apply only to distributing
information, there is no place in it for the client to express
privacy preferences about the data (indeed, that's likely to be covered
by EPP).
regards,
Ted
>From: hardie@qualcomm.com
>To: mankin@psg.com, iesg@ietf.org
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt
At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>Overall this is a very well-written spec. One transport issue and two
>questions about scope - perfectly reasonable answers are out of scope,
>or already discussed and dismissed.
>
>1.
>
>The protocol MUST
> define one or more transport mechanisms for mandatory implementation.
> ^congestion-aware or overload-aware
>
>I realize that the transport choice could be UDP, but in that case,
>congestion-aware would mean UDP without aggressive retransmission.
>And in the case that that "transport" may be used here to mean a
>higher layer protocol such as mail or http, then the term
>overload-aware applies.
Speaking as one of the chairs, this change should be uncontroversial,
so an RFC editor note could cover it.
>2.
>
>Is it out of scope for there to be a requirement in the protocol for
>the registry to be able to authenticate itself to the client, because
>in some cases there could be falsified registries?
3.1.9 covers the protocol and service descriptions here; the wg
did discuss the various use case scenarios. The result was:
must be able to authenticate itself, but does not require that
for operation of a CRISP server.
If you have further issues, I'd be happy to discuss it with you,
or set up a call with the author.
>3.
>
>Is it out of scope for there to be a requirement on the protocol for
>some support for authentication of the contact information?
This would have to be covered by the requirements on the protocol
that populates the data. A distribution protocol is pretty much too late
in the game to put in requirements for authenticating the contact
information that _has_been_populated.
>To: hardie@qualcomm.com
>Subject: Re: evaluation: draft-ietf-crisp-requirements
>From: "Steven M. Bellovin" <smb@research.att.com>
In message <p06001201bb20c6217d42@[129.46.227.161]>, hardie@qualcomm.com writes
:
>Steve,
> This is meant to be covered by this text:
>
>3.1.4.1 Protocol Requirement
>
> The protocol MUST NOT prohibit an operator from granularly assigning
> multiple types of access to data according to the policies of the
> operator. The protocol MUST provide an authentication mechanism and
> MUST NOT prohibit an operator from granting types of access based on
> authentication.
>
> The protocol MUST provide an anonymous access mechanism that may be
> turned on or off based on the policy of an operator.
>
> Since these protocol requirements apply only to distributing
>information, there is no place in it for the client to express
>privacy preferences about the data (indeed, that's likely to be covered
>by EPP).
Not very explicit, and authentication isn't the same as authorization.
But what attracted my attention was 3.1.3, which talks about tagging
data. What I'm asking about is language about privacy-related tags, or
use of tags for privacy purposes. That was the big hangup with the EPP
document, as I recall.
At 9:25 AM -0400 6/26/03, Steve Bellovin wrote:
>I think there should be some requirement that data be taggable to meet
>privacy requirements. We just went through this a few months ago.
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com (2nd edition of "Firewalls" book)
>From: Leslie Daigle <leslie@thinkingcat.com>
>To: hardie@qualcomm.com
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt
Speaking as a WG participant:
hardie@qualcomm.com wrote:
> At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>
>> Overall this is a very well-written spec. One transport issue and two
>> questions about scope - perfectly reasonable answers are out of scope,
>> or already discussed and dismissed.
>>
>> 1.
>>
>> The protocol MUST
>> define one or more transport mechanisms for mandatory implementation.
>> ^congestion-aware or overload-aware
>>
>> I realize that the transport choice could be UDP, but in that case,
>> congestion-aware would mean UDP without aggressive retransmission.
>> And in the case that that "transport" may be used here to mean a
>> higher layer protocol such as mail or http, then the term
>> overload-aware applies.
>
>
>
> Speaking as one of the chairs, this change should be uncontroversial,
> so an RFC editor note could cover it.
I believe the intention of the requirement is to be an
*application* transport. I.e., beep, http, etc.
Leslie.
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>,
<ietf-not43@lists.verisignlabs.com>
Subject: Document Action: Cross Registry Internet Service Protocol (CRISP)
Requirements to an Informatinal RFC
------------------------
The IESG has approved the Internet-Draft 'Cross Registry Internet Service
Protocol (CRISP) Requirements' <draft-ietf-crisp-requirements-05.txt> as an
Informatinal RFC. This document is the product of the Cross Registry Information
Service Protocol Working Group.
The IESG contact persons are Ned Freed and Ted Hardie
3.2.1 New Item
NONE
3. Document Actions
3.2 Individual Submissions Via AD
3.2.2 Returning Item - 1 of 1
o draft-gill-gtsh-04.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental)
Token: Alex Zinin
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 1 of 2
o draft-dfncis-netnews-admin-sys-06.txt
Netnews Administration System (NAS) (Experimental)
Note: AD review comments not completely addressed but might as well get
feedback from the entire IESG at this point.
Token: Ned Freed
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 2 of 2
o draft-carroll-dynmobileip-cdma-01.txt
Dynamic Mobile IP Key Update for cdma2000(R) Networks (Informational)
Token: Thomas Narten
3.3.2 Returning Item
NONE
3.3.3 To be assigned
o draft-jseng-idn-admin-05.txt
Internationalized Domain Names Registration and Administration Guideline
for Chinese, Japanese and Korean (Informational)
4. Working Group Actions
4.1.1 Proposed for IETF Review
o Access Link Intermediaries Assisting Services (alias) - 1 of 1
Token: Jon
Access Link Intermediaries Assisting Services (alias)
-----------------------------------------------------
Last Modified: 2003-10-24
Current Status: Proposed Working Group
Chair(s):
Hui-Lan Lu <huilanlu@lucent.com>
Kevin Fall <kfall@eecs.berkeley.edu>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: alias@mailman.berkeley.intel-research.net
To Subscribe:
http://mailman.berkeley.intel-research.net/mailman/listinfo/alias
Archive: http://mailman.berkeley.intel-research.net/pipermail/alias/
Description of Working Group:
Several types of physical links increasingly used for Internet
connectivity today possess undesirable characteristics, such as high
loss, high delay, and low reliability. Dial-up telephone lines and radio
links in wireless networks (e.g., 3G, GPRS, GSM, IS-95, IEEE 802.11 and
satellite) are examples of such links, whose presence results in
degradation in performance of Internet protocols and services.
Transport intermediaries have been used to mitigate performance
degradation caused by problematic links (see RFC 3135). Such
intermediaries typically reside in nodes (e.g., base stations, or access
points) located at the ends of problematic links. Up to this point,
however, there has been no systematic investigation of the security
implications of the use of transport intermediaries, performance
enhancing or not, and of a common framework for secure transport
intermediary services. The ALIAS working group will fill this void by
first investigating the requirements for standard means for:
+ Transport intermediaries to signal to endpoints their existence and
information (e.g., knowledge of changing link conditions) pertaining to
their services or to usefully influencing the endpoint operation
+ Intermediaries and endpoints to communicate in a secure manner and to
establish security associations
If this investigation yields useful requirements that point towards a
feasible solution, the working group will then develop the common
framework and the standard means.
While conducting its work, the working group will take into
consideration the related work in other active working groups, including
pilc, ipsec, midcom, opes, nsis and send.
Goals and Milestones:
Jan 04 Survey of state-of-the-art to IESG as Informational
Jan 04 Characteristics of services to IESG as Informational
Mar 04 Requirements for intermediary services to IESG as Informational
Mar 04 Analysis of signaling information to IESG as Informational
Jun 04 Evaluate work; recharter or close WG
4. Working Group Actions
4.1.2 Proposed for Approval
o Credential and Provisioning (enroll) - 1 of 2
Token: Russ
Credential and Provisioning (enroll)
------------------------------------
Last Modified: 2003-10-8
Current Status: Proposed Working Group
Chair(s):
Eric Rescorla <ekr@rtfm.com>
Paul Hoffman <phoffman@imc.org>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Mailing list: ietf-enroll@mit.edu
To Subscribe: mailman@mit.edu
In Body or Subject: subscribe
Archive:
Description:
There are many cases where a service consumer needs to contact a
service provider to get credentials that the consumer can use when
accessing the service; part of this initial contact may involve
the consumer and the provider mutually validating the other's identity.
This working group will look at some of the cases where cryptography
is used to provide authentication.
When doing enrollment of a service consumer against a service provider,
three pieces of information need to be provided or created in order to
support authentication of the service consumer to the service provider
(and visa versa) and to allow for additional security services to be
provided any information exchanged. These pieces of data are:
1. An identifier, within a namespace controlled by the service
provider, for the service consumer.
2. Keying information to be used for identity confirmation.
3. A set of service consumer permissions. These permissions
describe to the provider the services that the consumer
wants to access, and they describe to the consumer what
services offered by the provider will be accessable.
Each of these data items could be created by either the consumer or
provider at any point during the enrollment process.
This group will create a model to be used in describing enrollment
procedures and create a document for a framework how this is to be done.
The group will then produce three documents profiling the use of the
framework for the following types of keying material:
1. A shared secret key.
2. A bare asymmetric key.
3. A bound asymmetric key (such as an X.509 certificate).
As part of the validation of the framework, the group will examine how
other real world enrollment procedures could be profiled. For example,
credit card information might be part of the input to the enrollment
process.
Goals and Milestones:
Nov 2003 First draft of model
Feb 2004 Last call on model document
Feb 2004 First draft of Framework document
Jun 2004 Last call on module document
May 2004 First draft of secret key profile
May 2004 First draft of bare asymmetric key profile
May 2004 First draft of bound asymmetric key profile
Oct 2004 Last call on secret key profile
Oct 2004 Last call on bare asymmetric key profile
Oct 2004 Last call on bound asymmetric key profile
4. Working Group Actions
4.1.2 Proposed for Approval
o IP over DVB (ipdvb) - 2 of 2
Token: Margaret
IP over DVB (ipdvb)
-------------------
Last Modified: 2003-10-13
Current Status: Proposed Working Group
IETF Area: Internet Area
Chair(s): Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Responsible Area Director: Margaret Wasserman
Mailing Lists:
General Discussion:ip-dvb@erg.abdn.ac.uk
To subscribe: subscribe ip-dvb at majordomo@erg.abdn.ac.uk
Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive/
Description of Working Group:
The MPEG-2 Transport Stream provides a transmission network that has become
widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T.
These, and related standards, define a set of commercially available
components that are increasingly being used to provide a general-purpose
packet transmission network. MPEG-2 Transport networks are being used to
build IP networks to supplement broadcast TV/audio services and also provide
one-way and two-way IP-only subnetworks.
There is a need to define an efficient standardised encapsulation for IPv4
and IPv6 datagrams, and to recommend procedures for supporting protocols.
Examples include dynamic address resolution, multicast group membership
reporting and possibly management information tables and MIBs. Documents
will be defined that describe protocols required to build a complete
IPv4/IPv6 unicast/multicast services, and the mappings required to perform
dynamic address resolution. The primary purpose of this working group is to
develop a set of Internet Drafts and where appropriate to progress these as
either Internet Informational RFCs or Standards track RFCs.
The current list of work items is:
1. Issue an Internet Draft specifying Requirements and Framework for
supporting IP services via MPEG-2 transmission networks. Such requirements
should consider the range of platforms currently (or anticipated to be) in
use. This draft will be submitted to the IESG for possible publication as
an Informational RFC.
2. The working group will investigate and design an efficient encapsulation
method for IPv4/IPv6, and advance this via the IESG to a standards-track
RFC. The design needs to consider the need for MAC addresses, the potential
need for synchronisation between streams, support for IPv6 and multicast
services, and support for multiple gateways (feeds).
3. The working group will consider the options for unicast and multicast
address resolution. A working group Internet Draft will define a framework
and recommend appropriate address resolution mechanisms for IPv4 and IPv6
using both the existing Multi-Protocol Encapsulation and any new
encapsulation developed by the working group. Consideration will be paid to
existing standards, and the cases for IPv6 and IPv4 will be described. This
document will be submitted to the IESG for publication as an Informational
RFC.
4. A working group Internet Draft will be written to recommend a set of
dynamic address resolution procedures for IPv6. It will describe the
protocol and syntax of the information exchanged. This work may be based on
an extension to the Neighbor Discovery (ND) protocol to support MPEG-2
transmission, and include specific optimisations for broadcast networks.
This document will be submitted to the IESG for publication as a
standards-track RFC.
5. If there is a need for further supporting protocols, it will consider a
possible recharter under the guidance of the IESG. Examples in this area
include, the negotiation/association of IP QoS with MPEG-2 transport
streams, address resolution for IPv4, and the need for SNMP MIBs.
Goals and Milestones:
Nov 2003 Issue a working group Architecture ID
Nov 2003 Issue a working group Encapsulation ID
Mar 2004 Review Encapsulation ID
Mar 2004 Review Architecture ID
Mar 2004 Issue a working group Address Resolution (AR) Framework ID
Jun 2004 Submit Architecture ID to IESG for consideration as a INFO RFC
Jun 2004 Submit Encapsulation ID to IESG for consideration as a STD RFC
Jun 2004 Review Address Resolution Framework ID
Jun 2004 Issue a working group AR Protocol ID
Sep 2004 Review AR Protocol ID
Dec 2005 Submit Address Resolution Framework ID to IESG for
consideration as an INFO RFC.
Dec 2005 Submit the AR Protocol ID to IESG for consideration as
an INFO RFC.
Dec 2005 Progress STD RFCs along standards track process.
Dec 2005 Possible recharter to investigate MIBs,
and other protocol components (if required).
4. Working Group Actions
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
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