Subject: RE: [midcom] requirements-01 status

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Fri, 29 Jun 2001 10:44:58 -0600

> The middleboxes that I am talking about have no routing tables or
routing
> capability. They sit on a pipe between two routers. Whatever comes in
on one
> end of the pipe is sent out the other end. The routers take care of
sending
> the packets down the right pipe.

In this simplistic case, the routers can be reasonably expected to take
care of anti-spoofing as well, so it really won't matter if the
middlebox uses the same set of pinholes on all interfaces. But on the
other hand, I don't see a big problem with adding something like a
1-byte token to the spec that could be given meaning outside of midcom.
If you want to implement it to mean "interface" then that could be fine
as long as you don't expect that byte to mean anything outside of your
own closed, preconfigured system.

For the general case, I agree with Melinda that interface identification
doesn't belong in midcom, especially when it forces application agents
(assumed to be ignorant of the routing topology) to make interface
decisions. We don't want to force the tail to wag the dog. But adding a
1-byte token might be useful for very simple toplogies with static
routing and simple agent configuration. Comments?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 29 Jun 2001 17:31:03 -0500 (CDT)

> routing and simple agent configuration. Comments?

	On the one hand, adding 'interpreted any way you like' elements
to a protocol sounds very spooky, on the other hand it seems useful.
I'd like to see it, when the time comes to define it, wrapped up in
language to the effect that:

	- the middlebox may define specific semantics for such
	  and such an imeplentation defined cookie
	- the MIDCOM agent should not by design assume any specific
	  semantics for that cookie
	- the MIDCOM agent may allow user specification of cookies
	  (in some undefined way).

	The point being that the engineer who *builds* the MIDCOM
Agent isn't allowed to assume anything about what such cookies do,
but the user who *deploys* and Agent (presumably in concert with
a specific middlebox) is allowed to assume semantics (presumably since
the Brand X Middlebox implements them, and says so right in the manual).

	In short, I support the idea, and might well support other
uses of it in other places, but with the caveat that it needs to
be well fenced-in to prevent weird vendor lock-in scenarios.

		Andrew

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