IPv6 Backbone Router

Note: This ballot was opened for revision 16 and is now closed.

(Suresh Krishnan) Yes

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Comment (2020-02-19 for -16)
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?

Roman Danyliw (was Discuss) No Objection

Comment (2020-03-21 for -19)
No email
send info
Thanks for addressing my DISCUSS points.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-03-22 for -19)
No email
send info
Thank you for all the updates for my Discuss and Comment points!

(Mirja Kühlewind) No Objection

Comment (2020-02-19 for -16)
Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)!

(Barry Leiba) No Objection

Comment (2020-02-18 for -16)
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.

(Alexey Melnikov) No Objection

Comment (2020-02-18 for -16)
No email
send info
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.

Alvaro Retana No Objection

Comment (2020-02-19 for -16)
This document should be tagged as replacing draft-thubert-6lo-backbone-router.

(Adam Roach) No Objection

Comment (2020-02-19 for -16)
No email
send info
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.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-02-20 for -16)
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,




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

(Magnus Westerlund) No Objection