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

From: "Mary Barnes" <[email-masked]>
Date: Thu, 1 Nov 2007 21:06:00 -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.  

Thanks, 
Mary. 

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

- 'Requirements for Multicast Support in Virtual Private LAN Services '
   <draft-ietf-l2vpn-vpls-mcast-reqts-05.txt> as an Informational RFC

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-05
.txt

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

--------------------------- 
Reviewer: David Black

- 'L2VPN OAM Requirements and Framework '
   <draft-ietf-l2vpn-oam-req-frmk-09.txt> as an Informational RFC

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-09.txt

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

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

- 'VPLS Interoperability with CE Bridges '
   <draft-ietf-l2vpn-vpls-bridge-interop-02.txt> as an Informational RFC

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop
-02.txt

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

--------------------------- 
Reviewer: Eric Gray

- 'Failure Detection and Locator Pair Exploration Protocol for IPv6 
   Multihoming '
   <draft-ietf-shim6-failure-detection-09.txt> as a Proposed Standard

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-0
9.txt

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

--------------------------- 
Reviewer: Francis Dupont

- 'Definitions for Textual Conventions and for Managing Pseudowires 
   over PSN '
   <draft-ietf-pwe3-pw-tc-mib-12.txt> as a Proposed Standard

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-12.txt

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

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

- 'Pseudowire (PW) Management Information Base '
   <draft-ietf-pwe3-pw-mib-12.txt> as a Proposed Standard

IETF LC ends on 2007-11-09. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-12.txt

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

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

- 'Definition of Events For Channel-Oriented Telephony Signalling '
   <draft-ietf-avt-rfc2833biscas-05.txt> as a Proposed Standard

IETF LC ends on 2007-11-12. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833biscas-05.txt

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

--------------------------- 
Reviewer: Michael Patton
- 'Revised Civic Location Format for PIDF-LO '
   <draft-ietf-geopriv-revised-civic-lo-06.txt> as a Proposed Standard

IETF LC ends on 2007-11-12. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic-lo-
06.txt

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

--------------------------- 
Reviewer: Miguel Garcia
- 'Distributing a Symmetric FMIPv6 Handover Key using SEND '
   <draft-ietf-mipshop-handover-key-03.txt> as a Proposed Standard

IETF LC ends on 2007-11-14. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-handover-key-03.t
xt

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

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

- 'A More Loss-Tolerant RTP Payload Format for MP3 Audio '
   <draft-ietf-avt-rfc3119bis-05.txt> as a Proposed Standard

IETF LC ends on 2007-11-15. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3119bis-05.txt

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

--------------------------- 
Reviewer: Spencer Dawkins

- 'IPv4 Address Conflict Detection '
   <draft-cheshire-ipv4-acd-05.txt> as a Proposed Standard

IETF LC ends on 2007-11-23. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-cheshire-ipv4-acd-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
7869&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: Fri, 02 Nov 2007 12:25:44 -0400

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>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 

Document: Definition of Events For Channel-Oriented Telephony Signalling
Reviewer: Joel M. Halpern
Review Date:
IETF LC End Date: 2007-11-12
IESG Telechat date: (if known) not known

Summary: This document is ready for publication as a Proposed Standard

---

From: [email-masked]
Date: Mon, 5 Nov 2007 17:39:33 -0500

Folks,

I need someone to take this review for me - there's no way I'm going to
be able to get it done this week - any volunteers, please?  Thanks,
--David

Reviewer: David Black 

The file can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-09.txt
<http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-09.tx
t>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Nov 2007 17:41:54 -0500

I can take it.
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Nov 2007 21:45:25 -0500

Document: L2VPN OAM Requirements and Framework
Reviewer: Joel M. Halpern
Review Date: 2007-11-05
IETF LC End Date: 2007-11-09
IESG Telechat date: (if known) not known

Summary: This document is almost ready for publication as an
Informational RFC.
	There are several small items that need to be addressed.

Comments:

Right after referencing three different types of Layer 2 VPNS (VPWS,
VPLS, and IPLS) the text says that "The requirements are intended to
identify OAM requirements for L2VPN services (e.g. VPLS and VPWS)."  is
the omission of IPLS intentional?  If intentional, it should be
explained. (I suspect that the intended answer is that IPLS are VPLS,
but the text currently reads inconsistently.)

Given that section 3.1 says that the only underlying mechanism of
interest is MPLS/IP, it would probably be a good idea to say that same
thing in the very well written introduction.  (I am sure it is implicit
in the terminology, but it seems a good idea to state it anyway.)  Or
section 3.1 could be reworded not to say that the underlying transport
must be MPLS/IP.

In describing diagram 5(D), it might be helpful if there were a little
text explaining that the boundary between network operators must be MIPs
for the Service Provider, and visible to the service provider, precisely
because they are the MEPs for the individual network operator.  (I got
stalled for a few minutes because I tried to compare with IP, where the
customer does not see the ISP border routers differently from the ISP
internal routers.  But this case is different.)  I realize the need is
inherent in the required architecture.  Just a few words might have
prevented a reader getting confused.

In the VPLS case, the Service Provider OAM domain spans multiple Network
Operator OAM domains.  That makes sense.  But then the VPWS section
(5.2) explicitly makes the operator domain boundaries align with the
Service Provider domain boundaries.  Is this deliberate?  If so, the
difference needs to be explained.  If it is accidental, it is quite
confusing.

The VPWS Data Path requirement states that VPWS must be forwarded using
the "transfer plane."  Given that this is different from the VPLS
requirement, it would seem that there ought to me some text explaining
why the requirement is stricter for VPWS than for VPLS.  As a smaller
point, the introduction of the phrase "transfer plane" is probably a
mistake.  Just say explicitly that the forwarding must use the same
forwarding mechanism as regular data.

Minor Comments:

Should the introduction include expansions of the terms VPWS, VPLS, and
IPLS when they are first used just before section 1.1?  Or does the
working group consider those effectively to be names rather than
acronyms for the different services?

It seems odd to me, but is probably appropriate (which is why this is in
the "minor" block) to require delay variation monitoring capability.
This seems odd for two reasons.  Firstly, one way delay measurement is
only optional, not mandatory.  And the other is that many LAN services
don't make delay variation commitments, so it seems surprising for this
to be mandatory.  After all, one may want availability monitoring
without jitter concerns.

The text in section 8.1 on Partial mesh issues for VPLS says that either
the whole mesh should be shut down, or enough should be shut down to
restore the full mesh connectivity.  The requirements actually say tha
the OAM MUST support both capabilities.  This seems stricter than necessary.

The VPLS Connectivity Faul Notification text says that the OAM "should"
provide alarm suppression.  Then the requirement text (R15) actually
says "MUST support."  This may be consistent, but it is confusing.

Yours,
Joel M. Halpern