Subject: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-rfc6126bis-17: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 02 Jul 2020 09:50:09 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-babel-rfc6126bis-17: 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-babel-rfc6126bis/

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

My review is focusing mainly on the diff with RFC6126 for expediency.  The
technical material seems fine to me, so I just have some editorial nits to
offer:

Section 1.2:

* "The ability to build such heterogeneous networks makes Babel particularly
adapted to the unmanaged and wireless environment." -- The ending feels
awkward.  Maybe "to unmanaged, wireless environments"?  Or maybe "or" in
between?

Section 3:

* "... assigns host IDs, see the definition ..." -- comma splice; "see" should
begin a new sentence, or the comma should be a semi-colon

Section 3.1:

* "... in a previous TLV, (such as in ..." -- remove the comma

Section 3.2.1:

* "Given a seqno s and a non-negative integer n, the sum ..." -- It feels to me
as if things like "s" and "n" should be quoted when in prose.  I don't know
what the RFC Editor prefers, but I keep thinking this as I read through the
whole document; I hit it again in 3.5.2, for example.

Section 4.6.5:

* "neighbor" is spelled the American way here, but the British way everywhere
else.  Come to think of it, I think the RFC Editor standardizes on the former
(see RFC 7322) if you're not internally consistent.  So, if you like your "u"s,
don't give them this ammunition to change them.

Section 5:

* I suggest replacing with "IANA has {registered, created} ..." with "IANA
previously {registered, created} ..." to make it clear that the prior RFCs did
that work, and that they're simply being restated here and/or that this
document is assuming authority over them.

* The new registries feel like they're under-specified to me.  It's not clear,
for example, whether I could register bit 16 in the "Babel Hello Flags Values"
registry.  Maybe add a sentence making it explicit that registrations can only
be made from the "Unassigned" range?   Admittedly, this could be experience
bias on my part as I typically work with registries that cover unconstrained
namespaces, so I'm leaving this only as a comment.

Appendix G:

* Although it's possibly obvious and perhaps unnecessary, I suggest making it
explicit that this appendix is not intended to be published and can be removed
by the editor.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 5 Jul 2020 12:41:10 -0400

Hi Murray,

Thanks for your comments. See below.

My apologies for the delay in response. I am replying as the document
shephard.

On Thu, Jul 2, 2020 at 12:50 PM Murray Kucherawy via Datatracker <
[email-masked]> wrote:
> ...

I think changing "and" to "or" is reasonable. You don't need a network that
is both unmanaged and wireless for Babel to be well adapted.

> begin a new sentence, or the comma should be a semi-colon

I like semicolons; I think they are used too rarely.

> * "... in a previous TLV, (such as in ..." -- remove the comma

Removing the comma seems reasonable.

> whole document; I hit it again in 3.5.2, for example.

I understand your feeling but this would be a pretty massive change that no
one else has previously requested. Readers do not seem to have difficulty
understanding the document as it is in this regard. Perhaps we should wait
to see if the RFC Editor says anything.

> don't give them this ammunition to change them.

They should all be consistent.

> document is assuming authority over them.

Sorry, I don't actually see how what you suggest above changes anything.

> namespaces, so I'm leaving this only as a comment.

The range of bits available is determined by the field size so I don't
think any additional text is needed here.

> explicit that this appendix is not intended to be published and can be
removed

Sure, I think a line right after the Appendix section line saying

RFC Editor: Please delete this section before publication.

would do it.

Thanks again for the comment,
Donald [document shephard]
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]