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, [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
