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

["David Harrington" <[e-mail]>]

I recommend sending them an explicit email asking for review during
WGLC. 

We aren't bound by their comments, any more than anybody else's
comments, but it would be good to get their feedback.

dbh

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[e-mail]] 
> Sent: Monday, October 10, 2011 2:11 PM
> To: [e-mail]
> Cc: Thomas Stockhammer; David Harrington; 
> [e-mail]; 
> [e-mail]; [e-mail]
> Subject: RE: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor
> 
> 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
> > >
>