[Gen-art] Re: Gen-art review of draft-ietf-rmt-fec-bb-revised-06

[Elwyn Davies <[e-mail]>]

I am fine with all these proposals/discussions.

Regards,
Elwyn

Mark Watson wrote:
> Elwyn,
>
> Thanks for the detailed review. Comments below...
>
> Others on cc: There are some suggestions below that need your review.
>
> ...Mark
>
>
> On 4/10/07 5:25 PM, "Elwyn Davies" <[e-mail]> wrote:
>
>   
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>>
>> Document: draft-ietf-rmt-fec-bb-revised-06.txt
>> Reviewer: Elwyn Davies
>> Review Date:  11 April 2007
>> IETF LC End Date: 12 April 2007
>> IESG Telechat date: (if known) -
>>
>> Summary:
>> Almost ready for PS.  There are some minor issues and editorial nits that
>> should be addressed before it goes to the IESG.
>>
>> Comments:
>>
>> Minor Issues:
>> s6:  As well as data packets, para 1 introduces session-control and
>> feedback packets, but then para 4 says that we are specifying stuff
>> about data packets.  Session-control and feedback packets disappear into
>> the void.  Some words about what is or is not specified about these
>> other kinds of packets would help - even if only to say they are out of
>> scope.
>>
>>     
>
> Good point. I will add some words to clarify in the introduction.
>
>   
>> s6.1:  The implication of the last para is that an 8 bit field is enough
>> to hold the FEC Encoding ID (confirmed more or less in 6.2.3).  2 * 128
>> possible values may be enough but given that proprietary schemes are
>> allowed and lots of different CDPs might have different schemes, one
>> wonders if this might be constraining - and I see no means of expanding
>> the range. Justify?  Also there isn't an experimental range.
>>
>>     
>
> Yes, this has been discussed occasionally in the group and Magnus has
> mentioned this now and again. I do think that 128 values is plenty - we have
> had only a handful of FEC Schemes proposed or even mooted during the several
> years Experimental period and there isn't much reason to expect a
> significant number more - certainly nothing on the scale of RTP payload
> types, for example. Even if there were 10 times more than at present we
> would be ok.
>
> However, I would rather not be made to eat my words ;-) Instead of 2 ranges
> of 128 values, we could instead allocate 4 ranges for:
> - Fully Specified FEC Schemes
> - Dynamically allocated FEC Encoding IDs
> - Partially specified FEC Schemes
> - Experimental FEC Schemes
>
> Dynamic allocation would be preformed by means out of scope of the document
> (in practice often by SDP). As I say, I don't anticipate we will ever need
> them, but it is essentially cost-free to reserve them now.
>
> Comments ?
>  
>   
>> s6.2.1, para 4: Make it explicit whether the choice of (a) or (b) for
>> the encoding is allowed to be per object or per CDP/FEC Scheme.  Even
>> though it is probably obvious, it would be wise to state that if there
>> is an option the CDP has to provide means to transmit which choice has
>> been made.
>>     
>
> Ok. The choice is per CDP, so a CDP specification needs to state which
> mechanism is being used. I will mentioned this also in the section on CDP
> requirements, if not already.
>
>   
>> s6.2.1, last para: The statements about the length of the field read as
>> if there has been previous statements about the length of Common Object
>> encodings.  There hasn't been.  Either reword to cover all lengths here
>> or add words to the earlier paragraphs about the Common Objects.
>>     
>
> The previous statement is the last sentence of the previous paragraph.
>
>   
>> s6.3:  I would have expected (I think) that a maximum range for FEC
>> Payload IDs should be given to give a hint to CDPs on the field size
>> needed, but I may be wrong - perhaps some words of explanation as to why
>> it is not needed (if that is the case) would help others.
>>     
>
> Ok. I think the only requirement (which is a practical, rather than a
> theoretical one), is that the FEC Payload ID is a small fraction of the
> packet size. Currently in-progress FEC Scheme specifications use 4 to 8
> bytes, but one can easily imagine applications where 16 or more might be
> used. 
>
>   
>> s11: Should we still be, even indirectly, suggesting that MD5 would be a
>> suitable hash functtion?
>>
>>     
>
> No opinion from me. I would be happy to replace this with SHA1 if requested.
>
>   
>> Editorial
>> =========
>> Global: s/[Aa]n FEC/[Aa] FEC/ (OK, maybe an sounds more euphonious but
>> it is wrong).  I'm sure the RFC Editor will have a view.
>>
>>     
>
> Ah, this depends on whether you treat FEC as an abbreviation ('eff ee cee')
> or an acronym ('feck'). I use the abbreviation, and I believe this is more
> common. It also steers clearer of an Irish expletive ...
>
>
>   
>> Global: Prefer octet rather than byte.
>>     
>
> OK.
>
>   
>> s1: It would be good to explicitly state the section (4.2 I assume) of
>> RFC 3048 ([10]) which this draft covers.
>>
>>     
>
> OK.
>  
>   
>> s1: Worth expanding RMT for future generations (or remove the note about
>> the wg that produced it).
>>
>>     
>
> I will expand it, since it is worth keeping the reference to RFC 3269, which
> includes Reliable Multicast Transport in its title.
>  
>   
>> s1, para 6: Helpful to add a forward ref to s4 or s6.1 where
>> Fully/Under-Specified are defined.
>>
>>     
>
> Ok.
>  
>   
>> s4, para 1:  'A FEC code is a valuable component...':  I am not sure if
>> this the best phraseology.  Maybe: A FEC coding scheme is a valuable
>> component...  Actually I found the term 'FEC code' somewhat distracting
>> throughout - it doesn't sound quite right when referring to the adjuncts
>> needed to provide the extra FEC information and the encoding used to
>> generate them.
>>
>>     
>
> The intention was to distinguish between the basic algorithm used to
> generate FEC data ("FEC code") and the various bits of protocol coding
> needed to communicate using FEC ("FEC Scheme") - "FEC coding scheme" would
> confuse the two. We could have a different term for "FEC code" which we can
> more clearly define, if that would help ?
>  
>   
>> s4, para 4: s/ancilliary/anciliary/ (last instance)
>>     
>
> OK
>
>   
>> s5, para 1: Might be good to refer explicitly to s3.2 of RFC 2357.
>>
>>
>>     
>
> OK.
>  
>   
>> s6.1, para 5: s/FEc/FEC/
>>
>>     
>
> OK.
>  
>   
>> s6.2.2, paras 2 and 3:  It would be better to start these paras with
>> 'Any' rather than 'The'.  At present it is very easy to read paras 2 and
>> 3 as contradictory.
>>     
>
> OK.
>
>   
>> s6.2.4, last para: s/EXT-FTI/EXT_FTI/.  Also need to expand LCT acronym.
>>
>>     
>
> OK.
>  
>   
>> s6.3, last para:  The term 'systematic FEC codes' appears to be a term
>> of art that is not defined.  Explanation would be appreciated.
>>
>>     
>
> OK.
>  
>   
>> s11: s/to many receivers/at many receivers/
>>     
>
> OK.
>
>   


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art