Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 nits

From: Lloyd Hilaiel <[email-masked]>
Date: Fri, 1 Dec 2006 17:14:46 -0800

Greetings,

This first email has editorial nits of
draft-ietf-behave-rfc3489bis-05.txt.  Please let me know if the the
format (universal diffs) is inconvenient.

These 13 issues are minor and don't require a response.  I apologize if 
I duplicated previously discussed issues.  Please drop said duplicates
on the floor.

I'll send along my (marginally) deeper questions in the next day.

0. There are at least three different phrases used to refer to the same
   usage:
   "binding refresh usage", "binding keepalive usage" and
   "NAT keepalive usage".  One phrase should be chosen.
   (searching keepalive throughout reveals them all). 

1. A repeat of Philip's comment about "client" and "server" being
   potentially confusing.  Especially in the abstract where the terms
   haven't been defined yet, I found the use of the terms to be
   a bit misleading.
 
@@ -59,3 +59,3 @@
    allocated to them by a NAT and to keep NAT bindings open.  It can
-   also serve as a check for connectivity between a client and a server
+   also serve as a means to check connectivity between two endpoints
    in the presence of NAT, and for the client to detect failure of the

2. In section 1, the stun relay usage does not handle the case where the
   "STUN server is not in a common address realm".

@@ -248,4 +250,5 @@
    STUN relay usage, when used by itself, eliminates all of the
    limitations of using the binding usage by itself, as described above.
+>> except when the STUN server is not in a common shared address realm.
    However, it requires a server to act as a relay for application
    traffic, which can be expensive to provide, operate, and manage.

3. section 5, overview of operation.  replace all with both.

@@ -531,7 +534,7 @@
 
-   These two usages all utilize the same Binding Request message, and
-   all require the same basic processing on the server.  They differ
+   These two usages both utilize the same Binding Request message, and
+   both require the same basic processing on the server.  They differ

4. section 5, overview of operation.  I think we missed an update from 
   rfc3489bis-04 to rfc3489bis-05.  Fingerprint is no longer mandatory.
   Also, wondering if dropping "cryptographic" is appropriate due to the
   change in algorithm from SHA1 to CRC32.

@@ -548,5 +553,6 @@
    STUN defines a special field in the message called the magic cookie,
-   which is a fixed 32 bit value that identifies STUN traffic.  STUN
-   requests also contain a fingerprint, which is a cryptographic hash of
-   the message, that allow for validation that the message was a STUN
+   which is a fixed 32 bit value that identifies STUN traffic.  In cases
+   where the magic cookie is insufficient, STUN requests may also contain
+   a fingerprint, which is a hash of
+   the message, that allows for validation that the message was a STUN
    request and not a data packet that happened to have the same 32 bit
 
5. section 6, stun message structure.  thoughts on word choice.  I felt
   "consist of" was clearer than "utilize"

@@ -585,4 +591,4 @@
    There are two types of transactions in STUN - request/response
-   transactions, which utilize a request message and a response message,
-   and indication transactions, which utilizes a single indication
+   transactions, which consist of a request message and a response message,
+   and indication transactions, which consist of a single indication
    message.  Furthermore, responses are broken into two types - success

8. 11.3 password.  copy paste errors

@@ -1690,6 +1723,6 @@
    key in the MESSAGE-INTEGRITY attribute of a subsequent STUN
-   transaction.  Note that, as described above, if the USERNAME is not a
+   transaction.  Note that, as described above, if the PASSWORD is not a
    multiple of four bytes it is padded for encoding into the STUN
    message, in which case the attribute length represents the length of
-   the USERNAME prior to padding.
+   the PASSWORD prior to padding.

9.  11.5 fingerprint, word choice.

@@ -1715,3 +1748,3 @@
 
-   The FINGERPRINT attribute can be present in all STUN messages.  It is
+   The FINGERPRINT attribute MAY be present in any STUN message.  It is
    computed as the CRC-32 of the STUN message up to (but excluding) the

10. 11.11 server, copy paste errors
   
@@ -1928,4 +1966,4 @@
    of four bytes, it is padded for encoding into the STUN message, in
-   which case the attribute length represents the length of the USERNAME
-   prior to padding.
+   which case the attribute length represents the length of the SERVER
+   value prior to padding.

11. 11.13 refresh-interval, if this is normative, consider replacing "can"
    with "MAY"

@@ -1953,3 +1991,3 @@
    REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
-   represents an interval measured in millseconds.  It can be present in
+   represents an interval measured in millseconds.  It MAY be present in

12. 12.1.1 applicability of binding discovery.  Don't know if this is useful,
    but I was confused by using the phrase "mapped address" because of the
	collision with the "MAPPED-ADDRESS" attribute. 

@@ -1995,6 +2033,6 @@
    address that is assigned by a NAT between a STUN client and a STUN
-   server.  This transport address will be present in the mapped address
-   of the STUN Binding Response.
+   server.  This transport address will be present in the
+   XOR-MAPPED-ADDRESS attribute of the STUN Binding Response.

best,
lloyd

-- 
[email-masked] | maintain granted for and be customers'
         http://docs.yahoo.com/info/values/

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