[tram] draft-ietf-tram-stunbis

[Noriyuki Torii <[e-mail]>]

To whom it may concern.

I'm Noriyuki Torii. I have red the updated I-D of STUNbis-16 and found
some issues would like to be shared.

Hope this may help for improvement.

- Section 9.1.1 and 9.2.2 defines the HMAC key calculation based on some
  elements such that the password, username and realm.
  Sections say those elements should be proccessed using OpaqueString
profile
  defined in RFC8265.

  On the other hand, RFC8265 says in its "Changes from RFC 7613" that
     "Removed UTF-8 as a mandatory encoding, because that is a matter
      for the application."

  So, the specification of applied encoding for those elements on
calculating
  HMAC key is up to STUNbis document.

  Please note that username and realm have the applied encoding
specification
  as UTF-8 in its corresponding STUN attribute description.
  (please see section 14.3 and 14.9)
  But the password doesn't have such a description, therefore some care need
  to be taken.

- Section 14.6 mentions to the HMAC truncation, but as far as I read, I
  couldn't precisely find out the minimum byte of length of the HMAC.

  From my understandings, minimum length
  maybe 16 because
  > The HMAC MUST NOT be truncated below a minimum size of 16 bytes.

  OR
  maybe 8 because
  > The value (snip) MUST be a positive multiple of 4 bytes
    AND
  > STUN Usages may specify a minimum length longer than 4 bytes.

  Here above I conceived "longer than (but not equal to) 4 bytes".
  IMHO, some clarification will be preferable.

- There are some occurence such like
   > a UTF-8 [RFC3629] encoded
   > sequence of less than 128 characters (which can be as long as 509
   > bytes when encoding them or 763 bytes when decoding them).

   The sentence inside parenthesis have off-by-one error.
   To be exact,

   (which can be less than 509 bytes when encoding them or 763 bytes
   when decoding them)

   or alternatively

   (which can be as long as 508 bytes when encoding them or 762 bytes
   when decoding them)

- In Section 9.2.4, there are some typoes.
  Unnecessary extra white space such that "PASSWORD- ALGORITHM".

- At page 40, bizzare (perhaps unintended) page break occurs.

Best regards,

Noriyuki Torii