Multicast Negative-Acknowledgment (NACK) Building Blocks
RFC 5401

Note: This ballot was opened for revision 07 and is now closed.

Magnus Westerlund Yes

(Jari Arkko) No Objection

(Ron Bonica) (was Discuss) No Objection

(Ross Callon) No Objection

Comment (2008-07-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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).

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2008-06-30)
No email
send info
>    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.

(Pasi Eronen) (was No Record, Discuss) No Objection

Comment (2008-07-03)
No email
send info
In the acknowledgements section, I suspect that the comma in "George,
Gross" is a typo.

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2008-07-03)
No email
send info
Security Considerations, second paragraph:

s/appropriate extend IPsec mechanisms/extend appropriate IPsec mechanisms/

(Dan Romascanu) No Objection

(David Ward) (was Discuss) No Objection