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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 14 Jul 2020 02:24:49 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 Jul 2020 16:51:50 +0000

Rob -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Robert Wilton via Datatracker <[email-masked]>
> Sent: Tuesday, July 14, 2020 2:25 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Christian Hopps <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02:
> (with COMMENT)
> 
[Les:] I have no objection to the wording change.  

But, I do find your interpretation that "an implementation which receives...is non-compliant" a bit pedantic (no offense intended).
Clearly an implementation cannot control what it receives. 😊
But I agree your proposed wording change is more "traditional".

> update to that YANG model?

[Les:] Note that the wording of this has been revised based on recent comments and now speaks to future instances as well as existing ones. But to answer your question, this isn’t just "one thing".  For each non-backwards compatible behavior I would expect that an implementation would need to provide a separate control. So coverage in a YANG model is going to be on a feature-by-feature basis. There is no one generic "backwards-compatible-knob" that will suffice.

More details I leave to the team that will be working on extensions to the base protocol YANG model.

   Les