[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pls review documents on IESG Agenda for September 1, 2005
AAA Doctors,
as always, pls review, specifically from an AAA viewpoint.
I need your comments (if any) no later than Wednesday August 31st.
Note that at this stage of the process, the main purpose of
the review is to check if you see major issues or any fatal flaws.
Minor issues or typos/language issues can be reported, but pls
mark them as such, so that the authors can work on them if
a new rev needs to be done anyway.
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-tls-rfc3546bis-01.txt
Transport Layer Security (TLS) Extensions (Proposed Standard) - 1 of 10
Token: Russ Housley
o Three-document ballot: - 2 of 10
- draft-ietf-lemonade-urlauth-07.txt
Internet Message Access Protocol (IMAP) - URLAUTH Extension (Proposed
Standard)
- draft-ietf-lemonade-burl-02.txt
Message Submission BURL Extension (Proposed Standard)
- draft-ietf-lemonade-catenate-05.txt
Internet Message Access Protocol (IMAP) CATENATE Extension (Proposed
Standard)
Token: Ted Hardie
o draft-ietf-avt-rtp-3gpp-timed-text-15.txt
RTP Payload Format for 3GPP Timed Text (Proposed Standard) - 3 of 10
Note: PROTO shepherd: magnus.westerlund@ericsson.com
Token: Allison Mankin
o draft-ietf-webdav-quota-07.txt
Quota and Size Properties for DAV Collections (Proposed Standard) - 4 of 10
Token: Ted Hardie
o draft-ietf-pkix-crlaia-02.txt
Internet X.509 Public Key Infrastructure Authority Information Access CRL
Extension (Proposed Standard) - 5 of 10
Note: proto shepherd: tim.polk@nist.gov
Token: Sam Hartman
o draft-ietf-secsh-newmodes-05.txt
SSH Transport Layer Encryption Modes (Proposed Standard) - 6 of 10
Note: proto shepherd: sommerfeld@sun.com
Token: Sam Hartman
o draft-ietf-secsh-break-04.txt
Secure Shell (SSH) Session Channel Break Extension (Proposed Standard) - 7
of 10
Token: Sam Hartman
o draft-ietf-xcon-bfcp-05.txt
The Binary Floor Control Protocol (BFCP) (Proposed Standard) - 8 of 10
Note: Last Call will end 9/2.Aa The companion mmusic document. got its Last
Call ending 9/1 and this one slipped over to the next day.Aa . If
IETF wide issues arise, it is possible to remove. the document from the
closely following IESG consideration. IETF Last Call review is
encouraged!
Token: Allison Mankin
o draft-ietf-mmusic-sdp-bfcp-02.txt
Session Description Protocol (SDP) Format for Binary Floor Control Protocol
(BFCP) Streams (Proposed Standard) - 9 of 10
Note: PROTO shepherd Colin Perkins csp@csperkins.org. IETF Last Call for
this document ends 9/1.Aa If there IETF wide issues arise, it is possible
to remove. the document from the closely following IESG consideration.Aa
IETF Last Call review is encouraged!
Token: Allison Mankin
o draft-ietf-secsh-gsskeyex-10.txt
GSSAPI Authentication and Key Exchange for the Secure Shell Protocol
(Proposed Standard) - 10 of 10
Token: Sam Hartman
2.1.2 Returning Item
o draft-ietf-pkix-rfc3770bis-03.txt
Certificate Extensions and Attributes Supporting Authentication in
Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
(Proposed Standard) - 1 of 1
Note: proto shepherd: tim.polk@nist.gov. Back on the agenda to see where we
are with Mark's discus.
Token: Sam Hartman
2.2 Individual Submissions
2.2.1 New Item
o draft-harris-ssh-arcfour-fixes-03.txt
Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
(Proposed Standard) - 1 of 2
Token: Sam Hartman
o draft-hoffman-rfc3664bis-04.txt
The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
(Proposed Standard) - 2 of 2
Token: Russ Housley
2.2.2 Returning Item
NONE
2.2.3 For Action
o draft-ekrema-smldn-00.txt
Standardization of Multilingualizing Domain Names(MLDN) (Proposed Standard)
- 1 of 1
Note: On the agenda to request IESG support for a DNP response to this
document (see ballot write-up and technical reviews in the tracker comments
section, as they become available).
Token: Margaret Wasserman
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-mip6-mipext-advapi-04.txt
Extension to Sockets API for Mobile IPv6 (Informational) - 1 of 2
Token: Margaret Wasserman
o draft-ietf-ipv6-ndproxy-03.txt
Neighbor Discovery Proxies (ND Proxy) (Experimental) - 2 of 2
Token: Margaret Wasserman
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-garcia-sipping-poc-isb-am-03.txt
A Session Initiation Protocol (SIP) Event Package and Data Format for
Various Settings in Support for the Push-to-talk Over Cellular (PoC)
Service (Informational) - 1 of 1
Note: Forwarded by SIPPING WG's Expert Reviewer, Gonzalo Camarillo, per RFC
3427. Sent for ietf-types review Aug 6
Token: Allison Mankin
3.2.2 Returning Item
NONE
3.2.3 For Action
o draft-hendrikx-wallis-urn-nzl-00.txt
A Uniform Resource Name (URN) Formal Namespace for the New Zealand
Government (Informational) - 1 of 1
Note: Sent to URN-NID for review
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