Subject: (retry) implementation report for rfc2462bis

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Apr 2005 20:06:53 +0900

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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------