Subject: [BEHAVE] 3 more comments on draft-ietf-behave-rfc3489bis-05

From: Lloyd Hilaiel <[email-masked]>
Date: Sat, 2 Dec 2006 16:19:27 -0800

Hello all,

My remaining issues are 3 in number, and again, minor.  Most of
the notes I jotted down on a fresh read of rfc3489bis-05 ended up
being already addressed by folks previously...

Overall, I'm excited to see this go to RFC, and find it much clearer
(and simpler, despite the name change) than RFC 3489.  FWIW, I think
moving nat type detection out into a seperate usage was a wonderful
decision.

1. rename "magic cookie"?

   afaict, there are three roles the magic cookie serves:
   * provides a tool for demux
   * serves as a STUN version number
   * is the xor value used in encoding of XOR-MAPPED-ADDRESS
     (along with the transaction id)

   I would find it clearer if there were fewer interdependencies here,
   that is, if XOR-MAPPED-ADDRESS was encoded using a constant.  And
   the magic cookie because simply a version number.

   So I'd propose:
   1. change "magic cookie" to "STUN version number"
   2. define a 16 byte constant in the document for encoding of
      XOR-MAPPED-ADDRESS (as is done in 11.5, FINGERPRINT)
   3. everywhere we talk about the magic cookie being used as a demux
      tool, update language to refer to stun version number.
	  
   This is a matter of semantics, and results in no normative changes
   other than xor mapped address encoding, I just felt it made it
   explicit what bits 32..61 in a STUN message really do.  Also there
   was some wondering about why the transaction id needs to be 96 bits,
   this removes a reason. fwiw.  My assumption is that it is not required
   /desired that the xor'd mapped address is a function of the stun
   header...

2. change the encoding of UNKNOWN-ATTRIBUTES:

   from section 11.9:
   "If the number of unknown attributes is an odd number, one of the
   attributes MUST be repeated in the list, so that the total length of
   the list is a multiple of 4 bytes."

   This seems needless ambiguity.  I'd suggest zero byte padding and
   setting the length of the attribute header to only the usable portion
   of the payload.

3. confusion over transaction ids in indications.

  I find it a little unclear the conflicting language around TIDs
  and indications:

  section 8.4 says:
  "Indication message types are not sent reliably, do not elicit a
  response from the server, and are not retransmitted."

  vs. 
  
  Section 6 says:
  "Indications are also identified by their transaction ID.  The
   transaction ID there MUST also be uniformly and randomly distributed
   between 0 and 2**96 - 1.As with requests, the value is chosen by the
   server and MUST be unique for each unique indication generated by the
   server.  Unless a request or indication is bit-wise identical to a
   previous request, and was sent to the same server from the same
   transport address, a client MUST choose a new transaction ID for it."

  The contradiction here is "Unless a request or indication is bit-wise
  identical to a previous request" suggests I may retransmit indications.
  while section 8.4 explicitly states I may not.  
  
  Suggest "Unless a request is bit-wise identical to a previous request,
  a client MUST choose a new transaction ID for it.  A client
  MUST NOT send two indications with the same transaction id."

best,
lloyd

-- 
[email-masked] | irreverence responsibility share
         http://docs.yahoo.com/info/values/

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