IPv6 Scoped Address Architecture
draft-ietf-ipv6-scoping-arch-02

[Ballot comment]
In Section 6:


      A tunnel interface (e.g., the abstract endpoint of an
      IPv6-over-IPv6 tunnel [8], presumably established over either the
      Ethernet or the point-to-point link.)

COMMENT:  In general, this is a very helpful example.  I would
suggest, though, that defining the tunnel interface as established
over the Ethernet might help illustrate the point that it gets
its own link-local zone, where two interfaces to the same Ethernet
link do not.  Not strictly necessary, but it would be a good opportunity
to make the point.

[Ballot comment]
This formulation (towards bottom of page 6) sounds/feels a bit strange:
  dedicated purpose.  An entry of a Management Information Base (MIB)
  will be an example of the dedicated purpose.  The actual
Not sure what "An entry of a .. (MIB)" is.
Maybe a better sentence might be

  Usage of the index to identify an entry in the Management Information
  Base (MIB) is an example of the dedicated purpose.

[Ballot discuss]
The Security Considerations section should note that the ambiguity of addresses means that unqualified source IP addresses cannot safely be used in security contexts such as ACLs or IKE negotiation.

IANA Last Call Comments:
In section 9, it says the following:

Note: Code 2 is currently left as unassigned in
[4]. But the IANA is going to re-assign the value
for the new purpose, and [4] will be revised with
this change.

Where are the directions for the IANA to re-assign this value?  In another document?  Can you please clarify.  Which registry is this value in?

Submission questionnaire from IPv6 WG chairs:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The document has been reviewed by key IPv6 working group members and some people outside of the working group.  I don't have any concerns about the breadth or quality of the reviews.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

None.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

This document captures the consensus of the WG.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The document has been underway for some time.  At this time I believe that this document represent the consensus of the many and vocal members of the working group.  The document has been discussed at IPv6 sessions at IETF meetings and on the mailing list.  Several working group last calls were done including one that ended on May 6, 2004.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

I am unaware of any planned appeal.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a write up section with the following
  sections:

  - Technical Summary

  This document describes the issues surrounding the use of IPv6 site-
  local unicast addresses in their original form, and formally
  deprecates them. This deprecation does not prevent their continued
  use until a replacement has been standardized and implemented.

  Internet Protocol version 6 includes support for addresses of
  different "scope", that is, both global and non-global (e.g.,
  link-local) addresses. While non-global addressing has been
  introduced operationally in the IPv4 Internet, both in the use of
  private address space ("net 10", etc.) and with administratively
  scoped multicast addresses, the design of IPv6 formally incorporates
  the notion of address scope into its base architecture.  This
  document specifies the architectural characteristics, expected
  behavior, textual representation, and usage of IPv6 addresses of
  different scopes.

  Though the current address architecture specification defines
  unicast site-local addresses, the IPv6 working group decided to
  deprecate the syntax and the usage, and is now investigating
  other forms of local IPv6 addressing. The usage of any new forms of
  local addresses will be documented elsewhere in the future.  Thus,
  this document intentionally focuses on link-local and multicast
  scopes only.

  - Working Group Summary

  The IPv6 working group has done extensive review of this document and
  this document reflects the consensus of the group.

  - Protocol Quality

  This document has been reviewed by members of the ipv6@ietf.org
  mailing list and by the work group chairs.