Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
draft-ietf-trill-clear-correct-06

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

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-07-30)
No email
send info
Thank you for addressing my concerns.

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-07-05 for -04)
No email
send info
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

(Stephen Farrell) No Objection

Comment (2012-06-19 for -03)
No email
send info
- 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.

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-06-14 for -03)
No email
send info
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?

(Pete Resnick) No Objection

Comment (2012-07-04 for -04)
No email
send info
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) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection