Date: Mon, 12 Aug 2002 09:57:14 -0400
From: Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| We can only perform interoperability testing for external behaviours of
| boxes that are visible on the wire.
True, but interoperability testing isn't required.
Let me quote 2026, section 4.1.2 (part thereof) just in case anyone
here isn't clear on the requirements ...
[...] "interoperable" means to be functionally
equivalent or interchangeable components of the system or process in
which they are used.
The requirement for at least two independent and interoperable
implementations applies to all of the options and features of the
specification. In cases in which one or more options or features
have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Draft Standard
level only if those options or features are removed.
The Working Group chair is responsible for documenting the specific
implementations which qualify the specification for Draft or Internet
Standard status along with documentation about testing of the
interoperation of these implementations. The documentation must
include information about the support of each of the individual
options and features.
Note: nothing requires that there be any interoperability testing, and
while it is great that there has been some (lots) of v6 implementations,
other protocols advance with none.
What is required is that every feature be implemented in a way that is
interoperable (twice, independently).
Every feature, or it must be removed.
There's nothing unclear about this, nor is it without good reason. This
is how we get rid of the odd attachments that people just thought would be
a good idea when the doc was proposed, but then no-one (except possibly the
one who suggested it) ever bothered to implement. It is how all the
chaff is removed.
| 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.
Yes, some things are harder than others. And I agree, what's there now
is pretty good - it documents all that is important (except the new stuff,
which it couldn't possibly have done) which needs to be in the doc.
That's great. What follows from that is that the parts that aren't
documented as having been implemented, get removed from the doc, just
as the process I quoted above requires.
What happens to those bits afterwards is for the WG to decide.
I'm not sure why we're even discussing this next part, but ...
| The subnet ID changes don't affect the external behaviour of an IPv6
| implementation.
Yes it does. If one implementation refused to accept a prefix with
fec0::/10 which is not also fec0::/48 (which I believe was once actually
implemented somewhere, I recall someone mentioning it) then it will not
interoperate with anything which attempts to use the new larger SLA.
| We were always required to perform all routing and
| comparisons in a CIDR-like fashion, and that hasn't changed.
Sure, but this has nothing to do with that.
| 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.
It is an implementation report issue as regards with getting this accepted
as a DS (even if it gets included, it could be decided that this is a big
enough change to require the doc to recycle at PS anyway. I don't think it
quite goes that far, but that isn't out of the question).
But what is the issue here - all we need is for two different implementations
to say "We allow 54 bit SLAs for SL addresses", that goes in the implementation
reports for those two implementations, and we're done ?
Why would anyone want to even tempt fate just to avoid doing that?
| 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.
No. But the specification of IID uniqueness is. That's why there is
text in this draft being changed after all.
Again, all it takes is for (at least) two implementations to say "we allow
this in our code" (and I'd be surprised if there were any who don't already)
and for an entry to be added to the report. This is easy, why not just
do it to be complete?
| The Addressing Architecture doesn't specify any behaviour related to the
| global uniqueness of addresses with the 'u' bit set.
No, it just says that should be set on addresses formed from IIDs
with global scope. And not otherwise.
The question is where are the two implementations that actually do that?
And before anyone claims "mine does" first answer the question how you
determine that the IID does really have global scope?
| 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.
The changes should be fine - they just need to be actually documented
(that is, we aren't allowed to just say "we know it is all OK", we are,
or more correctly, you (with Bob & Steve) as chair are, required to
actually document all of this).
But for the rest of the doc, how about (sect 2.5.4)...
All global unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in section 2.5.1.
Where are the two implementations that implement/enforce that feature?
This is quite clearly an feature of the specification. If not, why is
it there? Thus, according to 2026, we (you) are required to document
the implementations of it.
If there are none, 2026 requires that it be removed for the doc to go
to DS.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
