Subject: [BEHAVE] review of rfc3489bis-05 - section 8 onward...

From: "Kevin Johns" <[email-masked]>
Date: Fri, 17 Nov 2006 15:15:57 -0700

Hi,
 
Here are my comments which follow-up those sent earlier in the week.
 
Kevin

Section 8.3.1 (formulating the request message)

Suggest making the first sentence normative. The client MUST follow the
syntax rules...

Section 8.3.2 (processing responses)

In the first paragraph it discusses discarding further responses for the
same request. There is no guidance on how long the client should
continue to discard responses. Given this is based on the transaction
ID, would it make sense to add a requirement that the client MUST not
repeat a transaction ID for some period of time? Later on it state the
server must remember the response to a given transaction ID for 10
seconds.

Section 9.1.1 (receive request message)

The ninth paragraph (discusses error codes 430 and 436). Consider adding
normative statements to match the other paragraphs in this section,
(i.e. If the USERNAME as previously valid but has expired, the server
MUST generate and error response. The error response MUST include an
ERROR-CODE attribute with a response code of 430 (state credentials).
The same suggestion applies to error response 436 later in the same
paragraph.

Section 9.1.1 (receive request message)

Last paragraph; When the server sends a 420 response code, should it not
also be required to include a UNKNOWN-ATTRIBUTE attribute in the
response?

Section 9.1.2 (constructing responses)

First sentence; suggest this be made normative and add a reference to
section 7 as well.

Section 9.1.3 (sending the response)

Suggest making the two sentences in this section normative.

Section 11.1 (mapped-address)

I would suggest adding a few normative statements to line up with the
other attribute definitions. In particular:

If the address family is IPv4, the address MUST be 32 bits, in network
byte order. If the address family is IPv6, the address MUST be 128 bits,
in network bye order.

Section 11.11 (server)

If found the first sentence a bit confusing:

The alternate server represents an alternate transport address for a
different STUN server to try.

Consider revising to:

The alternate server represents an alternate transport address
identifying a different STUN server which the STUN client should try.

Section 12 (STUN usages):

Would it be possible to add a STUN attributes table for each STUN usage?
I see that the section on short-term password has such a table, it would
be nice to have a similar table for the binding usage?

Section 12.2 (NAT keepalives)

I noticed that no where in this section was the method type mentioned.
Given the spec only defines two methods (bindings and shared secret) it
is obvious that the binding method is applicable, but it might not hurt
to state the obvious?

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