[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for October 2, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the October 2, 2003 IESG Teleconference
This agenda was generated at 16:3:4 EDT, September 26, 2003
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
o Review of Action Items
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-disman-conditionmib-10.txt
Alarm Reporting Control MIB (Proposed Standard) - 1 of 9
Note: IESG evaluation
Token: Bert Wijnen
o draft-ietf-rmonmib-apm-mib-11.txt
Application Performance Measurement MIB (Proposed Standard) - 2 of 9
Note: Ready for IESG Evaluation.. No IETF Last Call comments received.
Token: Bert Wijnen
o draft-ietf-ipsec-rfc2402bis-05.txt
IP Authentication Header (Proposed Standard) - 3 of 9
Token: Russ Housley
o draft-ietf-ipsec-esn-addendum-02.txt
Extended Sequence Number Addendum to IPsec DOI for ISAKMP (Proposed
Standard) - 4 of 9
Token: Russ Housley
o draft-ietf-ipsec-esp-v3-06.txt
IP Encapsulating Security Payload (ESP) (Proposed Standard) - 5 of 9
Token: Russ Housley
o draft-ietf-dnsext-keyrr-key-signing-flag-09.txt
KEY RR Secure Entry Point Flag (Proposed Standard) - 6 of 9
Note: Some editorial nits, can be folded in with IESG review.
Token: Thomas Narten
o draft-ietf-ldup-lcup-06.txt
LDAP Client Update Protocol (Proposed Standard) - 7 of 9
Token: Ted Hardie
o draft-ietf-nomcom-rfc2727bis-07.txt
IAB and IESG Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees (BCP) - 8 of 9
Token: Harald Alvestrand
o draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt
KDC Server Address Sub-option (Proposed Standard) - 9 of 9
Token: Margaret Wasserman
2.1.2 Returning Item
o draft-ietf-ftpext-mlst-16.txt
Extensions to FTP (Proposed Standard) - 1 of 3
Token: Ted Hardie
o draft-ietf-dhc-isnsoption-10.txt
The IPv4 DHCP Options for the Internet Storage Name Service (Proposed
Standard) - 2 of 3
Note: Note: new version (-10) should address outstanding discusses.
Token: Thomas Narten
o draft-ietf-avt-mpeg4-simple-08.txt
RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed
Standard) - 3 of 3
Note: On agenda again to check if mods from MPEG4 group to language
about ECMAscript risks are ok for clearing SMB's Discuss - there was
agreed language during Vienna but it needed a little modification.
Token: Allison Mankin
2.2 Individual Submissions
2.2.1 New Item
o draft-zeilenga-ldap-rfc2596-04.txt
Language Tags and Ranges in LDAP (Proposed Standard) - 1 of 1
Token: Ted Hardie
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-isis-igp-p2p-over-lan-03.txt
Point-to-point operation over LAN in link-state routing protocols
(Informational) - 1 of 2
Note: On agenda for 2003-10-02 telechat
Token: Bill Fenner
o draft-ietf-magma-msf-api-05.txt
Socket Interface Extensions for Multicast Source Filters
(Informational) - 2 of 2
Token: Margaret Wasserman
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-newton-ldap-whois-04.txt
Whois Domain Data using the Lightweight Directory Access Protocol
(LDAP) (Experimental) - 1 of 2
Token: Ted Hardie
o draft-gill-gtsh-01.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental) - 2 of 2
Token: Alex Zinin
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Long-Term Archive and Notary Services (ltans) - 1 of 1
Token: Russ
4.1.2 Proposed for Approval
o Centralized Conferencing (xcon) - 1 of 1
Token: Description
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Audio/Video Transport (avt) - 1 of 4
Token: Allison
o DNS Extensions (dnsext) - 2 of 4
Token: Thomas
o Common Control and Measurement Plane (ccamp) - 3 of 4
Token: Alex
o Ethernet Interfaces and Hub MIB (hubmib) - 4 of 4
Token: Bert
4.2.2 Proposed for Approval
NONE
5. Agenda Working Group News
6. IAB News We can use
7. Management Issue
7.1 Appropriate Methods for getting Meeting Minutes from Chairs (Harald Alvestrand)
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
7.3 Referral of draft-klensin-name-filters-03.txt to the IAB (Ted Hardie)
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the October 2, 2003 IESG Teleconference
This package was generated at 16:3:5 EDT, September 26, 2003.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, October 2,
2003 from 11:30-14:00 US-ET. If you are *unable* to participate in the
teleconference, or if you wish to change your usual procedures for
connecting to the call (as indicated in the list below), then please reply
to this message as follows:
o If you are unable to participate, then please write "Regrets" after your
name.
o If you normally call in, but will require operator assistance for this
teleconference, then please provide the telephone number where you can be
reached.
o If you are normally connected to the teleconference by an operator, but
will call in for this teleconference, then please write "Will call in"
next to your name in place of the telephone number.
Harald Alvestrand---Will call in
Rob Austein---Will call in
Steve Bellovin---Will call in
Randy Bush--- Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten--- Will call in
Jon Peterson---Will call in
Joyce K. Reynolds---Regrets
Dinara Suleymanova--- Will call in
Amy Vezza---Will call in
Margaret Wasserman---Will call in
Bert Wijnen---Will call in
Alex Zinin---Will call in
To join the teleconference, please call the appropriate dial-in number
(see below) at 11:30 AM ET. If you have requested operator assistance,
then an operator will call you and connect you to the call. Participants
inside the U.S. should use the toll-free number 888-315-1685.
Participants outside the U.S. should use either one of the toll-free
numbers listed at the end of this message, or the direct-dial number
703-788-0617. Participants using the direct-dial number will pay their own
long distance charges through their own carriers. Participants dialing the
toll-free number will not pay any charges for the conference, as all
charges, including long distance, will be included on the invoice sent to
the company hosting the call. In some cases, participants from certain
international countries may only use a direct-dial number.
All participants should enter the passcode 235467 when prompted to do so.
The first person on the call will not hear anything until joined by other
participants. A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND
THUS INCUR CHARGES FROM THEIR OWN CARRIER.
1.2 Bash the Agenda
1.3 Approval of the Minutes
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the September 18, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Michelle Cotton / ICANN
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
Thomas Narten / IBM
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Jennifer Rodriguez / ICANN
Dinara Suleymanova / IETF Secretariat
Amy Vezza / IETF Secretariat
Margaret Wasserman / Wind River
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Randy Bush / IIJ
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the September 4, 2003 Teleconference were approved.
The Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Thomas Narten will send his comments on Creating, Rechartering
and Closing a Working Group to the IESG mailing list.
o Harald Alvestrand will send a proposed authentication method for
Liaison Statement submission to the Secretariat.
o Steve Bellovin will draft a message to the RFC Editor regarding
the early assignment of an RFC number for draft-housley-ccm-mode.
DELETED:
o Steve Bellovin to propose a different document classification
than the current info/proposed/etc.
IN PROGRESS:
o Jon Peterson to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Thomas Narten to write (or cause to be written) a draft on "how
to get to Draft".
o Thomas Narten to contact Cablelabs to discuss formal relationship
with IAB.
o Steve Bellovin to write RFC re: TCP MD5 option.
o Randy Bush and Ned Freed to finish ID on Clarifying when
Standards Track Documents may Refer Normatively to Documents at
a Lower Level.
o Alex Zinin to send proposal and justification for interim
document review.
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.
NEW:
o Bill Fenner, Ted Hardie, and Thomas Narten to work out acceptable
text to resolve ABNF and SRV issues.
o Harald Alvestrand to consult with Randy Bush and make sure a policy
is generated regarding interoperability testing at IETF Meetings.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-iptel-trip-mib-08.txt - 1 of 6
Management Information Base for Telephony Routing over IP (TRIP) (Proposed Standard)
Token: Jon Peterson
The document remains under discussion by the IESG in order to resolve
points raised by Margaret Wasserman.*
o Two-document ballot: - 2 of 6
- draft-ietf-sacred-framework-06.txt
Securely Available Credentials - Credential Server Framework (Informational)
- draft-ietf-sacred-protocol-bss-08.txt
Securely Available Credentials Protocol (Proposed Standard)
Token: Steve Bellovin
The documents remain under discussion by the IESG in order to resolve
points raised by Russ Housley.*
o draft-ietf-mobileip-aaa-nai-06.txt - 3 of 6
AAA NAI for Mobile IPv4 Extension (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin and Ted Hardie.*
o draft-ietf-pkix-logotypes-11.txt - 4 of 6
Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates (Proposed Standard)
Token: Steve Bellovin
The document remains under discussion by the IESG in order to resolve
points raised by Harald Alvestrand, Ned Freed, Ted Hardie, Margaret
Wasserman, and Bert Wijnen.*
o draft-iab-isocbot-00.txt - 5 of 6
IETF ISOC Board of Trustee Appointment Procedures (BCP)
Token: Harald Alvestrand
The document remains under discussion by the IESG in order to resolve
points raised by Thomas Narten.*
o Three-document ballot: - 6 of 6
- draft-ietf-mpls-ldp-mib-13.txt
Definitions of Managed Objects for the Multiprotocol Label Switching,
Label Distribution Protocol (LDP) (Proposed Standard)
- draft-ietf-mpls-ftn-mib-08.txt
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next
Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base (Proposed Standard)
- draft-ietf-mpls-te-mib-12.txt
Multiprotocol Label Switching (MPLS) Traffic Engineering Management
Information Base (Proposed Standard)
Token: Alex Zinin
The documents remain under discussion by the IESG in order to resolve
points raised by Bert Wijnen.*
2.1.2 Returning Item
o Five-document ballot: - 1 of 2
- draft-ietf-impp-cpim-msgfmt-08.txt
Common Presence and Instant Messaging: Message Format (Proposed Standard)
- draft-ietf-impp-cpim-pidf-08.txt
Presence Information Data Format (PIDF) (Proposed Standard)
- draft-ietf-impp-pres-03.txt
Common Profile for Presence (CPP) (Proposed Standard)
- draft-ietf-impp-im-03.txt
Common Profile for Instant Messaging (CPIM) (Proposed Standard)
- draft-ietf-impp-srv-03.txt
Address Resolution for Instant Messaging and Presence (Proposed Standard)
Token: Ted Hardie
The documents remain under discussion by the IESG in order to resolve
points raised by Bill Fenner and Thomas Narten.*
o draft-ietf-webdav-ordering-protocol-10.txt - 2 of 2
WebDAV Ordered Collections Protocol (Proposed Standard)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
2.2 Individual Submissions
2.2.1 New Item
o draft-mrose-ietf-posting-03.txt - 1 of 1
A Practice for Revoking Posting Rights to IETF mailing lists (BCP)
Token: Steve Bellovin
The document remains under discussion by the IESG in order to resolve
points raised by Russ Housley and Thomas Narten.*
2.2.2 Returning Item
o draft-zeilenga-ldap-user-schema-mr-00.txt - 1 of 1
LDAP: Additional Matching Rules (Proposed Standard)
Token: Ted Hardie
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Ted Hardie. The Secretariat will send an individual submission
Protocol Action Announcement that includes the RFC Editor Note.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-send-psreq-03.txt - 1 of 5
IPv6 Neighbor Discovery trust models and threats (Informational)
Token: Margaret Wasserman
The document remains under discussion by the IESG.*
o draft-ietf-ieprep-ets-telephony-06.txt - 2 of 5
IP Telephony Requirements for Emergency Telecommunication Service (Informational)
Token: Jon Peterson
The document remains under discussion by the IESG.*
o draft-iesg-charter-03.txt - 3 of 5
An IESG charter (Informational)
Token: Steve Bellovin
The document remains under discussion by the IESG.*
o draft-ietf-pkix-warranty-extn-03.txt - 4 of 5
Internet X.509 Public Key Infrastructure Warranty Certificate Extension (Informational)
Token: Steve Bellovin
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Steve Bellovin. The Secretariat will send a working group
submission Document Action Announcement that includes the RFC Editor Note.
o draft-ietf-tsvwg-highspeed-01.txt - 5 of 5
HighSpeed TCP for Large Congestion Windows (Experimental)
Token: Jon Peterson
The document was approved by the IESG. The Secretariat will send
a working group submission Document Action Announcement.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-rfc-editor-rfc2223bis-07.txt - 1 of 2
Instructions to Request for Comments (RFC) Authors (Informational)
Token: Harald Alvestrand
The document remains under discussion by the IESG.*
o draft-mealling-liberty-urn-00.txt - 2 of 2
A URN Namespace For The Liberty Alliance Project (Informational)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send an
individual submission Document Action Announcement.
3.2.2 Returning Item
o draft-siemborski-mupdate-04.txt - 1 of 1
The MUPDATE Distributed Mailbox Database Protocol (Experimental)
Token: Ned Freed
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Ned Freed. The Secretariat will send an individual
submission Document Action Announcement that includes the
RFC Editor Note.
3.2.3 To be assigned
o draft-baker-soap-media-reg-03.txt
The 'application/soap+xml' media type (Informational)
The document was assigned to Ned Freed.
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-fleming-ldap-printer-schema-02.txt - 1 of 2
Lightweight Directory Access Protocol (LDAP):Schema for Printer Services (Informational)
Token: Ted Hardie
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-touch-ipsec-vpn-05.txt - 2 of 2
Use of IPsec Transport Mode for Dynamic Routing (Informational)
Token: Russ Housley
The document remains under discussion by the IESG.*
3.3.2 Returning Item
NONE
3.3.3 To be Assigned
o draft-klensin-name-filters-03.txt - 1 of 2
User Interface Evaluation and Filtering of Internet Addresses and
Locators -or- Syntaxes for Common Namespaces (Informational)
The document was assigned to Ted Hardie.
o draft-foster-mgcp-redirect-05.txt - 2 of 2
Media Gateway Control Protocol (MGCP) Redirect and Reset Package (Informational)
The document was assigned to Jon Peterson.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o MIPv6 Signaling and Handoff Optimization - 1 of 2
Token: Thomas Narten
The WG remains under discussion by the IESG. Thomas Narten will
prepare a revised charter for further IESG review.
o Storage Transport - 2 of 2
Token: Margaret Wasserman
The IESG approved the draft charter for IETF review pending submission of
an updated version of the charter, provided by Margaret Wasserman that reflects
a name change to IP over Fiberchannel (ipofc). The Secretariat will send a
WG Review announcement, with a copy to new-work@ietf.org and place the WG
on the agenda for the next IESG teleconference.
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Common Control and Measurement Plane - 1 of 1
Token: Alex Zinin
The IESG decided to proceed with IETF review of the revised charter pending an
updated charter provided by Alex Zinin. The Secretariat will send a WG Review:
Recharter announcement, with copies to new-work@ietf.org and to the WG Chairs.
The Secretariat will place the WG on the agenda for the next IESG teleconference.
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
7.1 Appropriate Methods for getting Meeting Minutes from Chairs (Harald Alvestrand)
This management issue was postponed until the next IESG teleconference by Harald
Alvestrand.
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
This management issue was discussed, and Harald Alvestrand requested that it
be placed on the agenda for the next IESG teleconference.
7.3 Nomcom - List of open positions and appoint a Liaison (Harald Alvestrand)
This management issue was discussed. Bill Fenner agreed to serve as the IESG
liaison to the Nomcom.
7.4 Tony Hain Appeal (Harald Alvestrand)
This management issue was discussed. Rob Austein, Michelle Cotton, Leslie
Daigle, Thomas Narten, Joyce Reynolds, and Margaret Wasserman left the teleconference
prior to the discussion. The IESG has made a decision on the appeal, and the
decision will disclosed in a message to the IETF Announcement list.
7.5 Todd Glassey Appeal (Bert Wijnen)
This management issue was discussed. Harald Alvestrand, Rob Austein, Steve
Bellovin, Michelle Cotton, Leslie Daigle, and Joyce Reynolds left the teleconference
prior to the discussion. Thomas Narten and Margaret Wasserman rejoined the
teleconference for discussion of this issue. The IESG has made a decision on
the appeal, and the decision will be disclosed in a message to the IETF Announcement
list.
----------------------------------------
* Please see the ID Tracker
(https://datatracker.ietf.org/public/pidtracker.cgi) for details
on documents that are under discussion by the IESG.
1. Administrivia
1.4 Review of Action Items
OUTSTANDING TASKS
Last updated: September 23, 2003
IP o Jon Peterson to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Thomas Narten to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas Narten to contact Cablelabs to discuss formal relationship with IAB
IP o Steve Bellovin to write RFC re: TCP MD5 option
IP o Randy Bush and Ned Freed to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex Zinin to send proposal and justification for interim document review.
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 Bill Fenner, Ted Hardie, and Thomas Narten to work out acceptable
text to resolve ABNF and SRV issues.
IP o Harald Alvestrand to consult with Randy Bush and make sure a policy
is generated regarding interoperability testing at IETF Meetings.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 9
o draft-ietf-disman-conditionmib-10.txt
Alarm Reporting Control MIB (Proposed Standard)
Note: IESG evaluation
Token: Bert Wijnen
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-disman-conditionmib -
Alarm Reporting Control MIB
--------
Last Call to expire on: 2003-09-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 [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <disman@ietf.org>
Subject: Protocol Action: 'Alarm Reporting Control MIB' to
Proposed Standard
The IESG has approved following document:
- 'Alarm Reporting Control MIB '
<draft-ietf-disman-conditionmib-10.txt> as a Proposed Standard
This document is the product of the Distributed Management Working Group.
The IESG contact persons are Bert Wijnen and Randy Bush.
Technical Summary
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for controlling the reporting of
alarm conditions.
Working Group Summary
The Working Group reached consensus to request publication of this
document as a Proposed Standard. Input from ITU-T and DMTF has been
considered during development of this document and the concerns
raised have been accommodated.
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 - 2 of 9
o draft-ietf-rmonmib-apm-mib-11.txt
Application Performance Measurement MIB (Proposed Standard)
Note: Ready for IESG Evaluation.. No IETF Last Call comments received.
Token: Bert Wijnen
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-rmonmib-apm-mib -
Application Performance Measurement MIB
--------
Last Call to expire on: 2003-09-16
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <rmonmib@ietf.org>
Subject: Protocol Action: 'Application Performance Measurement
MIB' to Proposed Standard
The IESG has approved following document:
- 'Application Performance Measurement MIB'
<draft-ietf-rmonmib-apm-mib-11.txt> as a Proposed Standard
This document is the product of the Remote Network Monitoring Working
Group.
The IESG contact persons are Bert Wijnen and Randy Bush.
Technical Summary
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for measuring the application
performance as experienced by end-user.
Working Group Summary
The Working Group has consensus to publish this document as a
Proposed Standard
Protocol Quality
The document has been reviewed for the IESG by Bert Wijnen.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 3 of 9
o draft-ietf-ipsec-rfc2402bis-05.txt
IP Authentication Header (Proposed Standard)
Token: Russ Housley
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 4 of 9
o draft-ietf-ipsec-esn-addendum-02.txt
Extended Sequence Number Addendum to IPsec DOI for ISAKMP (Proposed
Standard)
Token: Russ Housley
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 5 of 9
o draft-ietf-ipsec-esp-v3-06.txt
IP Encapsulating Security Payload (ESP) (Proposed Standard)
Token: Russ Housley
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 6 of 9
o draft-ietf-dnsext-keyrr-key-signing-flag-09.txt
KEY RR Secure Entry Point Flag (Proposed Standard)
Note: Some editorial nits, can be folded in with IESG review.
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-keyrr-key-signing-flag -
KEY RR Secure Entry Point Flag
--------
Last Call to expire on: 2003-09-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <namedroppers@ops.ietf.org>
Subject: Protocol Action: 'KEY RR Secure Entry Point Flag' to
Proposed Standard
The IESG has approved following document:
- 'KEY RR Secure Entry Point Flag '
<draft-ietf-dnsext-keyrr-key-signing-flag-09.txt> as a Proposed Standard
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Thomas Narten and Margaret Wasserman.
The Delegation Signer (DS) resource record introduced the concept of a
key acting as a secure entry point into a delegation. During
DNS-related key exchanges between the child and parent zone, there is
a need to differentiate secure entry point keys from other keys in the
KEY resource record set. This differentiation is not for the DNS
protocols per se, but to help in determining what types of keys need
to be generated (e.g., for a DS RR) and how to automate their generation.
This document defines a flag bit in the KEY RR to indicate KEY RRs
that are used as a secure entry point. The flag bit is intended to
assist in oprational procedures to correctly generate DS resource
records, or to indicate what keys are intended for static
configuration. The flag bit has no semantics in the DNS protocols and
its value results in no special processing by the DNS protocols when
operating on KEY RRs. This document updates RFC 2535 and RFC 3445.
Working Group Summary
The dnsext Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Thomas Narten for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 7 of 9
o draft-ietf-ldup-lcup-06.txt
LDAP Client Update Protocol (Proposed Standard)
Token: Ted Hardie
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ldup-lcup -
LDAP Client Update Protocol
--------
Last Call to expire on: 2003-09-23
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <ietf-ldup@imc.org>
Subject: Protocol Action: 'LDAP Client Update Protocol' to
Proposed Standard
The IESG has approved following document:
- 'LDAP Client Update Protocol'
<draft-ietf-ldup-lcup-06.txt> as a Proposed Standard
This document is the product of the LDAP Duplication/Replication/Update Protocols Working Group.
The IESG contact persons are Ted Hardie and Ned Freed.
Technical Summary
The LCUP protocol allows LDAP clients to synchronize
with the content stored by LDAP servers; it does not
address server to server synchronization. It has three
main proposed use cases: limited clients that need to
maintain read-only copies of directory data for use while
off-line; applications synchronizing local data with multiple
data stores to create a different view of the data (e.g. a
meta directory); and clients which perform automated tasks
based on directory information triggers (e.g. a client that
creates new mailboxes when a new directory entry is created).
Working Group Summary
The group achieved rough consensus after significant debate.
A minority view that this protocol represented the wrong engineering
choice in the face of common implementations was discussed extensively
on the mailing list and the issues raised again during last call. The
key point of contention was how the balance between server state
and on-the-wire traffic should be struck. The draft's applicability statement
indicates that some level of server state would be required to
avoid full synchronization (and its implied cost in traffic and
processing), and there was debate over the relative costs for
current and furture implementations. After a focused period
of discussion, the working group came to rough consensus
that the protocol contained sufficient mechanisms to handle cases
where incremental update was sub-optimal and the document
clear enough in its applicability statement to prevent misunderstanding.
Protocol Quality
Ted Hardie reviewed this document for the IESG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 8 of 9
o draft-ietf-nomcom-rfc2727bis-07.txt
IAB and IESG Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees (BCP)
Token: Harald Alvestrand
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-nomcom-rfc2727bis -
IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
--------
Last Call to expire on: 2003-09-12
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <ietf-nomcom@lists.elistx.com>
Subject: Protocol Action: 'IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees' to BCP
The IESG has approved the Internet-Draft 'IAB and IESG Selection,
Confirmation, and Recall Process: Operation of the Nominating and Recall
Committees' <draft-ietf-nomcom-rfc2727bis-07.txt> as a BCP. This document
is the product of the Operation of the IESG/IAB Nominating and Recall
Committees Working Group.
The IESG contact person is Harald Alvestrand.
Technical Summary
This document describes the operation of the IETF NomCom.
This version updates the rules by which the Nomcom process is governed.
In many cases, ambiguities that had been found in 2727 were resolved.
In other cases, situations that had been left to the discretion of the
participants were codified.
Working Group Summary
On a lot of issues, there was smooth consensus in the working group.
On some issues, there was significant controversy, but rough consensus.
In one case (publication of names of nominees) consensus was not reached,
and the text remained unchanged from 2727.
Protocol Quality
The document has been reviewed for the IESG by Harald Alvestrand.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 9 of 9
o draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt
KDC Server Address Sub-option (Proposed Standard)
Token: Margaret Wasserman
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-dhc-suboptions-kdc-serveraddress -
KDC Server Address Sub-option
--------
Last Call to expire on: 2003-09-30
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ned Freed:
Comment:
This seems, well, highly vendor-specific. I guess this is OK...
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <dhcwg@ietf.org>
Subject: Protocol Action: 'KDC Server Address Sub-option' to
Proposed Standard
The IESG has approved following document:
- 'KDC Server Address Sub-option '
<draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt> as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working
Group.
The IESG contact persons are Margaret Wasserman and Thomas Narten.
Technical Summary
This document describes a sub-option of the "DHCP Option for CableLabs
Client Configuration", RFC 3495. A certain class of CableHome devices
require the configuration of a "Key Distribution Center" server as an IP
address rather than as a domain name. The new sub-option provides KDC
configuration as an IPv4 address.
Working Group Summary
The -04 revision of the draft addresses comments received during the WG last
call. Note that there were few responses to the WG last call; all of these
response supported acceptance of the doc and a couple of responses suggested
edits. The important changes in the -04 rev are additional text in the
Security Considerations section and a new reference to the CableHome 1.1
specification.
Protocol Quality
This document has been reviewed for the IESG by Margaret Wasserman.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 3
o draft-ietf-ftpext-mlst-16.txt
Extensions to FTP (Proposed Standard)
Token: Ted Hardie
Evaluation: draft-ietf-ftpext-mlst - Extensions to FTP to
Proposed Standard
--------
Last Call to expire on: December 17, 2001
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [XX ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ XX] [ X ] [ ]
Ned Freed [ ] [ ] [ X ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
RFC EDITOR:
The Abstract section does not meet with RFC Editor style guidelines.
The Abstract section reads more as an introduction than a brief
summary of the document. (note: version 13)
Comment:
Scott: note: should this doc (and writeup) say that it updates STD 9
see sec 8
DISCUSS
=======
Ned: The second paragraph of section 2.2 says, in part:
Implementations are advised against converting a UTF-8 pathname to a local
encoding, and then attempting to invert the encoding later.
I think this incorrectly confuses encodings with charsets. In particular,
I don't want an implementation that uses UTF-16 internally to refrain
from converting UTF-16 to UTF-8 on the wire. I do want, however to
discourage _charset_ conversions. I suggest this be changed to read:
Implementations are advised against converting a UTF-8 pathname to a local
charset, and then attempting to invert the transformation later.
I also note that even with the changed wording this is slightly in
conflct with the recommendations in section 7.5.9, but I guess this is OK.
===========
Bill: Several suggestions, all relatively minor:
--
Should the reference to RFC 2119 follow the form suggested in RFC 2119?
--
Section 3.4 starts:
If we assume the existence of three files, A B and C, and a directory
D, and no other files at all
but later it assumes the existence of files named "file6" and
"19990929043300 File6".
--
Section 7.1:
For these purposes, the contents of a directory are whatever
file names (not pathnames) the server-PI will allow to be referenced
when the current working directory is the directory named, and which
the server-PI desires to reveal to the user-PI.
Earlier text refers to both "file names" and "directory names", implying
that they are seperate things, so this text seems to preclude including
directory names in MLSx responses. Should this say "file or directory names"?
--
In the last paragraph of 7.2:
Facts
should be provided in each output line only if they both provide
relevant information about the file named on the same line, and they
are in the set requested by the user-PI.
Should this refer to section 7.9, since this is a forward reference
to the fact that the set is requestable?
--
Section 7.5.1:
...
file -- a file entry
...
type-val = "File" / "cdir" / "pdir" / "dir" /
os-type
Fact values are case-sensitive, right, so the ABNF should probably
use "file".
--
Relevant to section 7.5.1.2 and 7.5.1.4:
All the examples in section 7.7 show listings where, if present,
"type=cdir" and "type=pdir" are at the beginning, despite the warnings
that they may be anywhere. Even if it means modifying an example from
what was actually returned by an implementation, I think it'd be worth
having an example that has these entries elsewhere, since examples are
commonly heavily used during implementation.
--
Section 7.7.9:
This server seems to use uppercase when fully-qualifying the type=cdir
entry on MLSD responses, and lowercase when fully-qualifying responses
to MSLT. This is a little confusing, so although the explanation does
mention that it is a case-independent NVFS, perhaps it could explicitly
say "and that's why it uses different case for the fully-qualified path
in different responses".
--
The last example in section 7.8.1:
S> MLST Type*;Size*;Modify*;Perm;Unique*;
... All of the facts supported by
this server are enabled by default.
In the example response, Perm is not enabled by default.
Steve:
Section 3 talks about comparing the server's file modification time to
the client's. But 2.3 says that the times aren't synchronized.
(How many FTP clients and servers implement Block and Compressed?)
7 says that all 256 octet values are permitted. Must telnet NVT
characters be escaped here? Clarify.
Servers should ensure that the unique identifier fact is not security
sensitive, e.g., it should not be the NFS handle for the file.
And I don't think I particularly want to discuss the copyright notice...
^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>,ftp-wg@hethmon.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Extensions to FTP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Extensions to FTP'
<draft-ietf-ftpext-mlst-16.txt> as a Proposed Standard. This document
is the product of the Extensions to FTP Working Group. The IESG
contact persons are Ned Freed and Patrik Faltstrom.
Technical Summary
This document specifies new FTP commands to obtain listings of remote
directories in a defined format, and to permit restarts of interrupted data
transfers in STREAM mode. It allows character sets other than US-ASCII,
and also defines an optional virtual file storage structure,
Working Group Summary
There was consensus in the working group for this document. Version 14 of
the Internet-Draft reflects comments during last call.
Protocol Quality
The protocol was reviewed for the IESG by Patrik Faltstrom.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 3
o draft-ietf-dhc-isnsoption-10.txt
The IPv4 DHCP Options for the Internet Storage Name Service (Proposed
Standard)
Note: Note: new version (-10) should address outstanding discusses.
Token: Thomas Narten
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dhc-isnsoption -
The IPv4 DHCP Options for the Internet Storage Name Service
--------
Last Call to expire on: 2003-07-22
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ X ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Steve Bellovin (Discuss):
Is 3118 mandatory-to-implement or not? I have a hard time
understanding why it should be optional.
What are the semantics if both "Main Mode" and "Aggressive Mode" have
the same value? "Transport Mode" and "Tunnel Mode"? If IKE/IPsec is
disabled, what security should be used? Any? None?
The IANA Considerations section is inadequate. First, it should state
what registry the option code should be taken from. Second, it should
state what what procedure (per 2434) should be used to assign new
values to the assorted bit fields in this option.
Alex Zinin (Discuss):
[iSNS] is listed as non-normative. How's that possible if the opinion
is supposedly specific for iSNS and doesn't make sense outside of iSNS
context, i.e., iSNS needs to exist for the option to make sense.
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@isi.edu>, <dhcwg@ietf.org>
Subject: Protocol Action: 'The IPv4 DHCP Options for the Internet
Storage Name Service' to Proposed Standard
The IESG has approved the Internet-Draft 'The IPv4 DHCP Options for the
Internet Storage Name Service' <draft-ietf-dhc-isnsoption-08.txt> as a
Proposed Standard. This document is the product of the Dynamic Host
Configuration Working Group. The IESG contact persons are Thomas Narten and
Margaret Wasserman.
Technical Summary
This document describes the DHCP option to allow Internet Storage Name
Service (iSNS) clients to automatically discover the location of the
iSNS server through the use of DHCP for IPv4.
Working Group Summary
There was support in both the DHC and IPS WGs for this option.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 3 of 3
o draft-ietf-avt-mpeg4-simple-08.txt
RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed
Standard)
Note: On agenda again to check if mods from MPEG4 group to language
about ECMAscript risks are ok for clearing SMB's Discuss - there was
agreed language during Vienna but it needed a little modification.
Token: Allison Mankin
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-avt-mpeg4-simple - RTP Payload Format for
Transport of MPEG-4 Elementary Streams to Proposed Standard
--------
Last Call to expire on: 2003-6-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Steve:
2.4: Why is this form of application-level fragmentation better than
IP fragmentation?
Where is the security model defined for ECMAScript in this context?
(Problems with the model have been part of the Javascript security
problem for Web browsers.)
COMMENT:
=======
Russ Housley:
It is strange to have more than one section labeled
"Introduction." Please pick a new label for section 2.1.
^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>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Payload Format for Transport of MPEG-4
Elementary Streams to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The RTP Payload Format for Transport
of MPEG-4 Elementary Streams <draft-ietf-avt-mpeg4-simple-07.txt> as a
Proposed Standard. This document is the product of the Audio Video Transport
Working Group. The IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
The MPEG-4 standard specifies compression of audio-visual data into
for example an audio or video elementary stream. In the MPEG-4
standard, these streams take the form of audio-visual objects that may
be arranged into an audio-visual scene by means of a scene
description. Each MPEG-4 elementary stream consists of a sequence of
Access Units; examples of an Access Unit (AU) are an audio frame and a
video picture.
This specification defines a general and configurable payload
structure to transport non-multiplexed MPEG-4 elementary streams, in
particular MPEG-4 audio (including speech) streams, MPEG-4 video
streams and also MPEG-4 systems streams, such as BIFS (BInary Format
for Scenes), OCI (Object Content Information), OD (Object Descriptor)
and IPMP (Intellectual Property Management and Protection) streams.
The RTP payload defined in this document is simple to implement and
reasonably efficient. It allows for optional interleaving of Access
Units (such as audio frames) to increase error resiliency in packet
loss.
This payload format is largely compatible with the video part
of RFC 3016, the RTP Payload Format for MPEG-4 Audio/Visual Streams, and
extends that format to effectively support other classes of media and also
MPEG-4 Systems streams.
The specification registers the MIME sub-types audio/mpeg4-generic,
video/mpeg4-generic and application/mpeg4-generic.
MPEG-4 Systems supports stream types including commands that are
executed on the terminal like OD commands, BIFS commands, etc. and
programmatic content like MPEG-J (Java(TM) Byte Code) and
CMAScript. The Security Considerations discuss risks associated with
these capabilities and ways to mitigate these risks.
Working Group Summary
This was a strenuous effort by the AVT Working group.
This payload format has been under development since the 39th IETF meeting
in Munich, August 1997. It is the result of collaboration between AVT, the
MPEG committee and the Internet Streaming Media Alliance. When the
consensus designs were achieved, there was a thorough Last Call review and
strong support for advancement.
Protocol Quality
The specification was reviewed for the IESG by Allison Mankin.
2. Protocol Actions
2.2 Individual Submissions
2.2.1 New Item - 1 of 1
o draft-zeilenga-ldap-rfc2596-04.txt
Language Tags and Ranges in LDAP (Proposed Standard)
Token: Ted Hardie
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-zeilenga-ldap-rfc2596 -
Language Tags and Ranges in LDAP
--------
Last Call to expire on: 2003-09-23
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>
Subject: Protocol Action: Language Tags and Ranges in LDAP to Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Language Tags and Ranges in LDAP' <draft-zeilenga-ldap-rfc2596-04.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 person is Harald Alvestrand
Technical Summary
This document describes how language tags and ranges are
carried in LDAP and are to be interpreted by LDAP implementations.
It replaces RFC 2596, and it contains signficant changes:
it adds support for language ranges; provides a mechanism
for discovery of whether a server supports language
tags and ranges; and it clarifies how attributes with multiple language
tags are to be treated. The approach described is signficantly
different from the approach in X.500; the document summarizes
those differences in a non-normative appendix.
Working Group Summary
This document is not the product of a working group, but it do go
through IETF Last Call; no objections were received.
Protocol Quality
This document was reviewed by Ted Hardie for the IESG.
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 2
o draft-ietf-isis-igp-p2p-over-lan-03.txt
Point-to-point operation over LAN in link-state routing protocols
(Informational)
Note: On agenda for 2003-10-02 telechat
Token: Bill Fenner
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 2
o draft-ietf-magma-msf-api-05.txt
Socket Interface Extensions for Multicast Source Filters
(Informational)
Token: Margaret Wasserman
3.1.2 Returning Item
NONE
3. Document Actions
3.2 Individual Submissions Via AD
3.2.1 New Item - 1 of 2
o draft-newton-ldap-whois-04.txt
Whois Domain Data using the Lightweight Directory Access Protocol
(LDAP) (Experimental)
Token: Ted Hardie
3. Document Actions
3.2 Individual Submissions Via AD
3.2.1 New Item - 2 of 2
o draft-gill-gtsh-01.txt
The Generalized TTL Security Mechanism (GTSM) (Experimental)
Token: Alex Zinin
3.2.2 Returning Item
NONE
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Long-Term Archive and Notary Services (ltans) - 1 of 1
Token: Russ
Long-Term Archive and Notary Services (ltans)
---------------------------------------------
Last Modified: 2003-9-25
Current Status: Proposed Working Group
CHAIR(S):
Tobias Gondrom <tobias.gondrom@ixos.de>
Carl Wallace <cwallace@orionsec.com>
SECURITY AREA DIRECTORS:
Russ Housley <housley@vigilsec.com>
Steve Bellovin <smb@research.att.com>
SECURITY AREA ADVISOR:
Russ Housley <housley@vigilsec.com>
MAILING LIST:
General Discussion: ietf-ltans@imc.org
To Subscribe: subscribe-ietf-ltans@imc.org
In Body: subscribe
To Unsubscribe: unsubscribe-ietf-ltans@imc.org
Archive: http://www.imc.org/ietf-ltans
DESCRIPTION OF WORKING GROUP:
In many scenarios, users need to be able to ensure and prove the existence
and validity of data, especially digitally signed data, in a common and
reproducible way over a long and possibly undetermined period of time.
Cryptographic means are useful, but they do not provide the whole solution.
For example, digital signatures (generated with a particular key size) might
become weak over time due to improved computational capabilities, new
cryptanalytic attacks might "break" a digital signature algorithm, public
key certificates might be revoked or expire, and so on. Complementary
methods covering potential weaknesses are necessary.
Long-term non-repudiation of digitally signed data is an important aspect
of PKI-related standards. Standard mechanisms are needed to handle routine
events, such as expiry of signer's public key certificate and expiry of
trusted time stamp authority certificate. A single timestamp is not
sufficient for this purpose. Additionally, the reliable preservation of
content across change of formats, application of electronic notarizations,
and subsequent notary services require standard solutions.
The objective of the LTANS working group is to define requirements, data
structures and protocols for the secure usage of the necessary archive and
notary services. First, the requirements for the long-term archive will be
collected. Based on that information we will develop a protocol to access
archive services supplying long-term non-repudiation for signed documents
and define common data structures and formats. Upon completion of the
archive-related specifications, we will address 'notary services' in a
similar way. The term 'notary services' is not clearly defined. The working
group will determine which functions need standards, including transformation
of documents from one format to another without losing the value of evidence,
electronic notarization, and further verification of legal validity of signed
documents. We will determine the needs via the requirements paper and act
upon the results accordingly.
Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as
the basis to define those structures and protocols. For example, the
Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive
Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server
Protocols (DVCS)", contain applicable concepts.
GOALS AND MILESTONES
Nov 03 Initial requirements for long-term archive I-D
Dec 03 Revised requirements for long-term archive I-D
Dec 03 Initial data structures for long-term archive I-D
Dec 03 Initial protocol for long-term archive I-D
Feb 04 Last call requirements for long-term archive I-D
Mar 04 Submit requirements for long-term archive to IESG as informational
Mar 04 Revised data structures for long-term archive I-D
Mar 04 Revised protocol for long-term archive I-D
Apr 04 Last call data structures for long-term archive I-D
Apr 04 Last call protocol for long-term archive I-D
May 04 Submit data structures for long-term archive to IESG as proposed standard
May 04 Submit protocol for long-term archive to IESG as proposed standard
Jul 04 Initial requirements for notary services I-D
Sep 04 Revised requirements for notary services I-D
Nov 04 Last call requirements for notary services I-D
Dec 04 Submit requirements for notary services to IESG as proposed standard
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Centralized Conferencing (xcon) - 1 of 1
Token: Description
Centralized Conferencing (xcon)
---------------------------------
Last Modified: 2003-09-25
Current Status: Proposed Working Group
Current Status: Proposed Working Group
CHAIRS: Alan Johnston (alan.johnston@mci.com)
Adam Roach (adam@dynamicsoft.com)
Mailing list: <http://www.softarmor.com/mailman/listinfo/xcon>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
Transport Area
Responsible Area Director: Allison Mankin
Description of Working Group
The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong
security and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization (known as a focus) so they can enforce specific media and
membership relationships, and provide an accurate roster of participants.
The media mixing or combining function of a tightly-coupled conference
need not be performed centrally, however.
The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.
Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be invisible to all but the conference owner, or to be
visible but participate anonymously with respect to some or all of
the other participants.
Authorization rules allow for participants and non-participants
to have roles (ex: speaker, moderator, owner), and to be otherwise
authorized to perform membership and media manipulation for or on
behalf of other participants. In order to preserve these properties,
the protocols used will require implementation of channel security
and authentication services.
Due to the centralized architecture of the WG, XCON's mechanisms will place
requirements on the signaling protocol used between the focus and the
participants. At a high level, the signaling protocol must be able to
establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in both a
centralized and distributed mixing architecture. SIP will be the
reference session signaling protocol used for examples; however, none of the XCON
solutions themselves will be signaling protocols, nor will XCON extend existing
signaling protocols. Other signaling protocols than SIP may be used between the focus
and participants, including non-IETF protocols, but the requirements and
possible extensions needed for other signaling protocols to utilize the
full functionality of the XCON architecture is outside the scope of XCON.
The deliverables for the group will be:
- A mechanism for membership and authorization control
- A mechanism to manipulate and describe media "mixing" or "topology" for
multiple media types (audio, video, text)
- A mechanism for notification of conference related events/changes (for
example a floor change)
- A basic floor control protocol
The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.
The following items are specifically out-of-scope:
- Voting
- Fully distributed conferences
- Loosely-coupled conferences (no central point of control)
- Far-end device control
- Protocol used between the conference controller and the mixer(s)
- Capabilities negotiation of the mixer(s)
- Master-slave cascaded conferences
The working group will coordinate closely with the SIPPING and
MMUSIC working groups. In addition the working group will cooperate
with other groups as needed, including SIP, MSEC, AVT, and the W3C
SMIL working groups. In addition, the working group will consider
a number of existing drafts as input to the working group.
Proposed Milestones
Oct 2003 Submit Requirements for Membership Manipulation for
publication as Informational
Oct 2003 Submit Requirements for Basic Floor Control for
publication as Informational
Nov 2003 Submit Conferencing Scenarios document for publication
as Informational
Nov 2003 Submit Use Cases for Media Topology Control for publication
as Informational
Dec 2003 Submit Requirements for Media Topology Control for
publication as Informational
Feb 2004 Submit Basic Floor Control Protocol for publication as PS
Mar 2004 Submit Notification Event package extension for conference
related events for publication as PS
May 2004 Submit Membership Manipulation Protocol for publication
as PS
Jul 2004 Submit Protocol for Media Topology Control for publication
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Audio/Video Transport (avt) - 1 of 4
Token: Allison
Audio/Video Transport (avt)
---------------------------
Last Modified: 2003-9-25
Current Status: Active Working Group
Chair(s):
Colin Perkins <csp@csperkins.org>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: avt@ietf.org
To Subscribe: avt-request@ietf.org
Archive: www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
The Audio/Video Transport Working Group was formed to specify a
protocol for real-time transmission of audio and video over unicast
and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
together with its associated profiles and payload formats. The
current aims of the working group are:
- to advance the main RTP specification and RTP Profile
for Audio and Video Conferences with Minimal Control
for publication as full Internet Standards
- to review and revise existing payload formats to advance those
which are useful to Draft Standard, and to declare others
as Historic. Milestones will be established as a champion for
each payload format is identified.
- to develop payload formats for new media codecs, and to
document best-current practices in payload format design.
The group continues to be precluded from work on codecs
themselves because of overlap with the other standards
bodies, and because the IETF does not have the ability
to effectively review new codecs. An exception was made
for the freeware iLBC codec on a highly experimental basis,
but acceptance of new codec work is unexpected and subject
to rechartering.
- to complete the forward error correction work in the ULP and
UXP payload formats
- to extend RTP to work with Source-Specific Multicast sessions
with unicast feedback
- to provide a framing mechanism for RTP over TCP and TLS
- to review the applicability of Compressed RTP operation on
MPLS networks, developing extensions as necessary
- to develop a new RTP profile as the combination of the SRTP
profile and the Extended RTP Profile for RTCP-based Feedback
(RTP/SAVPF)
The group will also coordinate with the DCCP working group to
ensure that RTP can be efficiently transported over DCCP.
The longer term goals of the working group are to advance the
SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
the Compressed RTP framework, and the RTP MIB to Draft Standard.
The group has no plans to develop new RTP profiles beyond those
listed above, but will consider rechartering to produce profile
level extensions if appropriate.
Milestones:
Oct 2003 Review DCCP including prototypes and API; feedback to DCCP WG
Nov 2003 Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 2003 Submit UXP Payload Format for Proposed Standard
Dec 2003 Submit ULP Payload Format for Proposed Standard
Dec 2003 Submit RTCP/SSM draft for Proposed Standard
Dec 2003 Submit iLBC codec specification for Experimental
Dec 2003 Submit iLBC payload format for Proposed Standard
Jan 2004 Advance RTP specification and A/V profile to Full Standard
Mar 2004 Submit Framing of RTP for TCP and TLS for Proposed Standard
Mar 2004 Identify payload formats to classify as Historic
Mar 2004 Finish requirements for ECRTP over MPLS; recharter for subsequent work
Jul 2004 Submit RTP/SAVPF profile for Proposed Standard
Jul 2004 Begin update of SRTP profile for Draft Standard RFC
Jul 2004 Begin update of RTP/AVPF profile for Draft Standard RFC
Aug 2004 Consider update of RTP MIB
Nov 2004 Collect SRTP implementation reports
Nov 2004 Collect RTP/AVPF implementation reports
Mar 2005 Submit SRTP for Draft Standard
Mar 2005 Submit RTP/AVPF for Draft Standard
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o DNS Extensions (dnsext) - 2 of 4
Token: Thomas
DNS Extensions (dnsext)
-----------------------
Last Modified: 16-September-2003
Current Status: Active Working Group
Chair(s):
Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <olaf@ripe.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: <http://ops.ietf.org/lists/namedroppers/>
The DNSEXT Working Group actually uses an additional mailing
list:
DNS Security: dnssec@cafax.se
To Subscribe: dnssec-request@cafax.se
Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list
Description of Working Group:
DNS was originally specified in RFC's 1034 and 1035, with subsequent
updates. Within the scope of this WG are DNS protocol issues,
including the specification of message formats, message handling, and
data formats used for DNS client-server and server-server
communication.
This WG is focused on advancing the zone transfer, update and notify
documents to Draft standard and on the rewrite of the DNSSEC proposed
standard.
Issues surrounding the operation of DNS, recommendations concerning
the configuration of DNS servers, and other issues with the use of
the protocol are out of this Working Group's charter. These issues
are considered in other venues, such as the DNS Operations Working
Group.
Specific work items are:
o Protocol clarifications and corrections for DNSSEC, initially
these clarifications will be done as separate RFCs that will
later be folded into a document that we refer to as the RFC
2535bis document standard. These include changes that
simplify the operation of DNSSEC.
o Generate new specification documents of DNSSEC (the RFC
2535bis document set) that includes all changes to RFC2535.
This includes the following RFCs 2931, 3007, 3008, 3090 and
3226 and a number of Internet Drafts including DS,
AD-is-secure, Key Signing Flag, etc. Advance this document
set through the standards process.
o Clarification of RFC1034/1035 relating to DNSEXT ongoing work.
+ Clarification of wildcard processing rules.
+ Case Insensitivity Clarification.
o After the work items above have been completed the working
group will continue on reviewing the following existing
proposed standard and examine if there is a possibility to
progress them on the standards track.
+ RFC1995 (IXFR) to Draft standard.
+ RFC1996 (Notify) to Draft standard.
+ RFC2136bis (Dynamic Update) to Draft Standard.
+ RFC2181 (Clarify) to IESG for advancement to Draft Standard.
+ RFC2308 (Neg Caching) to Draft Standard.
+ RFC2671 (EDNS0) to Draft Standard.
+ RFC2845 (TSIG)to Draft standard.
+ RFC2930 (TKEY) to Draft standard.
+ RFC3007 (Secure Update) to Draft standard.
+ RFC3??? AXFR clarify to Draft Standard.
+ RFC3??? GSS/TSIG to Draft Standard
o Foster the development of Link Local Multicast Name
Resolution (LLMNR) standard. The WG has taken up this work
since LLMNR it is very similar to the DNS protocol. LLMNR is
targeted as proposed standard.
The lifetime of the group is set by the work items above but while
these are ongoing the working group has additional tasks:
o Reviewing and providing recommendations about the specification,
by other working groups, of RR types that do not require any
special processing and that do not require any special naming
conventions.
Goals and Milestones:
Sep 03 Update boilerplate text on OPT-IN
Oct 03 Forward LLMNR to IESG for Proposed Standard.
Oct 03 WG last call on the DNSSEC document set(RFC2535-bis).
Oct 03 Forward Wildcard clarification to IESG for proposed standard
Nov 03 Submit KEY algorithm documents RFC253[69d] and RFC3110 to IESG for proposed standard.
Sep/Oct 03 Forward RFC2535-bis to IESG for proposed standard.
Feb 04 Submit to IESG RFC2845 (TSIG)to Draft standard.
Feb 04 Submit to IESG RFC2930 (TKEY) to Draft standard.
Nov 03 Start of process of reviewing the following RFCs and to move them to PS status.
Feb 04 RFC1982 (Serial Number Arithmetic)
Feb 04 RFC2782 (SRV RR) to Draft Standard
Feb 04 RFC2538 (CERT RR) to Draft Standard.
May 04 RFC1995 (IXFR) to Draft standard
May 04 RFC1996 (Notify) to Draft Standard.
May 04 RFC2136 (Dynamic Update) to Draft Standard.
May 04 RFC3007 (Secure Update) to Draft standard.
Aug 04 RFC2181 (Clarify) to Draft Standard.
Aug 04 RFC2671 (EDNS0) to Draft Standard.
Aug 04 RFC2308 (Neg Caching) to Draft Standard.
Nov 04 RFC3090 (TKEY) to Draft Standard.
Nov 04 FRC2539 (DH Key RR) to Draft Standard.
Nov 04 RFC3226 (Message Size) to Draft Standard
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Common Control and Measurement Plane (ccamp) - 3 of 4
Token: Alex
Common Control and Measurement Plane (ccamp)
--------------------------------------------
Last Modified: 2003-9-22
Current Status: Active Working Group
Chair(s):
Ronald Bonica <ronald.p.bonica@mci.com>
Kireeti Kompella <kireeti@juniper.net>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: http://ops.ietf.org/lists/ccamp
Description of Working Group:
Organizational Overview
The CCAMP working group coordinates the work within the IETF defining
a common control plane and a separate common measurement plane for
physical path and core tunneling technologies of Internet and telecom
service providers (ISPs and SPs), e.g. O-O and O-E-O optical
switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
with the MPLS WG. In this context, measurement refers to the
acquisition and distribution of attributes relevant to the setting up
of tunnels and paths.
CCAMP WG work scope includes:
- Definition of protocol-independent metrics and parameters
(measurement attributes) for describing links and paths that are
required for routing and signaling. These will be developed in
conjunction with requests and requirements from other WGs (e.g.
TEWG) to insure overall usefulness.
- Definition of protocol(s) and extensions to them required for
link and path attribute measurement. Link Management Protocol (LMP)
is included here.
- Functional specification of extensions for routing (OSPF, ISIS) and
signalling (RSVP-TE) required for path establishment. Protocol formats
and procedures that embody these extensions will be done jointly with
the WGs supervising those protocols.
- Definition of the mechanisms required to determine the route and
properties of an established path (tunnel tracing).
- Definition of MIB modules relevant to the protocols and extensions
specified within the WG.
CCAMP WG currently works on the following tasks:
- Define how the properties of network resources gathered by a
measurement protocol can be distributed in existing routing
protocols, such as OSPF and IS-IS. CCAMP defines the generic
description of the properties and how they are distributed in OSPF.
The specifics of distribution within IS-IS are being addressed in
the ISIS WG.
- Define signaling and routing mechanisms to make possible the creation
of paths that span multiple IGP areas, multiple ASes, and multiple
providers, including techniques for crankback.
- Define abstract link and path properties needed for link and path
protection. Specify signalling mechanisms for path protection,
diverse routing and fast path restoration. Ensure that multi-layer
path protection and restoration functions are achievable using the
defined signalling, routing, and measurement protocols, either
separately or in combination.
- Identify requirements for signaling and routing for ASON not currently
met; based on these, define mechanisms to address these requirements.
- Define a protocol that can determine the actual route and other
properties of paths set up by CCAMP signaling protocols, as well
as other types of tunnels (tunnel tracing).
In doing this work, the WG will work closely with at least the following
other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
ITU-T.
Goals and Milestones:
Done Post strawman WG goals and charter
Done Identify and document a limited set of candidate solutions for signalling
and for measurement. Among candidate control solutions to be considered are the
existing GMPLS drafts
Done Build appropriate design teams
Done Submit WG document defining path setup portions of common control plane protocol
Done Submit WG document defining common measurement plane protocol
Nov 03 Submit LMP MIB to IESG
Dec 03 Submit GMPLS MIBs to IESG
Dec 03 Submit protection & restoration documents to IESG
Dec 03 Submit ASON signaling requirements doc to IESG
Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
Feb 04 Submit ASON routing requirements doc to IESG
Mar 04 Submit revised charter and milestones to IESG for IESG consideration of more
detailed deliverables and determination of usefulness of continuation of WG
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Ethernet Interfaces and Hub MIB (hubmib) - 4 of 4
Token: Bert
Ethernet Interfaces and Hub MIB (hubmib)
----------------------------------------
Last Modified: 2003-9-24
Current Status: Active Working Group
Chair(s):
Dan Romascanu <dromasca@avaya.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: hubmib@ietf.org
To Subscribe: hubmib-request@ietf.org
In Body: subscribe your_email_address
Archive: www.ietf.org/mail-archive/working-groups/hubmib/current/maillist
Description of Working Group:
The Ethernet Interfaces and Hub MIB WG is Chartered to define
a set of managed objects that instrument devices, MAUs and
interfaces that conform to the IEEE 802.3 standard for Ethernet.
This set of objects should be largely compliant with, and even
draw from IEEE 802.3, although there is no requirement that any
specific object be present or absent.
Close coordination with hardware standards development in
IEEE 802.3 will be followed. The WG chair will support the
communication with IEEE 802.3. When objects are added that
require hardware support, IEEE 802.3 shall be informed,
so that they consider to add them to their draft/standard.
The MIB object definitions produced will be for use by SNMP and
will be adequately consistent with other SNMP objects, standards
and conventions.
The working group will work on the following MIB modules
for the IEEE 802.3ah (Ethernet First Mile) interfaces and
devices:
- Ethernet First Mile (EFM) MIB
common attributes, OAM operations and statistics
- Copper EFM MIB
- Ethernet Passive Optical Networks (EPON) MIB
The base for the definition of the managed objects in these
MIB modules will be the management-related clauses in IEEE
802.3ah specification. The working group will also take
into consideration management objects defined by other
Working Groups in the IETF (ADSL MIB for example), or other
standard bodies (G.983.2), will avoid work duplication,
and describe the relationship with these specifications.
Goals and Milstones
< keep complete list of DONE work items for archival reasons >
Oct 2003 - Individual submissions for the EFM MIB modules
Dec 2003 - First round of WG Internet-Drafts for the
EFM MIB modules
Apr 2004 - Working Group Last Call
Jun 2004 - Submit the Internet-Drafts to the IESG for
consideration as Proposed Standards
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
Jon Peterson
Margaret Wasserman
Bert Wijnen
Alex Zinin
6. IAB News We Can Use
7. Management Issues
7.1 Appropriate Methods for getting Meeting Minutes from Chairs (Harald Alvestrand)
7.2 Interoperability Testing at IETF Meetings (Harald Alvestrand)
------------------------------------------------------------
Message #1 From Michael Richardson (in its entirety)
Subject: [57crew] IETF anchored interop testing
Date: Monday 28 July 2003 11:53
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: ietf-secretariat@ietf.org, Brett Thorson <bthorson@ietf.org>
Cc: hugh@xisp.net, martin.steimerling@ccrle.nec.de, Edward Lewis
<edlewis@arin.net>, Bill Manning <bmanning@ISI.EDU>, paul.hoffman@vpnc.org,
57crew@ietf.org, Sabine.Beauvois@etsi.org, Andrew McGregor
<andrew@indranet.co.nz>
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
various WGs have attempted to organize interop/plug testing either before or after IETF sessions. Sometimes during. I am aware of IPsec, HIP, DNSSEC, and DHCPv6 tests that have occured or been attempted in the past year.
I wanted to arrange a manner in which we might organize this kind of thing in a more organized, less ad-hoc manner. I wanted to propose that a mailing list be set up that included someone from the secretariat, as well as interested parties.
Primarily, I am interesting in reducing the lead time for getting things organized - in great part so that the cost to the participants of attending such a plugtest is reduced into the noise level compared to IETF itself.
If we can do this @ietf.org, that would be great. If not, let me know,
and I will create a list elsewhere.
I will save conversation about my thoughts about logistics for the list itself.
------------------------------------------------------------
Message #2 From Bill Manning (excerpt)
(NOTE: In his message, Bill forwarded Message #1 from Michael Richardson, and added one sentence. The excerpt contains the additional sentence.)
Envelope-to: bfuller@foretec.com
From: Bill Manning <bmanning@ISI.EDU>
Subject: Re: IETF anchored interop testing
To: mcr@sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu, 4 Sep 2003 02:59:28 -0700 (PDT)
Cc: ietf-secretariat@ietf.org, bthorson@ietf.org, hugh@xisp.net,
martin.steimerling@ccrle.nec.de, edlewis@arin.net, bmanning@ISI.EDU,
paul.hoffman@vpnc.org, 57crew@ietf.org, Sabine.Beauvois@etsi.org,
andrew@indranet.co.nz, bmanning@ep.net
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
There are some rumblings of doing another series of
testing in Korea prior to the IETF next spring.
--bill
------------------------------------------------------------
Message #3 From Kevin Almeroth (in its entirety, but without headers)
(NOTE: This message was forwarded to me by Brett Thorson who originally received it. Kevin Almeroth is the head of the multicast group at the University of Oregon that provides multicast support at the IETF meetings.)
On Tue, 26 Aug 2003, Kevin C. Almeroth wrote:
Brett, don't know if I have the right email for Jim, but I think I do. Okay...
So, we are planning a pretty interesting/aggressive project for the Minn IETF and we wanted to get your feedback.
First, the "we" is me, Elizabeth Belding-Royer (a faculty member here who is active with Charlie Perkins in the Ad hoc area), and our usual group of students.
Second, we are building (soon to be "have built") a plug-in that allows a laptop to run in true ad hoc mode. The idea is to use other such laptops to build a "real" ad hoc network. My personal idea is to be able to use these ad hoc nodes to extend connectivity into the upper floors of the hotel. A better idea would be if there is an area that could use wireless access, but for some reason (money, AP access, etc.) there won't be. Based on what ya'll know about the layout, do you have any idea on whether Minn will have this?
Third, we want to conduct a parallel experiment to start doing a better job tracking and collecting stats about what is happening on the wireless network. I wanted to do this in Vienna but the goobers couldn't figure out how to do what I wanted. Basically, I'd like to periodically dump a variety of SNMP data from the APs. The problems in Vienna seemed to be that they'd already configured the APs to ONLY listen to one address and they'd also configured them to ONLY do fault alarms... So, anyway we can set up to collect decent information?
Thanks for your support. :-)
-Kevin
------------------------------------------------------------
Message #4 From Michael Richardson (almost in its entirety...extraneous sentence omitted)
(NOTE: Brett sent Michael Richardson and Kevin Almeroth a note asking for more details about their testing plans for Minneapolis. He cc'd the mailing list for his IETF "meeting crew" on the note. Message #4 is Michael Richardson's response to Brett's note.)
Subject: Re: Testing at the IETF
Date: Tuesday 09 September 2003 15:20
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: Brett Thorson <bthorson@foretec.com>
Cc: "Kevin C. Almeroth" <almeroth@cs.ucsb.edu>
>>>>> "Brett" == Brett Thorson <bthorson@foretec.com> writes:
Brett> Hi there Michael & Kevin.
Brett> It has come to my attention that both of you would like to do some
Brett> testing at the IETF meetings (and from what I understand, at the
Brett> Minneapolis IETF meeting). The Acting IETF Director has discussed
Brett> this idea with Harald (The IETF Chair) and he would like me to
Brett> collect from you a description of what you will be testing /
Brett> providing, and your goals.
I am not specifically interesting in doing it *at* IETF, but rather
immediately preceeding - Friday/Saturday.
My impression from being involved with network setup is that it is much easier to be the guinea pigs as the network goes up, rather than try and get the network to remain up after Friday.
And in general, I was hoping that this could become a tradition rather
than just an incidental occurance.
Brett> If you could get this to me by 1300 Eastern Time Thursday
Brett> 2003/11/09, I can then submit it for the weekly discussion.
The protocols that I have in mind are:
IPsec IKEv2
DNSSEC
I can not be certain at this time that there is sufficient interest in
either of them at this time, but I will attempt to determine this by
Thursday.
------------------------------------------------------------
Message #5 From Michael Richardson (in its entirety)
(NOTE: Chris Liljenstolpe, who is on the mailing list for Brett's "meeting crew," responded to Brett's note with a question, and Michael Richardson responded to Chris. Message #5 is Michael's response to Chris's question.)
Subject: Re: [58crew] Testing at the IETF
Date: Tuesday 09 September 2003 15:29
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: Chris Liljenstolpe <cds@io.com>
Cc: Brett Thorson <bthorson@foretec.com>, "Kevin C. Almeroth"
<almeroth@cs.ucsb.edu>
>>>>> "Chris" == Chris Liljenstolpe <cds@io.com> writes:
Chris> What kind of testing?
I can't speak for Kevin, since I don't know what he is after.
In general, what we are looking for is a tradition of having some
room(s) with a network drop that becomes live on the IETF network earlier, ideally Friday morning. With real IPv4 and IPv6 space alive.
Pretty much anyone who wants to do testing winds up needing some amount of Internet, but we one 9 of reliability is probably enough.
What? DNSSEC, IPsec is what I do.
I think most groups could easily deal with bring hubs/switches, etc. We would not bring wireless if asked not to.
------------------------------------------------
----------------------------------------------------------------
Envelope-to: bfuller@foretec.com
From: Brett Thorson <bthorson@foretec.com>
To: "Barbara B. Fuller" <bfuller@foretec.com>
Subject: Testing @ IETF Meeting
Date: Thu, 11 Sep 2003 14:20:22 -0400
User-Agent: KMail/1.5
If the IESG decides to approve of the testing, they should be aware of the
added difficulties & cost that it adds to the host and/or Foretec.
>From some previous e-mails it reads that some of these testers were expecting
the network to be up and running when they got there (which would be before
the meeting). Trying to setup a network with "experiments" going on,
increases the level of stress while trying to get this network up and
running. On the back end, leaving the network run longer for testers is just
that many more days added onto a really long week (for the NOC Crew).
One of the considerations should also be the cost of this event. If we are
going to sanction testing before or after the meeting, some level of network
infrastructure will need to be setup before or remain after the meeting.
Even now, we have a hard time getting into these rooms before the meeting. The
hotel would rather sell them to a customer, rather than letting us in for
free before we have officially purchased the room. Also with the hotels now
adding more wiring to the buildings, and the IETF using that wiring, we also
incur the additional costs of using their infrastructure for these days. In
some cases (Such as Minneapolis) we have received gracious considerations
from both Onvoy and U of M in providing Internet circuits. Right now, they
are donating these to the IETF. Would we then need to offer some sort of fee
to them for using their networks beyond the official IETF meeting?
If we get into a hotel that doesn't mind us being there early, and lets us
leave the equipment there for as long as we want, or come in as early as we
want, then we still have the issue of people to set it up. (Hotel rooms,
meals, missed work, etc.)
All costs aside, it also encompasses a face to face issue. The relationship
that any host or secretariat has with the hotel is important. If you get a
good team at the hotel (and treat them right) the meeting is A LOT easier.
If these groups were to offer that they would show up at the hotel early, set
up their own equipment, I would also fear that these testers might not give
the hotel a good impression of the IETF. That would make our job (coming in
the week after, etc.) that much harder. The telecom guys especially, you
want to keep them happy, and starting off with a positive relationship is
VERY important.
Also take into consideration that the network quality expected at an IETF
meeting, is VERY different than the network expected at an Interop meeting.
People come to the IETF to work and attend meetings. I don't know a lot about
the Interop testing grounds, but I do know that they have a hot-stage event.
IETF usually does not. Most of our equipment (when Foretec has hosted the
meeting) is loaned and borrowed, and we usually don't get it until close to
meeting time. Making this hardware plug and play, with IETF expectations is
a different scenario then getting hardware early, hotstaging it, and finding
bugs and kinks early.
The possibility of a testing event is not out of our grasp. All the
challenges listed here have solutions. However, it doesn't appear that any
of the solutions are free. Nothing to say that it can't be done. I do think
having an open discussions about the costs & benefits of this event is worth
while.
Respectfully submitted,
Brett M. Thorson
---------------------------------------------------------------------------
On Monday 15 September 2003 13:13, Kevin C. Almeroth wrote:
> BTW, more info and a question. (I've CC'ed the person who will be running
> and coordinating the whole project: Krishan Ramachandran).
>
> Details on what we would like:
>
> 1. SNMP access (either from one of our UCSB machines or a
> machine we put at the IETF) to each wireless AP. From these
> APs we want to collect data from a variety of MIBs at intervals
> as short as one minute (or what load will allow without causing
> problems).
>
> 2. In conjunction with #1, we'd like to have access to all
> egress traffic so we can do a tcpdump of snaplen 60 bytes. We'll
> provide the machine, we just need a 100 Mbps Ethernet port.
>
> 3. We also want to set up a test network for supporting ad hoc
> networking. Basically, we'll set up 3-4 gateways at the edge
> of the IETF network and this will provide access to people with
> wireless cards who want to roam around using AODV. We'll
> eventualy be clearer about what our needs are from the IETF
> but this is the basic idea for now.
>
> The question: do you know what which vendors AP you'll be
> using? It makes a difference because each implements a
> different set of MIBs (related to #1).
>
> -Kevin
------------------------------------------------
7.3 Referral of draft-klensin-name-filters-03.txt to the IAB (Ted Hardie)
1. Architectural question to IAB
Document draft-klensin-name-filters-03.txt has been sent
to the RFC editor for publication and referred to the IESG
for review as an Informational RFC. The draft raises an
issue related to protocol processing which seems fairly
important, which can be summarized as:
"What issues should be considered when deciding when
and how to apply validity checks for protocol
processing not conducted by the application applying
the validity check?"
To steal a concrete example, what might be the issues in an
application pre-checking the syntactical validity of a DNS
name prior to passing it to the DNS?
2. Type of response expected
The IESG expects two things in response:
- a review of the Klensin draft and
- a short document describing the issues.
Note that this is not asking IAB to re-write the Klensin
draft, which explicitly does not take on this task:
"this document takes no position on whether or not the
testing is desirable. It only identifies the correct
tests to be made if tests are to be applied."
3. Response expected by: November 7, 2003.
4. Specific IAB people the IESG considers to have the best
background are: Leslie Daigle, Rob Austein, Patrik Falstrom