Please Review: Documents on IESG Agenda for October 13, 2005 Tele chat

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

AAA-doctors,

My bi-weekly request/plea for review, specifically from a
AAA point of view.

Please send comments (if any) no later than Wed 12Oct 2005. 

Thanks, 
Bert

-----Original Message-----
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-ips-ifcp-mib-07.txt
    Definitions of Managed Objects for iFCP (Proposed Standard) - 1 of 5 
    Note: This 
    Token: Allison Mankin
  o draft-ietf-sipping-app-interaction-framework-05.txt
    A Framework for Application Interaction in the Session Initiation Protocol 
    (SIP) (BCP) - 2 of 5 
    Note: PROTO shepherd: Rohan Mahy, rohan@ekabal.com. Last Call ends 12 
    October.Aa LC review encouraged, even though document is. currently set for 
    IESG agenda 
    Token: Allison Mankin
  o draft-ietf-pwe3-iana-allocation-12.txt
    IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) (BCP) - 3 of 
    5 
    Token: Mark Townsley
  o draft-ietf-dnsext-rfc2538bis-08.txt
    Storing Certificates in the Domain Name System (DNS) (Proposed Standard) - 
    4 of 5 
    Note: Olaf Kolkman is the PROTO shepherd for this document.Aa 
    Token: Margaret Wasserman
  o Two-document ballot:  - 5 of 5
     - draft-ietf-ltru-initial-05.txt
       Initial Language Subtag Registry (Informational) 
       Note: Document shepherd is Randy Presuhn 
       <randy_presuhn@mindspring.com> 
     - draft-ietf-ltru-registry-13.txt
       Tags for Identifying Languages (BCP) 
       Note: Document shepherd is Randy Presuhn 
       <randy_presuhn@mindspring.com> 
    Token: Scott Hollenbeck

2.1.2 Returning Item
  o draft-ietf-avt-rtp-retransmission-12.txt
    RTP Retransmission Payload Format (Proposed Standard) - 1 of 2 
    Note: proto shepherd: colin perkins (csp@csperkins.org). Need to check on 
    Discusses - DLNA requests approval by 12 Oct.  The. rev was given to 
    the ADs (not published) Aug 22, then submitted Sep 15. with another request 
    for re-review.  (Before Aug: some discussion of the issues). 
    Token: Allison Mankin
  o draft-ietf-ssm-arch-07.txt
    Source-Specific Multicast for IP (Proposed Standard) - 2 of 2 
    Token: Alex Zinin


2.2 Individual Submissions
2.2.1 New Item
NONE
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 Three-document ballot:  - 1 of 3
     - draft-ietf-rserpool-arch-10.txt
       Architecture for Reliable Server Pooling (Informational) 
       Note: PROTO Shepherd: Maureen Stillman 
     - draft-ietf-rserpool-comp-10.txt
       Comparison of Protocols for Reliable Server Pooling (Informational) 
       Note: PROTO Shepherd: Maureen Stillman 
     - draft-ietf-rserpool-threats-05.txt
       Threats Introduced by Rserpool and Requirements for Security in response 
       to Threats (Informational) 
       Note: PROTO Shepherd: Maureen Stillman 
    Token: Jon Peterson
  o draft-ietf-xcon-conference-scenarios-05.txt
    Conferencing Scenarios (Informational) - 2 of 3 
    Token: Allison Mankin
  o draft-ietf-sipping-message-tag-00.txt
    Internet Assigned Number Authority (IANA) Registration of the Message Media 
    Feature Tag (Informational) - 3 of 3 
    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
NONE
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
NONE
3.3.2 Returning Item
NONE