Appeal Against IESG Action by Mr. R. Elz(Appeal Text) — IAB Response, February 2003

Home»Documents»IAB Correspondence, Reports, and Selected Documents»2003»Appeal Against IESG Action by Mr. R. Elz(Appeal Text) -- IAB Response, February 2003

From: Robert Elz <kre@munnari.OZ.AU>
To: iab@iab.org
cc: iesg@ietf.org, ietf@ietf.org, rfc-editor@isi.edu
Subject: Appeal against IESG decision
Date: Sat, 04 Jan 2003 15:07:28 +0700

This is an appeal to the IAB against the IESG decision to reject my appeal
against their earlier decision to approve the publication of draft-ietf-ipngwg-addr-arch-v3-11.txt
as a Draft Standard.

The issues here are very simple, and no lengthy examination of mailing list
archives, taking of evidence, hearing opinions, … should be necessary in
this case. I believe that none of the facts are in any kind of dispute.

Those facts are

RFC2026 says, in section 4.1.2 …
draft-ietf-ipngwg-addr-arch-v3-11.txt contains at least one (and perhaps
two) features for which there are not two interoperable implementations.

The one 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.

There’s no dispute that there are no interoperable implementations of this
– there are no implementations of it at all (or no documented ones anyway).

Note that the spec actually gives no option here, other than the exceptions
(the 000 addresses, and multicast), interface IDs are required to be 64 bits
long. While all implementations I’m aware of allow 64 bit IDs, none have been
presented that require it. The draft *requires* it.

Any reasonable reading of 2026 would require that that feature of the specification
be removed from the draft before the draft is permitted to be published as
a draft standard. Of course, as an alternative, the WG or IESG could have
the draft, as it is, published as a Proposed Standard, and await the necessary
two implementations of the feature before requesting advancement.

The IESG’s opinion of this seems to be that the “two implementations of
every feature” applies only where they consider it important enough to bother
checking. I have no problems with drafts advancing when no-one brings to the
attention of the IESG that there is a problem in this area. But when a problem
is pointed out, the clear words of 2026 really must be enforced.

The rationale for this requirement in 2026 is simple (as the IESG should
know, as the author of 2026 is a member of the IESG). First, it ensures that
the text in the document is clear enough that it can be implemented in an
interoperable way. And second, it helps make sure that the document doesn’t
get cluttered with requirements in practice no-one bothers to implement –
that is, that the document is a proper specification, and anyone reading the
document can implement from it, with the expectation that their implementation
will interoperate with others.

The quoted text from the draft fails both of those tests. We have no implementations
so we don’t know that the text is clear enough to be implemented correctly.
It may seem obvious that the text is clear to any reader – but the IETF has
always ignored “seem obvious” and required actual implementation experience
as a demonstration.

Second, an implementation which did faithfully follow the words of the draft
would fail to interoperate correctly with every other known implementation
of it. It may be claimed that it is the other implementations, or the way
they are configured, that is at fault here, but that’s not relevant – the
aim is to get interoperability, and if we have operators configuring /112,
/226, /227 and similar prefix lengths (that is, interface ID’s that are 16,
2, or 1, and other, numbers of bits long) – and we do – then an implementation
that enforced the 64 bit IID requirement (allowed only /64 prefix on an interface)
would fail to interoperate with other implementations (with all other existing
implementations).

This seems to be a “placeholder” fluff feature, being maintained to perhaps
allow some future design to allow applications to simply “know” what is the
prefix, and what is the interface-ID. The requirement for existing implementations
in 2026 is a specific requirement that such fluff be removed from docs before
they’re allowed to advance to DS status.

The extra requirement should be removed from the document, and then, if
the WG so desires, published as a PS (or Experimental) RFC of its own. If
it then becomes accepted and implemented, it could be merged back with the
main document in a later revision.

The second issue in the appeal to the IESG concerned the ‘u’ bit, which
is one of the bits of the IID as defined.

The IESG referred to this as …

B/ Robert says “The requirement that where the ‘u’ bit (the inverted L
bit from the MAC address) is set, the IID is globally unique.”

and eventually concluded …

The IESG notes that there is no wording in draft-ietf-ipngwg-addr-arch-v3-11.txt
requiring that IIDs be globally unique.

and then quoted two passages from the draft, only the last part of which
is relevant.

In the resulting Modified EUI-64 format the “u” bit is set to one (1)
to indicate global scope, and it is set to zero (0) to indicate local scope.

It is true that the doc does not expressly say “globally unique”, what it
says is “indicate global scope”.

The draft also says …

Modified EUI-64 format based Interface identifiers may have global scope
when derived from a global token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64
identifiers [EUI64]) or may have local scope […]

And …

The use of the universal/local bit in the Modified EUI-64 format identifier
is to allow development of future technology that can take advantage of
interface identifiers with global scope.

I doubt I’m the only reader to come to the conclusion that “have global
scope” actually means “be globally unique”. What’s more, a review of various
IPv6 related mailing lists will show this opinion expressed over and over
again. Clearly there are many readers who have leapt to this wrong conclusion,
if it is in fact wrong, and as the IESG have concluded, there is no actual
expectation that the IID will be any more than probably globally unique, then
the draft should probably be more explicit in saying that, rather than allowing
readers to leap to the incorrect interpretation.

But there is more to this than the IESG apparently understood. The question
isn’t just whether the ‘u’ bit being set implies that the IID is globally
unique (or has “global scope”) but whether there are any implementations at
all that actually enforce the setting of the ‘u’ bit only when the IID has
been formed from a (probably) globally unique token (a MAC address or similar).
Here there has been one implementation reported on the mailing list (but not
in the interoperability report) – but for DS status, one implementation isn’t
enough.

Other implementations allow the user to configure the ‘u’ bit set without
having any knowledge or expectation, or reason to assume, that the address
is derived from any kind of globally unique token (or token with global scope).
What’s more, they do this for good reason, as without that ability, users
have no way to remove a NIC, and replace it with another, and retain the original
(auto-configured) IPv6 address (which being based upon the MAC address that
the old NIC provided, would have had the ‘u’ bit set). In this case the address
is in fact based upon a globally unique token, but the implementation has
no way to know that, and so must also allow the ‘u’ bit to be set when the
rest of the IID is 0, or 1, or 2, which are most certainly not tokens with
any kind of global scope. What’s more, as the old NIC may be now in use in
some other host, there’s no reason in the example cited to assume that there’s
any uniqueness at all – for correct IPv6 operation, the NIC can’t be connected
to the same subnet as where it used to be, but beyond that IPv6 works just
fine with the same IID on different nets).

Once again, we have a feature of the specification which is either not implemented,
or at best, is not clear.

The IESG’s response to all of this is …

When considering this appeal, it is clear from the interoperability reports
that there are implementations that generate the interface ID from the EUI-64
identifier, which makes it be 64 bits long. It is also clear that the uniqueness
properties of EUI-64 based identifiers will be the same as the EUI-64 identifiers
from which they are derived (which is slightly weaker than a requirement
for global uniqueness).

Yes – though in practice implementations (bar one) allow addresses to be
generated from EUI-64’s, but they also allow indistinguishable addresses to
be manually configured – so in practice (which is what the interoperable implementation
requirement is attempting to ensure that the specification conforms to) extracting
an IID from an IPv6 address, and expecting it to have any kind of similar
properties of global uniqueness as an EUI-64 would be a false expectation,
and the draft should not lead people into expecting otherwise. Only if implementations
actually enforced this requirement (which they can easily do, as the one which
has done it shows, though of course, this loses functionality) would this
expectation be justified.

So for at least some implementations, they are capable of acting as specified
in the document being challenged.

No. The requirement challenged is a “must only be” – or if you like, a MUST
NOT. The fact that it is possible to conform with the spec using existing
implementations has nothing to do with the issue at all.

The IESG’s response here would be the equivalent of responding to a requirement
that “All cars must be red” by pointing to a few red cars and saying “see,
it can be done”. That it can be done isn’t the issue, the issue is that the
specification says it MUST be done. To be advanced to DS, all that is required
is that there be 2 conforming implementations, what the rest do is irrelevant
(until the doc is ready to be advanced to full standard). For some specifications,
2 implementations itself is a large hurdle, for IPv6, it isn’t, there are
many implementations. That none of them have implemented one of the requirements
of the doc, and only one another, should be a pretty obvious red flag that
these requirements should not remain in the document.

The IESG also says …

We traditionally require that things interoperate when configured correctly,
not that they interoperate when configured incorrectly, or that it be impossible
to configure them incorrectly.

Of course, that’s as it should be. That is, except where the specification
explicitly says that something must not be possible. There’s no point keeping
a prohibition in the specification if no-one takes any notice of it. There’s
no difference here to keeping some other feature that no-one bothers to implement.

And again from the IESG …

Implementation reports are used to verify that independent implementations
can succesfully interoperate. This is a quality check on the clarity of
the documents.

Yes. But the IESG have managed to conveniently forget the other purpose
for the requirement – that is, as a check that the features are actually being
implemented, and that the document isn’t describing things which in practice
everyone ignores.

But even without that, here we have no quality check on the clarity of the
relevant statements in the documents – no-one has implemented them. (No-one
has implemented one, there’s only one implementation of the other). We’re
only guessing if we assume that the statements are clear enough.

IESG again:

Requiring explicit verification on all statements would be a change to
existing practice and one that would likely increase the difficulty in advancing
documents on the standards track.

That’s what was intended. If existing practice has been to ignore the two
implementation requirement, when it is known not to be met, then I submit
that the IESG has been operating contrary to the clear instructions of 2026.

It need not be onerous to enforce this however – it is entirely reasonable
to expect the community to point out any flaws in the implementation reports
as published. If there are no reported problems, the IESG, and the community,
are justified in assuming that the reports fully document the required interoperability
of every feature. Where there are reports that interoperability of some feature
has not been properly documented, then it should be easy for the implementation
report to be corrected, if the feature has in fact been implemented and tested.
If it has been implemented, but not tested, then the report should be seen
as being of benefit, in showing a potential trouble area, not as a burden.
If testing shows that all works, then there’s real harm done, and the implementation
report can be corrected. If testing shows non-interoperability, then clearly
there’s something that needs fixing (in some cases, just implementation bugs,
after which further testing will show the specification is fine). On the other
hand if testing is not possible, because the feature has not been implemented,
then it really should be removed from the document before it is advanced.
That’s what the requirement in 2026 is there for.

The IESG again …

There are many places in IETF standards where a field is stated to be
a specific length or a value to be within a range. Requiring that the limits
be enforced in software for all of these cases would put a significant extra
burden on the implementers and the documenters of the implementations for
questionable benefit.

This is once again based upon a misunderstanding of what is required. No-one
is requiring that the limits be enforced in general. What is being asked is
that someone (sometwo really) has done it. What’s the point of a requirement
that is universally ignored? There is none, it is misleading, and should not
be permitted in a Draft Standard.

I would ask that the IAB instruct the IESG to overturn their decision to
publish the draft (draft-ietf-ipngwg-addr-arch-v3-11.txt) as a Draft Standard,
and at their choice, either publish it as a Proposed Standard, or return it
to the working group for amendments that will allow it to be published as
a Draft Standard.

kre

ps: I would also request that the RFC editor continue to defer publication
of this draft until the IAB has dealt with this appeal.

Internet Architecture Board

RFC2850

Appeal Against IESG Action by Mr. R. Elz(Appeal Text) — IAB Response, February 2003