Re: [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

David,

Thanks much for taking the time to read the draft and for providing this
feedback! This is an Ack, we'll reply later, with answers/text to
address these open issues.

Thanks,

--Carlos.

On 12/10/2008 11:47 AM, Black_David@emc.com said the following:
> 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: draft-ietf-softwire-hs-framework-l2tpv2-10
> Reviewer: David L. Black
> Review Date: December 10, 2008
> IETF LC End Date: December 15, 2008
> 
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
> 
> Comments:
> 
> The draft is well-written, with a lot of details that will be
> valuable to implementers.  I have two open issues:
> 
> (1) Section 5.1 of this draft is clearly defining a softwire
> profile of L2TPv2 in that it states extensive requirements
> on AVP usage (and AVP contents in some cases) for softwires.
> Use of this profile is not explicitly signaled - the
> expectation is that both the SI and SC will be implemented
> in accordance with this draft, and won't try to communicate
> with L2TPv2 implementations that aren't using this profile.
> As the requirements of this softwire profile appear to differ
> from RFC 2661, defining an AVP to signal use of this profile
> seems like a good idea (its use should be required).
> 
> (2) This is more of a minor annoyance than an open issue, but
> it does need attention.  This draft uses UDP as part of an
> IP-in-IP tunnel, so the UDP guidelines in RFC 5405 apply.
> Note that Section 3.1.3 of RFC 5405 indicates that no
> additional congestion control is required for this scenario
> beyond what is already done for the IP traffic carried through
> the tunnel.  That should be noted in this draft, and RFC 5405
> should be scanned for any other considerations that may apply
> to this draft.
> 
> Everything else I found is relatively minor:
> - Please add CPE and LNS to the abbreviations section.
> - Most of the text after the figure in each of Sections 3.1.1
> 	through 3.1.4 is common.  Consider factoring it out into
> 	one location.  Ditto for 3.2.1 to 3.2.4.  It's fine to
> 	not do this if the result would be difficult to follow.
> - In Section 5.1.1.3, please clarify that the "SHOULD NOT send"
> 	requirement applies only to AVPs not covered in sections
> 	5.1.1, 5.1.1.1 and 5.1.1.2 .
> - I found a number of lower case instances of "must", "should"
> 	and "may" that are candidates for upper case (i.e.,
>  	RFC 2119 usage).  Please check all of these and upper case
> 	as appropriate.
> - Please expand the ULA acronym on its first use in Section
> 	6.1.1 .
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires