[MIB-DOCTORS] FW: UPDATED Agenda and Package for April 19, 2007 Telechat

["Romascanu, Dan \(Dan\)" <[e-mail]>]

Please find below the preliminary agenda of the 4/19 IESG telechat.
Please have a look at the documents proposed for approval and let me
know if there are any comments or concerns until 4/18 COB the latest. 

Note that the agenda includes one MIB document proposed for standards
and three CAPWAP initial submission documents that are proposed to be
published as informational RFCs. 

Thanks and Regards,

Dan
 



 

      
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-simple-presence-rules-09.txt
    Presence Authorization Rules (Proposed Standard) - 1 of 5 
    Token: Jon Peterson
  o draft-ietf-ips-isns-mib-11.txt
    Definitions of Managed Objects for iSNS (Internet Storage Name
Service) 
    (Proposed Standard) - 2 of 5 
    Note: PROTO Shepherd: David Black ([e-mail]). MIB Doctor:
Bert 
    Wijnen ([e-mail]). Initial expert review: Keith McCloghrie

    ([e-mail]) 
    Token: Lars Eggert
  o draft-ietf-rmt-fec-bb-revised-06.txt
    Forward Error Correction (FEC) Building Block (Proposed Standard) -
3
of 5 
    Token: Magnus Westerlund
  o draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
    IPv6 Over the IP Specific part of the Packet Convergence sublayer in
802.16 
    Networks (Proposed Standard) - 4 of 5 
    Note: NOTE: There are some LC and IEEE-review comments pending 
    Token: Jari Arkko
  o draft-ietf-behave-tcp-06.txt
    NAT Behavioral Requirements for TCP (BCP) - 5 of 5 
    Token: Magnus Westerlund

2.1.2 Returning Item
  o draft-ietf-pkix-lightweight-ocsp-profile-08.txt
    Lightweight OCSP Profile for High Volume Environments (Proposed
Standard) - 
    1 of 1 
    Token: Russ Housley


2.2 Individual Submissions
2.2.1 New Item
  o draft-siemborski-imap-sasl-initial-response-06.txt
    IMAP Extension for SASL Initial Client Response (Proposed Standard)
-
1 of 
    1 
    Token: Chris Newman

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-16ng-ipv6-link-model-analysis-03.txt
    Analysis of IPv6 Link Models for 802.16 based Networks
(Informational)
- 1 
    of 2 
    Note: PROTO Shepherd is Soohong Daniel Park 
    <[e-mail]> 
    Token: Jari Arkko
  o draft-ietf-trill-routing-reqs-02.txt
    TRILL Routing Requirements in Support of RBridges (Informational) -
2
of 2 
    Token: Mark Townsley

3.1.2 Returning Item
  o Five-document ballot:  - 1 of 1
     - draft-ietf-hip-base-07.txt
       Host Identity Protocol (Experimental) 
     - draft-ietf-hip-esp-05.txt
       Using ESP transport format with HIP (Experimental) 
     - draft-ietf-hip-registration-02.txt
       Host Identity Protocol (HIP) Registration Extension
(Experimental)

     - draft-ietf-hip-mm-05.txt
       End-Host Mobility and Multihoming with the Host Identity Protocol

       (Experimental) 
     - draft-ietf-hip-rvs-05.txt
       Host Identity Protocol (HIP) Rendezvous Extension (Experimental) 
    Token: Mark Townsley


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-allen-sipping-poc-p-answer-state-header-05.txt
    The P-Answer-State Header Extension to the Session Initiation
Protocol
for 
    the Open Mobile Alliance Push-to-talk over Cellular (Informational)
-
1 of 
    1 
    Note: SIPPING RFC 3427 Expert Reviewer is Gonzalo Camarillo;
dependency of 
    OMA 
    Token: Jon Peterson

3.2.2 Returning Item
NONE
3.3 Independent 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-iino-capwap-wicop-02.txt
    Wireless LAN Control Protocol (WiCoP) (Informational) - 1 of 2 
    Note: This document is an independent submission via the RFC Editor.
In 
    conformace with RFC 3932, Section 4, the IESG requests the
publication
of 
    the following note: "This RFC documents the WiCoP protocol as it was
when 
    submitted to the IETF as a basis for further work in the CAPWAP WG,
and 
    therefore it may resemble a current IETF work in progress or a
published 
    IETF work. This RFC itself 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 it has not had complete
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." 
    Token: Dan Romascanu
  o draft-ohara-capwap-lwapp-04.txt
    Light Weight Access Point Protocol (Informational) - 2 of 2 
    Note: This document is an independent submission via the RFC Editor.
In 
    conformace with RFC 3932, Section 4, the IESG requests the
publication
of 
    the following note: "This RFC documents the LWAPP protocol as it was
when 
    submitted to the IETF as a basis for further work in the CAPWAP WG,
and 
    therefore it may resemble a current IETF work in progress or a
published 
    IETF work. This RFC itself 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 it has not had complete
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." 
    Token: Dan Romascanu

3.3.2 Returning Item
  o draft-narasimhan-ietf-slapp-01.txt
    SLAPP : Secure Light Access Point Protocol (Informational) - 1 of 1 
    Note: This document is an independent submission via the RFC Editor.
In 
    conformace with RFC 3932, Section 4, the IESG requests the
publication
of 
    the following note: "This RFC documents the SLAPP protocol as it was
when 
    submitted to the IETF as a basis for further work in the CAPWAP WG,
and 
    therefore it may resemble a current IETF work in progress or a
published 
    IETF work. This RFC itself 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 it has not had complete
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.". 
    Token: Dan Romascanu



_______________________________________________
MIB-DOCTORS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mib-doctors