Subject: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-backbone-router-16: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 20 Feb 2020 05:07:18 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-backbone-router-16: 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-6lo-backbone-router/

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

Thank you for the work put into this document. It is really easy to read with
very nice ASCII art figures.

Nevertheless, please find below some non-blocking COMMENTs (and I would
appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
As my esteemed colleague from East US Coast, I liked the introduction but I
would prefer to have the EARO acronym expanded.

-- Section 2.3 --
I wonder whether using "6LBBR" would be more readable and consistent (with
"6LN" and "6LBR") than using "6BBR"

-- Section 3 --
Should the method to achieve "ensure that the Address is not duplicated over
the Backbone" be specified? E.g., DAD ?

-- Section 3.2 --
"The RS sent initially by the 6LN(STA) is transmitted as a multicast
   but since it is intercepted by the 6BBR, it is never effectively
   broadcast."
Perhaps worth mentioning "layer-3 multicast" hence "layer-2 broadcast"... And
"never... broadcast" it would important to mention the scope of the broadcast.
This ambiguity about layer & scope happens quite often in the document.
Knowledgeable readers will understand of course but what about less
knowledgeable ones?

== NITS ==

I found the use of acronyms a little too heavy, complicating the reading for
little benefits: e.g., ODAD = Optimistic DAD, SLLAO = Source LLA Option. On the
contrary, well-known acronyms are not used :-) E.g., multiple instance of "Link
Local addresses" rather than the well-known "LLA".

In the same vein, it is sometimes "Layer 2 Address" and other times "MAC
address"