Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor

[Thomas Stockhammer <[e-mail]>]

Dave, all

thanks for the comments, please find inline responses.
In addition to the comments, the references are separated in normative and informative.

I do think we can move the RTP payload also to WGLC, but thus may have to happen in AVTCORE.

Thanks

Thomas

> Can you get a revised ID asap?

[T] A revised ID is prepared and has been uploaded here http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-05.txt

> AD Review of draft-ietf-fecframe-rtp-raptor-04:
> It would be good to use RFC2119 keywords in active voice - "The implementer SHOULD
> select" (or is it the operator?) rather than "It is RECOMMENDED to select".
> For example, I recommend changing "The (integer) rate SHALL be larger than 1000".
> Whose responsibility is it to enforce this SHALL? MUST implementations
> reject values less than 1000? (if implementations don't enforce this, I don't know
> how you'll enforce this SHALL. Which means a user MAY choose a lower value;
> therefore this isn't really a MUST. yada yada yada ...
> So you should use active voice to be explicit about whose responsibility it is to enforce this MUST. (and similar to RFC 3665, MUST is for implementers; SHOULD is for users).

[T] It is the responsibility of the operator to pick a value of 1000 at least. This has been made clear in the revision.

> in 5.1.1, rate definition. 
> "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate
> SHALL be larger than 1000 to provide sufficient resolution to RTCP
> operations. However, it is RECOMMENDED to select the rate that matches the rate of
> the protected source RTP stream." The However in this paragraph makes it
> sound like you recommend using the rate that matches (even if it is below 1000).
> I recommend removing the "However," 

[T] Done

> in 5.1.1, s/shall/SHALL/

[T] Done

> "Restrictions on usage: This media type depends on RTP framing, and hence is only
> defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols
> is not defined at this time. " Do we need the "at this time"? Is it envisioned this
> media type will be exteneded for additional framing protocols at a later time?

[T] Yes, this may indeed happen. We have seen similar generalization for other formats recently, such as the MPEG-2 TS. So it is considered  important to avoid any confusion and make it clear that the registration is for RTP only.

> in 12 s/recommended/RECOMMENDED/, s/may/MAY/g

[T] Done

> in 8, is Session Announcement Protocol (SAP) [RFC2947] the right reference? I saw no mention of SAP in 2947.

[T] This is indeed wrong, it needs to be RFC2974. Thanks!


> in 15.2, rfc2947 seems to refer to the wrong document. I think you
> need 2974.

[T] See above

> in 1, "Repair data flows may be sent directly over a transport protocol
> such as UDP, or they may be encapsulated within RTP." Is RTP the only
> protocol that could be used to encapsulate flows? should this be "they may be
> encapsulated within specialized transports for multimedia, such as RTP"?

[T] Agreed! Despite nothing is defined today, it be in the future. I have changed accordingly.

> s/FECs operates/FECs operate/

[T] Done

> s/an FEC/a FEC/

[T] Done

> Shepherd, Since AVT is the change controller, was this WGLC'd in AVT?

[T] No this was not yet done. It would be good to send out the Raptor schemes for WGLC. Once this is done, I will send out a message to the AVT list reporting the status of the Raptor schemes and this payload format and ask if WGLC'd in AVT can be issued. Is this appropriate?

Thomas

> 
> Thanks,
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
> 

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.