Subject: [midcom] Comments on protocol evaluation draft

From: [email-masked]
Date: Wed, 31 Jul 2002 14:35:53 -0500

Middlebox experts,

Overall, I think this work is great. Mary Barnes should be complimented
and thanked for pulling this together.

While I have a few small issues with the facts or claims in Sections
1 and 2, my real concern is with Section 3. The concern is not so much
with the facts presented there, but with the way they might be
interpreted *as presented there*.

What the MIDCOM WG has tried to do in this protocol evaluation, and I
think largely succeeded in doing, is to compare the frameworks and
capabilities of a number of protocols to the MIDCOM requirements and
framework (Many of the MIDCOM requirements addressed the matching of
MIDCOM and protocol framework elements.). If you look at this on a MIDCOM
requirement by requirement (and / or framework element by framework
element basis) against the framework elements and protocol capabilities
of a single protocol, there are a number of possibilities:

- The protocol's framework elements and protocol capabilities match
exactly (or extremely close to exactly) the MIDCOM requirement or
framework element. GREAT! This is what we were looking and hoping for.

- The protocol does not have any framework elements or protocol
capabilities that address the MIDCOM requirement or framework element.
Not so great, but, again, this is what we were looking (but not hoping)
for.

- The protocol's framework elements and protocol capabilities somewhat
match the MIDCOM requirement or framework element. Here's where I start
to have some problems.

Where the match is not exact, there's two possibilities (or a
combination of them):

- In the individual protocol evaluation, a proposal is made to modify
or extend the protocol's mandatory framework elements or protocol
capabilities, or to modify optional framework elements or protocol
capabilities, to match the MIDCOM requirement or framework element.
From our perspective, this is good, but it may not be so good to other
users of the protocol. If the protocol is single purpose with few users
at this time and no guarantee of forward compatibility (e.g., RSIP),
modifying the protocol ain't so bad. But if the protocol has other
purposes, many users, or the guarantee of forward compatibility, this
may not be so good (The implications of "other purposes" and "many
users" is hopefully obvious. I'll return to the issue of guaranteed
forward compatibility below.). Also, extending the protocol with
optional framework elements and capabilities is probably not bad.

- Alternately or in combination, a proposal is made to "think about the
MIDCOM requirement or framework element in a different way" so that the
match is exact or almost so. I think there's quite a bit of this going
on in the protocol evaluations. Taken individually, if the proposed
change in thinking is not large, this might not be bad. Taken together,
if the sum of all such changed thinking for a protocol is not large,
this may also be not bad.

But, if taken together the sum of all such proposals for a given
protocol is large, then essentially this says that the MIDCOM framework
or requirements would need some rather extensive revision to match the
protocol's framework and capabilities. That's probably bad.

For both of the above alternatives, the protocol would have been scored
as partially matching the MIDCOM requirements. But the distinction
between the two alternatives is lost in the scoring, so that the count of
the partial matches can not be easily evaluated as being overall good or
overall bad.

I didn't go through the exercise (and maybe I should) of marking each
partial requirements match as one or the other of the above and
counting the number of each alternative for each protocol, but my gut
feeling is that we may have a problem here.

Returning to the issue of guaranteed forward compatibility, if the
proposal is to modify or extend mandatory framework elements or protocol
capabilities, or to modify optional elements or capabilities, then all
other users of the protocol, or its modified optional elements and
capabilities, would have to support the changes that were made to the
protocol for MIDCOM. Depending on the size of these changes, this may
not be acceptable to the protocols other users. And we probably
shouldn't consider these types of changes without those users buying
into them. Again, I didn't specifically count the applicable scorings
here and maybe I should have, but in this case I don't really think we
have much of a problem.

Another issue that I have with the whole evaluation is that it did not
consider the impact of a protocol's mandatory framework elements and
protocol capabilities that are *not* required by MIDCOM. The problem
here is that middleboxes and agents / applications may have to support
these even though they're not used. If the protocol has another
simultaneous use in the middlebox or agent / application, then the
impact is not so bad, in fact there may be no impact at all. But if
the use of the protocol is its first use in the middlebox or agent /
application, then I think we have to seriously consider this potential
problem. This problem relates to, but is not exclusive to, library and
source code reuse, which in general is desirable. But if the library or
source code has a lot of unused capabilities, and the MIDCOM implementer
can't (afford to) remove them, then this will place an unnecessary cost
on implementations.

I have no idea how to evaluate this in advance, but I have a gut feeling
we may have a *real* problem here. I am certainly open to ideas on how
to evaluate this in advance. But maybe we'll just have to wait for
specific protocol proposals to be able to see through this issue.

So, overall, I think the evaluation is good, but I have some issues with
how the facts presented, especially the summary counts, may be
interpreted.

Comments expected and welcome.

Jim

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