IPv6 Backbone Router
draft-ietf-6lo-backbone-router-20
Yes
(Suresh Krishnan)
No Objection
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
Note: This ballot was opened for revision 16 and is now closed.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2020-03-21 for -19)
Sent for earlier
Thanks for addressing my DISCUSS points.
Éric Vyncke
No Objection
Comment
(2020-02-20 for -16)
Sent
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 IESG member
Yes
Yes
(for -16)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2020-02-19 for -16)
Not sent
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 IESG member
No Objection
No Objection
(2020-02-18 for -16)
Not sent
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 IESG member
No Objection
No Objection
(2020-02-19 for -16)
Sent
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?
Alvaro Retana Former IESG member
No Objection
No Objection
(2020-02-19 for -16)
Sent
This document should be tagged as replacing draft-thubert-6lo-backbone-router.
Barry Leiba Former IESG member
No Objection
No Objection
(2020-02-18 for -16)
Sent
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 IESG member
(was Discuss)
No Objection
No Objection
(2020-03-22 for -19)
Sent for earlier
Thank you for all the updates for my Discuss and Comment points!
Deborah Brungard Former IESG member
No Objection
No Objection
(for -16)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -16)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -16)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-02-19 for -16)
Sent
Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)!