Subject: RE: [midcom] Protocol evaluation contribution reminder

From: "Mary Barnes"<[email-masked]>
Date: Wed, 3 Apr 2002 10:31:41 -0600

With my editor's hat on...

There seems to be general WG interest in visiting a larger number of
protocols.  At this point, I've not taken any of these queries as
"volunteering" to do these evaluations of these other protocols.

With my editor's hat off...

I think it's a really good idea to do a minimal evaluation of several of the
protocols that have been put forth over the past couple days (DIAMETER,
SOCKS, RSVP, etc.).  I do realize that some of these have already been
previously considered and already discarded, but from a completeness
perspective, it would be really useful to capture why they were discarded or
considered inappropriate.  I have a feeling that the reason why people that
have suggested these haven't volunteered has more to do with that limitation
of only 24 hours in a given day versus lack of interest.  

With my editor's hat back on...

I would suggest we add an additional section to the Protocol Evaluation
document template to cover these other protocols.  What this would require
from the WG would be some discussion on the list to compile this information
or "volunteers" (that word again) to provide minimal content for the
protocol evaluation document for these other protocols (i.e. just a brief
overview and summary of Pros/cons (per the requirements) and perhaps a
recommendation as to why this wouldn't be appropriate as the MIDCOM
protocol).  Now, I can see problems with doing this as it's possible one of
these others might actually be better and we've not necessarily evaluated
these as thoroughly as the others (although, Melinda seems to be indicating
that a certain level of analysis had been previously done in an informal
manner on some of these others). 

So, what do people think about this proposal? 

Mary.  

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 9:13 AM
To: Pete Cordell; [email-masked]
Subject: Re: [midcom] Protocol evaluation contribution reminder

At 01:01 PM 4/3/02 +0100, Pete Cordell wrote:
>SOCKS would seem to be a candidate also.  Or do people already know that it
>is not useful?

SOCKS would require significant extension, and I think that
its basic model is actually covered in a more general way by 
RSIP.  It's a reasonable protocol to investigate, though.

Melinda

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

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 3 Apr 2002 19:12:51 +0100

RE: [midcom] Protocol evaluation contribution reminderMary,

I think it's a good idea to list the protocols that we 'know' won't work
also.  But maybe it should be sufficient to just list the fatal reason (or
set of reasons) why it is not suitable, rather than matching the full
template.  Indeed, I think it would be better to say something like:

    SOCKS (or whatever) - Gut feeling was that it was not appropriate and so
it wasn't considered further.

rather than ignore these protocols completely.

Mind you, it would be good if we could also list what is useful about the
discarded protocol as that information may come in handy when polishing off
various parts of the selected candidate protocol.

A few arguments on the list ought to be sufficient to provide the
information.  Maybe I can start the ball rolling by saying:

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

SOCKS does not allow for persistent TCP listeners for receiving incoming
calls (although it does allow for one-shot listeners that automatically
close on reception of the first incoming TCP connection).  Control and
authentication is on a per-connection basis, potentially placing significant
computational load on the server and so may limit scalability.  Each UDP
connection requires a separate authenticated TCP control connection thus
requiring TCP state in addition to UDP state which further limits scaling.

The BIND operation does have sufficient information to be used with a NAT
function.  However, the UDP ASSOCIATE semantics do not readily allow for the
inclusion of NAT functionality (BND.ADDR/PORT indicate where the local
client must send data to in order to send it from the allocated port rather
than where the remote client should send data to to be relayed to the local
client).

The BIND and CONNECT operations involve essentially in-band configuration.
Hence it is not clear how these mechanisms would be used if the firewall and
the NAT were separate devices.

In its favour, SOCKS does pass around the sorts of data fields that a midcom
protocol would require, although the actual addressing tuples that are used
are probably insufficient for the midcom case.  It also includes a simple
authentication mechanism scheme that may be worth looking at if the selected
midcom protocol is lacking in this respect, although there are likely to be
many of these to choose from, and the mechanism used is definitely on the
simpler side of things.

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

Pete.

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

----- Original Message -----
From: Mary Barnes
To: 'Melinda Shore' ; Pete Cordell ; [email-masked]
Sent: 03 April 2002 17:31
Subject: RE: [midcom] Protocol evaluation contribution reminder

Mary.