WG, On 12/22/2008 7:49 PM, [email protected] said the following: > After a lengthy private discussion with Carlos, and some > serious "quality time" spent with RFC 2661 ;-), here's > where I think the two major issues from my Gen-ART review > of this draft stand: > > (1) AVP for softwire profile of L2TPv2. I'm no longer > convinced that a new AVP is needed, but the specification > of the profile needs significant clarification and cleanup.
For completeness, I do not think that significant cleanup is needed, but rather that some localized editorial clarifications of context might help the reader. In any case, one of the big decisions in this discussion is that there's no new "softwire AVP", and some fall out is that S5.1.1.X can use more specific descriptions. > For example, what happens if a softwire implementation of > L2TPv2 happens to receive an OCRQ message? For example, draft-ietf-softwire-hs-framework-l2tpv2 specifies that: in the Softwire context, the voluntary tunneling model applies ... Since L2TPv2 compulsory tunneling model does not apply to Softwires, it should not be requested or honored. ... In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) assumes the role of the LAC Client And more notably: No outgoing or analog calls are permitted. So, if a softwire implementation of L2TPv2 happens to receive an OCRQ message, it needs to CDN it (as strongly hinted though not explicitly spelled out; for a versatile and variation-rich protocol as L2TP a this seems a self-evident exception protocol paths for softwire). The fall-through protocol definition lies in RFC2661 (the doc says "as defined in [RFC2661]"), and that scenario is the same as "if a full RFC2661 implementation of L2TP not configured for outgoing calls receives an OCRQ message". > This has also > turned up a topic that needs to be covered in the Security > Considerations section - a brief discussion of the security > consequences of the recommendation not to hide AVPs. Right, this is one new thing that came up, from looking into the Random Vector AVP. The document is recommending not to hide AVPs, from the very original text. But, I think, the document "MAY" allow AVP hiding (instead of describing the consequences of not hiding). > > (2) RFC 5405 and UDP. In addition to referencing RFC 5405, > a recommendation for L2TPv2 use of PMTUD will be added. We will describe all the changes when we post an updated version of the document. Thanks, --Carlos. > > 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, DSE, CISCO. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
