Hi Dan, We just released a new revision of the ds-lite draft. Did we address all your comments?
Thanks, Yiu On 5/5/11 8:42 PM, "Dan Wing" <[email protected]> wrote: >I've reviewed this document as part of the transport area directorate's >ongoing effort to review key IETF documents. These comments were written >primarily for the transport area directors, but are copied to the >document's >authors for their information and to allow them to address any issues >raised. The authors should consider this review together with any other >last-call comments they receive. Please always CC [email protected] if you >reply to or forward this review. > >This draft is basically ready for publication, but has nits that should be >fixed before publication: > > >In draft-ietf-softwire-dual-stack-lite-08, it says: > > 8.3. Application Level Gateways (ALG) > > AFTR performs NAT-44 and inherits the limitations of NAT. Some > protocols require ALGs in the NAT device to traverse through the NAT. > For example: SIP and ICMP require ALGs to work properly. > >Three comments on that "For example:" > >1. I do not believe SIP requires an ALG. > >Here are three citations that SIP ALG is unnecessary: > * ICE (RFC5245), which has the SIP endpoint do its own NAT traversal. >With > this, a SIP ALG is unnecessary. > * Session Border Controllers routinely implement 'media latching' >(described > in draft-ietf-mmusic-media-path-middleboxes), which works with >endpoints >that > don't implement ICE. With this, a SIP ALG is unnecessary. > * draft-ietf-sipping-nat-scenarios describes how all of this stuff works >in > great detail, and its Section 3 says SIP ALG is not required. > >I worry that the IETF is requiring / suggesting / recommending that >vendors >implement ALGs in NATs. If the IETF were to make such a recommendation, >it >needs to come from BEHAVE which is where the NAT work occurs, not >SOFTWIRE. > >Unless there is a citation that SIP ALG is necessary, please strike it. > > >2. "ALG" is an abbreviation for Application Layer Gateway, but ICMP is not >an application; it is a layer 4 protocol. If anything, it is >traditionally >considered a "layer 3.5", because it is not normally used for transport >but >rather to signal the IP layer. The term "ALG" is not appropriate when >discussing ICMP. RFC5508, which describes the behavior of ICMP for NAT, >does not use the term ALG (or Application) when describing ICMP. I >suggest >simply striking "ICMP" from the example of protocols needing an ALG. > >This also requires updating the text: > > This specification only requires that the AFTR MUST > support [RFC5508]. > >by moving it out of the ALG section and to section 8.2 ("NAT Conformance") >where there are already citations for RFC4787 (UDP operation) and RFC5382 >(TCP operation). > >I suggest striking the mention of RFC5508 from the ALG section and adding >it >to Section 8.2 ("NAT Conformance"), like this: > >OLD: > A dual-stack lite AFTR MUST implement behavior conforming to the best > current practice, currently documented in [RFC4787] and [RFC5382]. >NEW: > A dual-stack lite AFTR MUST implement behavior conforming to the best > current practice, currently documented in [RFC4787], [RFC5382], and >.................................................................^^^^^ > [RFC5508]. >...^^^^^^^^^ > > >3. If the authors desire an example of a protocol that requires an ALG, a >good example is "active-mode FTP". (Which is seldom used anymore, because >it requires an ALG! It has been surpassed by passive-mode FTP.) > >-d > >
