Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
RFC 7180
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Ralph Droms; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
Section 1.2 is a useful section to have at the top of the document. I would have liked it more had it: - listed each non-backward compatible feature (with a section reference) instead of saying "several" - explained in summary how non-compatiblity is handle in general
(Barry Leiba; former steering group member) No Objection
As this document incorporates errata reported against the other three RFCs, but leaves those three current (not Obsoleted), it would be nice to list the RFC-numbers+errata-numbers that are resolved by this document. How hard would that be to add?
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
This is strictly a procedural point for the chair/shepherd; The authors may ignore this. The ballot writeup makes me very grumpy and it makes me concerned that the chair/shepherd did not do their due diligence in passing this document to the IESG. The chair/shepherd being a former AD, I have to assume that this was just a sloppy writeup and not a real problem. But I would like to see a real writeup for the record. I did not make this a DISCUSS since I am sure this COMMENT will generate the right outcome. The writeup template says for "Working Group Summary": Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Your response was: There was consensus in the working group in favor of the document. That's all you're going to say? Perhaps you'd like to add, "Unlike every other document which has gotten serious review in the IETF, this one generated no controversy at all and there were no points of contention. At the end of each face-to-face meeting, the entire WG held hands and sang songs together." :-) Seriously, we all assume there was consensus since you are submitting the document; you would not have submitted it otherwise. To make sure that due diligence was done, the answer the IESG is interested in is what the nature of the consensus was. At the very least say, "There was nothing particularly noteworthy about the consensus around this document. In the end, there was no roughness apparent for any part of the consensus." At least then we could see that you answered the question. Then in the "Document Quality", it asks: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Your answer was: The document has been carefully reviewed in the WG and by the document shepherd. The document was forwarded to the IS-IS WG mailing list, which resulted in some additional improvements. First of all, the document itself says that it is making non-backward-compatible changes to a protocol. I would *hope* that there is a fair bit of implementation of the new stuff already that would justify such changes. But you mention no existing implementations, nor any indication of vendors taking on such implementations, in your writeup. And as far as "reviewers that merit special mention", you call out "the WG and the document shepherd". If the WG and the document shepherd *hadn't* done thorough reviews, that would be worthy of mention; that they have done their jobs is not. (On the other hand, the IS-IS WG *is* worthy of mention.) This document is outside of my area of expertise. The only serious review I do is look through the document for Applications impacts and look to the writeup to see that no procedural nonsense was missed. This writeup is a pretty serious miss. Please give at least some indication on the implementation question.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- typo in abstract: s/provide/provides/ (same sentence is correct in intro:-) - 2nd para of section 5 is odd, it says its about the case where nothing is known, but then says "if it is known that other..." I'd say replacing the opening phrase with some more specific might work, e.g. "If not all MTU information is known for the entire campus..." - 10.1: "...in the Down state out a port..." is an odd phrase, maybe s/out/for/ or something? - 10.1: What is a DRB? - 10.2: I think this needs rephrasing/fixing: "Therefore, the DRB SHOULD NOT appointed an RBridge in overload as Appointed Forwarder for an VLAN unless there is no alternative." I'm not sure what it means really.
(Stewart Bryant; former steering group member) (was Discuss) No Objection
Thank you for addressing my concerns.
(Wesley Eddy; former steering group member) No Objection