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@xxxxxxxx> 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@xxxxxxxx mailing lists by 2009-01-27. Exceptionally, > comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf