[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please review documents on IESG agenda for March 30, 2006 Telechat
... and thanks Bert, for the wonderful job that you have been doing all
these years. I hope that we will enjoy your participation and advice for
many years ahead.
Dan
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, March 24, 2006 2:55 AM
> To: Aaa-Doctors (E-mail)
> Cc: Romascanu, Dan (Dan)
> Subject: Please review documents on IESG agenda for March 30,
> 2006 Telechat
>
> 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=vie
w_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