Re: [rtcweb] NAT Draft

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 04 November 2011 23:35 UTC

Return-Path: <HKaplan@acmepacket.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 7C81D1F0C41 for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 16:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level:
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599]
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 2ldfKupyr0CY for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 16:35:46 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E10B71F0C35 for <rtcweb@ietf.org>; Fri, 4 Nov 2011 16:35:45 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 4 Nov 2011 19:35:43 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 4 Nov 2011 19:35:43 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] NAT Draft
Thread-Index: AQHMm0p39Ahvf8bhNEuia+G7a2U8zw==
Date: Fri, 04 Nov 2011 23:35:42 +0000
Message-ID: <3815A3A8-A6CF-4024-9FBD-AE2E7D2A2211@acmepacket.com>
References: <E37C139C5CB78244A781E9E7B721527B54858D@USSCMB03.plt.plantronics.com> <F0ED2194-3C00-4409-9B11-116419AEA5D3@acmepacket.com> <4EB3AE5B.4090401@ericsson.com>
In-Reply-To: <4EB3AE5B.4090401@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <CBDDD375B73F3A4FA056D81195CF79F2@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 23:35:46 -0000

On Nov 4, 2011, at 5:20 AM, Magnus Westerlund wrote:

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

Hey you're one of the Chairs - if the Chairs want to have a dozen RFCs on requirements, and another dozen on actual behavior, that's your call.  
Seems silly to me, but most of the admin work is on the authors, the Chairs, and the ADs I think... so it's no skin off my nose to have more RFCs.

As I said in my email: draft-ietf-rtcweb-use-cases-and-requirements is high-layer/general WebRTC requirements, and if we want a separate detailed specification, that would make sense (or even multiple if that's your preference).  But draft-cbran-rtcweb-nat-02 doesn't appear to be that - it reads like a requirements for NAT traversal mechanism, and that the answer to that is native ICE support.  

-hadriel