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

From: "Kevin Johns" <[email-masked]>
Date: Thu, 16 Nov 2006 16:53:10 -0700

Hi,
 
I have been reviewing rfc3489bis-05 and have some comments on the text
upto section 8. These are mostly focused on suggested additions of
normative statements to the existing text as well as a few editorial
comments. Where suggesting text be made normative I have tried to verify
that related normative statements do not appear later in the document.
 
Kevin
 
Section 2 (Introduction), second to last para: I found this a bit
confusing as it seems to be saying that online games and Voice over IP
are proprietary protocols, when I think it is trying to say that
proprietary version of these protocols have been developed to address
NATs?

Section 5 (Overview of Operation), first para: This paragraph indicates
that normative behavior is defined in sections 8 and 9. This should also
indicate that sections 6 and 7 provide normative behavior as well.

Section 6 (STUN Message Structure), first para: There seems to be
duplicate information in the first few sentence of the opening
paragraph. Suggest striking the second, third and fourth sentences.

Section 6 (STUN Message Structure), fifth para: Consider making this a
normative statement - All STUN messages MUST consist of a 20 byte header
as defined below:

Section 6 (STUN Message Structure), first para after figure 2 (format of
STUN Message Header) consider adding normative statements: The most
significant two bits of every STUN message MUST be zeros.

Section 6 (STUN Message Structure), second para after figure 2 (format
of STUN Message Header) should read: The STUN message...

Section 6 (STUN Message Structure), second para after figure 3 (format
of STUN Message Type Field) consider making normative and clarify with
field: The message length field MUST contain the size, in bytes, ...

Section 6 (STUN Message Structure), third para after figure 3 (format of
STUN Message Type Field) consider making normative and clarify with
field: The magic cookie field MUST contain the fixed value of...

Section 6 (STUN Message Structure), first para before figure 4 (format
of STUN Attributes) consider making normative: After the STUN header are
zero or more attributes. Each attribute MUST be TLV encoded, with a 16
bit type, 16 bit length, and variable value. Each STUN attribute MUST
end on a 32 bit boundary.

Section 6 (STUN Message Structure), first para after figure 4 (format of
STUN Attributes) consider making normative: The value in the Length
field MUST contain the length of the Value part of the attribute prior
to padding...

Section 7.1 (Request/Response Transactions), fourth para, consider
making the last sentence normative: If the client has not received a
response after 7900ms, it MUST consider the transaction to have timed
out.

~~~~~~~~~~~~~~~~~~~~~~
Kevin C. Johns
Project Director - PacketCable Communications Protocols
CableLabs(r)
858 Coal Creek Circle
Louisville, CO 80027-9750
Phone:  303.661.9100
Direct: 303.661.3303
HTTP://www.CableLabs.com <http://www.cablelabs.com/>  

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