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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 4 Jun 2011 17:04:42 -0700

Section 3: 
- I suppose UL stands for Universal Label. Maybe define the acronym when "Universal Label" first appears.
- s/ "K L V"/"KLV"

Section 4.3.1.1:
- In the figure, "for time 30" was repeated twice. 
- 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.
- Consider replacing "may" with an alternative like "can" or "might". (You might wanna consider this for any lower-case version of 2119 keywords)

Section 6.1:
- Put a note for RFC editor to replace RFCXXXX with this doc's RFC number.
- Put a "None" in optional parameters.
- Are the target applications really streaming and conferencing tools? Any broadcast, video transport application targeted?
- Add "IETF Payload Working Group" for further contact. Also change the control from AVT to PAYLOAD.
- I believe you ought to repeat the registration for video, audio and text as well, although you do not need them.

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)

-acbegen

---

From: Jeff Downs <[email-masked]>
Date: Wed, 15 Jun 2011 14:25:50 -0400

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

> - I suppose UL stands for Universal Label. Maybe define the acronym when "Universal Label" first appears.

Fixed.

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

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.

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

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