Subject: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 14:10:46 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-isis-invalid-tlv-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The shepherd writeup is a bit unclear as to why Proposed Standard is the
right document status (vs., e.g., Informational).  I guess it's desired
to have the Updates: relationship to the indicated documents, which
essentially forces it to be standards-track.  On the other hand, perhaps
the sense that ignoring a TLV that is specifically disallowed (as
opposed to "merely" unrecognized) is itself a newly specified
requirement, in which case the status as Proposed Standard makes sense
for that reason.  It might be worth a little more clarity on which (if
either) of these scenarios are intended.

Section 1

   A corollary to ignoring unknown TLVs is having the validation of PDUs
   be independent from the validation of the TLVs contained in the PDU.

nit: this doesn't exactly seem like a "corollary" specifically, but
rather a choice that [ISO10589] made (and which keeps some overall sense
of consistency between PDU and TLV handling).

Section 3.1

   [ISO10589] defines the behavior required when a PDU is received
   containing a TLV which is "not recognised".  It states (see Sections
   9.3 - 9.13):

This is Sections 9.5 (not 9.3) to 9.13 in the copy I have.

Section 3.2

   Similarly, the extensions defined by [RFC6233] are not compatible
   with the behavior defined in [RFC5304], therefore can only be safely
   enabled when all nodes support the extensions.

nit: I'd argue that technically the extensions are *defined* by 6232, even
though 6233 is what makes their nature (as "allowed in purge") easily
discoverable.

   It is RECOMMENDED that implementations provide controls for the
   enablement of behaviors that are not backward compatible.

We also specifically want the ability to generate but not
process/require at least some of them, right?  Is that worth calling out
in addition to just "controls for the enablement"?

Section 3.3

   a given sub-TLV is allowed.  Section 2 of [RFC5305] is updated by the
   following sentence:

      "As with TLVs, it is required that sub-TLVs which
       are disallowed MUST be ignored on receipt.".

Do we want to say where this logical insertion occurs?

Section 3.4

   The correct setting for "LSP" is "n".  This document updates
   [RFC6232] by correcting that error.

It's slightly interesting that there doesn't seem to be a corresponding
Errata Report (but may not be worth doing anything about given that this
update is about to be approved).

Section 8.1

It's not entirely clear that RFC 7356 is referenced in a normative
manner.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 13 Jul 2020 23:05:35 +0000

Ben -

Thanx for your review.

Responses inline.

> -----Original Message-----

> From: Benjamin Kaduk via Datatracker <[email-masked]>

> Sent: Monday, July 13, 2020 2:11 PM

> To: The IESG <[email-masked]>

> Cc: [email-masked]; [email-masked]; [email-masked];

> Christian Hopps <[email-masked]>; [email-masked];

> [email-masked]

> Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with

> COMMENT)

[Les:] What prompted the writing of this document was a real world interoperability scenario wherein one implementation generated a malformed TLV and a receiving implementation rejected the entire PDU because of it. This resulted in persistent LSPDB inconsistency in the network for a prolonged period with a significant impact on the proper functioning of the network. This failure was considered significant enough that Standards Track seemed appropriate.

As the document developed, the authors were encouraged to address some other issues, one of which was clarifying disallowed TLV handling as well.

I can understand why Informational track may seem appropriate to you. In early discussions with Alvaro I had suggested that there was no need to write the document - that existing specifications were sufficiently clear. But the fact that - despite existing standards - such an interoperability issue did occur was compelling. The WG also embraced this as useful.

[Les:] Rejecting a PDU because of some issue with a single TLV would mean that the full set of updates contained in that LSP would not be propagated. This has a significant impact on the correct operation of the protocol. So I think this really isn’t an option.

[Les:] Well spotted. I see you have put your newly acquired  copy of ISO 10589 to good use. Bravo!! 😊

[Les:] Fair enough. I will change this to RFC6232 - which is one of documents updated by this draft.

> in addition to just "controls for the enablement"?

[Les:] This sentence is serving as a guideline for new behaviors that have backwards compatibility issues. New information which could be safely sent in the presence of legacy routers does not fall into this category.

[Les:] As this is not modifying existing text in any way, I am not sure that it is necessary to do so.

I can envision adding this to the end of the first paragraph or creating a new paragraph.

Unless we are actually going to create a BIS draft, I am not sure that it matters.

??

> update is about to be approved).

[Les:] The error was found during the writing of this draft.

[Les:] I will move it to Informational.

   Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Jul 2020 16:23:37 -0700

Hi Les,

> Thanx for your review.

My pleasure; this is a nice document.  (A shame it's needed, of course, but
that's neither here nor there.)

> I can understand why Informational track may seem appropriate to you. In early discussions with Alvaro I had suggested that there was no need to write the document - that existing specifications we…

Thanks for the extra explanation.  I think PS makes sense, and the only
text change I might (emphasis: *might*) consider is to emphasize that the
"occurrence of non-conformant behavior seen in real world deployments" is
decidedly not hypothetical.  But I could understand if the current text is
seen to be saying that already, too.

> [Les:] Rejecting a PDU because of some issue with a single TLV would mean that the full set of updates contained in that LSP would not be propagated. This has a significant impact on the correct op…

I agree that doing anything else would have been a bad idea!  I was just
suggesting that a different word might be preferred (but am not trying to
press the issue).
> [Les:] Well spotted. I see you have put your newly acquired  copy of ISO 10589 to good use. Bravo!! 😊

Indeed; it was quite helpful to be able to follow along.

> [Les:] This sentence is serving as a guideline for new behaviors that have backwards compatibility issues. New information which could be safely sent in the presence of legacy routers does not fall…

That makes sense, though now I wonder if I was misreading the quoted
snippet.  I assumed it was meant to refer to how 5304 is not compatible to
ISO10589, and 6233 is not compatible to 5304, and giving specific guidance
for implementing those two RFCs.  But it also makes sense if it's a
forward-looking thing for any future changes that are
backwards-incompatible.  Perhaps a similarly generic:

% When new protocol behaviors are specified that are not backwards
% compatible, it is RECOMMENDED that implementations provide controls for
% their enablement to allow for incremental implementation deployment and a
% smooth transition.

Anyways, up to you.

> Unless we are actually going to create a BIS draft, I am not sure that it matters.

It probably doesn't matter.  I'm just remembering that something similar
got discussed in the past (IIRC, for an NFSv4 document).

> [Les:] The error was found during the writing of this draft.

Ah, I see :)

> [Les:] I will move it to Informational.

Thanks for the updates,

Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 Jul 2020 03:39:55 +0000

Ben -

I have prepared V3 of the draft to address your comments.
As the window for draft submissions is temporarily closed, I have attached the diffs for your review.

I will post the updated version once the window for submissions reopens.

A few more remarks inline.

> From: Benjamin Kaduk <[email-masked]>
> Sent: Monday, July 13, 2020 4:24 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; lsr-
> [email-masked]; [email-masked]; Christian Hopps <[email-masked]>;
> [email-masked]
> Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with
> COMMENT)
> 
> Hi Les,
> 
> > [Les:] What prompted the writing of this document was a real world
> interoperability scenario wherein one implementation generated a
> malformed TLV and a receiving implementation rejected the entire PDU
> because of it. This resulted in persistent LSPDB inconsistency in the network
> for a prolonged period with a significant impact on the proper functioning of
> the network. This failure was considered significant enough that Standards
> Track seemed appropriate.
> >
> >
> >
> > As the document developed, the authors were encouraged to address
> some other issues, one of which was clarifying disallowed TLV handling as
> well.
> >
> >
> >
> > I can understand why Informational track may seem appropriate to you. In
> early discussions with Alvaro I had suggested that there was no need to write
> the document - that existing specifications were sufficiently clear. But the
> fact that - despite existing standards - such an interoperability issue did occur
> was compelling. The WG also embraced this as useful.
> 
[Les:] There is mention in the Abstract that " deployment experience has
   shown..."

> > [Les:] Rejecting a PDU because of some issue with a single TLV would mean
> that the full set of updates contained in that LSP would not be propagated.
> This has a significant impact on the correct operation of the protocol. So I
> think this really isn’t an option.
> 

[Les:] I have reworded this to indicate this is more than just a "corollary".

> > [Les:] This sentence is serving as a guideline for new behaviors that have
> backwards compatibility issues. New information which could be safely sent
> in the presence of legacy routers does not fall into this category.
> 
[Les:] I have used a modified version of your text. Thanx for the suggestion - and let me know if the revised wording is to your liking.

     Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Jul 2020 21:14:14 -0700

Hi Les,

Looks good, thanks for making these tweaks.  (I was about to write
"hopefully final" but I see that half the IESG still has to weigh in ... so
I can't really expect this to be the last word quite yet.)

-Ben

>        < draft-ietf-lsr-isis-invalid-tlv-02.txt                 draft-ietf-lsr-isis-invalid-tlv-03.txt >        
>  LSR Working Group L. Ginsberg                           LSR Working Group L. Ginsberg                          
>  Internet-Draft P. Wells                                 Internet-Draft P. Wells                                
>  Updates: 5305 6232 (if approved) Cisco Systems          Updates: 5305 6232 (if approved) Cisco Systems         
>  Intended status: Standards Track T. Li                  Intended status: Standards Track T. Li                 
>  Expires: December 24, 2020 Arista Networks              Expires: January 14, 2021 Arista Networks              
>  T. Przygienda                                           T. Przygienda                                          
>  S. Hegde                                                S. Hegde                                               
>  Juniper Networks, Inc.                                  Juniper Networks, Inc.                                 
>  June 22, 2020                                           July 13, 2020                                          
>  Invalid TLV Handling in IS-IS                           Invalid TLV Handling in IS-IS                          
>  draft-ietf-lsr-isis-invalid-tlv-02                      draft-ietf-lsr-isis-invalid-tlv-03                     
>  Abstract                                                Abstract                                               
>  Key to the extensibility of the Intermediate System to  Key to the extensibility of the Intermediate System to 
>  Intermediate                                            Intermediate                                           
>  System (IS-IS) protocol has been the handling of        System (IS-IS) protocol has been the handling of       
>  unsupported and/or                                      unsupported and/or                                     
>  invalid Type/Length/Value (TLV) tuples. Although there  invalid Type/Length/Value (TLV) tuples. Although there 
>  are explicit                                            are explicit                                           
>  statements in existing specifications, deployment       statements in existing specifications, deployment      
>  experience has                                          experience has                                         
>  shown that there are inconsistencies in the behavior    shown that there are inconsistencies in the behavior   
>  when a TLV which                                        when a TLV which                                       
>  is disallowed in a particular Protocol Data Unit (PDU)  is disallowed in a particular Protocol Data Unit (PDU) 
>  is received.                                            is received.                                           
>  This document discusses such cases and makes the        This document discusses such cases and makes the       
>  correct behavior                                        correct behavior                                       
>  explicit in order to insure that interoperability is    explicit in order to ensure that interoperability is   
>  maximized.                                              maximized.                                             
>  This document updates RFC5305 and RFC6232.              This document updates RFC5305 and RFC6232.             
>  Requirements Language                                   Requirements Language                                  
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
>  "SHALL NOT",                                            "SHALL NOT",                                           
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT             "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT            
>  RECOMMENDED", "MAY", and                                RECOMMENDED", "MAY", and                               
>  "OPTIONAL" in this document are to be interpreted as    "OPTIONAL" in this document are to be interpreted as   
>  described in BCP                                        described in BCP                                       
>  14 [RFC2119] [RFC8174] when, and only when, they        14 [RFC2119] [RFC8174] when, and only when, they       
>  appear in all                                           appear in all                                          
>  capitals, as shown here.                                capitals, as shown here.                               
>         skipping to change at page 2, line 7 P:                 skipping to change at page 2, line 7 P:         
>  Internet-Drafts are working documents of the Internet   Internet-Drafts are working documents of the Internet  
>  Engineering                                             Engineering                                            
>  Task Force (IETF). Note that other groups may also      Task Force (IETF). Note that other groups may also     
>  distribute                                              distribute                                             
>  working documents as Internet-Drafts. The list of       working documents as Internet-Drafts. The list of      
>  current Internet-                                       current Internet-                                      
>  Drafts is at                                            Drafts is at                                           
>  https://datatracker.ietf.org/drafts/current/.           https://datatracker.ietf.org/drafts/current/.          
>  Internet-Drafts are draft documents valid for a         Internet-Drafts are draft documents valid for a        
>  maximum of six months                                   maximum of six months                                  
>  and may be updated, replaced, or obsoleted by other     and may be updated, replaced, or obsoleted by other    
>  documents at any                                        documents at any                                       
>  time. It is inappropriate to use Internet-Drafts as     time. It is inappropriate to use Internet-Drafts as    
>  reference                                               reference                                              
>  material or to cite them other than as "work in         material or to cite them other than as "work in        
>  progress."                                              progress."                                             
>  This Internet-Draft will expire on December 24, 2020.   This Internet-Draft will expire on January 14, 2021.   
>  Copyright Notice                                        Copyright Notice                                       
>  Copyright (c) 2020 IETF Trust and the persons           Copyright (c) 2020 IETF Trust and the persons          
>  identified as the                                       identified as the                                      
>  document authors. All rights reserved.                  document authors. All rights reserved.                 
>  This document is subject to BCP 78 and the IETF         This document is subject to BCP 78 and the IETF        
>  Trust's Legal                                           Trust's Legal                                          
>  Provisions Relating to IETF Documents                   Provisions Relating to IETF Documents                  
>  (https://trustee.ietf.org/license-info) in effect on    (https://trustee.ietf.org/license-info) in effect on   
>  the date of                                             the date of                                            
>  publication of this document. Please review these       publication of this document. Please review these      
>  documents                                               documents                                              
>         skipping to change at page 2, line 35 P:                skipping to change at page 2, line 35 P:        
>  1. Introduction . . . . . . . . . . . . . . . . . . .   1. Introduction . . . . . . . . . . . . . . . . . . .  
>  . . . . . 2                                             . . . . . 2                                            
>  2. TLV Codepoints Registry . . . . . . . . . . . . . .  2. TLV Codepoints Registry . . . . . . . . . . . . . . 
>  . . . . . 3                                             . . . . . 3                                            
>  3. TLV Acceptance in PDUs . . . . . . . . . . . . . .   3. TLV Acceptance in PDUs . . . . . . . . . . . . . .  
>  . . . . . 4                                             . . . . . 4                                            
>  3.1. Handling of Disallowed TLVs in Received PDUs       3.1. Handling of Disallowed TLVs in Received PDUs      
>  other than                                              other than                                             
>  LSP Purges . . . . . . . . . . . . . . . . . . . . . .  LSP Purges . . . . . . . . . . . . . . . . . . . . . . 
>  . 4                                                     . 4                                                    
>  3.2. Special Handling of Disallowed TLVs in Received    3.2. Special Handling of Disallowed TLVs in Received   
>  LSP                                                     LSP                                                    
>  Purges . . . . . . . . . . . . . . . . . . . . . . . .  Purges . . . . . . . . . . . . . . . . . . . . . . . . 
>  . 4                                                     . 4                                                    
>  3.3. Applicability to sub-TLVs . . . . . . . . . . . .  3.3. Applicability to sub-TLVs . . . . . . . . . . . . 
>  . . . . 5                                               . . . . 5                                              
>  3.4. Correction to POI TLV Registry Entry . . . . . .   3.4. Correction to POI TLV Registry Entry . . . . . .  
>  . . . . 5                                               . . . . 5                                              
>  4. TLV Validation and LSP Acceptance . . . . . . . . .  4. TLV Validation and LSP Acceptance . . . . . . . . . 
>  . . . . . 5                                             . . . . . 6                                            
>  5. IANA Considerations . . . . . . . . . . . . . . . .  5. IANA Considerations . . . . . . . . . . . . . . . . 
>  . . . . . 6                                             . . . . . 6                                            
>  6. Security Considerations . . . . . . . . . . . . . .  6. Security Considerations . . . . . . . . . . . . . . 
>  . . . . . 6                                             . . . . . 6                                            
>  7. Acknowledgements . . . . . . . . . . . . . . . . .   7. Acknowledgements . . . . . . . . . . . . . . . . .  
>  . . . . . 7                                             . . . . . 7                                            
>  8. References . . . . . . . . . . . . . . . . . . . .   8. References . . . . . . . . . . . . . . . . . . . .  
>  . . . . . 7                                             . . . . . 7                                            
>  8.1. Normative References . . . . . . . . . . . . . .   8.1. Normative References . . . . . . . . . . . . . .  
>  . . . . 7                                               . . . . 7                                              
>  8.2. Informative References . . . . . . . . . . . . .   8.2. Informative References . . . . . . . . . . . . .  
>  . . . . 8                                               . . . . 8                                              
>  Authors' Addresses . . . . . . . . . . . . . . . . . .  Authors' Addresses . . . . . . . . . . . . . . . . . . 
>  . . . . . 8                                             . . . . . 8                                            
>  1. Introduction                                         1. Introduction                                        
>  The Intermediate System to Intermediate System (IS-IS)  The Intermediate System to Intermediate System (IS-IS) 
>  protocol                                                protocol                                               
>  [ISO10589] utilizes Type/Length/Value (TLV) encoding    [ISO10589] utilizes Type/Length/Value (TLV) encoding   
>  for all content                                         for all content                                        
>  in the body of Protocol Data Units (PDUs). New          in the body of Protocol Data Units (PDUs). New         
>  extensions to the                                       extensions to the                                      
>  protocol are supported by defining new TLVs. In order   protocol are supported by defining new TLVs. In order  
>  to allow                                                to allow                                               
>  protocol extensions to be deployed in a backwards       protocol extensions to be deployed in a backwards      
>  compatible way an                                       compatible way an                                      
>  implementation is required to ignore TLVs that it does  implementation is required to ignore TLVs that it does 
>  not                                                     not                                                    
>  understand. This behavior is also applied to sub-TLVs   understand. This behavior is also applied to sub-TLVs  
>  [RFC5305],                                              [RFC5305],                                             
>  which are contained within TLVs.                        which are contained within TLVs.                       
>  A corollary to ignoring unknown TLVs is having the      Also essential to the correct operation of the         
>  validation of PDUs                                      protocol is having the                                 
>  be independent from the validation of the TLVs          validation of PDUs be independent from the validation  
>  contained in the PDU.                                   of the TLVs                                            
>  PDUs which are valid must be accepted [ISO10589] even   contained in the PDU. PDUs which are valid must be     
>  if an                                                   accepted                                               
>  individual TLV contained within that PDU is invalid in  [ISO10589] even if an individual TLV contained within  
>  some way                                                that PDU is not                                        
>  (e.g., incorrect syntax, data value out of range,       understood or is invalid in some way (e.g., incorrect  
>  etc.).                                                  syntax, data                                           
>                                                          value out of range, etc.).                             
>  The set of TLVs (and sub-TLVs) which are allowed in     The set of TLVs (and sub-TLVs) which are allowed in    
>  each PDU type is                                        each PDU type is                                       
>  documented in the TLV Codepoints Registry established   documented in the TLV Codepoints Registry established  
>  by [RFC3563]                                            by [RFC3563]                                           
>  and updated by [RFC6233] and [RFC7356].                 and updated by [RFC6233] and [RFC7356].                
>  This document is intended to clarify some aspects of    This document is intended to clarify some aspects of   
>  existing                                                existing                                               
>  specifications and thereby reduce the occurrence of     specifications and thereby reduce the occurrence of    
>  non-conformant                                          non-conformant                                         
>  behavior seen in real world deployments. Although       behavior seen in real world deployments. Although      
>  behaviors                                               behaviors                                              
>  specified in existing protocol specifications are not   specified in existing protocol specifications are not  
>  changed, the                                            changed, the                                           
>  clarifications contained in this document serve as      clarifications contained in this document serve as     
>  updates to RFC                                          updates to RFC                                         
>         skipping to change at page 4, line 15 P:                skipping to change at page 4, line 15 P:        
>  3. TLV Acceptance in PDUs                               3. TLV Acceptance in PDUs                              
>  This section describes the correct behavior when a PDU  This section describes the correct behavior when a PDU 
>  is received                                             is received                                            
>  which contains a TLV which is specified as disallowed   which contains a TLV which is specified as disallowed  
>  in the TLV                                              in the TLV                                             
>  Codepoints Registry.                                    Codepoints Registry.                                   
>  3.1. Handling of Disallowed TLVs in Received PDUs       3.1. Handling of Disallowed TLVs in Received PDUs      
>  other than LSP Purges                                   other than LSP Purges                                  
>  [ISO10589] defines the behavior required when a PDU is  [ISO10589] defines the behavior required when a PDU is 
>  received                                                received                                               
>  containing a TLV which is "not recognised". It states   containing a TLV which is "not recognised". It states  
>  (see Sections                                           (see Sections                                          
>  9.3 - 9.13):                                            9.5 - 9.13):                                           
>  "Any codes in a received PDU that are not               "Any codes in a received PDU that are not              
>  recognised shall be ignored."                           recognised shall be ignored."                          
>  This is the model to be followed when a TLV is          This is the model to be followed when a TLV is         
>  received which is                                       received which is                                      
>  disallowed. Therefore TLVs in a PDU (other than LSP     disallowed. Therefore TLVs in a PDU (other than LSP    
>  purges) which                                           purges) which                                          
>  are disallowed MUST be ignored and MUST NOT cause the   are disallowed MUST be ignored and MUST NOT cause the  
>  PDU itself to                                           PDU itself to                                          
>  be rejected by the receiving IS.                        be rejected by the receiving IS.                       
>  3.2. Special Handling of Disallowed TLVs in Received    3.2. Special Handling of Disallowed TLVs in Received   
>  LSP Purges                                              LSP Purges                                             
>         skipping to change at page 4, line 50 P:                skipping to change at page 4, line 50 P:        
>  other than the authentication TLV".                     other than the authentication TLV".                    
>  This behavior was extended by [RFC6232] which           This behavior was extended by [RFC6232] which          
>  introduced the Purge                                    introduced the Purge                                   
>  Originator Identification (POI) TLV and [RFC6233]       Originator Identification (POI) TLV and [RFC6233]      
>  which added the                                         which added the                                        
>  "Purge" column to the TLV Codepoints registry to        "Purge" column to the TLV Codepoints registry to       
>  identify all the                                        identify all the                                       
>  TLVs which are allowed in purges.                       TLVs which are allowed in purges.                      
>  The behavior specified in [RFC5304] is not backwards    The behavior specified in [RFC5304] is not backwards   
>  compatible with                                         compatible with                                        
>  the behavior defined by [ISO10589] and therefore can    the behavior defined by [ISO10589] and therefore can   
>  only be safely                                          only be safely                                         
>  enabled when all nodes support cryptographic            enabled when all nodes support cryptographic           
>  authentication.                                         authentication.                                        
>  Similarly, the extensions defined by [RFC6233] are not  Similarly, the extensions defined by [RFC6232] are not 
>  compatible                                              compatible                                             
>  with the behavior defined in [RFC5304], therefore can   with the behavior defined in [RFC5304], therefore can  
>  only be safely                                          only be safely                                         
>  enabled when all nodes support the extensions.          enabled when all nodes support the extensions.         
>  It is RECOMMENDED that implementations provide          When new protocol behaviors are specified that are not 
>  controls for the                                        backwards                                              
>  enablement of behaviors that are not backward           compatible, it is RECOMMENDED that implementations     
>  compatible.                                             provide controls                                       
>                                                          for their enablement. This serves to prevent           
>                                                          interoperability issues                                
>                                                          and allow for non-disruptive introduction of the new   
>                                                          functionality                                          
>                                                          into an existing network..                             
>  3.3. Applicability to sub-TLVs                          3.3. Applicability to sub-TLVs                         
>  [RFC5305] introduced sub-TLVs, which are TLV tuples     [RFC5305] introduced sub-TLVs, which are TLV tuples    
>  advertised within                                       advertised within                                      
>  the body of a parent TLV. Registries associated with    the body of a parent TLV. Registries associated with   
>  sub-TLVs are                                            sub-TLVs are                                           
>  associated with the TLV Codepoints Registry and         associated with the TLV Codepoints Registry and        
>  specify in which TLVs                                   specify in which TLVs                                  
>  a given sub-TLV is allowed. Section 2 of [RFC5305] is   a given sub-TLV is allowed. Section 2 of [RFC5305] is  
>  updated by the                                          updated by the                                         
>  following sentence:                                     following sentence:                                    
>  "As with TLVs, it is required that sub-TLVs which       "As with TLVs, it is required that sub-TLVs which      
>         skipping to change at page 8, line 5 P:                 skipping to change at page 8, line 14 P:        
>  [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J.      [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J.     
>  Dong, "Purge                                            Dong, "Purge                                           
>  Originator Identification TLV for IS-IS", RFC 6232,     Originator Identification TLV for IS-IS", RFC 6232,    
>  DOI 10.17487/RFC6232, May 2011,                         DOI 10.17487/RFC6232, May 2011,                        
>  <https://www.rfc-editor.org/info/rfc6232>.              <https://www.rfc-editor.org/info/rfc6232>.             
>  [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry       [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry      
>  Extension for                                           Extension for                                          
>  Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,      Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,     
>  <https://www.rfc-editor.org/info/rfc6233>.              <https://www.rfc-editor.org/info/rfc6233>.             
>  [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang,      
>  "IS-IS Flooding                                        
>  Scope Link State PDUs (LSPs)", RFC 7356,               
>  DOI 10.17487/RFC7356, September 2014,                  
>  <https://www.rfc-editor.org/info/rfc7356>.             
>  [RFC8174] Leiba, B., "Ambiguity of Uppercase vs         [RFC8174] Leiba, B., "Ambiguity of Uppercase vs        
>  Lowercase in RFC                                        Lowercase in RFC                                       
>  2119 Key Words", BCP 14, RFC 8174, DOI                  2119 Key Words", BCP 14, RFC 8174, DOI                 
>  10.17487/RFC8174,                                       10.17487/RFC8174,                                      
>  May 2017, <https://www.rfc-editor.org/info/rfc8174>.    May 2017, <https://www.rfc-editor.org/info/rfc8174>.   
>  [TLV_CODEPOINTS]                                        [TLV_CODEPOINTS]                                       
>  IANA, "IS-IS TLV Codepoints web page                    IANA, "IS-IS TLV Codepoints web page                   
>  (https://www.iana.org/assignments/isis-tlv-codepoints/  (https://www.iana.org/assignments/isis-tlv-codepoints/ 
>  isis-tlv-codepoints.xhtml)".                            isis-tlv-codepoints.xhtml)".                           
>  8.2. Informative References                             8.2. Informative References                            
>  [RFC3359] Przygienda, T., "Reserved Type, Length and    [RFC3359] Przygienda, T., "Reserved Type, Length and   
>  Value (TLV)                                             Value (TLV)                                            
>  Codepoints in Intermediate System to Intermediate       Codepoints in Intermediate System to Intermediate      
>  System",                                                System",                                               
>  RFC 3359, DOI 10.17487/RFC3359, August 2002,            RFC 3359, DOI 10.17487/RFC3359, August 2002,           
>  <https://www.rfc-editor.org/info/rfc3359>.              <https://www.rfc-editor.org/info/rfc3359>.             
>                                                          [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang,      
>                                                          "IS-IS Flooding                                        
>                                                          Scope Link State PDUs (LSPs)", RFC 7356,               
>                                                          DOI 10.17487/RFC7356, September 2014,                  
>                                                          <https://www.rfc-editor.org/info/rfc7356>.             
>  Authors' Addresses                                      Authors' Addresses                                     
>  Les Ginsberg                                            Les Ginsberg                                           
>  Cisco Systems                                           Cisco Systems                                          
>  Email: [email-masked]                               Email: [email-masked]                              
>  Paul Wells                                              Paul Wells                                             
>  Cisco Systems                                           Cisco Systems                                          
>                                        End of changes. 12 change blocks. 
>               20 lines changed or deleted                              24 lines changed or added                
>                This html diff was produced by rfcdiff 1.47. The latest version is available from
>                                       http://tools.ietf.org/tools/rfcdiff/