Subject: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Sep 2011 08:34:38 +0200

Hi,

(as individual)

I would suggest that some section for general requirements that aren't
use case specific is created and at least one such requirement is added.

The requirement is the need to support IPv4 only, IPv6 only and
dual-stack deployments as required by our charter. I think this should
be added into the use-case and requirement document for two reasons.
First, that is located next to the other requirements, secondly because
W3C has decided to use our document also, I think it is important that
such a general requirement both on protocols and any address field in
the API handling both address families are covered.

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: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Sep 2011 11:57:42 +0200

> the API handling both address families are covered.
I support adding those requirements.

I think that it can also be instantiated within the specific use cases, 
such as:
- Point to point call: One endpoint on IPv4, the other endpoint on IPv6
- Multipoint call (with and without central server): One user on IPv4, 
one user on IPv6

This is a limitation of the use-case-based model; it gets messy to 
shoehorn all the "permutations" of situations into a single set of use 
cases, without the list of use cases growing impossibly long or the use 
cases' description expanding into incomprehensibility.

On balance, I think having a "considerations applicable to all 
scenarios" section saying:

- Clients can be on IPv4-only
- Clients can be on IPv6-only
- Clients can be on dual-stack
- Clients can be on wideband (10s of Mbits/sec)
- Clients can be on narrowband (10s to 100s of Kbits/sec)
- Clients can be on variable-media-quality networks (wireless)
- Clients can be on congested networks
- Clients can be on firewalled networks with no UDP allowed
- Clients can be on networks with cone NAT
- Clients can be on networks with symmetric NAT

might be a good way to go forward.

A particular query on v4/v6 interoperation: Should we make it a 
requirement that dual-stack to IPv4 always use the IPv4 native path 
rather than a gateway functionality (and the converse for IPv6), or 
should we just be silent about it?
I think it may affect some tuning of the ICE address selection 
algorithm, in particular if we encounter 6to4 addresses. There might be 
RFCs we can cite already.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 26 Sep 2011 14:27:05 +0200

Hi,

as editor:

I have some difficulties right now to judge what should be in and what 
should be out (in terms of use cases). I think some more consensus calls 
might be needed, but I need guidance from the chairs.

Then there are some pieces that are discussed that are not really new 
use cases, but things that could be added existing ones or as a separate 
section. I keep a list of these at the *W3C* webrtc WiKi (because that 
is convenient to me, and to show that there are two stakeholders!): 
<http://www.w3.org/2011/04/webrtc/wiki/Main_Page#Use_cases_and_requirements>

Please give me a heads up of the things I have missed to put in that list.

Stefan

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 07:31:16 -0700

> the API handling both address families are covered.

+1
Cb

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 27 Sep 2011 10:05:44 +0300

> the API handling both address families are covered.
I agree

/Sal

---

From: Jim McEachern <[email-masked]>
Date: Tue, 27 Sep 2011 13:53:57 +0000

I like the idea of a general considerations section applicable to all use cases, and I think this proposed list would be a good start.

Jim 

On Sep 26, 2011, at 5:57 AM, "Harald Alvestrand" <[email-masked]> wrote:

> I think that it can also be instantiated within the specific use cases, such as:
> - Multipoint call (with and without central server): One user on IPv4, one user on IPv6
> 
> This is a limitation of the use-case-based model; it gets messy to shoehorn all the "permutations" of situations into a single set of use cases, without the list of use cases growing impossibly long or the use cases' description expanding into incomprehensibility.
> 
> On balance, I think having a "considerations applicable to all scenarios" section saying:
> 
> A particular query on v4/v6 interoperation: Should we make it a requirement that dual-stack to IPv4 always use the IPv4 native path rather than a gateway functionality (and the converse for IPv6), or should we just be silent about it?
> I think it may affect some tuning of the ICE address selection algorithm, in particular if we encounter 6to4 addresses. There might be RFCs we can cite already.
> 
> 
>> Cheers
>> 
>> Magnus Westerlund
>>