Homenet Profile of the Babel Routing Protocol
draft-ietf-homenet-babel-profile-07

Please also see Tim Chown’s OpsDir review

Thanks for addressing my DISCUSS!  For reference, the discussion is here: https://mailarchive.ietf.org/arch/msg/homenet/A2PbWoYvxDbK0oqHFa_yPb80H9k 


I do have some non-blocking comments:

(1) I think that this document walks a fine line when Normatively referring to Appendix A in rfc6126bis given that it is an informative appendix.  In general, it does a good job at it -- I do, however, have one nit: "The algorithm described in Appendix A of RFC 6126bis MAY be used."  I think that changing that to something non-normative would be good, perhaps something like "Appendix A provides an example of an algorithm..." or simply s/MAY/may 

(2) This reminds me; please use rfc8174 template (for Normative language).

(3) The Non-requirements sections (2.2/3.2) are confusing to me.  Maybe it's the "negative logic"...

(3.1) What do these non-requirements represent?  Are they requirements that were considered at some point, but discarded?  Using rfc2119 language adds to the confusion -- consider describing these non-requirements not using it.

NR2, for example, is worded as a requirement that was considered, and the rationale explains why not: an "implementation of Babel MAY include support for other extensions"...this is not a requirement because "with the exception of source-specific routing, no extensions are required".  Ok.

(3.2) Are implementers to interpret that the converse is true/expected?  In the case of NR2, is a true interpretation that implementations SHOULD NOT include support for other extensions?  IOW, while the option of other extensions is not a requirement, is not having them one?

(3.3) The non-requirements in §3.2 seem a lot more confusing to me:

(3.3.1) NR3 -- The text says that the requirement not considered (non-requirement) is such that "an HNCP node that receives a DHCPv6 prefix delegation MAY announce a non-specific IPv6 default route", but the rationale says that "announcing an additional non-specific route is allowed".  I'm confused.  Is announcing the additional route ok, or not?  Is it ok to assume that optionally advertising the additional route is ok?  If it's allowed, then why is this a non-requirement?

(3.3.2) For NR4, is the non-requirement, i.e. one that was not considered, that the source-specific route SHOULD NOT be announced?  This piece is also confusing to me because the rationale says (at least the way I read it) that it may be ok to advertise.  It seems to me that the text is saying that in fact the route SHOULD NOT (or even MUST NOT be announced)...which brings me to the question: what is the requirement that was not considered?  What am I missing?

Some very minor comments:

Substantive Comments

§2.1, REQ5: I agree with Benjamin Kaduk that " MUST use metrics that are of
   a similar magnitude" is a bit vague to be used with a MUST.

Editorial Comments:

§1.1: Please consider using the 8174 boilerplate. There is at least one instance of a lower case keyword.

§2.2 and others: I find the term "non-requirements" confusing here. Please consider "Optional Requirements".

§3, first paragraph: "separates between configuration, which is done by HNCP, and routing, which is done by Babel": The word "between" does not belong.

Section 2.1

   REQ5: a Homenet implementation of Babel MUST use metrics that are of
   a similar magnitude to the values suggested in Appendix A of
   RFC 6126bis.

"MUST" and "similar magnitude" are not a great pairing.

I agree with the secdir reviewer that the link classification is
important, and would suggest a that SHOULD become MUST for "if it is
unable to determine whether a link is wired or wireless, it MUST
make the worst-case hypothesis".

Section 4

I always worry a little bit about the ability to classify links as 
"trusted", but there are probably cases where it's valid to do so. 
(Whether there are enough cases where it's valid to do so that would
provide enough use cases for this document perhaps will need to wait
for deployment experience.)

I do wonder whether it's worth enumerating the "upper-layer security
protocol"s that HNCP and Babel support, as there are tradeoffs among
the PSK/PKI/TOFU options that the implementor may need to consider.

Support Alvaro's Discuss and comments. I also found the language/wording used for the non-requirements to be especially confusing.

A nit comment on the metrics of the similar magnitude - there may be lessons learned from ISIS and wide style metrics as the current metric name space is quite narrow.

Hello,
you should refer to 8174.

Just as a side note, you need to make sure that all occurances of RFC 6126bis will be replaced with the new RFC by the RFC Editor before publication.