[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Tue, 14 July 2020 09:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569653A0775; Tue, 14 Jul 2020 02:24:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lsr-isis-invalid-tlv@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com, chopps@chopps.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <159471868933.24921.14877121564881281834@ietfa.amsl.com>
Date: Tue, 14 Jul 2020 02:24:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ULqY3oQpTwhhFpbR3UBGDVpIeSI>
Subject: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 Jul 2020 09:24:49 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-invalid-tlv-02: No Objection

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 document is short and easy to read, thanks!  However, I was sure whether I
should put a DISCUSS on this document for section 3.4.

I find that the quoted paragraph from RFC6232 to be badly worded:

      "The POI TLV SHOULD be found in all purges and
       MUST NOT be found in LSPs with a non-zero
       Remaining Lifetime."

Taking a strict reading of this, my interpretation is that an implementation is
not compliant to RFC 6232 if it happens to receive a POI TLV in an LSP with
non-zero remaining lifetime!  Further, this text then arguably conflicts with
earlier parts of this document regarding how unrecognized or bad TLVs should be
handled.

Hence, given that RFC6232 is being updated, I would prefer it if this document
also updated RFC6232 to clarify the above paragraph to something like:

      "The POI TLV SHOULD be sent in all purges and
       MUST NOT be sent in LSPs with a non-zero
       Remaining Lifetime."

One other minor comment:

    It is RECOMMENDED that implementations provide controls for the enablement
    of behaviors that are not backward compatible.

Is this covered by the existing ISIS YANG model, or included in the latest
update to that YANG model?

Regards,
Rob