IP Addressing Model in Ad Hoc Networks
draft-ietf-autoconf-adhoc-addr-model-03

[Ballot comment]
Expand DAD (end of section 6.2).  For consistency, either use "DAD" in both 6.1 and 6.2, or in neither.
---
The first paragraph of section doesn't accurately describe the applicability:

  The configuration proposed by this model is applicable to any
  router's IP interface.  It specifies IP addresses and IP subnet
  prefixes to be configured on network interfaces.

Perhaps "This model gives guidance about the autoconfiguration of IP addresses and the IP subnet prefixes as on-link on router's IP interfaces."??
---
I was OK with section 4 up to and including the principle about not configuring an interface with any knowledge of on-link prefixes.  Then I got lost. While the following paragraph about L2 communication regardless of configuration of on-link prefixes is true, it's seems irrelevant because the principle advices against the configuration of on-link prefixes.  The last paragraph may also be true, but appears out of place in a document about a network model in which nothing can be guaranteed about on-going L2 connectivity.
---
Re-reading sectinos 6.1 and 6.2, I am pretty sure there is no fundamental difference in the ways in which this model can be applied to IPv6 and IPv4.  For example, doesn't this observation apply to IPv4 as well as IPv6?

  o  There is no mechanism to ensure that IPv6 link-local addresses are
      unique across multiple links, hence they can not be used to
      reliably identify routers.

"routers" or "router interfaces" - which hints at something that might need clarification: IP addresses are used both as interface addresses and sometimes, by selecting one global address from those assigned to the interfaces, as an identifier for the entire router.

Why does the model suggest no on-link prefixes for IPv6 and allow /32 on-link prefixes for IPv4?  Why not /128s for IPv6 or, conversely, no prefixes for IPv4?
---
(Previous DISCUSS)

The document include RFC 2119 boilerplate but uses lower case requirements words throughout both normatively and non-normatively.

I know this document comes from the autoconf working group, but as far as I can tell, none of the principles or rules are specific to autoconfiguration.  The term "autoconfigure" is used only sporadically in the document.  Is this document specifically about autoconfiguration or configuration in general?  It would help to include some text explaining the scope of the document.

[Ballot discuss]
The document include RFC 2119 boilerplate but uses lower case requirements words throughout both normatively and non-normatively.

I know this document comes from the autoconf working group, but as far as I can tell, none of the principles or rules are specific to autoconfiguration.  The term "autoconfigure" is used only sporadically in the document.  Is this document specifically about autoconfiguration or configuration in general?  It would help to include some text explaining the scope of the document.

[Ballot comment]
Expand DAD (end of section 6.2).  For consistency, either use "DAD" in both 6.1 and 6.2, or in neither.
---
The first paragraph of section doesn't accurately describe the applicability:

  The configuration proposed by this model is applicable to any
  router's IP interface.  It specifies IP addresses and IP subnet
  prefixes to be configured on network interfaces.

Perhaps "This model gives guidance about the autoconfiguration of IP addresses and the IP subnet prefixes as on-link on router's IP interfaces."??
---
I was OK with section 4 up to and including the principle about not configuring an interface with any knowledge of on-link prefixes.  Then I got lost. While the following paragraph about L2 communication regardless of configuration of on-link prefixes is true, it's seems irrelevant because the principle advices against the configuration of on-link prefixes.  The last paragraph may also be true, but appears out of place in a document about a network model in which nothing can be guaranteed about on-going L2 connectivity.
---
Re-reading sectinos 6.1 and 6.2, I am pretty sure there is no fundamental difference in the ways in which this model can be applied to IPv6 and IPv4.  For example, doesn't this observation apply to IPv4 as well as IPv6?

  o  There is no mechanism to ensure that IPv6 link-local addresses are
      unique across multiple links, hence they can not be used to
      reliably identify routers.

"routers" or "router interfaces" - which hints at something that might need clarification: IP addresses are used both as interface addresses and sometimes, by selecting one global address from those assigned to the interfaces, as an identifier for the entire router.

Why does the model suggest no on-link prefixes for IPv6 and allow /32 on-link prefixes for IPv4?  Why not /128s for IPv6 or, conversely, no prefixes for IPv4?
---

[Ballot discuss]
The document include RFC 2119 boilerplate but uses lower case requirements words throughout both normatively and non-normatively.

I know this document comes from the autoconf working group, but as far as I can tell, none of the principles or rules are specific to autoconfiguration.  The term "autoconfigure" is used only sporadically in the document.  Is this document specifically about autoconfiguration or configuration in general?  It would help to include some text explaining the scope of the document.

[Ballot comment]
It seems the content of this document could be summarized "if you want
to use a routing protocol that requires unique addresses (within the
routing domain), link-local addresses are not sufficient (since
they're unique only within a link)".

I wonder if the document title should be more precise about this?
Perhaps something like "Why Link-Local Addresses Are Not Sufficient
For Ad Hoc Routers"?

[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-02-27 included very
  minor editorial comments.  Please consider them if an update to
  this document is needed for any reason.

[Ballot comment]
>                  IP Addressing Model in Ad Hoc Networks

  Title doesn't fit the document too well - the document is not only
  about ad hoc networks, and it doesn't describe a general IP addressing
  model, just guidelines for addressing router interfaces.

PROTO writeup for draft-ietf-autoconf-adhoc-addr-model-02.txt
=================================================

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and,
in particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

Ryuji Wakikawa, AUTOCONF co-chair, is the document shepherd for this document,
draft-ietf-autoconf-adhoc-addr-model, and believes that it is ready for publication.

(1.b) Has the document had adequate review both from key WG members and
from key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

The document has had adequate review. The document shepherd does not have any
concerns about the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization,
or XML?
No.

(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for
it. In any event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those concerns here.
Has an IPR disclosure related to this document been filed? If so, please i
include a reference to the disclosure and summarize the WG discussion and
conclusion on this issue.

No.

(1.e) 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?

There is a good consensus around this document, but not unanimity.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarize the areas of conflict in separate email messages to
the Responsible Area Director. (It should be in a separate email because
this questionnaire is entered into the ID Tracker.)

There has been no threat of an appeal.

The document discourages the use of Link Local addresses on MANET router
interfaces, but does neither prohibit their use (nor does the document
prohibit assignment hereof to such MANET router interfaces). The document
explains the reasoning behind this recommendation: that as Link Local addresses
can not be communicated beyond one IP hop, a protocol does not exist which can
ensure that Link Local addresses are unique across the routing domain, and thus
the Link Local addresses do not satisfy the most stringent of the criteria, set
out in the document, for a MANET router interface configuration to be valid for
all current MANET routing protocols. A few WG members have expressed discomfort
with this.

The above paragraph is also sent to the responsible AD in a separate email, for
tracker-purposes.

(1.g) Has the Document Shepherd personally verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type, and URI type
reviews? If the document does not already indicate its intended status
at the top of the first page, please indicate the intended status here.

IDNits returns:

== You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
http://trustee.ietf.org/license-info/)

The document, otherwise, satisfies all ID nits.

The intended status is INFORMATIONAL

(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion? Are there
normative references that are downward references, as described in
[RFC3967]? If so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has only normative references. There are no downward references.

(1.i) Has the Document Shepherd verified that the document's IANA Considerations
section exists and is consistent with the body of the document? If the
document specifies protocol extensions, are reservations requested in
appropriate IANA registries? Are the IANA registries clearly identified?
If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for future
registrations? Does it suggest a reasonable name for the new registry?
See [RFC2434]. If the document describes an Expert Review process, has
the Document Shepherd conferred with the Responsible Area Director so
that the IESG can appoint the needed Expert during IESG Evaluation?

This document does not define any new registries or registrations; indeed,
it does not have any IANA actions

(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can
be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes a model for configuring IP addresses and
subnet prefixes on the interfaces of routers which connect to links
with undetermined connectivity properties. While the considerations
in this document are general, they are specifically written with the
most stringent requirements of MANETs in mind; essentially, a router
configured according to the principles set forth in this document
will be able to support operation of a MANET routing protocol.


Working Group Summary
As indicated in 1.f, the recommendation in the document to not use
Link Local addresses for operation over interfaces towards links with
undetermined connectivity properties was not unanimous, and on this
point, consensus was rough.

Document Quality
While the document does not specify a protocol, there are about a
decade of experience with running MANETs in which routers have
their interfaces configured according to the recommendations in this
document.

Personnel
Ryuji Wakikawa is the document shepherd of this document.