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

[Stefan Håkansson LK <[e-mail]>]

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

On 2011-09-26 11:57, Harald Alvestrand wrote:
> On 09/26/11 08:34, Magnus Westerlund wrote:
>> 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.
> 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.
>
>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb