my thoughts on the IAB response to addr-arch appeal

[Thomas Narten <narten@us.ibm.com>]

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

Note, here it sounds like the current document cannot be approved as a
DS without changes. A number of such changes are mentioned later. Is
the IAB in effect requiring those changes? What if the WG and/or
community disagree with those recommendations?

note that 2026 says:

   The IAB decision is final with respect to the question of whether or
   not the Internet standards procedures have been followed and with
   respect to all questions of technical merit.

Given the above, it is unclear how to respond to the IAB's
recommendations and discuss issues where there may be
misinterpretations or where the will of the WG and community disagree
with some of the IAB's recommendations. One could certainly believe
that disagreeing with the IAB's recommendations, and attempting to
advance the document at Draft Standard without following the
recommendation would be met with a predictable outcome on appeal.

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

This statement is quite broad and provides no guidance on what parts
need to be made more clear or what would constitute being "clear
enough". As an AD who must make these judgements  in general, are
there specific issues other than the interface IDs mentioned later?
What criteria am I to use when judging whether the requirements have
been meant?

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

On what grounds would the current document be clear enough for
publication as a Proposed Standard (as the IAB recommends), but not
for Draft Standard?  (More on this below.)

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

I assume the reference to 2119 is an oversite. Or, does the IAB feel
it is necessary to use RFC 2119 terminology in all Standards Track
documents?

Also, since addr-arch does not reference 2119 or use 2119-terminology,
how can it be in violation of it?

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

This is presumably a technical question that 2026 defines the IAB has
having the final say on.

> 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

There are none. Presumably the document can be modified to say
something like:

   At present, IPv6 implementations treat the Interface Identifier
   portion of an IPv6 address as a 64-bit opaque block. Other than
   setting the 'u' bit when an interface identifier is formed,
   implementations do not take any special actions depending on the
   setting of any individual bits.

or something similar.   

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

I disagree that there is a material conflict. RFC 2462 (Section
5.5.3., under "d)"), where receiver processing requirements are
discussed says:

       If the sum of the prefix length and interface identifier length
       does not equal 128 bits, the Prefix Information option MUST be
       ignored.

Thus, 2462 supports a longer prefix only in conjunction with a shorter
interface ID (which is defined per link-layer technology).

Quite some time back, the WG discussed the issue of updating 2462 but
decided to leave it as it is. Arguments included:

 - no need to change the spec in a way that invalidated existing
   implementations.

 - the above check was sufficient to catch misconfigurations

 - if, in the future it was deemed necessary or desireable to change
   the size of IIDs, or use prefix 000 in a way that we can not forsee
   today, it is better for implementations to be more flexible, so
   that future changes may be contemplated that would be supported by
   deployed systems.

Note that requiring the hosts check for prefix 000 and not allow
autoconfiguration of such prefixes would make it rather difficult to
ever use the 000 prefix for normal global unicast addresses. It seems
unwise to hard-wire the restriction into implenations, given that
there is no apparent harm with leaving the specs as they are today.

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

This comment is surprising. On the one hand, the IAB stated earlier
(points A), B) and C)) that enforcement checks were not required
unless the document explicitely calls for them. Yet, here, the IAB
seems to say that such checks _are_ a requirement and that RFCs 2461
and 2462 need to add wording to require such checks and that
implementations must enforce them.

I am confused as to which principal to apply when.

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

I disagree, per comments above. The WG is quite aware that other
documents do not include checks that require IIDs be exactly 64 bits
long.

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

I don't recall the appeal raising the issue that the IAB says we
didn't check for. This sounds to me like a broadening of the scope of
an appeal beyond the issues cited in the appeal. If so, I find this
troubling.

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

To clarify, 2026 states:

   If circumstances warrant, the IAB may direct that an IESG decision be
   annulled, and the situation shall then be as it was before the IESG
   decision was taken. The IAB may also recommend an action to the IESG,
   or make such other recommendations as it deems fit. The IAB may not,
   however, pre-empt the role of the IESG by issuing a decision which
   only the IESG is empowered to make.

Thus, the language used above ("must not be published") seems rather
strong, in that it can be read to mean that the IESG cannot approve
document as a Draft Standard.

Can I assume that the official action is to annull the IESG decision
and send the issue back to the IESG for reconsideration?

> a) We recommend to the IESG that the current version of the I-D draft
> 	be published as a Proposed Standard.

As mentioned earlier, I would like to better understand the criteria
for determining whether a document is good enough for PS, but not good
enough for DS, when the cited issue is "lack of clarity" of the
document. 2026 makes no such distinction by my read. It talks mainly
about implementations, of which there are over XXX for IPv6 (5 listed
on the IETF web page, but that page is dated 1998 and I think a newer
one exists).

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

This can easily be done, per above

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

This can be done easily enough, per above. But I assume that 2119
language is not required.

> 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,

Disagree, for reasons mentioned above.

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

Disagree, per above. Exactly, what problem is this intended to
address?

Thomas