As I do not attend meetings, perhaps someone at the meeting could ask the author these questions:
1) > 10 - discard the packet and, regardless of whether or not the > packet's Destination Address was a multicast address, send an ICMP > Parameter Problem, Code 2, message to the packet's Source Address, > pointing to the unrecognized Option Type. > The PDM destination options extension header SHOULD be turned on by > each stack on a host node. Perhaps the Security Considerations section could explain why this "SHOULD" be enabled feature does not give a way to implement a variation of the Smurf attack? 2) > As with all other destination options extension headers, the PDM is > for destination nodes only. As specified above, intermediate devices > MUST neither set nor modify this field. Does this "MUST" prevent firewalls stripping the PDM option at the site network edge? It seems a rather strong requirement that firewalls cannot do this. Perhaps the intent is that the entire packet be dropped by a firewall if PDM is undesired by the site's administrators? Maybe the I-D could explain in more detail what an intermediate system like a firewall is permitted to do with a PDM-containing packet entering a zone where PDM is not permitted (drop with Admin Prohibit ICMP, etc). 3) > Application Reserved > A 64-bit field reserved for performance and diagnostic metrics to be > used by end nodes. The meaning is agreed upon by the source and > destination nodes. Usual whinge about vendor-defined fields in specifications which are intended to achieve interoperability. How can we even tell if 64b is adequate? If justification for the adequacy of 64b remains lacking then I counter-propose that 0b is adequate. Thank you glen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
