Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
draft-ietf-idr-bgp-ls-segment-routing-msd-18

[Ballot comment]
For some reason this document feels very familiar to me -- I feel like I read it a few months ago, but I cannot find anything in the document history / my ballots...

Anyway, NoObj.

Closed request for Telechat review by INTDIR with state 'Withdrawn': Request has expired and INT AD has balloted his review. No need to do a further review albeit I am sure that authors will read and act on useful review.

[Ballot comment]
Thank you for the work put into this document. The document is easy to read albeit a little unclear about its focus (see my comments below).

I am always positively amazed how BGP can be used as a signaling protocol for new use cases :-)

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In "doesn't exceed the number of SIDs the node is capable of imposing.", is it "imposing" or "processing" ? Esp. when section 1.1.1 uses the word "supported" and "label imposition" does not really fit SRv6.

If this document is only about SR-MPLS, then please modify title, abstract, and introduction to reflect this focus.

-- Section 3 --
Unsure whether "MSD values may be learned via a hardware API or may be provisioned. " provides any added value.

While it is unclear to me whether this document applies only to SR-MPLS, but, if it applies also to SRv6, then is it required to be able to advertise to MSD per node ? One for SR-MPLS and one for SRv6?

[Ballot comment]
[[ nits ]]

[ section 3 & 4 ]
* MSD-Value: Perhaps a small explicit statement that this value in units of
  SIDs of type MSD-Type.

[Ballot comment]
Not a whole lot of interesting comments on this one; it seems like a
pretty straightforward codepoint allocation with relevant (security and
other) considerations covered in other documents.  I do appreciate the
discussion in the security considerations section; it looks good.

This document talks about the MSD as being the depth of a stack that a
given node can "impose".  Is there a similar consideration (or protocol
element) for what a given node can read/process?  (I think I remember
such a document going by, but don't have enough keywords to search for
it efficiently.)

Is there a specific error-handling behavior to use when a Node MSD TLV
is received with a value larger than the value of a Link MSD TLV
associated with that node (for the same MSD-type)?  Is that one of the
things "left to the consumer of the BGP-LS information" by Sectoin 7?

Section 1

  In the future, it is expected that new MSD-Types will be defined to
  signal additional capabilities, e.g., ELs, SIDs that can be imposed
  through recirculation, or SIDs associated with another data plane
  such as IPv6.  MSD advertisements may be useful even if SR itself is
  not enabled.  For example, in a non-SR MPLS network, MSD defines the
  maximum label depth.

It's slightly interesting that we still call it "MSD" even though there
are potential uses in a broader scope.  Perhaps just a historical legacy
and we need to remain consistent with the name in common use...
Though, perhaps the terminology section in this document does not need
to be quite so constrained by the past.

Section 3

  identified by the corresponding Router-ID.  Node MSD is the smallest
  MSD supported by the node on the set of interfaces configured for
  use.  MSD values may be learned via a hardware API or may be

It is a shame that the semantics are already locked in (as was noted by
a previous review that I can't find right now?) and the efficient
encoding of "large per-node value with smaller per-link values for
exceptions" is not admissible.

Section 5

  MSD-type is not supported.  The correct interpretation MUST be
  specified when an MSD-type is defined in [RFC8491].

Is this "is defined in the registry defined in [RFC8491]" or "is defined
according to the procedures in [RFC8491]" or something else?  The
current text doesn't scan properly, as it implies that a future new
MSD-type will be defined in RFC 8491, an immutable document.

Section 7

  Specifically, the malformed attribute tests for syntactic checks in
  the Fault Management section of [RFC7752] now encompass the new BGP-
  LS Attribute TLVs defined in this document.  [...]

Interestingly, the referenced section of 7752 does not seem to
explicitly say that other invariant properties of TLV lengths (e.g.,
that they must be a multiple of 2 as for the ones defined by this
document) should be checked.

  [RFC7752].  The MSD information introduced in BGP-LS by this
  specification, may be used by BGP-LS consumer applications like a SR
  path computation engine (PCE) to learn the SR SID stack handling

https://www.rfc-editor.org/materials/abbrev.expansion.txt lists "PCE" as
having a well-known expansion to "Path Computation Element" (not
"engine") that can be used directly in abbreviated form without any
expansion given.

Section 8

  issues when propagating the TLVs into BGP-LS.  The advertisement of
  the node and link attribute information defined in this document
  presents no additional risk beyond that associated with the existing
  node and link attribute information already supported in [RFC7752].

I'd suggest hedging to "no significant additional risk", though I do not
have an example of additional marginal risk at hand.

[Ballot comment]
Just some nits:

Section 1:
* "... and controller does not participate ..." -- should be "the controller"

Section 1.1.1:
* Though the term "PCC" is in this glossary, it is not used anywhere in this document.

Section 7:
* "The extensions specified in this document, do not specify ..." -- remove the comma

[Ballot comment]
Update: Alvaro says the design below is inherited from other specs, and cannot be changed.

====

This is not a DISCUSS-level concern, but I found it odd that the Node MSD TLV must be the minimum of all configured interfaces without regard for the presence of any Link MSD TLVs.

For example, if all node interfaces have an MSD of 20 except one with an MSD of 10, it would be much more compact to advertise a Node MSD of 20 and a single Link MSD of 10. Section 5 says the Link MSD would take precedence, so there would be no information loss. As I understand the spec, this would not be allowed, and each link would have to be advertised separately to gain that level of granularity.

If this is not the intent, then in Section 3, extending a sentence to say "Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use, [excepting links advertised with their own Link MSD TLV]" would avoid the problem.

[Ballot comment]
This is not a DISCUSS-level concern, but I found it odd that the Node MSD TLV must be the minimum of all configured interfaces without regard for the presence of any Link MSD TLVs.

For example, if all node interfaces have an MSD of 20 except one with an MSD of 10, it would be much more compact to advertise a Node MSD of 20 and a single Link MSD of 10. Section 5 says the Link MSD would take precedence, so there would be no information loss. As I understand the spec, this would not be allowed, and each link would have to be advertised separately to gain that level of granularity.

If this is not the intent, then in Section 3, extending a sentence to say "Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use, [excepting links advertised with their own Link MSD TLV]" would avoid the problem.

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

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ls-segment-routing-msd-16. 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 BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

two temporary registrations will be made permanent and their references changed to [ RFC-to-be ]. The two temporary registrations are:

+------------+-----------------+---------------------------+-------------------+
| Code Point | Description | IS-IS TLV/Sub-TLV | Reference |
+------------+-----------------+---------------------------+-------------------+
| 266 | Node MSD | 242/23 | [ RFC-to-be ] |
| 267 | Link MSD | (22,23,25,141,222,223)/15 | [ 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 2020-04-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org, Susan Hares , shares@ndzh.com, aretana.ietf@gmail.com, idr-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Signaling MSD (Maximum SID Depth) using
Border Gateway Protocol - Link
  State'
  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
last-call@ietf.org mailing lists by 2020-04-17. 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 defines a way for a Border Gateway Protocol - Link
  State (BGP-LS) speaker to advertise multiple types of supported
  Maximum SID Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3273/
  https://datatracker.ietf.org/ipr/3023/

Template date:  24 February 2012.

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
      No additional vendors indicated a plan to implement the IDR MSD feature.
      However, there is support for this feature in SR in the LSR  WG.

  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?
    RTG-DIR: Mach Chen

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  RTG-DIR early review:  Mach Chen

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt, -08.txt)

Current text in shepherd:
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA:  Mach Chen
Ready.  Minor nits he mentioned addressed in -08.txt

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


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

No.  The WG has been asked about

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

This is a normal SR draft so the following suggestions are made for the reviewers:

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support of the SR function.

To this shepherd, MSD seems to improve the manageability of the
SR functions in a network.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU


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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG.

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative or informative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
      No additional vendors indicated a plan to implement the IDR MSD feature.
      However, there is support for this feature in SR in the LSR  WG.

  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?
    RTG-DIR: Mach Chen

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  RTG-DIR early review:  Mach Chen

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt, -08.txt)

Current text in shepherd:
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA:  Mach Chen
Ready.  Minor nits he mentioned addressed in -08.txt

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


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

No.  The WG has been asked about

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

This is a normal SR draft so the following suggestions are made for the reviewers:

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support of the SR function.

To this shepherd, MSD seems to improve the manageability of the
SR functions in a network.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

Please note that the IPR on this feature  may preclude open source
implementations from creating it.

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG.

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
      No additional vendors indicated a plan to implement the IDR MSD feature.
      However, there is support for this feature in SR in the LSR  WG.

  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?
    RTG-DIR: Mach Chen

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  RTG-DIR early review:  Mach Chen

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt, -08.txt)

Current text in shepherd:
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA:  Mach Chen
Ready.  Minor nits he mentioned addressed in -08.txt

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


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

No.  The WG has been asked about

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

This is a normal SR draft so the following suggestions are made for the reviewers:

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support of the SR function.

To this shepherd, MSD seems to improve the manageability of the
SR functions in a network.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

Please note that the IPR on this feature  may preclude open source
implementations from creating it.

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG.

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.
Awaiting: -09.txt with downrefs resolved
----------------------
(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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
      No additional vendors indicated a plan to implement the IDR MSD feature.
      However, there is support for this feature in SR in the LSR  WG.

  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?
    RTG-DIR: Mach Chen

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  RTG-DIR early review:  Mach Chen

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt, -08.txt)

Current text in shepherd:
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA:  Mach Chen
Ready.  Minor nits he mentioned addressed in -08.txt

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


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

No.  The WG has been asked about

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

This is a normal SR draft so the following suggestions are made for the reviewers:

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support of the SR function.

To this shepherd, MSD seems to improve the manageability of the
SR functions in a network.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

Please note that the IPR on this feature  may preclude open source
implementations from creating it.

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG.

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

Status: To-do
Implementation status:  Wiki ok, IDR question on planned MSD implementations
Shepherd's review of -07.txt:  Ok
Awaiting QA reviews: RTG-DIR (9/14), OPS-DIR: (overdue)
----------------------
(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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
[TBD -based on call]

  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?
  [TBD - awaiting RTG-DIR and OPS-DIR early review]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  OPS-DIR early reviewer:  Al Morton
  RTG-DIR early review:  TBD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt(pending))

Current text in shepherd:  [-06.txt version]
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA
[TBD]

4. OPS-DIR QA [Al Morton]
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[TBD] - after RTG-DIR and OPS-DIR Early review


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG:
(TBD)

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

Status: To-do
Implementation status:  Wiki ok, IDR question on planned MSD implementations
Shepherd's review of -07.txt:  Ok
Awaiting QA reviews: RTG-DIR (9/14), OPS-DIR: (overdue)
----------------------
(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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
[TBD -based on call]

  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?
  [TBD - awaiting RTG-DIR and OPS-DIR early review]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  OPS-DIR early reviewer:  Al Morton
  RTG-DIR early review:  TBD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt(pending))

Current text in shepherd:  [-06.txt version]
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA
[TBD]

4. OPS-DIR QA [Al Morton]
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[TBD] - after RTG-DIR and OPS-DIR Early review


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG:
(TBD)

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

Status: To-do
Implementation status:  Wiki ok, IDR question on planned MSD implementations
Shepherd's review of -06:  Needs -07.txt
Awaiting QA reviews: RTG-DIR, OPS-DIR

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
    see report at:
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations   

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  Additional vendors with segment routing implementations
  have indicated they which to add the MSD feature. 
[TBD -based on call]

  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?
  [TBD - awaiting RTG-DIR and OPS-DIR early review]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana
  OPS-DIR early reviewer:  Al Morton
  RTG-DIR early review:  TBD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt, -07.txt(pending))

Current text in shepherd:  [-06.txt version]
The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 
Needs draft-ietf-idr-rfc7752bis-00 reference and clarified
management based on yang models. 

3.  RTG-DIR QA
[TBD]

4. OPS-DIR QA [Al Morton]
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[TBD] - after RTG-DIR and OPS-DIR Early review


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

RFC7752 is being revised by IDR to clarify sections in the draft
based on implementation experience.  Rushing RFC7752bis to
completion is unwise since it takes careful review of the implementation
reports to address the places where RFC7752 is unclear.

RFC7752 and segment routing (SR) are in use with
centralized controllers.  This specification addresses a known
need in deployed SR.    Therefore it is unwise to hold this
specification back or hurry RFC7752bis.

There may not be substantial discussion on this point
because the people developing BGP and the people operating
BGP realize we have a balancing act as we deploy segment routing features.
We must balance sending forward features that aid deployments
and clarify the RFC752bis specification so that new implementations
may be interoperable with existing implementations.

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG:
(TBD)

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

No XML code, BNF rules, MIB definitions.
References to all Yang models have been checked.

Template date:  24 February 2012.

Status: To-do
Implementation status:  Only 2 Cisco implementations, need full implementation (MUST/Should/Etc) in report (8/8 to 8/15)
Shepherd's review of -06: TBD
Awaiting QA reviews: RTG-DIR, OPS-DIR

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
 
  No details are available on the SHOULD/MAY/MUST. 

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  [Shepherd todo:  Ask on WG LC]

  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?
  [Shepherd todo:  Start QA review from RTG-DIR]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending
RTG-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt (pending)

The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 

I would prefer if draft-ketant-idr-rfc7752bis-00 is assumed
as an accompanying document for this work to provide
the required error handling. 

3.  RTG-DIR QA
[TBD]

4. OPS-DIR QA
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
[TBD] - Must have draft-ietf-idr-rfc7752bis-00 as WG document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[TBD] - after RTG-DIR and OPS-DIR Early review


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

[TBD]

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG:
(TBD)

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

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

Template date:  24 February 2012.

Status: To-do
Implementation status:  Only 2 Cisco implementations, need full implementation (MUST/Should/Etc) in report (8/8 to 8/15)
Shepherd's review of -06: TBD
Awaiting QA reviews: RTG-DIR, OPS-DIR

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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

WG LC is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  WG consensus was postive with indications of
that this feature was needed in BGP-LS neworks.

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
 
  No details are available on the SHOULD/MAY/MUST. 

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  [Shepherd todo:  Ask on WG LC]

  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?
  [Shepherd todo:  Start QA review from RTG-DIR]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  OPS-DIR early review requested: pending
RTG-DIR early review requested: pending

Personnel
  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  on each version.
2. Review of entire document and dependents
  (-04.txt, -05.txt, -06.txt (pending)

The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 

I would prefer if draft-ketant-idr-rfc7752bis-00 is assumed
as an accompanying document for this work to provide
the required error handling. 

3.  RTG-DIR QA
[TBD]

4. OPS-DIR QA
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
[TBD] - Must have draft-ietf-idr-rfc7752bis-00 as WG document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[TBD] - after RTG-DIR and OPS-DIR Early review


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

[TBD]

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

WG Call for the WG approval of IPR on drafts:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

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

11 people indicated a strong support. 
There are 2 Cisco interoperable implementations.

WG Approval of 2 Cisco implementations to send to IESG:
(TBD)

WG response is at:
https://mailarchive.ietf.org/arch/msg/idr/lKmYs5G7OrbgjCTHivz3iIQ7LNU

(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 public appeals or discontent on mail list. 

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

No NITS founds.

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

No formal review. 

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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

  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

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

Template date:  24 February 2012.

Status: To-do
IPR Status:  Before WG LC:  Need all IPR statements,  complete implementation report, query to WG on 2 IPR
Implementation status:  Only 2 Cisco implementations, need full implementation (MUST/Should/Etc)
WG LC:  questions:  Any planned implementations?  Are cisco implementatnios enough 
Shepherd status:  Need QA review by RTG-DIR and OPS-DIR
Shepherd review:  Pre-WG LC and post-WG LC needed
----------------------
(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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  [TBD]

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
 
  No details are available on the SHOULD/MAY/MUST. 
    [Shepherd todo:  Ask authors to fill out should/may/must
      before/during WG LC starts. Allow 3 Week WG LC.] 

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  [Shepherd todo:  Ask on WG LC]

  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?
  [Shepherd todo:  Start QA review from RTG-DIR]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  [OPS-DIR QA review requested]

Personnel

  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  [6/7/2019] 
2. Review of entire document and dependents

The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 

I would prefer if draft-ketant-idr-rfc7752bis-00 was
proposed for WG adoption prior to sending this to the IESG.
Is there anyway this can be hurried along? 
Otherwise, this draft will need more error handling specified.

3.  RTG-DIR QA
[TBD]
4. OPS-DIR QA
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

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


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

[TBd]

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
https://mailarchive.ietf.org/arch/msg/idr/lMM_arn4fS1x3gaeWzuP9qrfK-4

N  Triantafillis
https://mailarchive.ietf.org/arch/msg/idr/zdb3NF-PWv2nf9LyD23VUm99PcU

Contributor: Siva Sivabalan
https://mailarchive.ietf.org/arch/msg/idr/1Hhz2Xl5_l2xnhHP3cdqNvFnfLg


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

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

[Shepherd TBD]

(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.)
[Sheperd TBD]

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

No NITS founds.

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

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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


  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

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

Template date:  24 February 2012.

Status: To-do
IPR Status:  Before WG LC:  Need all IPR statements,  complete implementation report, query to WG on 2 IPR
Implementation status:  Only 2 Cisco implementations, need full implementation (MUST/Should/Etc)
WG LC:  questions:  Any planned implementations?  Are cisco implementatnios enough 
Shepherd status:  Need QA review by RTG-DIR and OPS-DIR
Shepherd review:  Pre-WG LC and post-WG LC needed
----------------------
(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

    This document defines a way for a Border Gateway Protocol Link-State
  (BGP-LS) speaker to advertise multiple types of supported Maximum SID
  Depths (MSDs) at node and/or link granularity.

  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular Segment Identifier (SID) stack can be
  supported in a given network.

Working Group Summary

  Was there anything in WG process that is worth noting?
  2 IPR filed on this work
  2 implementation are only cisco

  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?  [TBD]

Document Quality

  Are there existing implementations of the protocol?
 
    2 Cisco implementations have indicated support for the protocol.
 
  No details are available on the SHOULD/MAY/MUST. 
    [Shepherd todo:  Ask authors to fill out should/may/must
      before/during WG LC starts. Allow 3 Week WG LC.] 

  Have a  significant number of vendors indicated their plan to
  implement the specification?
  [Shepherd todo:  Ask on WG LC]

  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?
  [Shepherd todo:  Start QA review from RTG-DIR]

  If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? 
  [OPS-DIR QA review requested]

Personnel

  Who is the Document Shepherd?  Susan Hares
  Who is the Responsible AD? Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1. NITS run  [6/7/2019] 
2. Review of entire document and dependents

The document lacks error handling section that indicates
what happens if the TLVS are incorrectly parsed. 

I would prefer if draft-ketant-idr-rfc7752bis-00 was
proposed for WG adoption prior to sending this to the IESG.
Is there anyway this can be hurried along? 
Otherwise, this draft will need more error handling specified.

3.  RTG-DIR QA
[TBD]
4. OPS-DIR QA
[TBD]

If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

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


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

RTG-DIR Review should look LSR documents linked.
OPS-DIR review should look at operational support.

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

[TBd]

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

Jeff Tantsura (Apstra, Inc.)
https://mailarchive.ietf.org/arch/msg/idr/71nuwWWzQkdbJKKuviy_FP2QuWQ

Uma Chunduri (Futurewei)
https://mailarchive.ietf.org/arch/msg/idr/RhwAd8gfTRy7w4ws3monyGjvl3o

Ketan Talaulikar (Cisco Systems)
https://mailarchive.ietf.org/arch/msg/idr/V9t7o86mWyetN3XUJjTJZ2ZtIxU

Greg  Mirsky
(missing)

N  Triantafillis
(missing)


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

https://datatracker.ietf.org/ipr/3273/
https://datatracker.ietf.org/ipr/3023/

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

[Shepherd TBD]

(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.)
[Sheperd TBD]

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

No NITS founds.

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

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

All references are normative.

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

All normative references are RFCS.

(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 normative references are downward references.

(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


  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs" based on table below.  Early allocation for these code-points
  have been done by IANA.

      +------------+-----------------+---------------------------+
      | Code Point |  Description        |    IS-IS TLV/Sub-TLV          |
      +------------+-----------------+---------------------------+
      |    266    | Node MSD        | 242/23                                              |
      |    267    | Link MSD        | (22,23,25,141,222,223)/15            |
      +------------+-----------------+---------------------------+


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

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