Subject: [AVTCORE] AD review: draft-ietf-ports-for-ucast-mcast-rtp-00

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Feb 2011 15:06:52 -0600

Summary: Ready, but with minor concerns.
        I've requested IETF LC - please treat these as 
        IETF LC comments

1) Section 3.2: "That is, clients MUST NOT implement this
specification with only a specific use case in mind" is not
testable. I suggest either removing the sentence or replacing it
with something that is more of an observation of the consequences
of improperly implementing the MUST in the preceeding sentence

2) Consider replacing "guaranteed to be temporally and globally
unique" in section 4.1 with "extremely unlikely to collide with
other clients sharing the same IP address", pointing again to
4086 for implementation guidance.

3) In section 4.3.1, "might also need to be authenticated" could
be more assertive. Are you trying to primarily influence
implementers or application designers here? 

4) In the final paragraph of Section 5, "and implementations
might need to handle this eventually" is not that useful. Please
consider deleting the phrase, or providing a concrete
recommendation.

5) The end of Section 6 could be read to say that receiving a
token verification failure message is part of the normal path for
discovering that a session description change has occurred. Was
the intent here to note that a _very_ recent change may have
occurred and that an implementation should take care to avoid
scheduling retries when that happens? If so, could this be
rewritten to look less like it is encouraging implementations to
rely on Token Verification Failures to notice that a session
description has changed?  Finally, it would help if this short
description of retries could point to where the limit on the
number of retries is defined.

6) (Nit) Section 7.1.1 "The 'portmapping-req' attribute SHALL be
used as a media-level attribute" is slightly off target. It says
that the attribute SHALL be used. The intent, I think, is that
if it is used, it is used only at the media-level. I suggest 
adding the word "only" at "SHALL only be used".

7) To avoid confusion, consider saying "sub-registry of the
Real-Time Transport Protocol (RTP) Parameters registr for the
sub-message type"...

8) The way Section 3.2's item 5 is currently written,
[I-D.ietf-avt-app-rtp-keepalive] looks like it should be a
normative reference. If you intend for implementers to follow the
guidance in that draft, please move the reference to normative
and strengthen the text. If that's not the intent, adjust the
text to make it clear that you are referring people to that draft
for more information about the problem.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 23 Feb 2011 15:51:08 -0800

Hi Robert,

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Monday, February 21, 2011 12:48 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00
> 

I am fine with removing this sentence, since the earlier sentence tells what I wanna say.
 
> 4086 for implementation guidance.

Good suggestion.
 
> implementers or application designers here?

Implementers. As being more assertive, I am not sure how we could do that since we don’t wanna be more assertive.
 
> consider deleting the phrase, or providing a concrete

Deleting is fine with me:

   Finally, be aware that NTP timestamps will wrap around in year 2036.
   Refer to Section 6 of [RFC5905] for further details
 
> discovering that a session description change has occurred. Was

I don’t think the implementations should try the token approach to confirm whether SDP was updated or not. That was not the intention of this text.

> description has changed?  Finally, it would help if this short

I hope it does not encourage doing that. I will think how to reword this.

> number of retries is defined.

We did not define a max limit since if the client needs it, it will keep trying I guess.
 
> adding the word "only" at "SHALL only be used".

Good catch.
 
> Real-Time Transport Protocol (RTP) Parameters registr for the

OK.
 
> for more information about the problem.

OK, we did not intend to make it normative. I will check the text.

Thanks.
-acbegen

---

From: Robert Sparks <[email-masked]>
Date: Fri, 25 Feb 2011 11:02:15 -0600

(trimming to one topic)

> Implementers. As being more assertive, I am not sure how we could do that since we don’t wanna be more assertive.

Are you trying to not be assertive about implementing or about using? If you're just trying to avoid forcing people to _use_
the mechanism, but want to make sure a particular deployment can decide to use the mechanism without forklifting its
install base, you could say something like  "Implementations MUST support authenticating such RTCP messages by 
using a Token".

RjS

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 25 Feb 2011 09:07:41 -0800

> Sent: Friday, February 25, 2011 9:02 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00
> 
> (trimming to one topic)
> 

Ok, thanks. This addresses my concern. I will hold on to the changes till we get the other LC comments.

-acbegen