[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Alternate Agenda and Package for July 10, 2003 Telechat (First Draft)
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the July 10, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
o Review of Action Items
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-dnsext-gss-tsig-06.txt
GSS Algorithm for TSIG (GSS-TSIG) (Proposed Standard) - 1 of 12
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) -
2 of 12
Token: Fenner, Bill
Note: Last Call sent per Alex Zinin's request
o draft-ietf-atommib-atm2-19.txt
Definitions of Supplemental Managed Objects for ATM Interface (Proposed
Standard) - 3 of 12
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) - 4 of 12
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) - 5 of 12
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) - 6 of 12
Token: Mankin, Allison
o draft-ietf-ips-fcip-slp-07.txt
Finding FCIP Entities Using SLPv2 (Proposed Standard) - 7 of 12
Token: Mankin, Allison
Note: SLP details were expert-reviewed (mediated by Thomas Narten)
o draft-ietf-sipping-3pcc-04.txt
Best Current Practices for Third Party Call Control in the Session
Initiation Protocol (BCP) - 8 of 12
Token: Mankin, Allison
o draft-ietf-dnsext-rfc1886bis-03.txt
DNS Extensions to support IP version 6 (Draft Standard) - 9 of 12
Token: Nordmark, Erik
Note: Please put on agenda.
o draft-ietf-ospf-hitless-restart-07.txt
Graceful OSPF Restart (Proposed Standard) - 10 of 12
Token: Zinin, Alex
o draft-ietf-webdav-ordering-protocol-09.txt
WebDAV Ordered Collections Protocol (Proposed Standard) - 11 of 12
Token: Hardie, Ted
o draft-ietf-avt-rtcp-report-extns-06.txt
RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard) -
12 of 12
Token: Mankin, Allison
2.1.2 Returning Item
o draft-ietf-dnsext-ad-is-secure-06.txt
Redefinition of DNS AD bit (Proposed Standard) - 1 of 5
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) - 2 of 5
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) - 3 of 5
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) - 4 of 5
Token: Nordmark, Erik
Note: Document has been updated to address concerns from Thomas and
Russ.
o draft-ietf-dnsext-unknown-rrs-06.txt
Handling of Unknown DNS Resource Record Types (Proposed Standard) - 5
of 5
Token: Nordmark, Erik
Note: 06 has replaced IANA considerations with "no
considerations".
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) - 1 of 1
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) - 1
of 4
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) - 2 of 4
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) - 3 of 4
Token: Zinin, Alex
o draft-ietf-atommib-atm2-19.txt
Definitions of Supplemental Managed Objects for ATM Interface (Proposed
Standard) - 4 of 4
Token: Nordmark, Erik
Note: Please put on the IESG agenda.
3.1.2 Returning Item
o draft-ietf-ippm-owdp-reqs-06.txt
A One-way Active Measurement Protocol Requirements (Informational) - 1
of 2
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) - 2 of 2
Token: Zinin, Alex
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o draft-siemborski-mupdate-04.txt
The MUPDATE Distributed Mailbox Database Protocol (Experimental) - 1 of
1
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
o draft-sun-handle-system-11.txt
Handle System Overview (Informational) - 1 of 3
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.
o draft-sun-handle-system-protocol-05.txt
Handle System Protocol (ver 2.1) Specification (Informational) - 2 of 3
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.
o draft-sun-handle-system-def-08.txt
Handle System Namespace and Service Definition (Informational) - 3 of 3
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.
3.3.2 Returning Item
o draft-bradner-pbk-frame-06.txt
A Framework for Purpose-Built Keys (PBK) (Informational) - 1 of 2
Token: Bellovin, Steve
o draft-leech-chinese-lottery-04.txt
Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking
Tool (Informational) - 2 of 2
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)
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, June 26, 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---Will call in
Steve Bellovin---Will call in
Randy Bush---Will call in
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---Will call in
Joyce K. Reynolds---Will call in
Bert Wijnen---Regrets
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
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
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. 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.
2. Review of Action Items
DONE:
o Allison and Thomas will email Secretariat note to send to RFC Editor about 3GPP
RFC Editor documents.
o Ned to write an IESG note for draft-tegen-smqp (Informational)
o 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.
o Secretariat to include teleconference bridge/call-in details in teleconference
packages going forward.
DELETED:
o Steve to generate a summary of IESG views of the "problem"
OUTSTANDING:
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 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 propose a different document classification than the current
info/proposed/etc.
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 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 :
o 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.
o Steve Bellovin to make proposal to discuss "problem" at the Sunday IESG meeting
in Vienna.
o 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 - 1 of 3
o draft-ietf-enum-rfc2916bis-06.txt
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. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 3
o draft-ietf-avt-srtp-08.txt
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 Russ Housley.
o draft-ietf-sipping-overlap-04.txt - 2 of 3
Mapping of 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 Protocol Action Announcement.
o draft-ietf-ccamp-lmp.txt - 3 of 3
Link Management Protocol (LMP).
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. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 1 of 1
o draft-legg-ldapext-component-matching-10.txt
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 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 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.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item -
o draft-ietf-v6ops-unman-scenarios-02.txt - 7of 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. Document Actions
3.1 WG Submissions
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 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 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 Document Action Announcement.
3. Document Actions
3.2 Indiviual 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 a Document Action Announcement that includes
the RFC Editor Note.
3.2.2 Returning Item
NONE
3. Document Actions
3.3 Indiviual 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 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: 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: Thomas
See decision under Layer 2 Virtual Private Networks
4.1.2 Proposed for Approval - 3 of 3
o Path Maximum Transmission Unit Discovery
Token: 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. Working Group Actions
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)
1. Administrivia
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 - 1 of 12
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..
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 2 of 12
o draft-katz-yeung-ospf-traffic-10.txt
Traffic Engineering Extensions to OSPF Version 2 (Proposed Standard)
Token: Fenner, Bill
Note: Last Call sent per Alex Zinin's request
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.
^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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 12
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.
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 [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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:
======================
^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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 12
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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 5 of 12
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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 6 of 12
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
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 [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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>, 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].
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 7 of 12
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)
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 [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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>, 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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 8 of 12
o draft-ietf-sipping-3pcc-04.txt
Best Current Practices for Third Party Call Control in the Session
Initiation Protocol (BCP)
Token: Mankin, Allison
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 [ ] [ ] [ ] [ ]
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>, 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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 9 of 12
o draft-ietf-dnsext-rfc1886bis-03.txt
DNS Extensions to support IP version 6 (Draft Standard)
Token: Nordmark, Erik
Note: Please put on agenda.
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 [ ] [ ] [ ] [ ]
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:
======================
^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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 10 of 12
o draft-ietf-ospf-hitless-restart-07.txt
Graceful OSPF Restart (Proposed Standard)
Token: Zinin, Alex
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 11 of 12
o draft-ietf-webdav-ordering-protocol-09.txt
WebDAV Ordered Collections Protocol (Proposed Standard)
Token: Hardie, Ted
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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 12 of 12
o draft-ietf-avt-rtcp-report-extns-06.txt
RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard)
Token: Mankin, Allison
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 [ ] [ ] [ ] [ ]
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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 5
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.
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 [ ] [XX ] [ X ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 5
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.
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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 3 of 5
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.
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 [ ] [ ] [ 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-02.txt> as a Proposed Standard. This
document is the product of the Session Initiation Protocol Working
Group. The IESG contact persons are Scott Bradner 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 loosely 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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 4 of 5
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.
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 [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ 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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 5 of 5
o draft-ietf-dnsext-unknown-rrs-06.txt
Handling of Unknown DNS Resource Record Types (Proposed Standard)
Token: Nordmark, Erik
Note: 06 has replaced IANA considerations with. "no
considerations".
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-unknown-rrs - Handling of
Unknown DNS Resource Record Types to Proposed Standard
--------
Last Call to expire on: 2003-4-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ X ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [XX ] [ X ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Steve:
It's clearly necessary to have something like that, but frankly,
the document scares me; it retroactively changes the behavior
required for older RFCs. I sure with Mockapetris had thought of
saying this.
Am I offbase? Is this much better -- or much worse -- than I fear?
Russ:
Please change "RFC TBD" to "this specification." I believe that it
will be easier for the reader.
Jon:
> Jon Peterson [ ] [ ] [ x ] [ ]
Does this document place too great a burden on the IANA? The IANA
Considerations require IANA to enforce the policy described in the
second-to-last paragraph of Section 4, I gather, which entails pretty deep
knowledge of the mechanics of a new RR - significantly more than just
verifying whether or not the RR name has been taken, or what have you. The
policy for name compression in RDATA definitely makes sense, but I suspect
IANA isn't the right body to analyze new RR proposals and enforce that
policy. Perhaps it would be better if the IESG, or an Expert Reviewer, or
something along those lines were identified as the enforcer of the name
compression policy.
^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: Handling of Unknown DNS Resource Record
Types to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Handling of Unknown DNS
Resource Record Types' <draft-ietf-dnsext-unknown-rrs-05.txt> as a
Proposed Standard. This document is the product of the DNS Extensions
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
Extending the Domain Name System with new Resource Record (RR) types
currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations
to handle new RR types transparently.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The specification has been reviewed for the IESG by Erik Nordmark.
2.2.1 New Item
NONE
2. Protocol Actions
2.2 Individual Submissions
2.2.2 Returning Item - 1 of 1
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.
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 [ ] [ ] [ ] [ 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:
========
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.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 4
o draft-ietf-gsmp-reqs-06.txt
Requirements For Adding Optical Support To GSMPv3 (Informational)
Token: Wijnen, Bert
Note: Responsible: Bert Wijnen
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 4
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.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 3 of 4
o draft-ietf-manet-tbrpf-09.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Zinin, Alex
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 4 of 4
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.
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 2
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..
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 2
o draft-ietf-manet-olsr-11.txt
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
3. Document Actions
3.2 Indiviual Submissions Via AD
3.2.1 New Item - 1 of 1
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. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item - 1 of 3
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.
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item - 2 of 3
o draft-sun-handle-system-protocol-05.txt
Handle System Protocol (ver 2.1) Specification (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.
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item - 3 of 3
o draft-sun-handle-system-def-08.txt
Handle System Namespace and Service Definition (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.
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.2 Returning Item - 1 of 2
o draft-bradner-pbk-frame-06.txt
A Framework for Purpose-Built Keys (PBK) (Informational)
Token: Bellovin, Steve
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.2 Returning Item - 2 of 2
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. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
Harald Alvestrand
Steve Bellovin
Randy Bush
Bill Fenner
Ned Freed
Ted Hardie
Russ Housley
Allison Mankin
Thomas Narten
Erik Nordmark
Jon Peterson
Bert Wijnen
Alex Zinin
6. IAB News We Can Use
7. Management Issues