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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lsr-multi-tlv@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org, rfc-editor@rfc-editor.org, yingzhen.ietf@gmail.com
Subject: Protocol Action: 'Multi-Part TLVs in IS-IS' to Proposed Standard (draft-ietf-lsr-multi-tlv-18.txt)

The IESG has approved the following document:
- 'Multi-Part TLVs in IS-IS'
  (draft-ietf-lsr-multi-tlv-18.txt) as Proposed Standard

This document is the product of the Link State Routing Working Group.

The IESG contact persons are Gunter Van de Velde, Jim Guichard and Ketan
Talaulikar.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/

Ballot Text

Technical Summary

   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.

Working Group Summary

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

There have been two main areas of debate:
* Worries about operational interop, which found consensus solution by adding text in the draft to mandate alarms and strongly encourages implementers to provide configuration knobs to enable/disable multi-part TLVs  
* Intense debate about what constitutes as a ISIS TLV/sub-TLV "key". The WG debated and landed upon a rough consensus during WGLC where all perspectives were debated and investigated. The single person who disagreed and was in the rough, filed an appeal (November 6, 2024) which was declined by IESG (January 24, 2025).
* Shepherd report has been updated with the narrative of the document evolution through WGLC and IETF LC 

Document Quality

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

Document quality is good and details the Working Group rough consensus

Personnel

   The Document Shepherd for this document is Yingzhen Qu. The Responsible
   Area Director is Gunter Van de Velde.

RFC Editor Note