IAB response to Robert Elz appeal

["Leslie Daigle" <[e-mail]>]

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.