Hello, As far as I know there has been no response at the list on this subject: http://www.ietf.org/mail-archive/web/ipv6/current/msg04465.html
so I'm going to give it a second try, based on the relevant discussion at the Minneapolis meeting. According to the (draft) minutes of the meeting (http://www3.ietf.org/proceedings/05mar/ipv6.html) Margaret needs info if former impl reports apply (just checking to make sure). Also need statement from chairs and pointer to the old impl report to this effect. Brian clarifies that reports are not needed if the existing implementations are not affected. Regarding Margaret's comments, the former report is available at: http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt I'm pretty sure that changes in rfc2462bis do not affect the implementations reported at that time (although this is mainly because the report was quite "coarse-grained".) But I don't know if this addresses the comment from Allison: No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed bit, which is stated in the draft as an implementation result. It's a good simplification, it sounds like, but documenting this in the report would be good. (BTW: "dropping" might be misleading. We did not "drop" that bit, but moved details about how to use it to a separate document) If not, how can we move forward with this comment? Regarding whether other changes in rfc2462bis affect existing implementations, I've listed in an appendix (candidates of) those changes: Major changes that can affect existing implementations: o Specified that a node performing Duplicate Address Detection delay joining the solicited-node multicast group, not just delay sending Neighbor Solicitations, explaining the detailed reason. o Added a requirement for a random delay before sending Neighbor Solicitations for Duplicate Address Detection if the address being checked is configured by a multicasted Router Advertisements. o Clarified that on failure of Duplicate Address Detection, IP network operation should be disabled and that the rule should apply when the hardware address is supposed to be unique. If necessary, we can solicit implementation reports on these changes, although the reports would suddenly contain detailed nits compared to the previous report. I'd also like to make a consensus on this. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
