Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx> writes:
> Because we believe that this is a problem that will become more and
> more frequent, we decided to fix it, at least for new implementations.
>
> Please have a look at -17 and let us know what you think of it.
It looks like you've handled the problem of a NAT that changes the
address family of the request as well as can be done.
You've clarified the question of how the security feature bits are
assigned, although I note that -16 and -17 assign the bits differently
than versions -7 through -15 do.
That completes all of the significant issues from my review of -16.
And there are some nits:
6.2.1. Sending over UDP or DTLS-over-UDP
SHOULD be greater or equal than 500 ms.
s/equal than/equal to/.
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP
To do that, it follows the
identification procedures defined in [RFC6125], with a certificate
containing an identifier of type DNS-ID or CN-ID, eventually with
wildcards, but not of type SRV-ID or URI-ID.
The meaning of "eventually" here is not clear.
14. STUN Attributes
The
padding bits MUST be set to zero on sending and must be ignored by
the receiver.
I assume the latter "must" is supposed to be "MUST".
14.13. UNKNOWN-ATTRIBUTES
Note: In [RFC3489], this field was padded to 32 by duplicating the
last attribute. In this version of the specification, thPetriNet
m --> PetriNet m --> e normal padding rules for attributes are
used instead.
I assume that "thPetriNet m --> PetriNet m --> e" is intended to be
"the".
Appendix C. Release notes
Section C.8 has the same contents as section C.9, but section C.9 has
the same title as section C.10. (Although section C will be removed
before publication, so it's not important.)
Dale
