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 <[email protected]> > > Sent: Monday, July 13, 2020 4:24 PM > > To: Les Ginsberg (ginsberg) <[email protected]> > > Cc: The IESG <[email protected]>; [email protected]; lsr- > > [email protected]; [email protected]; Christian Hopps <[email protected]>; > > [email protected] > > 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 <[email protected]> > > > > > > > Sent: Monday, July 13, 2020 2:11 PM > > > > > > > To: The IESG <[email protected]> > > > > > > > Cc: [email protected]; [email protected]; > > > > [email protected]; > > > > > > > Christian Hopps <[email protected]>; [email protected]; > > > > > > > [email protected] > > > > > > > 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: [email protected] Email: > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
