IS-IS Extended Sequence Number TLV
draft-ietf-isis-extended-sequence-no-tlv-06

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

Alvaro Retana No Objection

Just a small formatting nit:  Sections 10 and 11 seem to be intended as appendixes, but show up as sections.

(Alia Atlas; former steering group member) Yes

(Barry Leiba; former steering group member) No Objection

With respect to keeping the ESSN increasing, you mention cold-starting the router... but what about when the router hardware is replaced?  The mechanism outlined in Section 10.1 should cover things there (just make sure that the old and new routers both have the time set correctly), but the mechanism in 10.2 won't.  Does this matter?  Or will the new router always have new keys, so it doesn't matter (I guess the last sentence in 10.2 covers that)?

As long as you call Sections 10 and 11 "Appendix", the RFC Editor will move them to the end and re-number them.  Please check in AUTH48 to be sure the forward references to Section 10 (in Sections 3 and 3.1) are correct.  Or perhaps just don't call those sections appendices.  It seems to me that they're useful enough and brief enough to be part of the document main.

(Ben Campbell; former steering group member) No Objection

-- Section 5, third paragraph:

Can you offer any guidance on timeliness? At least an order of magnitude?
.
Nits:

-- Please expand IS-IS on first mention in the body, even though you already did in the abstract.

-- Section 5, 2nd paragraph: "The implementation SHOULD also allow
   operators to control the configuration of ’send’ and/or ’verify’ the
   feature of IS-IS PDUs for the links and for the node."

I don't understand the sentence

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

(Deborah Brungard; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Kathleen Moriarty; former steering group member) No Objection

Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05560.html

(Martin Stiemerling; former steering group member) No Objection

(Spencer Dawkins; former steering group member) No Objection

(Stephen Farrell; former steering group member) No Objection

- last para of section 5 (before 5.1) could do
with a bit of a re-write, it's not very clear.

- section 7: When this mechanism is used, can an
attacker who can delete or re-order packets
(which is v. similar to one who can replay
packets) cause any new bad outcomes due to the
verification of the out-of-order arrival? (Sorry,
I don't know IS-IS enough to know the answer
there, it's probably obvious.) If so, then maybe
that argues that one ought note that this doesn't
address such threats (but that this is still I
guess worthwhile).

(Terry Manderson; former steering group member) No Objection