FYI - I've submitted the following comments last week sometime, but I
think they may be held up in the moderator queue:
I'm in the process updating reTurn (opensource Turn server in
resiprocate project) to the latest turn-12, and have the following
comments/typos after reviewing the draft.
1. section 1, 4th paragraph, "When the client send...." - should be
"...sends..."
2. section 2.1, last paragraph, ".., the client may send and received
packets..." - should be "...receive..."
3. section 2.6, list "The ECN field is may be reset..." - remove "is"
4. section 5, 3rd last paragraph indicates that username, password,
realm and nonce are used to verify subsequent requests - but according
to section 4 paragraph 6 the only information authentication
information used to verify subsequent requests is the username. I
think one of these sections needs to be re-worded to avoid confusion.
Perhaps section 4 should indicate that username, realm and password
should be stored and verified across all requests for an allocation -
this will cover cases where the same username exists in two different
realms. However note that if password hash is stored instead of the
plain password, then we don't really need to store and compare realm,
since it is hashed into the password.
5. section 6.2 - step 5 "... request contains a EVEN-PORT
attribute..." - should be "...contains an EVEN-PORT attribute..."
6. section 7.2 - first step indicates that "the additional username
check of section 4" should be complete. This comment needs to be
brought inline with the wording decided for comment 4.
7. section 9, 2nd paragraph - missing space "... inSection..."
8. section 9.2 is missing the steps/checks to process similar to
Allocate and Refresh requests - it would be good to add these for
consistency. It should also include: Long Term Cred check, existing
allocation check, and the required auth (username, etc.) checks.
9. section 10, 1st paragraph - "...for sending and receive data
from..." - should read "...for sending and receiving data..."
10. section 10.2 - should include a step to ensure that an allocation
exists for the 5-tuple, else message is dropped
11. section 10.2, 4th paragraph, last sentence - "...the server MUST
NOT refresh the permission due to the receipt of the Send
indication..." - should be removed since Send Indication never refresh
permissions now
12. section 10 indicates that Data attribute is mandatory in a Send
Indication - should we allow no data attribute to indicate that a 0
length UDP packet? Note the ChannelBinding section discusses sending
a 0 length packet (section 11.6 last paragraph). Perhaps this could
also be accomplished using a Data attribute containing a data length
of 0 - but I think there should be some mention of this in section 10.
13. section 11, paragraph 5 - "...or may choose never to bind a
channel it." - should be "...channel to it."
14. section 11.2 - check list should be numeric to be consistent with
Allocate and Refresh requests. Should also contain Long Term Cred
check, existing allocation check, and the required auth (username,
etc.) checks
15. section 11.5 - I'm not sure I understand the need to pad the
ChannelData message to a multiple of four bytes. TCP implementations
are capable of reading in the exact right number of bytes from the
stream. Can this requirement be removed?
16. Is there are reason we don't just make the default permission and
channel binding lifetime the same, to facilitate use of the
ChannelBind refresh to accomplish both refreshes without worrying
about the difference?
My apologies if my questions/suggestions have already been discussed.
Thanks,
Scott Godin
On Tue, Jan 13, 2009 at 10:52 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
wrote:
The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN) '
<draft-ietf-behave-turn-12.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-01-27. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case,
please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14443&rfc_flag=0
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf