[tram] Review of dual allocation in TURNbis-11

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

I should first apologize the the delay in reviewing this draft.  I never managed to get a sponsorship that spans the whole lifetime of a draft (or a Working Group for that matter), and that why it is so difficult for me to work on IETF stuff in a sustained and consistent manner.

Anyway, I was working on a review for turnbis-11 that was specifically focusing on the synchronization with stunbis, but I kept be distracted by issues related to the dual allocation feature.  So I decided instead to send a separate email for that, to make things less confusing.

My main comment about the dual allocation approach is about the choice of adding a new attribute for that.  STUN supports sending multiple attributes of the same type, and has a default processing rule for them ("Any attribute type MAY appear more than once in a STUN message.  Unless specified otherwise, the order of appearance is significant:  only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver.")

So a TURNbis client that wants to do a dual allocating adds two REQUESTED-ADDRESS-FAMILY (RAF), one for IPv4 and one for IPv6.  An RFC 5766 server will just use the first one and ignore the second.  The TURNbis client receives only one XOR-RELAYED-ADDRESS (XRA), for the first RAF it sent.

The client can choose the order, so it receives immediately a XRA from the family it is most interested in, and can try a second allocation for the other if the server is implementing RFC 5766.

I think that this makes for simpler rules to implement and simpler text.

Now some more specific comments about the text:

- Title and abstract

The draft should obsolete both RFC 5766 and RFC 6156, and that fact should be repeated in the abstract.  The authors of RFC 6156 should be acknowledged either in the Acknowledgment or Contributors section.

- Section 5.

The first item in the bullet list should say "the relayed transport address or addresses;"

In the the fourth item, there is one time-to-expiry per relayed transport address.

Same for the list of permissions in the fifth item.

"Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation."

With the dual allocation, the 5-tuple no longer uniquely identify an allocation.

- Section 6.2 

I would suggest to make ADDRESS-ERROR-CODE more generic by renaming it as WARNING-CODE and use the same format than for ERROR-CODE.  Then allocate a new error code for that specific warning.  I would suggest to request the 0x8009 codepoint for that attribute.

Also I think we needs two different warnings, one that states that dual allocation is not available in a TURNbis server, but both protocols are available, and another that says that dual allocation failed because one of the two protocols is not available.  This is to let the client know that it is useless to try another allocation for the missing protocol.

What is the policy when reserving the next port with the EVEN-PORT attribute in a dual allocation, but one of them fails to find a pair of subsequent ports available?

It is not said that the Allocate successful response must contain two XRAs after a successful dual allocation.

I would also suggest to add some text that says that when a TURNbis server sends an Allocate success response, it must always send the XRAs in the same order than the RAFs were sent.  So in case the server sends back by mistake two XRAs, the first one matches the one requested by the client.

The bullet list at the end needs also to be fixed for dual allocation.

- Section 6.3

Here's too, the text needs to be updated for the dual allocation case.


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