Re: [rtcweb] NAT Draft
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 04 November 2011 09:20 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CBB21F8C34 for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 02:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level:
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j56utGuEJyZP for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 02:20:55 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F021F8BF0 for <rtcweb@ietf.org>; Fri, 4 Nov 2011 02:20:49 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-59-4eb3ae707902
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.0E.13753.07EA3BE4; Fri, 4 Nov 2011 10:20:48 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 4 Nov 2011 10:20:29 +0100
Message-ID: <4EB3AE5B.4090401@ericsson.com>
Date: Fri, 04 Nov 2011 10:20:27 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <E37C139C5CB78244A781E9E7B721527B54858D@USSCMB03.plt.plantronics.com> <F0ED2194-3C00-4409-9B11-116419AEA5D3@acmepacket.com>
In-Reply-To: <F0ED2194-3C00-4409-9B11-116419AEA5D3@acmepacket.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "Bran, Cary" <Cary.Bran@plantronics.com>
Subject: Re: [rtcweb] NAT Draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 09:20:56 -0000
On 2011-11-04 02:59, Hadriel Kaplan wrote: > > Howdy, > I've read the draft and I do think some consensus has been reached with > regard to some of it. > > Having said that, though, I don't think this needs to be a WG document > because that implies we would be publishing this as an RFC eventually... > and I don't see a need to do that. > > We should instead incorporate any requirements we reach WG consensus on > into the draft-ietf-rtcweb-use-cases-and-requirements WG document; or if > we feel that that document is meant for high-level requirements only, > then we should create a new WG document that covers all the specific > requirements. > > Having separate individual drafts is ok for now, but having a separate > WG doc and RFC for every requirement sub-category seems unnecessary to > me, and likely to cause confusion. It's not like we would expect to > only satisfy the requirements of RFC X but not Y, is it? Hadriel, I think a document of this type should and will eventually be published as its own RFC. The reason for this I think is that the document should evolve from requirements to actually specify how the Peer to Peer transport flow establishment layer for WebRTC works. As that layer will be used by both the RTP based media transport and the Data Transport having a document only containing that functionality will make it simpler to reference. In addition I think it is good from specification maintenance perspective. If we have bugs in a functionality block we don't need to republish other functionality blocks just to update, in this case the NAT traversal functionality. Given that a NAT traversal document will specify how WebRTC establish the transport flows do you think that really should be part of the use-cases and requirements? My personal input to draft-cbran-rtcweb-nat is to stop using requirements as the word for what an end-point shall implement and which specifications they should follow. Instead call it specification. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [rtcweb] NAT Draft Bran, Cary
- Re: [rtcweb] NAT Draft Christer Holmberg
- Re: [rtcweb] NAT Draft Cameron Byrne
- Re: [rtcweb] NAT Draft Hadriel Kaplan
- Re: [rtcweb] NAT Draft Magnus Westerlund
- Re: [rtcweb] NAT Draft Hadriel Kaplan
- Re: [rtcweb] NAT Draft Magnus Westerlund