Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-09

[Ballot discuss]
Section 3.2 notes that "the presence of [the Restart] TLV indicates that
the sender supports the functionality defined in this document".  But,
while that was true for RFC 5306, I don't see how it can be true for the
extended functionality that's new in this document.  It seems on first
look that the need for a PR to be acknowledged by a PA means that the
routers in question will be able to properly determine full feature
support at runtime, in which case this is essentially an editorial
issue, but I would like to make sure it's received enough thought, so am
raising it as a Discuss point to get the needed discussion.
(We will still need to change this text to reflect reality, though.)
It's also unclear to me if we need to give more description of the
behavior when a router planning to restart does not receive (all) the
necessary PAs -- does it cancel the planned restart?  Fall back to the
regular RR usage?

It looks like there's an internal inconsistency between Section 3.2
("[w]hen transmitting a TLV multiple flags MUST NOT be set.") and
Section 3.3.2 ("the IIH is retransmitted with both RR and SA bits set").

[Ballot comment]
Abstract

Four paragraphs is perhaps pushing it a bit, for RFC style.  It might
also be nice to avoid starting two sentences with "This document
additionally describes", e.g., as Barry suggests.

It also seems a little mismatched to me to differentiate between
"restart while maintaining forwarding plane state" and "restarting",
since in Section 2 we make the convention that "restarting" means that
forwarding state is maintained definitionally.

Section 1

  In the case of a restarting router process, the first of these is
  highly undesirable, but the second is essential in order to ensure
  synchronization of the LSP database.

Is the convention introduced in section 2 about preserving forarding
state intended to apply here?

Section 3.2.3

  Neighbors of the router which has signaled planned restart SHOULD
  maintain the adjacency in a planned restart state until it receives
  an IIH with the RR bit set, receives an IIH with both PR and RR bits
  clear, or the adjacency holding time expires - whichever occurs
  first.

When might a router want to ignore the SHOULD (and how so)?

  c.  on a Point-to-Point circuit, transmission of LSPs, CSNPs, and
      PSNPs MAY be suppressed.  It is expected that the PDUs will not
      be received.

Are there any security considerations here (e.g., a spoofed PR flag
would cause suppression of updates and potentially DoS)?

Section 4.1

I'm a little surprised to see "RX PA" under the "Running Router" table,
since I thought the "running" categorization was supposed to imply that
it was not going to restart (which would be a "restarting router").  If
the categorizations are exclusive, then receiving PA would be an error
condition.

Section 6

I think we should go a bit further about the false-IIH with PR bit set,
since there is not a protocol mechanism to apply any sanity check to the
hold time that the recipient is obligated to apply (overriding local
policy).  Such spoofed values could be unreasonably large, and it may be
prudent to have a policy filter that rejects implausible values.
Even if such a policy is present, it seems that a series of spoofed IIHs
with PR set could force an adjacency to be maintained (absent topology
changes), by cancelling the PR-bit and then sending a new PR-bit in
quick succession.

Relatedly, Section 3.2.1's description of the RR/RA bits notes that:
      "This procedure allows the restarting router to cause the neighbor
      to maintain the adjacency long enough for restart to successfully
      complete, while also preventing repetitive restarts from
      maintaining an adjacency indefinitely."
It doesn't seem that this property (preventing repetitive restarts from
maintaining an adjacency indefinitely) still holds for PR/PA with a
neighbor router that is (mis)behaving in a certain way.  Explicitly
noting this disparity seems reasonable to me.

[Ballot comment]
(1) Section 3.1.  The two “NOTE” statements in this section seem to conflict:
-- NOTE: These timers are NOT applicable to a router which is preparing to do a planned restart.

-- NOTE: The timer T3 is only used by a restarting router.

(2) Per the definition of the “Remaining Time” field, when is it the “remaining holding time” vs. “recommended holding time"

(3) Editorial Nits:
-- Multiple places.  s/signalling/signaling/g

[Ballot comment]
Hello,

thank you for this document.
What is the expected behaviour, if any needing to be described, when the neighbor of a router planning to restart decides to also plan a restart?

Thank you

[Ballot comment]
Thank you for writing / updating this, it's really useful.


I do have some comments though:
1: "2.  It sets SRMflags on its own LSP database on the adjacency concerned."
There are a number of instances throughout this document where acronyms / terms are used without expansion - this being just one instance. I think that the right reference here is RFC1142, but it sure would make reading the doc easier if these were cited / expanded. I get that this is a -bis, so perhaps just a "Familiarity with IS-IS and RFC 1142, ... ... is assumed"?

2: Section 3.1.  Timers
"A typical value is 3 seconds." -- for this, and other timers, you list a "typical" value - typical implies "not universal / fixed", so *who* should be twiddling it? Is it defined to be 3? Should vendors choose the right number or should this be user configurable (I assume the latter, but...)

3: I'm assuming I'm missing something really obvious here, but:
"The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set." -- and then what / why? Let's say I'm a restarting router, and I ** don't ** get a receipt from a neighbor, does that mean I hold off on restarting? Do I resend until I *do* get a RA response?

4: "... the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network."
No action needed, I just wanted to mention that I really liked the use of "incarnation" here. I'm not sure if this came from the original or -bis, but it was good...

5: "NOTE: Receipt of an IIH with PA bit set indicates to the router planning a restart that the neighbor is aware of the planned restart  and - in the absence of topology changes as described below - will maintain the adjacency for the "remaining time" included in the IIH with PA set." -- Sounds good, but as I understand it, Remaining Time can be up to 65535 seconds -- this is (I think) 18 hours, which feels way too long to be reasonable. I realize this gets into bikeshedding on what *reasonable* is, but should this be defined, or configurable?

6: "On a LAN circuit, if the router in planned restart state is the DIS at any supported level, the adjacency(ies)" -- another unexpanded acronym.

[Ballot comment]
Thanks for this well written document, which I’ve found easy to read and mostly clear.  I have some editorial comments below, a few related to clarity.  I realize that some of these apply to text that was in RFC 5306, and I ask you to please consider them, but I understand if you want to minimize changes from 5306.

— Abstract —

This is entirely an editorial style comment, and no response is needed; just do what you think best, and if that is to leave it as it is, then that’s fine.  I find the “This document…  This document additionally…  This document additionally…” to be awkward, and suggest this instead:

NEW
  This document obsoletes RFC 5306 and describes a set of mechanisms
  that can improve neighbor reconfiguration when a router restarts.
  Using these mechanisms:

  1. A restarting router can signal to its neighbors that it is
  restarting, allowing them to reestablish their adjacencies without
  cycling through the down state, while still correctly initiating
  database synchronization.

  2. A router can signal its neighbors that it is preparing to initiate
  a restart while maintaining forwarding plane state.  This allows the
  neighbors to maintain their adjacencies until the router has
  restarted, but also allows the neighbors to bring the adjacencies down
  in the event of other topology changes.

  3. A restarting router can determine when it has achieved Link State
  Protocol Data Unit (LSP) database synchronization with its neighbors
  and can optimize LSP database synchronization, while minimizing
  transient routing disruption when a router starts.
END

— Section 1 —

  This document describes a mechanism for a restarting router to signal
  that it is restarting to its neighbors, and allow them to reestablish
  their adjacencies without cycling through the down state, while still
  correctly initiating database synchronization.

As this is written, (1) “to its neighbors” is misplaced (it is not “restarting to its neighbors”) and (2) it sounds like the restarting router is allowing them to do the reestablishment, but it’s the signal that is.  I suggest this:

NEW
  This document describes a mechanism for a restarting router to signal
  to its neighbors that it is restarting.  The signal allows them to
  reestablish their adjacencies without cycling through the down state,
  while still correctly initiating database synchronization.
END

— Section 3.1 —

  An instance of the timer T2 is maintained for each LSP database
  (LSPDB) present in the system, i.e., for a Level 1/2 system, there
  will be an instance of the timer T2 for Level 1 and an instance for
  Level 2.

Do you really mean “i.e.” here?  Is this the only possible situation, or is it an example (for which you would want “e.g.”)?  I think it’s the latter, in which case I would avoid the Latin, use English, and start a new sentence:

NEW
  An instance of the timer T2 is maintained for each LSP database
  (LSPDB) present in the system.  For example, for a Level 1/2 system,
  there will be one instance of the timer T2 for Level 1 and another
  instance for Level 2.
END

  This is initialized to 65535
  seconds, but is set to the minimum of the remaining times of received
  IIHs containing a restart TLV with the Restart Acknowledgement (RA)
  set and an indication that the neighbor has an adjacency in the "UP"
  state to the restarting router.

I found that quite confusing, because the long clause after “minimum of” is hard to follow (maybe it’s not an issue for readers who are versed in IS-IS).  I don’t understand what it’s set to (and when it’s set to it, after the initial value of 65535), and I can’t suggest a rephrasing because I don’t understand.  Can you try re-wording this (and maybe splitting it into two sentences)?

— Section 3.2 —

  A new TLV is defined to be included in IIH PDUs.  The presence of
  this TLV indicates that the sender supports the functionality defined
  in this document and it carries flags that are used to convey
  information during a (re)start.

The antecedent of “it” isn’t formally clear from the wording.  I suggest this:

NEW
  A new TLV is defined to be included in IIH PDUs, which carries flags
  that are used to convey information during a (re)start.  The presence
  of this TLV indicates that the sender supports the functionality
  defined in this document.
END

  The functionality associated with each of the defined flags (as
  described in the following sections) is mutually exclusive with any
  of the other flags.  Therefore, it is expected that at most one flag
  will be set in a TLV.  Received TLVs which have multiple flags set
  MUST be ignored.

Is there a reason not to say, “Therefore senders MUST NOT set more than one flag in a Restart TLV.”?  Why aren’t we forbidding it, if the TLV will be ignored (MUST be ignored) on receipt otherwise?

— Section 3.2.1 —

  b.  immediately (i.e., without waiting for any currently running
      timer interval to expire, but with a small random delay of a few
      tens of milliseconds on LANs to avoid "storms")

Then it’s not “immediately”, right?  Might “promptly” be an appropriate characterization?  Or is “immediately but with a small random delay” a common meaning of “immediately” in this context?

(Similar comment for Section 3.2.3.)

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

The IANA Functions Operator has completed its review of draft-ietf-lsr-isis-rfc5306bis-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the TLV Codepoints Registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing codepoint:

Type Description
---- ------------------------------
211 Restart TLV

will have its reference changed from [RFC5306] to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lsr-isis-rfc5306bis@ietf.org, uma.chunduri@huawei.com, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Uma Chunduri , lsr@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Restart Signaling for IS-IS) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Restart Signaling for IS-IS'
  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 2019-08-27. 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


  This document describes a mechanism for a restarting router to signal
  to its neighbors that it is restarting, allowing them to reestablish
  their adjacencies without cycling through the down state, while still
  correctly initiating database synchronization.

  This document additionally describes a mechanism for a router to
  signal its neighbors that it is preparing to initiate a restart while
  maintaining forwarding plane state.  This allows the neighbors to
  maintain their adjacencies until the router has restarted, but also
  allows the neighbors to bring the adjacencies down in the event of
  other topology changes.

  This document additionally describes a mechanism for a restarting
  router to determine when it has achieved Link State Protocol Data
  Unit (LSP) database synchronization with its neighbors and a
  mechanism to optimize LSP database synchronization, while minimizing
  transient routing disruption when a router starts.

  This document obsoletes RFC 5306.





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

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


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

(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?

The Intended Status is 'Proposed Standard'. 
This is an approprtate status as the mechanism defined in this documnet should
be interoperable.
The type of RFC is properly indicated in the title page header.


(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
This document describes an additional mechanism to IS-IS Graceful restart
functionality (RFC 5306)  so that planned restart by operator can happen with the support
of the neighboring nodes.

Working Group Summary
There is no much working group discussion on the enhancement presented in the bis
document. But, the draft has been presented in the LSR WG meeting(s).
The draft adoption and progress has received good support from the WG.

No major concerns have been raised.  The draft is ready for publication

Few review comments discussed in the list for this write have been fully addressed by authors.

Document Quality
The draft has yet to go through routing directorate review.
Proposed enhancements  have been proto typed/implemented by 1
vendor-os/implementation.


Personnel
Uma Chunduri is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(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.

The draft has been thoroughly reviewed by the Shepherd.
Comments and review feedback has been discussed in the LSR mailing list  and duly addressed.

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

N/A.

(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.

N/A

(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.

  N/A

(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.  Every author has confirmed.

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.  The authors have been asked (and they answered) on the WG list about IPR
in the LC process.  There haven't been any concerns raised on the list.

(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? 

The draft adoption and progress had received reasonable support from the WG.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.
There are still some editorial comments that need to be addressed.
From idnits:

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

Warning about ISO10859 has to be ignored (tool issue).


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

N/A

For Yang updates one of the co-chair's response:
"I have been working with an IS-IS developer who has worked on our native YANG
models and we are considering a separate draft which augments the operational
state for IS-IS adjacencies to include more information".


(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 (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.

This document obsoletes RFC 5306 - "Restart Signaling for IS-IS"

(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).

N/A

(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.
N/A

(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.
N/A

(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?

The Intended Status is 'Proposed Standard'. 
This is an approprtate status as the mechanism defined in this documnet should
be interoperable.
The type of RFC is properly indicated in the title page header.


(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
This document describes an additional mechanism to IS-IS Graceful restart
functionality (RFC 5306)  so that planned restart by operator can happen with the support
of the neighboring nodes.

Working Group Summary
There is no much working group discussion on the enhancement presented in the bis
document. But, the draft has been presented in the LSR WG meeting(s).
The draft adoption and progress has received good support from the WG.

No major concerns have been raised.  The draft is ready for publication

Few review comments discussed in the list for this write have been fully addressed by authors.

Document Quality
The draft has yet to go through routing directorate review.
Proposed enhancements  have been proto typed/implemented by 1
vendor-os/implementation.


Personnel
Uma Chunduri is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(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.

The draft has been thoroughly reviewed by the Shepherd.
Comments and review feedback has been discussed in the LSR mailing list  and duly addressed.

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

N/A.

(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.

N/A

(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.

  N/A

(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.  Every author has confirmed.

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.  The authors have been asked (and they answered) on the WG list about IPR
in the LC process.  There haven't been any concerns raised on the list.

(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? 

The draft adoption and progress had received reasonable support from the WG.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.
There are still some editorial comments that need to be addressed.
From idnits:

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

Warning about ISO10859 has to be ignored (tool issue).


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

N/A

For Yang updates one of the co-chair's response:
"I have been working with an IS-IS developer who has worked on our native YANG
models and we are considering a separate draft which augments the operational
state for IS-IS adjacencies to include more information".


(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 (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.

This document obsoletes RFC 5306 - "Restart Signaling for IS-IS"

(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).

N/A

(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.
N/A

(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.
N/A

(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?

The Intended Status is 'Proposed Standard'. 
This is an approprtate status as the mechanism defined in this documnet should
be interoperable.
The type of RFC is properly indicated in the title page header.


(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
This document describes an additional mechanism to IS-IS Graceful restart
functionality (RFC 5306)  so that planned restart can happen with the support
of the neighboring nodes.

Working Group Summary
There is no working group discussion on the enhancement presented in the bis
document. But, the draft has been presented in the LSR WG meeting(s).
The draft adoption and progress has received good support from the WG.

No major concerns have been raised.  The draft is ready for publication
(pending agreed updates in the LSR list discussions).
Few comments are sent in a separate document/email to be addressed by authors.

Document Quality
The draft has yet to go through routing directorate review.
Proposed enhancements  have been prototyped/implemented by 1
vendor-os/implementation (yet to be shipped).


Personnel
Uma Chunduri is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(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.

The draft has been thoroughly reviewed by the Shepherd.
Comments and review feedback has been discussed in the LSR mailing list and
waiting to see the updated (02) version.

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

Expecting IESG directorate reviews else the answer to this question is N/A.

(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.

N/A

(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.

  N/A

(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.  Every author has confirmed.

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.  The authors have been asked (and they answered) on the WG list about IPR
in the LC process.  There haven't been any concerns raised on the list.

(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? 

The draft adoption and progress had received reasonable support from the WG.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.
There are still some editorial comments that need to be addressed.
From idnits:

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 13, 2018) is 166 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'


    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).


Some of the above would be taken care on 02 version and warning about ISO10859
has to be ignored.


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

N/A

For Yang updates one of the co-chair's response:
"I have been working with an IS-IS developer who has worked on our native YANG
models and we are considering a separate draft which augments the operational
state for IS-IS adjacencies to include more information".


(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 (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.

This document obsoletes RFC 5306 - "Restart Signaling for IS-IS"

(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).

N/A

(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.
N/A

(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.
N/A