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

[Mark Watson <[e-mail]>]

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