Subject: [midcom] Protocol selection procedure

From: Juergen Quittek <[email-masked]>
Date: Wed, 16 Oct 2002 11:06:25 +0200

Hi all,

Maybe I'm too impatient, but I want to get an idea how we are
going to select the midcom protocol.

We have our requirements, we have an almost completed evaluation
of five protocols, and we are getting towards an idea of the
semantics of the protocol. This is apparently sufficient preparation
for starting to think about the decision process.

Unfortunately, the evaluation did not identify a clearly superior
candidate, but found that there are several ones that are suited.

This positive finding (we do have a choice!) should not become
a negative one by blocking progress because we do not know how
to decide.

So, how to go on?
    Shall we refine our seelection criteria?
    Shall we prioritize them?
    Are there already clear preference for one of the protocols?
    Shall we wait until some of the candidates have died? ;-)

We are not the only working group that was requested by the IESG
to select a protocol. Does anyone have experieces from other WGs
handling similar protocol decisions?

    Juergen

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Oct 2002 08:05:49 -0400

Because this process has the potential to be singularly
unproductive, I've been talking with our ADs about how they
think we should go about it.  Those discussions are not
finished, which is part of the reason that we haven't begun
the discussion on the mailing list.

At a minimum, the first step will be to eliminate any
obviously weak candidates.

Another working group which evaluated a number of protocols
and selected one is AAA.

Melinda

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 16 Oct 2002 14:35:56 +0200

>candidate, but found that there are several ones that are suited.

I actually think this protocol shopping is a bug in strategy. With 
some effort very many protocols may be tweaked to make requirements 
happy, each having some cons and prons. The result seems questionnable 
-- after two years of advocating why one's pet better than someone else's,
we may easily end up with a suboptimal protocol. I would not be surprised
to see too big complexity, because of reusing a protocol for too many 
purposes.

I saw few simple proposals on the table and would prefer going ahead with
them. Simplicity is good and actually should be boldly stated as R0.

-Jiri

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 17 Oct 2002 10:39:47 +0200

[...]
> some effort very many protocols may be tweaked to make requirements 

Protocol shopping takes a lot of time for sure, but it may be good to 
take a look around to existing protocols. The point is that it is 
impossible to tweak a protocol to fit with the requirements and 
framework unless you break the existing protocol (and then it isn't 
anymore the actual existing protocol). But it is possible to tweak the 
evaluation of a protocol versus requirements and framework, so that the 
protocol seems to be suitable.

> to see too big complexity, because of reusing a protocol for too many 

Agreed, that we have to be careful, otherwise we really end up with a 
suboptimal or even worse with a non-working protocol.

> them. Simplicity is good and actually should be boldly stated as R0.

I would prefer as well a simple protocol!

Martin