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
----------------------------------------------------------------------