[tram] Mirja Kühlewind's Yes on draft-ietf-tram-stunbis-16: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-stunbis-16: Yes

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-tram-stunbis/



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

1) Maybe it would make sense to refer informationally to
draft-ietf-tram-stun-pmtud in section 6.1?

2)  sec 6.2.2: This sentence seems to assume that only one request is sent per
TCP connection/each request sends out after a new SYN: "However, for a
request/response transaction, if the client has not
   received a response by Ti seconds after it sent the SYN to establish
   the connection, it considers the transaction to have timed out.“
i don’t think that assumption would be correct. Maybe rephrase this sentence…?

3) Also section 6.2.2: Should the client send keep-alives if a connection is
hold open but currently not used? If not, I guess further recommendation is
needed to address the case where a transmission fails because an existing idle
TCP connection was used that doesn’t work anymore. In this case, I'd say the
recommendation would be to send a RST and try to open a new TCP connection.

4) Should section 9.2 maybe provide further guidance on the lifetime of the
(server-selected) nonce?

5) I'm sure, I just missed something but how does a server know if a first
request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1.
and 9.2.4 I guess). Or is this pre-configured?

6) Section 6.3 says that this doc only specifies the procedures for the new
spec in this document and subsequently says: "It checks [...] that the magic
cookie field has the correct value..." However, given this spec obsoletes
RFC5389, I think that section 11 should provide more guidance on how to handle
"old" STUN messages. Or is the intention that an upgraded STUN server does not
handle old requests anymore? If so that should be spelled out as well.

7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy
value." Should the dummy value be further specified? Also it looks like there
was a compile problem on page 39. Is there text missing?

8) sec 17.6: Isn't "stuns  5349/upd" used for DTLS? If so, it should be
registered!