[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FINAL 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 16:12:59 EDT, October 29, 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 4
Note: Implementation report available at.
http://www.ietf.org/IESG/Implementations/rfc-2338-implementation.txt
Token: Alex Zinin
o Three-document ballot: - 2 of 4
- 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) - 3 of
4
Note: On IESG agenda 30-Oct-2003
Token: Ned Freed
o draft-ietf-geopriv-dhcp-lci-option-02.txt
Dynamic Host Configuration Protocol Option for Location Configuration
Information for GEOPRIV (Proposed Standard) - 4 of 4
Token: Ted Hardie
2.1.2 Returning Item
o draft-ietf-sigtran-v5ua-04.txt
V5.2-User Adaption Layer (V5UA) (Proposed Standard) - 1 of 7
Token: Jon Peterson
o Four-document ballot: - 2 of 7
- 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) - 3 of 7
Note: IESGácommentsáreturnedátoáWGáatáAltantaámeeting
Token: Ted Hardie
o draft-ietf-msec-mikey-07.txt
MIKEY: Multimedia Internet KEYing (Proposed Standard) - 4 of 7
Token: Russ Housley
o draft-dasilva-l2tp-relaysvc-07.txt
L2TP Active Discovery Relay for PPPoE (Proposed Standard) - 5 of 7
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 draft-ietf-ipv6-flow-label-08.txt
IPv6 Flow Label Specification (Proposed Standard) - 6 of 7
Token: Thomas Narten
o draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
KEY RR Secure Entry Point Flag (Proposed Standard) - 7 of 7
Note: -11 is out, should clear outstanding discusses.
Token: Thomas Narten
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 5
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 5
Token: Jon Peterson
o draft-ietf-rpsec-routing-threats-03.txt
Generic Threats to Routing Protocols (Informational) - 3 of 5
Token: Alex Zinin
o draft-ietf-geopriv-threat-analysis-01.txt
Threat Analysis of the geopriv Protocol (Informational) - 4 of 5
Token: Ted Hardie
o draft-ietf-geopriv-reqs-04.txt
Geopriv requirements (Informational) - 5 of 5
Token: Ted Hardie
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
Note: Not ready for final approval, but would like to get security AD
opinions on document and flush out remaining issues.
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
7.1 Deadlines for New and Returning Items on the Telechat Timetable and Minimum Review Time for Internal Review of New and Rechartered Working Groups. (Harald Alvestrand)
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the October 30, 2003 IESG Teleconference
This package was generated at 16:12:51 EDT, October 29, 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 4
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 [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin:
Comment:
The document speaks of a "Digital Equipment Corporation" protocol. Digital
doesn't exist any more; the text should be reworded.
Ned Freed:
Comment:
Interop report seems a bit weak. In particular, I see nothing listed beyond
go/no-go testing. It seems to me that some indication of the actual
options in the protocol that were tested might be in order.
Ted Hardie:
Comment:
Meta-comment:
(Bob wrote and gave some background on the version numbers,
pointing out that 2328 was also version 2, and that the early
versions would not have been interoperable with this in any
useful way. Leaving the comment in for the record, but not
having this in the draft makes sense to me now)
The draft does a good job of motivating VRRP, but it doesn't seem to tackle
the question of the transition to this version. Since this version specifie
that any other version number than 2 means the packet should be tossed,
clearly there is no aim for interoperability among versions (making historic
2328 being another clue here). The only text about the previous version
I saw, though, was in describing why the authentication mechanisms were
tossed out, and that didn't seem to motivate it.
As a personal comment, I think some discussion of the need for a transition
(and motivation for why no backwards compatibility is required) would be
valuable. It would not, obviously, affect protocol processing, though, so
this is just a comment.
Nits:
1.1
"currnet RFC Editor policies"--> current RFC Editor policies.
2.3
"that is more preferential than the current Master." seems clumsy;
would "that is preferred over the current Master." be better?
5.3.3
I think it would be valuable to make clear here that VRID is
a configured item. It is mentioned later in section 6.1, but a
forward pointer or repeat of the text might be useful here. (Not
a protocol issue, obviously, just helpful to the new reader)
^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 4
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 [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Discuss:
draft-ietf-ipr-submission-rights-08:
In section 5.2, the special rules for MIB or PIB modules are
discussed. ASN.1 modules should be explicitly listed too;
however, ASN.1 modules do not require any handling by IANA. In
this way, ASN.1 modules are different than MIB and PIB modules.
Also, some documents include programs or scripts. These are
intended to be copied from the RFC.
In section 5.6, the document calls for the inclusion of a URL
to obtain full for full legal notices. I see this as quite
different than referencing a section in an RFC since the content
of the referenced web page can be changed after publication.
draft-ietf-ipr-technology-rights-12:
In section 6.3, the URL does not point to anything:
http://www.ietf.org/ipr-instructions.
Comment:
draft-ietf-ipr-submission-rights-08:
In section 1, the definition of "Reasonably and personally known"
starts with a description, but then moves into a "requirement."
Requirements should not be embedded in definitions.
draft-ietf-ipr-technology-rights-12:
In section 1, the definition of "Reasonably and personally known"
starts with a description, but then moves into a "requirement."
Requirements should not be embedded in definitions.
draft-ietf-ipr-wg-guidelines-05:
Section 4.3 says: "In the mid-90s, the basic principles of public
key infrastructure had been patented for years." This is not
quite right. All digital signature algorithms were covered by
patents, and a digital signature algorithm is needed to implement
PKI. In sections 4.1 and 4.2, the patented technology is named.
Why not name RSA here?
^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 - 3 of 4
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 [ ] [ ] [ 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:
======================
Ted Hardie:
Discuss:
After talking to the working group chair, I was tempted to defer this doc
and follow up with the author, but I've decided it probably needs public
discussion.
Section 3.2 says:
Note: A client trying to make an atomic change to the state of a particular
metadata item (or a set of metadata items) should be prepared
to deal with the case when the server returns MODIFIED response code
if the state of the metadata item being watched hasn't changed (but
the state of some other metadata item has). This is necessary, because
some servers don't store separate mod-sequences for different metadata
items. However, a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
even when the server stores a single mod-sequence per message.
Upon the receipt of MODIFIED response code the client SHOULD try to
figure out if the required metadata items have indeed changed. If they
haven't the client SHOULD retry the command.
First, this is a classic case of IMAP being so server focused as to make a
client's life hell. In order to avoid keeping per-metadatum state, the protocol
now forces client round trips to check that what it wants to change isn't the
bit that has already been changed. I'm not sure that I believe "SHOULD try
to figure out" is a realistic piece of protocol specification, and seeing it in
a document about conditional storage makes my head hurt.
I also think the sentence "a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
even when the server stores a single mod-sequence per message" doesn't
make any sense. What is the server supposed to do here? Not send
a modified response even though it knows something changed and doesn't
know what, based on some extra-protocol knowledge? This doesn't seem
like a win for interoperability. If it doesn't know what changed (because it is using a
single mod-sequence) it's not spurious, just lame.
I believe we normally have documents that update other RFCs mention that in
the abstract, and since this does, it probably ought to.
^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 - 4 of 4
o draft-ietf-geopriv-dhcp-lci-option-02.txt
Dynamic Host Configuration Protocol Option for Location Configuration
Information for GEOPRIV (Proposed Standard)
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-dhcp-lci-option-02.txt to Proposed
Standard
--------
Evaluation for 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 [ ] [ 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:
======================
Ned Freed:
Comment:
Nits:
No IPR boilerplate in any of the documents
References not split into normative and informative groups
in dhcp-lci-option
I'll leave it to the security folks to register any actual discuss
votes here, but I'm concerned about the security considerations given
in draft-ietf-geopriv-dhcp-lci-option-02.txt aren't adequate. In particular
while the possibility of eavesdropping on LCI information returned to client
is mentioned, there's no reference given to the discussion of the possible
threats such exposure causes given in
draft-ietf-geopriv-threat-analysis-01.txt.
The security considerations section also doesn't discuss the fact that it
provides information about the "last plug" but nothing beyond that. I often
see wireless equipment attached to those plugs, which can make an LCI that
says
"she's at her desk" pretty much a lie. For example, I sometimes use my lapto
in my dentist's office, which as it happens is one floor above me and
manages
to be able to see the wireless base station next to my desk.
^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 7
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 ] [ ]
Randy Bush [ ] [ ] [ ] [ X ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ 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
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, 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.2 Returning Item - 2 of 7
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 ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ XX] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ 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.2 Returning Item - 3 of 7
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 ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ X ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ XX] [ X ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ ] [ X ] [ ]
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:
------------------------------------
Russ Housley (Comment):
NOTE: Russ has provided comments along with his position of "Abstain"
This specification is ambitious and daunting in its generality; it seeks
to define and manage an abstract meta-model of reference monitor
behavior. What's primarily being specified here isn't a protocol for
performing access control (mediating requests for data objects), but rather
a management protocol for ACLs (a control interface to adjust the metadata
that enables those requests to be mediated subsequently). As such, "WebDAV
Authorization Management Model and Protocol" might be a more descriptive title.
WebDAV and this ancillary specification use some novel concepts (new
HTTP methods, XML multistatus elements encapsulating HTTP exceptions along
with other data) which integrate with HTTP at a lower sublayer than most
current web service work.
There is an unusual interoperability goal being addressed here. The
idea is to allow a single client using this protocol to manage ACLs that
may exist in different servers, where those servers may apply semantics and
group privileges in different ways. A lot of the features are driven by UI
design concerns, which are important to the intended application even
though often considered to be a local matter, outside the scope of an IETF
protocol perspective.
The indirection and nesting of aggregate privileges adds considerable
complexity. It is not clear that the approach is sufficient to enable a
user to administer ACLs in a comprehensible and security-consistent way on
servers that apply different groupings.
Some specific points:
* The introduction refers to client software as one of the
principal types; how are software modules to be authenticated
in a distributed fashion?
* The discussion of inherited ACLs in section 5.6 could benefit
from some more explicit treatment of denial entries and of
cases when different ACLs contain ACEs that have matches on
different subsets of the overall set of privileges.
* In section 8.1.1, implementations should give precedence to
returning a 403 (Forbidden) rather than a 409 (Conflict);
otherwise, an attacker lacking the authorization to read ACEs
belonging to other principals could infer their values by
observing the results to attempts to change those ACEs.
* In the Security Considerations, the point that the
protocol-accessible facility for enumerating principals could
easily compromise privacy of stored identities en masse, and
that implementors and deployers should consider carefully
what's made readable to accessors who have not been
authenticated as belonging to a constrained set of recognized
principals.
-----------------------------------------------------------------
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.2 Returning Item - 4 of 7
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. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 5 of 7
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 ] [ ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
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.2 Returning Item - 6 of 7
o draft-ietf-ipv6-flow-label-08.txt
IPv6 Flow Label Specification (Proposed Standard)
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ipv6-flow-label -
IPv6 Flow Label Specification
--------
Last Call to expire on: 2003-07-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ XX] [ X ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ X ] [ ]
Margaret Wasserman [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ X ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ted Hardie (Discuss - August 7, 2003 teleconference Ted
reclassified this to a COMMENT):
This is very mild, and I could be talked out of it on the call,
but I do find it odd that the key motivational text is in
section 5.1, in the security requirements. This is the
text I mean:
The goal of the Flow Label is to allow different levels of service to
be provided for traffic streams on a common network infrastructure. A
variety of techniques may be used to achieve this, but the end result
will be that some packets receive different (e.g., better or worse)
service than others. The mapping of network traffic to the flow-
specific treatment is triggered by the IP addresses and Flow Label
value of the IPv6 header,
This looks to me like it belongs in the introduction, so that the reader
can understand the impetus to the work.
As a side note, I have some concerns about whether any protocol can
meet the explicit requirements in Section 4 and the implicit requirement
of "do some good" without running into the maw of some well-known
dragons, but the statement of requirements looks fair to me.
Alex Zinin (Discuss):
This document talks about per-flow state establishment and
processing on interim nodes. This is essentially IntServ
and it doesn't scale well.
More comments from rtg-dir (Ross) below.
General Comments
It seems to me that the flow label has a purpose, and two possible
uses. To me the document seems to be not totally clear or perhaps
even wrong regarding which of the uses is the main one.
The purpose is to identify flows. For example, this allows the flow to
be identified using only fields which are in fixed positions in the
IPv6 Header. This purpose seems to me to be well defined in the
document.
Now that you have an indicator regarding what flow a particular packet
belongs to, what use would you have for this information?
One possible use is for hashing packets, for example to spread traffic
across equal cost multi-paths without re-ordering packets from any one
flow. This seems like a pretty straightforward and sensible use, which
requires close to zero change to the Internet architecture, and which
is briefly mentioned in the document.
The other possible use is for an explicit flow set up procedure.
However, since the flow are per-{source-address; destination-address;
flow field} triplet, it would seem that this won't scale much better
than the current int-serve specification. Thus it is not clear whether
this will end up being useful in practice. At best I would call this
experimental.
In some places in the document it appears that the flow field is for
the purpose of identifying flows, and that either of the two uses
might be sensible reasons that you might want to identify flows. In
other places in the document it looks like the second purpose (which
to me seems the more speculative) is the reason for the flow field.
I think that it would make sense to clearly separate these.
More specific comments
>> Section 1:
First three paragraphs do a good job of defining the purpose of the
flow ID (to allow efficient flow classification based only on fields in
the fixed part of the IPv6 header).
Fourth paragraph, first sentence:
The minimum level of IPv6 flow support consists
of labeling the flows.
In a sense this is reasonable, but I am not sure precisely what it
means.
Does this mean:
In order to be an IPv6 conformant node, IPv6 source
nodes MUST be able to label outgoing flows.
or does this mean:
In order to claim conformance to the IPv6 flow
label specification, IPv6 source nodes MUST support
labeling outgoing flows.
Or does this mean something else?
>> Sections 2 and 3.
This seems reasonable, and again defines the purpose of the
flow label in a reasonable way, as well as defining some very
reasonable requirements, for example specifying how a source
should set the flow value.
>> Proposed New Section Between section 3 and 4:
It seems to me that the most obviously worthwhile of the
potential uses of the flow label field is to allow routers to split
traffic on multiple paths (for example, for load sharing and traffic
engineering purposes), without having to look past the IPv6
header.
One example of where this might be very useful is in the case
of encapsulation, for example <anything> over IPsec over IPv6
or <anything> over GRE over IPv6 encapsulations. In this case
there might be a potentially very large number of high layer flows
which will be encapsulated with the same IPv6 source and
destination addresses in the outer IPv6 header. If you can hash
only on the outer IPv6 addresses, then you could get a lot of
traffic which is forced to take the same path. If you allow a finer
grain flow label to be placed in the flow label field, then you can
get a much more even distribution of traffic across, for example,
equal cost multi-paths.
I think that it is worth having a section on this possibility. I don't
think that this requires all that much text.
There is one question which I have, which could be cleared up
in such a section: Specifically, the second sentence of section
2 states:
A Flow Label of zero is used to indicate packets
not part of any flow.
Suppose that I am an IPv6 router which is hashing on source
address, destination address, and flow label, and I am using
the hash to split traffic among several paths.
If I see a packet with a flow label of zero, which of the following do
I assume:
- the node does not implement any flow labelling ability, and
therefore I must hash only on source and destination
address.
- the node does implement flow labelling, and is telling me
that the packet is not part of any flow, and can therefore
be
forwarded on any path without regard for re-ordering.
If we assume the latter, then implementation of the flow labelling
capability must be supported by all IPv6 source nodes (at least
to the point of sticking a non-zero value in the flow field), since
otherwise their packets might be re-ordered by nodes which
assume that their packets are not part of any flow.
I would suggest using zero to indicate that flow labelling is not
supported (and thus routers better keep the packets in order
based only on source and destination addresses). If we also
want to indicate that some packets are not part of a flow, we
might give them a random value, or a different special value.
>> Section 4:
The flow state establishment requirements in section 4 seem to be
very much incomplete. If there were a complete set of flow state
establishment requirements, then I think that the requirements
specified in this section are reasonable ones, and would be
included in the set. However, the two requirements specified in
section 4 seem to be such a small subset of the complete set of
requirements that I don't see why it is worth listing them at all. I
think that it would be cleaner just to say that methods and
requirements for explicit flow establishment are outside of the
scope of this document.
Naturally if section 4 were removed, then the last phrase of the
first paragraph of the abstract would also need to be removed
(page 1, phrase "and the requirements for flow state establishment
methods"). Similarly the second to last paragraph of section 1
would need to be abbreviated.
>>Section 5:
First paragraph, last sentence:
Even if the flow label were encrypted, its presence
as a constant value in a fixed position might assist
traffic analysis and cryptoanalysis.
The flow label is supposed to be unstructured -- in the sense that if
I am not the source node, then I don't know anything about how the
source set the label, except that a different value means a different
flow. As such, I don't understand what encryption would do to change
the interpretation of a flow label. If two labels were encrypted to
the same exact value, then it would seem clear that they can't be
un-encrypted back to different values. If two flow labels were
encrypted to different values, then as a node in the middle observing
the packets going by I don't detect any difference.
Section 5.1, second paragraph (top of page 5), first sentence:
Note that there is no guarantee that flow labels sent by a node are
not set in any manner that the node wants to, such as reusing flow
labels, against the recommendations in this document.
This seems to be a rather awkward sentence, and should probably
be re-written.
Additional Topic: Somewhere in the security section (probably in a new
subsection at the end) it might be worth mentioning that in those
locations where a firewall or filtering router is employed which looks
past the IP header to higher level headers, the flow label does
nothing to eliminate the need to continue to look at the higher
headers.
Ross
Jon Peterson (Discuss):
Along the same lines as the comments from the Routing Area Directorate, but
with a few different issues in the text:
I believe there are two purposes of flows given in the document - first, a
flow as a way of flagging a stream of related traffic coming from a node
(following Section 3, first paragraph), and second, a flow as something that
would be prioritized by routers (following Section 5.1, first paragraph).
There are a couple of ways in which the two seem to get mixed up.
1) In the last paragraph of 5.1, it suggests that a policy decision in the
source node should be made to determine whether or not an application or
transport protocol is allowed to use a non-zero Flow Label. But reading, for
example, the first paragraph of Section 3, the document suggests that "each
unrelated transport connection and application data stream" on a node should
be assigned to a new flow (which presumably means that they would have a
non-zero Flow Label).
2) Section 3, second paragraph, says:
To enable applications and transport protocols to define what packets
constitute a flow, the source node MUST provide means for the
applications and transport protocols to specify the Flow Label values
to be used with their flows.
Given that there is some sort of policy decision associated with the
assignment of flows, I don't think applications and transport protocols
could really get to 'specify' these Flow Labels. It also isn't clear how
collisions would be managed (Section 3, third paragraph) if it were possible
for any multiple applications on the same host to specify Flow Label values.
^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@isi.edu>, <ipng@sunroof.eng.sun.com>
Subject: Protocol Action: 'IPv6 Flow Label Specification' to
Proposed Standard
The IESG has approved the Internet-Draft 'IPv6 Flow Label Specification'
<draft-ietf-ipv6-flow-label-07.txt> as a Proposed Standard. This document is
the product of the IP Version 6 Working Group Working Group. The IESG
contact persons are Thomas Narten and Margaret Wasserman.
Technical Summary
The details of the IPv6 Flow Label are not defined in detail in the
base IPv6 documents (i.e., RFC 2460). Although an appendix in 2460
provides some background and a possible usage, they are not considered
part of the specification itself. This document specifies the IPv6
Flow Label field, the requirements for IPv6 source nodes labeling
flows, the requirements for IPv6 nodes forwarding labeled packets, and
the requirements for flow state establishment methods.
Working Group Summary
There was consensus in the WG for the current definitions. Indeed,
there has been a desire for sometime to define the Flow Label, as its
considered a part of IPv6, and its lack of a clear definition
contributed to an appearance of lack of completeness.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 7 of 7
o draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
KEY RR Secure Entry Point Flag (Proposed Standard)
Note: -11 is out, should clear outstanding discusses.
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-keyrr-key-signing-flag-11.txt to
Proposed Standard
--------
Evaluation for draft-ietf-dnsext-keyrr-key-signing-flag-11.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9289&rfc_flag=0
Last Call to expire on: 2003-09-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ XX] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
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:
Why is this a standard? What changes in over-the-wire behavior as a
result of this bit being set?
Ted Hardie:
Comment:
"Once this label was applied, it
had the side effect of removing the temptation to have a KSK flag bit
and a ZSK flag bit, setting on needing just one bit.)" is a little
clumsy;
how about: "Once this label was applied, it had the side effect of removing
the temptation to have both a KSK flag bit and a ZSK flag bit"
Russ Housley:
Discuss:
The document fails to distinguish public keys and private keys. This is prevalent throughout the document. For example:
One key is used to sign just the zone's KEY
resource record (RR) set and is the key
referenced by a DS RR at the parent or
configured statically in a resolver.
The first half of the sentence is referring to the private key that is used to sign the RR set, and the second have of the sentence is referring to the public key that is used to validate the signature on the RR set. People who are very familiar with public key cryptography may not get confused, but I believe that many implementors will be mislead.
It is interesting to note that the 'KSK' and 'ZSK' labels are being applied to the public keys, which are used for signature validation, not the private keys, which are used for signing.
Comment:
In section 2, the document says: "The SEP bit (TBD) ..." The bit position
of the SEP flag bit has been set, so I do not understand the "TBD."
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <namedroppers@ops.ietf.org>
Subject: Protocol Action: 'KEY RR Secure Entry Point Flag' to
Proposed Standard
The IESG has approved following document:
- 'KEY RR Secure Entry Point Flag '
<draft-ietf-dnsext-keyrr-key-signing-flag-09.txt> as a Proposed Standard
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Thomas Narten and Margaret Wasserman.
The Delegation Signer (DS) resource record introduced the concept of a
key acting as a secure entry point into a delegation. During
DNS-related key exchanges between the child and parent zone, there is
a need to differentiate secure entry point keys from other keys in the
KEY resource record set. This differentiation is not for the DNS
protocols per se, but to help in determining what types of keys need
to be generated (e.g., for a DS RR) and how to automate their generation.
This document defines a flag bit in the KEY RR to indicate KEY RRs
that are used as a secure entry point. The flag bit is intended to
assist in oprational procedures to correctly generate DS resource
records, or to indicate what keys are intended for static
configuration. The flag bit has no semantics in the DNS protocols and
its value results in no special processing by the DNS protocols when
operating on KEY RRs. This document updates RFC 2535 and RFC 3445.
Working Group Summary
The dnsext Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Thomas Narten 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 5
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 5
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 [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
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 5
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.1 New Item - 4 of 5
o draft-ietf-geopriv-threat-analysis-01.txt
Threat Analysis of the geopriv Protocol (Informational)
Token: Ted Hardie
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 5 of 5
o draft-ietf-geopriv-reqs-04.txt
Geopriv requirements (Informational)
Token: Ted Hardie
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)
Note: Not ready for final approval, but would like to get security AD
opinions on document and flush out remaining issues.
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
Te