Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

"James M. Polk" <jmpolk@cisco.com> Fri, 29 January 2010 19:18 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3943A6A41 for <tsvwg@core3.amsl.com>; Fri, 29 Jan 2010 11:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.47
X-Spam-Level:
X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2854rbzKHCv2 for <tsvwg@core3.amsl.com>; Fri, 29 Jan 2010 11:18:43 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AD1C13A6961 for <tsvwg@ietf.org>; Fri, 29 Jan 2010 11:18:43 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsUFAPvCYkurR7H+/2dsb2JhbACGUrw8l1+EQgQ
X-IronPort-AV: E=Sophos;i="4.49,370,1262563200"; d="scan'208";a="236469559"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 29 Jan 2010 19:19:06 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0TJJ6mF014113; Fri, 29 Jan 2010 19:19:06 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:19:06 -0800
Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:19:06 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 29 Jan 2010 13:19:03 -0600
To: Xiangsong Cui <Xiangsong.Cui@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Randy Stewart <randall@lakerest.net>, tsvwg <tsvwg@ietf.org>, Michael Tuexen <tuexen@fh-muenster.de>, draft-stewart-natsupp-tsvwg@tools.ietf.org, Dan Wing <dwing@cisco.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <08d501caa0b7$52d0dec0$58106f0a@china.huawei.com>
References: <01c301ca9b06$ed2ba510$c2f0200a@cisco.com> <XFE-SJC-211rMh0R1hY0000286d@xfe-sjc-211.amer.cisco.com> <7B4DD94D79534300BD1A8C79BAB93402@china.huawei.com> <XFE-SJC-212sBt8sBju00002534@xfe-sjc-212.amer.cisco.com> <3A6D764F-4FDC-4873-B900-43B219558493@lakerest.net> <04ab01ca9df8$738c3860$c2f0200a@cisco.com> <A03B1092-9896-42DA-A226-08B29D1C4643@lakerest.net> <4B5EA57D.9020301@ericsson.com> <20100126105530.GA2801@openss7.org> <4B5ED37A.5060309@ericsson.com> <20100126132153.GA6204@openss7.org> <4B5EF322.4040701@ericsson.com> <08d501caa0b7$52d0dec0$58106f0a@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-211R1OGokN700004c6c@xfe-sjc-211.amer.cisco.com>
X-OriginalArrivalTime: 29 Jan 2010 19:19:06.0370 (UTC) FILETIME=[ECDCE620:01CAA117]
Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 19:18:44 -0000

Xiangsong

Please define "space" as you use it, as I cannot parse it (i.e., I 
can come up with uses of "space", but none work consistently through 
your examples).

A couple of examples of what I know, RFC4960 obsoleted RFC2960.

- So, in your definition - how does that affect RFC 3775?

- Of course RFCs 3309 or 3775 could have formally updated RFC 2960 at 
the time of its publication., and either could have obsoleted the 
previous current base spec of SCTP.

I guess I don't get the logic you are suggesting, that both 3309, 
3375 and all other IPv6 RFCs are outside of the Transport Area, which 
includes the TSVWG. Are you specifically talking about which WG or 
Area these IDs and RFCs were generated in?

That is actually part of the question -- as Dan Wing (BEHAVE WG 
chair) is very conscious of anything in his WG updating any other 
WG's (or Area's) protocols.  HE and I have talked frequently and this 
topic as his WG is working on various ways that transport protocols 
can be modified to traverse NATs, and he prefers (which I agree with) 
any changes to the transport protocols be done in the protocol's home 
WG (TCP in TCPM WG, SCTP and UDP in TSVWG, and DCCP in the DCCP WG).

The applicable WG chairs and the Transport ADs are discussing how 
*not* to duplicate or replicate new (and different) ways for each 
transport protocol to traverse NATs. We're unofficially looking for a 
generic mechanism (i.e., in one ID) that covers all transport 
protocols can traverse NAT the same way.  This reduces complexity and 
therefore it's probably this approach will increase interoperability 
(especially for the HOMEGATE group).

James

At 01:47 AM 1/29/2010, Xiangsong Cui wrote:
>Dear all,
>
>Please allow me to comment.
>
>I don't think this draft updates RFC4960,
>In my understanding, if one draft updates another,  they should be 
>in the same space.
>
>If one draft is in one space, while another one is in a space of 
>different level, I do not consider the update relation between them.
>For example, RFC2460 is for IPv6, RFC3775 is for Mobile IPv6, does 
>RFC3775 update RFC2460? I see no such relation in IETF.
>And, RFC2460 is also not updated by all IPv6-related documents.
>
>As to SCTP cases, RFC2960 was updated by RFC3309, they are in the 
>same space (in fact RFC3309 is in a subspace of RFC2460).
>But the SCTP-NAT-draft and RFC4960 are in different space.
>
>Regards
>Xiangsong
>
>----- Original Message ----- From: "Magnus Westerlund" 
><magnus.westerlund@ericsson.com>
>To: "Randy Stewart" <randall@lakerest.net>; "tsvwg" 
><tsvwg@ietf.org>; "Michael Tuexen" <tuexen@fh-muenster.de>; 
><draft-stewart-natsupp-tsvwg@tools.ietf.org>; "Dan Wing" 
><dwing@cisco.com>; "James M. Polk" <jmpolk@cisco.com>
>Sent: Tuesday, January 26, 2010 9:50 PM
>Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00
>
>
>>Brian F. G. Bidulock skrev 2010-01-26 14:21:
>>>Magnus,
>>>
>>>I just thought that it would be good to comment on a WG item draft
>>>before arguing whether it updates RFC 4960 or not.
>>
>>Well, with the expectation that the next update will be a WG item I
>>don't find it that strange. But I do agree that we should make it clear
>>that it is going to become a WG item.
>
>--snip--