Subject: [midcom] Protocol Evaluation document template

From: "Mary Barnes"<[email-masked]>
Date: Wed, 27 Mar 2002 12:52:10 -0600

Hi all,

The protocol evaluation document template is now available at:
http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt

I won't be submitting this to the archives as the intent would be to get
feedback such that the format for the initial protocol evaluation document
can be agreed.  Section 4 of this template contains the "mandatory" content
for the individual protocol evaluations. 

There are a couple of format items for which I would like feedback, so that
we're not arguing these things once we actually get technical content:

1. In section 3, where the protocols are summarized against each of the
requirements, I've got a level 3 heading per requirement to match the
requirements document section 2.  The really pedantic question is whether I
should ensure that the protocol evaluation document is also section 2?    

2. The second question related to section 3 is with regards to the actual
text for the level 3 headings, in section 3.1, I've started copying the
headings verbatim from the requirements document. In section 3.3, I've
abstract the requirement to a higher level description/tag.  Is there a
preference?  You loose a bit of information in the abstraction, BUT
including the text verbatim seems a bit too verbose, however, this does make
this document fairly self contained.  So, if you have a preference, please
let me know now, so that we're not debating this nit later.

Also, there had been some discussion during the meeting to have some
additional comparison criteria that seemed to be geared towards more general
protocol evaluation criteria.  I think it's a good idea for some of this to
be included in the individual documents, perhaps in the section highlighting
the pros/cons of the protocol against the framework.  I've not included such
things specifically in the template at this time, but will if someone has
specific suggestions for which we have WG concensus that these are good
criteria. The things I could think of with regards to simplicity (easy to
implement), efficiency (small code size, fast code, etc.) and other such
protocol "motherhood" requirements tend to be things for which there are
implementation tradeoffs and might end up being far more subjective than the
comparison against the MIDCOM requirements.  However, I think this would be
a useful thing to discuss on this list prior to finalizing the proposed
document content and format.  

Regards,
Mary H. Barnes
[email-masked]
972-684-5432
Wireless 817-703-4806

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Mar 2002 18:09:49 -0500

I must admit that I really feel that this approach is still quite
broken.

The requirements documents are at a high enough level that I do not see
how they would be used to rule out or support protocols. Just about any
sensible protocol that supports a session oriented communication between
two things, with messages in both directions, will meet the
requirements. Thus, the protocol analysis work will enter the swamps of
"efficient" and "simple" and "easier to work with" and other things that
are the source of unending debate on other lists. As an example, the
fact that we will be having an analysis of BOTH RSIP and MEGACO for
suitability, when these are such vastly different protocols, tells me
that we are in for a long and mostly futile debate.

Furthermore, this tactic makes no sense when, in parallel, we have
decided to move forward and specify the protocol abstractly anyway. 

I would really like to understand why we cannot just specify the
abstract protocol completely FIRST, and then evaluate concrete protocols
SECOND. This makes much more sense, since we will know EXACTLY how well
each candidate protocol fits.

I would also welcome comments from our ADs, as I understand they have
been the motivating force behind this comparison work.

-Jonathan R.

Mary Barnes wrote:
> <http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt>
> 
> feedback such that the format for the initial protocol evaluation
> document can be agreed.  Section 4 of this template contains the
> "mandatory" content for the individual protocol evaluations.
> 
> There are a couple of format items for which I would like feedback, so
> that we're not arguing these things once we actually get technical
> content:
> 
> requirements document section 2.  The really pedantic question is
> whether I should ensure that the protocol evaluation document is also
> section 2?
> 
> 2. The second question related to section 3 is with regards to the
> actual text for the level 3 headings, in section 3.1, I've started
> copying the headings verbatim from the requirements document. In section
> 3.3, I've abstract the requirement to a higher level description/tag.
> Is there a preference?  You loose a bit of information in the
> abstraction, BUT including the text verbatim seems a bit too verbose,
> however, this does make this document fairly self contained.  So, if you
> have a preference, please let me know now, so that we're not debating
> this nit later.
> 
> additional comparison criteria that seemed to be geared towards more
> general protocol evaluation criteria.  I think it's a good idea for some
> of this to be included in the individual documents, perhaps in the
> section highlighting the pros/cons of the protocol against the
> framework.  I've not included such things specifically in the template
> at this time, but will if someone has specific suggestions for which we
> have WG concensus that these are good criteria. The things I could think
> of with regards to simplicity (easy to implement), efficiency (small
> code size, fast code, etc.) and other such protocol "motherhood"
> requirements tend to be things for which there are implementation
> tradeoffs and might end up being far more subjective than the comparison
> against the MIDCOM requirements.  However, I think this would be a
> useful thing to discuss on this list prior to finalizing the proposed

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 28 Mar 2002 18:27:24 -0500

At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote:
>requirements. 

Right.  I think there may be some confusion at work, though -
the protocol "evaluation" document is not a protocol recommendation
document - the decision about which protocol will ultimately be
used will take place after the evaluation document is complete.
By then the semantics document should be done or nearly done,
although I'm somewhat disappointed that there hasn't been one response
to the proposal that Tom has put out and there haven't been any other
proposals put forward.  And, frankly, I don't think that the semantics
we settle on are going to have that much discriminatory power.

I understand your concern but I think we're okay.  If you're familiar
with "Indiana Jones and the Last Crusade" you may recall the scene in
which he steps into the abyss only to find that there's actually an
invisible bridge there.  It's possible that there's no bridge here,
but I'm willing to try it anyway.  I really don't want to delay starting 
the protocol evaluation until the semantics are put together - it would
end up taking us over a year to finish.

Melinda

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 29 Mar 2002 10:56:11 +0100

Hi,

please find my comment inline (just a short comment, because I'm on holidays).

> to the proposal that Tom has put out and there haven't been any other

That there haven't been any response or other proposal does not mean that
nobody is working on this topic. I'm currently working on some protocl
semantics, but as always it takes some days to get everything right on the
paper. As well I have talked shortly with Tom on this.
I hope I can provide some notes on Monday .

Martin