Multicast Negative-Acknowledgment (NACK) Building Blocks
RFC 5401
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert (was Discuss) No Objection
> This > document is a product of the IETF RMT WG and follows the guidelines > provided in [RFC3269]. Suggest to remove the reference to the RMT WG for the published RFC.
(Magnus Westerlund; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) (was Discuss) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was No Record, Discuss) No Objection
In the acknowledgements section, I suspect that the comma in "George, Gross" is a typo.
(Ron Bonica; former steering group member) (was Discuss) No Objection
(Ross Callon; former steering group member) No Objection
I just have a few minor comments that the authors can address or not at their discretion. Having once long ago looked at a few reliable multicast protocols I had noticed that reliable multicast is in fact a family of loosely related problems rather than one problem, and I am quite pleased that this document recognizes and clarifies this, and is focused on an approach that supports multiple related solutions. Questions: Does this document obsolete RFC3941? If so it should say so. Minor: I think that you should say a bit more about what to do when one receiver, or a few receivers, are suffering from either much slower or much less reliable service than other receivers. One option would be to slow down the entire group. Another option would be to remove the receiver from the group, and either serve it in a different group, or not serve it at all. Is there some threshold below which a receiver should be cut out of the group (since it would be harming service to everyone else)? Is this so obvious that it doesn't need to be discussed? Minor Editorial: In section 1, the following sentence is at best awkward, and is probably not grammatically quite right: Here the protocol mechanism for reliability is described as a "repair process" since the use of packet-based Forward Error Correction (FEC) erasure coding for recovery of missing packets as compared to classical re-transmission schemes. I have two questions regarding this sentence. One issue is that my understanding of FEC is that it can be used to substantially reduce the probability of error. However, it can't completely eliminate any chance of error. Also, the document otherwise talks about NAKs, suggesting that there will be cases where receivers have figured out that they are missing something (and something like "classic retransmission" may be needed). Thus on the one hand I can't figure out what this sentence is intending to say (and my second problem is that whatever it is trying to say, I don't think that it does). In reading section 2 (top of page 5) there is the mention of bulk transfer. At this point I was wondering whether this referred to a known fixed length bulk transfer (in the case that one receiver among a great many miss a few packets, this would allow reliable multicast by transmitting the whole thing once and then going back and retransmitting parts that someone missed) versus indefinite length bulk transfer (which needs a different solution). About 20 pages later I found the correct answer in section 3.5 on page 25 (which is that both need to be supported). I am wondering if there should be a very brief forward reference on page 5 (although a reader might assume that they need to read on if they have such questions early in the document).
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
Security Considerations, second paragraph: s/appropriate extend IPsec mechanisms/extend appropriate IPsec mechanisms/