[payload] AD review: draft-ietf-payload-rfc3016bis-00

[Robert Sparks <[e-mail]>]

There are some issues to address with a draft revision before progressing to IETF LC:

Much of this text was from 3016, shouldn't the document be using the
pre-5378 boilerplate (see 6.c.iii of <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>)?

It is hard to tell what the actual changes from 3016 are (even when using
diff against 3016). The changes section should summarize the technical changes
with a little more detail. For instance, what exactly is the change to the binary
format of the LATM payload? It would also help to summarize where requirements levels
have changed. For instance, noting the change of the MAY to MUST (actually SHALL) in
section 5.3.

The abstract needs to mention that the document is obsoleting 3016.
Can the document explain the limitations the abstract calls out and 
better motivate the preferrence for RFC3640? Why doesn't the abstract
mention the reason for revising 3016?

The document removed the word "new" from the description of some MPEG-4
features, but not all of them. Should it have removed all of them?

Section 1.3 should more explicitly state that the working group believes
there are NO implementations of 3016 that do not already behave as the 
3GPP document (and this document) specify, so there is no need to consider 
backwards compatability. (If that's not true, there are several places where 
backwards compatability needs more consideration.)

The three new definitions in section 2 don't define the terms. Instead
they try to clarify how values are chosen in various circumstances. This
would be much clearer in a short section titled "Clarifications on specifying
sampling rates" or similar.

The change control for the two media types should say PAYLOAD instead of AVT.

The second paragraph of the security considerations section starts by exploring
the existence of covert channels, then shifts to template text on providing
security to RTP. It's not clear how those existing mechanisms help with respect
to the possibility of a covert channel. Was the intent only to note that the
covert channels existed? If so, the paragraph should be split so pointing to
the security mechanisms for RTP doesn't appear to be a response to that issue.

Nits:

Section 1.1, first paragraph: Why did "bitrates" get changed to "bitrate"?
Section 5.2, first paragrah: "enhance layer" should be "enhanced layer"