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” _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
