Subject: [Isis-wg] Barry Leiba's No Objection on draft-ietf-isis-extended-sequence-no-tlv-05: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 20 Apr 2015 14:15:24 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-isis-extended-sequence-no-tlv-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-isis-extended-sequence-no-tlv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 21 Apr 2015 15:59:46 +0000

Hi Barry,

Thank you for your review, please see in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Barry Leiba [mailto:[email-masked]] 
Sent: Monday, April 20, 2015 2:15 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Barry Leiba's No Objection on draft-ietf-isis-extended-sequence-no-tlv-05: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

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),
[Uma]: Right, 10.1 should cover this. As specified in 10.1, 2nd paragraph".. especially after cold
   restarts or any other similar events."
Did I answer your question?

 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)?
[Uma]: Yes, changing keys is the last resort, per 10.2 -
" If the non-volatile
   storage is ever repaired or upgraded such that the contents are lost,
   keys MUST be changed to prevent replay attacks."

FWIW, I can change "upgraded" to "router hardware is upgraded"!

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.

[Uma]: Thank you and (Alvaro too) for pointing out this. I shall remove the section numbering and update the references to point to correct Appendix.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2015 12:11:48 -0400

Hi, Uma, and thanks for the response.

>> the router... but what about when the router hardware is replaced?
...
> [Uma]: Right, 10.1 should cover this. As specified in 10.1, 2nd paragraph
> ".. especially after cold restarts or any other similar events."
...
> FWIW, I can change "upgraded" to "router hardware is upgraded"!

Thanks.  I was just "thinking out loud", and I do see that
everything's covered.  If you think adding "router hardware" is
useful, go ahead and add it... but I'm satisfied with it as it is.

Barry