I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-teep-protocol-21 Reviewer: Paul Kyzivat Review Date: 2025-10-15 IETF LC End Date: 2025-10-20 IESG Telechat date: ? This draft is on the right track but has open issues, described in the review. ISSUES: 4 NITS: 3 1) ISSUE: TEEP Message token lifetime The processing of TEEP messages, discussed in sections 4.1.1, 4.2.2, and 7.1, calls for assigning unique token values, using them to match responses to requests, expiring them and preventing reuse. This potentially could require unbounded storage to track them. Presumably that is not the intent. Since the purpose of these tokens is to match a request to the first response, it seems likely that it is unanswered requests, including the token, that need to be stored. Since the protocol calls for dropping messages that fail certain checks, it is presumably possible that some requests will never receive a response. To handle this, message senders need some mechanism to eventually drop unanswered requests. But this is not mentioned in the document. I suggest you add a discussion of the need to have a timeout on messages awaiting responses. This could then also address token uniqueness and lifetime. 2) ISSUE: The range of err-code values The CDDL definition of the update message in section 4.4 includes: "err-code => (0..23)," The CDDL definition of specific values leaves values 0,11-16,18-23 unassigned. I gather the value 23 is chosen because it is the max integer value that can be encoded in a single byte in CBOR encoding. If that is important, is there a way to decouple the value symbolically, rather than hard coding "23"? Why not instead restrict it symbolically to defined err code values? And then, *encourage* extensions to stay below 23. I guess nothing catastrophic would happen if some err-codes were assigned values greater than 23. Why is 0 unassigned? Is it intentionally reserved? Would anything bad happen if it were assigned? This seems worthy of explanation. 3) ISSUE: The range of TEEP Message Parameter labels Section 6 (The Mapping of TEEP Message Parameters to CBOR Labels), like err-code, seems to intend that message labels be restricted to [0..23], presumably for concise encoding as CBOR integers. It appears only 0,5,22 remain unassigned. Is there a plan if more values are needed in the future? Is 0 assignable? (If it is reserved, it would be good to say something about that.) Would anything bad happen if future parameters were assigned values greater than 23? 4) ISSUE: Unqualified use of SHOULD This document contains many SHOULDs that lack any qualification of circumstances that would justify violating the SHOULD. Many implementers treat such conditions as entirely optional to implement. I suggest that all uses of SHOULD include discussion of what would justify failing to comply, and the implications of doing so. 5) NIT: Definition of version 0 The explanation of message fields in section 4.2 says this about 'versions': "A value of 0 refers to the current version of the TEEP protocol." This is pretty vague. I gather you mean the version of the protocol defined by *this* document. Can you please be more explicit about this? 6) NIT: Editor instructions Appendix C includes the following ; DO NOT EDIT this cddl file manually. ; This cddl file is Auto-generated file from md file. ; Edit the md file and run make for generating this cddl file. ; Please do not forget to commit and push this cddl file to git repo ; every time you have revised the md file. This works while this document is a draft. But what is to happen once this becomes an RFC? Will the md format even be available during production of the RFC? I suggest you plan for this and provide guidance. 7) NIT: IdNits stuff The IdNits tool reports a number of errors. Some of them are spurious, but a couple are not: ** There are 43 instances of too long lines in the document, the longest one being 88 characters in excess of 72. These all seem to be in examples. You will need to find a way to fold these. == Outdated reference: ... There are a bunch of these. I trust they will eventually be updated.