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

From: Elwyn Davies <[email-masked]>
Date: Wed, 11 Apr 2007 01:25:25 +0100

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.

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.

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.

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.

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.

s11: Should we still be, even indirectly, suggesting that MD5 would be a 
suitable hash functtion?

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.

Global: Prefer octet rather than byte.

s1: It would be good to explicitly state the section (4.2 I assume) of 
RFC 3048 ([10]) which this draft covers.

s1: Worth expanding RMT for future generations (or remove the note about 
the wg that produced it).

s1, para 6: Helpful to add a forward ref to s4 or s6.1 where 
Fully/Under-Specified are defined.

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.

s4, para 4: s/ancilliary/anciliary/ (last instance)

s5, para 1: Might be good to refer explicitly to s3.2 of RFC 2357.

s6.1, para 5: s/FEc/FEC/

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.

s6.2.4, last para: s/EXT-FTI/EXT_FTI/.  Also need to expand LCT acronym.

s6.3, last para:  The term 'systematic FEC codes' appears to be a term 
of art that is not defined.  Explanation would be appreciated.

s11: s/to many receivers/at many receivers/

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

---

From: Mark Watson <[email-masked]>
Date: Mon, 16 Apr 2007 10:02:33 -0700

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" <[email-masked]> wrote:

> 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:

Good point. I will add some words to clarify in the introduction.

> 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 ?
 
> is an option the CDP has to provide means to transmit which choice has

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.

> or add words to the earlier paragraphs about the Common Objects.

The previous statement is the last sentence of the previous paragraph.

> 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

No opinion from me. I would be happy to replace this with SHA1 if requested.

> 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.

> RFC 3048 ([10]) which this draft covers.

OK.
 
> 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.
 
> Fully/Under-Specified are defined.

Ok.
 
> needed to provide the extra FEC information and the encoding used to

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.
 
> 'Any' rather than 'The'.  At present it is very easy to read paras 2 and

OK.

> s6.2.4, last para: s/EXT-FTI/EXT_FTI/.  Also need to expand LCT acronym.

OK.
 
> of art that is not defined.  Explanation would be appreciated.

OK.
 
> s11: s/to many receivers/at many receivers/

OK.

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 16 Apr 2007 18:40:06 +0100

I am fine with all these proposals/discussions.

Regards,
Elwyn