Thomas,
At 12:35 PM 05/20/2005, Thomas Narten wrote:
Bob,
The changes look good to me.
Thanks!
One thing I noticed while reading this text (and this issue actually was in previous versions):
> +-+-+-+-+ > flgs is a set of 4 flags: |0|R|P|T| > +-+-+-+-+
> The high-order flag is reserved, and must be initialized to 0.
Because the high-order flag is reserved, its contents should be ignored by all implementations. So "must be initialized to 0" is perhaps better just dropped, to prevent an implementer from thinking they need to (somehow) verify/check this. Maybe change to:
The high-order flag is reserved, and its value should be ignored on receipt (other than being considered part of the address when performing address comparisons).
(Maybe the last part is too long/complicated/obvious, in which case just dropping it might be better.)
I agree it gets complicated trying to spell this out because implementations don't set the flags in a multicast address like they might dynamically set a flag in a protocol header. However, I think we do want to do something to insure that it is zero so as to avoid ending up with two different multicast address for the same thing. How about if it just says:
The high-order flag is reserved and must be zero.
This avoids the idea that an implementation might have to initialize it dynamically.
I'm also fine with not adding any additional text to the IANA considerations regarding the unicast/multicast instructions.
Thanks!
Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
