Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC
Pyda Srisuresh <srisuresh@yahoo.com> Thu, 16 August 2007 03:28 UTC
Return-path: <behave-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILW20-0004rB-Av; Wed, 15 Aug 2007 23:28:20 -0400
Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ILW1z-0004r5-8U for behave-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 23:28:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILW1y-0004qx-V7 for behave@ietf.org; Wed, 15 Aug 2007 23:28:18 -0400
Received: from web33305.mail.mud.yahoo.com ([68.142.206.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILW1x-0006SG-I6 for behave@ietf.org; Wed, 15 Aug 2007 23:28:18 -0400
Received: (qmail 58321 invoked by uid 60001); 16 Aug 2007 03:28:17 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kh2AYTIcBQzIvf2tRCIOfCDjFTyUpUMueXQiRZ+qNes55OlplwVC/AvdYulQW/k0sBRJNbNDXEJzLCR9DlqxuuEWEl1qypBPNpmb3K1Mo75AqRjeLoaxTkkm+QQoBqxjQ30BC50HCTYeE/gucojX+sXQR6JeroRRXBU4DXgZrcw=;
X-YMail-OSG: gDI132UVM1lpaooAXo4.B1vQK.n0d375qXJyRRdCFJTEscGtK0Ssg3fRrSP5ovLy19jLM18uo9Lx1_q9PbszkExoObltSu1Vs4uz4LljbJcA0RlKVJI-
Received: from [209.172.74.45] by web33305.mail.mud.yahoo.com via HTTP; Wed, 15 Aug 2007 20:28:17 PDT
Date: Wed, 15 Aug 2007 20:28:17 -0700
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <46AF3813.1020105@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <136097.58028.qm@web33305.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Cc: behave@ietf.org
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
Errors-To: behave-bounces@ietf.org
Magnus, I was out of town and just got back. Just catching up on the e-mails. Please see my responses inline below. regards, suresh --- Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > Suresh, > > I would propose that you drop MMUSIC mailing listif responding to this > as you appear to want to discuss the removal of a BEHAVE milestone, > rather than ICE and its way forward. But I will leave it there to let > the MMUSIC people see my response. > [suresh] I am not opposed to ICE moving forward. Please see below for my objection to ICE. > It seems most of the issues in this discussion is between, what I at > least thought was a specific way of performing the hole punching rather > than the general concept that I acknowledge has existed since the > creation of NATs. I will drop these items an respond to few of them. [suresh] Sorry, the hole punchign techniques havent been there since the conception of NATs. They came about principally in the context of P2P applications, much aftet the original NATs. > > Pyda Srisuresh skrev: > > --- Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > >> > >> There also has been discussion about if there should be multiple > >> solutions etc. But, to my knowledge the consensus also there has been > >> that one solution is the way to go. > >> > > [suresh] I have not been part of the discussion pertaining to the merit of > > multiple solutions vs single soultions. This may have been discussed in the > > context of SIP and NAT traversal. So, I cant comment on this. > > Yes, that was in the context of ICE. As my email was about that. > > > > >> So Suresh, you and everyone else as participants in the IETF is > >> responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG > >> item. > > > > [suresh] Magnus - I dont know what you are talking about. How do you mean I > am > > responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The > > ford-behave-app draft has been around for many years since the inception of > > BEHAVE. Last I checked, The application milestone is no longer on BEHVAE > > charter. I certainly am not responsible for removign the milestone. > > This was written as reaction on how work gets done in the IETF. One or > more proponents goes out and sell their idea so that enough people are > interested to participate in the work on that idea. In cases the > proponents are not succesful in getting traction for the idea it rarely > goes anywhere. In the case of the ford-behave-app draft there has been > no support for keeping the milestone or more important, do the work. > [suresh] I personally know of several applications using the TCP/UDP HOLE PUNCHING techniques directly (not using ICE). Irrespective of whether the IETF endorses design guidelines using HOLE PUNCHING techniques or not, this work will continue. It is ironic to me why the WG chose not to take up design guidelines using HOLE PUNCHING techniques as WG item. I cant explain it. > > > [suresh] Magnus - I have not been part of the consensus for ICE. However, I > do > > know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations > > identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or > the > > TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING > as > > normative reference. This iS WRONG. > > > > I believe, the ICE drafts should refer the prior work (kegel work on UDP > hole > > punching, USENIX paper for TCP hole punching and ford-behave-app draft for > > application traversal design) on which the ICE work is based. > > > > I think you should review your sources here. The first version of > ford-beahve-app was submitted february 2005. At that point STUN (RFC > 3489 had been published in almost 2 years (March 2003). The first > individual version of ICE was submitted to IETF february 2003. I am not > going to untangle this, but if you are going down this path: Please have > you facts right. > [suresh] Below is the chronology of the sources I am refering to. You can see for yourself what I am talking about. Nothing complex to untagle. a) http://alumnus.caltech.edu/~dank/peer-nat.html (Dec 98)- First documented reference to UDP hole punching technique. b) draft-ford-midcom-nat-p2p-00.txt (Sept 03) - First known reference to TCP hole punching technique and P2P application design guidelines c) Peer-to-peer communication across NATs USENIX '05 paper (04/2005) - This is derived from draft-ford-midcom-nat-p2p draft. Considerign that draft-ford-midcom-nat-p2p draft expired, this is the first formal documented reference to TCP hole punching d) draft-ford-behave-app-05.txt (March '07) - This is the currently active application design guidelines draft, derived from draft-ford-midcom-nat-p2p draft. e) draft-rosenberg-sipping-ice-00 (Feb 03) - First rev of ICE over UDP draft. This uses UDP hole punching technique. The ICE draft currently in MMUSIC WG has evolved and folds in a number of application design guidelines in ford-midcom-nat-p2p and ford-behave-app drafts, besides the UDP HOLE PUNCHING technique. f) draft-ietf-mmusic-ice-tcp-00 (Mar 06) - First rev of ICE over TCP draft. This uses TCP hole punching technique and folds in a number of application design guidelines in ford-midcom-nat-p2p and ford-behave-app drafts. I believe, there should be acknowledgement where the acknowledgement is due. The ICE drafts use the HOLE PUNCHING technique and adapt guidelines specified in ford-behave-app draft. But none of a), c) or e) are referred by the ICE drafts (ICE and ICE-TCP). > I am not denying that work commonly builds up on others. And that it is > common curtesy to reference such work. However, that is commonly done by > an informative reference. Normative references are for things that you > absolutely need to include to build interoperable implementations. > Please do review IESG statement on references: > > http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt > [suresh] Thanks for the pointer. The description is subject to individual interpretation. For example, it says "Normative references specify documents that must be read to understand or implement the technology in the new RFC". If you describe the technique used inside a draft, does it make the technique non-normative? I dont want to get into the nitty grittys on this. I will be fine, if the ICE drafts referred the docs I mentioned even as informational references. > > > > On the one hand, IETF (IESG) has been adamant about the standard level of > the > > normative references for a proposes standard. Yet, it is ironic that when > HOLE > > PUNCHING is normative to the design of ICE, the IETF is not allowing the > HOLE > > PUNCHING work to be standardized. > > Once more a missunderstanding about what it means to be a normative > reference in an RFC. > [suresh] Please see my comment above. > > > > Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application > > traversal identified in draft-ford-behave-app draft to move forward as a > BCP WG > > item? > > > > As stated before. There is a clear lack of interest in this document. I > wished there wasn't. But the fact is that no-one except you have really > argued for it, not even your co-authors. We can't publish a document > where no-one reads and reviews it and stil claim that their exist > consensus behind it. [suresh] Magnus - My co-authors are not arguing for it because they have given up they can get anywhere with arguing. It is just that I didnt. regards, suresh > > Regards > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave
- [BEHAVE] Re: ICE deployment data before LC for RFC Henry Sinnreich
- [BEHAVE] RE: [MMUSIC] ICE deployment data before … Henry Sinnreich
- [BEHAVE] RE: [MMUSIC] ICE deployment data before … DRAGE, Keith (Keith)
- Re: [BEHAVE] Re: ICE deployment data before LC fo… Magnus Westerlund
- RE: [BEHAVE] Re: ICE deployment data before LC fo… Henry Sinnreich
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Frank W. Miller
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Philip Matthews
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… David Barrett
- RE: [BEHAVE] Re: ICE deployment data before LC fo… Dan Wing
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Melinda Shore
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- RE: [BEHAVE] Re: ICE deployment data before LC fo… Henry Sinnreich
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Henry Sinnreich
- RE: [BEHAVE] Re: ICE deployment data before LC fo… Francois Audet
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Henry Sinnreich
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Frank W. Miller
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… David Barrett
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Dean Willis
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Philip Matthews
- Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deplo… Philip Matthews
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Frank W. Miller
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Cullen Jennings
- RE: [Sip] Re: [BEHAVE] Re: ICE deployment data be… David Barrett
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Philip Matthews
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Evgeniy Khramtsov
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Rémi Denis-Courmont
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Evgeniy Khramtsov
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Rémi Denis-Courmont
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Jonathan Rosenberg
- RE: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Frank W. Miller
- RE: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deplo… Henry Sinnreich
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Adam Roach
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… David Barrett
- Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deplo… Philip Matthews
- RE: [Sip] Re: [BEHAVE] Re: ICE deployment data be… David Barrett
- RE: [Sip] RE: [BEHAVE] Re: ICE deployment data be… David Barrett
- RE: [Sip] Re: [BEHAVE] Re: ICE deployment data be… David Barrett
- RE: [Sip] Re: [BEHAVE] Re: ICE deployment data be… David Barrett
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Philip Matthews
- [BEHAVE] Re: ICE deployment data before LC for RFC Henry Sinnreich
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… Adam Roach
- Re: [Sip] Re: [BEHAVE] Re: ICE deployment data be… David R Oran
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Magnus Westerlund
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Pyda Srisuresh
- Re: [Sip] RE: [BEHAVE] Re: ICE deployment data be… Magnus Westerlund