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

[[e-mail]]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires