Subject: Re: [BEHAVE] behave-turn-07 comments

From: Philip Matthews <[email-masked]>
Date: Sat, 12 Jul 2008 18:02:40 -0400

Scott:
Thanks for your comments. Responses inline.
- Philip

On Tue, 27-May-08, at 07:13 , Scott Godin wrote:

> Hello,
>
> I just finished updating the opensource turn implementation (reTurn  
> - in resiprocate SVN) from turn-05 to turn-07, and have the  
> following comments about the draft.
> 1.  I like the new channel bind and framing mechanism - both ended  
> up simlifying the implementation. : )  The overall flow of draft  
> reads better.
Thanks.

> 2.  Section 2 - last paragraph, 2nd last sentence - double "the".
Fixed.

> 3.  Section 2.2 - 5th paragraph, last sentence - add "or port" ->  
> "(e.g., by using a different client host address or port)
Fixed.

> 4.  Section 5 - I find the wording around the allocation transation  
> id being used to detect retransmissions confusing and unnecessary -  
> using the tid to detect retransmissions is part of the stun draft.
Not sure exactly what you are referring to. The text in section 5 reads:
   The transaction ID of the allocation is the transaction ID used in
    the Allocate request.  This is used to detect retransmissions of the
    Allocate request over UDP (see Section 6.2 for details).
and I am not sure what I could do to fix this. Perhaps you could  
suggest text?

> 5.  Section 6.2 - there are no specific instructions on what to do  
> if the RequestedProps is not set - ie. allocation any port in the  
> range.
I have added the following sentence:
      Otherwise (i.e., the E and R flags are not set,
      and RESERVATION-TOKEN is not included),
      the server allocates any port in the range described
      above.
> 6.  Section 9.2 - should probably contain some explicit text around  
> finding the allocation and dropping the packet if not found.
The text now contains the following paragraph:
    The resulting UDP datagram is then sent to the peer.  If any errors
    are detected during this process (e.g., the Send indication does not
    contain a PEER-ADDRESS attribute), the received indication is
    silently discarded and no UDP datagram is sent.

> 7.  Section 9.3 - extra "I" in front of "Section" -> "ISection 10"
Fixed.

> 8.  Section 10.2 - need to specify what headers the Channel Bind  
> Response should include.  I found including at least the channel  
> number, very useful for the client implmentation.  We could also  
> include the Peer Address for completeness.  This saves a tid lookup  
> of cahced requests in order to discover this information.

I think that a client has to keep track of the info in the request  
anyway, in case the request failed.
So for now, I have added a sentence saying that there are no required  
attributes in a ChannelBind response.

> 9.  Section 14 - 438 (Wrong Credentials) - 438 error code is used in  
> rfc3489bis-15 (Stale Nonce) - should choose another value
Fixed. "Wrong Credentials" now uses 441.

> Cheers,
> Scott

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave