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 <ka...@mit.edu>
> > Sent: Monday, July 13, 2020 4:24 PM
> > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> > Cc: The IESG <i...@ietf.org>; draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-
> > cha...@ietf.org; lsr@ietf.org; Christian Hopps <cho...@chopps.org>;
> > aretana.i...@gmail.com
> > 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 <nore...@ietf.org>
> > >
> > > > Sent: Monday, July 13, 2020 2:11 PM
> > >
> > > > To: The IESG <i...@ietf.org>
> > >
> > > > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; 
> > > > lsr@ietf.org;
> > >
> > > > Christian Hopps <cho...@chopps.org>; aretana.i...@gmail.com;
> > >
> > > > cho...@chopps.org
> > >
> > > > 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: ginsb...@cisco.com                               Email: 
> ginsb...@cisco.com                              
>  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/


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to