I had this note from Wei Luo after my last call review.. he attached a 
proposed new version but this doesn't seem to have been submitted.

Is this a drop off?

I was reasonably happy with the resolutions proposed although I still 
have some minor qualms about the M bit stuff.

regards,
Elwyn

-------- Original Message --------
Subject: 	Re: draft-ietf-l2tpext-l2vpn-06.txt
Date: 	Tue, 07 Feb 2006 15:50:52 -0800
From: 	Wei Luo <luo@cisco.com>
To: 	Elwyn Davies <elwynd@dial.pipex.com>
CC: 	gen-art@ietf.org, Mary Barnes <mary.barnes@nortel.com>, Mark 
Townsley <townsley@cisco.com>
References: 	<43E3BBAE.3040206@dial.pipex.com>



Thank you for the thorough review, Elwyn.  I have incorporated most of your 
suggested changes in the latest revision, enclosed herewith. The ones I 
specifically respond to below use a slightly different approach.

Elwyn Davies wrote:
> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Document: draft-ietf-l2tpext-l2vpn-06.txt
> Intended Status: Proposed Standard (WG submission)
> Shepherding AD: Mark Townsley
> Review Trigger: IETF last call ended 23 Jan 2006
> 
> Summary:
> This document is close to being ready for PS.  It has one minor issue 
> relating to the M bit in the various AVPs (see below) and its 
> readability/usefulness could be much improved by pointers to the 
> relevant parts of RFC3931 for definitions and processes referred to.  It 
> also could do with a terminology section to make it clear where all the 
> various terms come from and expand some of the acronyms.
> 
> 
> Minor issues:
> 
> M bit in AVPs:
> ==============
> s4.3: In the description of the new AVPs, the M bit is specified as 
> SHOULD be 0 for all three items i.e. the receiver should ignore the AVP 
> if it doesn't understand it.  Two questions (one with two parts) come to 
> mind:
> - For each AVP, will everything work as expected if the sender includes 
> the AVP and the receiver ignores it?  Should the behaviours in this 
> eventuality be discussed?

For each newly defined AVP, the specification already defines the 
receiver's behaviors when these AVPs are absent.  The behaviors when the 
receiver ignores the AVPs can be inferred based on the specification.

Will this work?  The answer is yes.  When the receiver ignores the AVPs, it 
continues to process the rest of the message as if they are absent.  Since 
it ignores the AVPs, it will not send an response back to the sender with 
these AVPs.  As the specification defines, the sender simply assumes the 
receiver uses the default values (specified for each AVP).  On the other 
hand, the sender could have a user-defined policy that refuses a connection 
that uses the default values, but that's not something the protocol 
specification should control.

> - What circumstances would lead an implementer to set the M bit to 1?

Only if the implementer does not want the session to be established if the 
receiver does not understand these AVPs.  Such an implementation, however, 
will impair its interoperability.

> 
> A related point: in this application do any of the existing AVPs need to 
> be sent with M=1?

The M-bit settings of this application for the existing AVPs align with 
those specified in RFC3931, and impose no additional requirement or special 
condition.

All the M-bit issues you mentioned are described in RFC 3931 Section 5.2. 
I add some clarification and reference on the points I made above.

> 
> At least a pointer to s5.2 of RFC3931 would help.
> 
> ======================
> 
> Editorial:
> s1: Acronyms PPP and LAC need expansion..  More generally a brief 
> terminology section saying where terms are imported from (mostly either 
> the L2TPv3 and L2VPN Framework documents) would be helpful.

I expand all the acronyms and add references you mentioned in their current 
places accordingly rather than add new terminology section.

> 
> s2, last para: s/cross-connect/cross-connects/
> 
> s4.1, para 1: s/to signaling L2VPNs/for signaling L2VPNs/, s/has some 
> advantages/have some advantages/
> 
> s4.2: AVP, SCCRQ, SCCRP, ICRQ, ICRP, ICCN, SLI need expanding or (in the 
> cased of the message IDs, noting that this is what they are and saying 
> where they are defined).
> 
> s4.2: It would be worth noting that these existing AVPs are defined in 
> s5.4.3 of RFC3931.
> 
> s4.3: All AVPs: should specify lengths are in octets.
> 
> s4.3: It would be useful to provide a pointer to s5.3 of RFC3931 for a 
> description of hiding.
> 
> s4.3: MTU AVP should specify encoding (presumably integer, octet order?) 
> of MTU.
> 
> s5.1, para 2: A pointer to the relevant IANA registry  for the  
> psudowire types should be included and also a reference to 
> draft-ietf-pwe3-iana-allocation-15.txt.
> 
> s5.1, para 4: s/forwarder identifier/forwarder identifiers/ (refers to 
> both local and remote).
> 
> s5.2, last para:  A pointer to (presumably) to Session Mgmt Tie Breaker 
> AVP in s5.4.4 of RFC3931 would help.
> 
> s5.3 (and also s1): Make it explicit that the object of the exercise is 
> to create a complete mesh of interconnections between SOURCE_FORWARDERS 
> and TARGET_FORWARDERS.
> 
> s5.3, algorithm: I know it is a bit pedantic but it should explicitly 
> say start from beginning of SOURCE_FORWARDERS (new Step 0), and Step 1 
> should say start again from the beginning of TARGET_FORWARDERS.  This 
> should be matched in the diagram.

This seems to get too much into programming details.  A reasonable 
programmer should understand the basics of initialization and looping of 
the algorithm.

> 
> s6: Should point at the IANA registry procedures in RFC3931.
> 
> s7:  The text is rather clumsy.  Try something like: 'This specification 
> does not introduce any additional security issues beyond those discussed 
> in [RFC3931] and [L2VPN FW].'

The rest of the comments has been incorporated in the new draft, which also 
passed the I-D nit checker.

Thanks,

---Wei

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art