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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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

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?


Lsr mailing list

Reply via email to