Subject: [BEHAVE] RFC3489bis-05 comments (section 8 onward)

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Dec 2006 19:03:53 -0600

Hi all,

Here are my remaining comments from section 8 onward:

Section 8.3.1, paragraph 5 (a.k.a. step 3):
		NIT: Change 'nulls' to 'whitespace'.

Section 8.3.1
		Last sentence in the section about pipelining... Same
question I raised about similar text in section 7.1.

Question: Is it allowable to have multiple transactions outstanding
between the same two endpoints, or is it intended that a given server
will only have one transaction outstanding from any given client? 

Suggest changing last sentence in 8.3.1 from:

"Regardless of the transport protocol, a client MAY pipeline requests
(that is, it can have multiple requests outstanding at the same time)."

...to:

"Regardless of the transport protocol, a client MAY have multiple
outstanding STUN requests (with different transaction IDs) and not wait
for completion of one STUN transaction before initiating another STUN
request to the same STUN server."

Page 18, next to last paragraph:

To match with section 8.3.3 should read: When using TCP or TLS over TCP,
the client SHOULD close the connection as soon as it has received the
STUN response, and determines it has no further messages to send to the
server.

Section 8.3.2, page 20, next to last paragraph:

In the case of a 431 response, do we really want to specify a "SHOULD
alert the user" clause in the protocol? Isn't that a UI issue that is
out of scope, or at the very least a RECOMMENDED instead of a SHOULD? 

What should the client do if it gets a 431 response to a request that
did not use a short term credential obtained from a Shared Secret
request in the request? Unrecoverable failure?

Page 21, second paragraph:

"It the client receives..." should be changed to "If the client
receives..."

I have the same issue of codifying when to alert the user in a protocol
specification as in the previous text.

What constitutes "repeated rejection" of a request by a 436 response?
Two, three, ten? Can't we put a number on this? If you keep getting
usernames from the Shared Secret request that are bad, why not limit
this to two retries to get a new username and use that to retry the
original request (just to be safe in case of race conditions)?

Page 21, second paragraph:

Although later in the document it becomes obvious that success responses
do not have a response code, for those who are familiar with SIP/HTTP
response codes, listing 100-299 as response codes to be discarded can be
initially confusing. May want to point out that this paragraph is
talking about error response messages as Section 8.3.2 talks about both
types interchangibly.

Page 22, first paragraph:

This text states that indications are typically sent over the same TCP
connection, but the next to last paragraph in section 8.3.1 said that
the client SHOULD close the TCP connection after getting a response to a
request. I understand that this is a TURN usage, and in that context,
the two pieces of text make sense. However, since indications can be
used for other usages in the future, this is an additional reason to
relax the wording in section 8.3.1 from "further request" to "further
messages" as noted above.

Page 23, next to last paragraph:

Idempotentcy is not guaranteed for binding requests in the case that the
NAT creates a new binding between retransmissions of the same STUN
request (NAT may have been rebooted, etc).

Page 25, third paragraph of Secion 9.1.2:

NIT: "source" in fifth sentence is given as "souce".

Section 9.1.3:

Should make all of the statements in this section normative MUSTs.

Section 11.2, third paragraph:

MAPPED-ADDRESS is left-padded with the first eight bits. USERNAME is
right-padded with trailing bytes. What encoding is to be used for
string-based attributes? UTF-8, US-ASCII (ANSI X3.4-1986)? Same question
for other text-encoded elements in the STUN message.

Is this padding a SHOULD, MUST, or RECOMMENDED?

Section 11.3, last paragraph:

Text should read: "If the PASSWORD is not a multiple of four bytes, it
SHOULD/MUST/RECOMMENDED be right-padded for encoding into the STUN
message to a natural four-byte boundary. The attribute length represents
the length of the PASSWORD prior to any padding."

Section 11.4:

The hash would naturally be binary, so how was it encoded into text, and
then how is that text encoded back into binary? Is padding
MUST/SHOULD/RECOMMENDED?

Section 11.13:

First paragraph, typo on provides. Second paragraph... what does a
refresh interval of zero mean?

Regards,
Brian

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