[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pls review documents on IESG agenda for March 16



AAA doctors,

as allways, your review of these documents would be appreciated,
specifically from a AAA point of view.

Any comments should be in my inbox by Thursday 9am US EST at the latest.
Earlier is better.

Thanks,
Bert

--------
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 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
  o draft-ietf-disman-remops-mib-v2-09.txt
    Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup 
    Operations (Proposed Standard) - 2 of 8 
    Note: IETF Last Call ends March 9th.. Sofar only one minor comment has been 
    received. 
    Token: Bert Wijnen
  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
  o draft-ietf-ipcdn-device-mibv2-11.txt
    Cable Device Management Information Base for Data-Over-Cable Service 
    Interface Specification Compliant Cable Modems and Cable Modem Termination 
    Systems (Proposed Standard) - 4 of 8 
    Note: PROTO-shepherding by Jean Francois: jf.mule@cablelabs.com 
    Token: Bert Wijnen
  o draft-ietf-avt-rfc2032-bis-13.txt
    RTP Payload Format for H.261 Video Streams (Proposed Standard) - 5 of 8 
    Note: Last Call ends 3-16 /  PROTO shepherd: 
    magnus.westerlund@ericsson.com / media types review: 
    http://www.alvestrand.no/pipermail/ietf-types/2006-February/001653.html 
    Token: Allison Mankin
  o draft-ietf-sasl-rfc2222bis-15.txt
    Simple Authentication and Security Layer (SASL) (Proposed Standard) - 6 of 
    8 
    Token: Sam Hartman
  o draft-ietf-avt-mime-h224-05.txt
    MIME type registration for RTP Payload format for H.224 (Proposed Standard) 
    - 7 of 8 
    Note: Last Call ends 3/16 / PROTO shepherd: magnus.westerlund@ericsson.com 
    / media types review: 
    http://www.alvestrand.no/pipermail/ietf-types/2006-February/001654.html 
    Token: Allison Mankin
  o rfc2613.txt
    Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 
    (Draft Standard) - 8 of 8 
    Note: IETF Last Call ends on March 9th 
    Token: Bert Wijnen

2.1.2 Returning Item
  o draft-ietf-pwe3-frame-relay-07.txt
    Encapsulation Methods for Transport of Frame Relay Over MPLS Networks 
    (Proposed Standard) - 1 of 1 
    Token: Mark Townsley


2.2 Individual Submissions
2.2.1 New Item
  o draft-songlee-aes-cmac-prf-128-03.txt
    The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) 
    (Proposed Standard) - 1 of 3 
    Token: Russ Housley
  o draft-fenner-iana-exp-2780-02.txt
    Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers 
    (Proposed Standard) - 2 of 3 
    Token: Margaret Wasserman
  o draft-bagnulo-cga-ext-01.txt
    Cryptographically Generated Addresses (CGA) Extension Field Format 
    (Proposed Standard) - 3 of 3 
    Note: 1/27/06:  Jari asked to have this published.  1/30/06:  Russ 
    suggested IPsec mailing list review, now ongoing in parallel with IETF LC.
    Token: Margaret Wasserman

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-tcpm-tcp-roadmap-06.txt
    A Roadmap for TCP Specification Documents (Informational) - 1 of 2 
    Note: PROTO Shepherd: Mark Allman 
    Token: Jon Peterson
  o draft-ietf-pce-architecture-04.txt
    A Path Computation Element (PCE) Based Architecture (Informational) - 2 of 
    2 
    Token: Alex Zinin

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-crockford-jsonorg-json-04.txt
    JavaScript Object Notation (JSON) (Informational) - 1 of 3 
    Token: Scott Hollenbeck
  o draft-hartman-mailinglist-experiment-01.txt
    Experimental Procedure for Long Term Suspensions from Mailing Lists 
    (Experimental) - 2 of 3 
    Note: Last call ends March 15 
    Token: Brian Carpenter
  o draft-harrington-8021-mib-transition-01.txt
    Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG (Informational) 
    - 3 of 3 
    Note: IETF Last Call ends on March 17th.. Some IETF Last Call comments 
    (mainly editorial) have been received.. I'd like to see IESG comments as 
    well, so we can do one more revision during IETF week and then hopefully be 
    done with this one. 
    Token: Bert Wijnen

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