Subject: [midcom] Protocol evaluation contribution reminder

From: Melinda Shore <[email-masked]>
Date: Tue, 02 Apr 2002 09:15:41 -0500

Reminder: if you're planning on contributing an evaluation
of an existing IETF protocol to the evaluation deliverable,
please let Mary Barnes ([email-masked]) know by
*tomorrow*, 3 April.

Thanks,

Melinda

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Apr 2002 09:25:16 -0500

Is there a list of which protocols folks have signed up for so far? I am
only aware of Megaco and RSIP from the list.

Are there any suggestions for protocols that we ought to look at, but nobody
has signed up for yet?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 2 Apr 2002 09:25:04 -0800

I'm sort of surprised not to see

RSVP
HTTP ( perhaps a SOAP or UPNP style thing )
WEBDAV to modify an XML document that describes the current filter specs?
If you consider the midbox to be a IP to IP gateway, this could be a Session
Initiation Problem
telnet of IOS style ACLs

Many of these protocol evaluations are going to amount to - yes, the
protocol could function as a transport for  the data and perhaps deal with
the security and authentication issues and No, the protocol has no idea of
the semantics of what we want to do on a midbox but we can invent that on
top of the current protocol.

Cullen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 02 Apr 2002 13:00:34 -0500

>If you consider the midbox to be a IP to IP gateway, this could be a Session

RSVP is actually one of the few IETF protocols that really
diverges from the midcom framework and requirements, and I
think we disposed of the notion of using its model, in the 
context of the midcom working group, last December.  Other 
candidates could include Diameter and even GSMP.  I'd like to
see us be thorough, but at the same time I don't think we 
need to go overboard.  That is to say, it's probably best if
people limit themselves to evaluation of protocols that
they really believe are good fits to the framework and 
requirements.

Melinda

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 12:40:32 +0200

Cullen,

I am much more surprised not to find Diameter in the list
of evaluated protocols. Although being heavy-weight it certainly
has the potential to serve as a midcom protocol.

Isn't there anyone who wants to volunteer for evaluating Diameter?

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 3 Apr 2002 13:01:42 +0100

SOCKS would seem to be a candidate also.  Or do people already know that it
is not useful?

Pete.

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

----- Original Message -----
From: Cullen Jennings <[email-masked]>
To: Bob Penfield <[email-masked]>; <[email-masked]>; Melinda
Shore <[email-masked]>
Sent: 02 April 2002 18:25
Subject: RE: [midcom] Protocol evaluation contribution reminder

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Apr 2002 10:12:58 -0500

>SOCKS would seem to be a candidate also.  Or do people already know that it

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 18:35:01 +0200

Pete,

Our lab runs very well behind a SOCKS firewall.
So, I consider it quite useful.

However, I think it is too simple to match the
midcom requirements.

    Juergen

---

From: "Mark Pietras" <[email-masked]>
Date: Wed, 3 Apr 2002 10:39:22 -0600

I'm in general agreement with other posts in that having a more abstract
definition makes sense first, but not strongly enough to make a stink
about it.

Given where we are though, I'm surprised nobody has brought up in this
thread SIP as a candidate for evaluation.  I recall someone suggesting
this before jokingly, but I'm surprised to not see it come up again
recently.

Anyway, it sounds silly (overboard?), and I'm not saying I necessarily
believe it's the best fit, but it's as good a construct as some of the
others.  Master-Slave'ness versus Peer-to-Peer'ness issues could be
worked out in usage, we could have a ruleset description protocol (RDP)
closely mirroring but in place of SDP (we'll need something like this
with any protocol choice)... and it has the advantage in that there's
likely to be a parser and other logic right there with the MIDCOM agent
ready to use!!  If I had some time on my hands I'd do a real
evaluation...

Remind me again why this is stupid?

Mark.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Melinda Shore
Sent: Tuesday, April 02, 2002 12:01 PM
To: Cullen Jennings; [email-masked]
Subject: RE: [midcom] Protocol evaluation contribution reminder

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Apr 2002 12:02:29 -0500

>this before jokingly, but I'm surprised to not see it come up again

I think it's not unreasonable, myself.  I've been generally
surprised by the taste and restraint being shown by volunteers,
for which I'm endlessly grateful.

If there are people who would like to help out with a protocol
evaluation but either haven't identified one they'd like to
describe or they have but there's already someone covering it,
perhaps they could get in touch with Mary ([email-masked])
and we can get more of the obvious candidates covered.

Many thanks to everybody who's volunteering.

Melinda

---

From: "Cullen Jennings" <[email-masked]>
Date: Wed, 3 Apr 2002 09:09:30 -0800

I had not considered SOCKS - interesting idea. I did completely miss
Diameter on my list which seems like a better candidate than anything I
mentioned.

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 4:02 AM
> Subject: Re: [midcom] Protocol evaluation contribution reminder
>
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Apr 2002 12:15:53 -0500

> Diameter on my list which seems like a better candidate than anything I

Doesn't help unless someone takes responsibility for writing each one
up.  

I suppose someone could write up more than one.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 04 Apr 2002 12:18:57 +0200

An old email (midcom list 02/07/02) regarding SOCKS and MIDCOM and SOCKS 
is not suitable for MIDCOM:

 > In the MIDCOM case the SOCKS server is the firewall/NAT and the client
 > is located at the MIDCOM agent. After establishing a pinhole/binding
 > in the NAT by the MIDCOM agent, the data flow from the client, e.g. a
 > SIP phone with UDP traffic, has to take the follwing way:
 > SIP-Phone -> MIDCOM agent/SOCKS client -> SOCKS/Server.

This is certainly not the way it should work.

Martin

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de