[Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Deborah Brungard via Datatracker <[e-mail]>]

Deborah Brungard has entered the following ballot position for
draft-ietf-isis-te-app-14: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.


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

I found this document a bit easier to read than the OSPF one. Though it also
seems (implementation) confused on 1:1 association of signaling over a link
with data use of the link and so the confusion on what application to support
on the link. As I noted on the OSPF one, it would be much clearer to simply
discuss the main problem (to me) - the ability to support advertisement of
application specific values?

I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.