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: 19 April 2007 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/