Subject: RE: [midcom] WG scope/deliverables

From: "Christian Huitema" <[email-masked]>
Date: Wed, 24 Jan 2001 09:40:53 -0800

At this stage, I believe it is important to concentrate on the
requirements. Part of the problem with RSIP is that it tries to solve a
very large problem set, and so end up being very hard to deploy -- you
basically have to rework all the TCP stack in the clients. I think that
we should take the "ease of deployment" into account. I see at least
three dimensions that affect the ease of deployment:

1) Timing considerations. Should we open resources in real time, exactly
when we need them, or through an off-line configuration action? The
latter is less powerful, but it is also much less intrusive on the host
software. A configuration can be changed by usin the right command line
parameter; a real-time action implies rewriting the software to call an
API, and to deal with the new error cases introduced by this API.

2) Trust model. Most of the "NAT appliance" configuration systems today
have a very simple trust model: whoever is inside the perimeter is
allowed to modify the mappings through some vendor specific web
interaction or telnet connection. Most of the firewalls also have a
simple trust model: only registered administrators can change the
configuration. We could change that to introduce various forms of ACL or
policy decisions, but this definitely introduces a higher complexity in
both software and operation.

3) First party versus third party. There are implications on the trust
model, which is obviously more complex in the first party case, and on
the protocol design -- this has already been debated in the list. First
party solutions tend to be only required if we want to enable
"real-time" opening, but real-time can also be achieved with relay
servers.

-- Christian Huitema

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 5:15 AM
> To: Randy Turner; [email-masked]
> Subject: Re: [midcom] WG scope/deliverables
> 
> 
> > I'm assuming that the model of an RSIP client and server 
> would be an example
> > of middlebox communication, per the charter. And further, 
> that the real
> > deliverable for this working group
> > would be a capability that would superset RSIP and provide 
> a more generic
> > model for middlebox policy interrogation, including more 
> sophisticated trust
> > models. Is this correct?  
> 
> This isn't a competition and there's no intention to
> supersede RSIP.  RSIP doesn't solve the entire set of
> problems we're facing (3rd-party "control" interfaces,
> large number of always- or usually-on devices).  It's
> possible that RSIP may end up being used as the base
> protocol when we do get to that stage, but there are
> other candidate protocols, as well.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

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

---

From: Manish Karir <[email-masked]>
Date: Thu, 25 Jan 2001 09:17:54 -0500 (EST)

Hi,

I'm new to the list and this working group...
though I have scanned the charter and the list archives..I'm still
not clear regarding the scope of the WG and where this group fits 
with the rest of the group.

Basically I found this WG while looking for a more sympathetic
place for my arguments for supporting intelligence in the middle 
of the network-boxes....All the other groups are outright hostile
to anyone proposing anything thats not End-to-End.

Is this the charter of this group?. Basically to come up with some agreed
upon symantics for devices int he middle of the network, to 
support things cannot be done end-to-end.?

Though I have seen talk of NAT in this group..I would also like to point
out some other types of devices that might benefit from this effort.
In particular my interest was in TCP-connection splitting gateways. 
But to a certain extent caches and all sorts of proxies fall into the 
same group as well.

thanks
manish

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 25 Jan 2001 17:14:05 +0100

> to anyone proposing anything thats not End-to-End.

Actually, the idea here is to move the intelligence OUT of the boxes.

Jiri