Subject: [tram] Review of draft-ietf-tram-stunbis-04

From: Brandon Williams <[email-masked]>
Date: Thu, 03 Sep 2015 11:16:31 -0400

I have reviewed the STUN changes proposed in stunbis-04. Sorry for the 
long delay since Prague -- hope I don't have to return my star :-)

First, I've got a small number of substance comments.

s 6.1
This section still says "MTU constraint MUST be followed" language. I'm 
pretty sure that we decided to relax this constraint in Dallas, but I 
don't see it in the minutes. It seems to be implied by the decision 
about removing the SCTP requirement.

s 9.2.3
The third bullet states 'If the NONCE attribute starts with the value 
"obMayJos2" but the PASSWORD-ALGORITHMS attribute is not present ... the 
server MUST generate an error response'. However, I don't see a way for 
the server to determine whether it's safe to require this when sending 
the PASSWORD-ALGORITHMS attribute. Maybe the third bullet's requirement 
can only be safely applied if MI-SHA256 is present.

s 14.4/14.5
There has been some discussion in mmusic about trying to compress ICE 
connectivity checks. Justin presented on this. IIRC, one of his 
proposals was to shrink the size of the ICV. It would be good to follow 
up on this and perhaps update stunbis to allow ICV's that are shorter.

s 14.10
States "... is present only in responses." This is incorrect.

The rest of my comments are nits.

s 9.1.2
"... from an external indication what is the message integrity algorithm 
supported by both agents." I suggest "... from an external indication 
which message integrity algorithm is supported by both agents."

s 9.1.3
In the paragraph that starts "If these checks pass, ...", it might be 
useful to explicitly state that only one of MI-SHA256 or MI will be 
included, not both. It's probably obvious to most readers though.

s 9.2.3
There is what appears to be a random URL in the text of the first bullet.

s 11
The text seems to describe backward compatibility with RFC3489, but the 
section title is "Backwards Compatibility with RFC 5389".

s 13
I think this section should also include TURN in the list of defined 
STUN usages. Maybe there are others. Alternatively, change the wording 
to indicate it's not a complete list.

Please let me know if any of the above comments are unclear.

--Brandon