Change:
connTimeout <del> Numeric, with special value "Disabled" </del> <ins> Numeric or "Disabled" </ins> <del> Disabled </del> <ins> "Disabled" </ins> <del> This property specifies how long to wait before deciding that an active Connection has failed when trying to reliably deliver data to the Remote Endpoint.  Adjusting this Property will only take effect when the underlying stack supports reliability.  The special value "Disabled" means that no timeout is scheduled. </del> <ins> If this property is Numeric, it specifies how long to wait before deciding that an active Connection has failed when trying to reliably deliver data to the Remote Endpoint.  Adjusting this Property will only take effect when the underlying stack supports reliability.  If this property has the enumerated value "Disabled", it means that no timeout is scheduled. </ins> 8.1.4. keepAliveTimeout <del> Numeric, with special value "Disabled" </del> <ins> Numeric or "Disabled" </ins> Implementation-defined A Transport Services API can request a protocol that supports sending <del> keep alive packets keep-alive.  This property specifies the maximum length of time an idle connection (one for which no transport packets have been sent) should wait before the Local Endpoint sends a keep- alive packet to the Remote Endpoint.  Adjusting this Property will only take effect when the underlying stack supports sending keep- alive packets.  Guidance on setting this value for datagram transports is provided in RFC8085.  A value greater than the connection timeout (conn-timeout), or the special value "Disabled", will disable the sending of keep-alive packets. </del> <ins> keep alive packets keep-alive.  If this property is an Integer, it specifies the maximum length of time an idle connection (one for which no transport packets have been sent) should wait before the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this value for datagram transports is provided in RFC8085.  A value greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets. </ins> 8.1.5.

Discussion:
This replacement for PR was discussed at the last interim.
5 from this . Slightly modified as a result of . Should “Type” line also include (non-negative) like s9.1.3.2 does? Just trying to be matchy-matchy.
3 from this . This issue was addressed via . I included this only for completeness. Close at your leisure. I read this definition a bunch. Are there two special values? The Type line says “Full Coverage” is special, but then the description says “0” is special too. Maybe look at s91.3.6 for inspiration?
This issue on coverage is resolved in the latest.
I cringe at systems that define Integers to be integers and some other enumerated things ("special values"). Is it necessary to define things this way? I understand it's currently typical to have this behavior in the APIs of the protocols this system is attempting to abstract, but is it impossible to stop propagating that kind of type confusion? This API could move the things special values are being used for into separate arguments for example.
This only appears to be used for checksum coverage; don't overload integer for this application.
Use type enumerations instead. Some languages let you do this. Otherwise you just pick an out-of-range integern.
The "special value" also shows up for numeric in 8.1.3, 8.1.4, 8.1.8 and 8.1.9
We discussed this in the last interim, but I don't think the tuple-based approach in works well, and prefer the type enumeration suggestion NAME made. That is, don't say: rather say:
ACK - already in my todo list...
In the interface draft, section 1.1: Do we need to conflate numeric types and enumerations, or can numbers be numbers?
From interim: add a clarification on what this is about, why it (symbolic values) is there.
Fixed by Reviewer: Sean Turner Review result: Has Issues This is an early sector review. Based on the ARTART early reviews of this I-D and the -arch I-D, there is no doubt going to need to be another review after the authors get done restructuring both I-Ds. BTW: Theresa thank you for the heads up about that restructuring.

It forced me to read the -arch and -impl I-Ds, but that probably helped me not make silly requests of the authors/WG. tl;dr: I picked "has issues" knowing there is a rewrite on the way and I would like to reserve final judgement until then. I apologize upfront because I am going to ramble a bit before I get to the specifics: The taps I-Ds are about “a protocol-independent Transport Services Application Programming Interface (API).” I took a pretty liberal approach when reviewing this I-D from a security perspective because these I-Ds are somewhat different than the “normal” protocol I-Ds. As noted in the -arch I-D: these I-Ds do not specify “specific protocols or algorithms” … gasp. But, that’s probably okay in this context. I wondered what you would say about an API: Apps need to use the API properly! check: see -arch I-D Implementation/Library needs to be from trust source! check: see -interface I-D - Apps need to use the right keys at the right time! check: see -arch I-D - Avoid fallback/downgrade to insecure protocols! check: see -arch I-D and -impl I-D - Deal with 0-RTT! check: see -impl I-D - Address privacy aspects! check: see -interface I-D I mean maybe you could add something about: randomness for keys - but that better already be in the security protocol specifications so I do not think it is absolutely needed here. following good programming techniques - but I am not sure where you would point nor whether it really makes sense to do so. I think I found what I was looking for is somewhere in the stack of I-Ds. Am I worried somebody can implement this wrong. Sure. But, not any more than I would be for any other protocol. Now on to the specifics: NOTE: I tried not repeat anything from the ARTART review. 0) s6: maybe this wording would be better? For these two sentences are you trying to say that MUST else if? OLD: At least one Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but the list of Local Endpoints MAY be empty if the Preconnection is used to Initiate() connections.

NEW: At least one Remote Endpoint MUST be specified if the Preconnection is used to Initiate() Connections, but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen() for incoming Connections 1) s6.3.1 I know this is an example, but can we replace: SecurityParameters.Set(supported-group, "secp256k1") with SecurityParameters.Set(supported-group, "secp256r1") r1 the current MTI for TLS. k1 is for bitcoin :) Or, is this where I get a bitcoin because I caught the shiny object? :) 2) s6.3.2: Is this like checking the certificate status? 3) s8.1.1- I read this definition a bunch. Are there two special values? The Type line says “Full Coverage” is special, but then the description says “0” is special too. Maybe look at s91.3.6 for inspiration? 4) s8.1.2: Any reason it’s not called connPriority? Seems arbitrary to drop the end of the word when connTimeout is even longer. 5) s8.1.2-should “Type” line also include (non-negative) like s8.1.1 and s9.1.3.2 do? 6) s8.1.3/.4: The Numeric values specifies seconds, minutes, hours, or millennia? 7) s8.1.6: don’t you need to specify the Type? I guess Enumeration is what you’re after? 8) s8.1.11.2/.3/.4: Are these sizes in bytes too like 8.1.11.1? 9) s8.2.1: RFC 5482 allows granularity of minutes or seconds don’t you need to say which it is here? 10) s8.2.2: Is there some reason it’s not called tcp.userTimeoutEnabled? 11) s8.2.3: Is there some reason it’s not called tcp.userTimeoutChangable? 12) s9.1.3.2: Why 100? 13) s9.1.3.2: Why shorten to msrPrio when msgOrdered is almost as long and safelyReplayable is longer?

14) A.1: Could the caution about freeing memory be generalized? 15) What follows are the I-D nits references to check. Some of these might be on purpose: == Outdated reference: A later version (-11) exists of draft-ietf-taps-arch-10 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-priority-03 == Outdated reference: A later version (-10) exists of draft-ietf-taps-impl-09 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656)