I have made my points for pitfalls related to the rules of this document. However, since the new rules in this document have a language of SHOULD NOT drop for receive and MAY for transmit, I don't see any MUST language in the rules. The only MUST in the rules section is a MUST to apply such additional considerations where the actual considerations have no MUST. Thus if my hardware chooses to ignore the receive and transmit rules of this document and comply to RFC 2464, my hardware does not violate this document. Therefore, I support this document.
However, before we forward this document to the IESG, could we please make some minor changes to text. One change is suggested below. OLD TEXT [An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message containing a multicast destination address in the IPv6 header, but with a unicast destination address in the link-layer header, withstanding all other validity considerations as specified in the relevant IPv6 standards specifications. ] NEW TEXT [An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message containing a multicast destination address in the IPv6 header, but with a unicast destination address in the link-layer header.] The reason is the use of word "relevant" in old text which appears loose to me because folks may question, well, which specific IPv6 standards specifications and the discussion protracts. I have other minor text changes to propose that I couldn't get to today. I hope to get to the other suggestions early next week. Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
