Distributed Prefix Assignment Algorithm
draft-ietf-homenet-prefix-assignment-08

[Ballot discuss]
Updated position based on feedback from Int-Dir review (Suresh Krishnan)...

I don't object to the publication of this document, but there are some issues that need to be remedied.

1. Section 5 provides the considerations for selecting prefixes. However, those considerations are incomplete. RFC 7421 provides the analysis for the use of the /64 boundary.  The Homenet Architecture (RFC 7368) discusses various Homenet-related issues around not getting sufficient address space to allocate /64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on point-to-point links. Why does this section not mention any of these considerations when selecting a prefix?

2. I am raising Alvaro's point about the impact of topology changes to a DISCUSS.  I think there needs to be sufficient discussion in the document on the impact of topology changes on the prefix assignment algorithm and the impact of changing prefix assignments on nodes in the network. This ties in to the point raised by Brian Carpenter on the claim in the Introduction that this algorithm can be used in "fully autonomic as well as professionally managed networks". This is especially true when convergence is described as occurring "eventually".

3. I understand that this document became standalone when the HNCP and DNCP documents split. What dependencies/assumptions does this document have on either one of them?  There appears to be some assumptions on the Node ID and the flood algorithm.

4. How does the algorithm deal with prefix delegations that have holes (e.g. RFC6603)? This text seems to preclude such delegations.

5. Section 6 discusses Listener nodes. Does there need to be some discussion/warning about links that consist of all Listeners?  The link will not get a prefix assigned to it in such a situation.

6. How does this approach deal with asynchronous link state changes?

[Ballot comment]
* ID-nits complains about the malformed 2119 keywords text in the Terminology section.  It would be good to use the entire boilerplate for the 2119 keywords.

* The terminology section claims that the definitions are ordered to avoid forward reference, but that is not the case. For example, Link refers to Shared Link and Private Link, Delegated Prefix refers to Assigned Prefix, etc.

* The definition of Node ID is unclear. What do you mean by "The set of identifiers MUST be strictly and totally ordered". A node id is a single identifier, right?

[Ballot comment]
Tim Chown did the opsdir review. I think some of the criticism is well take and it looks like discussion is ongoing to address it.

I think brians discuss and the outstanding comments are sufficient to address it.

Tim's review follows


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



_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

[Ballot comment]
I agree with Alvaro and Brian on the need to clarify topology changes.  In Sec 3, I see
"  The algorithm supports dynamically changing topologies:

  o  Nodes may join or leave the set of participating Nodes.

  o  Nodes may join or leave Links.

  o  Links may be joined or split."

and what isn't clearly stated is that when a link fails (partially or fully) or comes into existence ,
is that a topology change?

For instance, if a link fails, surely that shouldn't be a topology change for the prefix assignment,
but rather a matter for routing to handle.  I do see in Sec 4.3 "When a Link is removed, all Assigned Prefixes
assigned to that Link MUST be destroyed."  Perhaps a link removal isn't considered a topology change in this
context because it doesn't cause renumbering??

How is a new Link added to be considered?  How does a router know that its end of a link is the
same link as on another router?  How is a link "removed" versus merely down?

An assumption seems to be that the flooding mechanism can work without any prefix numbering.  That's fine but
would be good to state.  I'm a bit twitchy about the bootstrapping.

[Ballot comment]
I support Brian's second Discuss point (on the text raised by Brian Carpenter).

I believe I'm seeing changes to address that. Thank you in advance.

[Ballot comment]

- section 3: I expected some security text here, not to say that
this all needs to be encrypted but rather to say that because
this is flooding, you can't really encrypt it and that hence
this scheme is only suited for smaller deployments and/or those
with lower layer security already in place. (And hence also
probably small.)

- section 3: Similarly, you could also add some privacy text to
the effect that this scheme only applies where the privacy
characteristics of the various prefixes involved are all
roughtly similar, that is, where there's no real privacy
difference in which prefixes end up with which nodes. (Mind you,
I need to ponder that a bit myself to see if it's really the
case;-)

- sections 4 & 5: I found this impossible to understand in a
(quick) linear reading. I'd find actual code easier tbh. It's
interesting that Barry found this clear though (I did not,
clearly:-) so this isn't a discuss. But why didn't you first
provide an overview of the algorithm?

- Where is the evidence that the algorithm converges? I'd have
thought there would be a reference to an academic publication
that also described the algorithm and a proof for convergence.

[Ballot discuss]
I don't object to the publication of this document, but there are some issues that need to be remedied.

1. Section 5 provides the considerations for selecting prefixes. However, those considerations are incomplete. RFC 7421 provides the analysis for the use of the /64 boundary.  The Homenet Architecture (RFC 7368) discusses various Homenet-related issues around not getting sufficient address space to allocate /64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on point-to-point links. Why does this section not mention any of these considerations when selecting a prefix?

2. I am raising Alvaro's point about the impact of topology changes to a DISCUSS.  I think there needs to be sufficient discussion in the document on the impact of topology changes on the prefix assignment algorithm and the impact of changing prefix assignments on nodes in the network. This ties in to the point raised by Brian Carpenter on the claim in the Introduction that this algorithm can be used in "fully autonomic as well as professionally managed networks". This is especially true when convergence is described as occurring "eventually".

3. I understand that this document became standalone when the HNCP and DNCP documents split. What dependencies/assumptions does this document have on either one of them?  There appears to be some assumptions on the Node ID and the flood algorithm.

[Ballot comment]
* ID-nits complains about the malformed 2119 keywords text in the Terminology section.  It would be good to use the entire boilerplate for the 2119 keywords.

* The terminology section claims that the definitions are ordered to avoid forward reference, but that is not the case. For example, Link refers to Shared Link and Private Link, Delegated Prefix refers to Assigned Prefix, etc.

[Ballot comment]
I don’t object to the publication of this document, but I do have several comments that I think should help in making it clearer.

Comments:

(1) Topology Changes.  The Introduction reads: "Assigned prefixes do not change in the absence of topology or configuration changes. . .the algorithm also ensures that all assigned prefixes. . .remain unchanged, unless. . .the topology changes and renumbering cannot be avoided.”  But later in Section 3. (Applicability Statement) you wrote that the "algorithm supports dynamically changing topologies”. 

What are then topology changes that may result in renumbering being unavoidable?


(2) To Destroy.  The term “destroy” is used in several places, but it is not defined in Section 2.  It looks like Section 4.2. (Overriding and Destroying Existing Assignments) might define it, but instead it uses “destroy” to to define “Removing an Assigned Prefix”.  Destroy seems to be the local action that may result in removing a Published Assigned Prefix.  Please add to the terminology.


(3) Unique Node IDs.  Having unique Node IDs is important to break ties in the algorithm.  However, the text seems to allow the existence of duplicate IDs for some (undefined) period of time.  Section 3. (Applicability Statement) reads: "Node IDs MAY change over time and be the same on multiple Nodes at some point, but each Node MUST eventually have a Node ID which is unique among the set of participating Nodes.”  How long is “eventually”?  The sentence is (at best) confusing, but it reads as contradicting to me: If multiple Nodes can have the same ID, how can the MUST be enforced?  You mention in the Security Considerations section that an “attacker. . .using a Node ID used by another Node may prevent the correctness and convergence of the algorithm. . .”  Allowing for multiple Nodes to have the same ID is then an attack for however long “eventually” is.

The same type of language (“eventually” and “at some point”) is used on other places.  It would be nice to tighten the text up (where appropriate); for example, the part about “Each Node MUST have a set of non-overlapping Delegated Prefixes..” seems to be ok as it doesn’t mention that at some point the Delegated Prefixes may overlap, just that the sets may not be the same.


(4) How is a Node ID defined?  What I mean is: is it a number, a string, whatever?  It sounds like the specific definition may be left to the Flooding Mechanism, is that true?  If so, then I think it would be a good idea to call it out — this also means that as an operator I may have to redefine my Node ID assignment mechanism if I decide to change the Flooding Mechanism.  The ordering of the Node IDs will also depend on how they are defined.

BTW, “Node ID assignment mechanism” is mentioned in the Security Considerations, but not defined anywhere.  It may of course not be an in-the-network mechanism and simply a manual assignment of IDs — it would be nice to say something about what it is (or may be).


Nits:

(A) Consistency in naming. 

For example: “Available prefix” is defined, but later “available prefix” is used (I think) to refer to the same thing.  Given that common words are used (Available, Valid, etc.) it is important to differentiate when the specific term is used vs just the generic use of the word.

Precedence is defined in Section 2.1, but later not used in Section 4.  That is ok (except for the text in Section 4 that calls it out) given that it looks like the term is used when defining Best Assignment and Valid — I say it "looks like it" because “precedence” (not “Precedence”) is used.  Should it be “Precedence”?

Valid (capital V) is also defined but not used later.  There are a couple of places where maybe “Valid” should replace “valid”.


(B) Section 2. (Terminology)  In the definition of “Private Link”, I think the “MAY” should really be “may”.  There’s nothing normative about the example.


(C) s/received from the Flooding Mechanism/received through the Flooding Mechanism

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed  draft-ietf-homenet-prefix-assignment-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributed Prefix Assignment Algorithm) to Proposed Standard


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document:
- 'Distributed Prefix Assignment Algorithm'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a distributed algorithm for automatic prefix
  assignment.  Given a set of delegated prefixes, it ensures that at
  most one prefix is assigned from each delegated prefix to each link.
  Nodes may assign available prefixes to the links they are directly
  connected to, or for other private purposes.  The algorithm
  eventually converges and ensures that all assigned prefixes do not
  overlap.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is a product of the IETF Homenet Working Group. It is intended to be used as a normative reference by other network protocols, some likely to be Standards Track, which require this type of algorithm. Yes, the “Intended Status” in the RFC header is “Proposed Standard.”

(2) 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 specifies a distributed algorithm for prefix assignment within a site. While developed primarily for IPv6, it is generic enough to be used for any prefix-based numbering space such as IPv4. In order to run, the algorithm requires that participating nodes share information through a flooding mechanism of some kind.  If the flooding mechanism ensures that all messages are propagated to all nodes faster than a given timing upper bound, the algorithm also ensures that all assigned prefixes used for networking operations (e.g., host configuration) remain unchanged, unless another node assigns an overlapping prefix with a higher assignment priority, or the topology changes and renumbering cannot be avoided.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This algorithm began as an extension to OSPF as, at the time, the Homenet WG was heading down the path of using OSPF as a monolithic home network routing and configuration protocol. There was strong consensus against using OSPF in this manner in the WG, leading to the the standalone prefix-assignment document. As a modular piece of work, the algorithm has now been applied to OSPF, IS-IS, and HNCP.

RFC 7503 includes this text:

  “This new LSA is designated for information related to OSPFv3
  autoconfiguration and, in the future, could be used for other
  autoconfiguration information, e.g., global IPv6 prefixes.  However,
  this is beyond the scope of this document.”

While this document is not referenced directly above, the work in this document is what was in mind when RFC 7503 was written.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Open source implementation: http://github.com/sbyx/hnetd,

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Mark Townsley, Terry Manderson

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Mark Townsley reviewed this document. The document is ready for advancement.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

Since the split from OSPF, the document was used for implementation and received at least four in-depth reviews (Jiazi Ji, Markus Stenberg, Steven Barth, Benjamin Patterson, etc…)

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There are no “bits on the wire” aspects defined in this document for review. However, algorithm correctness is very important. In addition to implementation and testing, correctness was determined as part of an academic paper and formal proof by Benjamin Paterson in 2012 (available upon request, albeit not yet formally published outside of the university system where it was submitted).

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Email has been sent (April 17, 2015) to all authors from chairs asking for formal yes/no for this question.

2015/04/20 - confirmation received from Pierre and Benjamin - still waiting for Jari!

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.

(9) 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? 

Whilst the subject material is not necessarily understood in detail by a large proportion of the WG participants, there is a substantive core that has reviewed this document without dissent.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No, not that we are aware of.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Yes, there is one warning in the current version that MAY need to be addressed:

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords.

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Only normative reference is BCP so, no.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA actions required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is a product of the IETF Homenet Working Group. It is intended to be used as a normative reference by other network protocols, some likely to be Standards Track, which require this type of algorithm. Yes, the “Intended Status” in the RFC header is “Proposed Standard.”

(2) 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 specifies a distributed algorithm for prefix assignment within a site. While developed primarily for IPv6, it is generic enough to be used for any prefix-based numbering space such as IPv4. In order to run, the algorithm requires that participating nodes share information through a flooding mechanism of some kind.  If the flooding mechanism ensures that all messages are propagated to all nodes faster than a given timing upper bound, the algorithm also ensures that all assigned prefixes used for networking operations (e.g., host configuration) remain unchanged, unless another node assigns an overlapping prefix with a higher assignment priority, or the topology changes and renumbering cannot be avoided.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This algorithm began as an extension to OSPF as, at the time, the Homenet WG was heading down the path of using OSPF as a monolithic home network routing and configuration protocol. There was strong consensus against using OSPF in this manner in the WG, leading to the the standalone prefix-assignment document. As a modular piece of work, the algorithm has now been applied to OSPF, IS-IS, and HNCP.

RFC 7503 includes this text:

  “This new LSA is designated for information related to OSPFv3
  autoconfiguration and, in the future, could be used for other
  autoconfiguration information, e.g., global IPv6 prefixes.  However,
  this is beyond the scope of this document.”

While this document is not referenced directly above, the work in this document is what was in mind when RFC 7503 was written.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Open source implementation: http://github.com/sbyx/hnetd,

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Mark Townsley, Terry Manderson

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Mark Townsley reviewed this document. The document is ready for advancement.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

Since the split from OSPF, the document was used for implementation and received at least four in-depth reviews (Jiazi Ji, Markus Stenberg, Steven Barth, Benjamin Patterson, etc…)

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There are no “bits on the wire” aspects defined in this document for review. However, algorithm correctness is very important. In addition to implementation and testing, correctness was determined as part of an academic paper and formal proof by Benjamin Paterson in 2012 (available upon request, albeit not yet formally published outside of the university system where it was submitted).

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Email has been sent (April 17, 2015) to all authors from chairs asking for formal yes/no for this question.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.

(9) 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? 

Whilst the subject material is not necessarily understood in detail by a large proportion of the WG participants, there is a substantive core that has reviewed this document without dissent.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No, not that we are aware of.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Yes, there is one warning in the current version that MAY need to be addressed:

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords.

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Only normative reference is BCP so, no.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA actions required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A