Pls review documents on IESG Agenda October 27, 2005 Telechat

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

As always, your review and comments (if any), specifically
from a SNMP/MIB/NM perspective will be appreciated.

Bert

-----Original Message-----
2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-mpls-lsp-ping-10.txt
    Detecting MPLS Data Plane Failures (Proposed Standard) - 1 of 6 
    Token: Alex Zinin
  o Two-document ballot:  - 2 of 6
     - draft-ietf-pim-sm-v2-new-11.txt
       Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol 
       Specification (Revised) (Proposed Standard) 
     - draft-ietf-pim-proposed-req-01.txt
       PIM Sparse-Mode IETF Proposed Standard Requirements Analysis 
       (Informational) 
    Token: Alex Zinin
  o draft-ietf-nfsv4-rfc1832bis-06.txt
    XDR: External Data Representation Standard (Standard) - 3 of 6 
    Token: Jon Peterson
  o draft-ietf-radext-chargeable-user-id-06.txt
    Chargeable User Identity (Proposed Standard) - 4 of 6 
    Token: David Kessens
  o draft-ietf-sieve-variables-07.txt
    Sieve Extension: Variables (Proposed Standard) - 5 of 6 
    Note: Document shepherd is Alexey Melnikov 
    <alexey.melnikov@isode.com> 
    Token: Scott Hollenbeck
  o draft-ietf-enum-iris-ereg-02.txt
    An ENUM Registry Type for the Internet Registry Information Service 
    (Proposed Standard) - 6 of 6 
    Note: Finishes Last Call on October 27.  On IESG agenda, however LC 
    comments urged and will be heeded. 
    Token: Allison Mankin

2.1.2 Returning Item
  o Three-document ballot:  - 1 of 1
     - draft-ietf-lemonade-urlauth-08.txt
       Internet Message Access Protocol (IMAP) - URLAUTH Extension (Proposed 
       Standard) 
     - draft-ietf-lemonade-burl-03.txt
       Message Submission BURL Extension (Proposed Standard) 
     - draft-ietf-lemonade-catenate-05.txt
       Internet Message Access Protocol (IMAP) CATENATE Extension (Proposed 
       Standard) 
       Note: Checking for revised DISCUSSes based on updates 
    Token: Ted Hardie


2.2 Individual Submissions
2.2.1 New Item
  o draft-hansen-2717bis-2718bis-uri-guidelines-06.txt
    Guidelines and Registration Procedures for new URI Schemes (BCP) - 1 of 2 
    Token: Scott Hollenbeck
  o draft-legg-ldap-binary-03.txt
    Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option 
    (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-ieprep-domain-req-05.txt
    Emergency Telecommunications Services (ETS) Requirements for a Single 
    Administrative Domain (Informational) - 1 of 2 
    Note: Note the RFC-Editor note that removes the reference in the Abstract. 
    Token: Jon Peterson
  o draft-ietf-xcon-floor-control-req-03.txt
    Requirements for Floor Control Protocol (Informational) - 2 of 2 
    Note: This was meant to go on the agenda when we considered 
    draft-ietf-xcon-bfcp, but. the AD mislaid the request and thought wrongly 
    this wasn't intended for ultimate publication. 
    Token: Allison Mankin

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-mccobb-xv-media-type-00.txt
    XHTML+Voice - application/xv+xml (Informational) - 1 of 1 
    Token: Scott Hollenbeck

3.2.2 Returning Item
  o draft-rharrison-lburp-05.txt
    LDAP Bulk Update/Replication Protocol (Informational) - 1 of 2 
    Token: Ted Hardie
  o draft-vandesompel-info-uri-04.txt
    The "info" URI Scheme for Information Assets with Identifiers in Public 
    Namespaces (Informational) - 2 of 2 
    Note: Handling may depend on the results of review of APP 
    draft-hansen-2717bis-2718bis-uri-guidelines-06.txt [Open Web Ballot] 
    Token: Ted Hardie

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
NONE
3.3.2 Returning Item
NONE