Skip to main content

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

Yes

(Alia Atlas)

No Objection

(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

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

Alia Atlas Former IESG member
Yes
Yes (for -05) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2015-04-17 for -05) Unknown
Just a small formatting nit:  Sections 10 and 11 seem to be intended as appendixes, but show up as sections.
Barry Leiba Former IESG member
No Objection
No Objection (2015-04-20 for -05) Unknown
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 IESG member
No Objection
No Objection (2015-04-20 for -05) Unknown
-- 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 IESG member
No Objection
No Objection (for -05) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-04-21 for -05) Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-04-21 for -05) Unknown
- 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 IESG member
No Objection
No Objection (for -05) Unknown