Subject: RE: [midcom] Protocol Eval: 3 Conclusions

From: "Mary Barnes" <[email-masked]>
Date: Tue, 25 Jun 2002 11:20:56 -0500

Martin,

I totally agree that the pure numbers don't at all provide enough
information for an accurate assessment; that's just there for completeness
and it does provide a quick assessment wrt protocols that fail to meet
requirements. It also gives you an overview of the level of extensions and
enhancements required to support MIDCOM using any of the protocols proposed.
The question the group must answer is whether failing to meet one
requirement means the protocol is not suitable. At a minimum, I think it
highlights that there's something that requires detailed consideration as to
whether the reason for failure is a key aspect of the protocol (and there's
something fundamentally wrong with applying that protocol to this specific
problem domain), or perhaps there's just an inconsistency in architectures
or frameworks for which the protocol was originally designed. Unfortunately,
I think this type of analysis often leads to huge "ratholes", thus the only
practical approach is to make an arbitrary decision that failing to meet a
requirement means a particular protocol is not suitable.  This all needs to
be discussed by the group. 

There is one additional point that needs to made wrt DIAMETER in that it is
the only protocol evaluated that is currently still in draft form and not
yet an RFC (I thought I had added this somewhere in the -01, but can't find
it now).  

Mary. 

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: Monday, June 24, 2002 7:57 AM
To: [email-masked]
Subject: [midcom] Protocol Eval: 3 Conclusions

The overall statistics looks good at the first view. But consider the 
following points:
- If a protocol fails one of the requirements, it can be used at all, or 
we adapt the requirements. But this can't be the way, since the 
requirements are not made out of pure air, but rather by facts. So one 
'failed' or 'F' should in a result like: Sounds good, but an important 
feature is missing!

- If a protocol has more 'T' than other, but some 'P' or 'P+' as well, 
we should have a look onto these 'P' or 'P+' as well. I think somebody 
else has mentioned this earlier! It might be that one of these partials 
is something we really need, so there is a lot space for discussions.

The pure numbers may not be that good for deciding the protocol. Mary 
has made a good textual comparison between these protocols which 
highlight this topic of 'we have to look behind the scenes'.

This will be the last email off this thread from my side. Looking 
forward to all the discussions and I hope you don't feel bored through 
all these comments.

Cheers
Martin

-- 
Martin Stiemerling

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

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

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 26 Jun 2002 12:41:54 +0200

> be discussed by the group. 

Yes, I agree and let's go for more group discussions.

> yet an RFC (I thought I had added this somewhere in the -01, but can't find

Oh yes, it didn't find this as well.

Thanks for all the responses and looking forward for more answer
from the particular protocol supporters.

Cheers
Martin