Subject: [Gen-art] A *new* batch of IETF LC reviews - 13 Sept 2007

From: "Mary Barnes" <[email-masked]>
Date: Thu, 13 Sep 2007 21:22:16 -0500

Hi all,

Here's this week's LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included at the end of the assignments.  

Note, there's a lot of assignments (22) this week (including those for
the telechat next week), so I have pulled in a couple people from
"Reserves" AND folks that have docs on the telechat may also be getting
new LC assignments. However, I have only done the latter in the case
that your telechat assignments are for docs that you've already reviewed
for LC. Overall, almost everyone is getting one new assignment this
week. 

Thanks, 
Mary. 

--------------------------- 
Reviewer: Vijay Gurbani

- 'Signaling MIB for PacketCable and IPCablecom Multimedia Terminal 
   Adapters (MTAs) '
   <draft-ietf-ipcdn-pktc-signaling-15.txt> as a Proposed Standard

IETF LC ends on 2007-09-24. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-15.t
xt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
9514&rfc_flag=0

--------------------------- 
Reviewer: Elwyn Davies

- 'Deprecation of Type 0 Routing Headers in IPv6 '
   <draft-ietf-ipv6-deprecate-rh0-01.txt> as a Proposed Standard

IETF LC ends on 2007-09-24. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
16026&rfc_flag=0

--------------------------- 
Reviewer: Ben Campbell

- 'Dynamic Authorization Extensions to Remote Authentication Dial In
User Service (RADIUS) '
   <draft-ietf-radext-rfc3576bis-09.txt> as an Informational RFC

IETF LC ends on 2007-09-24. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15614&rfc_flag=0

--------------------------- 
Reviewer: Christian Vogt

- 'Session Initiation Protocol (SIP) User Agent Capability Extension to 
   Presence Information Data Format (PIDF) '
   <draft-ietf-simple-prescaps-ext-08.txt> as a Proposed Standard

IETF LC ends on 2007-09-25. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-08.tx
t

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
11411&rfc_flag=0

--------------------------- 
Reviewer: Gonzalo Camarillo

- 'IP Multicast Requirements for a Network Address (and port) Translator
   (NAT) '
   <draft-ietf-behave-multicast-10.txt> as a BCP

IETF LC ends on 2007-09-25. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-10.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
13134&rfc_flag=0

--------------------------- 
Reviewer: Joel Halpern

- 'An Extensible Markup Language (XML) Patch Operations Framework 
   Utilizing XML Path Language (XPath) Selectors '
   <draft-ietf-simple-xml-patch-ops-03.txt> as a Proposed Standard

IETF LC ends on 2007-09-25. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-03.t
xt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
14052&rfc_flag=0

--------------------------- 
Reviewer: Mark Allman

- 'Preventing Use of Recursive Nameservers in Reflector Attacks '
   <draft-ietf-dnsop-reflectors-are-evil-04.txt> as a BCP

IETF LC ends on 2007-09-25. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil
-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
14686&rfc_flag=0

--------------------------- 
Reviewer: Miguel Garcia

- 'MIB for the UDP-Lite protocol '
   <draft-ietf-tsvwg-udplite-mib-01.txt> as a Proposed Standard

IETF LC ends on 2007-09-26. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udplite-mib-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
16141&rfc_flag=0

--------------------------- 
Reviewer: Pasi Eronen

- 'Experiment in Study Group Formation within the Internet Engineering 
   Task Force (IETF) '
   <draft-aboba-sg-experiment-02.txt> as an Experimental RFC

IETF LC ends on 2007-10-08. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
16256&rfc_flag=0

--------------------------- 
Reviewer: Robert Sparks

- 'EAP-IKEv2 Method '
   <draft-tschofenig-eap-ikev2-14.txt> as an Experimental RFC

IETF LC ends on 2007-10-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-14.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
10250&rfc_flag=0

--------------------------- 
Reviewer: Scott Brim

- 'A Uniform Resource Name Namespace For The EPCglobal Electronic 
   Product Code (EPC) and Related Standards '
   <draft-mealling-epc-urn-02.txt> as an Informational RFC

IETF LC ends on 2007-10-11. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-mealling-epc-urn-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
13012&rfc_flag=0

-------------------------------------------------------------------

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Sep 2007 14:52:06 -0400

Checking the records, I see that I am the assigned gen-art reviewer for:
     Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)

This document seems to be in a revision-needed state from last June, 
so it is quite possible that these comments have been overtaken by events.

Summary: This document appears ready for publication as an Informational RFC

Minor comments:
         In section 3.2 on architecture the acronym S-PE is used in 
Figure 2 and the text thereafter with no expansion.  It would be a 
good idea to put in the meaning of S-PE just before it is used, as is 
done with T-PE.  (It is expanded in the next paragraph.  The 
guideline I was taught was to always expand at first use.)

         I found the wording of requirement iv (in section 
6.1.1)  "The MS-PWs MUST be composed of SS-PWs." slightly odd.  The 
rest of the document is written so that one thinks of an MS-PW as 
composed of segments, and an SS-PW as being composed of a single 
segment.  I think this requirement is intended to say that individual 
segments behave just like SS-PWs.  But I am not sure.

      Does the "should" in section 6.3.2 on Statically configured 
MPLS-PW based MS-PWs (about the need for in-band PW OAM capabilities) 
belong as a "SHOULD".  Note: If this is a "SHOULD" then the best 
practice is to at least provide an example of when the specified 
behavior is not required.
         The same question apples to "should" in sections 6.3.3 and 
6.4.2 on Resiliency.
         (These comments on "SHOULD" are prompted by the presence of 
several capitalized MUST and MAY clauses earlier in the document.)
         There appear to actually be a lot of these, including "must" 
in the rest of section 6.  I will not call out each one.  It is 
particularly eye catching when in the list in section 6.4.3 on 
Quality of service the first two bullet items use "must" and the next 
two use "MUST"