[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Alternate Agenda and Package for July 10, 2003 Telechat (2nd 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-atommib-atm2-19.txt
Definitions of Supplemental Managed Objects for ATM Interface (Proposed
Standard) - 1 of 10
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) - 2 of 10
Token: Wijnen, Bert
Note: On IESG agenda for July 10th<br>Responsible: Bert
o draft-ietf-policy-qos-info-model-05.txt
Policy QoS Information Model (Proposed Standard) - 3 of 10
Token: Wijnen, Bert
Note: On IESG Agenda for July 10th<br>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) - 4 of 10
Token: Mankin, Allison
o draft-ietf-ips-fcip-slp-07.txt
Finding FCIP Entities Using SLPv2 (Proposed Standard) - 5 of 10
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) - 6 of 10
Token: Mankin, Allison
o draft-ietf-dnsext-rfc1886bis-03.txt
DNS Extensions to support IP version 6 (Draft Standard) - 7 of 10
Token: Nordmark, Erik
Note: Please put on agenda.
o draft-ietf-ospf-hitless-restart-07.txt
Graceful OSPF Restart (Proposed Standard) - 8 of 10
Token: Zinin, Alex
o draft-ietf-webdav-ordering-protocol-09.txt
WebDAV Ordered Collections Protocol (Proposed Standard) - 9 of 10
Token: Hardie, Ted
o draft-ietf-avt-rtcp-report-extns-06.txt
RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard) -
10 of 10
Token: Mankin, Allison
2.1.2 Returning Item
o draft-ietf-dnsext-gss-tsig-06.txt
GSS Algorithm for TSIG (GSS-TSIG) (Proposed Standard) - 1 of 7
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.<br>
o draft-katz-yeung-ospf-traffic-10.txt
Traffic Engineering Extensions to OSPF Version 2 (Proposed Standard) -
2 of 7
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) - 3 of 7
Token: Nordmark, Erik
Note: Version 06 seems to satisfy discusses. Check if this<br>is the
case.<br>
o draft-ietf-enum-rfc2916bis-06.txt
The E.164 to URI DDDS Application (ENUM) (Proposed Standard) - 4 of 7
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) - 5 of 7
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) - 6 of 7
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) - 7
of 7
Token: Nordmark, Erik
Note: 06 has replaced IANA considerations with<br>"no
considerations".<br>
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 3
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 3
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 3
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) - 1 of 4
Token: Housley, Russ
o draft-ietf-ippm-owdp-reqs-06.txt
A One-way Active Measurement Protocol Requirements (Informational) - 2
of 4
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.<br>
o draft-ietf-manet-olsr-11.txt
Optimized Link State Routing Protocol (Experimental) - 3 of 4
Token: Zinin, Alex
o draft-ietf-crisp-requirements-05.txt
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational) - 4 of 4
Token: Freed, Ned
Note: Asked to be added to IESG agenda
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
NONE
3.3.2 Returning 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<br>IESG
Note attached (originally drafted by Patrik): IESG NOTE: The IETF and
IRTF have discussed the Handle system in the realm<br>of URI-related
work. The IESG wishes to point out that there<br>is no IETF
consensus on the current Handle system nor on<br>where it fits in the
IETF architecture. The IESG is of the view that<br>the Handle
system would be able to, with very small changes,<br>fit into the IETF
architecture as a URN namespace. These documents,<br>however,
contain information on the Handle system without these changes.
o draft-bradner-pbk-frame-06.txt
A Framework for Purpose-Built Keys (PBK) (Informational) - 2 of 3
Token: Bellovin, Steve
o draft-leech-chinese-lottery-04.txt
Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking
Tool (Informational) - 3 of 3
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 10
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 [ ] [ 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:
======================
^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 - 2 of 10
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
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 [ ] [ ] [ ] [ ]
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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 10
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
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 [ ] [ ] [ ] [ ]
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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 10
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 - 5 of 10
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 - 6 of 10
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 - 7 of 10
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 - 8 of 10
o draft-ietf-ospf-hitless-restart-07.txt
Graceful OSPF Restart (Proposed Standard)
Token: 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-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 [ ] [ ] [ ] [ ]
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:
======================
^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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 9 of 10
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 - 10 of 10
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 7
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..
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
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 7
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
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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 3 of 7
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.<br>
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.
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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 4 of 7
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 - 5 of 7
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 [ 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.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 6 of 7
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 - 7 of 7
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".<br>
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 3
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 3
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.
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.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 3 of 3
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.2 Returning Item - 1 of 4
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
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 4
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 - 3 of 4
o draft-ietf-manet-olsr-11.txt
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 4 of 4
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
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
--------
Last Call to expire on: 0000-00-00
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 [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
>From: hardie@qualcomm.com
>To: Steve Bellovin <smb@research.att.com>, iesg-secretary@ietf.org
>Subject: Re: evaluation: draft-ietf-crisp-requirements
Steve,
This is meant to be covered by this text:
3.1.4.1 Protocol Requirement
The protocol MUST NOT prohibit an operator from granularly assigning
multiple types of access to data according to the policies of the
operator. The protocol MUST provide an authentication mechanism and
MUST NOT prohibit an operator from granting types of access based on
authentication.
The protocol MUST provide an anonymous access mechanism that may be
turned on or off based on the policy of an operator.
Since these protocol requirements apply only to distributing
information, there is no place in it for the client to express
privacy preferences about the data (indeed, that's likely to be covered
by EPP).
regards,
Ted
>From: hardie@qualcomm.com
>To: mankin@psg.com, iesg@ietf.org
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt
At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>Overall this is a very well-written spec. One transport issue and two
>questions about scope - perfectly reasonable answers are out of scope,
>or already discussed and dismissed.
>
>1.
>
>The protocol MUST
> define one or more transport mechanisms for mandatory implementation.
> ^congestion-aware or overload-aware
>
>I realize that the transport choice could be UDP, but in that case,
>congestion-aware would mean UDP without aggressive retransmission.
>And in the case that that "transport" may be used here to mean a
>higher layer protocol such as mail or http, then the term
>overload-aware applies.
Speaking as one of the chairs, this change should be uncontroversial,
so an RFC editor note could cover it.
>2.
>
>Is it out of scope for there to be a requirement in the protocol for
>the registry to be able to authenticate itself to the client, because
>in some cases there could be falsified registries?
3.1.9 covers the protocol and service descriptions here; the wg
did discuss the various use case scenarios. The result was:
must be able to authenticate itself, but does not require that
for operation of a CRISP server.
If you have further issues, I'd be happy to discuss it with you,
or set up a call with the author.
>3.
>
>Is it out of scope for there to be a requirement on the protocol for
>some support for authentication of the contact information?
This would have to be covered by the requirements on the protocol
that populates the data. A distribution protocol is pretty much too late
in the game to put in requirements for authenticating the contact
information that _has_been_populated.
>To: hardie@qualcomm.com
>Subject: Re: evaluation: draft-ietf-crisp-requirements
>From: "Steven M. Bellovin" <smb@research.att.com>
In message <p06001201bb20c6217d42@[129.46.227.161]>, hardie@qualcomm.com writes
:
>Steve,
> This is meant to be covered by this text:
>
>3.1.4.1 Protocol Requirement
>
> The protocol MUST NOT prohibit an operator from granularly assigning
> multiple types of access to data according to the policies of the
> operator. The protocol MUST provide an authentication mechanism and
> MUST NOT prohibit an operator from granting types of access based on
> authentication.
>
> The protocol MUST provide an anonymous access mechanism that may be
> turned on or off based on the policy of an operator.
>
> Since these protocol requirements apply only to distributing
>information, there is no place in it for the client to express
>privacy preferences about the data (indeed, that's likely to be covered
>by EPP).
Not very explicit, and authentication isn't the same as authorization.
But what attracted my attention was 3.1.3, which talks about tagging
data. What I'm asking about is language about privacy-related tags, or
use of tags for privacy purposes. That was the big hangup with the EPP
document, as I recall.
At 9:25 AM -0400 6/26/03, Steve Bellovin wrote:
>I think there should be some requirement that data be taggable to meet
>privacy requirements. We just went through this a few months ago.
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com (2nd edition of "Firewalls" book)
>From: Leslie Daigle <leslie@thinkingcat.com>
>To: hardie@qualcomm.com
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt
Speaking as a WG participant:
hardie@qualcomm.com wrote:
> At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>
>> Overall this is a very well-written spec. One transport issue and two
>> questions about scope - perfectly reasonable answers are out of scope,
>> or already discussed and dismissed.
>>
>> 1.
>>
>> The protocol MUST
>> define one or more transport mechanisms for mandatory implementation.
>> ^congestion-aware or overload-aware
>>
>> I realize that the transport choice could be UDP, but in that case,
>> congestion-aware would mean UDP without aggressive retransmission.
>> And in the case that that "transport" may be used here to mean a
>> higher layer protocol such as mail or http, then the term
>> overload-aware applies.
>
>
>
> Speaking as one of the chairs, this change should be uncontroversial,
> so an RFC editor note could cover it.
I believe the intention of the requirement is to be an
*application* transport. I.e., beep, http, etc.
Leslie.
^L
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>,
<ietf-not43@lists.verisignlabs.com>
Subject: Document Action: Cross Registry Internet Service Protocol (CRISP)
Requirements to an Informatinal RFC
------------------------
The IESG has approved the Internet-Draft 'Cross Registry Internet Service
Protocol (CRISP) Requirements' <draft-ietf-crisp-requirements-05.txt> as an
Informatinal RFC. This document is the product of the Cross Registry Information
Service Protocol Working Group.
The IESG contact persons are Ned Freed and Ted Hardie
3. 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.3.1 New Item
NONE
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.2 Returning 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<br>of URI-related
work. The IESG wishes to point out that there<br>is no IETF
consensus on the current Handle system nor on<br>where it fits in the
IETF architecture. The IESG is of the view that<br>the Handle
system would be able to, with very small changes,<br>fit into the IETF
architecture as a URN namespace. These documents,<br>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)
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.
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.2 Returning Item - 2 of 3
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 - 3 of 3
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