Subject: [midcom] One week to review: Updated version of MIDCOM Protocol evaluation draft submitted

From: "Mary Barnes" <[email-masked]>
Date: Sat, 15 Jun 2002 00:32:48 -0500

Hi all,

I've just submitted an updated version of the MIDCOM Protocol evaluation
draft.  Until it's available in the draft repository, it can be obtained
from:
http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-01.txt

I will be following up with replies to several of the email threads to
summarize how the issues raised have been handled, but I did want to bring
the most major change to your attention.  Another category of compliancy
classification has been added and several of the items have been
re-classified. P+ is now used for those protocols that can easily be
extended to support the requirement and to differentiate these partial
compliancies from those that require larger changes which may not
necessarily be compatible with the protocol's design.  This addition seemed
to resolve many of the issues raised on the list and also allowed
classification of some requirements for which we did not achieve WG
concensus on P vs. T. 

In addition, I'd like to summarize 3 remaining issues which are denoted by 2
Editor's notes and one Contributor's note in the document which require some
consideration/discussion:

1) There seems to be some confusion about the SNMP evaluation in that the
SNMP Agent is defined to be the MIDCOM PDP (versus the PEP).  However,  text
in section 1.1.3 seems to imply that the SNMP evaluation is based on the
MIDCOM PDP being in the Middlebox. If this is indeed the implication, we
need to add a statement to that affect. 

2) There had been an issue raised with regards to the application of Megaco
VMG's to MIDCOM (req. 2.1.2).  This has been changed from a P/T to a P+. If
everyone is okay with that, I'll just remove the Editor's note. 

3) Several of the protocols encountered issues with 2.2.7 (Multiple agents
acting on the same ruleset), with the RSIP evaluation indicating that it may
be impossible to satisfy this requirement along with the deterministic and
security requirements and RSIP has Failed this requirement.  Only the SNMP
evaluation provides a concrete explanation of how the protocol can meet this
requirement. I know there was lots of discussion around this topic during
development of the requirements and around the semantic analysis, so I don't
anticipate we can resolve it for the evaluation.  However, I think the issue
that should be resolved is the evaluations against this one are inconsistent
with RSIP failing, MEGACO and COPS being partically compliant, and DIAMETER
and SNMP being Fully Compliant.  In addition, I think it might be useful to
include a mention of this issue in the conclusion. 

The plans for completing the next round of updates are as follows:
June 14th-June 21st  Mailing list discussion of -01 version of draft. 
June 24th (noon CST) Cutoff for input to -02 version. 
June 28th       Updated Draft (-02) Available.  The plans are for this
version of the
                draft be ready for WGLC (pending WG chair approval), with
discussion     
                of any remaining open issues in Yokohama.

Note that these dates have to remain fairly firm as the cutoff for Internet
drafts for Yokohama is July 1st. 

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

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