[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Please review documents on IESG agenda for March 30, 2006 Telecha t
AAA-doctors, pls review these documents, specifically for
AAA specific aspects.
I am stepping down tomorrow (Friday) and so the comments need
to go to this list or (if you want to send them private) to Dan.
Pls send them (if any, but an I read x and it is good/OK is
also welcome) no later than COB wednessday (any timezone).
Dan will be sending these messgae in the future.
Thank you all for your reviews in support of my role as AD.
Pls give Dan your support and help him do the best job possible!
Bert and Dan
-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary@ietf.org]
Sent: Thursday, March 23, 2006 18:30
To: IESG
Cc: Barbara.Fuller@neustar.biz; tme@multicasttech.com;
Amy.Vezza@neustar.biz; spencer@mcsr-labs.org
Subject: PRELIMINARY Agenda and Package for March 30, 2006 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the March 30, 2006 IESG Teleconference
This agenda was generated at 19:24:2 EDT, March 23, 2006
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
1.3 Approval of the Minutes
1.4 Review of Action Items
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-sasl-plain-08.txt
The Plain SASL Mechanism (Proposed Standard) - 1 of 2
Token: Sam Hartman
o draft-ietf-pkix-sim-07.txt
Internet X.509 Public Key Infrastructure Subject Identification Method
(SIM) (Proposed Standard) - 2 of 2
Token: Russ Housley
2.1.2 Returning Item
NONE
2.2 Individual Submissions
2.2.1 New Item
o draft-mcgrew-aes-gmac-esp-02.txt
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
(Proposed Standard) - 1 of 2
Note: The T11 FC-SP Working Group needs RFC number by Friday, May 19th.
Token: Russ Housley
o draft-saintandre-xmpp-iri-03.txt
Internationalized Resource Identifiers (IRIs) and Uniform Resource
Identifiers (URIs) for the Extensible Messaging and Presence Protocol
(XMPP) (Proposed Standard) - 2 of 2
Token: Ted Hardie
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item
o draft-ietf-pce-architecture-04.txt
A Path Computation Element (PCE) Based Architecture (Informational) - 1 of
2
Token: Alex Zinin
o draft-ietf-mboned-msdp-mib-01.txt
Multicast Source Discovery protocol MIB (Experimental) - 2 of 2
Token: Bert Wijnen
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.2.1 New Item
o draft-westerlund-mime-dls-01.txt
Media Type Registrations for Downloadable Sounds for MIDI (Informational) -
1 of 1
Token: Ted Hardie
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.
3.3.1 New Item
o draft-zorn-radius-port-type-03.txt
Additional Values for the NAS-Port-Type Attribute (Informational) - 1 of 1
Token: Bert Wijnen
3.3.2 Returning Item
NONE
3.3.3 For Action
o draft-xdlee-idn-cdnadmin-06.txt
Registration and Administration Guideline for Chinese Domain Names
(Informational) - 1 of 1
Token: Brian Carpenter
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. IAB News We can use
6. Management Issue
6.1 Ted Hardie as IESG liaison (Brian Carpenter)
7. Agenda Working Group News
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the March 30, 2006 IESG Teleconference
This package was generated at 19:24:2 EDT, March 23, 2006.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, March 30,
2006 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.
Jari Arrko---Will call in
Ross Callon---Will call in
Brian Carpenter---Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Spencer Dawkins---Will call in
Lisa Dusseault---Will call in
Lars Eggert---Will call in
Marshall Eubanks---Will call in
Bill Fenner---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Sam Hartman---Will call in
Russ Housley---Will call in
Cullen Jennings---Will call in
David Kessens---Will call in
Dave Meyer---Will call in
Ray Pelletier---Will call in
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Dan Romascanu---Will call in
Barbara Roseman---Will call in
Dinara Suleymanova---Will call in
Mark Townsley---Will call in
Amy Vezza---Will call in
Magnus Westerlund---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 877-597-9705.
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
706-679-1570. 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 5647852103 when prompted to do
so.
Please ignore the insructions for entering the "Leader PIN."
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
Country Number
Argentina Dial-In #: 08005557912
Australia Dial-In #: 1800008435
Austria Dial-In #: 0800291433
Bahamas Dial-In #: 18665985175
Belgium Dial-In #: 080071223
Brazil Dial-In #: 08008916186
Chile Dial-In #: 12300206915
China Dial-In #: 108007130752
China Dial-In #: 108001300752
Colombia Dial-In #: 018007001685
Costa Rica Dial-In #: 08000130935
Cyprus Dial-In #: 80095744
Czech Republic Dial-In #: 800142255
Denmark Dial-In #: 80881797
Dominican Republic Dial-In #: 18887514623
Finland Dial-In #: 0800115427
France Dial-In #: 0800908353
Germany Dial-In #: 08001815558
Greece Dial-In #: 0080018092017560
Hong Kong Dial-In #: 800900018
Hungary Dial-In #: 0680015814
Iceland Dial-In #: 8008217
India Dial-In #: 0008001001032
Indonesia Dial-In #: 0018030152017564
Ireland Dial-In #: 1800481100
Israel Dial-In #: 1809315366
Italy Dial-In #: 800786633
Jamaica Dial-In #: 18002150129
Japan Dial-In #: 00531115058
Korea (South) Dial-In #: 00308140504
Latvia Dial-In #: 8000826
Lithuania Dial-In #: 880090083
Luxembourg Dial-In #: 80024506
Malaysia Dial-In #: 1800808622
Mexico Dial-In #: 0018663165137
Monaco Dial-In #: 80093171
Netherlands Dial-In #: 08000223630
New Zealand Dial-In #: 0800448873
Norway Dial-In #: 80013866
Panama Dial-In #: 0018002018501
Peru Dial-In #: 080052204
Poland Dial-In #: 008001113626
Portugal Dial-In #: 800819404
Russian Federation Dial-In #: 81080023181012
Saint Kitts and Nevis Dial-In #: 18007449306
Singapore Dial-In #: 8001011539
South Africa Dial-In #: 0800992789
Spain Dial-In #: 900961265
Sweden Dial-In #: 020797816
Switzerland Dial-In #: 0800562493
Taiwan Dial-In #: 00801148630
Thailand Dial-In #: 001800132017580
Trinidad and Tobago Dial-In #: 18002031294
Turkey Dial-In #: 00800130098756
United Kingdom Dial-In #: 08000322417
Uruguay Dial-In #: 00040190036
Venezuela Dial-In #: 08001003433
(list updated 2006-01-18)
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 March 16, 2006 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
---------------------------------
Jari Arkko (Ericsson) / Incoming Internet Area
Ross Callon (Juniper Network) / Incoming Routing Area
Brian Carpenter (IBM) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA liaison
Leslie Daigle (Cisco) / IAB Chair
Spencer Dawkins (Futurewei) / Scribe
Lisa Dusseault (Microsoft) / Incoming Applications Area
Marshall Eubanks (Multicast Tech) / Scribe
Bill Fenner (AT&T) / Routing Area
Barbara Fuller (NSS) / IETF Secretariat
Ted Hardie (Qualcomm, Inc.)/ Applications Area
Sam Hartman (MIT) / Security Area
Scott Hollenbeck (VeriSign)/ Applications Area
Russ Housley (Vigil Security, LLC) / Security Area
Cullen Jennings (Cisco) / Incoming Real-time App. and Infra. Area
David Kessens (Nokia) / Operations and Management Area
Allison Mankin / Transport Area
Jon Peterson (NeuStar, Inc.) / Transport Area
Eric Rescorla / Temporary IAB Liaison
Joyce K. Reynolds (ISI) / RFC Editor liaison
Dan Romascanu (Avaya) / Incoming Operations and Management Area
Dinara Suleymanova (NSS) / IETF Secretariat
Mark Townsley (Cisco) / Internet Area
Amy Vezza (NSS) / IETF Secretariat
Margaret Wasserman / Internet Area
Magnus Westerlund (Ericsson) / Incoming Transport Area
Bert Wijnen (Lucent) / Operations and Management Area
Alex Zinin (Alcatel) / Routing Area
REGRETS
---------------------------------
Dave Meyer (Cisco/University of Oregon) / IAB Liaison
Ray Pelletier (ISOC) / IAD
Barbara Roseman (ICANN) / IANA liaison
MINUTES
---------------------------------
1. Administrivia
1.1 Approval of the Minutes
The narrative minutes of the February 16, 2006 teleconference were approved.
The minutes of the March 02, 2006 Teleconference were approved. The
Secretariat will place the minutes in the public archives
1.2 Documents Approved since the March 02, 2006 IESG Teleconference
1.2.1 Protocol Actions
o draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt (Proposed Standard)
o draft-ietf-dnsext-tsig-sha-06.txt (Proposed Standard)
o draft-ietf-l3vpn-ospf-2547-06.txt (Proposed Standard)
o draft-ietf-mip4-faerr-02.txt (Proposed Standard)
o draft-ietf-mmusic-comedia-tls-06.txt (Proposed Standard)
o draft-ietf-mobike-protocol-08.txt (Proposed Standard)
o draft-ietf-ospf-ospfv3-auth-08.txt (Proposed Standard)
o draft-ietf-pwe3-fcs-retention-04.txt (Proposed Standard)
o draft-ietf-pwe3-satop-05.txt (Proposed Standard)
1.2.2 Document Actions
o draft-edwards-mime-mxf-03.txt (Informational)
o draft-ietf-capwap-eval-00.txt (Informational)
o draft-ietf-capwap-objectives-04.txt (Informational)
o draft-ietf-ipngwg-icmp-name-lookups-15.txt (Experimental)
o draft-ietf-nemo-home-network-models-06.txt (Informational)
o draft-ietf-tsvwg-mlpp-that-works-04.txt (Informational)
o draft-ietf-v6ops-vlan-usage-01.txt (Informational)
1.3 Review of Action Items
DONE:
NONE
DELETED:
NONE
IN PROGRESS:
o Bert Wijnen to update I-D Checklist to talk about example phone numbers.
NEW:
NONE
1.4 Review of Projects
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Four-document ballot: - 1 of 8
- draft-ietf-dnsext-dhcid-rr-12.txt
A DNS RR for Encoding DHCP Information (DHCID RR) (Proposed Standard)
- draft-ietf-dhc-fqdn-option-12.txt
The DHCP Client FQDN Option (Proposed Standard)
- draft-ietf-dhc-ddns-resolution-11.txt
Resolution of FQDN Conflicts among DHCP Clients (Proposed Standard)
- draft-ietf-dhc-dhcpv6-fqdn-04.txt
The DHCPv6 Client FQDN Option (Proposed Standard)
Token: Margaret Wasserman
The documents were approved by the IESG pending an RFC Editor Note to be
prepared
by Margaret Wasserman. The Secretariat will send a working group submission
Protocol
Action Announcement that includes the RFC Editor Note.
o draft-ietf-disman-remops-mib-v2-09.txt - 2 of 8
Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
Operations (Proposed Standard)
Token: Bert Wijnen
The document was approved by the IESG pending an RFC Editor Note to be prepared
by
Bert Wijnen. The Secretariat will send a working group submission Protocol
Action
Announcement that includes the RFC Editor Note.
o Two-document ballot: - 3 of 8
- draft-ietf-netconf-ssh-06.txt
Using the NETCONF Configuration Protocol over Secure Shell (SSH) (Proposed
Standard)
- draft-ietf-netconf-prot-12.txt
NETCONF Configuration Protocol (Proposed Standard)
Token: Bert Wijnen
Margaret Wasserman formally recused herself from the discussion. The documents
remain under discussion by the IESG in order to resolve points raised by Bert
Wijnen on behalf of IANA.* [Bert Wijnen to provide text]
o draft-ietf-ipcdn-device-mibv2-11.txt - 4 of 8
Cable Device Management Information Base for Data-Over-Cable Service Interface
Specification Compliant Cable Modems and Cable Modem Termination Systems
(Proposed
Standard)
Token: Bert Wijnen
The document was approved by the IESG. The Secretariat will send a working
group submission Protocol Action Announcement that includes an RFC Editor
Note prepared by Bert Wijnen.
o draft-ietf-avt-rfc2032-bis-13.txt - 5 of 8
RTP Payload Format for H.261 Video Streams (Proposed Standard)
Token: Allison Mankin
The document was approved by the IESG. The Secretariat will send a working
group submission Protocol Action Announcement that includes an RFC Editor
Note prepared by Allison Mankin.
o draft-ietf-sasl-rfc2222bis-15.txt - 6 of 8
Simple Authentication and Security Layer (SASL) (Proposed Standard)
Token: Sam Hartman
The document remains under discussion by the IESG in order to resolve
points raised by Sam Hartman on behalf of IANA.*
o draft-ietf-avt-mime-h224-05.txt - 7 of 8
MIME type registration for RTP Payload format for H.224 (Proposed Standard)
Token: Allison Mankin
The document was approved by the IESG. The Secretariat will send a working
group submission Protocol Action Announcement that includes an RFC Editor
Note prepared by Allison Mankin.
o rfc2613.txt - 8 of 8
Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
(Draft Standard)
Token: Bert Wijnen
The document was approved by the IESG. The Secretariat will send a working
group submission Protocol Action Announcement.
2.1.2 Returning Item
o draft-ietf-pwe3-frame-relay-07.txt - 1 of 1
Encapsulation Methods for Transport of Frame Relay Over MPLS Networks (Proposed
Standard)
Token: Mark Townsley
The document was approved by the IESG. The Secretariat will send a working
group submission Protocol Action Announcement that includes an RFC Editor
Note prepared by Mark Townsley.
2.2 Individual Submissions
2.2.1 New Item
o draft-songlee-aes-cmac-prf-128-03.txt - 1 of 3
The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
(Proposed Standard)
Token: Russ Housley
The document was approved by the IESG. The Secretariat will send
an individual submission Protocol Action Announcement.
o draft-fenner-iana-exp-2780-02.txt - 2 of 3
Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers (Proposed
Standard)
Token: Margaret Wasserman
Bill Fenner formally recused himself from the discussion. The document remains
under discussion by the IESG in order to resolve points raised by Brian
Carpenter,
Russ Housley, and Mark Townsley.*
o draft-bagnulo-cga-ext-01.txt - 3 of 3
Cryptographically Generated Addresses (CGA) Extension Field Format (Proposed
Standard)
Token: Margaret Wasserman
The document remains under discussion by the IESG in order to resolve
points raised by Sam Hartman.*
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-tcpm-tcp-roadmap-06.txt - 1 of 2
A Roadmap for TCP Specification Documents (Informational)
Token: Jon Peterson
The document was approved by the IESG. The Secretariat will send a working
group
submission Document Action Announcement that includes an RFC Editor Note
prepared
by Jon Peterson.
o draft-ietf-pce-architecture-04.txt - 2 of 2
A Path Computation Element (PCE) Based Architecture (Informational)
Token: Alex Zinin
The document was deferred to the next IESG Teleconference (03/30/2006) by Sam
Hartman.*
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-crockford-jsonorg-json-04.txt - 1 of 3
JavaScript Object Notation (JSON) (Informational)
Token: Scott Hollenbeck
The document was approved by the IESG. The Secretariat will send an individual submission Document Action Announcement that includes an RFC Editor Note
prepared by Scott Hollenbeck.
o draft-hartman-mailinglist-experiment-01.txt - 2 of 3
Experimental Procedure for Long Term Suspensions from Mailing Lists
(Experimental)
Token: Brian Carpenter
Sam Hartman formally recused himself from the discussion. The document
remains under discussion by the IESG in order to resolve points raised
by Brian Carpenter.*
o draft-harrington-8021-mib-transition-01.txt - 3 of 3
Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG (Informational)
Token: Bert Wijnen
The document remains under discussion by the IESG in order to resolve
points raised by Bert Wijnen.*
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
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
o Security Issues in Network Event Logging (syslog) - 1 of 1
Token: Sam Hartman
The IESG approved the revised charter for the working group.
The Secretariat will send a WG Action: RECHARTER announcement.
5. IAB News We Can Use
6. Management Issues
6.1 Decision on PR-Action against JFC Morfin (Brian Carpenter)
The management issue was discussed. The IESG approved an RFC 3683
PR-action for JFC (Jefsey) Morfin. Sam Hartman and Margaret Wasserman
voted against this action. Mark Townsley and Alex Zinin abstained.
6.2 Approval of appeal response to Dean Anderson (Brian Carpenter)
The management issue was discussed. The IESG agreed to reject the
appeal made by Dean Anderson against the PR-action announced
on January 5, 2006.
6.3 Approval of appeal response to JFC Morfin (Brian Carpenter)
The management issue was not discussed. Brian Carpenter withdrew the
item at the start of the teleconference.
7. Working Group News We Can Use
-----------------------------------------------
* 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: March 6, 2006
IP o Bert Wijnen to update I-D Checklist to talk about example
phonenumbers.
1. Administrivia
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item - 1 of 2
o draft-ietf-sasl-plain-08.txt
The Plain SASL Mechanism (Proposed Standard)
Token: Sam Hartman
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-sasl-plain-08.txt to Proposed Standard
--------
Evaluation for draft-ietf-sasl-plain-08.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9912&rfc
_flag=0
Last Call to expire on: 2005-02-25
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ X ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
sasl mailing list <ietf-sasl@imc.org>,
sasl chair <tlyu@mit.edu>,
sasl chair <kurt@openLDAP.org>
Subject: Protocol Action: 'The Plain SASL Mechanism' to Proposed
Standard
The IESG has approved the following document:
- 'The Plain SASL Mechanism '
<draft-ietf-sasl-plain-06.txt> as a Proposed Standard
This document is the product of the Simple Authentication and Security Layer
Working Group.
The IESG contact persons are Sam Hartman and Russ Housley.
Technical Summary
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism. The PLAIN mechanism is intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command. This document
updates RFC 2595.
Working Group Summary
The working group came to rough consensus on this document. There
was some debate about how stringprep's desire to avoid comparison of
two strings both involving unassigned codepoints interacts with
situations where one string is transported by an IETF-controlled
protocol like this mechanism and the other string is the providence of
an implementation-specific protocol with broader applicability than
this specification.
Protocol Quality
This specification has been reviewed by Sam Hartman for the IESG.
RFC Editor Note
(Insert RFC Editor note here)
IESG Note
(Insert IESG Note here)
IANA Note
(Insert IANA Note here)
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item - 2 of 2
o draft-ietf-pkix-sim-07.txt
Internet X.509 Public Key Infrastructure Subject Identification Method
(SIM) (Proposed Standard)
Token: Russ Housley
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pkix-sim-07.txt to Proposed Standard
--------
Evaluation for draft-ietf-pkix-sim-07.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=9680&rfc
_flag=0
Last Call to expire on: 2006-03-20
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
pkix mailing list <ietf-pkix@imc.org>,
pkix chair <kent@bbn.com>,
pkix chair <wpolk@nist.gov>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure
Subject Identification Method (SIM)' to Proposed Standard
The IESG has approved the following document:
- 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)'
<draft-ietf-pkix-sim-06.txt> as a Proposed Standard
This document is the product of the Public-Key Infrastructure (X.509) Working
Group.
The IESG contact persons are Russ Housley and Sam Hartman.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-06.txt
Technical Summary
To distinguish among multiple individuals with the same name, it may
be necessary to include in a certificate some personal data that may
be considered sensitive. Examples of such personal ID data are U.S.
social security numbers and similar national ID numbers in other
countries. A certificate subject may be willing to disclose this data
to some relying parties (RPs), but not to everyone who may have access
to his/her certificate. Recall that certificates are often passed
over the Internet without encryption, stored in repositories that may
allow public access, and so on. Thus a wide range of possible
adversaries will have an opportunity to conduct offline attacks that
seek to reveal sensitive ID data if it is part of a certificate.
SIM is a technique for managing this problem of selective disclosure
of such sensitive (though not secret) ID data in the context of X.509
certificates. The SIM data is carried as a subject alternative name
(SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format,
also defined in this document. Because this data is carried in the
SAN, the subject name must itself be unique without the further
qualification provided by this other data, consistent with X.509 and
PKIX certificate requirements.
The PEPSI value is the result of applying a two-pass hash function to
the SIM data, employing a user-supplied password and a Registration
Authority supplied random number. An attacker trying to confirm a
guessed SIM value cannot employ a pre-computed dictionary attack, due
to the use of the random number. Nonetheless, selection of a poor
password by a user does allow an attacker to mount a focused, offline
guessing attack on a PEPSI value.
Three scenarios for use of SIM are described:
- If a relying party knows the user's SIM value, and uses
it to uniquely identify the user, the RP can confirm the
user's identify through processing of the certificate and
user disclosure of the password to the RP via a secure
channel.
- If the RP does not know the SIM value, it can be disclosed
to the RP via secure transfer of the password, and processing
of the certificate by the RP, e.g., so that the RP can
acquire the SIM value for future use.
- Finally, knowledge of the password by the user can be
employed as a secondary authentication mechanism, in
addition to the user's knowledge of his private key,
without exposing the SIM data to an RP.
Working Group Summary
The PKIX working group expressed consensus to advance the document to
Proposed Standard.
Protocol Quality
This document has been reviewed by PKIX working group and by the PKIX
working group chairs.
This document was reviewed by Russ Housley for the IESG.
Note to RFC Editor
Please add a sentence to the Introduction to highlight the dependency
on digital signature (as opposed to key management) certficates.
OLD:
In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
sensitive identifier information can be exchanged without disclosing
the identifier to an eavesdropper.
NEW:
This feature MUST be used only in conjunction with protocols that make
use of digital signatures generated using the subject's private key.
In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
sensitive identifier information can be exchanged without disclosing
the identifier to an eavesdropper.
Please expand the first use of "RA".
OLD:
R The random number value generated by an RA.
NEW:
R The random number value generated by a Registration
Authority (RA).
Please inser the missing new line in section 4.1.
OLD:
KISA specific OIDs id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
NEW:
KISA specific OIDs
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
2.1.2 Returning Item
NONE
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.2 Individual Submissions
2.2.1 New Item - 1 of 2
o draft-mcgrew-aes-gmac-esp-02.txt
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
(Proposed Standard)
Note: The T11 FC-SP Working Group needs RFC number by Friday, May 19th.
Token: Russ Housley
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-mcgrew-aes-gmac-esp-02.txt to Proposed Standard
--------
Evaluation for draft-mcgrew-aes-gmac-esp-02.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=13203&rf
c_flag=0
Last Call to expire on: 2005-12-12
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'The Use of Galois Message Authentication
Code (GMAC) in IPsec ESP' to Proposed Standard
The IESG has approved the following document:
- 'The Use of Galois Message Authentication Code (GMAC) in IPsec ESP '
<draft-mcgrew-aes-gmac-esp-00.txt> as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Russ Housley.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcgrew-aes-gmac-esp-00.txt
Technical Summary
AES-GMAC-ESP provides an ESP data origin authentication mechanism that
is amenable to high speed implementation. Unlike all other ESP
authentication mechanisms, it can be parallelized and can avoid
pipeline stalls. It is designed so that the incremental cost of
implementing it, given an implementation is AES-GCM-ESP (RFC4106), is
small.
Working Group Summary
This draft is not the product of any working group; however, it has
been reviewed by the Fibre Channel Security Protocols group in T11,
which is considering its adoption.
Protocol Quality
There is a software prototype implementation of the specification.
The document was brought to the attention of the CFRG, which raised no
concerns.
The document was brought to the attention of the IPsec mail list,
which raised no concerns.
This document was reviewed by Russ Housley for the IESG.
Note to RFC Editor
Please delete section 1.1 prior to publication.
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.2 Individual Submissions
2.2.1 New Item - 2 of 2
o draft-saintandre-xmpp-iri-03.txt
Internationalized Resource Identifiers (IRIs) and Uniform Resource
Identifiers (URIs) for the Extensible Messaging and Presence Protocol
(XMPP) (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-saintandre-xmpp-iri-03.txt to Proposed Standard
--------
Evaluation for draft-saintandre-xmpp-iri-03.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=13205&rf
c_flag=0
Last Call to expire on: 2006-03-15
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the Extensible
Messaging and Presence Protocol (XMPP)' to Proposed Standard
The IESG has approved the following document:
- 'Internationalized Resource Identifiers (IRIs) and Uniform Resource
Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
'
<draft-saintandre-xmpp-iri-03.txt> as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Scott Hollenbeck.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-iri-03.txt
Technical Summary
This document defines the use of Internationalized Resource
Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in
identifying or interacting with entities that can communicate via the
Extensible Messaging and Presence Protocol (XMPP).
Working Group Summary
This is an individual submission. It was discussed on the working group
mailing list of the former XMPP working group and on the URI-review mailing
list. Earlier versions of this document were also reviewed and discussed on
the URI mailing list, and substantial revisions took place in response to
feedback.
Protocol Quality
This draft was reviewed for the IESG by Ted Hardie. The original document
shepherd for this document was Scott Hollenbeck.
Note to RFC Editor
(Insert note to RFC Editor here)
IESG Note
(Insert IESG Note here)
IANA Note
(Insert IANA Note here)
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item - 1 of 2
o draft-ietf-pce-architecture-04.txt
A Path Computation Element (PCE) Based Architecture (Informational)
Token: Alex Zinin
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pce-architecture-04.txt to Informational RFC
--------
Evaluation for draft-ietf-pce-architecture-04.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=13013&rf
c_flag=0
Last Call to expire on:
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
David Kessens [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ X ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
DISCUSSES AND COMMENTS:
======================
Brian Carpenter:
Comment [2006-03-15]:
I'm slightly surprised that this has only one rather casual mention of the word
"loop". I'd have expected some discussion of loop avoidance. Similarly, the
assumption that QoS enters into path computation seems very casual given the
history of QoS-based routing.
Russ Housley:
Discuss [2006-03-16]:
Section 6.10 covers confidentiality requirements. Authentication
and integrity are even more important. Please expand this section
to cover all three topics. The Security Considerations section
touches on some of these points, but the document structure leads
the reader to the conclusion that confidentiality is more important
than authentication and integrity, which is false in this protocol
environment.
COMMENT
Section 1: Please spell out the first use of PCC, TED, and LSR.
Section 9.7: Why is this here? Please delete it.
David Kessens:
Comment [2006-03-16]:
I received the following comments by Pekka Savola from the OPS directorate thatyou might want to consider:
(Note: we don't run MPLS or GMPLS TE networks so review from someone
who does woudln't hurt..)
I read the draft and thought it was reasonably clear and easy to read.
There seemed to be a couple of internal inconsistancies (section x
said "foo", section y said "foo and bar") but nothing major. I think
the doc could easily be wrapped up in a month with one revision.
semi-substantial
----------------
4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC2547] and
for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing
computation on the ingress (TE LSP head-end) router, and that does
not rely on static loose hops configuration in which case optimal
shortest paths could not be achieved. A distinct PCE-based solution
can help here. Note that the PCE in this case may, itself, provide a
path that includes loose hops.
==> I'm not sure how relevant this scenario really is. If you don't
rely on external equipment (e.g., CE's, maybe under the customer
control or not) to participate in the routing domain for
administrative reasons, why could you rely on them doing TE decisions?
(which could hurt ISP's own TE decisions..) In any case, such nodes
basically just have a default route to the ISP, so I'm not sure why
they need to participate in TE at all..
Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state
given other recent PCE-computed paths changes.
==> do you assume that if a PCE computes a path, it will actually
automatically get used? The last sentence seems to imply that. (But
text further in the draft doesn't seem to assume that.) The router
could just also very well discard it. The path computations made to
PCC's seem irrelevant, as the PCEs should use solely TED to get info
about path changes. (This might imply that you might need to wait
until TED has been updated between each PCE computation to know if it
was activated or not...)
editorial
---------
4.8 Path Selection Policy
===> it might have been useful to briefly also mention the policy
synchronization here, because if you have multiple PCE's, that's pretty
important; whether that needs to be done out-of-band or using e.g., PCE-PCE
protocols remains to be seen.
5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be
performed along the path of a signaled service. As in the previous
example, the head-end PCC makes a request to an external PCE, but the
path that is returned is such that the next network element finds it
necessary to perform further computation. This may be the case when
the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. [...]
==> in section 5 or 6, you don't describe the scenario at all where PCC
sends in a request to a PCE, which fails to provide a reply or replies in
such a manner (e.g., the first hop is loose) that the PCC needs to contact
another PCE for better path information. On the other hand, the second
bullet in Section 7 seems to imply this is also possible. Is this an
intentional omission or should that scenario also be mentioned here?
(AFAICS, your the two cases addressed here are: 1) contact PCE, get enough
information to forward packets to the next hop, let that contact the same or
some other PCE, and 2) contact PCE, and assume inter-PCE communication to
sort it out.)
6.6. PCC-PCE & PCE-PCE Communication
==> you don't include any requirements on how the communication needs to be
1) secured (well, later in section 6.10 you have some but PCE-PCE or PCC-PCE
IMHO belong here; note that you'll probably want more than just
confidentiality, e.g., integrity), or
2) what kind of requirements there are for communication (e.g., how fast
should you notice if the communication doesn't form? or dies in the middle?)
[I note that some of this is under 6.5]
9.7. Other Considerations
No other management considerations arise.
==> hmm.. shouldn't you rather say, "No other management considerations have
been identified." ? :-)
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
pce mailing list <pce@ietf.org>,
pce chair <adrian@olddog.co.uk>,
pce chair <jpv@cisco.com>
Subject: Document Action: 'A Path Computation Element (PCE) Based
Architecture' to Informational RFC
The IESG has approved the following document:
- 'A Path Computation Element (PCE) Based Architecture '
<draft-ietf-pce-architecture-04.txt> as an Informational RFC
This document is the product of the Path Computation Element Working Group.
The IESG contact persons are Alex Zinin and Bill Fenner.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-04.txt
Technical Summary
This document specifies the architecture for a Path Computation
Element (PCE)-based model to address the problem of path computation
in large, multi-domain, multi-region or multi-layer networks. This
document describes a set of building blocks for the PCE architecture
from which solutions may be constructed.
Working Group Summary
The WG had a consensus on progressing this document.
Protocol Quality
Alex Zinin Reviewed this document for the IESG.
Note to RFC Editor
(Insert note to RFC Editor here)
IESG Note
(Insert IESG Note here)
IANA Note
(Insert IANA Note here)
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item - 2 of 2
o draft-ietf-mboned-msdp-mib-01.txt
Multicast Source Discovery protocol MIB (Experimental)
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-mboned-msdp-mib-01.txt to Experimental RFC
--------
Evaluation for draft-ietf-mboned-msdp-mib-01.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=11998&rf
c_flag=0
Last Call to expire on:
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
mboned mailing list <mboned@lists.uoregon.edu>,
mboned chair <ohta.hiroshi@lab.ntt.co.jp>,
mboned chair <tme@multicasttech.com>
Subject: Document Action: 'Multicast Source Discovery protocol MIB' to
Experimental RFC
The IESG has approved the following document:
- 'Multicast Source Discovery protocol MIB '
<draft-ietf-mboned-msdp-mib-01.txt> as an Experimental RFC
This document is the product of the MBONE Deployment Working Group.
The IESG contact persons are Bert Wijnen and David Kessens.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-msdp-mib-01.txt
Technical Summary
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers.
Working Group Summary
The WG has consensus to publish this document as an Experimental RFC.
There are existing implementations of this MIB module, which date back
several years, and so usage of IpAddress SYNTAX and DisplayString
in this (experimental) MIB module is a conscious decision and acceptable
at experimental level. The implementations are specific for IPv4 and so
is the MIB module.
Protocol Quality
Quick check with MIB doctors list for this experiment was done.
Bert Wijnen reviewed this document for the IESG.
Note to RFC Editor
- bottom of page 6, change module name:
OLD:
DRAFT-MSDP-MIB DEFINITIONS ::= BEGIN
NEW:
MSDP-MIB DEFINITIONS ::= BEGIN
- On page 10 at the bootom, replace:
OLD:
msdpRequestsStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
NEW:
msdpRequestsStatus OBJECT-TYPE
SYNTAX RowStatus { active(1), destroy(6) }
MAX-ACCESS read-create
IESG Note
(Insert IESG Note here)
IANA Note
(Insert IANA Note here)
3.1.2 Returning Item
NONE
3. Document Actions
3.2 Individual Submissions Via AD
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.2.1 New Item - 1 of 1
o draft-westerlund-mime-dls-01.txt
Media Type Registrations for Downloadable Sounds for MIDI (Informational)
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-westerlund-mime-dls-01.txt to Informational RFC
--------
Evaluation for draft-westerlund-mime-dls-01.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=13877&rf
c_flag=0
Last Call to expire on:
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
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 <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Media Type Registrations for Downloadable
Sounds for MIDI' to Informational RFC
The IESG has approved the following document:
- 'Media Type Registrations for Downloadable Sounds for MIDI '
<draft-westerlund-mime-dls-01.txt> as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Ted Hardie.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-01.txt
Technical Summary
The present document seeks to register a media type for
Downloadable Sounds (DLS). The DLS format is used to define
instruments for widely used wavetable synthesizers. The media
type defined here is needed to correctly identify DLS
files when they are served over HTTP, included in multi-part
documents, or used in other places where media types are used.
Working Group Summary
This is an individual submission. It was reviewed by the IETF types
list and changes were made in response to the feedback received.
Protocol Quality
The document was reviewed for the IESG by Ted Hardie. The underlying
standards for DLS standards are maintained and defined by two organizations,
the MIDI Manufacturers Association (MMA) and the Association of the Musical
Electronics Industry (AMEI).
Note to RFC Editor
(Insert note to RFC Editor here)
IESG Note
(Insert IESG Note here)
IANA Note
(Insert IANA Note here)
3.2.2 Returning Item
NONE
3. Document Actions
3.3 Individual Submissions Via RFC Editor
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.
3.3.1 New Item - 1 of 1
o draft-zorn-radius-port-type-03.txt
Additional Values for the NAS-Port-Type Attribute (Informational)
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-zorn-radius-port-type-03.txt to Informational RFC
--------
Evaluation for draft-zorn-radius-port-type-03.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=12910&rf
c_flag=0
Last Call to expire on:
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Brian Carpenter [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Sam Hartman [ ] [ ] [ ] [ ]
Scott Hollenbeck [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
David Kessens [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Mark Townsley [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
"Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
with no "Discuss" positions, are needed for approval.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>
Subject: Re: Informational RFC to be:
draft-zorn-radius-port-type-03.txt
The IESG has no problem with the publication of 'Additional Values for the
NAS-Port-Type Attribute' <draft-zorn-radius-port-type-03.txt> as an
Informational RFC.
The IESG would also like the RFC-Editor to review the comments in the
datatracker
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12910&rfc_flag=0)
related to this document and determine whether or not they merit incorporation
into the document. Comments may exist in both the ballot and the comment log.
The IESG contact person is Bert Wijnen.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-port-type-03.txt
Thank you,
The IESG Secretary
Technical Summary
This document defines a set of new values for the NAS-Port-Type
RADIUS Attribute.
Working Group Summary
This is not a WG document, but an independent submission via
RFC-Editor. The AAA Doctors group and RADEXT WG chairs have been
consulted if this work conflicts with current IETF work.
Protocol Quality
AAA-doctors conclude:
This document simply requires Designated Expert Review of the
port type values prior to IANA assignment. It appears
that the new port type values are sufficiently well defined
by reference to existing RFCs.
Note to RFC Editor
Pls insert IESG note number 2 of section 4 in RFC3932.
IESG Note
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and in particular notes that the decision to publish
is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at
its discretion. Readers of this document should exercise caution
in evaluating its value for implementation and deployment. See
RFC 3932 for more information.
IANA Note
(Insert IANA Note here)
3.3.2 Returning Item
NONE
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.3 For Action - 1 of 1
o draft-xdlee-idn-cdnadmin-06.txt
Registration and Administration Guideline for Chinese Domain Names
(Informational)
Token: Brian Carpenter
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
NONE
5. IAB News We Can Use
6. Management Issues
6.1 Ted Hardie as IESG liaison (Brian Carpenter)
To be minuted:
The IESG has appointed Ted Hardie as liaison to the IAB through May 2006,
pending review when the new ADs have gained experience.
7. Working Group News We Can Use