IETF Last Call Review of draft-ietf-teep-protocol-21
review-ietf-teep-protocol-21-genart-lc-kyzivat-2025-10-15-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.