Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 14:39:32 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-isis-te-app-14: 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-isis-te-app/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in length.
The SABM Length field represents that length and has 7 bits to do that. 
However, the maximum number of bits needed to represent 8 is only 4 bits. 
What’s the thinking on those three extra bits?  Should they be marked as
reserved?  I would have the same question for the UDABM mask.

** Section 6.2.  I didn’t follow what it means to send the sub-TLV in Section
4.2 with a zero length SABM Length and UDABM Length – that is two empty
bitmasks?  Is that permitted?  What would it convey?

** Section 8.  Per “Tampering with the information defined in this document may
have an effect on applications using it, including impacting Traffic
Engineering.”, I have no disagreement with this statement.  However, I would
recommend adding a brief statement what is the security impact of “impacting
Traffic Engineering”.

** Section 8.  Per “This is similar in nature to the impacts associated  with
(for example) [RFC5305]”, what specific text in RFC5305 was envisioned?  The
SecCon section (Section 6) of RFC5305 contains only one sentence that points to
RFC5304?

** Editorial
-- Section 3.  Editorial.  Consider providing a reference for the registries
instead of an inline URL.

-- Section 4.1.  The rendering of the sub-TLV diagram was split between Page 6
and 7 when this draft is read in TXT format.  IMO, it would be more readable if
it was on one page.

-- Per Section 4.1.  Editorial.  Per “See the following section for a
description …”, please explicitly name the section.

-- Section 4.2.  Typo. s/Identifer/Identifier/