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

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke 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:
----------------------------------------------------------------------

I know very little about this, but just checking:
- I trust that a network that mixes routers that use application attributes,
and not, will not lead to long-term routing loops in spite of them not having a
common picture of the network?

- It is odd that a link that advertises a zero-length flags field means support
for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? When is
it OK to use a zero-length flags field given this ambiguity? In a standard, can
we not decide on a meaning to eliminate the uncertainty? I would appreciate
some language here to answer at least the first two questions.

- as the TSVart review points out, the length field wastes 3 bits of 7 because
the maximum length is 8. You could reserve them or even use them to encode
these three legacy applications.

Nits:

Abstract:
In “these link attributes for a given attribute” add a comma after both
instances of attribute(s)

Sec 4 2)Application. Add a space

Sec 5. Missing a period at the end of “existence of link attribute
advertisements”