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. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
