Rob -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Robert Wilton via Datatracker
> Sent: Tuesday, July 14, 2020 2:25 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> Christian Hopps ; aretana.i...@gmail.com;
> cho...@chopps.org
> Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02:
> (with COMMENT)
>
> 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."
>
[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".
> 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?
[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
>
> Regards,
> Rob
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
