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

[Robert Sparks <[e-mail]>]

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.