Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-isis-invalid-tlv-02: Yes

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 shepherd writeup is a bit unclear as to why Proposed Standard is the
right document status (vs., e.g., Informational).  I guess it's desired
to have the Updates: relationship to the indicated documents, which
essentially forces it to be standards-track.  On the other hand, perhaps
the sense that ignoring a TLV that is specifically disallowed (as
opposed to "merely" unrecognized) is itself a newly specified
requirement, in which case the status as Proposed Standard makes sense
for that reason.  It might be worth a little more clarity on which (if
either) of these scenarios are intended.

Section 1

   A corollary to ignoring unknown TLVs is having the validation of PDUs
   be independent from the validation of the TLVs contained in the PDU.

nit: this doesn't exactly seem like a "corollary" specifically, but
rather a choice that [ISO10589] made (and which keeps some overall sense
of consistency between PDU and TLV handling).

Section 3.1

   [ISO10589] defines the behavior required when a PDU is received
   containing a TLV which is "not recognised".  It states (see Sections
   9.3 - 9.13):

This is Sections 9.5 (not 9.3) to 9.13 in the copy I have.

Section 3.2

   Similarly, the extensions defined by [RFC6233] are not compatible
   with the behavior defined in [RFC5304], therefore can only be safely
   enabled when all nodes support the extensions.

nit: I'd argue that technically the extensions are *defined* by 6232, even
though 6233 is what makes their nature (as "allowed in purge") easily
discoverable.

   It is RECOMMENDED that implementations provide controls for the
   enablement of behaviors that are not backward compatible.

We also specifically want the ability to generate but not
process/require at least some of them, right?  Is that worth calling out
in addition to just "controls for the enablement"?

Section 3.3

   a given sub-TLV is allowed.  Section 2 of [RFC5305] is updated by the
   following sentence:

      "As with TLVs, it is required that sub-TLVs which
       are disallowed MUST be ignored on receipt.".

Do we want to say where this logical insertion occurs?

Section 3.4

   The correct setting for "LSP" is "n".  This document updates
   [RFC6232] by correcting that error.

It's slightly interesting that there doesn't seem to be a corresponding
Errata Report (but may not be worth doing anything about given that this
update is about to be approved).

Section 8.1

It's not entirely clear that RFC 7356 is referenced in a normative
manner.



_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to