IS-IS Multi-Instance
RFC 6822

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

(Stewart Bryant) Yes

(Adrian Farrel) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) (was Discuss) No Objection

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

That seems self-contradictory.  How about "Full specification of uses..."?

(Pete Resnick) No Objection

Comment (2012-09-23 for -07)
No email
send info
+1 to Barry's comment: Good usage of 2119. Just one comment along those lines:


   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.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection