Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[[e-mail] (Dale R. Worley)]

Marc Petit-Huguenin <[e-mail]> 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