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

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" <harald@alvestrand.no> 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  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb