[Lsr] [Errata Rejected] RFC8919 (6630)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 14 May 2022 00:58 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
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 752E6C1D3C70; Fri, 13 May 2022 17:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekbhLf7ReJps; Fri, 13 May 2022 17:58:08 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33799C1D3C73; Fri, 13 May 2022 17:58:08 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 0EEBB6A9C8; Fri, 13 May 2022 17:58:08 -0700 (PDT)
To: ginsberg@cisco.com, ginsberg@cisco.com, ppsenak@cisco.com, stefano@previdi.net, wim.henderickx@nokia.com, jdrake@juniper.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: jgs@juniper.net, iesg@ietf.org, lsr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220514005808.0EEBB6A9C8@rfcpa.amsl.com>
Date: Fri, 13 May 2022 17:58:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PHsPe8xLVaLbK2qIpScIjwzQl1Q>
Subject: [Lsr] [Errata Rejected] RFC8919 (6630)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.34
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: Sat, 14 May 2022 00:58:12 -0000

The following errata report has been rejected for RFC8919,
"IS-IS Application-Specific Link Attributes".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6630

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Les Ginsberg <ginsberg@cisco.com>
Date Reported: 2021-07-05
Rejected by: John Scudder (IESG)

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.
 --VERIFIER NOTES-- 
It would be more appropriate to pursue this as an update or bis RFC, see discussion at https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/

--------------------------------------
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