Subject: [midcom] pre-midcom candidates

From: Melinda Shore <[email-masked]>
Date: Fri, 12 Oct 2001 16:58:07 -0400

I believe we now have three candidate documents for the
pre-midcom work item, and we need to work quickly towards 
getting one selected for use as the base document.  Those
three documents are:

http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt
http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt
<http://www.ridgewaysystems.com/pdf/Whitepapers/draft-davies-fw-nat-traversal-01.txt>http://www.ridgewaysystems.com/pdf/Whitepapers/draft-davies-fw-nat-traversal-01.txt 

Please read these, and let's have some serious discussions about
this over the next week.  Remember, the ability to compromise is
a virtue.

Note, as well, that although the document does not state as much
there are some intellectual property claims on technology described
in the Davies draft.  I've appended some text that originally
appeared on the APPS area web page, giving a rough description of
the IETF position on IPR (http://www.apps.ietf.org/procedures.html).
Please read it and take particular note of the second bullet item.
In the future, if you submit a technology for consideration that
is encumbered you MUST inform the working group.

Thanks,

Melinda
======== 

As all who have been with the IETF for a while know, IPR problems are a pain.

The most interesting discussions are found in RFC 2026 chapter 10; the basic tenets of which are:

    * All IPR problems known to participants MUST be identified to the WG.
    * The WG is expected to prefer non-encumbered technology whenever such technology exists and is not significantly worse than the encumbered alternative.
    * Where licensing is an issue, licensing MUST be available on "reasonable and non-discriminatory terms". The first test is whether 2 independent licenses have in fact been granted under such terms between the Proposed and Draft status for the specification.
    * Patents where the patent holder has filed a grant of rights to freely use the patent are not considered terribly encumbering.

For discussions of release of IPR, the correct address is the ISOC vice president for standards, Scott Bradner, <[email-masked]>; also send CC to the IETF Chair (Fred Baker <[email-masked]>) and the IESG secretary <[email-masked]>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Oct 2001 01:15:36 -0500

Comments inline

> -----Original Message-----
> From: Mark Pietras [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 10:45 AM
> To: midcom; Jonathan Rosenberg
> Subject: RE: [midcom] pre-midcom candidates
> 
> 
> These two statements seem to be conflicting (or maybe I'm 
> just taking it out
> of context), but I think the second statement needs 
> clarification in that
> there is another place that the response might go than the obseved
> addr/port:
> > 6 Message Overview
> >    There is also a RESPONSE-ADDRESS attribute, which
> >    is also an IP address and port. The RESPONSE-ADDRESS 
> attribute can be
> >    present in the request, and >>indicates where the 
> response is to be
> >    sent<<. Its optional, and when not present, the response 
> is sent to the
> >    source IP address and port of the request.
> > 7 Server Behavior
> >    The server MUST add a MAPPED-ADDRESS attribute to the 
> response. The
> >    IP address component of this attribute >>MUST be set to 
> the source IP
> >    address observed<< in the request. The port component of 
> this attribute
> >    MUST be set to the source port observed in the query request.
> 

These don't conflict at all. I server receives a request, lets say, from IP
address/port X. THe request has a RESPONSE-ADDRESS attribute with IP
address/port Y. The server will send a response. The response is sent to
(i.e., its destination address/port) Y. The response has a MAPPED-ADDRESS
attribute, and the value of that attribute is X.

> 
> 
> 
> Seems to me that the FLAGS attribute could be optional in the request,
> although that's not stated.  As a side note, if that's not 
> reasonable, then
> the line: "After the header are 0 or more attributes" 
> shouldn't be: "0 or
> more" as there will always be at least 1 (Request with flags, 
> or Response
> with mapped-address).

Flags is optional. The document does explicitly say that, but not in the
section where its first introduced. I added a sentence to that effect.

> In the attribute, the length field isn't specifically defined 
> as to whether
> the attribute header is included or not.  I'd suggest that it doesn't
> include the four octets (type and length) to be consistent 
> with the main
> header.
> >   10.2 Message Attributes
> >   After the header are 0 or more attributes. Each attribute is TLV
> >   encoded, with a 16 bit type, 16 bit length, and variable value:...
> 

Yes, it refers to only the attribute value, so that it does not include the
four octets you refer to. I will clarify that.

> 
> 
> Unless I'm missing something, it seems to me a multi-homed 
> implementation
> would be more efficient (and therefore perhaps a better 
> suggestion) than
> using the RESPONSE-ADDRESS.  I suppose the RESPONSE-ADDRESS 
> is the more
> complex implementation though and deserves more attention...

RESPONSE-ADDRESS is only useful if you are multihomed in the first place, so
I'm not sure I understand what you are saying here.

> >   One potential way to implement the change-IP feature is for the
> >   server to generate its own request, and send it to 
> another server...
> From what I can tell, this is also the only reason for 
> RESPONSE-ADDRESS too,
> right?

No, its unrelated. RESPONSE-ADDRESS allows the client to tell the server
where teh response should go. The FLAGS has a change-IP that allows the
client to tell the server from where to send its response (i.e., the
RESPONSE-ADDRESS determines the destination IP and destination port of the
response, and the FLAGS determines the source IP and source port of the
response). 

> 
> 
> 
> Seems to me that CHANGED-ADDRESS is missing from the list:
> >   0x0001: MAPPED-ADDRESS
> >   0x0002: RESPONSE-ADDRESS
> >   0x0003: FLAGS
> >   0x0004: SOURCE-ADDRESS
> Based on layout of document, I think this was intended:
> >   0x0001: MAPPED-ADDRESS
> >   0x0002: RESPONSE-ADDRESS
> >   0x0003: CHANGED-ADDRESS
> >   0x0004: FLAGS
> >   0x0005: SOURCE-ADDRESS
> 

Correct. I've fixed that.

> 
> A side note on address realms:
> If a STUN packet traverses address realm types (ipv4 client 
> <-> ipv6 server)
> a client in the ipv4 realm will have to be ipv6 aware because 
> the response
> will contain the ipv6 address of the NAT.  And when I say 
> client, I mean
> both the STUN client _and_ the client using the information 
> as it will be
> communicating it somewhere else in it's signaling (e.g. SIP/SDP).

Correct.

> 
> 
> Note on attributes:
> There's no explicit or implied order to how attributes appear 
> in messages, I
> suppose that's okay (although slightly more work to deal 
> with), but I don't
> recall seeing a statement about what servers (or clients for 
> that matter) do
> when 1) they see an attribute in a request meant only for a 
> response (or
> visa versa), or 2) there is more than one attribute of the 
> same type in a
> message (e.g. two FLAGS attributes).

Right, I have not specified anything. Since there isn't really any error
handling, the server should accept attributes in any order, and ignore any
attributes that are defined but not supposed to be present in that message.
I will add that.

> 
> 
> That's it for now...  looks good.

Thanks for your comments and questions.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "James Ho" <[email-masked]>
Date: Wed, 31 Oct 2001 14:19:31 -0800

As I understand it, the Davies proposal requires an open
UDP port on the firewall for media traversal. I can't think
of many/any enterprises being willing to implement such a
firewall policy. Or maybe my understanding is faulty??

james

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp