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

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 20 February 2020 13:07 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-backbone-router@ietf.org, Carles Gomez <carlesgo@entel.upc.edu>, Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, shwethab@cisco.com, 6lo@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <158220403895.12513.15734968369539084290.idtracker@ietfa.amsl.com>
Date: Thu, 20 Feb 2020 05:07:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/yUT629NTnpM3qCbcv0wc8sYqzs0>
Subject: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-backbone-router-16: (with COMMENT)

É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"

[6lo] Éric Vyncke's No Objection on draft-ietf-6l… Éric Vyncke via Datatracker