IPv6 Backbone Router
draft-ietf-6lo-backbone-router-20

Thanks for addressing my DISCUSS points.

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"

Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

The introduction is hard to read for an non expert like me. It reads “blah blah ... excessive traffic generated, can be optimised”. I think it can be made shorter and crisper.

I'm curious if what is specified in this document affects any of the considerations discussed in RFC 8505 Section 8 about how addresses should be formed. RFC 8505 discourages the use of EUI-64 to form IIDs, while this spec seems to incentivize or at least make possible use cases where the 6LBR has to store MAC addresses in order to serve as a mapping server. Should this document discuss the privacy considerations associated with Bridging Proxy mode?

This document should be tagged as replacing draft-thubert-6lo-backbone-router.

For what it's worth, I disagree with my distinguished colleague from London: I find the extensive background given in the Introduction to be readable and useful.

Thank you for all the updates for my Discuss and Comment points!

Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)!