RE: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08

"Dan Wing" <dwing@cisco.com> Fri, 13 May 2011 22:59 UTC

From: Dan Wing <dwing@cisco.com>
To: "'Lee, Yiu'" <Yiu_Lee@Cable.Comcast.com>, 'David Harrington' <ietfdbh@comcast.net>, 'Transport Directorate' <tsv-dir@ietf.org>, tsv-area@ietf.org
References: <034e01cc0b86$8b9eb8e0$a2dc2aa0$@com> <C9F2070A.E711%yiu_lee@cable.comcast.com>
In-Reply-To: <C9F2070A.E711%yiu_lee@cable.comcast.com>
Subject: RE: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
Date: Fri, 13 May 2011 15:59:31 -0700
Message-ID: <005f01cc11c1$6b598150$420c83f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQHMERB3lu/yiPYZnk+l7jo39BoXCZSLYKfg
Content-Language: en-us
Precedence: list

> -----Original Message-----
> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On
> Behalf Of Lee, Yiu
> Sent: Thursday, May 12, 2011 6:53 PM
> To: Dan Wing; 'David Harrington'; 'Transport Directorate'; tsv-
> area@ietf.org
> Subject: Re: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
> 
> Hi Dan,
> 
> We just released a new revision of the ds-lite draft. Did we address
> all your comments?

Yes, all my comments were addressed.

Thank you,
-d


> Thanks,
> Yiu
> 
> 
> 
> On 5/5/11 8:42 PM, "Dan Wing" <dwing@cisco.com> 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  tsv-dir@ietf.org 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
> >
> >

TSVDIR review, draft-ietf-softwire-dual-stack-lit… Dan Wing
Re: TSVDIR review, draft-ietf-softwire-dual-stack… Lee, Yiu
Re: TSVDIR review, draft-ietf-softwire-dual-stack… Lee, Yiu
RE: TSVDIR review, draft-ietf-softwire-dual-stack… Dan Wing