Re: [apps-discuss] APPSDIR review of draft-ietf-l2vpn-arp-mediation-19

[Stewart Bryant <[e-mail]>]

RFC Editor: please continue with the publication process.

AA Reviewer: thank you for the review

The purpose of the last call was to address an IPR issue discovered
whilst the document was with the RFC Editor, however we
will attempt to address these points.


On 02/05/2012 11:23, S Moonesamy wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on AppsDir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
> ).
>
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-l2vpn-arp-mediation-19
> Title: ARP Mediation for IP Interworking of Layer 2 VPN
> Reviewer: S. Moonesamy
> Review Date: May 2, 2012
> IETF Last Call Date: April 12, 2012
>
> Summary: I'll abstain from making any recommendation about publication 
> as the L2VPN Working Group has been working on this draft since 
> October 2004.
>
> This draft describes methods for ARP Mediation when different 
> resolution protocols are used on either Attachment Circuit.  It does 
> not contain any Application considerations.  I am not familiar with 
> the subject.
>
> Major issues:
>
> It is not clear throughout the document whether "IP address" refers to 
> IPv4 and IPv6 or IPv4 only.

SB> I would like to ask the authors to clearly inspect the usage the 
term "IP Address"
and determine whether there is any ambiguity of the term in each case 
and provide
the necessary clarification if required.
>
> In Section 1:
>
>   "In this document, we specify the procedures for VPWS services,
>    which the PEs MUST implement in order to mediate the IP address
>    resolution mechanism."
>
> BTW, VPWS is expanded on first use below that.
SB> I am sure the RFC Editor will get that one
>
> It's difficult to figure out the procedures for that "MUST".
SB> Yes, suggest s/MUST/need to/
>
> In Section 4.1.2:
>
>   "This document mandates that there MUST be only one CE per
>    Attachment Circuit. However, customer facing access topologies
>    may exist whereby more than one CE appears to be connected to
>    the PE on a single Attachment Circuit."
>
> There is a requirement for only one CE per Attachment Circuit and yet 
> it is mentioned that there may be cases where more than one CE appears 
> to be connected.  If there are cases when the requirement cannot be 
> followed, why is it a requirement?

SB> I suggest:
OLD
This document mandates that there MUST be only one CE per Attachment 
Circuit.
NEW
The method described in  this document only supports the case where 
there is a single CE per Attachment Circuit.
END
>
> In Section 8.1:
>
>   "For greater security the LDP connection between two trusted PEs
>    MUST be secured by each PE verifying the incoming connection
>    against the configured address of the peer and authenticating
>    the LDP messages using MD5 authentication, as described in
>    section 2.9 of [RFC5036]."
>
> Isn't the MD5 authentication considered as obsolete?
SB> A good point, but this document is not the place to specify LDP 
security.
I suggest the following change:

OLD
"For greater security the LDP connection between two trusted PEs
    MUST be secured by each PE verifying the incoming connection
    against the configured address of the peer and authenticating
    the LDP messages using MD5 authentication, as described in
    section 2.9 of [RFC5036]."
NEW
"For greater security the LDP connection between two trusted PEs
    MUST be secured by each PE verifying the incoming connection
    against the configured address of the peer and authenticating
    the LDP messages as described in  section 2.9 of [RFC5036]."
END

>
> In Appendix A.1:
>
>   "In an IP L2 interworking L2VPN, when an IGP on a CE connected to
>    a broadcast link is cross-connected with an IGP on a CE
>    connected to a point-to-point link, there are routing protocol
>    related issues that MUST be addressed."
>
> Addressing protocol related issues is a vague requirement.
SB> I think these are addressed in the sub sections that follow.
>
> Minor isues:
>
> In Section 2:
>
>   "1. Discover the IP address of the locally attached CE device"
>
> Is this for IPv4 addresses only?
SB> IPv6 is described separately in the next para.
>
> In Section 3:
>
>   "If the IP packet arrives at the ingress PE with multiple data
>    link headers (for example in the case of bridged Ethernet PDU
>    on an ATM Attachment Circuit), all data link headers MUST be
>    removed from the IP packet before transmission over the PW."
>
> What is "PW"?
SB> s/PW/pseudowire/
>
> Nits:
>
> I found the Abstract Section difficult to parse.
I think I am OK with it, but will leave it to the RFCEditor to work though
any issues with the Authors.
>
> There are four authors listed on the first page of the draft.  
> However, there are 16 authors/editors listed in the Authors' Addresses 
> section.  Given that there is an IPR disclosure on this draft, can the 
> document shepherd answer the following question:
>
>    Has each author confirmed that any and all appropriate IPR
>    disclosures required for full conformance with the provisions of
>    BCP 78 and BCP 79 have already been filed.  If not, explain why.
>
> Please note that this review does not contain editorial comments.
>

This document was approved by the IESG prior to this procedure coming 
into operation.
The document has been re Last Called on this. It is difficult for any of 
the remaining
authors to justify sitting on IPR.

Stewart