IS-IS Minimum Remaining Lifetime
draft-ietf-isis-remaining-lifetime-04

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…

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?

Tim Wicinski, tjw.ietf@gmail.com performed the opsdir review, some nits that I haven't seen comment on yet.


Hi

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:

Abstract:
   "Corruption of the Remainining Lifetime Field"

*Remaining*

2 (vi):

   not result in LSPDB inconsistency among routers in the newtork.

*network*

(vi):
   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?

tim

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

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?