Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04

[Vincent Roca <[e-mail]>]

Greg, Mike, everybody,

We had a discussion last month on the topic:
         "Managing losses between the sending application
          and the FECFRAME instance"
as part of the framework I-D (see the bottom of page 41 for
the agreed text).

The RTP Raptor I-D is of course concerned by this discussion
and unfortunately this -04 version is from November 2010,
before the discussion.

Unless I missed some key sentence, I have the feeling that this
I-D implicitly assumes there CANNOT be any RTP packet loss
before reaching the Fecframe encoder, i.e. the RTP SN are always
in sequence.

(NB: the only text I've found that discusses RTP SN is in
section 3 and does not mention this requirement at all)

It's a critical requirement that MUST be clearly stated. If there is
any risk this requirement does not hold, the I-D MUST define an
appropriate behavior. So it's worth a quick fix (it's fairly easy) IMHO.
Note that it might also be an attack (in specific deployment
scenarios, not all of them of course), so it's also worth saying a
few words in section 12 as well (BTW, we should do the same in
the FEC Framework I-D, I didn't realize that before, sorry).

Cheers,

   Vincent

On 11/03/11 13:13, Greg Shepherd wrote:
> *,
>
> The document draft-ietf-fecframe-rtp-raptor-04 is now ready for
> publication. Please see the Document Shepherd Write-up below.
>
> Thanks,
> Greg
>
> ---
>
> Document Shepherd Write-up for draft-ietf-rtp-raptor-04 as per RFC
> 4858, template dated September 17, 2008
>
> (1.a) Who is the Document Shepherd for this document? Has the
>          Document Shepherd personally reviewed this version of the
>          document and, in particular, does he or she believe this
>          version is ready for forwarding to the IESG for publication?
>
> I, Greg Shepherd as the document shepherd have personally reviewed
> this document and believe it to be ready for forwarding to the IESG.
>
> (1.b) Has the document had adequate review both from key WG members
>          and from key non-WG members? Does the Document Shepherd have
>          any concerns about the depth or breadth of the reviews that
>          have been performed?
>
> The document has had adequate review both from within and from outside
> the FECFrame working group.
>
> (1.c) Does the Document Shepherd have concerns that the document
>          needs more review from a particular or broader perspective,
>          e.g., security, operational complexity, someone familiar with
>          AAA, internationalization or XML?
>
> There are no concerns regarding the need for additional expanded review.
>
> (1.d) Does the Document Shepherd have any specific concerns or
>          issues with this document that the Responsible Area Director
>          and/or the IESG should be aware of? For example, perhaps he
>          or she is uncomfortable with certain parts of the document, or
>          has concerns whether there really is a need for it. In any
>          event, if the WG has discussed those issues and has indicated
>          that it still wishes to advance the document, detail those
>          concerns here. Has an IPR disclosure related to this document
>          been filed? If so, please include a reference to the
>          disclosure and summarize the WG discussion and conclusion on
>          this issue.
>
> There are no specific concerns with this document.
>
> (1.e) How solid is the WG consensus behind this document? Does it
>          represent the strong concurrence of a few individuals, with
>          others being silent, or does the WG as a whole understand and
>          agree with it?
>
> There is solid WG consensus for this document.
>
> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>          discontent? If so, please summarise the areas of conflict in
>          separate email messages to the Responsible Area Director. (It
>          should be in a separate email because this questionnaire is
>          entered into the ID Tracker.)
>
> There is no discontent.
>
> (1.g) Has the Document Shepherd personally verified that the
>          document satisfies all ID nits? (See the Internet-Drafts Checklist
>          and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>          not enough; this check needs to be thorough. Has the document
>          met all formal review criteria it needs to, such as the MIB
>          Doctor, media type and URI type reviews?
>
> Only two miscellaneous warnings  and one outdated reference which can
> be addressed with editor's notes:
>
>    == The copyright year in the IETF Trust and authors Copyright Line does not
>       match the current year
>
>    -- The document date (November 25, 2010) is 46 days in the past.  Is this
>       intentional?
>
>    == Outdated reference: A later version (-04) exists of
>       draft-ietf-fecframe-raptor-02
>
> (1.h) Has the document split its references into normative and
>          informative? Are there normative references to documents that
>          are not ready for advancement or are otherwise in an unclear
>          state? If such normative references exist, what is the
>          strategy for their completion? Are there normative references
>          that are downward references, as described in [RFC3967]? If
>          so, list these downward references to support the Area
>          Director in the Last Call procedure for them [RFC3967].
>
> Normative and informative references are split with two reference to
> drafts that are currently in the editor's queue or will be soon.
>
> (1.i) Has the Document Shepherd verified that the document IANA
>          consideration section exists and is consistent with the body
>          of the document? If the document specifies protocol
>          extensions, are reservations requested in appropriate IANA
>          registries? Are the IANA registries clearly identified? If
>          the document creates a new registry, does it define the
>          proposed initial contents of the registry and an allocation
>          procedure for future registrations? Does it suggest a
>          reasonable name for the new registry? See [RFC5226]. If the
>          document describes an Expert Review process has Shepherd
>          conferred with the Responsible Area Director so that the IESG
>          can appoint the needed Expert during the IESG Evaluation?
>
> Section 12 describes the IANA considerations, which refers to Section
> 5 for a comprehensive registration description. The document itself is
> primarily a document of media registrations/definitions.
>
> (1.j) Has the Document Shepherd verified that sections of the
>          document that are written in a formal language, such as XML
>          code, BNF rules, MIB definitions, etc., validate correctly in
>          an automated checker?
>
> The xml code validates correctly
>
> (1.k) The IESG approval announcement includes a Document
>          Announcement Write-Up. Please provide such a Document
>          Announcement Write-Up? Recent examples can be found in the
>          "Action" announcements for approved documents. The approval
>          announcement contains the following sections:
>
> Technical Summary
> 	This document specifies an RTP payload format for Forward Error
> Correction /  (FEC) repair data produced by the Raptor FEC schemes.
> Raptor FEC schemes are specified for use with the IETF FEC Framework
> which supports transport of repair data over both UDP and RTP. This
> document specifies the payload format which is required for the use of
> RTP to carry Raptor repair flows.
>
> Working Group Summary
> 	There were no seriously contentious issues during the WG process.
>
> Document Quality
> 	The Working Group feedback covered both the quality of the document
> itself as well as the technical issues with the content of the
> document.
>
> Personal
> 	Document Shepherd - Greg Shepherd
> 	Responsible Area Director - David Harrington<[e-mail]>
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe