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