[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for July 10, 2003 Telechat (Final)
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the July 10, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, July 10, 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
Marcia Beaulieu---Regrets
Steve Bellovin---Will call in
Randy Bush---Call at +1 206 356 8341
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Dinara Suleymanova---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Jacqueline Hargest---Regrets
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten---Will call in
Erik Nordmark---Call at +33 4 76 99 84 29
Jon Peterson---Call at +358 9 4310 1
Joyce K. Reynolds---Regrets
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 participant should enter the passcode 235467 when prompted to do so.
The first person on the call will not hear anything until joined by other
participants. A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND
THUS INCUR CHARGES FROM THEIR OWN CARRIER.
o Bash the Agenda
o Approval of the Minutes
- June 26, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: June 20, 2003
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking architectural
questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex to send proposal and justification for interim document review.
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the current
info/proposed/etc.
IP o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
IP o Harald Alvestrand to talk to RFC Editor about independent submissions.
IP o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
IP o Secretariat to include teleconference bridge/call-in details in telechat
packages going forward.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-atommib-atm2-19.txt
Definitions of Supplemental Managed Objects for ATM Interface (Proposed
Standard)
Token: Nordmark, Erik
Note: Please put on the IESG agenda.
o draft-ietf-policy-qos-device-info-model-10.txt
Information Model for Describing Network Device QoS Datapath Mechanisms
(Proposed Standard)
Token: Wijnen, Bert
Note: On IESG agenda for July 10th. Responsible: Bert
o draft-ietf-policy-qos-info-model-05.txt
Policy QoS Information Model (Proposed Standard)
Token: Wijnen, Bert
Note: On IESG Agenda for July 10th. Responsible: Bert Wijnen
o draft-ietf-sip-sctp-03.txt
The Stream Control Transmission Protocol as a Transport for for the
Session Initiation Protocol (Proposed Standard)
Token: Mankin, Allison
o draft-ietf-ips-fcip-slp-07.txt
Finding FCIP Entities Using SLPv2 (Proposed Standard)
Token: Mankin, Allison
Note: SLP details were expert-reviewed (mediated by Thomas Narten)
- draft-ietf-ips-iscsi-slp-06.txt
Finding iSCSI Targets and Name Servers Using SLP (Proposed Standard)
o draft-ietf-sipping-3pcc-04.txt
Best Current Practices for Third Party Call Control in the Session
Initiation Protocol (BCP)
Token: Mankin, Allison
o draft-ietf-dnsext-rfc1886bis-03.txt
DNS Extensions to support IP version 6 (Draft Standard)
Token: Nordmark, Erik
Note: Please put on agenda.
o draft-ietf-ospf-hitless-restart-07.txt
Graceful OSPF Restart (Proposed Standard)
Token: Zinin, Alex
o draft-ietf-webdav-ordering-protocol-09.txt
WebDAV Ordered Collections Protocol (Proposed Standard)
Token: Hardie, Ted
o draft-ietf-avt-rtcp-report-extns-06.txt
RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard)
Token: Mankin, Allison
2.1.2 Returning Item
o draft-ietf-dnsext-gss-tsig-06.txt
GSS Algorithm for TSIG (GSS-TSIG) (Proposed Standard)
Token: Nordmark, Erik
Note: Need to get re-approved by the IESG. 05 was removed from the
rfc-editor's queue after IESG approval due to a conflict with TSIG
which has been resolved in 06..
o draft-katz-yeung-ospf-traffic-10.txt
Traffic Engineering Extensions to OSPF Version 2 (Proposed Standard)
Token: Fenner, Bill
Note: Returning to telechat to see if new version addresses DISCUSS
o draft-ietf-dnsext-ad-is-secure-06.txt
Redefinition of DNS AD bit (Proposed Standard)
Token: Nordmark, Erik
Note: Version 06 seems to satisfy discusses. Check if this. is the
case.
o draft-ietf-enum-rfc2916bis-06.txt
The E.164 to URI DDDS Application (ENUM) (Proposed Standard)
Token: Mankin, Allison
Note: Liaison statement was sent to SG-2 about Last Call.
o draft-ietf-sip-scvrtdisco-04.txt
Session Initiation Protocol Extension Header Field for Service Route
Discovery During Registration (Proposed Standard)
Token: Mankin, Allison
Note: Returning document on agenda to have SMB review security Discuss
and Ted review Discuss by Patrik - minor issue of unclear schematics.
Revision cycles were slow.
o draft-ietf-magma-mld-source-07.txt
Source Address Selection for Multicast Listener Discovery Protocol (RFC
2710) (Proposed Standard)
Token: Nordmark, Erik
Note: Document has been updated to address concerns from Thomas and
Russ.
o draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents (Proposed Standard)
Token: Narten, Thomas
Note: smb and randy have discusses, please see if concerns met.
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o draft-legg-ldapext-component-matching-11.txt
LDAP & X.500 Component Matching Rules (Proposed Standard)
Token: Hardie, Ted
Note: Depending on Subentry Specification for LDAP.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-gsmp-reqs-06.txt
Requirements For Adding Optical Support To GSMPv3 (Informational)
Token: Wijnen, Bert
Note: Responsible: Bert Wijnen
o draft-ietf-sipping-3gpp-r5-requirements-00.txt
3rd-Generation Partnership Project (3GPP) Release 5 requirements on the
Session Initiation Protocol (SIP) (Informational)
Token: Mankin, Allison
Note: On agenda with a proposed IESG Note clarifying that this
requirements discussion with 3GPP was a give-and-take, and that not
every requirement in this document is met.
o draft-ietf-manet-tbrpf-09.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Zinin, Alex
3.1.2 Returning Item
o draft-ietf-pkix-ipki-new-rfc2527-02.txt
Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework (Informational)
Token: Housley, Russ
o draft-ietf-ippm-owdp-reqs-06.txt
A One-way Active Measurement Protocol Requirements (Informational)
Token: Mankin, Allison
Note: Returning document. Important as guides main protocol of WG.
Now has strong mandatory to implement security and supports timestamp
encryption - on agenda for SMB to check against his pseudo-discuss..
o draft-ietf-manet-olsr-11.txt
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
o draft-ietf-crisp-requirements-05.txt
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
Token: Freed, Ned
Note: Asked to be added to IESG agenda
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o draft-savola-ipv6-127-prefixlen-04.txt
Use of /127 Prefix Length Between Routers Considered Harmful
(Informational)
Token: Bush, Randy
o draft-song-pppext-sip-support-02.txt
SIP server IPCP configuration option for PPP (Informational)
Token: Narten, Thomas
Note: Proposed DNP note:. The IESG requests that this document not
be published as an RFC. The document proposes extensions to PPP that
are not supported by the WG. Specifically, in response to discussion
on the PPPEXT mailing list, the WG chair reported "I think the
consensus is clear: Existing mechanisms are adequate to the
task." The PPPEXT WG considers the addition of PPP options
that are not directly related to PPP harmful to the protocol, and
therefore opposes publication of this document. Publishing this
document would be considered an end run around the wishes of the
PPPEXT WG.
o draft-siemborski-mupdate-04.txt
The MUPDATE Distributed Mailbox Database Protocol (Experimental)
Token: Freed, Ned
Note: On IESG agenda
3.2.2 Returning Item
NONE
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
o draft-sun-handle-system-11.txt
Handle System Overview (Informational)
Token: Hardie, Ted
Note: It is suggested that these go forward with the following. IESG
Note attached (originally drafted by Patrik): IESG NOTE: The IETF and
IRTF have discussed the Handle system in the realm of URI-related
work. The IESG wishes to point out that there is no IETF
consensus on the current Handle system nor on where it fits in the
IETF architecture. The IESG is of the view that the Handle
system would be able to, with very small changes, fit into the IETF
architecture as a URN namespace. These documents, however,
contain information on the Handle system without these changes.
- draft-sun-handle-system-protocol-05.txt
Handle System Protocol (ver 2.1) Specification (Informational)
- draft-sun-handle-system-def-08.txt
Handle System Namespace and Service Definition (Informational)
o draft-bradner-pbk-frame-06.txt
A Framework for Purpose-Built Keys (PBK) (Informational)
Token: Bellovin, Steve
o draft-leech-chinese-lottery-04.txt
Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking
Tool (Informational)
Token: Bellovin, Steve
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the June 26, 2003 IESG Teleconference
Reported by: Dinara Suleymanova, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Marcia Beaulieu / IETF Secretariat
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Erik Nordmark / Sun
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Dinara Suleymanova / IETF Secretariat
Alex Zinin / Alcatel
REGRETS
------------
Michelle Cotton / ICANN
Jacqueline Hargest / IETF Secretariat
Bert Wijnen / Lucent
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the June 12, 2003 Teleconference were approved pending
the removal of Microsoft characters. The Secretariat will place the
minutes in the public archives.
1.2 Review of Action Items
DONE:
* Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
* Ned to write an IESG note for draft-tegen-smqp (Informational).
* Allison Mankin to submit a Revised Charter for the Next Steps in
Signaling WG (nsis) to the Secretariat. Secretariat to send a WG Review
Announcement with copy to new-work@ietf.org.
* Secretariat to include teleconference bridge/call-in details in
teleconference packages going forward.
DELETED:
* Steve to generate a summary of IESG views of the "problem."
IN PROGRESS:
* Allison to review draft-agrawal-sip-h323-interworking-reqs and send
decision to IESG.
* Erik to document process of how the IESG goes about asking architectural
questions of the IAB.
* Thomas to write (or cause to be written) a draft on "how to get to
Draft."
* Thomas to contact Cablelabs to discuss formal relationship with IAB.
* Steve to write RFC re: TCP MD5 option.
* Randy and Ned to finish ID on Clarifying when Standards Track Documents
may Refer Normatively to Documents at a Lower Level.
* Alex to send proposal and justification for interim document review.
* Steve to propose a different document classification than the current
info/proposed/etc.
* Harald Alvestrand to talk to RFC Editor about independent submissions.
* Alex Zinin to phrase a question to RTG and OPS Area Directorates and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
NEW:
* Thomas Narten to coordinate and send comments on minutes to the
Secretariat. IESG to review the format of the minutes and propose
changes to improve readability and communication to the outside world.
* Steve Bellovin to make proposal to discuss "problem" at the Sunday IESG
meeting in Vienna. Thomas Narten to writeup issue with references in
draft-dasilva-l2tp-relaysvc-06.txt and start discussion in IESG list.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-enum-rfc2916bis.txt - 1 of 3
The E.164 to URI DDDS Application (ENUM) (Proposed Standard)
Token: Mankin, Allison
The document was deferred to the next teleconference by Harald Alvestrand.
The document remains under discussion by the IESG in order to resolve
points raised by Ted Hardie.*
o draft-ietf-mmusic-sdp-new-13.txt - 2 of 3
SDP: Session Description Protocol (Proposed Standard)
Token: Peterson, Jon
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Bill Fenner, Ned Freed, Ted Hardie and Russ
Housley.*
o draft-ietf-avt-mpeg4-simple-07.txt - 3 of 3
RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed
Standard)
Token: Mankin, Allison
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin.*
2.1.2 Returning Item
o draft-ietf-avt-srtp-08.txt - 1 of 3
The Secure Real-time Transport Protocol (Proposed Standard)
Token: Mankin, Allison
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin and Russ Housley.*
o draft-ietf-sipping-overlap-04.txt - 2 of 3
Mapping of Integrated Services Digital Network (ISUP) Overlap Signalling
to the Session Initiation Protocol (Proposed Standard)
Token: Mankin, Allison
The document was approved by the IESG.
The Secretariat will send a working group submission Protocol Action
Announcement.
o draft-ietf-ccamp-lmp.txt - 3 of 3
Link Management Protocol (LMP) (Proposed Standard)
Token: Zinin, Alex
The document was added to the agenda by Alex Zinin and remains under
discussion by the IESG in order to resolve points raised by Steve
Bellovin, Ted Hardie, Thomas Narten and Russ Housley.*
2.2 Individual Submissions
2.2.1 New Item
o draft-legg-ldapext-component-matching-10.txt - 1 of 1
LDAP & X.500 Component Matching Rules (Proposed Standard)
Token: Hardie, Ted
The document was deferred to the next teleconference by Harald Alvestrand
and Bill Fenner.
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-speechsc-reqts-04.txt - 1 of 7
Requirements for Distributed Control of ASR, SI/SV and TTS Resources
(Informational)
Token: Peterson, Jon
The document remains under discussion by the IESG.* A revised I-D is
needed.
o draft-ietf-nsis-req-08.txt - 2 of 7
Requirements for Signaling Protocols (Informational)
Token: Mankin, Allison
Note: Extensive review with WG and editor. Document was revised to meet
deadline of 6/26 agenda.
The document remains under discussion by the IESG.* A revised I-D is
needed
o draft-ietf-mpls-ldp-restart-applic-01.txt - 3 of 7
Applicability Statement for Restart Mechanisms for the Label
Distribution Protocol (Informational)
Token: Zinin, Alex
Note: Responsible: WG chairs
The document was approved by the IESG.
The Secretariat will send a working group submission Document Action
Announcement.
o draft-ietf-manet-olsr-10.txt - 4 of 7
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
The document remains under discussion by the IESG.*
o draft-ietf-rmt-bb-fec-supp-compact-01.txt - 5 of 7
Compact Forward Error Correction (FEC) Schemes (Experimental)
Token: Mankin, Allison
The document was approved by the IESG pending an RFC Editor Note regarding
IANA considerations to be prepared by Thomas Narten and Allison Mankin.
The Secretariat will send a working group submission Document Action
Announcement that includes the RFC Editor Note.
o draft-ietf-crisp-requirements-05.txt - 6 of 7
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
Token: Freed, Ned
Note: Asked to be added to IESG agenda
The document remains under discussion by the IESG.*
o draft-ietf-v6ops-unman-scenarios-02.txt - 7 of 7
Unmanaged Networks IPv6 Transition Scenarios (Informational)
Token: Bush, Randy
Ted Hardie and Allison Mankin will send comments to the IESG on this
document.
3.1.2 Returning Item
o draft-ietf-multi6-multihoming-requirements-07.txt - 1 of 3
Goals for IPv6 Site-Multihoming Architectures (Informational)
Token: Bush, Randy
The document was approved by the IESG. The Secretariat will send a
working group submission Document Action Announcement.
o draft-ietf-nsis-qos-requirements-01.txt - 2 of 3
Requirements of a QoS Solution for Mobile IP (Informational)
Token: Mankin, Allison
Note: This document is a renaming of
draft-ietf-mobileip-qos-requirements-03.txt (expired). That document
was reviewed by IESG already and was given a go, except for lacking a
Security Consideration section, which it now has (2003-06-19).
The document was approved by the IESG. The Secretariat will send a working
group submission Document Action Announcement.
o draft-ietf-ccamp-tracereq-05.txt - 3 of 3
Tracing Requirements for Generic Tunnels (Informational)
Token: Wijnen, Bert
Note: Approved by IESG
The document was approved by the IESG pending confirmation from Alex Zinin
that Randy Bush approves. Upon notification from Alex Zinin, the
Secretariat will send a working group submission Document Action Announcement.
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-lear-tftp-uri-06.txt - 1 of 1
URI Scheme for the TFTP Protocol (Informational)
Token: Hardie, Ted
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Ted Hardie. The Secretariat will send an individual
submission Document Action Announcement that includes the RFC Editor Note.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-paskin-doi-uri-03.txt - 1 of 4
The 'doi' URI Scheme for Digital Object Identifier (DOI) (Informational)
Token: Hardie, Ted
The IESG recommends that the RFC Editor does not publish this document.
The Secretariat will send a Do Not Publish note prepared by Ted Hardie to
the RFC Editor.
o draft-foster-mgcp-bulkaudits-09.txt - 2 of 4
The Media Gateway Control Protocol (MGCP) Bulk Audit Package
(Informational)
Token: Peterson, Jon
The IESG has no problem with the RFC Editor publishing this document.
Jon Peterson will prepare a "no problem" message, and forward it to the
Secretariat to send to the RFC Editor.
o draft-eastlake-xxx-06.txt - 3 of 4
.sex Considered Dangerous (Informational)
Token: Alvestrand, Harald
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-baker-slem-architecture-01.txt - 4 of 4
Cisco Support for Lawful Intercept In IP Networks (Informational)
Token: Alvestrand, Harald
The document was assigned to Steve Bellovin.
The Secretariat will update the ID-Tracker.
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Layer 2 Virtual Private Networks - 1 of 3
Token: Narten, Thomas
Thomas Narten and Alex Zinin will send a message to the IETF mailing list
regarding the formation of the two working groups: Layer 2 Virtual Private
Networks and Layer 3 Virtual Private Networks.
Both working groups were approved by the IESG. However, the Secretariat
will not send the WG Action Announcements until it receives the go-ahead
from Alex Zinin.
o Layer 3 Virtual Private Networks - 2 of 3
Token: Narten, Thomas
See decision under Layer 2 Virtual Private Networks
o Path Maximum Transmission Unit Discovery - 3 of 3
Token: Mankin, Allison
Allison Mankin will provide a revised charter to the IESG for review.
The Secretariat will send a WG Action Announcement when Allison Mankin
confirms that the IESG has approved the new charter.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o Issues on L2TP Active Discovery Relay for PPPoE - added by Thomas Narten
(discussed)
o Issues on "problem" group - added by Harald Alvestrand
(discussed)
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-atommib-atm2 -
Definitions of Supplemental Managed Objects for ATM Interface
--------
Last Call to expire on: 2003-06-19
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, atommib@research.telcordia.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Supplemental Managed Objects for ATM
Interface to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Definitions of Supplemental
Managed Objects for ATM Interface' <draft-ietf-atommib-atm2-19.txt> as a
Proposed Standard. This document is the product of the AToM MIB Working
Group. The IESG contact persons are Thomas Narten and Erik Nordmark
The IESG has approved the Internet-Draft 'Definitions of Supplemental
Managed Objects for ATM Interface' <draft-ietf-atommib-atm2-19.txt> as
a Proposed Standard.
This document is the product of the AToM MIB Working Group.
The IESG contact persons are
Thomas Narten
Erik Nordmark
Technical Summary
This memo defines objects used for managing ATM-based interfaces, devices,
and services in addition to those defined in the ATM-MIB [24], to
provide additional support for the management of:
- ATM Switched Virtual Connections (SVCs)
- ATM Permanent Virtual Connections (PVCs)
Working Group Summary
There was consensus in the WG to advance this document.
Protocol Quality
This document has reviewed for the IESG by Erik Nordmark and Bert Wijnen.
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-policy-qos-device-info-model -
Information Model for Describing Network Device QoS Datapath Mechanisms
--------
Last Call to expire on: 2003-06-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 [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
In the Abstract:
s/This documenthis document/This document/
s/Together, these two drafts/Together, these two documents/
In the Introduction:
s/A separate draft could be written/A separate document could be written/
s/Similarly, a draft could be written/Similarly, a document could be
written/
s/Together, these four drafts/Together, these four documents/
s/Model Extensions draft [PCIME]./Model Extensions [PCIME]./
In section 7:
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <policy@ietf.org>
Subject: Protocol Action: Information Model for Describing Network Device QoS
Datapath Mechanisms to a Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Information Model for Describing
Network Device QoS Datapath Mechanisms'
<draft-ietf-policy-qos-device-info-model-10.txt> as a Proposed Standard.
This document is the product of the Policy Framework Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen
Technical Summary
The purpose of this document is to define an information model to
describe the quality of service (QoS) mechanisms inherent in
different network devices, including hosts. Broadly speaking,
these mechanisms describe the properties common to selecting and
conditioning traffic through the forwarding path (datapath) of a
network device. This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services and Integrated Services.
This documen should be used with the QoS Policy Information Model
(QPIM) to model how policies can be defined to manage and configure
the QoS mechanisms (i.e., the classification, marking, metering,
dropping, queuing, and scheduling functionality) of devices.
Together, these two drafts describe how to write QoS policy rules
to configure and manage the QoS mechanisms present in the datapaths
of devices.
This document, as well as QPIM, are information models. That is,
they represent information independent of a binding to a specific
type of repository.
Working Group Summary
The Working Group has consensus on this document to be published as
Proposed Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
RFC-Editor notes:
- 2nd para of abstract
OLD:
This documenthis document
NEW:
This document
- Co-Author Walter Weiss is now at: walterweiss@attbi.com
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-policy-qos-info-model -
Policy QoS Information Model
--------
Last Call to expire on: 2003-06-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 [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ:
Discuss:
The first paragraph of the Introduction indicates that the QPIM includes
a standard framework for controlling access to network QoS resources. Yet,
I do not find any discussion of authentication, authorization, or access
control. The discussion of admission control actions is not sufficient to
meet fulfill the expectation of the Introduction. At a minimum, acc
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, policy@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action
-------------
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <policy@ietf.org>
Subject: Protocol Action: Policy QoS Information Model to a Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Policy QoS Information Model'
<draft-ietf-policy-qos-info-model-05.txt> as a Proposed Standard. This
document is the product of the Policy Framework Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen
Technical Summary
This document presents an object-oriented information model for
representing policies that administer, manage, and control access to
network QoS resources. This document is based on the IETF Policy Core
Information Model and its extensions.
This defines an information model for QoS enforcement for
differentiated and integrated services using policy.
It is important to note that this document defines an information
model, which by definition is independent of any particular data
storage mechanism and access protocol.
Working Group Summary
The Working Group has consensus to publish this document as Proposed
Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
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-sip-sctp -
The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol
--------
Last Call to expire on: 2003-07-03
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Bert Wijnen:
I wonder though about the last para of the Introduction.
It makes it read as if this "draft" (probably better to change
to "document") is intended as Expeirmental RFC.
Russ Housley:
1. Add "(the Session Initiation Protocol)" after the first use of "SIP" in the Abstract.
2. Please spell out first use of "SRV."
3. Is the Note in the middle of section 4.1 going to be removed prior to
publication as an RFC? If not, then it needs to be reworded. The RFC
should not refer to "previous versions of this document."
4. The following replacement for the Security Considerations section in
proposed in the ballot:
The security issues raised in [2] are not worsened by SCTP, provided the
advice in Section 4 is followed and SCTP over TLS [cite RFC 2436] is
used where TLS would be required in [2].
TLS is normally used over TCP. Wouldn't the layering here be SIP over TLS
over SCTP?
Ted Hardie:
Discuss:
Overall, I think this is good, interesting work. I'm not sure I understood
two small things, though, and I'd like help understanding them. In
Section 3.2,
one of the descriptions for advantages over TCP contains the following:
On the other hand, SCTP can deliver
signalling messages to the application as soon as they
arrive (when using the unordered service). The loss of a
signalling message does not affect the delivery of the rest
of the messages. This avoids the head of line blocking
problem in TCP, which occurs when multiple higher layer
connections are multiplexed within a single TCP connection.
A SIP transaction can be considered an application layer
connection. Between proxies there are multiple transactions
running. The loss of a message in one transaction should
not adversely effect the ability of a different transaction
to send a message. Thus, if SIP is run between entities
with many transactions occurring in parallel, SCTP can
provide improved performance over SIP over TCP (but not SIP
over UDP; but SIP over UDP is not ideal from a congestion
control standpoint, see above).
This seems to imply that SIP over SCTP is expected to be used commonly
only between proxies or other entities that meet the test "entities
with many transaction occurring in parallel". Is that a strong enough
expectation that an explicit applicability statement to that effect
would be useful?
It seems to be implied, but having that inside a section on comparisons
between SCTP and TCP may make it less than obvious.
In the section on mapping SIP transactions into streams, the document says:
Some applications introduce an extra layer between the transport
layer and SIP (e.g., compression and/or encryption). This extra layer
sometimes requires ordered delivery of messages from the transport
layer (e.g., TLS [6]). In this case, it is RECOMMENDED that SIP
messages belonging to the same transaction are sent over the same
stream and messages belonging to different transactions are sent over
I wonder whether there are not applications which introduce the same
requirement because of the semantics of their use of SIP itself, rather
than because of layering. In particular, I wonder whether session-mode
message (draft-ietf-simple-message-sessions-01.txt) would or
would not require the same treatment. If not, I suspect that this implies
that those applications either should not pipeline requests (since a proxy
may be using a transport that does not guarantee ordered delivery) or
they must be able to handle the resulting failure mode in some graceful way.
Notes:
Section 3.1: Looks like a minor grammar error in this sentence:
"IP fragmentation increases the likelihood of having packet losses
and make it difficult (when not impossible) NAT and firewall traversal."
Changing it to "and making it difficult (when not impossible) to traverse
NATs or firewalls" would fix it, as would several other choices.
Section 4. A couple of minor preposition questions:
"The SIP transport layers of both peers are responsible to manage the
for managing?
persistent SCTP connection between them. On the sender side the core
or a client (or server) transaction generates a request (or response)
and passes it to the transport layer. The transport sends the request
to the peer's transaction layer. The peer's transaction layer is
responsible of delivering the incoming request (or response) to the
for delivering?
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Stream Control Transmission Protocol as a
Transport for for the Session Initiation Protocol to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The Stream Control
Transmission Protocol as a Transport for for the Session Initiation
Protocol' <draft-ietf-sip-sctp-03.txt> as a Proposed Standard. This
document is the product of the Session Initiation Protocol Working
Group. The IESG contact persons are A. Mankin and J. Peterson.
Technical Summary
The Stream Control Transmission Protocol (SCTP)] has been designed
as a new transport protocol for the Internet at the
same layer as TCP and UDP. SCTP has been designed with the transport
of legacy SS7 signaling messages in mind. A number of
of the features designed to support transport of such signaling are
also useful for the transport of SIP (the Session Initiation
Protocol) [2], which is used to initiate and manage interactive
sessions on the Internet.
SIP itself is transport-independent, and can run over any reliable or
unreliable message or stream transport. However, procedures are only
defined for transport over UDP and TCP. In order to encourage
experimentation and evaluation of the appropriateness of SCTP for SIP
transport, this document defines transport of SIP over SCTP.
Note that this is not a proposal that SCTP be adopted as the primary
or preferred transport for SIP; substantial evaluation of SCTP,
deployment, and experimentation can take place before that happens.
This specification is targeted at encouraging such experimentation by
enabling it in SIP.
Working Group Summary
The working group had consensus to advance the draft to Proposed
Standard.
Protocol Quality
An implementation of a SIP client over SCTP in Linux has recently been
announced.
Review of this specification for the IESG was by Allison Mankin.
RFC Editor Note
In the following sentence:
This extra layer
sometimes requires ordered delivery of messages from the transport
layer (e.g., TLS [6]).
Add a normative reference to RFC 3436 (SCTP over TLS).
Replace Section 6 Security Considerations
The security issues raised in [2] are not worsened by SCTP, provided the
advice in Section 4 is followed and SCTP over TLS [cite RFC 2436] is
used where TLS would be required in [2].
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-ips-fcip-slp -
Finding FCIP Entities Using SLPv2
--------
Last Call to expire on: 2003-07-03
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ:
Comment:
Please remove references from the Abstract. Also, spell out FCIP.
Please spell out SLPv2 and FCIP in the Introduction.
Ted:
Discuss:
In the section on how to deal with NATs and NAPTs, the draft
says:
- Use the default IANA-assigned FCIP TCP port number in service URLs,
when possible.
- If advertising service URLs through a translating device (e.g., a
NAT/NAPT device), and the FQDN, IP address, or TCP port will be
translated, the translating device can provide an SLPv2 proxy
capability to do the translation.
I don't think I understand how the first one helps (is there some default
mapping through NAPTs presumed for well known ports?) For the second,
the point is that those inside a private address realm often don't know that
there is a NA(P)T between them and some user, and there can be
multiple ones in the path. I suspect the right answer is not fix this
in this particular document, but just note that "SLP advertisements
that occur inside a private address realm may be unreachable outside
that realm" and refer back to the SLP docs description of scope for
SLP.
Also, the security considerations in the templates chain badly. The first one
points to the concrete service template which says "See later section".
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ips@ece.cmu.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Finding FCIP Entities Using SLPv2 to Proposed
Standard
-------------
The IESG has approved the Internet-Drafts
* 'Finding FCIP Entities Using SLPv2'
<draft-ietf-ips-fcip-slp-07.txt>
* 'Finding iSCSI Targets and Name Servers Using SLP'
<draft-ietf-ips-iscsi-slp-06.txt>
as Proposed Standards. These documents are products of the IP Storage
Working Group. The IESG contact persons are A. Mankin and J. Peterson
Technical Summary
draft-ietf-ips-fcip-slp-07.txt describes the use of the Service
Location Protocol Version 2 (SLPv2) to perform dynamic discovery of
participating FCIP Entities. Implementation guidelines, service
type templates, and security considerations are specified. FCIP is
a pure FC encapsulation protocol that transports FC frames. As
defined by the IPS WG, it interconnects Fibre Channel switches over
TCP/IP networks.
draft-ietf-ips-iscsi-slp-06.txt defines the use of SLPv2 by iSCSI
hosts, devices, and management services, along with the SLP service
type templates that describe the services they provide and security
considerations. The iSCSI protocol provides a way for hosts to
access SCSI devices over TCP/IP.
Working Group Summary
The Working Group had consensus to advance both documents to Proposed
Standard. The SLPv2 and discovery aspects were given review and
discussion on the mailing list by Erik Guttman and James Kempf, and this
was an active discussion.
Protocol Quality
The documents were reviewed for the IESG by Erik Guttman, James Kempf,
Thomas Narten and Allison Mankin.
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-sipping-3pcc -
Best Current Practices for Third Party Call Control in the Session Initiation Protocol
--------
Last Call to expire on: 2002-06-03
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley:
The Introduction says that use of RFC 3312 and early media are not
trivial. I do not think that correctly implementing TCP is trivial
either. It would be much better to describe the nature of the adverse
complexity. A pointer to a section where that is discussed more fully
would be fine.
Sections 12.1 and 12.2 include a discussion of S/MIME, but there is not
a reference. I suspect that S/MIME is not really needed, bit that CMS (see
RFC 3369) is sufficient. Please add the appropriate reference.
I think that the security considerations should also address
authorization. I suggest that a new section 12.3 be added.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Best Current Practices for Third Party Call Control
in the Session Initiation Protocol to BCP
-------------
The IESG has approved the Internet-Draft 'Best Current Practices for
Third Party Call Control in the Session Initiation Protocol'
<draft-ietf-sipping-3pcc-04.txt> as a BCP. This document is the
product of the Session Initiation Proposal Investigation Working
Group. The IESG contact persons are A. Mankin and J. Peterson.
Technical Summary
Third party call control refers to the ability of one entity to
create a call in which communications is actually between other
parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However,
there are several possible approaches, each with different benefits
and drawbacks. This document discusses best current practices for the
usage of SIP for third party call control.
Security and identity are important issues in third party call control.
The document provides recommendations for the controller to use a
credentialled identity. It also provides recommendations to ensure that
the two endpoints in the third party controlled call can set up end-to-end
secured media.
Working Group Summary
There was strong working group consensus to advance this document and
it has a significant pull from the community, including 3GPP. There were
no issues raised during IETF Last Call.
Protocol Quality
The document was reviewed for the IESG by Eric Rescorla and Allison Mankin
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-dnsext-rfc1886bis -
DNS Extensions to support IP version 6
--------
Last Call to expire on: 2003-06-17
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Comment:
In the Abstract:
s/Domain Name System/Domain Name System (DNS)/
s/RFC1886/RFC 1886/
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: DNS Extensions to support IP version 6 to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'DNS Extensions to support IP
version 6' <draft-ietf-dnsext-rfc1886bis-03.txt> as a Draft Standard. This
document is the product of the DNS Extensions Working Group. The IESG
contact persons are Thomas Narten and Erik Nordmark
The IESG has approved the Internet-Draft 'DNS Extensions to support
IP version 6' <draft-ietf-dnsext-rfc1886bis-03.txt> as a Draft Standard.
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are
Thomas Narten
Erik Nordmark
Technical Summary
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
changes include a resource record type to store an IPv6 address,
a domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
This Document combines RFC1886 and changes to RFC 1886 made by
RFC 3152, obsoleting both. Changes mainly consist in replacing
the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
Working Group Summary
There was WG consensus to advance this document.
Protocol Quality
The specification has been reviewed for the IESG by Erik Nordmark.
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-ospf-hitless-restart -
Graceful OSPF Restart
--------
Last Call to expire on: 2003-06-20
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Comment:
In the Abstract and Introduction, spell out first use of OSPF.
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <OSPF@PEACH.EASE.LSOFT.COM>
Subject: Protocol Action: Graceful OSPF Restart to Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Graceful OSPF Restart'
<draft-ietf-ospf-hitless-restart-07.txt> as a Proposed Standard. This
document is the product of the Open Shortest Path First IGP Working Group.
The IESG contact persons are Bill Fenner and A. Zinin
Technical Summary
This memo documents an enhancement to the OSPF routing protocol,
whereby an OSPF router can stay on the forwarding path even as its
OSPF software is restarted. This is called "graceful restart" or
"non-stop forwarding". Deployment of this mechanism in the service
provider networks should decrease unnecessary path recalculation and
traffic rerouting.
Working Group Summary
The WG considered two proposals to address the graceful restart
problem--the one represented in draft-nguyen-ospf-restart, and the
one described in the submitted document. The main difference between
the two proposals was in the mechanism for graceful restart
signaling, database synchronization and determining when graceful
restart had completed. At the 50th IETF in Minneapolis the WG made a
decision via rough consensus to proceed with the latter approach,
which since then has receive substantial technical review within the
WG and passed the WG Last Call. The described mechanism has been
implemented and deployed by several vendors.
Protocol Quality
The specification has been reviewed for the IESG by Alex Zinin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-webdav-ordering-protocol -
WebDAV Ordered Collections Protocol
--------
Last Call to expire on: 2003-06-19
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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 Ordered Collections Protocol to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'WebDAV Ordered Collections
Protocol' <draft-ietf-webdav-ordering-protocol-08.txt> as a Proposed
Standard.
This document is the product of the WWW Distributed Authoring and
Versioning Working Group.
The IESG contact persons are
Ned Freed
Ted Hardie
Technical Summary
The document extends the WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members, for use
when a client's use of the search protocol's ordering option would
not be appropriate or sufficient. It defines protocol elements that
permit clients to specify the position of each member of a collection
in an ordering. One common use case that has been discussed is
maintaining markers like page numbers.
Working Group Summary
The working group held a four week last call on the document and
comments received were generally positive. There was one set of
comments received during IETF last call, and the authors revised
the documents to handle the issues. The working group acknowledged
that problem it faced represented choices among several sets of
engineering trade offs, and it believes it has come to consensus on
those trade-offs.
Note that the document specifies methods of handling client-specified
but server-maintained orderings. The presumption of this work is
that a human will generally use a webdav client to create and maintain
these orderings. The working group aims to allow further extensions
to describe automatic, server-maintained orderings, but this document
does not specify those mechanisms.
Protocol Quality
Ted Hardie reviewed this document for the IESG
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-avt-rtcp-report-extns -
RTP Control Protocol Extended Reports (RTCP XR)
--------
Last Call to expire on: 2003-07-03
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Control Protocol Extended Reports (RTCP XR) to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'RTP Control Protocol
Extended Reports (RTCP XR)' <draft-ietf-avt-rtcp-report-extns-06.txt>
as a Proposed Standard. This document is the product of the
Audio/Video Transport Working Group. The IESG contact persons are
A. Mankin and J. Peterson
Technical Summary
This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session
Description Protocol (SDP). XR packets are composed of report
blocks, and seven block types are defined here. The purpose of the
extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by
RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some
applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics. In addition to the block types defined here,
additional block types may be defined in the future by adhering to
the framework that this document provides. Security considerations
including the use of Secure RTCP to overcome the heightened amount of
information provided by the XR packet type are described.
Working Group Summary
The working group divided for a time on whether to include more complex
types of monitoring in the initial seven block types, but the resolution
on the framework achieved a very good consensus.
Protocol Quality
Prototype implementations exist of the XR packet type and have been
discussed in reviewing the specification.
The review of the specification was very active due to strong interest
by a variety of communities.
The review for the IESG was done by Allison Mankin.
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-dnsext-gss-tsig -
GSS Algorithm for TSIG (GSS-TSIG)
--------
Last Call to expire on: 2002-02-22
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <namedroppers@ops.ietf.org>
Subject: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'GSS Algorithm for TSIG (GSS-TSIG)' <draft-ietf-dnsext-gss-tsig-06.txt> as a Proposed Standard. This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Thomas Narten and E. Nordmark
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-katz-yeung-ospf-traffic - Traffic
Engineering Extensions to OSPF Version 2 to Proposed Standard
--------
Last Call to expire on: 2002-12-26
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ X ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Randy:
still no-ob, and apologies for posting a no-ob to the list, but an
ops-dir reviewer says
one question that strikes me is whether *Intra-area* TE is actually
usable and applicable to TE scenarios... and whether it's inter-area
which you really need, and having possibly different solutions for
each -- if this could not be extended to support inter-area -- could
be undesirable.
Russ:
In section 1: s/OSPF Version 2 [1]/OSPF Version 2 (OSPFv2) [1]/
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ospf@discuss.microsoft.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Traffic Engineering Extensions to OSPF
Version 2 to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Traffic Engineering
Extensions to OSPF Version 2' <draft-katz-yeung-ospf-traffic-09.txt>
as a Proposed Standard. This document is the product of the Open
Shortest Path First IGP Working Group.
The IESG contact persons are Bill Fenner and Alex Zinin.
Technical Summary
The Traffic Engineering Extensions to OSPF Version 2 define a method
for describing the traffic engineering topology (including bandwidth
and administrative constraints) and distributing this information
within a given OSPF area. The traffic engineering topology need not
be congruent with the regular routed topology.
Working Group Summary
There was strong support in the working group for this extension.
The working group made several clarifications to the document
during Working Group Last Call. Other minor changes, especially
to clarify that this extension is only suitable for intra-area
Traffic Engineering, were agreed to during IETF Last Call.
Protocol Quality
Bill Fenner and Alex Zinin reviewed the spec for the IESG. These
extensions are widely implemented and deployed.
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-ad-is-secure - Redefinition of
DNS AD bit to Proposed Standard
--------
Last Call to expire on: May 21, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ X ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
Since Jeff voted on this document, I contacted him about his concerns.
Jeff feels that the applicability statement in section 4 should really
re-emphasis the last paragraph of section 3, making it clear that even if
an organization decides to trust a certain DNS server, software should only
grant that trust if a secure transport can be negotiated. The proposed RFC
Editor note addresses this concern in a different way. It suggests that
the path must also be trusted.
I fear that implementors will trust the AD bit as meaning "secure" and
then not bother to protect the transport, which admits the possibility of
spoofing attacks. Therefore I propose an alternative paragraph for the RFC
Editor note:
In the latter two cases, the end consumer must also completely
trust the network path to the trusted resolvers or a secure
transport is employed to protect the traffic.
Further, I suggest that the Security Considerations be expanded to
provide a discussion on how a secure transport can be provided. I would
think that DNSSEC and IPsec are obvious alternatives.
COMMENT:
========
Randy: this 'discuss' is meant literally. i just think that there are
some issues here worth discussing.
the major issue here is that having a remote, often untrusted, server
assert (often over an untrusted channel) that the data met its local
policies is not overly useful and is possibly misleading. the counter
is that the stub client may have a trust relationship, via tsig or
whatever, with the server, which also provides a trustable channel.
on the other hand, this is no worse, and arguably better than the
current definition of the AD bit. this then devolves into the
question of whether it is better to improve a weak assertion or to
recover the bit and reserve it for future use.
who is going to use this assertion? is it thought that application
layers will learn the trust state of the dns data which they use?
and then, there is the exciting question of what this means in the
presense of the dreaded opt-in. the client can not tell if the server
which set the AD bit is locally configured to like opted-out data.
Scott:
never says what "AD" means - should expand in title and abstract
sec 2 - I can not tell what is old & what is new behavior
it would be good if the wording were clear
usage model would help
references not split
Allison: The final paragraph of the Security Considerations is written
in a way that obscures meaning, in contrast to the related
final paragraph of Section 3.
> Resolvers (full or stub) that blindly trust the AD bit without
> knowing the security policy of the server generating the answer can
> not be considered security aware.
A better version would be "that blindly trust the AD bit MUST
be used only in an environment in which configurations ensure
that the security policy of the server is appropriate to
the AD bit's information being valid for a decision on whether
to use the information it applies to"
Perhaps rather than obscuring meaning, it is actually wrong.
But the above hasty attempt tried to express something less
wrong.
^L
To: IETF-Announce:;
Dcc: all-ietf
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Redefinition of DNS AD bit to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Redefinition of DNS AD bit'
<draft-ietf-dnsext-ad-is-secure-06.txt> as a Proposed Standard.
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Erik Nordmark and Thomas Narten.
Technical Summary
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified or the server is
authoritative for the data and is allowed to set the bit by policy.
Working Group Summary
There was some dissent expressed by one person whether the AD bit
carries any semantics which can not be inferred from the replies
which the stub resolver receives.
Protocol Quality
The specification has been reviewed for the IESG by Erik Nordmark.
Suggested RFC Editor Note:
Before the last paragraph in section 4 add this paragraph:
In the latter two cases, the end consumer must also trust the
path to the trusted resolvers.
Add this paragraph to the end of section 2.2:
Note that having the AD bit clear on an authoritative answer is
normal and expected behavior.
The draft also has an odd "MUST" in section 2.2.1:
Organisations that require that all DNS responses contain
cryptographically verified data MUST separate the functions of
authoritative and recursive servers, as authoritative servers are not
required to validate local secure data.
This introduces a new concept "local secure data", w/o defining it.
Replace that paragraph with:
Organisations which require that all DNS responses contain
cryptographically verified data will need to separate the
authoritative name server and signature verification functions, since
name servers are not required to validate signatures of data for which
they are authoritative.
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-enum-rfc2916bis - The E.164 to URI DDDS
Application (ENUM) to Proposed Standard
--------
Last Call to expire on: 2003-6-23
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ D ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Ted:
I went back forth as to whether these were serious nits
or a mild discuss. The tired lady mentioned in the nit
related to section 2.1 was the deciding factor. In other
words, I think these should be fixed, but pushback is
welcome.
In the introduction:
"like delegation through NS records and NAPTR records, one can look up
what services are available for a specific domain name"
Would it not make more sense to say, "what services are associated with a
specific E.164 number"? This is not general to all domain names.
For Section 1.2, the language seems less than clear. How about:
This document describes the operation of these mechanisms in the context
of numbers allocated according to the ITU-T recommendation E.164. The
same mechanisms might be used for private dialing plans. If the
mechanisms are re-used, the suffix used for the private dialing plan
MUST NOT be e164.arpa, to avoid conflict with this specification.
Parties to the private dialing plan will need to know the the suffix
used by their private dialing plan for correct operation of these
mechanisms. Further, the application unique string used SHOULD be
the full number as specified, but without the leading '+'
In Section 2.1, the draft says:
For example, the E.164 number could start out as "+1-770-923-9595".
To ensure that no syntactic sugar is allowed into the AUS, all
non-digits except for "+" are removed, yielding "+17709239595".
I'm not sure "syntactic sugar" is clear. Is the AUS a gas tank? :)
Frankly, I'd suggest deleting the second paragraph, as I don't think it adds
anything, but if it's kept, I'd suggest updating it to "the E.164 number could
be represented to a user as". I'd also suggest using a known-to-be invalid
number. A tired lady answer this number when I called it,
and she didn't know anything about this draft.
In section 2.4.2.1, the draft says:
The mapping, if any, have
to be made explicit in the specification for the Enumservice itself.
A registration of a specific Type also have to specify the Subtypes
allowed.
I think the grammar is off there. how about: "the mapping, if any,
must be made
explicit"?
I'm concerned that section 2.5 might cause as much confusion as it
prevents. How about replacing the whole thing with "The ENUM algorithm
always returns a single rule. Specific applications may have
application-specific knowledge or facilities that allow them to
present multiple results or speed selection, but these should
never change the operation of the algorithm."
For the IANA consideration, the work requested by the first two paragraphs
is done. I think that it would be betterto change it to note that
the obsoleted RFC
requested these, and to give a pointer to the current IAB/ITU-T agreement.
COMMENTS:
========
Thomas:
One other nit on this document:
the document series specified in RFC 3401. It is very important to
note that it is impossible to read and understand this document
without reading the documents discussed in RFC 3401.
yet, 3401 is not a normative reference? That doesn't seem right.
Thomas
COMMENT:
=======
Allison:
Thomas,
I agree, I think it's an oversight that 3401 is not a normative reference.
Allison
^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>, enum@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The E.164 to URI DDDS Application (ENUM) to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The E.164 to URI DDDS Application
(ENUM)' <draft-ietf-enum-rfc2916bis-06.txt> as a Proposed Standard.
This document is the product of the Telephone Number Mapping Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
This document specifies how DNS can be used for identifying available
services connected to one E.164 number. It specifically obsoletes RFC
2916 to bring it in line with the Dynamic Delegation Discovery System
(DDDS) Application specification found in RFC 3401 and its companion
RFCs.
Working Group Summary
The working group strongly supported advancement of the draft, after
careful technical review.
Protocol Quality
There are currently in prototype use several implementations of this
draft, and registries of services following the format here are under
active development. The document was reviewed for the IESG by Allison
Mankin
RFC Editor Note -
Change the first sentence of Section 3.1.4 Publication Requirements:
Old:
Proposals for Enumservices registered must be published as RFCs on
the Standards Track or as a BCP.
New:
Proposals for Enumservices registered must be published as RFCs.
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-sip-scvrtdisco - Session Initiation
Protocol Extension Header Field for Service Route Discovery
During Registration to Proposed Standard
--------
Last Call to expire on: 2002-11-15
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ XX] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [XX ] [ X ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Steve: The Security Considerations section is confusing, and (I think) wrong.
The first paragraph speaks of proxies modifying things. This is indeed
a threat. But the end of that paragraph and the next speak of using
transport security between proxies. That does nothing against this
threat -- the problem occurs from misbehavior by the authorized proxy.
Transport security protects against MITM attacks, not nasty endpoints.
The note at the end of the second paragrap, suggesting S/MIME, is the
correct answer against this threat. Transport-level security might be
useful against other threats.
I suspect that fixing the first sentence of Section 7 to speak of MITMs
instead of proxies will clear up the confusion; the issue of
misbehaving proxies can be described briefly in the second paragraph.
I'm also concerned that there's no mandatory-to-implement specified (or
is S/MIME support required of Registrars elsewhere?). If not, there
should be some text somewhere mandating implementation of it, though
(of course) not necessarily use; the current "SHOULD" language is
sufficient.
Patrik:
Discuss/nit:
The scenario in section 6.4 is confusing.
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HS------|
HS is not used anywhere, but HSP. I guess this is a mistake.
Secondly, if we have nodes connected to a network which is IP enabled
(this is SIP, remember), and UA1 is to contact R initially, why is P1
and P2 there?
The correct scenario should be that UA1 contacts R, and get a
notification that his "home" at the moment is at HS(P) for the domain
HOMEDOMAIN.
The ascii art need to be more clear. What does the lines represent?
Lines between clouds which have firewalls between them? If so, where do
the RTP go?
Bert:
I think it should not be me to take these DISCUSSes,
but they are using (pages 9 and further):
EXAMPLEHOME.COM
EXAMPLEVISITED.COM
Probably they should use
home.example.com
visited.example.com
Possibly this can be fixed with an RFC-Editor note
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Session Initiation Protocol Extension Header
Field for Service Route Discovery During Registration to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Session Initiation Protocol
Extension Header Field for Service Route Discovery During Registration'
<draft-ietf-sip-scvrtdisco-04.txt> as a Proposed Standard. This
document is the product of the Session Initiation Protocol Working
Group. The IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
This document defines a SIP extension header field used in
conjunction with responses to REGISTER requests to provide a
mechanism by which a registrar may inform a registering User
Agent (UA), that is, an end-user, of a service route that the UA
may use to request outbound services from the registrar's domain.
SIP has a Route Header which is used to loose source route
messages, and this Service Route extension allows providers to
offer plans in which a user can ensure that they visit a provider's
proxy at which they registered. IETF protocols should neither favor
nor preclude* such capabilities. Security for the user and the
provider are provided by the use of the SIP sips: address of record
mandating that the hops be carried over TLS, and use of S/MIME for
the bodies in the messages.
Working Group Summary
There was active review. This document was split out from
the other direction, called the PATH header and worked on until
it had adequate clarity and security. Its current version has
good consensus.
Protocol Quality
This document has been reviewed for the IESG by Rohan Mahy and
and Allison Mankin. Some implementations were tested in recent
interoperability events.
To: Internet Engineering Steering Group <iesg@ietf.org>
Fcc: OUTBOX
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-magma-mld-source - Source Address
Selection for Multicast Listener Discovery Protocol (RFC 2710)
to Proposed Standard
--------
Last Call to expire on: 2002-10-25
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ R ]
Ned Freed [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ XX] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [XXX] [ XX] [ X ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Thomas:
> MLD Report and Done messages MUST be sent with a valid link-local
> address as the IPv6 source address. If a valid link-local address is
> not available, the message MUST be sent with the unspecified address
> (::) as the IPv6 source address.
A bit of a nit, but the MUSTs are almost contradictory. It's a bit odd
to say: Do X. Well except if you can't, in which case you do Y. Better
to rewrite something like:
MLD Report and Done messages are sent with a link-local address as
the IPv6 source address, if the one has been assigned to the
interface. If a none exists (e.g., one hasn't been assigned to
the interface yet), the message is sent with the unspecified
address (::) as the IPv6 source address.
nit: RFC 2119 reference should be normative rather than informative.
Finally, the document really could include a bit more context about
why the document exists and what problem is being solved.
Based on some discussions with the author, the exact problem being
solved seems to be:
The rules and desired behavior with regards to receiving multicast
traffic prior to having an IP address need clarification. Before
assigning an LL address to an interface, a node needs to run DAD. But
DAD involves recieving multicast traffic sent to the solicited node
multicast address. But joining a multicast group involves running
MLD. The MLD spec says that MLD messages MUST be sourced from a LL
source address. This is needed even for LL multicast addresses due to
l2 bridge snooping. Thus, clarifications/guidelines regarding the
handling of joining multicast groups when one has no LL address are
needed.
It would be good to get words into the document that explain this
better.
Also, I think it would be good to add some explicit wording to the
document making it clear which rules in 2710 are being changed. I
particular, it would be good to indicate that receivers should not
drop packets with a source address of unspecified.
In general, you might want to say something about what problems have
been encountered in practice from the current wording, and whether
this change will result in different/better/worse behavior.
For example, should an implementation (once it has a valid ll address)
also run MLD again with its new address, to be sure that it
interoperates well with routers that drop packets with a source
address of unspecified?
Russ:
The security considerations say:
The ability to send MLD messages with the unspecified address can
lead to on-link abuse that is harder to trace.
Harder than what? Please clarify.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, magma@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Source Address Selection for Multicast
Listener Discovery Protocol (RFC 2710) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Source Address Selection for
Multicast Listener Discovery Protocol (RFC 2710)'
<draft-ietf-magma-mld-source-02.txt> as a Proposed Standard. This
document is the product of the Multicast & Anycast Group Membership
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
The neighbor discovery specification allows using the unspecified
address as source for certain MLD messages but this is not captured
in the MLD specification. This document updates the MLD specification
with source address rules that are consistent with neighbor discovery.
Working Group Summary
There was WG consensus to advance this document.
Protocol Quality
The document has been reviewed for the IESG by Erik Nordmark.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-mobileip-mipv6-ha-ipsec - Using IPsec
to Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ XX] [ D ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [XXX] [ XX] [ D ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ XX] [ ] [ D ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Randy:
ops-dir comment causes me to register a DISCUSS
randy
---
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue284.txt
and further
From: Greg O'Shea
I have been raising issues on the MobileIP list as I encounter them,
resulting in a number of mods to the spec of which my favourite was
removal of the S bit in binding updates. Of what remains I do not know
of anything that I think warrants delay.
IMHO what is needed most at this point is a stake in the ground (an
initial stable spec.) pending which everyone is sitting painfully
still and holding their breath. Once the base spec is approved I
expect the innovation and serious experimentation will begin afresh
around it.
I do think that the specification could have been simpler, although
this is not a show stopper and once the initial base spec is
approved there may be efforts in this direction. I believe that home
nets and therefore home addresses should be virtual nets e.g. on a
virtual IF on a HA. This means that random hosts cannot directly
attach to the net and interfere with address assignment. In turn this
means that HA need not run DAD before protecting a HoA, the HA need
not protect link-local addresses derived from HoA, NS code is simpler
and in some cases handoff latency is reduced by a second or two. This
idea was well received on the list but has been set aside as future
work.
I am somewhat dubious about the HA discovery and prefix discovery
stuff. At best I think it belongs in a separate doc. It doesn't
achieve much at all with manual keying. But again that is not a show
stopper.
Steve:
Per Steve Kent's comments (see his annotated version of the draft
at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm ),
there seems to be a serious mismatch between the semantics of IPsec
and what is needed by this spec. In particular, the spec demands
special matching and processing rules for input and output packets
that are seriously inconsistent with IPsec. In principle, IPsec might
be changeable in this regard, since the specs are currently undergoing
revision; in practice, I suspect that the changes needed are too great.
In any event, the changes will require the approval of the IPsec
working group.
Beyond that, this spec requires changes to the SPD as the mobile node
roams. That implies a deep coupling between the MobileIP layer and the
IPsec layer. Implementation might be problematic if outboard (i.e.,
NIC-resident) IPsec implementations are used. I would note that these
have been on the market for a couple of years at the least; they're
not hypothetical devices. I suspect that some of these issues might
be resolvable by using IKE and negotiating new Phase 2 associations.
This would rely on the existing API to IPsec, though admittedly it
might require a new interface to IKE.
Kent's much more detailed comments must be addressed, too.
Russ:
Comments:
In section 1, ESP does not provide in order delivery. The introduction
indicates that this service is needed. If this is correct, then
additional protocol mechanisms are needed.
In section 3, in each instance tell whether ESP is used in transport
mode or tunnel mode.
In section 4.1, the document requires support for manual security
association configuration. I think this should be clear that ESP SAs
are being configured, not IKE pre-shared keys. Also, the phrase
"IPsec protection" really means ESP enacpsulation in many different
places.
Steve Kent's comments on section 4.2, 4.3, 5.1, 5.2, and 5.3 need to be
addressed (see http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm
). Since RFC 2401 is being updated, there is an opportunity for
compromise, but the MobileIP and IPsec working groups need to work
together in this area.
In section 4.3, I suggest that all discussion of AH be removed.
In section 4.4, there seems to be confusion about ESP replay
detection. Why not just say that IKE must be used if replay protection
is needed?
COMMENTS:
=========
Ted:
A couple of editorial nits, and three notes, cc'ed only
to Thomas, so as not to clutter the IESG list with
efforts-to-educate-the-newcomer.
Nits:
The Introduction says it illustrates the use of IPsec
in securing control traffic; Section 3.4 describes the
use of IPsec in protecting payload packets tunneled to
the home agent. Since these can be "any protocol",
they are probably not limiting this to control traffic.
"It is important for the home agent to verify that the care-of address
has not been tampered." seems to be missing a with"
"Where <condition> is an boolean expression" should be
"a boolean expression".
Notes:
I was surprised that the manual configuration for security
associations were MUST and IKE only MAY. I assume that
there is lots of history here, and I don't want to draw anyone into
it, but I was surprised.
In section 4.3, I was surprised that the instructions on using
integrity protection with the manually configured SA did not
have a "as of this writing FOO would be the best choice", since
it was willing to toss DES. I'm guessing that this means
different folks have different flavor preferences here.
Section 7's implementation considerations on fragmentation
in the presence of certificates surprised me by recommending
replacing firewalls or routers, given that we're talking about
mobility. Replacing gear in someone else's network is a good
trick.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents'
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt> as a Proposed Standard.
This document is the product of the IP Routing for Wireless/Mobile
Hosts Working Group.
The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. The mobile IPv6 base document defines the
main requirements these nodes must follow. This document discusses
these requirements in more depth, illustrates the used packet
formats, describes suitable configuration procedures, and shows how
implementations can process the packets in the right order.
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.
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-legg-ldapext-component-matching - LDAP &
X.500 Component Matching Rules to Proposed Standard
--------
Last Call to expire on: 2003-6-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [XX ] [ ] [ ] [ D ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ XX] [ ] [ D ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Steve Bellovin:
Does this document need a Stringprep profile per RFC 3454? If not,
I'd think that any applications that use it would need one, which
means that this shoould at least point to 3454. (Unless, of
course, I don't know what I'm talking about, which is quite likely
in this space.)
Russ Housley:
Section 9 includes:
"... because the
component matching rules are applicable to any attribute syntax,
support for them in a directory server may allow searching of
attributes that were previously unsearchable by virtue of there not
being a suitable matching rule. Such attribute types ought to be
properly protected with appropriate access controls."
Access controls cannot be implemented without authentication. How is
authentication achieved? Is there a reference?
Is there a standard mechanism for access control lists? If so reference
it. If not, does this cause interoperability issues?
COMMENTS:
========
Harald Alvestrand:
section 4.2.1.1 is the critical one about string matching - it punts the
whole thing off as "someone else's problem".
this appears to be consistent with the general thrust of LDAP development -
that one needs to redefine the caseIgnore and caseExact matching rules (and
their friends), and that all other docs should just refer to these
definitions. "get it right once".
Editorial nits:
section 1: unusual to number the TOC.
section 2: superfluous comma after "define"
the specifications in sections 4 to 7 of this document make it
possible to fully and precisely define, the LDAP-specific encoding,
the LDAP and X.500 binary encoding
section 4: "formally" should be "formerly"
MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
rule. MATCHING-RULE.&AssertionType is an open type (formally known
as the ANY type).
Ted Hardie:
Steve,
I think this draft takes a slightly different road
than RFC 3454-style stringprep. The way I look at it, stringprep
profiles define a set of steps which must be taken in order
to correctly store a string or compare two strings
within a particular protocol context (from section 1.2 of
RFC 3454). In a sense, it provides a set of mechanisms
that allow you to manipulate a set of data so that well-known
matching rules can be safely (and simply) applied.
This draft takes the other direction--it leaves
the data as is, but uses generic matching rules against
user-identified component parts to allow for
arbitrarily complex attribute matching. Some of those
generic matching rules relate to string matching (section
4.2.1.1 has a list), but they derive from types set up
in draft-legg-gser-abnf, which has both ABNF and
ASN.1 definitions for them. While stringprep profiles
could be used in the definitions of some of the generic
matching rules, I am not sure it is the right fit, since
the actual matches won't fit within the basic stringprep
theory.
If there are more particular problems you have
specific string matching profiles, let me know. Also,
both Harald and Russ have extensive experience here
(certainly much more than mine), and I'd be happy to
have their opinion on how this fits.
regards,
Ted Hardie
At 5:13 PM -0400 6/25/03, Steve Bellovin wrote:
> Yes No-Objection Discuss * Abstain
>
>
>Steve Bellovin [ ] [ ] [ x ] [ ]
>
>Does this document need a Stringprep profile per RFC 3454? If not,
>I'd think that any applications that use it would need one, which
>means that this shoould at least point to 3454. (Unless, of
>course, I don't know what I'm talking about, which is quite likely
>in this space.)
Steve Bellovin:
In message <p06001205bb1fdb74c1ee@[129.46.227.161]>, hardie@qualcomm.com writes
:
>Steve,
> I think this draft takes a slightly different road
>than RFC 3454-style stringprep. The way I look at it, stringprep
>profiles define a set of steps which must be taken in order
>to correctly store a string or compare two strings
>within a particular protocol context (from section 1.2 of
>RFC 3454). In a sense, it provides a set of mechanisms
>that allow you to manipulate a set of data so that well-known
>matching rules can be safely (and simply) applied.
> This draft takes the other direction--it leaves
>the data as is, but uses generic matching rules against
>user-identified component parts to allow for
>arbitrarily complex attribute matching. Some of those
>generic matching rules relate to string matching (section
>4.2.1.1 has a list), but they derive from types set up
>in draft-legg-gser-abnf, which has both ABNF and
>ASN.1 definitions for them. While stringprep profiles
>could be used in the definitions of some of the generic
>matching rules, I am not sure it is the right fit, since
>the actual matches won't fit within the basic stringprep
>theory.
> If there are more particular problems you have
>specific string matching profiles, let me know. Also,
>both Harald and Russ have extensive experience here
>(certainly much more than mine), and I'd be happy to
>have their opinion on how this fits.
I'd like such input, too; any time I comment on this area, I'm skating
on very thin ice indeed. However, on rereading 4.2.1.1 I suspect that
there really is an issue. If I understand 3454 correctly, you can't
even properly compare for equality without normalization. Consider the
case of an LDAP phone book, where one person prepares the entry -- and
hence implicitly selects the software used to encode a person's name --
while another person queries the phone book, using entirely different
software. Without some definition, the proper entry may fail to match.
But as I said, I'm on very shakey ground when I comment on this stuff.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: LDAP & X.500 Component Matching Rules to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAP & X.500 Component
Matching Rules' <draft-legg-ldapext-component-matching-11.txt> as a
Proposed Standard. This has been reviewed in the IETF but is not the
product of an IETF Working Group. The IESG contact persons are Ted
Hardie and Ned Freed.
Technical Summary
The structure or data type of data held in an attribute of an LDAP
or X.500 directory is described by the attribute's
syntax. Attribute syntaxes range from simple data types, such as
text string, integer, or boolean, to complex data types, for example,
the syntaxes of the directory schema operational attributes.
In LDAP, the attribute syntaxes are usually described by ABNF
though there is an implied association between the LDAP attribute
syntaxes and the X.500 ASN.1 types. To a large extent, the data
types of attribute values in either an LDAP or X.500 directory are
described by ASN.1 types. This formal description can be exploited
to identify component parts of an attribute value for a variety of
purposes. This document addresses attribute value matching.
Working Group Summary
Though this work was brought to the LDAPEXT working group
during the group's lifetime, the draft was not forwarded by
the working group before it shut down. The author continued
to work on it as an individual submission.
Protocol Quality
This document was reviewed by the LDAP directorate; there were
also significant last call comments, resulting in a revision of the
document.
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-sipping-3gpp-r5-requirements -
3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)
--------
DISCUSSES AND COMMENTS:
======================
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <sipping@ietf.org>
Subject: Document Action: 3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol (SIP)
to an Informatinal RFC
------------------------
The IESG has approved the Internet-Draft '3rd-Generation Partnership Project
(3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)'
<draft-ietf-sipping-3gpp-r5-requirements-00.txt> as an Informatinal RFC.
This document is the product of the Session Initiation Proposal Investigation
Working Group.
The IESG contact persons are A. Mankin and J. Peterson
Proposed Note:
The document "3rd-Generation Partnership Project (3GPP) Release 5
requirements on the Session Initiation Protocol (SIP)" is advisory in
nature. Its primary purpose is to help the IETF understand the IMS
environment and the manner in which 3GPP envisions using SIP within
that environment. Given this better understanding, we expect that the
IETF can more effectively evolve the SIP protocol. The IETF will not
respond to the requirements given in this document on a
point-for-point basis. Some requiremements have been and/or will be
met by extensions to the SIP protocol. Others may be addressed by
effectively using existing capabilities in SIP or other protocols,
and we expect that individual members of the SIP community will work
with 3GPP to achieve a better understanding of these mechanisms. Some
of the requirements documented in this document may not = be addressed
at all by the IETF, although we believe that the act of documenting
and discussing them is in itself helpful in achieving a better
all-around understanding of the task at hand.
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-manet-olsr -
Optimized Link State Routing Protocol
--------
DISCUSSES AND COMMENTS:
======================
Russ:
In section 20.1, I asked the authors to provide a reference to at least
one "regular cryptographic technique" for confidentiality. The authors
included a reference to PGP. PGP is traditionally used at the application
layer. I expected a reference to IPsec ESP, which does include support for
multicast traffic. If PGP is a better fit in this situation, it deserves
explanation.
In section 20.2, I asked for an explanation of "Authenticated signatures
on control messages." Which resulted in the following text:
An important consideration is, that all control messages in OLSR are
transmitted either to all nodes in the neighborhood (HELLO messages)
or broadcast to all nodes in the network (e.g. TC messages). I.e.
a control message in OLSR is always a point-to-multipoint
transmission. It is therefore important that the authentication
mechanism employed permits that any receiving node can validate the
authenticity of a message. As an analogy, given a block of text,
signed by a PGP private key, then anyone with the corresponding
public key can verify the authenticiy of the text.
Please correct the spelling of authenticity.
Again, PGP does not seem like the correct mechanism. Further, a message
authentication code is acceptable if the source needs to be limited to the
collection of nodes that know the key. IPsec ESP provides this service in
a multicast environment. If the node must know the precise source of each
control message, then a digital signature is probably going to be
needed. The work on SBGP may offer a way forward in this area.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <manet@ietf.org>
Subject: Document Action: 'Optimized Link State Routing Protocol'
to an Experimental RFC
------------------------
The IESG has no problem with the publication of the Internet-Draft
'Optimized Link State Routing Protocol' <draft-ietf-manet-olsr-11.txt> as
an Experimental RFC. This document is the product of the Mobile Ad-hoc
Networks Working Group.
The IESG contact person is Zinin, Alex.
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
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-siemborski-mupdate -
The MUPDATE Distributed Mailbox Database Protocol
--------
DISCUSSES AND COMMENTS:
======================
Russ Housley:
Comment:
Turn off hyphenation.
In section 8.8, the protocol allows as list of authentication
mechanisms, even if TLS is not in use. Without the integrity provided by
TLS, an adversary can reorder the list of mechanisms. One solution would
be to limit the list to a single item when TLS is not in use.
How was port 2004 assigned?
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>
Subject: Document Action: 'The MUPDATE Distributed Mailbox
Database Protocol' to an Experimental RFC
------------------------
The IESG has no problem with the publication of the Internet-Draft 'The
MUPDATE Distributed Mailbox Database Protocol'
<draft-siemborski-mupdate-04.txt> as an Experimental RFC. This has been
reviewed in the IETF but is not the product of an IETF Working Group.
The IESG contact person is Freed, Ned.
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-sun-handle-system -
Handle System Overview
--------
DISCUSSES AND COMMENTS:
======================
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>
Subject: Document Action: Handle System Overview to an Informatinal RFC
------------------------
The IESG has approved the Internet-Drafts
* 'Handle System Overview'
<draft-sun-handle-system-11.txt>
* 'Handle System Protocol (ver 2.1) Specification'
<draft-sun-handle-system-protocol-05.txt>
* 'Handle System Namespace and Service Definition'
<draft-sun-handle-system-def-08.txt>
as an Informatinal RFC. This has been reviewed in the IETF but is not
the product of an IETF Working Group.
The IESG contact person is Ted Hardie
Proposed IESG note:
Several groups within the IETF and IRTF have the discussed the
Handle system and its relationship to existing systems of
identifiers. The IESG wishes to point out that these discussions
have not resulted in IETF consensus on the described Handle system
nor on how it might fit into the IETF architecture for identifiers. Though
there has been discussion of handles as a form of URI, specifically
as a URN, these documents describe an alternate view of how namespaces
and identifiers might work on the Internet and include characterizations
of existing systems which may not match the IETF consensus view.