Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt

From: [email-masked]
Date: Thu, 26 Oct 2006 14:50:21 -0500 (CDT) (envelope-from [email-masked])

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance 
Working Group of the IETF.

        Title           : Simple Traversal Underneath Network Address 
Translators (NAT) (STUN)
        Author(s)       : J. Rosenberg, et al.
        Filename        : draft-ietf-behave-rfc3489bis-05.txt
        Pages           : 61
        Date            : 2006-10-26
        
Simple Traversal Underneath NATs (STUN) is a lightweight protocol
   that serves as a tool for application protocols in dealing with NAT
   traversal.  It allows a client to determine the IP address and port
   allocated to them by a NAT and to keep NAT bindings open.  It can
   also serve as a check for connectivity between a client and a server
   in the presence of NAT, and for the client to detect failure of the
   server.  STUN works with many existing NATs, and does not require any
   special behavior from them.  As a result, it allows a wide variety of
   applications to work through existing NAT infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-behave-rfc3489bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@xxxxxxxxx
In the body type:
        "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt".
        
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt>

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 26 Oct 2006 18:52:57 -0500 (CDT) (envelope-from [email-masked])

hi

some comments on draft-ietf-behave-rfc3489bis-05:

> Section 11.13 REFRESH-INTERVAL
>
>    that are being used for keepalives.  The REFRESH-INTERVAL provies a
>                                                              ^^^^^^^

typo - should be "provides"

> Section 11.13 REFRESH-INTERVAL
>
>   represents an interval measured in millseconds.  It can be present in
>                                      ^^^^^^^^^^^

typo - should be "milliseconds"

Section 6.  STUN Message Structure

                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
                          |1|1|9|8|7|1|6|5|4|0|3|2|2|0|
                          |1|0| | | | | | | | | | | | |
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                   ^
                                                   |
                            should be "M1" ? ------'

Section 7.1.  Request/Response Transactions

   The STUN application SHOULD NOT retransmit STUN requests when running
   over TCP.

-> could we change this to "MUST NOT" ?

Section 9.1.1.  Receive Request Message

   generate an error response which includes an ERROR-CORE attribute
                                                ^^^^^^^^^^

-> typo? I think this should be "ERROR-CODE"..

Section 15.2.  STUN Attribute Registry

    0x8023: FINGERPRINT
    0x8022: SERVER
    0x8023: ALTERNATE-SERVER
    0x8024: REFRESH-INTERVAL

-> it seems like the FINGERPRINT and ALTERNATE-SERVER have got
   the same value (0x8023) ?
   In my implementation I have chosen the value 0x8025 instead.

/alfred

Internet-Drafts@xxxxxxxx wrote:
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

        

Send a message to:
        mailserv@xxxxxxxxx
In the body type:

------------------------------------------------------------------------

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 28 Oct 2006 11:18:38 -0500 (CDT) (envelope-from [email-masked])

Hi,

this draft defines two address families but does not create an IANA 
registry for them. It should, in case it is necessary to register more 
address families at some point in the future.

Thanks,

Gonzalo

        

Send a message to:
        mailserv@xxxxxxxxx
In the body type:

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 29 Oct 2006 08:44:45 -0600 (CST) (envelope-from [email-masked])

Gonzalo,

The purpose of a registry is to make sure that there are no conflicts  
and that one specific item in a large number of items can be easily  
found.  It is not necessary to place in the registry every element of  
any protocol.

I am skeptical that the IETF will ever define a new address family.   
The IPv6 address space is large enough to address every atom in the  
known universe.  If the IETF defines a new address family there will be  
such a substantial number of changes needed to STUN (for example  
replacing all the attributes that can contain IP addresses).  I am  
confident that there will be no conflicts at that time with other  
address families and that the community will be able to notice the  
change without consulting a registry.

thanks,
-rohan

On Oct 28, 2006, at 9:17, Gonzalo Camarillo wrote:

Hi,

Thanks,

Gonzalo

Internet-Drafts@xxxxxxxx wrote:
A New Internet-Draft is available from the on-line Internet-Drafts  
directories.
This draft is a work item of the Behavior Engineering for Hindrance  
Avoidance Working Group of the IETF.
	Title		: Simple Traversal Underneath Network Address Translators  
(NAT) (STUN)

   also serve as a check for connectivity between a client and a  
server

   in the presence of NAT, and for the client to detect failure of the
   server.  STUN works with many existing NATs, and does not require  
any
   special behavior from them.  As a result, it allows a wide variety  
of

   applications to work through existing NAT infrastructure.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis 
-05.txt
To remove yourself from the I-D Announcement list, send a message to  
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body  
of the message. You can also visit  
https://www1.ietf.org/mailman/listinfo/I-D-announce to change your  
subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the  
username "anonymous" and a password of your e-mail address. After  
logging in, type "cd internet-drafts" and then "get  
draft-ietf-behave-rfc3489bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or  
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---------------------------------------------------------------------- 
--

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Oct 2006 09:20:21 -0600 (CST) (envelope-from [email-masked])

Hi,

if not creating the registry was not an oversight but a conscious 
decision, I am OK with it.

Cheers,

Gonzalo

Rohan Mahy wrote:

Gonzalo,

I am skeptical that the IETF will ever define a new address family.  The 
IPv6 address space is large enough to address every atom in the known 
universe.  If the IETF defines a new address family there will be such a 
substantial number of changes needed to STUN (for example replacing all 
the attributes that can contain IP addresses).  I am confident that 
there will be no conflicts at that time with other address families and 
that the community will be able to notice the change without consulting 
a registry.

thanks,
-rohan

Hi,

Thanks,

Gonzalo