Subject: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-12

From: IETF I-D Submission Tool <[email-masked]>
Date: Tue, 13 Nov 2007 22:57:37 -0500

A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository.

Filename:	 draft-ietf-behave-rfc3489bis
Revision:	 12
Title:		 Session Traversal Utilities for (NAT) (STUN)
Creation_date:	 2007-11-13
WG ID:		 behave
Number_of_pages: 48

Abstract:
Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with NAT traversal.  It can
be used by an endpoint to determine the IP address and port allocated
to it by a NAT.  It can also be used to check connectivity between
two endpoints, and as a keep-alive protocol to maintain NAT bindings.
STUN works with many existing NATs, and does not require any special
behavior from them.

STUN is not a NAT traversal solution by itself.  Rather, it is a tool
to be used in the context of a NAT traversal solution.  This is an
important change from the previous version of this specification (RFC
3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489.

The IETF Secretariat.

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

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 16 Nov 2007 10:06:24 +0100

Hi

here are some minor comments on this new version of rfc3489bis:

Comments on draft-ietf-behave-rfc3489bis-12

by Alfred E. Heggestad <[email-masked]>
16. Nov 2007

NITS:

 > Section 3.  Overview of Operation, 5th paragraph
 >
 >
 >   Response back to the the STUN client.  As this packet passes back
                      ^^^^^^^

-> should be "the"

 > Section 6.  4th paragraph
 >
 >   a response message), and indication transactions (which consists a
 >   single indication message).  Response classes are split into error

-> add "of" between "consists" and "a" -> "...(which consists of a single..."

 > Section 7.1. Forming a Request or an Indication
 >
 >   When formulating a request or indication message, the agehtn MUST
                                                           ^^^^^^

-> typo, should be "agent" ?

 > Section 7.2.1
 >
 >   the 3s recommended in RFC 2988).  In fixed- line access links, a
                                          ^^^^^^^^^^^

-> could be "fixed-line"

 > Section 10.  Authentication and Message-Integrity Mechanisms
 >
 >   additional processing occurs in three different places: when forming
 >   a message; when receiving a message immediately after the the basic
                                                           ^^^^^^^

-> should be "the"

 > Section 12 Backwards Compatibility with RFC 3489
 >
 >   o  There were three comprehension-required attributes, RESPONSE-
 >      ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESSthat have been removed
                                     ^^^^^^^^^^^^^^^^^^^

-> could add a space separator here

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 15:00:36 -0500

Thanks. I fixed and submitted -13 with these changes (that was the only 
difference from -12).

-Jonathan R.

Alfred E. Heggestad wrote:
>> A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been 
>> successfuly submitted by Jonathan Rosenberg and posted to the IETF 
>> repository.
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 15:00:36 -0500

-Jonathan R.