>>>>> * When responding to a multicast request over a multi-access medium, >>>>> why is the randomization of the transmit time only a SHOULD? >>>>> I would think that needs to be a MUST.
> Therefore I consider it a SHOULD; certainly, _for some link layer_, you > may want it a MUST, but in general, I think MUST increases > implementation complexity more than it brings to the table. Markus, I would tend to agree with Brian here. The cost to implementations is negligible: since you are already buffering the outgoing datagram in order to aggregate TLVs, adding a random delay to the flushing doesn't cost you much at all. > In practise, barring naive hubs of 90s, I am not aware of such a link > layer in use that would behave _that_ badly. Ethernet switches avoid > mostly collisions these days, and wifi unicast is ‘reliable’. Wifi unicast is based on CSMA, two stations sending simultaneously will cause a collision and a reemission. > That said, if this gets deployed on such a network, I will gladly > publish an errata saying MUST :-) It's a fine protocol, Markus, that solves a real problem. If it works well in home networks and is available on cheap hardware, people will deploy it in larger networks whether we like it or not. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
