Re: Appeal against IESG decision

[Leslie Daigle <[e-mail]>]

Robert, all,

Here is the IAB's response to this appeal, as it is queued
to be announced on [e-mail].

Regards,
Leslie.


================================================



On Saturday, January 4th 2003, Robert Elz filed an appeal with the
Internet Architecture Board (IAB).  The appeal concerned the IESG
decision to publish draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft
Standard and the subsequent IESG consideration of an appeal to the
IETF chair on this matter.


1. Background

The appeal asked the IAB to consider whether the Internet Engineering
Steering Group's (IESG's) decision to approve the publication of 
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard met the
process and technical standards of the IETF. The appeal contained the
following claims:

1) That the IESG failed to verify interoperability of 2
	independent implementations for the Internet Protocol
	version 6 (IPv6) unicast address format defined in the 
	above Internet-Draft.

2) That the IESG failed to verify that 2 independent implementations
	exist that prohibit the configuration of any IPv6 unicast
	address (not including those that start with binary 000)
	that does not have a 64-bit Interface-Identifier (Interface-ID).

3) That the document draft-ietf-ipngwg-addr-arch-v3-11.txt fails
	to clearly indicate (e.g. using customary MAY, SHOULD, MUST
	language) which parts of the document are mandatory or
	optional to implement or which parts of the document are
	interoperability requirements.

4) That the document uses the phrase "global scope" in a way that
	is materially confusing and causes a typical reader to
	incorrectly assume that "global scope" means "globally
	unique".

5) That the IESG has failed to verify that at least two interoperable
	implementations exist that prohibit the configuration of
	an interface-ID with the 'u' bit when the basis of the
	interface-ID is not a "globally unique token (MAC address
	or similar)".

6) That the document is materially unclear with respect to the
	language on when the 'u' bit of an Interface-ID is
	permitted to be set (or not set).

In its rejection of Robert Elz's original appeal to the IESG,
the IESG stated:

A) That there is no traditional requirement that implementation reports
	"include detailed verification that implementations enforce
	every statement...in the absence of explicit text requiring
	that an implementation make such checks."
	
B) That the requirement is that implementations operate when
	correctly configured, not that they interoperate when 
	incorrectly configured.
	
C) That there is no traditional requirement that an implementation
	disallow an operator from misconfiguring a protocol.
	
D) That the Internet-Draft in question does not require that
	the Interface-ID be globally unique when the 'u' bit
	is set; it merely requires that the Interface-ID comply
	with the EUI-64 specification when the 'u' bit is set.
	
E) That Elz's appeal is rejected by the IESG.


2. IAB Conclusion

Some of the issues raised in this appeal represent instances in which
the process or technical standards of the IETF were not met.  On that
basis, the IAB has determined that the IESG decision to advance this
specification on the IETF standards-track as a Draft Standard in its
current form, and the IESG's subsequent response to Elz's appeal, were
incorrect.

On that basis, the draft in its current form must not be published as a
IETF Draft Standard, and may be published as an IETF Proposed Standard.

The IAB response to this appeal is in three parts. The first part
contains particular facts determined by the IAB that relate to the
claims made in the appeal. The second part contains related
observations of the IAB arising from its review of documents germane to
the appeal. The third part contains recommendations to the IESG as to
possible actions on how to remedy the matters raised here.


2.1 Salient Facts

The IAB has determined the following facts regarding the Elz appeal:

I) An IP Address Architecture specification will always need to have
	some implementation requirements and interoperability 
	requirements.  Addressing and routing are inextricably
	linked.  Decisions about an address architecture necessarily
	have impacts on the forwarding of IP packets and on
	the routing protocols.  If there were no requirements
	in an IP Address Architecture, it is very unlikely that
	global interoperability could result in practice.  We
	further find that an IPv6 Address Architecture document
	belongs on the standards-track.
	
II) The IETF standards process does NOT require that a tested
	implementation prohibit misconfiguration of a protocol
	parameter, unless there is a specific written statement
	requiring such in the applicable specification document.

	    The IAB makes the additional comment that to interpret
	    the standards process requirements otherwise would be to
	    make it nearly impossible for any IETF standards-track
	    specification to advance and would be a new and undue
	    process burden on the IETF.

III) The IETF standards process does require that the default settings
	for each protocol parameter are valid and interoperable 
	when tested as part of an interoperability report.  It 
	is not required that each protocol parameter's default
	setting be individually documented in an interoperability 
	report.  The IETF requires interoperability testing, not
	conformance testing, as part of advancement beyond Proposed
	Standard according to RFC-2026.


2.2 IAB Considerations

In the course of reviewing the appeal and studying the facts 
germane to the appeal, the IAB also reached consensus on the 
following points:


IV) The Internet-Draft in question is not sufficiently clear 
	in specifying the implementation requirements and/or
	interoperability requirements for the IPv6 Address 
	Architecture.  
	
V) This lack of clarity on the part of the draft document violates
	criteria as specified in RFC-2026 and RFC-2119, by not
	containing clear documentation of the implementation
	requirements and interoperability requirements.  On this
	basis, the draft cannot be published in its current form on
	the IETF standards-track as a Draft Standard.	

VI) The questions of whether the IESG properly verified
	implementation report details regarding this I-D are moot,
	due to the consideration that the I-D itself was in violation
	of RFC-2026 and RFC-2119.

VII) The phrase 'global scope' does not mean 'globally unique'. There
	remains, however, some scope for confusion as to the precise
	meaning of the term 'global scope' for the average reader.
	
VIII) The existing specification of how the 'u' bit is used in
	an IPv6 unicast Interface-ID is clear, but the current
	version of the I-D under appeal is unclear regarding the
	implementation or interoperability requirements, if any, 
	that are related to the 'u' bit

IX) The IAB considers that the separation of the Interface-ID from
	the Subnet Identifier in IPv6 unicast addresses not starting 
	with binary 000 is a fundamental property of the IPv6 
	addressing and routing architecture and should be retained.

X) The IAB notes that RFC-2461 Section 4.6.2 permits an IPv6
	router to advertise an IPv6 unicast prefix-length of
	more than 64 bits while simultaneously setting the
	'autonomous configuration' flag to true.  Further,
	the RFC-2462 Section 5.5.3d does not explicitly require
	that the IPv6 prefix length not exceed 64 bits, as 
	the IPv6 Address Architecture draft requires.  Hence,
	we find a material conflict between the specifications
	in the IPv6 Address Architecture draft, in RFC-2461, and
	in RFC-2462.
	
XI) We believe that the conflicts noted in (X) occurred primarily 
	because of the failure of the I-D under appeal to comply 
	with the requirement for clearly specified implementation
	and interoperability requirements as per RFC-2119 and 
	RFC-2026.

XII) We concur with IESG statements paraphrased above as (A), (B),
	(C), and (D).  However, we reject the IESG conclusion (E) on
	the basis that the IESG's reply to Elz ignored the question
	of whether the current language regarding implementation
	requirements and interoperability requirements in draft-ietf-
	ipngwg-addr-arch-v3-11.txt is sufficiently clear and fully
	compliant with RFC-2026 and RFC-2119.


2.3 IAB Recommendations


The IAB makes the following recommendations with regard to draft-ietf-
ipngwg-addr-arch-v3-11.txt. An organizing theme behind these
recommendations is a desire on the part of the IAB to see the IPv6
addressing architecture stabilized as quickly as possible, with
interoperability requirements clearly specified, in an aid to
facilitating the more rapid implementation and deployment of IPv6 in the
Internet infrastructure.

As noted in Section 2, the IAB has determined that the draft in its
current form must not be published as an IETF Draft Standard.
	
a) We recommend to the IESG that the current version of the I-D draft
	be published as a Proposed Standard.

b) we recommend that the IESG consider the publication of subsequent
        updates to this document as per recommendations c) and d).

c) We recommend that, as an update to this document, and via a
        recommendation to the IESG, that the IPv6 Working
        Group create clear, specific, and concise implementation and
        interoperability requirements as per RFC-2026 and RFC-2119 in
        any revised version of the IPv6 Addressing Architecture
        document.  This includes, but is not limited to, the
        specification of any implementation or interoperability
        requirements relating to the use of the 'u' bit in an IPv6
        unicast Interface-ID.

d) We recommend that, as an update to this document, and via a
	recommendation to the IESG, that the IPv6 Working Group uses
	clearer specification language as per RFC-2026 and RFC-2119 to
	describe the requirement for a 64-bit Interface-ID in IPv6
	unicast addresses not starting with binary 000.
        
e) We recommend that, via a recommendation to the IESG, that the IPv6
        Working Group expeditiously revise RFC-2461 to:
	
	  - specifically note that it is not valid to configure an IPv6
	    router such that the 'autonomous configuration' bit is set
	    to TRUE AND the advertised IPv6 prefix length exceeds 64
	    bits AND the advertised IPv6 prefix does not start with
	    binary 000,
	
	and also expeditiously revise RFC-2462 to:
	
	  - specifically require that a host ignore a Prefix
	    Advertisement Option when the first three bits of the
	    advertised IPv6 prefix do not start with binary 000 AND the
	    advertised IPv6 prefix-length exceeds 64-bits.



Leslie Daigle,
for the IAB.

Robert Elz wrote:
> 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
> 
> 1) RFC2026 says, in section 4.1.2 ...
> 
>    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.
> 
> 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.
> 


-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
   -- ThinkingCat  (c.1983 - 2002)

Leslie Daigle
[e-mail]
-------------------------------------------------------------------