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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

I'm glad to see language clarifying error handling.  Thanks for the work on it.

Section 3.2.  Per “It is RECOMMENDED that implementations provide controls for
the enablement of behaviors that are not backward compatible”, I want to double
check that I’m understanding this  sentence correctly. RFC5304 provides
normative guidance that isn’t backward compatible with ISO10589. RFC6233
provide guidance that isn’t backward compatible with either RFC5304 or
ISO10589.  Is the initial sentence effectively saying that implementations
should support deployments in configurations that are not backward compatible
(i.e., those using the newer TLVs)?  As these changes are covering security
matters, I read “controls” in the cyber mitigation sense -- they prevent an
action, not enable one.