[homenet] Alvaro Retana's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-homenet-babel-profile-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-babel-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?