Received changes through RFC Editor sync (created alias RFC 7987, changed abstract to 'Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected.  In certain scenarios, this may cause or exacerbate flooding storms.  It is also a possible denial-of-service attack vector.  This document defines a backwards-compatible solution to this problem.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2016-10-19, changed IESG state to RFC Published)

[Ballot comment]
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…

[Ballot comment]
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?

[Ballot comment]
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

[Ballot comment]
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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-isis-remaining-lifetime-01.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: isis-wg@ietf.org, chopps@chopps.org, akatlas@gmail.com, "Christian Hopps" <chopps@chopps.org>, draft-ietf-isis-remaining-lifetime@ietf.org, isis-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-isis-remaining-lifetime-01.txt> (IS-IS Minimum Remaining Lifetime) to Proposed Standard


The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'IS-IS Minimum Remaining Lifetime'
  <draft-ietf-isis-remaining-lifetime-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Corruption of the Remainining Lifetime Field in a Link State PDU can
  go undetected.  In certain scenarios this may cause or exacerbate
  flooding storms.  It is also a possible denial of service attack
  vector.  This document defines a backwards compatible solution to
  this problem.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO Questionaire and Write-up for: draft-ietf-isis-remaining-life-01

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

Corruption of the Remainining Lifetime Field in a Link State PDU can
go undetected.  In certain scenarios this may cause or exacerbate
flooding storms.  It is also a possible denial of service attack
vector.  This document defines a backwards compatible solution to
this problem.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

Work progressed smoothly.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, Media
    Type or other expert review, what was its course (briefly)? In the case of a
    Media Type review, on what date was the request posted?

There is at least one implementation with others planned.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alia Atlas

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

This document has been reviewed by the Shepherd.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

No.

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

No.

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

Strong consensus in the WG.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this
        document. (See http://www.ietf.org/tools/idnits/ and the
        Internet-Drafts Checklist). Boilerplate checks are not enough; this
        check needs to be thorough.

No nits found.

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, media type, and URI type reviews.

N/A.

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

No.

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

No.

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not listed
        in the Abstract and Introduction, explain why, and point to the part of
        the document where the relationship of this document to the other RFCs
        is discussed. If this information is not in the document, explain why
        the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all protocol extensions that the document makes
        are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry, that
        allocations procedures for future registrations are defined, and a
        reasonable name for the new registry has been suggested (see RFC 5226).

No IANA considerations.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

None.

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

None.