[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Please review documens on IESG Agenda for January 19, 2006
AAA-doctors, as always, pls review and send me comments
by wednesday Jan 18th.
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 draft-ietf-msec-policy-token-sec-05.txt
Group Security Policy Token v1 (Proposed Standard) - 1 of 9
Token: Russ Housley
o draft-ietf-sieve-vacation-05.txt
Sieve Email Filtering: Vacation Extension (Proposed Standard) - 2 of 9
Note: Document shepherd is Cyrus Daboo <cyrus@daboo.name>
Token: Scott Hollenbeck
o draft-ietf-dnsext-tsig-sha-05.txt
HMAC SHA TSIG Algorithm Identifiers (Proposed Standard) - 3 of 9
Note: 1/12/06:A' Waiting for -06 version to address LC comments.A' The
PROTO Shepherd for this document is Olafur Gudmundsson
<ogud@ogud.com>.
Token: Margaret Wasserman
o draft-ietf-ldapbis-strprep-06.txt
LDAP: Internationalized String Preparation (Proposed Standard) - 4 of 9
Token: Ted Hardie
o draft-ietf-ldapbis-syntaxes-11.txt
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
(Proposed Standard) - 5 of 9
Token: Ted Hardie
o draft-ietf-ldapbis-user-schema-10.txt
LDAP: Schema for User Applications (Proposed Standard) - 6 of 9
Token: Ted Hardie
o draft-ietf-l2vpn-signaling-06.txt
Provisioning, Autodiscovery, and Signaling in L2VPNs (Proposed Standard) -
7 of 9
Token: Mark Townsley
o draft-ietf-pwe3-fcs-retention-04.txt
PWE3 Frame Check Sequence Retention (Proposed Standard) - 8 of 9
Token: Mark Townsley
o draft-ietf-mobike-protocol-07.txt
IKEv2 Mobility and Multihoming Protocol (MOBIKE) (Proposed Standard) - 9 of
9
Note: Proto shepherd is Jari Arkko <jari.arkko@ericsson.com>
Token: Russ Housley
2.1.2 Returning Item
o draft-ietf-l2vpn-vpls-bgp-06.txt
Virtual Private LAN Service (Proposed Standard) - 1 of 2
Note: This document and draft-ietf-l2vpn-vpls-ldp are different solutions
to similar problems. L2VPN agreed to advance both and essentially "let the
market decide."
Token: Mark Townsley
o draft-ietf-l2vpn-vpls-ldp-08.txt
Virtual Private LAN Services over MPLS (Proposed Standard) - 2 of 2
Note: This document and draft-ietf-l2vpn-vpls-bgp are different solutions
to similar problems. L2VPN agreed to advance both and essentially "let the
market decide."
Token: Mark Townsley
2.2 Individual Submissions
2.2.1 New Item
o draft-zeilenga-ldap-ext-09.txt
Considerations for LDAP Extensions (BCP) - 1 of 1
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-l3vpn-ipsec-2547-05.txt
Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs
(Experimental) - 1 of 4
Token: Mark Townsley
o draft-ietf-l2vpn-requirements-06.txt
Service Requirements for Layer 2 Provider Provisioned Virtual Private
Networks (Informational) - 2 of 4
Token: Mark Townsley
o draft-ietf-tls-ecc-12.txt
ECC Cipher Suites for TLS (Informational) - 3 of 4
Note: Proto shepherd is Eric Rescorla <ekr@networkresonance.com>.
Token: Russ Housley
o draft-ietf-dhc-pxe-options-02.txt
DHCP Preboot eXecution Environment (PXE) Options (Informational) - 4 of 4
Note: The PROTO Shepherd for this document is Ralph Droms
<rdroms@cisco.com>.
Token: Margaret Wasserman
3.1.2 Returning Item
NONE
3.1.3 For Action
o draft-ietf-ccamp-gmpls-ason-lexicography-06.txt
A Lexicography for the Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within The Context of the ITU-T's
Automatically Switched Optical Network (ASON) Architecture (Informational)
- 1 of 1
Note: The ITU-T wishes to refer to this document in G.8081 Amendment, to be
consented in their meeting Feb 6 to Feb 17 so we should request expedited
publication by February 10th.
Token: Bill Fenner
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