Re: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Wed, 11 May 2011 21:44 UTC
Return-Path: <yiu_lee@cable.comcast.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1532DE08A6; Wed, 11 May 2011 14:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.735
X-Spam-Level:
X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCRstK0-1jBK; Wed, 11 May 2011 14:44:38 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 43EEEE089C; Wed, 11 May 2011 14:44:38 -0700 (PDT)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.38005794; Wed, 11 May 2011 15:48:37 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Wed, 11 May 2011 17:44:32 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Dan Wing <dwing@cisco.com>, 'David Harrington' <ietfdbh@comcast.net>, 'Transport Directorate' <tsv-dir@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "draft-ietf-softwire-dual-stack-lite@tools.ietf.org" <draft-ietf-softwire-dual-stack-lite@tools.ietf.org>
Subject: Re: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
Thread-Topic: TSVDIR review, draft-ietf-softwire-dual-stack-lite-08
Thread-Index: AQHMECSclu/yiPYZnk+l7jo39BoXCQ==
Date: Wed, 11 May 2011 21:44:31 +0000
Message-ID: <C9F07A11.E56F%yiu_lee@cable.comcast.com>
In-Reply-To: <034e01cc0b86$8b9eb8e0$a2dc2aa0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [68.82.20.172]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4EE1E38210A0BE4F8D0D0B5B4E603481@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 12 May 2011 06:38:09 -0700
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2011 21:44:39 -0000
Hi Dan, Thanks very much for spending the time to review it. Comments inline: 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. [YL] When we wrote this section, we anticipated the class rfc3261 SIP without ICE and SBC. I will take your advice to 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]. >...^^^^^^^^^ > [YL] Agreed and will update the text to reflect this in next revision. > >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.) [YL] I think this is worth to mention some protocols may not work (such as active ftp). I will work on the text to bring it up but not give any recommendation. We will release the next revision very soon. /Yiu > >-d > >