Subject: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-09.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Sep 2002 13:49:55 -0700

Robert Elz <[email-masked]> writes:

> I believe that the IESG is considering publishing
> 	draft-ietf-ipngwg-addr-arch-v3-09.txt
> as a Draft Standard.

> Before that happens, you should be aware that RFC2026 requires

> 4.1.2  Draft Standard

>    A specification from which at least two independent and interoperable
>    implementations from different code bases have been developed, and
>    for which sufficient successful operational experience has been
>    obtained, may be elevated to the "Draft Standard" level.
> [...]
>    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 IPv6 address architecture contains 2 features for which the
> interoperability report (as currently published on the IETF web page)
> does not comment at all, let alone show two independent and interoperable
> implementations from different code bases.

> Those two are the requirement that all interfaces use /64 subnets,

As you have pointed out on the mailing list yourself, all link-layer
types will need to support 64-bit interface identifiers for stateless
address autoconfiguration. And we have Ethernet, FDDI, ATM, etc. that
do that just that. So there is ample evidence (and implementations)
that interfaces support the use of /64 subnets.

What you seem to be saying above, however, is subtly different.
Namely, that all interfaces must "use" /64 subnets. Presumably you
mean "implement", as implementation reports don't necessarily indicate
actual "use".

But if this is your argument, I disagree with it. It is not possible
(nor does it make sense) that when a spec says X, the implementation
report somehow needs to show that no implementations do *not* do
X. This line of reasoning would effectively prevent *any*
specification from ever advancing to Draft, as one can never be sure
that some implementation (or future implementation) does not do X. If
it were the case that there was evidence that there were
implementations that did not do X, that would be useful input, but
would certainly not by itself prevent a spec from going to Draft.

> and the requirement that when the 'u' bit is set, the address has been
> derived from a globally unique MAC address.

I'm not exactly sure what you think needs to be shown here. The
addrarch document describes how one creates EUI-64 identifiers and how
one sets the corresponding 'u' bit. We have a number of other
documents (e.g., IP over Ether) that actually require that
implementations do this. There seems to be wide agreement that
implementations do in fact do this (in fact, this is indicated in the
implementation report up at
http://www.ietf.org/IESG/Implementations/address-architecture.txt).

Again, your words seem to suggest an even stronger requirement,
namely, that there be some way to show that implementations that set
the 'u' bit have actually derived their IIDs from an IEEE
identifier. I know of no way of doing this. However, I also don't see
that as a problem. I suspect that it would be easy to find in many
specifications some implementation recommendations where it is not
immediately possible to demonstrate that an implementation that sets
bits in a certain way has actually been "authorized" to do so. (How
does one verify that an implementation is authorized to set the 'u'
bit?)

What 2026 requires, is that the words describing how to implement
something are clear enough to get interoperable implementations
from. 2026 does not require that an implementation that sets the bits
in a field in a certain way has actually satisfied all the
assumptions/requirements for setting the bits in that way. This would
be an unrealistic requirement.

> Further, all experience suggests that implementors are widely ignoring
> those two requirements - which makes them exactly the kinds of fluff
> that this part of 2026 is demanding be removed.

What is your evidence that *implementors* are widely ignoring these
requirements? I am aware of none.

> Or, or course, the doc can be republished as a PS, while awaiting
> implementation of the features.

> In any case, the document, as it is, with the interoperability report
> that exists, clearly do not satisfy the requirements of 2026 that would
> allow the document to be published as a draft standard.

I disagree, as explained above.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 20 Sep 2002 18:19:39 +0700

Date:        Thu, 19 Sep 2002 13:49:55 -0700
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

Note: I have updated the version of the draft in the subject line - the
-10 draft appeared just after I sent my previous message (which WG members
wouldn't have seen as it was sent only to the IESG)

  | But if this is your argument, I disagree with it. It is not possible
  | (nor does it make sense) that when a spec says X, the implementation
  | report somehow needs to show that no implementations do *not* do
  | X.

Of course.   I am going to avoid doing a line by line reply to your message,
as you seem to be (for whatever reason) ignoring or misconstruing the
thrust of my request.

I'm going to assume that was because I wasn't clear enough.   I thought
the issue was fairly obvious, and would be understood by anyone.  But
it appears not, so this time I will be more blunt.  That might make this
message seem patronising - that isn't the intent, I'm just not aware of
any other way to make the issues clear enough...

For now I will ignore the 'u' bit, we can come back to that later, if
necessary, and confine myself just to 64 bit IIDs for the rest of this
message (which will be long enough without more added on).

What draft-ietf-ipngwg-addr-arch-v3-10.txt requires, at the bottom of
page 8 (section 2.5.1) is ...

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Read that carefully (and I'll ignore the 000 case here, that's irrelevant).

	Interface IDs are required to be 64 bits long

no exceptions (ignoring 000), no alternatives, interface identifiers
are required to be 64 bits long.

Then again, at the bottom of page 10, and onto the top of page 11, in
section 2.5.4, the same thing is restated ...

   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.  Global unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

That comes after this ascii art showing a global unicast address...

   The general format for IPv6 global unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

(which itself is just fine).

Again, read what that says ...

	All global unicast addresses [...] have a 64-bit interface ID
	field (i.e., n + m = 64)

Again, no ambiguity, no alternatives.

What my message to the IESG requested, was that either that text be
deleted (there may be one or two other references as well - in a
message to the WG list a while ago I listed all the changes that should
be made, they're all simple deletes), or that the implementation reports
show at least 2 implementations of this requirement/feature.

Note: to implement this feature, the implementation would have to
prohibit any global unicast address (000 excepted...) from having
an interface id that was anything other than 64 bits long.  Or, from
having m+n in the above diagram being any different from 64 (which, of
course, is the same thing).

There's no other way to implement this feature.

Note, this has nothing at all to do with whether an implementation
allows the IID to be 64 bits long - there is quite likely other wording
in the doc, that I have no problem with at all, that requires implementations
to allow IIDs to be 64 bits, so that autoconfig can work.  That's all
just fine.

And so, I did mean "use" not "implement", as if I can use an address
that does not have a 64 bit IID (that is, if I can make m+n > 64) then
clearly the implementation is not implementing the above feature.
That is, the implementation is not requiring that m+n==64, or in other
words is not requiring that the IID be 64 bits long exactly.

All that is needed to show that the implementation does not implement
this particular feature, is to (attempt to) configure an address that
has something other than a 64 bit IID.   If it works, then the implementation
doesn't implement the two paragraphs I quoted, and cannot count as one
of the two that do, which is required for this feature to remain in the
doc when it advances to DS.

As for ...

  | What is your evidence that *implementors* are widely ignoring these
  | requirements? I am aware of none.

jade# ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet 10baseT
        status: active
[link locals and irrelevant cruft deleted]
        inet6 3ffe:b80:53:1234:2222::1 prefixlen 112

There's one.  There, right before your eyes, is a global IPv6
address. that starts with something other than 000, and in which m+n=112
(which is bigger than 64).   That is, the IID in this global address
is 16 bits, not 64.

What's more, it works ...

delta$ ping6 -n 3ffe:b80:53:1234:2222::1 
PING6(56=40+8+8 bytes) 3ffe:b80:53:181:206:5bff:feda:45ad --> 3ffe:b80:53:1234:2222::1
16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=0 hlim=64 time=0.744 ms
16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=1 hlim=64 time=0.272 ms

Go ahead, try it if you like (but no guaranntees that it will remain
configured for very long, as you can guess, this one I just installed
as I was typing this message, to demonstrate that it can be done).

Hence, this particular implementation has ignored the requirement that
all IIDs are "required to be 64 bits long" - hasn't it?

What's more, every implementation I have seen also ignores this requirement.
Can you point to even one, that doesn't?

But, it is not up to me to prove that the feature is widely ignored.  What
2026 requires is (from rfc2026 section 4.1.2):

   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.

That is, the IESG cannot advance a specification to DS, unless the WG
chair (using the WG to assist, one would normally assume) has documented
at least 2 implementations of every feature (interoperable ones, but that
part isn't likely to be an issue here).

2026 is very clear about that.   And while one of the reasons for this
is to make sure that the language in the doc is clear enough to implement
in an interoperable fashion, another reason is to make sure that "fluff"
doesn't remain in the specification, that no-one is actually bothering to
implement.

The two paragraphs I quoted above are quite clearly that kind of fluff.

And to be 100% clear, the feature / requirement that I am objecting to,
is the one that *requires* every IID to be 64 bits, and nothing else.

Not to the (related but different) one that requires implementations to
support 64 bit IIDs, which is just fine, and which the interop testing
does document (and I have no reason at all to doubt is widely implemented).

kre

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Sep 2002 14:09:40 -0400

First, thanks for clarifying the issue you have. I apparently didin't
fully understand your concern the first time around.

> show at least 2 implementations of this requirement/feature.

I still do not believe either of your requests needs to be made.

Let me quote another part of the addressing architecture:

   IPv6 nodes may have considerable or little knowledge of the internal
   structure of the IPv6 address, depending on the role the node plays
   (for instance, host versus router).  At a minimum, a node may
   consider that unicast addresses (including its own) have no internal
   structure:

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

That is, a host is not required to know what part of an address is an
interface identifier and what is not. Thus, there is no requirement in
addr-arch that implementations somehow test for the two components and
verify that they satisfy particular properties. Indeed, for a node
that only understands addresses, you seem to be suggesting that such
an implementation would also have to reject a request to set a
specific address on an interface, and instead require that addresses
be entered as a (prefix, IID) pair, so that properties of (say) the
IID could be verified/enforced.

> course, is the same thing).

You seem to be saying that implementations must follow a extermely
strict interpretation of a spec. Allow only that that is explcitely
permitted by the text, and reject everything else, including a
superset of the required feature. I.e., it's not enough to enter/check
an the address, one must know what its internal components are
(prefix, IID) and test both of those.

There is no such requirement in the spec that I can see. And no such
requirement in 2026 either. 

> clearly the implementation is not implementing the above feature.

This goes too far, IMO. You are saying that implementations can't
implement a superset of some feature in order for that feature to have
been supported properly. The purpose of 2026 interoperability testing
is to ensure that the words in the spec are sufficient to implement
from and not result in any interoperabilty features. If someone
implements a superset of feature X, and that implementation
interoperates just fine with other implementations of X, that is not
inherently a problem. And in the case of IIDs, it's clear from the
implementation report that a number of implementations have
implemented them.

> has something other than a 64 bit IID.

Because there is no way to take an arbitrary address, and determine
whether the IID is 64 bits or not, this is not something
implementations can realistically check.

> If it works, then the implementation

Disagree, per above.

> (which is bigger than 64).   That is, the IID in this global address

Correction: the address has been configured with a netmask of 112
bits. How the netmask is configured is independent of what IID is
used. One can assign a 112 bit mask on an IID that is in EUI-64 format
(which is what was done above). That, per se, is not an indication of
a problem.

> What's more, it works ...

Right. The WG wants it to work this way...

> part isn't likely to be an issue here).

The requirement is that folks implement EUI-64s IIDs. It is not that
implementations check for and reject any address or IID that isn't
guaranteed to follow the format.

> is the one that *requires* every IID to be 64 bits, and nothing else.

Understood. But I disagree with the requirements you believe that
implementations need to satisfy in order for addr-arch to go to Draft
Standard. That bar is too high, as it basically requires that
implementations check for lots and lots of things that are not
explicitely allowed prevent them from being used.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Sep 2002 16:59:23 +0700

Date:        Mon, 23 Sep 2002 14:09:40 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let me quote another part of the addressing architecture:

  | That is, a host is not required to know what part of an address is an
  | interface identifier and what is not.

That's fine.   Now we have two things in the doc, and hosts can do one
or the other.   The "must be two interoperable implementations of every
feature" requirement in 2026 says that if everyone happens to choose one
of those, then the other has to be deleted from the spec before it goes
to DS.   The other choice can reappear in a new PS spec, but it cannot
remain in the DS spec.

Thomas, there's nothing at all unclear about this in 2026...

  | Thus, there is no requirement in
  | addr-arch that implementations somehow test for the two components and
  | verify that they satisfy particular properties.

No, and I am not complaining about any implementation that doesn't do
that.   In fact, I would complain (to the authors of such a thing) if they
did attempt to do that - I certainly wouldn't use such an implementation.

But that's not what is important here.   What matters is whether or not
there are two implementations (at least) of every feature of the spec.
Not whether any (or every) particular implementation conforms to the spec.

  | Indeed, for a node
  | that only understands addresses, you seem to be suggesting that such
  | an implementation would also have to reject a request to set a
  | specific address on an interface, and instead require that addresses
  | be entered as a (prefix, IID) pair, so that properties of (say) the
  | IID could be verified/enforced.

No, I would hate such a thing.   What I am saying, is that according to
the address architecture doc, that is what is required, if hosts are to
implement that feature (whether or not they are required to implement
it is irrelevant here - 2026 applies to optional features just as much
as to mandatory ones).

If no-one is bothering to implement it, then it should be removed, correct?

If anyone is bothering to implement it, then that should be documented,
right?

  | You seem to be saying that implementations must follow a extermely
  | strict interpretation of a spec. Allow only that that is explcitely
  | permitted by the text, and reject everything else, including a
  | superset of the required feature.

No, nothing like that at all.

But consider a spec which says

	Saucepans MUST NOT boil potatoes.

If some saucepan comes along and says, "I boil potatoes, I'm not violating
the spec, I'm just implementing a superset, because no-one is actually
required to boil potatoes using this implement", you'd laugh at them.

A superset cannot be such as to deliberately violate a condition of the
spec, it has to implement everything required, and then can implement more.

The requirement here is "m+n==64" - always (with only non-unicast, non-global,
and the 000 case as exceptions).   That is, a host must implement that,
if it is to implement that particular feature.  If you like, what the spec
is saying, is

	Addresses MUST NOT have a IID that is any length other than 64.

And you seem to be saying, OK, as long as it is possible to have an IID
that is 64 bits long, that requirement is satisfied.   Really?

Please don't mane me give a lesson in boolean algebra and De Morgan's
laws relating to the inverses of "All X" and such.

If you don't believe that is what the spec is saying, then at the very
least it is unclear, as that's certainly how I read it.   It is also
an interpretation I have seen quoted by (several) other people in various
other contexts.   So, if it is (commonly) being read as saying something
different than what it is actually supposed to mean, surely it should be
corrected so it is clear.   By all means propose wording to make this
happen.  If your wording for this is in accord with what you seem to be
saying here, and the WG accepts it, then I doubt I will have any problems.

That is, if your replacement wording makes it clear that it is OK for
implementations to allow IIDs that are shorter (or in fact, longer) than
64 bits if they desire, and that m+n is not actually required to be 64
after all.

  | I.e., it's not enough to enter/check
  | an the address, one must know what its internal components are
  | (prefix, IID) and test both of those.

If the host is implementing that feature, then yes.   But note that we're
not discussing the adequacy of host implementations here, we're discussing
the correct procedures for advancing the spec.   That means that it is
irrelevant whether or not the feature in question is supposedly mandatory to
implement or not, all that matters is that it is in the doc, and there aren't
any documented implementations of it.   Hence, it has to go (or documentation
of implementations must be provided).

  | This goes too far, IMO. You are saying that implementations can't
  | implement a superset of some feature in order for that feature to have
  | been supported properly.

Once again, this is not a superset, it is a direct violation of the
wording.   And once again, I am not complaining about any implementation.
The complaint is about the spec, and its ability to go unchanged to DS.

  | The purpose of 2026 interoperability testing
  | is to ensure that the words in the spec are sufficient to implement
  | from and not result in any interoperabilty features.

Once again, that is only a part of it.   It is also to get rid of
features that no-one is bothering to implement.   That's why it says
that every feature must be documented.   It isn't good enough to simply
say "these two implementations interoperate with each other".

  | If someone implements a superset of feature X,

Supersets are irrelevant here.   No-one has implemented a superset of
the feature in question.   Remember, that what I'm asking to be
deleted, or for which interop reports need to be generated, is the
"all IIDs are required to be 64 bits long" language.   The text in
the spec (that is of concern) is not "all implementations are required
to support 64 bit IIDs" - if it were, then yes, supporting 64 would
be enough, and if 70, 80, ... bit IIDs supported, that would be a
superset.   But that's not what it says, it says, very clearly, and
in two different ways in two different sections, "*ALL* IIDs are
*required* to be 64 bits" (referring to global unicast addresses
that don't start with the first three bits being 000).

I am still waiting for you (or someone) to point to a single implementation
of this feature.   Once we get one, we could start looking for two...

  | And in the case of IIDs, it's clear from the
  | implementation report that a number of implementations have
  | implemented them.

Of course.   No-one is suggesting that IIDs be deleted from the spec.
Nor EUI-64 for that matter.

All I am asking is for the language that mandates that IIDs be 64 bits
long, and that no other length is permitted, be removed (or the
implementations of it be documented).  Are you somehow managing to miss
that particular text in the draft?

  | Because there is no way to take an arbitrary address, and determine
  | whether the IID is 64 bits or not, this is not something
  | implementations can realistically check.

If this were true, and there was no way for an implementation to tell
whether a prefix is 64 bits long or not, then what would be the point of
including language in the architecture doc to mandate it.   That would
make the requirement mere fluff.

But of course, that is utter nonsense.   For any local address, the
implementation must know which part identifies the net (link) and which
part identifies nodes on the net (link).   Otherwise it has no way to
tell which other nodes are "on link" and which are not.   And even if
this is necessary only for a subset of links, it clearly is possible.

Of course, in practice, nodes are always told what the prefix length
is, for any address configured (not that they would need to be if the
addr arch spec was followed literally, as it would always be a constant 64).

  | >         inet6 3ffe:b80:53:1234:2222::1 prefixlen 112

  | Correction: the address has been configured with a netmask of 112
  | bits.

Which parts of "prefixlen" do you not understand?   IPv6 doesn't
have netmasks...

  | How the netmask is configured is independent of what IID is
  | used.

Now this is an interesting argument, and truly clutching at straws
I believe.

Consider the wording from section 2.1 (Addressing Model) of the
draft ...

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

Also see section 2.5.1, where Interface Identifiers are defined...

   Interface identifiers in IPv6 unicast addresses are used to identify
   interfaces on a link.

So, we have the subnet prefix, which identifies the link, and the IID
that identifies the nodes on the link, and the prefixlen which tells
the implementation where the boundary between the two is.   Then we
have language in the doc which says that the IID must be 64 bits, and
other language that says that the combined global routing prefix, and
subnet ID (which together make the subnet prefix) must be 64 bits long.
How can the prefix length (or subnet mask if you insist on calling it that)
be anything other than 64, and actually be complying with the requirement
in the spec that m+n==64, or the one about the IID being 64 bits wide?

But if that's your interpretation of what the spec is actually saying
is required, then we certainly need different text to explain it, as
no-one else I know of has ever claimed that as a legitimate interpretation
before.

Rather, the addr arch doc is commonly quoted by people who claim (and
correctly as it is written, I believe - which is why it needs to be
changed) that it specifies that the prefixlen of any link is required
to be 64, and nothing else is permitted.

So, if that's not what it is actually saying, then the text clearly needs
corrections so it is understood the way you're claiming that it should be
understood.

  | One can assign a 112 bit mask on an IID that is in EUI-64 format
  | (which is what was done above).

Um, no, that's not what was done above.  EUI-64 format also makes
statements about the 'u' bit, and if you look, you'll see that the
address that was configured has the 'u' bit set, but most certainly
wasn't formed from any kind of global identifier.   And note this
was an ethernet (that's what fxp0 is on NetBSD) which means that its
tokens would be 48 bit MAC addresses, so a correctly formed (global) EUI-64
would have had the FFFE value in the middle of it.   That's missing too.

  | That, per se, is not an indication of a problem.

It looks like one of three cases is true here.

The spec really means something quite different from the way everyone
interprets it, in which case it should be corrected.

The spec doesn't really mean anything at all, in which case it should
be deleted.

The spec means exactly what it says, in which case either 2 implementations
of it need to be documented, or the spec has to be deleted (from this doc
for it to go to DS status).

You can pick one of those, but I can't see any other choices.   In each of
the above "the spec" means the particular lines from the draft in question
that I quoted in my last message.

  | > What's more, it works ...
  | Right. The WG wants it to work this way...

In that case, why is the addr arch doc not actually saying what the
WG wants?

On the other hand, if what you are saying here is that the WG wants
to have this in the spec, and to have the spec advanced to DS, even
though there aren't 2 implementations of this feature, then I'm afraid
it is the IESG's job to say "no".   2026 leaves it no choice.   It isn't
as if the IESG is usually shy about rejecting drafts that WG's have
agreed to, or ignoring specific "wants" from working groups.  And that's
when there isn't even a specific requirement that requires the IESG
reject the request, which there is here.

  | The requirement is that folks implement EUI-64s IIDs.

That is *a* requirement.   That's not the one I am concerned about.
Hasn't that much become clear yet?

There is also this other requirement that every (global unicast, 000
case excepted) address have m+n == 64.   In that m is the number of
bits in the global routing prefix, and n is the number of bits in the
subnet ID.   Is it possible that you can't see that in the draft?
The language isn't obtuse - it isn't required that anyone read this
requirement out of a combination of other statements, or anything
complex like that, after all, what it says is ...

   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. 

Notice that "All [...] addresses".   It leaves no room for there to be
a single address (other than the explicit exceptions) which isn't formatted
like this.

Look at the diagram above it (this is section 2.5.4).  That shows what
m and n mean.   Look at the definition of Interface ID, to see what that
means.   And you can just believe me that in the implementation I showed
(the one you claimed earlier didn't exist, though I think it is what
everyone does), when an address has a prefixlen of 112, it means that
m+n == 112.  The implementation doesn't actually care how much of that
is m, and how much is n, that is someone else's business - nor does the
addr arch doc care, all it currently requires is that m+n==64:  m=63 n=1,
or m=64 n=0, or m=3 n=61 would all satisfy it, but m+n==112 does not.

That one is the one in question.

And once more, I am not complaining about this implementation, I like it
a lot, it does exactly what I think it should do.   But it isn't one of
the ones which could possibly be used to claim that the feature in
question is implemented (and nor are any others I have seen - but of
course, that isn't all that exist, so it is possible that there are the
needed 2 implementations somewhere, just not documented).

  | It is not that
  | implementations check for and reject any address or IID that isn't
  | guaranteed to follow the format.

If nothing is supposed to check/reject addresses of IIDs that aren't
64 bits long, why is the text in the doc?   If it is just that
implementations are allowed to reject that, then that's an optional
feature right?   And 2026 requires that there be at least two
implementations of each optional feature, or the feature must be
removed.

  | > And to be 100% clear, the feature / requirement that I am objecting to,
  | > is the one that *requires* every IID to be 64 bits, and nothing else.
  | 
  | Understood.

It doesn't seem to be, because you keep referring to implementations
implementing IIDs, which has nothing to do with this at all.   The "nothing
else" above was meant to refer to "nothing other than 64 bits", not that
I am objecting to no other parts of the spec (because there's also the 'u'
bit of course, that is pending the outcome of this discussion).

  | But I disagree with the requirements you believe that
  | implementations need to satisfy in order for addr-arch to go to Draft
  | Standard.

2026 really is quite clear.

  | That bar is too high, as it basically requires that
  | implementations check for lots and lots of things that are not
  | explicitely allowed prevent them from being used.

No, that would not be the case at all, we're not talking about undocumented
cases here, or things just left open and undefined, or unspecified.

Let's look at another couple of cases for a minute, which aren't in this
area of dispute, so might make things just a bit clearer.

   2.5.3 The Loopback Address

[...]
   The loopback address must not be used as the source address in IPv6
   packets that are sent outside of a single node.

Now, if an implementation was sending packets with 0::1 as the source
address, it clearly wouldn't be complying with the spec, right?   That
wouldn't just be a "superset" implementation, would it?   So, for link
locals to pass into the DS draft, we need at least two implementations
that don't send ::1 as a source address.   I doubt that is any kind of
problem.  Note, it is not important if there are buggy implementations as
well, which do use ::1 as a source addr, unless they're caused by a lack of
clarity in the spec (which would not be likely here), but there must be
at least two implementations which do implement the spec.   Agreed?

On the other hand:

    2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
[...]
   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|    IPv4 address     |
   +--------------------------------------+----+---------------------+
   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
   must be a globally-unique IPv4 unicast address.
[...]
   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

In that section, nothing at all is said about (IPv6) addresses which
start with or 0::FFFF:0:0/96 but which don't contain an IPv4 address
in the low 32 bits.   Nor is anything said about addresses that start
with 0::/80 but which don't have 0000 or FFFF in the next 16 bits.
Implementations which supported any of that would be supersets of the
spec.   Clearly there is no requirement in the spec for such things to
be rejected.

But when an IPv4 address is used in a 0::/96 address, then it is
required to be a globally unique one.   If no-one implements that,
then that requirement would have to be deleted (but I believe that
actually is tested for in at least some implementations).

So, here, as long as there are two implementations of this, with or
without optional extensions, this part is also just fine to advance to DS.

This needs to be done for every feature in every spec that the IESG
considers advancing to DS.    Note I'm not about to require that the
IESG do all this all by itself, we have the rest of the IETF community
along to help.   First, the WG is supposed to document it all in the
implementation report.   And then, we have the rest of the community
(like me in this case) who should be examining all of this, and making
known any problems that we can see.

But once the IESG are made aware of a feature in a spec, for which there
aren't two documented implementations, it has no choice, according to
2026, other than to request the missing documentation, or reject the
doc's advancement to DS, or to require that the unimplemented features
be removed from the doc, after which what is left can advance to DS.

kre