[tram] some nits in i-d turnbis-27

[Noriyuki Torii <[e-mail]>]

To whom it may concern,

I had read I-D of TURNbis-27 and found some points would like to be shared.
Hope this may help for improvements.

page 25
> 6.  Allocations
>
>    All TURN operations revolve around allocations, and all TURN messages
>    are associated with either a single or dual allocation.

The document refers to single and dual allocation for the first time here,
but there seems no explicit definitions about what a single or dual allocation
actually is in any section of the document.
Readers can only infer meanings of those from later description.
I guess it would be preferrable having some explanations about these words
in the terminology of section 2.
---

page 30
>        If the
>        server can partially meet the request, i.e. if it can only
>        allocate one relayed transport address of a specific address
>        type, then it includes ADDRESS-ERROR-CODE attribute in the
>        response to inform the client the reason for partial failure of
>        the request.  The error code value signaled in the ADDRESS-
>        ERROR-CODE attribute could be 440 (Address Family not Supported)
>        or 508 (Insufficient Capacity).

Readers may wonder (at least I did) whether a server will reply with
Allocate success or error response when a request resulted into partial
failure. Readers must wait until section 7.3 to get the answer for this
question.
Perhaps some additional explanation will be appreciated here.
---

page 32
>   Once the allocation is created, the server replies with a success
>   response.  The success response contains:
>
>   o  An XOR-RELAYED-ADDRESS attribute containing the relayed transport
>      address.

Here seems only a single allocation is in concern. Additional description
for a dual allocation will be needed.
---

page 47
>   o  If the XOR-PEER-ADDRESS attribute contains an address of an
>      address family that is not the same as that of a relayed transport
>      address for the allocation, the server MUST generate an error
>      response with the 443 (Peer Address Family Mismatch) response
>      code.
>
>   If any of these tests fail, the server replies with a 400 (Bad
>   Request) error.

The document says initially "response with the 443" and later
"replies with a 400", so the acutual response is ambiguous.
---

page 61
> 18.4.  DATA
>
> The DATA attribute is present in all Send and Data indications.

I think not all Data indications have the DATA attribute, especially
when a Data indication carries an ICMP notification with the ICMP
attribute, although section 11.5. doesn't say explicitly that such an
indication MUST NOT have the DATA attribute.
---

page 62
>   RFFU:  Reserved For Future Use.
>
>   The other 7 bits of the attribute's value must be set to zero on
>   transmission and ignored on reception.

"The other 7 bits" actually refers to the RFFU field, so some fix seems
to be needed.
---

page 63
> 18.12.  ADDRESS-ERROR-CODE Attribute

and page 64
> 18.13.  ICMP Attribute

These words "Attribute" seem to be unnecessary and removal would be
preferable for alignment with other attribute descriptions in section 18.
---

page 64
>   Reserved:  at this point, the 13 bits in the Reserved field MUST be
>      set to zero by the client and MUST be ignored by the server.

Each fields of ADDRESS-ERROR-CODE Attribute must be set by the server,
so this description is the other way around.
---

page 75
>   An attacker can send packets to B as if they came
>   from A by sending packets towards A with a spoofed IP address of B.

Host A and B are replaced each other in before half and latter half.
---

Best regards,

Noriyuki Torii