Thank you. See inline. On 05/03/2018 06:32 PM, Dale R. Worley wrote: > 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/. Applied. > > 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. Rephrased as: [...] containing an identifier of type DNS-ID or CN-ID, eventually with a wildcard character as leftmost label, but not of type SRV-ID or URI- [...] > > 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". Fixed. > > 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". Fixed. > > 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.) Fixed. -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature
