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 PROTECTED]> 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 [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
