IS-IS Multi-Instance
draft-ietf-isis-mi-08
Yes
(Adrian Farrel)
(Stewart Bryant)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -07)
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(for -07)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2012-09-18 for -07)
Unknown
A couple of non-blocking comments, which I'd like the authors to please consider (and chat with me about if it helps): You have isis-genapp as a normative reference, but the only citation of it is as an example use case in the introduction. Why is it normative? If it is, shouldn't there be a citation when the normative bit comes up later? -- Section 2 -- This MAY also imply IID/ITID specific routing calculations and IID/ITID specific routing and forwarding tables. However, this aspect is outside the scope of this specification. I think this is not a 2119 "MAY" (one huge clue is the second sentence). I suggest changing it to "might". Kudos on what seems to be very crisp use of 2119 language in the rest of the document. ----- And, finally a totally trivial point: the last paragraph of the introduction says this: The above are examples of how MI-IS-IS might be used. The specification of uses of MI-IS-IS is outside the scope of this document. That seems self-contradictory. How about "Full specification of uses..."?
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2012-09-23 for -07)
Unknown
+1 to Barry's comment: Good usage of 2119. Just one comment along those lines: 2.4: The following sub-sections describe the additional rules an MI-RTR MUST follow when establishing adjacencies. I think this might be confusing to implementers. The next subsections contain one "SHOULD NOT" and some other guidance, but it's not clear what protocol requirement (i.e., "MUST") an implementer is REQUIRED to follow. I suggest replacing the sentence with: The following sub-sections describe additional procedures to follow when an MI-RTR establishes adjacencies. There are a few instances of your caps-lock key getting stuck. :-) In 2.1, change "BE" to "be" in two places. In 2.6.2, change "NOT" to "not" in two places.
Ralph Droms Former IESG member
No Objection
No Objection
(for -07)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -07)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -07)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -07)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -07)
Unknown