Subject: [midcom] Working group last call - STUN

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Apr 2002 10:37:37 -0400

We are starting working group last call on the STUN document.
The last call period closes on Tuesday, 23 April at 5pm EDT.
Please post any comments, etc. to the mailing list, and please
point out whether you feel your comment is editorial or a show-
stopper.

Thanks,

Melinda

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Date: Mon, 08 Apr 2002 09:51:01 -0400
>Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-00.txt
>Sender: [email-masked]
>X-Mailman-Version: 1.0
>List-Id:  <midcom.ietf.org>
>X-BeenThere: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Middlebox Communication Working Group of the IETF.
>
>        Title           : STUN - Simple Traversal of UDP Through NATs
>        Author(s)       : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy
>        Filename        : draft-ietf-midcom-stun-00.txt
>        Pages           : 32
>        Date            : 05-Apr-02
>        
>Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol
>that allows applications to discover the presence and types of
>Network Address Translators (NATs) and firewalls between them and the
>public Internet. It also provides the ability for applications to
>determine the public IP addresses allocated to them by the NAT. 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. The STUN
>protocol is simple, being almost identical to echo.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-midcom-stun-00.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:
>        [email-masked].
>In the body type:
>        "FILE /internet-drafts/draft-ietf-midcom-stun-00.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-midcom-stun-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-midcom-stun-00.txt>

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

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 8 Apr 2002 17:40:42 +0100

Here are my comments as part of WGLC...

- The biggest technical issues I have is that in 11.2.3 on CHANGED-ADDRESS,
the following change should be made:

    s|and/or|and|

- To be pedantic, I also think in section 9.1 an additional paragraph should
be added after the third paragraph to the effect of:

"Requests are sent to successive SRV listed servers according to the above
procedure until a response is successfully received.  Once a successful
response is received an operational STUN server is considered to have been
located and the client should not move the test to the next SRV listed
server if subsequent requests do not solicit a response after 30 seconds."

The above is pretty obvious, but I feel ought to be stated for completeness.

- Section 9.2 last paragraph - The response will also include the
CHANGED-ADDRESS attributes (although the section does not claim to be an
exhaustive list so its omission is no big deal.)

- In 11.2.6 CMS-SIGNED-DATA - When you say detached signatures, do you mean
external signatures?  I can see no mention of detached signatures in RFC2630
(but I might have missed them).

- I'm still getting to grips with RFC2630, but it seems to say "If the
eContent value within EncapsulatedContentInfo is absent, then the
signatureValue is calculated and the eContentType is assigned as though the
eContent value was present."  That implies to me that an object identifier
is needed for STUN, which is a bit of a hassle.  Maybe some words should be
added to 11.2.6 to address this.

- 11.1 Message Header: s/64 bit header/160 bit header/ in the first and
third paragraphs.

- Personally I would find it clearer if CHANGED-ADDRESS was actually called
CHANGE-ADDRESS.  The reason for this is I got CHANGED-ADDRESS confused with
MAPPED-ADDRESS.  i.e. I was thinking CHANGED-ADDRESS was the address changed
by the NAT.  I also think it's confusing because in a number of cases the
address is not actually changed, at least not in its entirity.  Calling it
CHANGE-ADDRESS also ties it in more with the 'change-ip' and 'change-port'
flags with which it is associated.

- In section 10 (Use cases) there could be more emphasis that the way STUN
is used is at the discretion of the client by breaking it into a number of
paragraphs, e.g.:

   "The rules of Sections 8 and 9 describe exactly how a client and server
interact to send requests and get responses.

   "How these requests and responses are used to obtain useful information
is at the discretion of the client.

   "Here, we provide some useful scenarios for applying STUN."

Definitely no show-stoppers.  The latter two are primarily intended to help
people avoid missing the points that I missed.

(Jonathan - sorry for submitting a few more comments than I initially I said
would.)

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================