[Ballot comment]
My Discuss was not addressed at all - I believe that the WG ignored the
spirit of the implementation report requirement - my Discuss said that
we should know that there are multiple implementations that have
handled the significant changes in the recycling of this Draft Standard.
The group apparently refused to update its implementation report, but I
believe did not respond on this.  I did not intend to conduct a pocket veto, and
I do not believe that my objection should have been played this way, if
that's what happened. 

Clearing rather than punish the technical protocol for its context.  I assume
the interoperability testers are somewhere out in the world (IETF is not
in this business).

[Ballot discuss]
1. No updated implementation report; I'd like to see reporting in there of the basis
    for the dropping of the Managed bit, which is stated in the draft as an implementation
    result.  It's a good simplification, it sounds like, but documenting this in the report
    would be good.

    Didn't the reading of 2026 come out updated implementation reports for recycling DS's?

2. There is a lot of normative dependency on the recycling DS of Neighbory Discovery which not
    even in the tracker yet, so are there some instabilities?

3.  Was there an analysis of the configuration consistency rule (section 5.6) of acceptng
    the most recent information, while trying to secure both DHCPv6 and ND/addrconf
    (SEND)?

[Ballot discuss]
1. No updated implementation report; I'd like to see reporting in there of the basis
    for the dropping of the Managed bit, which is stated in the draft as an implementation
    result.  It's a good simplification, it sounds like, but documenting this in the report
    would be good.

    Didn't the reading of 2026 come out updated implementation reports for recycling DS's?

2. There is a lot of normative dependency on the recycling DS of Neighbory Discovery which not
    even in the tracker yet, so are there some instabilities?

3.  Was there an analysis of the configuration consistency rule (section 5.6) of acceptng
    the most recent information, while trying to secure both DHCPv6 and ND/addrconf
    (SEND)?

[Ballot discuss]
RFC 3756 says that IPsec really does not work for neighbor
  discovery.  Even if it does work in some cases, there is not
  enough detail in this document to say how to use it.  SEND
  is the answer, of course.  However, this document cannot
  have a normative reference to SEND because this document is
  going for publication as Draft Standard.

  My recommendation is to delete the text regarding the use of
  IPsec and replace it with an Informative reference to SEND.
  I think this is better than misleading the reader.

[Ballot comment]
I suggest adding another event to section 5.3.  Consider an event
  that indicates that the physical network connectivity may have
  changed.  Such events include a carrier down/carrier sequence on
  an Ethernet NIC, a change of SSID on an 802.11 network, or waking
  up from a "sleep" period.

[Ballot discuss]
Steve Bellovin pointed out the following text in the security considerations section:
>These attacks can be addressed by requiring
>  that Neighbor Discovery packets be authenticated with IP security
>  [RFC2402].  However, it should be noted that [RFC3756] points out the
>  use of IP security is not always feasible depending on network
>  environments.

IPsec really isn't a good fit for neighbor discovery; SEND is the
solution we have come up with to solve these problems.  I realize we
cannot have a normative reference to SEND from this specification.  An
informative reference might be acceptable.  Either way I request that
the text on IPsec be deleted.  AT best it will lead people down the
wrong path.

AD REVIEW COMMENTS SENT TO AUTHOR & IPV6 LIST:

Hi Jinmei,

I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt.  I have several comments on this document that I believe should be resolved before this document is sent to IETF Last Call for publication as a Draft Standard.

All of my comments are included below, but my most serious concerns are:

(1) Having decided that "the stateful configuration" mechanism is DHCPv6, I don't think that there is a reason to maintain the awkward and confusing wording about "the stateful mechanism" in many places.  I've pointed out the worst cases, but there are many others.  I know that this is largely an editorial concern, but the awkwardness and lack of clarity are bad enough in some places (see below) that I consider this a blocking problem for publication at DS.

(2) I am not comfortable with the idea that we would punt the interpretation of the M & O bits to a "separate document" with no reference.  I believe that information about how to interpret these bits is essential to implementing IPv6 address autoconfiguration.  See below for the specific text that concerns me.

I'd be interested in your feedback on these issues, as well as on the other more minor issues I've noted below.

I've cc:ed the IPv6 WG on this message, and other IPv6 folks should also feel free to respond, especially if you think that I'm mistaken about something.

Margaret

---

My comments are in-line, marked with ">>"

Abstract

  This document specifies the steps a host takes in deciding how to
  autoconfigure its interfaces in IP version 6.  The autoconfiguration
  process includes creating a link-local address and verifying its
  uniqueness on a link, determining what information can be
  autoconfigured (addresses, other information, or both), and in the
  case of addresses, whether they can be obtained through the stateless
  mechanism, the stateful mechanism, or both. 

>> whether they can be obtained through stateless autoconfiguration, the Dynamic Host Configuration Protocol (DHCP) or both?

  This document defines
  the process for generating a link-local address, the process for
  generating global addresses via stateless address autoconfiguration,
  and the Duplicate Address Detection procedure.  The details of
  autoconfiguration using the stateful protocol are specified in RFC
  3315; an alternative way of using the stateful protocol to deliver
  'other information' only is specified in RFC 3736.

>> I'd move the whole last sentence to an introduction and take it out of the abstract.  Since we can't have references in an abstract, I think it is useless, anyway.

1.  INTRODUCTION

  This document specifies the steps a host takes in deciding how to
  autoconfigure its interfaces in IP version 6 (IPv6).  The
  autoconfiguration process includes creating a link-local address and
  verifying its uniqueness on a link, determining what information can
  be autoconfigured (addresses, other information, or both), and in the
  case of addresses, whether they can be obtained through the stateless
  mechanism, the stateful mechanism, or both.

>> s/the stateful mechanism/DHCP

  This document defines
  the process for generating a link-local address, the process for
  generating global addresses via stateless address autoconfiguration,
  and the Duplicate Address Detection procedure.  The details of
  autoconfiguration using the stateful protocol is specified in
  [RFC3315] and [RFC3736].

>> s/the stateful protocol/DHCP

  IPv6 defines both a stateful and stateless address autoconfiguration
  mechanism.  Stateless autoconfiguration requires no manual
  configuration of hosts, minimal (if any) configuration of routers,
  and no additional servers.  The stateless mechanism allows a host to
  generate its own addresses using a combination of locally available
  information and information advertised by routers.  Routers advertise
  prefixes that identify the subnet(s) associated with a link, while
  hosts generate an "interface identifier" that uniquely identifies an
  interface on a subnet.  An address is formed by combining the two.
  In the absence of routers, a host can only generate link-local
  addresses.  However, link-local addresses are sufficient for allowing
  communication among nodes attached to the same link.

  In the stateful autoconfiguration model, hosts obtain interface
  addresses and/or configuration information and parameters from a
  Dynamic Host Configuration Protocol (DHCPv6) server.  Servers
  maintain a database that keeps track of which addresses have been
  assigned to which hosts.  The stateful autoconfiguration protocol
  allows hosts to obtain addresses, other configuration information or
  both from a server.  Stateless and stateful autoconfiguration
  complement each other.  For example, a host can use stateless
  autoconfiguration to configure its own addresses, but use stateful
  autoconfiguration to obtain other information.

  To obtain other configuration information without configuring
  addresses in the stateful autoconfiguration model, a subset of DHCPv6
  [RFC3736] will be used.  While the model is called "stateful" here in
  order to highlight the contrast to the stateless protocol defined in
  this document, the intended protocol is also defined to work in a
  stateless fashion.  This is based on a result, through operational
  experiments, that all known "other" configuration information can be
  managed by a stateless server, that is, a server that does not
  maintain state of each client that the server provides with the
  configuration information.

>> This is the part that I consider to be quite awkward, particularly the vague references to operational experiments that aren't documented or referenced here.  If you switch to just referring to DHCP, the preceeding three paragraphs can be substantially simplified.  I also thin it is unnecessary to say so much about how DHCP works -- that is the subject of other document.  There are many other places where the text would be much clearer if DHCP (or DHCPv6) were used instead of "the stateful mechanism", but I will not mark them all.

  The stateless approach is used when a site is not particularly
  concerned with the exact addresses hosts use, so long as they are
  unique and properly routable.  The stateful approach is used when a
  site requires tighter control over exact address assignments.  Both
  stateful and stateless address autoconfiguration may be used
  simultaneously.  The site administrator specifies which type of
  autoconfiguration is available through the setting of appropriate
  fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis].

>> Given this normative reference, would it make sense to hold 2462bis until 2461bis is completed and send them forward together?  Otherwise, this will just block in the RFC Editor, and we won't have the ability to change it again if we discover issue while finishing the 2461 update.  Thoughts?

2.  TERMINOLOGY

>> Is this terminology section intended to be in logical order?  Is there a reason to prefer this order over an alphabetical listing? 

  Nodes (both hosts and routers) begin the autoconfiguration process by
  generating a link-local address for the interface.  A link-local
  address is formed by appending the interface's identifier to the
  well-known link-local prefix.

>> I think that there should be a reference to the addressing architecture or the scoped address architecture here...  Something that tells me how I actually create a link-local address.

  A "managed
  address configuration (M)" flag indicates whether hosts can use
  stateful autoconfiguration [RFC3315] to obtain addresses.  An "other
  stateful configuration (O)" flag indicates whether hosts can use
  stateful autoconfiguration [RFC3736] to obtain additional information
  (excluding addresses).

  The details of how a host may use the M flag, including any use of
  the "on" and "off" transitions for this flag, to control the use of
  the stateful protocol for address assignment will be described in a
  separate document.  Similarly, the details of how a host may use the
  O flag, including any use of the "on" and "off" transitions for this
  flag, to control the use of the stateful protocol for getting other
  configuration information will be described in a separate document.
  However a host uses the M and O flags, and local configuration to
  control autoconfiguration, the default setting will result in
  received Router Advertisements being processed for stateless address
  autoconfiguration.

>> I don't think it is okay to publish a DS that leaves important implementation details to a "separate document".  Has the separate document been published?  If so, it needs to be normatively referenced here.

  Router Advertisements also contain zero or more Prefix Information
  options that contain information used by stateless address
  autoconfiguration to generate global addresses.  It should be noted
  that the stateless and stateful address autoconfiguration fields in
  Router Advertisements are processed independently of one another, and
  a host may use both stateful and stateless address autoconfiguration
  simultaneously.  One Prefix Information option field, the "autonomous
  address-configuration flag", indicates whether or not the option even
  applies to stateless autoconfiguration.  If it does, additional
  option fields contain a subnet prefix together with lifetime values
  indicating how long addresses created from the prefix remain
  preferred and valid.

>> What happens if the value of the "autonomous address-configuration flag" changes over time?

  For safety, all addresses must be tested for uniqueness prior to
  their assignment to an interface.  The test should individually be
  performed on all addresses obtained manually, via stateless address
  autoconfiguration, or via stateful address autoconfiguration.  To
  accommodate sites that believe the overhead of performing Duplicate
  Address Detection outweighs its benefits, the use of Duplicate
  Address Detection can be disabled through the administrative setting
  of a per-interface configuration flag.

>> I am not sure how the last sentence is consistent with the must in the first sentence.  Change the must in the first sentence to a should?