IPv6 Backbone Router
draft-ietf-6lo-backbone-router-20
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
send info
Thanks for addressing my DISCUSS points.
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-03-22 for -19)
No email
send info
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
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
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, 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"