Multi-Part TLVs in IS-IS
draft-ietf-lsr-multi-tlv-19

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-lsr-multi-tlv and RFC 9885, changed IESG state to RFC Published)

With the resolution of the appeal to the IAB on this document, the IESG has requested that the RFC Editor and IANA resume processing of this document -- https://datatracker.ietf.org/group/iab/appeals/artifact/137.

[Ballot comment]
Many thanks to the authors and the WG for this important document for ISIS that addresses a pressing scaling challenge with a pragmatic solution.

My thanks to Yingzhen as the document shepherd for putting together a very good write-up that provides a summary of the document through its WG phase.

Thanks to the authors for working through addressing all of my DISCUSS concerns and almost all of my comments/suggestions for improving this document. For a couple of non-blocking comments where we could not converge, I am ok with going with what has emerged from the WG consensus.

[Ballot comment]
Thank you to David Mandelberg for their secdir reviews.  Also for the detailed shepherd review by Yingzhen Qu.

General:  I think the definition and explanation of how the term 'key' as used in this context is good.  I also agree w/ Ketan's comment on lines 247-251 for how to clarify the wording about where 'key' is defined for a given TLV.

Section 10:  The ability to add multiple TLVs to an IS-IS session (possibly not the right word) may increase the ability to cause a denial of service via resource exhaustion.  If that is a risk, please address this security concern.  Otherwise, please clarify why it isn't a concern.

[Ballot comment]
Thank you to Peter Yee for the GENART review.

** Section 9.2.1. Editorial.

        | 17        | IS-IS Area Node IDs TLV                | N  |
        +-----------+----------------------------------------+----+
        | 18        | IS-IS Flooding Path TLV                | N  |
        +-----------+----------------------------------------+----+
        | 19        | IS-IS Flooding Request TLV            | N  |

      | 126      | IPv4 Algorithm Prefix Reachability TLV | N  |
        +-----------+----------------------------------------+----+
        | 127      | IPv6 Algorithm Prefix Reachability TLV | N  |


These code point names include “TLV” as a suffix in this document, but that suffix is NOT present in the IANA registry.

[Ballot comment]
I had previously reviewed this document, as well as another objecting to it, in the course of understanding the appeal that was raised. While it would be nice to have a crisper definition of the "key" for each TLV, I understand and agree with the WG consensus that the key for each relevant TLV is sufficiently clear to implementers in practice. This document acknowledges and formalizes an existing workaround actively being used, and existing successful interoperation is the best evidence that this is clear to implementers.

[Ballot comment]
Thank you to the authors for this document, and a special thank you to the document shepherd for a very thorough review with pointers to much of the relevant WG discussion around specific points of contention. Most of my comments were nits that have been addressed by other reviewers ballots so I will not repeat them here. This leaves me with just a single comment on the abstract:

Abstract#

The sentence "Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial" implies that this document provides a pragmatic solution rather than a more intrusive update to the IS-IS protocol. This leaves me wondering what these extensions are, and I see no discussion around this further into the document (unless the text around [RFC7356] is what the authors were alluding too), or whether deployment of the solution in this document would allow for future extensions to be backwards compatible should the need arise to further define these "Extensions" in the future. Practically speaking I see no reasons why this should be a problem given that "significant IS-IS changes" could have implications far beyond MP-TLV so I am wondering if this sentence should just be removed as it does not really provide any value.

[Ballot discuss]
Thanks to the authors, first for taking up this work, and next for taking it through a "rigorous" WG process while focusing on technical aspects.

However, there are still some aspects in the document that I would like to have a discussion on (inline using idnits output of v14):

152   This document specifies a means for extending TLVs where no extension
153   mechanism has been previously explicitly specified, and defines this
154   mechanism as the default extension mechanism for future TLVs.  The
155   mechanism described in this document is applicable to top level TLVs
156   as well as any level of sub-TLVs which may appear within a top level
157   TLV.

Given that a TLV is bounded at 255 bytes, by definition its
sub-TLVs (at first and subsequent levels) are bounded to an even smaller limit.
This implies that if > 255 bytes need to be encoded in a 1st level sub-TLV,
then we would need two parts of the parent TLV as well. While this is
implicit, some text on this would be helpful - I would not be surprised if
this gets missed by people working on future specifications. Taking it further,
this aspect imposes some design restriction on the level of
sub-TLV/sub-sub-TLV/... that can be designed for future extensions due to the
reducing bounds as we go deeper. At some point, the overhead of the
"process of breaking into parts" may start to bring in higher overheads than
the actual information being conveyed. This brings in challenges in protocol
encoding design (specifically with many layer of sub-TLVs). I would like to
discuss why this document isn't providing such a guidance as well (or at least
touching upon this aspect). Perhaps a recommendation would be to not go more
than 2-3 level deep as there is a risk of hiting these limits?


289   For example, suppose that a router receives an LSP with a Multi-Part
290   Extended IS Reachability TLV.  The first part contains key
291   information K with sub-TLVs A, B, and C.  The second part contains
292   key information K with sub-TLVs D, E, and F.  The receiving router
293   must then process this as having key information K and sub-TLVs A, B,
294   C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F, A,
295   B, C, or any other permutation.

What if there is a single instance sub-TLV within an MP-TLV? In
this case, the ordering would be important if for some reason (or error) the
sender were to send multiple copies of that single instance sub-TLV and the
guidance is to 'use the first, ignore the rest'. Therefore, should the receiver
not have to process based on the ordering in the LSP(s) and that the sender
also is deliberate about the ordering of the parts in the LSP(s)?


310   Specifying how to handle such cases is the responsibility of the
311   document which defines the TLV.  If such a document is not explicit
312   in how to handle such cases, it is RECOMMENDED that the first
313   occurrence in the lowest numbered LSP be used.  In the case of IIHs,
314   it is RECOMMENDED that the first occurrence in the IIH be used.

Why RECOMMENDED (as in SHOULD) and not a MUST to ensure we arrive
at interoperable implementations down the line? Was there a proposal placed
before the WG to make this a MUST and some objection received on it?

399 8.  Deployment Considerations

I would like to discuss why this document is not recommending that
implementations and deployments move to RFC7356 as a long term approach to
scaling IS-IS to carry more information. RFC7356 is referenced in the
introduction, but some (short) additional text with references to its specific
sections may be a helpful guide. I see that the authors (and some other WG
members) had pointed to this work as "the long term solution", but the
document has not captured that aspect.

[Ballot comment]
Please find below some comments provided inline in the idnit output of v14. Would appreciate a response and some clarifications on the same.

110   The original TLV definition limits each TLV to a maximum of 255
111   octets of payload, which is becoming increasingly stressful.

How about the following?

CURRENT
The original TLV definition limits each TLV to a maximum of 255 octets of
payload, which is becoming increasingly stressful.

SUGGEST
The original TLV definition limits each TLV to a maximum of 255 octets of
payload are being increasingly stressed.


113   Some TLV definitions have addressed this by explicitly stating that a
114   TLV may appear multiple times inside of a Link State PDU (LSP).
115   However, this has not been done for many legacy TLVs, leaving the
116   situation somewhat ambiguous.

s/legacy/other - I am not sure the use of the term "legacy"
is appropriate here since those TLVs are very much in use today and likely in
the future as well.


147   The mechanism described in this document has not been documented for
148   all TLVs previously, so there is risk that interoperability problems
149   could occur.  This document provides the necessary protocol
150   definition.

The above text is incomplete. I would suggest that this paragraph
simply puts forward references to document sections that are dealing with
interoperability challenges and backwards compatibility aspects.


167 3.  Overview of TLVs

169   A TLV is a tuple of (Type, Length, Value) and can be advertised in
170   IS-IS packets.  Both Type and Length fields are one octet in size,
171   which leads to the limitation that a maximum of 255 octets can be
172   sent in a single TLV.

To do justice to the title of this section, why isn't it covering a
single-instance TLV as well?


247   The encoding of TLVs is not altered by the introduction of MP-TLV
248   support.  In particular, the "key" which is used to identify the set
249   of TLVs which form an MP-TLV is the same key used in the absence of
250   MP-TLV support.  Also note the definition of the "key" exists in the
251   specification(s) that define(s) the TLV.

Perhaps

CURRENT
Also note the definition of the "key" exists in the specification(s) that
define(s) the TLV.

SUGGEST
The definition of the "key" for a given TLV is outside the scope of this
document and has to be part of the specification(s) that define(s) the TLV.


265 5.  Procedure for Receiving Multi-Part TLVs

267   A router that receives a MP-TLV MUST accept all of the information in
268   all of the parts.  The order of arrival and placement of the TLV
269   parts in LSP fragments is irrelevant.  Multiple TLV parts MAY occur
270   in a single LSP or parts MAY occur in different LSPs.

272   The placement of the TLV parts in an IIH is irrelevant.

Does "placement" here also cover "ordering"? Is the intention
here that it is not required that all parts be encoded consequtively in an
LSP (or across LSP fragments), and that no specific ordering is expected? Please
also see my discussion point 2.


351   For example, if there are mutiple TLVs associated with the
352   advertisement of a neighbor and some routers do not use all of the
353   link attributes advertised, then constrained path calculations based
354   on those attributes are likely to produce inconsistent results and
355   produce forwarding loops or dropped traffic.

More specifically, this is for a distributed constraints path
calculation (as in FlexAlgo)? For P2P TE computations, this may not present a
loop but yes results might be not what is desired.


365   Routers which support MP-TLV for codepoints for which existing
366   specifications do not explicitly define such support, but for which
367   MP-TLV is applicable, SHOULD include this sub-TLV in a Router
368   Capability TLV.

Why is this not a MUST even if it is for informational purposes?
Likely someone is relying on this information to be accurate. Please also see
the next comment.


373   This advertisement is for informational purposes only.
374   Implementations MUST NOT alter what is sent or how what is received
375   is processed based on these advertisements.

By implementations, I assume the reference here is to IS-IS protocol
behavior? Because a controller should be free to use this information an adapt
its behavior? Please clarify.


382   deployment scenarios in which it is used.  Therefore, diligence is
383   still required on the part of the operator to ensure that
384   configurations which require the sending of MP-TLV for a given
385   codepoint are not introduced on any router in the network until all
386   routers in the network support MP-TLV for the relevant codepoints.

Perhaps an informative reference here to the PICS YANG work would
help?


401   Sending of MP-TLVs in the presence of routers that do not correctly
402   process such advertisements can result in interoperability issues,
403   including incorrect forwarding of packets.  This section discusses
404   best practices which SHOULD be used when a deployment requires the

Perhaps s/SHOULD/should since there isn't anything that is being
specified in this sentence.


416   Network operators SHOULD NOT enable MP-TLVs until ensuring that all
417   implementations that will receive the MP-TLVs are capable of
418   interpreting them correctly as described in Section 5.

The above sentence is better placed towards end of section 8.1 where
those controls to enable/disable MP-TLVs are introduced.


420 8.1.  Recommended Controls and Alarms

422   It is RECOMMENDED that implementations which support the sending of

Why not MUST instead of RECOMMENDED (i.e., SHOULD) for the global
control knob? This would be the bare minimum control that is required for the
operator?

423   MP-TLVs provide configuration controls to enable/disable generation
424   of MP-TLVs.  Given that MP-TLV support in a given implementation may
425   vary on a per TLV basis, these controls SHOULD support per codepoint
426   granularity. 


444   Sending a single TLV with all the information about an object is
445   preferable to sending multiple TLVs.  It is simpler and more
446   efficient to parse information from a single TLV than to combine the
447   information from multiple TLVs.  Implementations SHOULD NOT send
448   multiple TLVs unless MP-TLV is applicable to the TLV and the amount
449   of information which is required to be sent exceeds the capacity of a
450   single TLV.  For example, when additional space is required in an
451   existing TLV, as long as there is space in the TLV, information
452   SHOULD NOT be split into multiple TLVs.  If there is no space in the
453   current LSP to fit the now larger TLV, the TLV SHOULD be moved to a
454   new LSP.

All of these are SHOULD instead of MUST. What would be the conditions
in which they cannot be followed by implementations? Please consider adding
some short explanatory text.


531         | 19        | IS-IS Flooding Request TLV            | N  |
532         +-----------+----------------------------------------+----+
533         | 20        | Area Proxy                            | N  |

This has sub-TLVs and its own sub-TLV registry that is missing.

534         +-----------+----------------------------------------+----+
535         | 21        | Flooding Parameters TLV                | N  |

This has sub-TLVs and its own sub-TLV registry that is missing.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-multi-tlv-13
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks (and congratulations) to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (and the history) *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

s/New technologies are adding new information/New specifications and IS-IS extensions are adding new information/

### Section 1

Unsure whether IS-IS is used over the public Internet in `The continued growth of the Internet` :-)

In the first paragraph, it is unclear whether the 255 applies per TLV or for the whole set of TLV (even if the reader can have a guess, let's be clear).

s/Any future *document* *which* proposes/Any future *IETF specification* *that* proposes/ ?

Should there be an exhaustive list rather than `Some examples of this are` ?

Please introduce "LSP" before first use.

Strongly suggest to indicate that the MP-TLV capability is negotiated (as I had big ??? in mind until section 7).

### Section 4

Bear with my lack of IS-IS expertise, but can a IIH message be fragmented in several layer-2 packets ? If so, how can a node differentiate between recent and old TLV in "MP-TLV" bundle (i.e., are these TLV parts of a unique bundle or separates ones) ?

`Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be done` what is the expected behavior when receiving such a TLV ?

### Section 5

Does the basis IS-IS specification cover the case when several TLV having the same Type have conflicting values ? Should there be text about this corner case ?

### Section 6

Be more assertive and use "MUST" in `Therefore any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints`

### Section 7

I find this section under-specified , e.g., isn't the following wishful thinking `It is presumed that if such support is provided that it applies to all relevant codepoints`?

Why not a "MUST" in `SHOULD include this sub-TLV in a Router Capability TLV` ?

### Section 8

s/presence of routers *which* do not correctly/presence of routers *that* do not correctly/

Please explain the consequences (or when it can be bypassed) of the 2 "SHOULD".

### Section 9.1

Suggest adding informative references to the IANA registries URIs.

### Section 9.2

Should there be guidance for the designated experts ?

## NITS (non-blocking / cosmetic)

### Section 1

`PDU` acronym is never used, so do not introduce it ;)

[Ballot comment]
Hi Parag, Tony L., Tony P., Shraddha, and Les,

Many thanks for the effort put into this specification.

I strongly support the objective of this effort and like the pragmatic approach followed here. So, thanks again.

I have some comments that I’d like to be addressed/discussed, especially the ones marked with (*).

# General

## (nit) Please use consistent wording MP-TLV vs. Multi-Part TLV through the document

## (nit) I may be old school, but I think the document should use “router”, instead of “node”.

# Abstract (nit): not every technologies is adding info into IGP + split a long sentence:

OLD:
  New technologies are adding new information into IS-IS while
  deployment scales are simultaneously increasing, causing the contents
  of many critical TLVs to exceed the currently supported limit of 255
  octets. 

NEW:
  Deploying some new techniques relies upon adding new information into IS-IS while
  deployment scales are simultaneously increasing. This causes the contents
  of many critical TLVs to exceed the currently supported limit of 255
  octets. 

# Introduction

## (nit) s/Some TLV definitions have addressed this by explicitly/Some TLV definitions have addressed this issue by explicitly

## Justification for alternate mechanisms (*)

CURRENT:

  Any future document which
  proposes a different mechanism for scaling TLV contents for a given
  codepoint MUST provide justification.

I’m not fun of normative language in an introduction (as the context is not yet well established), we may consider replacing “provide justification” with a more meaningful guidance, e.g., “identify the shortcomings of the multiple part approach and motivate the need for a another mechanism”.

Also, you may consider: s/ Any future document which proposes/Any future document that proposes standardizing

## I would delete ", if they choose not to specify another extension mechanism".

# Section 3.2.1

Please cite where type 22 is defined + remind how the identifiers are encoded:

OLD:
  As an example, consider the Extended IS Reachability TLV (type 22).
  …
  *  Optionally one or more of the following link identifiers:

NEW:
  As an example, consider the Extended IS Reachability TLV (type 22) [RFC5305].
  …
  *  Optionally one or more of the following link identifiers encoded as sub-TLVs (0-244 octets):

# Section 4: On Keys

CURRENT:
  The encoding of TLVs is not altered by the introduction of MP-TLV
  support.  In particular, the "key" which is used to identify the set
  of TLVs which form an MP-TLV is the same key used in the absence of
  MP-TLV support.  Also note the definition of the "key" exists in the
  specification(s) which define(s) the TLV.

  NOTE: This document intentionally does not include a definition of
  the key for each codepoint.  To do so would be redundant and risk
  unintentionally deviating from the definition which already exists in
  the relevant specifications.

## Maybe it is accurate to also remind in the note that term “key” is not used per se in these specs.

## (nit) BTW, please fix this part: s/specification(s) which define(s) the TLV/specification(s) that define(s) a TLV.

# Section 5 (*)

CURRENT:
  When processing MP-TLVs, implementations MUST NOT impose a minimum
  length check. 

Agree... however, should we have a max of MP-TLVs to be used as a guard for splitting the information into a large numbers of TLVs?

# Section 6

## I don’t parse what is meant by "advertised in a codepoint". I guess you meant advertised with or in a TLV with a type/codepoint. I suggest to make the following change:

s/may be advertised in a single codepoint /may be advertised with a single codepoint

## Simplify

OLD:
  This guarantees that
  any new codepoints defined by future protocol extensions will
  explicitly indicate the applicability of Multi-Part TLV procedures to
  the new codepoints.

NEW:
  Future allocations will
  explicitly indicate the applicability of Multi-Part TLV procedures to
  the new codepoints.

# Section 7

## Please elaborate more the "extremely disruptive" mention in the following:

CURRENT:
  Introduction of the use of MP-TLV for codepoints where the existing
  specifications have not explicitly defined MP-TLV support can be
  extremely disruptive to network operations in cases where not all

## I don’t parse the following:

CURRENT:
  It is presumed that if such
  support is provided that it applies to all relevant codepoints. 

## Consider adding examples of deployment scenarios

OLD:
  a given implementation might limit MP-
  TLV support to particular codepoints based on the needs of the
  deployment scenarios in which it is used.

NEW:
  a given implementation might limit MP-
  TLV support to particular codepoints based on the needs of the
  deployment scenarios in which it is used (e.g., set by default
  or controlled by a configuration parameter). 

## I suggest to delete the following. This message is already stated in the document:

CURRENT:
  Note that with the introduction of explicit specification of MP-TLV
  applicability for codepoints (Section 9), implicit MP-TLV support
  will never occur in the future.

## What is the goal of this MUST if the implem is already conformant?! (*)

CURRENT:
  Where MP-TLV support is explicitly
  defined, conformant implementations MUST support MP-TLV.

# Section 8: Not sure the normative language makes sense in the following text:

CURRENT:
  Sending of MP-TLVs in the presence of nodes which do not correctly
  process such advertisements can result in interoperability issues,
  including incorrect forwarding of packets.  This section discusses
  best practices which SHOULD be used when a deployment requires the
  use of MP-TLVs for codepoints for which existing specifications do
  not explicitly indicate MP-TLV support.

# Section 8.1

## Configuration and defaults (*)

CURRENT:
  It is RECOMMENDED that implementations which support the sending of
  MP-TLVs provide configuration controls to enable/disable generation
  of MP-TLVs. 

(1) Should we also be able to expose the actual (configurable) capabilities?

(2) Given the implications of partial support, can we suggest the default be to disable?

## Does the report in the following covers logging? Can we be explicit here? (*)

CURRENT:
  Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions:

# Section 9.2: (nit) s/ This document requests that IANA extend/This document requests that IANA extends

# Section 10 (*)

CURRENT:
  This document creates no new security issues for IS-IS. 

Isn’t generalizing applicability of MP-TLV may be misused (e.g., abuse the number of occurrences to consume computing resources of a receiver)?

Cheers,
Med

[Ballot comment]
Thank you for writing this document, I have only one comment:
“A TLV may contain information in its fixed part that is not part of the key.”
- Could this be an RFC 2119 “MAY”?

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/

3) IETF LC Summary & Conclusion:

Throughout the IETF Last Call, Aijun repeatedly raised the same issue, despite it being addressed multiple times during both the Working Group Last Call (WGLC) and IETF LC. He challenged every directorate review, but received no support for his argument from the community, WG experts, or directorate reviewers.

* Publication Request & IETF LC Timeline
Publication was requested on 2/10/25: https://mailarchive.ietf.org/arch/msg/lsr/ud5_YmvjshH75KD6vlfIOt5Ibbk/
IETF Last Call (LC) was issued on 2/11/25 and ran through 2/25/25: https://mailarchive.ietf.org/arch/msg/lsr/ZwIM6WMSxCD_rK9AscMrh-iXZAs/

* Routing Directorate (RtgDir) Review
Mach Chen (RtgDir) reviewed the latest version and supported moving the document forward: https://mailarchive.ietf.org/arch/msg/lsr/b_n-bmCPn5mP3XNOI6BxDZl2E5k/
Aijun Wang later claimed that the issue of "undefined key information" remained, despite Mach confirming that his comments were resolved.
Aijun received no support from the community for this claim.

* Operations Directorate (OpsDir) Review
Aijun raised the same issue again with the OpsDir reviewer (Giuseppe Fioccola): https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/
Giuseppe responded clearly that he did not see this as an issue: https://mailarchive.ietf.org/arch/msg/lsr/enMwFsdMVrf5OKmD1tpJmRaM-Ww/
All OpsDir comments were resolved: https://mailarchive.ietf.org/arch/msg/lsr/vqys_yHDKB82BkIXvioEN0QW0nY/

* Repeated Concerns Raised During IETF LC
Aijun raised the same concern again: https://mailarchive.ietf.org/arch/msg/lsr/gPal2AYQklSE-WqUrYJd0SeuweI/
Les Ginsberg provided a detailed response:
https://mailarchive.ietf.org/arch/msg/lsr/vXF0iQunncuynpYAivR-J9gk0Po/
https://mailarchive.ietf.org/arch/msg/lsr/dC90EMogM576isGtWFiglgi0Haw/

* Further Review & Additional Responses
Adrian Farrel conducted an additional RtgDir review: https://mailarchive.ietf.org/arch/msg/lsr/xcvA31trLlzEv58ZEwHOZatzZFM/
Email exchanges between Adrian and Les addressed all comments, with clarifications added to the text.
Aijun sent the same concern to Adrian, who responded with a clear, detailed explanation with examples demonstrating why Aijun’s statement was incorrect:
(Aijun’s Email) - https://mailarchive.ietf.org/arch/msg/lsr/T9xtkFS84LrgWcOh1nx_GJtS9ic/
(Adrian’s Detailed Response) (Highly recommended for understanding TLV parsing in IS-IS) - https://mailarchive.ietf.org/arch/msg/lsr/nArqDW_dh7KUV7QTO57SLGPn-BY/
Joel Halpern also supported Adrian’s response: https://mailarchive.ietf.org/arch/msg/lsr/7Xb1_8tfaG0pyqldWAbZHt1AIOE/
Despite these responses, Aijun continued to insist that his question was unanswered: https://mailarchive.ietf.org/arch/msg/lsr/o5aSnMPOpSm_i2WYss8ISbbQ_y0/

* Security Directorate (SecDir) Review
David Mandelberg conducted the SecDir LC review: https://mailarchive.ietf.org/arch/msg/lsr/z_eZLksvKvwZIuJROotAcK7fNR4/
Aijun contacted David, asking to block the document’s progress: https://mailarchive.ietf.org/arch/msg/lsr/nvFrXRZ0OukexdyZE6q7WweIVi8/
David did not respond, and no further concerns were raised from SecDir.

4)
Aijun submitted a new draft with the same argument trying to stop the progress of draft-ietf-lsr-multi-tlv: https://mailarchive.ietf.org/arch/msg/lsr/fowS2U5NEYx_7m8xW5gtvPxnLmI/
Acee Lindem's response as WG chair: https://mailarchive.ietf.org/arch/msg/lsr/4VqiVl1H72ErMACCNbeCKpW8nnw/ It clearly stated that the WG had reached consensus and we were not going to spend more time discuss these "challenges".
John Drake's response supporting the WG consensus: https://mailarchive.ietf.org/arch/msg/lsr/JQZurX3dgR0fNsDHXjRat3J38Y4/


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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/

Before the formal appeal, Aijun raised the issue to the responsible AD and it was closed by the AD:
https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of existing registries.
All registries already have designated experts assigned.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/

3) IETF LC Summary & Conclusion:

Throughout the IETF Last Call, Aijun repeatedly raised the same issue, despite it being addressed multiple times during both the Working Group Last Call (WGLC) and IETF LC. He challenged every directorate review, but received no support for his argument from the community, WG experts, or directorate reviewers.

* Publication Request & IETF LC Timeline
Publication was requested on 2/10/25: https://mailarchive.ietf.org/arch/msg/lsr/ud5_YmvjshH75KD6vlfIOt5Ibbk/
IETF Last Call (LC) was issued on 2/11/25 and ran through 2/25/25: https://mailarchive.ietf.org/arch/msg/lsr/ZwIM6WMSxCD_rK9AscMrh-iXZAs/

* Routing Directorate (RtgDir) Review
Mach Chen (RtgDir) reviewed the latest version and supported moving the document forward: https://mailarchive.ietf.org/arch/msg/lsr/b_n-bmCPn5mP3XNOI6BxDZl2E5k/
Aijun Wang later claimed that the issue of "undefined key information" remained, despite Mach confirming that his comments were resolved.
Aijun received no support from the community for this claim.

* Operations Directorate (OpsDir) Review
Aijun raised the same issue again with the OpsDir reviewer (Giuseppe Fioccola): https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/
Giuseppe responded clearly that he did not see this as an issue: https://mailarchive.ietf.org/arch/msg/lsr/enMwFsdMVrf5OKmD1tpJmRaM-Ww/
All OpsDir comments were resolved: https://mailarchive.ietf.org/arch/msg/lsr/vqys_yHDKB82BkIXvioEN0QW0nY/

* Repeated Concerns Raised During IETF LC
Aijun raised the same concern again: https://mailarchive.ietf.org/arch/msg/lsr/gPal2AYQklSE-WqUrYJd0SeuweI/
Les Ginsberg provided a detailed response:
https://mailarchive.ietf.org/arch/msg/lsr/vXF0iQunncuynpYAivR-J9gk0Po/
https://mailarchive.ietf.org/arch/msg/lsr/dC90EMogM576isGtWFiglgi0Haw/

* Further Review & Additional Responses
Adrian Farrel conducted an additional RtgDir review: https://mailarchive.ietf.org/arch/msg/lsr/xcvA31trLlzEv58ZEwHOZatzZFM/
Email exchanges between Adrian and Les addressed all comments, with clarifications added to the text.
Aijun sent the same concern to Adrian, who responded with a clear, detailed explanation with examples demonstrating why Aijun’s statement was incorrect:
(Aijun’s Email) - https://mailarchive.ietf.org/arch/msg/lsr/T9xtkFS84LrgWcOh1nx_GJtS9ic/
(Adrian’s Detailed Response) (Highly recommended for understanding TLV parsing in IS-IS) - https://mailarchive.ietf.org/arch/msg/lsr/nArqDW_dh7KUV7QTO57SLGPn-BY/
Joel Halpern also supported Adrian’s response: https://mailarchive.ietf.org/arch/msg/lsr/7Xb1_8tfaG0pyqldWAbZHt1AIOE/
Despite these responses, Aijun continued to insist that his question was unanswered: https://mailarchive.ietf.org/arch/msg/lsr/o5aSnMPOpSm_i2WYss8ISbbQ_y0/

* Security Directorate (SecDir) Review
David Mandelberg conducted the SecDir LC review: https://mailarchive.ietf.org/arch/msg/lsr/z_eZLksvKvwZIuJROotAcK7fNR4/
Aijun contacted David, asking to block the document’s progress: https://mailarchive.ietf.org/arch/msg/lsr/nvFrXRZ0OukexdyZE6q7WweIVi8/
David did not respond, and no further concerns were raised from SecDir.

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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/

Before the formal appeal, Aijun raised the issue to the responsible AD and it was closed by the AD:
https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of existing registries.
All registries already have designated experts assigned.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/

3) IETF LC Summary & Conclusion:

Throughout the IETF Last Call, Aijun repeatedly raised the same issue, despite it being addressed multiple times during both the Working Group Last Call (WGLC) and IETF LC. He challenged every directorate review, but received no support for his argument from the community, WG experts, or directorate reviewers.

Publication Request & IETF LC Timeline
Publication was requested on 2/10/25: https://mailarchive.ietf.org/arch/msg/lsr/ud5_YmvjshH75KD6vlfIOt5Ibbk/
IETF Last Call (LC) was issued on 2/11/25 and ran through 2/25/25: https://mailarchive.ietf.org/arch/msg/lsr/ZwIM6WMSxCD_rK9AscMrh-iXZAs/

Routing Directorate (RtgDir) Review
Mach Chen (RtgDir) reviewed the latest version and supported moving the document forward: https://mailarchive.ietf.org/arch/msg/lsr/b_n-bmCPn5mP3XNOI6BxDZl2E5k/
Aijun Wang later claimed that the issue of "undefined key information" remained, despite Mach confirming that his comments were resolved.
Aijun received no support from the community for this claim.

Operations Directorate (OpsDir) Review
Aijun raised the same issue again with the OpsDir reviewer (Giuseppe Fioccola): https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/
Giuseppe responded clearly that he did not see this as an issue: https://mailarchive.ietf.org/arch/msg/lsr/enMwFsdMVrf5OKmD1tpJmRaM-Ww/
All OpsDir comments were resolved: https://mailarchive.ietf.org/arch/msg/lsr/vqys_yHDKB82BkIXvioEN0QW0nY/

Repeated Concerns Raised During IETF LC
Aijun raised the same concern again: https://mailarchive.ietf.org/arch/msg/lsr/gPal2AYQklSE-WqUrYJd0SeuweI/
Les Ginsberg provided a detailed response:
https://mailarchive.ietf.org/arch/msg/lsr/vXF0iQunncuynpYAivR-J9gk0Po/
https://mailarchive.ietf.org/arch/msg/lsr/dC90EMogM576isGtWFiglgi0Haw/
Further Review & Additional Responses
Adrian Farrel conducted an additional RtgDir review: https://mailarchive.ietf.org/arch/msg/lsr/xcvA31trLlzEv58ZEwHOZatzZFM/
Email exchanges between Adrian and Les addressed all comments, with clarifications added to the text.
Aijun sent the same concern to Adrian, who responded with a clear, detailed explanation with examples demonstrating why Aijun’s statement was incorrect:
(Aijun’s Email) - https://mailarchive.ietf.org/arch/msg/lsr/T9xtkFS84LrgWcOh1nx_GJtS9ic/
(Adrian’s Detailed Response) (Highly recommended for understanding TLV parsing in IS-IS) - https://mailarchive.ietf.org/arch/msg/lsr/nArqDW_dh7KUV7QTO57SLGPn-BY/
Joel Halpern also supported Adrian’s response: https://mailarchive.ietf.org/arch/msg/lsr/7Xb1_8tfaG0pyqldWAbZHt1AIOE/
Despite these responses, Aijun continued to insist that his question was unanswered: https://mailarchive.ietf.org/arch/msg/lsr/o5aSnMPOpSm_i2WYss8ISbbQ_y0/

Security Directorate (SecDir) Review
David Mandelberg conducted the SecDir LC review: https://mailarchive.ietf.org/arch/msg/lsr/z_eZLksvKvwZIuJROotAcK7fNR4/
Aijun contacted David, asking to block the document’s progress: https://mailarchive.ietf.org/arch/msg/lsr/nvFrXRZ0OukexdyZE6q7WweIVi8/
David did not respond, and no further concerns were raised from SecDir.

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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/

Before the formal appeal, Aijun raised the issue to the responsible AD and it was closed by the AD:
https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of existing registries.
All registries already have designated experts assigned.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/

3) IETF LC Summary & Conclusion:

Throughout the IETF Last Call, Aijun repeatedly raised the same issue, despite it being addressed multiple times during both the Working Group Last Call (WGLC) and IETF LC. He challenged every directorate review, but received no support for his argument from the community, WG experts, or directorate reviewers.

Publication Request & IETF LC Timeline
Publication was requested on 2/10/25: https://mailarchive.ietf.org/arch/msg/lsr/ud5_YmvjshH75KD6vlfIOt5Ibbk/
IETF Last Call (LC) was issued on 2/11/25 and ran through 2/25/25: https://mailarchive.ietf.org/arch/msg/lsr/ZwIM6WMSxCD_rK9AscMrh-iXZAs/
Routing Directorate (RtgDir) Review
Mach Chen (RtgDir) reviewed the latest version and supported moving the document forward: https://mailarchive.ietf.org/arch/msg/lsr/b_n-bmCPn5mP3XNOI6BxDZl2E5k/
Aijun Wang later claimed that the issue of "undefined key information" remained, despite Mach confirming that his comments were resolved.
Aijun received no support from the community for this claim.
Operations Directorate (OpsDir) Review
Aijun raised the same issue again with the OpsDir reviewer (Giuseppe Fioccola): https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/
Giuseppe responded clearly that he did not see this as an issue: https://mailarchive.ietf.org/arch/msg/lsr/enMwFsdMVrf5OKmD1tpJmRaM-Ww/
All OpsDir comments were resolved: https://mailarchive.ietf.org/arch/msg/lsr/vqys_yHDKB82BkIXvioEN0QW0nY/
Repeated Concerns Raised During IETF LC
Aijun raised the same concern again: https://mailarchive.ietf.org/arch/msg/lsr/gPal2AYQklSE-WqUrYJd0SeuweI/
Les Ginsberg provided a detailed response:
https://mailarchive.ietf.org/arch/msg/lsr/vXF0iQunncuynpYAivR-J9gk0Po/
https://mailarchive.ietf.org/arch/msg/lsr/dC90EMogM576isGtWFiglgi0Haw/
Further Review & Additional Responses
Adrian Farrel conducted an additional RtgDir review: https://mailarchive.ietf.org/arch/msg/lsr/xcvA31trLlzEv58ZEwHOZatzZFM/
Email exchanges between Adrian and Les addressed all comments, with clarifications added to the text.
Aijun sent the same concern to Adrian, who responded with a clear, detailed explanation with examples demonstrating why Aijun’s statement was incorrect:
(Aijun’s Email) - https://mailarchive.ietf.org/arch/msg/lsr/T9xtkFS84LrgWcOh1nx_GJtS9ic/
(Adrian’s Detailed Response) (Highly recommended for understanding TLV parsing in IS-IS) - https://mailarchive.ietf.org/arch/msg/lsr/nArqDW_dh7KUV7QTO57SLGPn-BY/
Joel Halpern also supported Adrian’s response: https://mailarchive.ietf.org/arch/msg/lsr/7Xb1_8tfaG0pyqldWAbZHt1AIOE/
Despite these responses, Aijun continued to insist that his question was unanswered: https://mailarchive.ietf.org/arch/msg/lsr/o5aSnMPOpSm_i2WYss8ISbbQ_y0/
Security Directorate (SecDir) Review
David Mandelberg conducted the SecDir LC review: https://mailarchive.ietf.org/arch/msg/lsr/z_eZLksvKvwZIuJROotAcK7fNR4/
Aijun contacted David, asking to block the document’s progress: https://mailarchive.ietf.org/arch/msg/lsr/nvFrXRZ0OukexdyZE6q7WweIVi8/
David did not respond, and no further concerns were raised from SecDir.

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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/

Before the formal appeal, Aijun raised the issue to the responsible AD and it was closed by the AD:
https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of existing registries.
All registries already have designated experts assigned.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-multi-tlv-10. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV registry on the IS-IS TLV Codepoints registry group located at:

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

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: MP-TLV Support for TLVs with implicit support
MP-TLV Applicability: N
Reference: [ RFC-to-be; Section 7.2 ]

IANA understands that the authors suggest a value of 30 for this registration.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the IS-IS TLV Codepoints registry group located at:

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

a number of registries will be modified to have a new column that indicates whether the MP-TLV procedures described in the draft under consideration are applicable to that codepoint. There are fourteen registries affected by this modification and all of them are in the IS-IS TLV Codepoints registry group.

What follows are the modifications to each of the fourteen registries:

First, in the IS-IS Top-Level TLV Codepoints registry:

Value Name MP
-------+---------------------------------------------------+---
0 Reserved
1 Area Addresses N
2 IIS Neighbors N
3 ES Neighbors N
4 Part. DIS N
5 Prefix Neighbors N
6 IIS Neighbors N
7 Instance Identifier Y
8 Padding N
9 LSP Entries N
10 Authentication N
11 ESN TLV N
12 Opt. Checksum N
13 Purge Originator Identification N
14 LSPBufferSize N
15 Router-Fingerprint N
16 Reverse Metric N
17 IS-IS Area Node IDs TLV N
18 IS-IS Flooding Path TLV N
19 IS-IS Flooding Request TLV N
20 Area Proxy N
21 Flooding Parameters TLV N
22 Extended IS reachability Y
23 IS Neighbor Attribute Y
24 IS Alias ID N
25 L2 Bundle Member Attributes Y
26 Unassigned
27 SRv6 Locator Y
28 Zone ID N
29-41 Unassigned
42 DECnet Phase IV N
43-65 Unassigned
66 Lucent Proprietary N
67-125 Unassigned
126 IPv4 Algorithm Prefix Reachability TLV N
127 IPv6 Algorithm Prefix Reachability TLV N
128 IP Int. Reach N
129 Prot. Supported N
130 IP Ext. Address N
131 IDRPI N
132 IP Intf. Address N
133 Illegal N
134 Traffic Engineering router ID N
135 Extended IP reachability Y
136 Unassigned
137 Dynamic Name N
138 GMPLS-SRLG Y
139 IPv6 SRLG N
140 IPv6 TE Router ID N
141 inter-AS reachability information Y
142 GADDR-TLV Y
143 MT-Port-Cap-TLV Y
144 MT-Capability TLV Y
145 TRILL Neighbor TLV N
146 Unassigned
147 MAC-RI TLV Y
148 BFD-Enabled TLV Y
149 Segment Identifier / Label Binding Y
150 Multi-Topology Segment Identifier / Label Binding Y
151-160 Unassigned
161 Flood Reflection N
162-175 Unassigned
176 Nortel Proprietary N
177 Nortel Proprietary N
178-210 Unassigned
211 Restart TLV N
212-221 Unassigned
222 MT-ISN Y
223 MT IS Neighbor Attribute Y
224-228 Unassigned
229 M-Topologies N
230-231 Unassigned
232 IPv6 Intf. Addr. N
233 IPv6 Global Interface Address TLV N
234 Unassigned
235 MT IP. Reach Y
236 IPv6 IP. Reach Y
237 MT IPv6 IP. Reach Y
238 Application-Specific SRLG Y
239 Unassigned
240 P2P 3-Way Adj. State N
241 Unassigned
242 IS-IS Router CAPABILITY TLV Y
243 Scope Flooding Support N
244-250 Unassigned
251 Generic Information Y
252-65535 Unassigned

Second, in the IS-IS Sub-TLVs for Reverse Metric TLV registry:

Value Name MP
-------+---------------------------+---
0 Reserved
1-17 Unassigned
18 Traffic Engineering Metric N
19-255 Unassigned

Third, in the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry:

Value Name MP
-------+----------------------------------------------------+---
0-2 Unassigned
3 Administrative group (color) N
4 Link Local/Remote Identifiers N
5 Unassigned
6 IPv4 interface address N
7 Unassigned
8 IPv4 neighbor address N
9 Maximum link bandwidth N
10 Maximum reservable link bandwidth N
11 Unreserved bandwidth N
12 IPv6 Interface Address N
13 IPv6 Neighbor Address N
14 Extended Administrative Group N
15 Link MSD Y
16 Application-Specific Link Attributes Y
17 Generic Metric N
18 TE Default metric N
19 Link-attributes N
20 Link Protection Type N
21 Interface Switching Capability Descriptor Y
22 Bandwidth Constraints N
23 Unconstrained TE LSP Count (sub-)TLV N
24 Remote AS Number N
25 IPv4 Remote ASBR Identifier N
26 IPv6 Remote ASBR Identifier N
27 Interface Adjustment Capability Descriptor (IACD) Y
28 MTU N
29 SPB-Metric N
30 SPB-A-OALG Y
31 Adjacency Segment Identifier N
32 LAN Adjacency Segment Identifier N
33 Unidirectional Link Delay N
34 Min/Max Unidirectional Link Delay N
35 Unidirectional Delay Variation N
36 Unidirectional Link Loss N
37 Unidirectional Residual Bandwidth N
38 Unidirectional Available Bandwidth N
39 Unidirectional Utilized Bandwidth N
40 RTM Capability N
41 L2 Bundle Member Adj-SID Y
42 L2 Bundle Member LAN Adj-SID Y
43 SRv6 End.X SID Y
44 SRv6 LAN End.X SID Y
45 IPv6 Local ASBR Identifier N
46-160 Unassigned
161 Flood Reflector Adjacency N
162-249 Unassigned
250-254 Reserved for Cisco-specific extensions
255 Reserved for future expansion

Fourth, in the IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability registry:

Value Name MP
-------+----------------------------------+---
0 Unassigned
1 32-bit Administrative Tag Sub-TLV Y
2 64-bit Administrative Tag Sub-TLV Y
3 Prefix Segment Identifier N
4 Prefix Attribute Flags N
5 SRv6 End SID Y
6 Flexible Algorithm Prefix Metric (FAPM) N
7-10 Unassigned
11 IPv4 Source Router ID N
12 IPv6 Source Router ID N
13-31 Unassigned
32 BIER Info Y
32-255 Unassigned

Fifth, in the IS-IS Sub-TLVs for MT-Capability TLV registry:

Value Name MP
-------+-------------------------------+---
0 Reserved
1 SPB-Inst N
2 SPB-I-OALG Y
3 SPBM-SI Y
4 SPBV-ADDR Y
5 Unassigned
6 NICKNAME Y
7 TREES N
8 TREE-RT-IDs Y
9 TREE-USE-IDs Y
10 INT-VLAN Y
11-12 Unassigned
13 TRILL-VER N
14 VLAN-GROUP Y
15 INT-LABEL Y
16 RBCHANNELS Y
17 AFFINITY Y
18 LABEL-GROUP Y
19-20 Unassigned
21 Topology sub-TLV Y
22 Hop sub-TLV N
23 Bandwidth Constraint sub-TLV N
24 Bandwidth Assignment sub-TLV N
25 Timestamp sub-TLV N
26-254 Unassigned
255 Reserved

Sixth, in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV registry:

Value Name MP
-------+-------------------------------------------------------------+---
0 Reserved
1 TE Node Capability Descriptor N
2 Segment Routing Capability N
3 TE-MESH-GROUP TLV (IPv4) Y
4 TE-MESH-GROUP TLV (IPv6) Y
5 PCED sub-TLV N
6 NICKNAME Y
7 TREES N
8 TREE-RT-IDs Y
9 TREE-USE-IDs Y
10 INT-VLAN Y
11 IPv4 TE Router ID N
12 IPv6 TE Router ID N
13 TRILL-VER N
14 VLAN-GROUP Y
15 INT-LABEL Y
16 RBCHANNELS Y
17 AFFINITY Y
18 LABEL-GROUP Y
19 Segment Routing Algorithm N
20 S-BFD Discriminators N
21 Node-Admin-Tag N
22 Segment Routing Local Block (SRLB) N
23 Node MSD Y
24 Segment Routing Mapping Server Preference (SRMS Preference) N
25 SRv6 Capabilities N
26 Flexible Algorithm Definition (FAD) N
27 IS-IS Area Leader Sub-TLV N
28 IS-IS Dynamic Flooding Sub-TLV N
29 IP Algorithm Sub-TLV N
30-160 Unassigned
161 Flood Reflection Discovery Y
162-255 Unassigned

Seventh, in the IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV registry:

Value Name MP
-------+-----------+---
0 Reserved
1-255 Unassigned

Eighth, in the IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV registry:

Value Name MP
------+--------------------------+---
0 Unassigned
1 BIER MPLS Encapsulation N
2-255 Unassigned

Ninth, in the IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs registry:

Value Name MP
-------+---------------------------+---
0 Reserved
1 SID/Label N
2 Unassigned
3 Prefix Segment Identifier N
4-255 Unassigned

Tenth, in the IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes:

Value Name MP
------+------------------------------------+---
0-2 Unassigned
3 Administrative group (color) N
4-8 Unassigned
9 Maximum link bandwidth N
10 Maximum reservable link bandwidth N
11 Unreserved bandwidth N
12-13 Unassigned
14 Extended Administrative Group N
15-16 Unassigned
17 Generic Metric Y
18 TE Default Metric N
19-32 Unassigned
33 Unidirectional Link Delay N
34 Min/Max Unidirectional Link Delay N
35 Unidirectional Delay Variation N
36 Unidirectional Link Loss N
37 Unidirectional Residual Bandwidth N
38 Unidirectional Available Bandwidth N
39 Unidirectional Utilized Bandwidth N
40-255 Unassigned

Eleventh, in the IS-IS Sub-TLVs for Application-Specific SRLG TLV registry:

Value Name MP
-------+-------------------------------+---
0-3 Unassigned
4 Link Local/Remote Identifiers N
5 Unassigned
6 IPv4 interface address N
7 Unassigned
8 IPv4 neighbor address N
9-11 Unassigned
12 IPv6 Interface Address N
13 IPv6 Neighbor Address N
14-255 Unassigned

Twelveth, in the IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs registry:

Value Name MP
-------+--------------------+---
0 Reserved
1 SRv6 SID Structure N
2-255 Unassigned

Thirteenth, in the IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV registry:

Value Name MP
-------+--------------------------------------------+---
0 Reserved
1 Flexible Algorithm Exclude Admin Group N
2 Flexible Algorithm Include-Any Admin Group N
3 Flexible Algorithm Include-All Admin Group N
4 Flexible Algorithm Definition Flags N
5 Flexible Algorithm Exclude SRLG N
6 IS-IS Exclude Minimum Bandwidth N
7 IS-IS Exclude Maximum Delay N
8 IS-IS Reference Bandwidth N
9 IS-IS Threshold Metric N
10-255 Unassigned

Fourteenth, in the IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV registry:

Value Name MP
-------+-----------------------------------------------------------+---
0-160 Unassigned
161 Flood Reflection Discovery Tunnel Encapsulation Attribute N
162-255 Unassigned

We understand that these are the only actions 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/


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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/

Before the formal appeal, Aijun raised the issue to the responsible AD and it was closed by the AD:
https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of existing registries.
All registries already have designated experts assigned.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

The following Last Call announcement was sent out (ends 2025-02-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lsr-multi-tlv@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org, yingzhen.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multi-part TLVs in IS-IS) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Multi-part TLVs in IS-IS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-25. 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


  New technologies are adding new information into IS-IS while
  deployment scales are simultaneously increasing, causing the contents
  of many critical TLVs to exceed the currently supported limit of 255
  octets.  Extensions exist that require significant IS-IS changes that
  could help address the problem, but a less drastic solution would be
  beneficial.  This document codifies the common mechanism of extending
  the TLV content space through multiple TLVs.




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



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

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/


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

Yes. Aijun Wang appealed on November 6, 2024:
https://mailarchive.ietf.org/arch/msg/lsr/r8_cD6VFK0AJnY-VMvFUVcsmKrw/
https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

The IESG had reviewed the working group's processing of the document and found that
the records didn't support the claimed defects. Hence the appeal was denied. Here is
a link to Roman's appeal response email:
https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:

v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/


In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is not clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

1)
There was a discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/

Suggestion from Bruno (https://mailarchive.ietf.org/arch/msg/lsr/YBYQtO4XvnidSQ8DnwcS2C52F34/):

Section 7.1

"It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. "

Possibly changing RECOMMENDED to REQUIRED


To resolve this comment, the authors made the following text change in Version -06:
v -05:
Implementations SHOULD report alarms under the following conditions:

v -06:
Implementations which support disablement of MP-TLVs MUST report 
alarms under the following conditions:

And this is the email reply from Les: https://mailarchive.ietf.org/arch/msg/lsr/leroGjztny0UdSoendvFj7YQkNM/

In my mind there is a difference between defining what is necessary to guarantee interoperability and defining what makes things easier to use (or - if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to want them to be treated the same. I don’t agree with this – not least because “easy to use” is a very subjective criteria. People may legitimately have very different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol advertisements which deviate from the expected content in some way – and it does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
  alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.


Considering there are implementations from multiple vendors that follow the mechanism defined in this document without the explicit configuration, which means a router may send MP-TLV without explicit enablement, changing from "RECOMMNDED" to "REQUIRED" is not going to help with interoperability.

2)
Whether it's necessary to explicitly define keys for all TLVs that support MP-TLV.
There was suggestion of enumerating keys for all code points. However, although the word "key" is introduced in this draft, the concept of a key in an IS-IS TLV is not new. It's essential to correctly parse ISIS LSDB.

Ketan's email about specifying the "key": https://mailarchive.ietf.org/arch/msg/lsr/SAdZH7D3Y7PTLxdLBT86-sIS87U/

The key of a TLV is implicitly defined:
https://mailarchive.ietf.org/arch/msg/lsr/pH7M4MBfg1FFKI4hsLlnqQ_dn60/
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
https://mailarchive.ietf.org/arch/msg/lsr/8_m_WBo9NJ1jovWuYDTT8O-29xA/
Reply from Chris explain well this is how TLVs are parsed in ISIS today:
https://mailarchive.ietf.org/arch/msg/lsr/11c9Cg2AgF5zCRDTnSb35zQisvk/

Ketan's reply later in the thread clarifying why he's supporting the publication of this draft after he went through some TLVs and convinced himself that it's not necessary to specify all the keys: https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/

So far people who think the key is under specified have not been able to provide an example, where the definition of an existing TLV is clear. The working grouping is aware that there might be interoperability issue with the proposal, and it's clearly articulated in the draft. Henk's email did a very well summarization: https://mailarchive.ietf.org/arch/msg/lsr/ph0bXIg7SXX4MNW1G0oKQOkrCG4/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document multiple times.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and they all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, multi vendors. There are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects
this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was discussion about whether the configuration control should be enforced,
"SHOULD" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. Although there are implementations that already follow the mechanism defined
in this document for some existing TLVs. To date, no one has implemented the
configuration option referenced in #2.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects
this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

During both the adoption call and the WGLC, this draft has gone through long
discussions. The majority of the WG agrees with solution.
WGLC: https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/
Adoption call: https://mailarchive.ietf.org/arch/msg/lsr/V4r9wJuDA1Wl9wMEXRyX3MtQMxk/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was discussion about whether the configuration control should be enforced,
"SHOULd" vs. "MUST".
email archive: https://mailarchive.ietf.org/arch/msg/lsr/dTCbe0H8V9S_9sHyIhL_lxMzEsQ/


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

Yes. https://mailarchive.ietf.org/arch/msg/lsr/chsd1CLQ9lvvWtz3Zi50pPeTUDU/
https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. Although there are implementations that already follow the mechanism defined
in this document for some existing TLVs.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

A Routing Directorate and OPS directorate review have been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - I've reviewed the document.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The IETF stream is Proposed Standard. This is correct for a document that
codifies the common mechanism of extending the TLV content space through
multiple TLVs and the Datatracker reflects
this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was answered by all authors and contributors during the WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The author list had been reduced to five authors and all have contributed to the
document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the document nits have been addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16]

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section and new code points have been reviewed.
This document requests IANA to add a column to a number of "IS-IS TLV Codepoints"
registries and a code point from IS-IS Sub-TLVs for IS-IS Router Capability TLV.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

A new column is added to a number of registries, that requires Designated Expert
Review. Suggested expert: Chris Hopps and Hannes Gredler.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed to previous authors: Chris Bowers , Les Ginsberg , Parag Kaneriya , Shraddha Hegde , Tony Li , Tony Przygienda , lsr-chairs@ietf.org

Request for posting confirmation emailed  to submitter and authors: Chris Bowers , Les Ginsberg , Parag Kaneriya , Shraddha Hegde , Tony Li , Tony Przygienda