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

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Dec 2010 22:55:06 +0000

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/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 2 Dec 2010 01:11:42 +0100

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: [email-masked] [mailto:[email-masked]] 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
> 
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 1 Dec 2010 16:15:08 -0800

I don’t think we can possibly list all approaches. We listed several and are not these enough for the implementations? Why would one need a different approach in the first place?

And in the future, if AVT decides to bless a new approach, they can update this document and 3550, no?

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, December 01, 2010 7:12 PM
> To: Colin Perkins; Robert Sparks
> Cc: IETF AVT WG
> 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.
> 
> 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
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 2 Dec 2010 01:18:22 +0100

I'm actually agreeing with you.

What I'm really saying is - If you have a use case where one of these doesn't work, or is difficult, and you have a further proposal, then we'll add it. But otherwise do you really need the freedom?

Keith

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Thursday, December 02, 2010 12:15 AM
> To: DRAGE, Keith (Keith); Colin Perkins; Robert Sparks
> Cc: IETF AVT WG
> Subject: RE: [AVT] AD review: draft-ietf-avt-rtp-cnames-02
> 
> I don’t think we can possibly list all approaches. We listed 
> several and are not these enough for the implementations? Why 
> would one need a different approach in the first place?
> 
> And in the future, if AVT decides to bless a new approach, 
> they can update this document and 3550, no?
> 
> -acbegen
> 
> Behalf Of 
> > DRAGE, Keith (Keith)
> > 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 
> > How much freedom do implementors actually need in this area? Is the 
> > only restriction really one where the root value is not 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Colin Perkins
> > > 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.
> > >
> 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.
> > >
> > > 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?
> > >
> > >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 1 Dec 2010 16:22:49 -0800

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, December 01, 2010 7:18 PM
> To: Ali C. Begen (abegen); Colin Perkins; Robert Sparks
> Cc: IETF AVT WG
> What I'm really saying is - If you have a use case where one of these doesn't work, or is difficult, and you have a further
> proposal, then we'll add it. But otherwise do you really need the freedom?

I think this is what we said during the development of the draft. And I don’t see a reason to change it now.

Cheers, acbegen.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Dec 2010 09:53:04 -0600

Could we get a short statement in the draft, then, that captures this rational for the MUST.
Specifically, I want to highlight to reviewers and implementers that other algorithms can, in fact,
be used in the future, but that they need review before deployment. (Or am I misunderstanding this exchange?)

RjS

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Dec 2010 07:59:45 -0800

OK, let's add the following to the end of Section 4. 

<text>
A future specification might define an alternative method for generating RTCP CNAMEs as long as the proposed method has appropriate uniqueness, and there is consistency between the methods used for multiple RTP sessions that are to be correlated. However, such a specification needs to be reviewed and approved before deployment.
</text>

Let me know if this good enough to resolve this. Also do we need to specify "AVT" here as the approver?

-acbegen

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 10:53 AM
> To: Ali C. Begen (abegen)
> Cc: DRAGE, Keith (Keith); Colin Perkins; IETF AVT WG

---

From: Roni Even <[email-masked]>
Date: Thu, 02 Dec 2010 18:45:08 +0200

Hi,
This looks good. 
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, December 02, 2010 6:00 PM
> To: Robert Sparks
> A future specification might define an alternative method for
> generating RTCP CNAMEs as long as the proposed method has appropriate
> uniqueness, and there is consistency between the methods used for
> multiple RTP sessions that are to be correlated. However, such a
> specification needs to be reviewed and approved before deployment.
> </text>
> 
> > be used in the future, but that they need review before deployment.
> (Or am I misunderstanding this exchange?)
> >
> > RjS
> >
> > >> What I'm really saying is - If you have a use case where one of
> these doesn't work, or is difficult, and you have a further
> > > I think this is what we said during the development of the draft.
> And I don't see a reason to change it now.
> > >
> > > Cheers, acbegen.
> > >
> > >> Keith
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 2 Dec 2010 18:20:07 +0100

Essentially, although this is not an IANA registration, we are setting the barrier at "RFC required" to reuse the terminology.

IETF will direct any new work to the appropriate working group, which would probably be AVT, may may not be for always, so do not mention AVT as the review body.

I might precede the text you have written with an additional sentence or two, something like:

"It is believed that obtaining uniqueness is an important property that requires careful evaluation of the mechanism. This document provides a number of mechanisms, for which it is believed that at least one of them would meet all deployment scenarios. This document therefore does not provide for the implementor to define and select an alternative method." 

regards

Keith

> From: Roni Even [mailto:[email-masked]] 
> Sent: Thursday, December 02, 2010 4:45 PM
> To: 'Ali C. Begen (abegen)'; 'Robert Sparks'
> Cc: DRAGE, Keith (Keith); 'Colin Perkins'; 'IETF AVT WG'
> > > Could we get a short statement in the draft, then, that captures 
> > > this
> > rational for the MUST.
> > > Specifically, I want to highlight to reviewers and 
> implementers that
> > other algorithms can, in fact,
> > > >> proposal, then we'll add it. But otherwise do you 
> really need the
> > freedom?
> > > >

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Dec 2010 21:12:58 +0000

This suggestion looks good to me, and captures my understanding of the rationale.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Dec 2010 13:15:11 -0800

Thanks. End of section 4 now says:

It is believed that obtaining uniqueness is an important property that requires careful evaluation of the method. This document provides a number of methods, for which it is believed that at least one of them would meet all deployment scenarios. This document therefore does not provide for the implementor to define and select an alternative method.

-acbegen

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 4:13 PM
> To: DRAGE, Keith (Keith)
> Cc: Roni Even; Ali C. Begen (abegen); 'Robert Sparks'; 'IETF AVT WG'