[Lsr] [Technical Errata Reported] RFC8919 (6630)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 05 July 2021 21:47 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EC83A1CB2 for <lsr@ietfa.amsl.com>; Mon, 5 Jul 2021 14:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTxxPdRWleQ6 for <lsr@ietfa.amsl.com>; Mon, 5 Jul 2021 14:47:48 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D62A3A1CB0 for <lsr@ietf.org>; Mon, 5 Jul 2021 14:47:48 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1124AF40759; Mon, 5 Jul 2021 14:47:21 -0700 (PDT)
To: ginsberg@cisco.com, ppsenak@cisco.com, stefano@previdi.net, wim.henderickx@nokia.com, jdrake@juniper.net, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, acee@cisco.com, chopps@chopps.org
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ginsberg@cisco.com, lsr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210705214721.1124AF40759@rfc-editor.org>
Date: Mon, 05 Jul 2021 14:47:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/i_oz5jSXFqSomn94zJFM2zqs5uw>
Subject: [Lsr] [Technical Errata Reported] RFC8919 (6630)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 21:47:54 -0000
The following errata report has been submitted for RFC8919, "IS-IS Application-Specific Link Attributes". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6630 -------------------------------------- Type: Technical Reported by: Les Ginsberg <ginsberg@cisco.com> Section: GLOBAL Original Text ------------- Section 4.2: OLD If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. (Later in Section 4.2) OLD If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link that is associated with a non-zero-length Application Identifier Bit Mask with a matching Application Identifier Bit set. Section 6.2 OLD Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. Corrected Text -------------- Section 4.2 NEW If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. When SABM or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use the link attribute advertisements in the sub-TLV. (Later in Section 4.2) NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Section 6.2 NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Notes ----- RFC 8919 defines advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined ApplicationBit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8919 (draft-ietf-isis-te-app-19) -------------------------------------- Title : IS-IS Application-Specific Link Attributes Publication Date : October 2020 Author(s) : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake Category : PROPOSED STANDARD Source : Link State Routing Area : Routing Stream : IETF Verifying Party : IESG
- [Lsr] [Technical Errata Reported] RFC8919 (6630) RFC Errata System
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Acee Lindem (acee)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… bruno.decraene
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… bruno.decraene
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… bruno.decraene
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… bruno.decraene
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… Les Ginsberg (ginsberg)
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC8919 (66… bruno.decraene