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

[Benjamin Kaduk <[e-mail]>]

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

On Tue, Jul 14, 2020 at 03:39:55AM +0000, Les Ginsberg (ginsberg) wrote:
> 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.
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <[e-mail]>
> > Sent: Monday, July 13, 2020 4:24 PM
> > To: Les Ginsberg (ginsberg) <[e-mail]>
> > Cc: The IESG <[e-mail]>; [e-mail]; lsr-
> > [e-mail]; [e-mail]; Christian Hopps <[e-mail]>;
> > [e-mail]
> > Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with
> > COMMENT)
> > 
> > Hi Les,
> > 
> > On Mon, Jul 13, 2020 at 11:05:35PM +0000, Les Ginsberg (ginsberg) wrote:
> > > Ben -
> > >
> > >
> > >
> > > 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.)
> > 
> > > Responses inline.
> > >
> > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Benjamin Kaduk via Datatracker <[e-mail]>
> > >
> > > > Sent: Monday, July 13, 2020 2:11 PM
> > >
> > > > To: The IESG <[e-mail]>
> > >
> > > > Cc: [e-mail]; [e-mail]; [e-mail];
> > >
> > > > Christian Hopps <[e-mail]>; [e-mail];
> > >
> > > > [e-mail]
> > >
> > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with
> > >
> > > > COMMENT)
> > >
> > > >
> > >
> > > > 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.
> > >
> > > >
> > >
> > > [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.
> > 
> > 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:] There is mention in the Abstract that " deployment experience has
>    shown..."
> 
> > >
> > >
> > > > 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).
> > >
> > > >
> > >
> > > [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.
> > 
> > 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:] I have reworded this to indicate this is more than just a "corollary".
> 
> > >
> > >
> > >
> > >
> > > > 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.
> > >
> > > >
> > >
> > > [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.
> > 
> > >
> > >
> > > > 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.
> > >
> > > >
> > >
> > > [Les:] Fair enough. I will change this to RFC6232 - which is one of documents
> > updated by this draft.
> > >
> > >
> > >
> > > >    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"?
> > >
> > >
> > >
> > > [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.
> > 
> > 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.
> >
> [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
>  
> 
> > Anyways, up to you.
> > 
> > >
> > >
> > > >
> > >
> > > > 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?
> > >
> > > >
> > >
> > > [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.
> > >
> > > ??
> > 
> > It probably doesn't matter.  I'm just remembering that something similar
> > got discussed in the past (IIRC, for an NFSv4 document).
> > 
> > >
> > >
> > > > 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).
> > >
> > >
> > >
> > > [Les:] The error was found during the writing of this draft.
> > 
> > Ah, I see :)
> > 
> > >
> > >
> > > >
> > >
> > > > Section 8.1
> > >
> > > >
> > >
> > > > It's not entirely clear that RFC 7356 is referenced in a normative
> > >
> > > > manner.
> > >
> > > >
> > >
> > > >
> > >
> > >
> > >
> > > [Les:] I will move it to Informational.
> > 
> > Thanks for the updates,
> > 
> > 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: [e-mail]                               Email: [e-mail]                              
>  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/