Re: [AVT] AD review: draft-ietf-avt-rtp-cnames-02

But if we do that, we still end up with a MUST, which has to say that if you use another mechanism, it MUST meet certain requirements, and we have to be very precise about evaluating those requirements.

Is it not better just to list all the possible ones?

How much freedom do implementors actually need in this area? Is the only restriction really one where the root value is not available for some reason? Have we covered all those?

Keith 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
> Behalf Of Colin Perkins
> Sent: Wednesday, December 01, 2010 10:55 PM
> To: Robert Sparks
> Cc: IETF AVT WG
> Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-cnames-02
> 
> On 23 Nov 2010, at 16:32, Robert Sparks wrote:
> > Summary: Ready for IETF LC - watch for the announcement shortly.
> > 
> > Please consider the following as LC comments.
> > 
> > The document does not sufficiently explain _why_ these 
> three mechanisms are the only three mechanisms allowed and 
> that any other mechanism that satisfies these properties is 
> explicitly declared to be non-conformant. Did I miss this 
> explanation in the text somewhere? In particular, I'm looking 
> for support for the argument that interoperability will be 
> harmed if these requirements are not followed.
> 
> I'd be happy for the "MUST use one of the following three 
> methods" at the start of section 4.2 to change to a "SHOULD 
> use". As long as the method chosen has appropriate 
> uniqueness, and there is consistency between the methods used 
> for multiple RTP sessions that are to be correlated, then it 
> doesn't especially matter what algorithm is used. 
> 
> > Can the document explain why implementations won't run 
> afoul of the problem it calls out with public IPv4 addresses 
> being used by more than one endpoint when it requires IPv6 
> addresses to be used as cnames in the second bullet of 4.2?
> 
> 
> This is because IPv6 addresses are assumed globally unique. 
> We could change "That address can be an IPv6 privacy address 
> [RFC4941] or a unique local IPv6 unicast address [RFC4193]" 
> to "That address can be a unique globally scoped IPv6 unicast 
> address, an IPv6 privacy address [RFC4941], or a unique local 
> IPv6 unicast address [RFC4193]" or similar, if you think it's needed.
> 
> Cheers,
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 