[homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

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

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to DISCUSS about the Intended Status of this document -- with the
Chairs and AD.

I have to confess that I haven't been following the homenet WG as closely as I
probably should have.  Hopefully that means that the topic below has been
discussed and documented already, making this DISCUSS easy to resolve.

Back in 2015, the then-Chairs and the AD posted a note titled "Routing Design
Team outcome and next steps"[1]; in it, they declared "rough consensus that
Babel[*] shall be the “mandatory to implement” routing protocol for Homenet
routers, albeit only on an Experimental basis at this time...we solicit
Experimental Internet Drafts to document Homenet-specific profiles of any
applicable routing solution and to report results of any relevant
experimentation and implementation.  We expect that this decision will be
revisited in a future Standards Track document based on specifications and
running code available at that time."

My interpretation of the above text is that Babel is MTI, but that the work
(documents) will be Experimental...and that this decision could change in the
future (most likely towards confirming and moving to the Standards Track). 
This document was originally adopted as Experimental.  I didn't find an
explicit discussion on the list about changing that original overall direction,
nor another declaration by the Chairs/AD.  I did find find a thread in which
one of the Chairs (Barbara) asked about the status for this document (and this
document only)[2]; the initial question was framed around the references being
Standards Track documents (HNCP and rfc6126bis) -- just one answer came back
(from the author of this document)...

I'm treating this point as a DISCUSS because I think that the WG consensus may
have not been determined to change the original declaration from the Chairs/AD
(from 2015).  In my interpretation of that original declaration, moving Babel
to the Standards Track means a recognition that it will be *the* protocol going
forward (which changes that initial "only on an Experimental basis at this
time" phrase), is something that should be discussed explicitly, and not just
in light of this one document.  That is the part that I haven't seen.

I note that in the conclusion of the thread about the status of this document
[3] Barbara does include reasoning that may result in changing the original
declaration (as does the Shepherd writeup), for example: "there exist multiple,
interoperable implementations" and "no drafts proposing other homenet routing
protocol profiles have been submitted"...but those points don't seem to have
been considered/discussed by the WG (they were not in the original message and
I didn't find another thread -- I also looked at the minutes of the last couple
of IETF meetings).

To be clear, I have no objection with Babel being used in homenet applications,
or with it being the Standard protocol.  My point here is that it is not clear
to me that the WG explicitly reached consensus to change the declaration from
the Chairs/AD.  I will be happy to clear this DISCUSS when the Chairs/AD point
me to the discussion that I missed, or simply tell me that the declaration from
2015 is no longer valid and that the WG knows, or that they believe that the
thread discussing this document is enough to call consensus...or something to
that effect.

[1] https://mailarchive.ietf.org/arch/msg/homenet/kiI7pIYfpgT2Qrfx1VBAwng7_QY
[2] https://mailarchive.ietf.org/arch/msg/homenet/5L5WYN14gDCamP7qlknJmWkeU5M
[3] https://mailarchive.ietf.org/arch/msg/homenet/35EU8oBr8hunvvSRYUStypZIPVU


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

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