Last Call Review of draft-ietf-homenet-prefix-assignment-06
review-ietf-homenet-prefix-assignment-06-opsdir-lc-chown-2015-07-13-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
 comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall, I believe the draft is ready with minor issues, mainly around
presentation and clarity.

As one part of the proposed HNCP protocol, having this distributed prefix
distribution algorithm documented is a Good Thing.

Homenet has considered previous work in this area, e.g.both
draft-arkko-homenet-prefix-assignment-04 and
draft-baker-homenet-prefix-assignment-01 have been discussed in homenet. While
those don’t need to be cited, it’s worth noting that homenet has been seeking a
self-configuring prefix distribution mechanism for some time (3-4 years).

General comments:

The draft very much throws the reader in at the deep end. It would be very
useful if a high-level description of the philosophy of the algorithm were
included in the introduction, such that those principles are in the reader’s
mind when they read through the remainder of the document, including the
description of the algorithm.

Related, there is very little content in the draft. It does not cite or mention
that it is used by HNCP, nor does it cite RFC 7368. There is no text describing
(even just briefly) why this approach is favoured, or any rationale why this
approach is most favoured for HNCP (or regarding the claimed convergence). If
those are documented elsewhere, a link/reference would be useful for the reader.

Regarding RFC 7368, the draft could claim compliance with that RFC, in
particular Section 3.4.3, given the support for assigned prefix stability
described within the draft. Given it is a homenet draft, this would seem
appropriate.

Because the draft describes an algorithm, rather than a detailed protocol, many
parts of the document omit specifics, e.g. the format of a Node ID, or of the
flooded messages. If the document aims to provide the means for a developer to
build an implementation of HNCP, this could be problematic. Are these formats
going to be described elsewhere, or are they already described somewhere?

What happens if there are not enough prefixes to assign a prefix to each Link?
Is there still convergence? What is the failure mode here? RFC 7368 considers
this an ‘error’ mode that needs to be indicated to the user. Or would you state
an assumption of enough prefixes? Some brief explicit discussion of this, early
in the text, would be useful. At present it’s hinted at at the end of Section
4.2 and end of Section 6.

The Terminology section could precede the Introduction for clarity.

Specific comments:

Page 1:

What does “or for other private purposes?” mean in the abstract?

Perhaps the abstract can mention that the algorithm can support prefix
stability over reboot given the presence of stable storage.

What does ‘eventually converges’ mean?

Page 2:

Line 3 of introduction, ‘prefix’ rather than ‘prefixes’.

As a homenet draft, should ‘professionally managed networks’ be mentioned here?
 Maybe say “as well as other deployment scenarios”?

Page 3:

How is the flooding mechanism made reliable? Or is that down to the method of
implementation?

Page 6:

Is this really an applicability statement? I think of something more general
here, by default, which this isn’t.

Terms such as 'non-overlapping’ and ‘disjoint’ are used - perhaps be consistent.

Page 7:

At the top, perhaps also mention here that in the moment context ULA prefixes
might also be configured by this method, alongside globally unique prefixes.

As an aside - where a moment has two routers advertising a /48 ULA, can this
algorithm be used to pick only one to use, or would it by default create prefix
assignments on each Link for each 48?

Page 8:

The term ‘considered’ is introduced a little abruptly here in the first bullet
point of 4.1.

Page 9:

It may be better for ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY to be explained
earlier, rather than forward referenced to Section 7.

Page 10:

‘is not valid’ - maybe that should be ‘is not Valid’, matching the upper case
used in the terminology section?

Page 12:

So if the upstream ISP goes away, what happens? Do all Links become unnumbered
for global prefixes, continuing to use ULAs if configured? Some clarity here
would be nice.

Page 13:

For Randomness, is there a privacy aspect here, that a homenet or a network
using this algorithm may choose to randomise prefixes internally over time for
privacy reasons (ignoring the complexity that may be introduced elsewhere as a
result)? We have considered IID and link layer address randomisation elsewhere
recently; this could be argued as another tool in that toolbox. Though adding
such text with subsequent comments may lead to delays in publication :)

Page 16:

I don’t think the Node ID assignment mechanism has been described anywhere?

The security considerations do not hint at any solution for the noted threats.
There are of course comparative threats to similar algorithms.

Tim