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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Robert,

> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: Monday, February 21, 2011 12:48 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00
> 
> 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

I am fine with removing this sentence, since the earlier sentence tells what I wanna say.
 
> 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.

Good suggestion.
 
> 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?

Implementers. As being more assertive, I am not sure how we could do that since we don’t wanna be more assertive.
 
> 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.

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
 
> 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

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.

> 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

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

> description of retries could point to where the limit on the
> number of retries is defined.

We did not define a max limit since if the client needs it, it will keep trying I guess.
 
> 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".

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

OK.
 
> 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.

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

Thanks.
-acbegen