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

["Ali C. Begen (abegen)" <[e-mail]>]

I think LC'ing here is sufficient. But, cc'ing [e-mail] would let them know about this and give the opportunity to review it. At the end, it is an RTP payload format doc.

-acbegen

> -----Original Message-----
> From: Greg Shepherd [mailto:[e-mail]]
> Sent: Monday, October 10, 2011 1:54 PM
> To: Ali C. Begen (abegen)
> Cc: Thomas Stockhammer; David Harrington; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor
> 
> Ali,
> 
> It's still a FF doc and needs to LC here, but are you saying Payload
> WG also needs LC rather than just review?
> 
> Greg
> 
> On Mon, Oct 10, 2011 at 10:43 AM, Ali C. Begen (abegen)
> <[e-mail]> wrote:
> > Note that it is not avtcore who should review this draft but it is payload wg. Also, the controller should be the Payload WG.
> >
> > -acbegen
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of Thomas Stockhammer
> >> Sent: Monday, October 10, 2011 1:39 PM
> >> To: David Harrington
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor
> >>
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Fecframe mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/fecframe
> > _______________________________________________
> > Fecframe mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/fecframe
> >