Subject: Re: [Gen-art] Gen-ART review of draft-ietf-fecframe-interleaved-fec-scheme-05

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 5 Jan 2010 21:13:18 -0800

Hi Spencer,

Thanks for the detailed review. See inline.

> Summary: This draft is almost ready for publication as a Proposed Standard.
> In my review, I found a few uses of 2119 language that did not seem to be
> justified (identified below as "Spencer (minor):"). The ADs should consider
> whether these uses should be changed or left alone.
> 
> Abstract
> 
>    This document defines a new RTP payload format for the Forward Error
>    Correction (FEC) that is generated by the 1-D interleaved parity code
>    from a source media encapsulated in RTP.  The 1-D interleaved parity
>    code is a systematic code, where a number of repair symbols are
>    generated from a set of source symbols and sent in a repair flow
>    separate from the source flow that carries the source symbols.  The
>    1-D interleaved parity code offers a good protection against bursty
>    packet losses at a cost of decent complexity.  The new payload format
> 
> Spencer (nit): "decent" doesn't seem entirely clear here. "additional"?
> "reasonable"?

"Reasonable" sounds good.

> 
>    defined in this document is used (with some exceptions) as a part of
>    the DVB Application-layer FEC specification.
> 
> 1.  Introduction
> 
>    Note that the source and repair packets belong to different source
>    and repair flows, and the sender MUST provide a way for the receivers
>    to demultiplex them, even in the case they are sent in the same
> 
> Spencer (minor): I'm not used to seeing normative statements in
> Introductions, and this MUST appears prior to the requirements conventions
> in section 2, but ignoring that - isn't this a statement about the mechanism
> in this draft, and not (so much) a statement about what a sender MUST do?
> (If you use the mechanism described in this draft, doesn't that satisfy the
> MUST?) I'd suggest something like "... and the sender needs to use a
> mechanism that provides a way ...", punting on the 2119 language completely.

Will do.

> 1.1.  Use Cases
> 
>    We generate one interleaved FEC packet out of D non-consecutive
>    source packets.  This repair packet can provide a full recovery of
>    the missing information if there is only one packet missing among the
>    corresponding source packets.  This implies that 1-D interleaved FEC
>    protection performs well under bursty loss conditions provided that L
>    is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter
>    than the duration of the burst that is intended to be repaired.
> 
> Spencer (minor): again, I don't think this is a 2119 SHOULD (NOT) - isn't it
> a definition?

Yes, it is a definition, we can make it lowercase.
 
> 1.3.3.  ETSI TS 102 034
> 
>    The Annex E of [ETSI-TS-102-034] defines an optional protocol for
>    Application-layer FEC (AL-FEC) protection of streaming media for
>    DVB-IP services carried over RTP [RFC3550] transport.  AL-FEC
>    protocol uses two layers for protection:  a base layer that is
>    produced by a packet-based interleaved parity code, and an
>    enhancement layer that is produced by a Raptor code.  While the use
> 
> Spencer (nit): could you provide a reference for "Raptor code", or at least
> include a definition for it?

Will provide an informative reference.
 
> 4.1.  Source Packets
> 
>    The source packets MUST contain the information that identifies the
> 
> Spencer (minor): this MUST (and the one at the beginning of 4.2) seem to
> define requirements for the protocol mechanism, not behavior for the
> endpoints - I'm thinking this isn't 2119 language. Just "... source packets
> contain the information ..."?

Sounds good to me.
 
> 4.2.  Repair Packets
> 
>    o  Payload Type:  The (dynamic) payload type for the repair packets
>       is determined through out-of-band means.  Note that this document
>       registers a new payload format for the repair packets (Refer to
>       Section 5 for details).  According to [RFC3550], an RTP receiver
>       that cannot recognize a payload type must discard it.  This
> 
> Spencer (nit): not sure what "This" refers to - the action of discarding an
> unrecognized payload type? If so, I'm thinking "... must discard it, and
> this action provides ..."

Yes, "this action" would be a better form.

There are a few comments from IESG and these all will be addressed in the next revision.

Cheers, acbegen.

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2010 14:24:44 -0500

Thanks for your diligence.  I do not see a problem with the "should not" 
in Section 1.1 or the "must" in Section 4.2.  The meaning is clear.

I do not find a "must" in Section 4.1.

Russ

On 1/13/2010 12:24 PM, Spencer Dawkins wrote:
> Hi, Russ,
>
> As you requested, I verified version -09 against my previous comments.
>
> All of my comments were addressed (thanks, authors!), but I did want to
> point one thing out - I had challenged a SHOULD NOT at the beginning of
> 1.1 and two MUSTs in 4.1 and 4.2 as not being 2119 statements, and the
> authors lower-cased these to "should not"/"must".
>
> I know there's a religious debate on whether 2119 language is
> case-insensitive(and the debate I had seen most recently was 70-30 "no",
> but it wasn't unanimous), but i'm not sure what *your* opinion is, and I
> wanted to make sure that you noticed this as part of your evaluation.
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: "Ali C. Begen (abegen)"
> <[email-masked]>
> To: "Spencer Dawkins" <[email-masked]>;
> <[email-masked]>
> Cc: "General Area Review Team" <[email-masked]>
> Sent: Tuesday, January 05, 2010 11:13 PM
> Subject: RE: Gen-ART review of
> draft-ietf-fecframe-interleaved-fec-scheme-05
>
>
> Hi Spencer,
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2010 16:35:26 -0500

Spencer:

Actually, in this case I'm saying that there is no confusion about the 
meaning.  I'm being pragmatic.  It is late in the process.  I do not 
think someone will make this into a protocol requirements statement.

Russ

On 1/13/2010 2:45 PM, Spencer Dawkins wrote:
> Hi, Russ,
>
> Sorry, must have eyes tested. 4.1 is now "need to contain", not "MUST
> contain". I was actually looking at the last sentence before 1.3.3,
> which is now "must be aware".
>
> But I think you're telling me that lower-cased "must", etc. isn't still
> 2119 - good to know.
>
> Thanks!
>
> Spencer
>
>
>> Thanks for your diligence. I do not see a problem with the "should
>> not" in Section 1.1 or the "must" in Section 4.2. The meaning is clear.
>>