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

Hi Robert,

Thanks for your review.
Please find our comments in-line.
In addition, in the registration section some changes proposed by Martin Dürst were made.
For the name of the change controller, the remark of Colin has been considered and, for the moment, only the name of the WG has been updated.

The updated draft has been submitted a few minutes ago.

Best regards,
Frans

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> Behalf Of Robert Sparks
> Sent: Wednesday 18 May 2011 18:09
> To: payload@ietf.org; draft-ietf-payload-rfc3016bis-00@tools.ietf.org
> Subject: [payload] AD review: draft-ietf-payload-rfc3016bis-00
>
> 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>)?

We think this is correct because we did not manage to contact the original 3016 authors.

> 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 changes have been described in a little more detail and a list is added with the changed requirements.

> 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 abstract has been updated accordingly.

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

One more occurrence of "new" has been removed.

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

It has been made more explicit that there is no need to consider backward compatibility.

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

A new section titled "Clarifications on specifying codec configurations for MPEG-4 Audio" has been added to describe the various sampling rates and channel configurations.

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

As said above, this has been updated.

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

That paragraph has now been split into two paragraphs.

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

These nits have been corrected.

> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.