Re: [Fecframe] comments on draft-ietf-fecframe-dvb-al-fec-02.txt

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Stephan,

Inline.

> -----Original Message-----
> From: Stephan Wenger [mailto:stewe at stewe.org]
> Sent: Monday, August 31, 2009 6:47 PM
> To: Ali C. Begen (abegen); zouzixuan; fecframe at ietf.org
> Cc: Thomas Stockhammer
> Subject: Re: [Fecframe] comments on draft-ietf-fecframe-dvb-al-fec-02.txt
> 
> Hi,
> 
> This may be a bit out of context, and if so, I apologize.
> 
> Am I right that this I-D attempts to circumscribe an existing ETSI spec in
> IETF lingo?  What's the purpose of this exercise?

The goal is to describe the AL-FEC protocol by using the IETF-approved specs. I believe this is a pretty good reason to have an informational rfc (The WG agreed on this when we submitted the first version).

 
> Unrelated to the technical aspects here, it seems odd to me that an IETF
> informational RFC-to-be would attempt to use any RFC 2119 normative language
> to describe what is already specified elsewhere (using non-RFC2119 lingo).
> First, arguably, an informational RFC should not use RFC2119 language at
> all---as it is informational.  Second, there may be subtle differences

We attempted to use 2119 language for the implementers of the 1-d draft to become compatible with the al-fec protocol. Is this incorrect use of the 2119 language?

If it is, then we can certainly lower-case those words. 

> between the interpretation of the normative languages of the two
> organization which could be lost in the "translation" process.  That, in
> turn, could lead to incompatible implementations stemming from the different
> specs.

I suppose lower-case words will help with this, too.
 
> On a more general note, the abstract should be more concise, and (especially
> in cases like this) focus on the obvious question of the purpose of the
> document, rather than the technical details.

OK. An updated abstract will be included in the next revision.

BR,
-acbegen

 
> Regards,
> Stephan
> 
> 
> 
> On 8/31/09 3:15 AM, "Ali C. Begen (abegen)" <abegen at cisco.com> wrote:
> 
> >>> Page 6, in SSRC item: " It is RECOMMENDED that the DVB AL-FEC
> >>> protocol uses this mechanism for explicit SSRC signaling"
> >>> Doe it make sense to use the keyword "RECOMMEDED"
> >>> within the scope of IETF to guide the way of using SSRC for AL-FEC
> >> protocol
> >>> specified in DVB?
> >>
> >> Using a deterministic SSRC=0 value is a special case, and is only acceptable
> >> by RTP if it is signaled explicitly.
> >>
> >> Do you think we should say "MUST" or "SHOULD"?
> >>
> >> [zou] It seems that I lead to a misunderstanding. Sorry. I'm asking whether
> >> it makes sense to stipulate in IETF the manner of a DVB standard by using
> >> the IETF keywords "RECOMMENDED" or "MUST" whatever. Maybe a lowercase form
> >> would be more proper.
> >
> > That keyword applies to the ones who will use an IETF spec (interleaved-fec
> > draft) to implement the al-fec protocol. So, I believe the use of the
> > keyword(s) is appropriate.
> >
> > -acbegen
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe at ietf.org
> > https://www.ietf.org/mailman/listinfo/fecframe
>