[tram] Review of TURNbis-11

[Marc Petit-Huguenin <[e-mail]>]

This is the second part of my review of TURNbis-11, i.e. everything but the dual allocation part.

- Section 2.1, last paragraph:

May be a reference to RFC 5764 and RFC 7983 can be useful here.  Same in section 4, second paragraph and following.  Same at the beginning of section 11.  Again in section 11.6 (if multiplexed, the message in the reserved range is not necessarily discarded).

- Section 2.2, first paragraph:

I think that an informative reference to RFC 7635 may be useful there, as alternative to the STUN authentication mechanism.

- Section 2.9:

The whole 2.9 section and subsections looks normative and so should be moved after section 3, perhaps on their own top level section.

- Section 4, 4th paragraph:

I would replace "For each allocation..." by "For each Allocate request...", because of the dual allocation feature.

- Section 4, 12th paragraph:

Should make clear clear that UDP covers also DTLS.

- Section 6.1, 2nd paragraph:

If the port is multiplexed with other protocols (RTP, WebRtc, etc..) then it has to reuse an existing socket.  The document should explain this.

- Section 6.2, 3th paragraph:

Is it time to recommend DTLS instead of UDP?  In that case we need to make DTLS mandatory in section 4 paragraph 11 (and I support that change).

- Section 6.4, second bullet:

Replace "...SRV procedures)." with "...DNS resolution procedures)."

- Sections 14, 15 and 16:

These are no longer new methods and attributes.  See also the next comment.

- Section 19:

Here you need to update the existing methods, attributes and error code so the IANA registries point to the RFC-to-be, then you request allocation for the new attributes.  See section 17 of STUNbis on a way to do that (that was done following a discussion with the IANA representative at an IETF meeting). 

Note that ICMP should be comprehension-mandatory, not optional, as we do not want an old client to reject a Data indication with an ICMP attribute.

Also, I do not know what this SendErr method is.


Nits
----

Section 1: 

s/connection to the Internet ./connection to the Internet./

Section 2.4, first paragraph:

The text switches between the words "mechanisms" and "way".  Choose one.

Section 6.2, item 8:

s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/

Section 12.1, "Preferred Behavior"

s/Label Field[RFC3697]/Label Field [RFC3697]/

Section 21:

s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/

Section 22:

s/orginal/original/

-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug