IPv6 Backbone Router
RFC 8929
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
Alvaro Retana No Objection
This document should be tagged as replacing draft-thubert-6lo-backbone-router.
Roman Danyliw (was Discuss) No Objection
Thanks for addressing my DISCUSS points.
Éric Vyncke No Objection
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"
(Suresh Krishnan; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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.
(Alexey Melnikov; former steering group member) No Objection
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.
(Alissa Cooper; former steering group member) No Objection
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?
(Barry Leiba; former steering group member) No Objection
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.
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for all the updates for my Discuss and Comment points!
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)!