Re: [payload] Review of draft-ietf-payload-rtp-klv-00

[Jeff Downs <[e-mail]>]

I've uploaded a new draft (-01) that I believe addresses all the 
comments.  Details are below.  Thank you Ali for the review.

On 6/4/2011 8:04 PM, Ali C. Begen (abegen) wrote:
> Section 3:
> - I suppose UL stands for Universal Label. Maybe define the acronym when "Universal Label" first appears.
> - s/ "K L V"/"KLV"

Fixed.

> Section 4.3.1.1:
> - In the figure, "for time 30" was repeated twice.

Duplicate removed, thanks.

> - The first rule seems to be underspecified. What if seq=3 had a marker set to 1, and seq=4 and 5 had a marker set to 0? Both 4 and 5 would be considered damaged, right? So, it is not just the prior packet. And in this case, SHOULD must be a MUST, right? The SHOULD in the 2nd rule seems correct, though.

Both rules should have been specified in terms of considering KLVunits 
damaged, with supporting language to identify constituent packets of 
those damaged units, but that first rule was rather confusing as 
written.  I reworded this entirely to better reflect what it was 
attempting to say.

> - Consider replacing "may" with an alternative like "can" or "might". (You might wanna consider this for any lower-case version of 2119 keywords)

Went through and looked for these, replaced per your suggestion.  Some 
of these remain (particularly "may") but these are in the template texts 
from the howto so I left them as-is.

> Section 6.1:
> - Put a note for RFC editor to replace RFCXXXX with this doc's RFC number.
> - Put a "None" in optional parameters.

Both done.

> - Are the target applications really streaming and conferencing tools? Any broadcast, video transport application targeted?

Updated with some new applications.

> - Add "IETF Payload Working Group" for further contact. Also change the control from AVT to PAYLOAD.

Done.

> - I believe you ought to repeat the registration for video, audio and text as well, although you do not need them.

I wasn't sure what you meant here - if further changes are required 
please let me know and I'll be glad to address.

> Section 6.2:
> - This payload format does not have optional parameters. Actually it does not have anything besides the rate. Maybe, you should get the required text from 4855 and put it here (You don't need all the parts).
> - You need to have a section here called "Offer-Answer Model and Declarative Considerations". You might not have any such considerations, but you need to say it explicitly. Probably something like below would work:
>
>     There no configuration parameters or optional format parameters for
>     the this payload format.  Thus, when offering SMPTE 336M Encoded Data
>     over RTP using SDP in an Offer/Answer model [RFC3264] or in
>     a declarative manner (e.g., SDP in the Real-time Streaming Protocol
>     (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
>     [RFC2974]), there are no specific considerations.
>
> (Add the related RFCs to the informative part)

I think I addressed this in the draft based on a combination of the 
howto instructions and your comments - take a look and let me know if it 
is ok.

Thanks again for your review,

	-Jeff