Subject: [AVT] WGLC for draft-ietf-avt-rtp-cnames-00

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Aug 2010 13:17:15 +0200

(As WG co-chair)

This is to annouce working group last call for draft-ietf-avt-rtp-cnames-00

Due to summer vacations, the WGLC will be for 3 weeks, so please get your comments submitted by close of business Wednesday August 25th.

Please respond to this message with your comments.

It is always helpful to try and categorise your comments as to the degree of severity, e.g. editorial, minor technical correction, major technical showstopper or whatever.

It is also helpful to propose what you believe would be acceptable replacement text to fix your concern.

(Note that we have two AVT WGLCs in parallel here - please comment on both documents)

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Aug 2010 17:53:19 +0200

I was looking at the RFC 2119 language in this document and finding it almost impossible to work out what I needed to do to conform to the document.

The core here is section 4.2.

It has a title with "Guideline" which to me implies optional to implement.

The section itself consists of a number of bullets, which is preceded by the statement: "SHOULD practice one of the following guidelines" which I assume means do one and no more than one of the bullets.

Some of the bullets contain MAY only, which implies that the entire bullet is optional.

Therefore to conform to the document I essentially don't need to implement anything.

So what actually are the minimum requirements in an RTP endpoint for implementation of this document?

(I will have some other more minor comments later.)

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, August 04, 2010 12:17 PM
> To: IETF AVT WG
> Cc: [email-masked]
> Subject: [AVT] WGLC for draft-ietf-avt-rtp-cnames-00
> 
> (As WG co-chair)
> 
> Due to summer vacations, the WGLC will be for 3 weeks, so 
> please get your comments submitted by close of business 
> Wednesday August 25th.
> 
> It is always helpful to try and categorise your comments as 
> to the degree of severity, e.g. editorial, minor technical 
> correction, major technical showstopper or whatever.
> 
> It is also helpful to propose what you believe would be 
> acceptable replacement text to fix your concern.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 5 Aug 2010 10:11:44 -0700

This is what we plan to do in the revision. Hopefully, they will fix these issues.

We will say that an RTP endpoint compliant with this new spec *MUST* implement one of the bullets listed in section 4.2. Any of those bullets will be sufficient, i.e., there is no priority or order among them.

We will hold on to the revision until the WGLC is completed, though.

-acbegen

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, August 04, 2010 6:53 PM
> To: IETF AVT WG
> Subject: RE: WGLC for draft-ietf-avt-rtp-cnames-00
> 
> The section itself consists of a number of bullets, which is preceded by the statement: "SHOULD practice one of the following
> guidelines" which I assume means do one and no more than one of the bullets.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Aug 2010 19:35:39 +0200

That is at least an improvement.

But with that structure, I would suggest the RFC 2119 language in each bullet has to become MUST as well, i.e. "In this specific solution (bullet), the RTP endpoint MUST...". If an implementor does not like that MUST, then they choose another bullet and therefore another option. Otherwise, I choose, for example, the first bullet, treat the MAY as an option, and do nothing. Hey presto, compliance!

Finally, is this intended to be a complete set, or do you allow an option that an implementor can adopt any other solution providing they demonstrate that it meets the criteria, in for example as section 4.1?

As regards reissue, I think the WGLC can still continue on the current version. I believe the general understanding is that each bullet represents a distinct solution, and can be reviewed as such, and it is just a matter of getting the words right to reflect that. Of course if anyone else needs the real words...

regards

Keith

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Thursday, August 05, 2010 6:12 PM
> To: DRAGE, Keith (Keith); IETF AVT WG
> We will say that an RTP endpoint compliant with this new spec 
> *MUST* implement one of the bullets listed in section 4.2. 
> Any of those bullets will be sufficient, i.e., there is no 
> priority or order among them.
> 
> > I was looking at the RFC 2119 language in this document and 
> finding it 
> > almost impossible to work out what I needed to do to 
> conform to the document.
> > 
> > The section itself consists of a number of bullets, which 
> is preceded 
> > by the statement: "SHOULD practice one of the following 
> > So what actually are the minimum requirements in an RTP 
> endpoint for implementation of this document?
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of DRAGE, Keith (Keith)
> please get 
> > > your comments submitted by close of business Wednesday 
> August 25th.
> > >
> > > It is always helpful to try and categorise your comments 
> as to the 
> > > degree of severity, e.g. editorial, minor technical correction, 
> > > major technical showstopper or whatever.
> > >
> > > (Note that we have two AVT WGLCs in parallel here - 
> please comment 
> > > on both documents)
> > >
> > > regards
> > >
> > > Keith

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 Aug 2010 12:14:35 -0400

I'd recommend saying that an RTP endpoint MUST choose a CNAME that ensures global uniqueness with respect to any other current, past, or future participant in the RTP session (or, for persistent CNAMEs, in all the RTP sessions the endpoint has joined in the past or may join in the future).  In practice, this probably means CNAMEs that are globally unique over space and time, and it may be simpler just to say that CNAMEs MUST be globally unique, period.  Compare with the text for SIP Call-ID in RFC 3261.

The bullets listed in section 4.2 are then various possible ways of achieving global uniqueness, but other methods may also be possible, and I don't think we want to preclude using them.

We probably also want to require that CNAMEs MUST be ASCII text, possibly with some syntactic restrictions (no spaces?).

It would also be useful to have guidance for what to do when there are multiple logically-distinct participants running on the same device (e.g. a media server, PSTN gateway, or what have you).  Presumably the user part of the CNAME should be used for this purpose, at least for persistent CNAMEs.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> Sent: Thursday, August 05, 2010 1:12 PM
> Subject: Re: [AVT] WGLC for draft-ietf-avt-rtp-cnames-00
> 
> We will say that an RTP endpoint compliant with this new spec *MUST*
> implement one of the bullets listed in section 4.2. Any of those
> bullets will be sufficient, i.e., there is no priority or order among
> them.
> 
> > I was looking at the RFC 2119 language in this document and finding
> it almost impossible to work out what I needed to do to
> > conform to the document.
> >
> > The section itself consists of a number of bullets, which is preceded

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Aug 2010 11:38:14 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Lennox
> Sent: Monday, August 09, 2010 9:15 AM
> To: Ali C. Begen (abegen); DRAGE, Keith (Keith); IETF AVT WG
> I'd recommend saying that an RTP endpoint MUST choose a CNAME that
> ensures global uniqueness with respect to any other current, past, or
> future participant in the RTP session (or, for persistent CNAMEs, in
> all the RTP sessions the endpoint has joined in the past or may join in
> the future).  In practice, this probably means CNAMEs that are globally
> unique over space and time, and it may be simpler just to say that
> CNAMEs MUST be globally unique, period.  Compare with the text for SIP
> Call-ID in RFC 3261.
> 
> The bullets listed in section 4.2 are then various possible ways of
> achieving global uniqueness, but other methods may also be possible,
> and I don't think we want to preclude using them.

That results in "do the right thing", to which every implementer will 
declare compliance.

Right now, inside my company, we have folks claiming SSRC=0 is "a 
perfectly valid random value, which happens to be chosen every time".
There are similar arguments for a CNAME that uses the hostname
(e.g., "home.comcast.net") and that matching CNAMEs should be 
resolved by examining other information such as the source IP
address or UDP port of the RTCP packet.  That's why we wanted to
be clearer and say do X, Y, or Z, and not leave wiggle-room for
"doing the right thing", because experience has shown implementations
aren't doing the right thing.

-d

> We probably also want to require that CNAMEs MUST be ASCII text,
> possibly with some syntactic restrictions (no spaces?).
>
> It would also be useful to have guidance for what to do when there are
> multiple logically-distinct participants running on the same device
> (e.g. a media server, PSTN gateway, or what have you).  Presumably the
> user part of the CNAME should be used for this purpose, at least for
> persistent CNAMEs.
> 
> --
> Jonathan Lennox
> Vidyo, Inc
> [email-masked]
> 
> > > So what actually are the minimum requirements in an RTP endpoint
> for
> > implementation of this document?
> > >