Subject: [rtcweb] NAT Draft

From: "Bran, Cary" <[email-masked]>
Date: Mon, 31 Oct 2011 22:23:03 +0000

Hello WebRTC chairs,

I have updated and submitted a 02 version of the WebRTC NAT draft: http://tools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt

I believe that this draft is representative of areas where the working group has achieved consensus and at this time I would like to ask that the 02 draft be adopted as a working group document.

I look forward to your feedback.

Regards,

Cary Bran
Senior Director Advanced Software Technology and Architecture
Office:  +1 831-458-7737     Cell: +1 206-661-2398
Plantronics  Simply Smarter Communications(tm)
345 Encinal St., Santa Cruz, CA 95060

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at [email-masked], and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 20:03:37 +0100

Hi,
  
A couple of questions for clarification.
 
In section 3.3, what does "RTC-Web clients MUST support IPv4 to IPv6 transition." really mean? I think you need to clarify.

In section 4.1, can we put requirements on gateways? Maybe we should rather say that RTCWeb clients shall accept cases where the remote ICE client supports ICE lite, or something like that. Because, there might not even be a gateway, but a legacy UA that actually supports ICE :)

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bran, Cary
Sent: 1. marraskuuta 2011 0:23
To: [email-masked]
Cc: [email-masked]
Subject: [rtcweb] NAT Draft

Hello WebRTC chairs,

Regards,

Cary Bran

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 3 Nov 2011 14:17:08 -0700

On Nov 3, 2011 12:03 PM, "Christer Holmberg" <[email-masked]>
wrote:
> In section 3.3, what does "RTC-Web clients MUST support IPv4 to IPv6
transition." really mean? I think you need to clarify.

Hopefully nat64 rfc 6146

Cb
> In section 4.1, can we put requirements on gateways? Maybe we should
rather say that RTCWeb clients shall accept cases where the remote ICE
client supports ICE lite, or something like that. Because, there might not
even be a gateway, but a legacy UA that actually supports ICE :)
> I have updated and submitted a 02 version of the WebRTC NAT draft:
http://tools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt
>
>
>
> I believe that this draft is representative of areas where the working
group has achieved consensus and at this time I would like to ask that the
02 draft be adopted as a working group document.
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents,
files or previous e-mail messages attached to it, may contain information
that is confidential and/or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the intended
recipient, please DO NOT disclose the contents to another person, store or
copy the information in any medium, or use any of the information contained
in or attached to this transmission for any purpose. If you have received
this transmission in error, please immediately notify the sender by reply
email or at [email-masked], and destroy the original transmission
and its attachments without reading or saving in any manner.
>
> For further information about Plantronics - the Company, its products,
brands, partners, please visit our website www.plantronics.com.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Nov 2011 01:59:14 +0000

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?

[note: We might have separate RFCs if we plan a phase-1 and phase-2 approach for W3C and browsers, but this NAT one isn't in that type of situation.  And we might have a separate RFC for requirements for new protocol work, such as a data-transport one if we need the Transport Area to create a new transport, but this NAT one isn't that type of situation either.]

-hadriel

On Oct 31, 2011, at 6:23 PM, Bran, Cary wrote:

Hello WebRTC chairs,

Regards,

Cary Bran
Senior Director Advanced Software Technology and Architecture
Office:  +1 831-458-7737     Cell: +1 206-661-2398
Plantronics  Simply Smarter Communications™
345 Encinal St., Santa Cruz, CA 95060

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at [email-masked]<mailto:[email-masked]>, and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com<http://www.plantronics.com>.
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Nov 2011 10:20:27 +0100

On 2011-11-04 02:59, Hadriel Kaplan wrote:
> 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: [email-masked]
----------------------------------------------------------------------

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Nov 2011 23:35:42 +0000

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Nov 2011 15:40:41 +0100

On 2011-11-05 00:35, Hadriel Kaplan 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.
>> 
>> 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.

No, you misunderstood me, or more likely I wasn't clear enough. I at
least, expect the NAT draft to define how to actually do it. Not
requirements on the solution.

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

Agreed, and I do expect the document to go in the direction of a
specification of what is needed to implement by the WebRTC end-point.

Cheers

Magnus Westerlund