IS-IS Minimum Remaining Lifetime
RFC 7987

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

(Alia Atlas) Yes

(Jari Arkko) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2016-08-16 for -03)
No email
send info
I have just a few minor comments:

- 1, 2nd paragraph: "... the checksum
   field MUST NOT be altered..."

That sounds more like a statement of fact than a normative requirement.

-1, paragraph 4: 

I’m no expert here, but are where the originator might want to let the LSP expire before it becomes unreachable? (e.g. during a graceful shutdown?) 

-2, 4th paragraph from end: "An additional
   action is added:
This document adds the additional action, or ISO10589 adds it?

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Joel Jaeggli) No Objection

Comment (2016-08-16 for -03)
No email
send info
Tim Wicinski, performed the opsdir review, some nits that I haven't seen comment on yet.


I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments
just like any other last call comments.

Document Reviewed:   draft-ietf-isis-remaining-lifetime-02

Status: Ready with nits

Spelling Nits:

   "Corruption of the Remainining Lifetime Field"


2 (vi):

   not result in LSPDB inconsistency among routers in the newtork.


   vi.  If the RemainingLifetime of the new LSP is less than MaxAge it
   is set to MaxAge

Period at end of sentence

It appears that you interchange 'Remaining Lifetime' and 'RemainingLifetime' (14 for the former, 19 for the latter).
I could not understand the pattern.  Was this intentional?


OPS-DIR mailing list

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2016-08-15 for -03)
No email
send info
Two small comments:
1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that would be helpful!
2) You write:
„Retention of stale LSPs therefore has no negative side effects other than requiring additional memory for the LSPDB.“
 -> Can this lead to a memory exhaustion attack instead? Should this be discussed in the security section?

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2016-08-16 for -03)
No email
send info
I have some comments related to the normative language in the document (and some other minor points later) — they don't raise to the level of a DISCUSS, but I would like to see them addressed before publication.

1. There are several parts of the text where statements of fact, or normative requirements from other documents are reflected using rfc2119 language.  I think that use of rfc2119 is inappropriate and (in the case of references to ISO10589) inaccurate [*].  Please find a way to reflect the requirements without using rfc2119 language.  These are the pieces of text I'm referring to:

a. Section 1. (Problem Statement):  "…as the checksum field MUST NOT be altered…" 
b. Section 2. (Solution): "[ISO10589] specifies that maximumLSPGenerationInterval MUST be…"
c. Section 2. (Solution):  "The pseudo-node LSPs generated by the previous DIS are no longer required and MAY be purged by the new DIS."   d. Section 3.3. (Impact of Delayed LSP Purging): "LSPs from a node which is unreachable (failure of the two-way-connectivity check) MUST NOT be used."

2. In Section 3.1. (Inconsistent Values for MaxAge): "Implementors of this extension MAY wish.."  Note that the "MAY" is modifying "wish", which is meaningless when talking about normative language.  Suggestion:  simply s/MAY/may   The "MUST" in the following sentence is enough.

3. In Section 3.2. (Reporting Corrupted Lifetime): "…an implementation MAY wish to retain the value of RemainingLifetime received…"  Similar to the previous comment; in this case the "MAY" is not even necessary because the behavior (to retain) is not needed for interoperability.  If you want to keep it, s/MAY wish to retain/MAY retain

4. There are several instances of "RemainingLifetime" -- that is fine, but you seem to be inconsistent with "Remaining Lifetime".  And there's even one "Lifetime" by itself…

5. s/w/with (Section 2).

[*] I haven't read ISO10598 in a while, but I'm pretty sure it doesn't use rfc2119 language…