We can only perform interoperability testing for external behaviours of boxes that are visible on the wire. This does make it fairly tricky to write an implementation checklist for something like an addressing architecture, and I think that Bob has done an outstanding job of figuring out which features do/don't have interoperability concerns.
>Since this doc is going to DS (we hope) it requires an implementation >report. There is one of those already - can be found on the IETF web site, >but for anyone who wants a direct URL, it is: > http://www.ietf.org/IESG/Implementations/address-architecture.txt > >That's great. It doesn't mention either of the new features, but I >would assume they can easily be added (since everyone does DAD, rather >than DIID anyway, reporting it as implemented will be easy, and I doubt >it will take much effort for a couple of implementation at least to test >longer SLAs in SL addresses). The subnet ID changes don't affect the external behaviour of an IPv6 implementation. We were always required to perform all routing and comparisons in a CIDR-like fashion, and that hasn't changed. I agree that vendors may want to check that their configuration mechanisms don't have a problem setting subnet IDs of longer than 16-bits, but that isn't an interoperability testing issue. DAD is actually specified in the IPv6 Address Autoconfiguration spec, not in the addressing architecture, so interoperability testing of DAD isn't necessary to advance the addressing architecture. >Those need to be fixed, but should be easy. > >But the implementation report also lacks any mention of testing, using, >or implementing the 'u' bit means "address has a globally unique IID" >feature, nor the "all unicast prefixes other than 0::/3 must be /64" >feature. The Addressing Architecture doesn't specify any behaviour related to the global uniqueness of addresses with the 'u' bit set. It does have an appendix that explains how nodes that use EUI-64 identifiers or ethernet addresses should set the 'u' bit when building IIDs for autoconfiguration. I don't know whether it is necessary to provide interoperability reports on items included in appendices, but we obviously wouldn't have any trouble finding two or more implementations that set this bit correctly. >If there are no implementations of those, then the IESG is just going >to tell the WG to delete them before the doc does to DS, isn't it? I don't think that there is any interoperability-related feature in the current addressing architecture document (including the proposed changes) that isn't implemented in two or more implementations. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
