RE: New SCMP Discussion List

I would be very interested in hearing a response to this e-mail from the
IETF.

Gunther has some good points here.

-Dave Darnell

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Gunther Schadow
Sent: Monday, June 28, 1999 12:15 PM
To: [email protected]; [email protected]; [email protected]
Subject: Re: New SCMP Discussion List


Hi,

I just browsed over the SCMP draft

http://www.ietf.org/internet-drafts/draft-arnold-scmp-03.txt

and I think it does contain some good ideas. However, I have a few
questions and I am unsatisfied by the lack of coordination that is
apparent in IETF working groups.

First the questions: I wonder how specific this SCMP protocol is for
the PKCS security protocol suite. I could not find the convincing
argument for such a dependency, nor could I see the dependency itself.

Second, and probably more important, this draft seems to be not the
entire picture of the protocol. How do the client and server connect?
Is this a direct TCP connection such as with SMTP or HTTP, or are the
SCMP messages sent as RFC822 messages amd through SMTP (or HTTP)? How
are the error messages returned? Did I miss something or could I not
implement the SCMP protocol with only what I see in the draft?

Now my wining.  I think that the emerge of this SCMP draft is a sign
of a bad coordination that goes on in the IETF.  There is a working
group called EDI-Internet Integration (EDIINT) that addresses EDI/EC
messaging over the internet for quite a few years now. I want to know
why there is a completely new and seemingly unrelated protocol "SCMP"
now?

I assume that the SCMP authors have done their duty to research the
field and have studied EDIINT specifications (though they don't
reference them in their draft.) I can see that the SCMP authors might
have missed some points in the current set of EDIINT specifications
(so did I for a long time.) And I can also see that the low activity
and delay in release of drafts to RFCs is a bad vital sign for the
EDIINT group. However, rather than quickly creating just another
protocol to do basically the same thing (with basically the same
means,) I would have found it more appropriate for the SCMP authors to
stir up some discussions in EDIINT about the missing features (e.g.,
the Time-To-Live real time feature.)

I believe that the world in general and the IETF in particular suffers
from today's popularity of standards. It seems as if standards have
become such prestige objects, that whoever believes he is a smart guy
writes a standard like he would write scientific papers.  This defeats
the purpose of standardization (required joke: "The nice thing about
standards is that there are so many to choose from!") If IETF
leadership does not step up and do some active coordination, Internet
standardization will become a farce.  The area chairs of IETF or the
IAB, if they see a potential overlap should:

(1) Force people to join another WG rather than opening up a new WG.
(2) Force existing WG and its chairs to listen to and appreciate the
    new ideas.
(3) Facilitate a resolution of disagreements and incompatibilities.

If IETF and IAB does not take on such a steering role, standardization
will no longer decided by IETF processes but by sheer marketing
power. Whatever Microsoft/RSADSI/u-name-it will choose will be the
standard.

As for SCMP, I'd like to see an open discussion on EDIINT WG list to
make us aware about the missing features in RFC1767 and associated
specs.  It makes much more sense to relaunch RFC1767 to include time
to life and secure message id, sequencing and referencing, than to
have yet another incompatible protocol.

regards
-Gunther

DISCLAIMER: I have no personal or material interest in the existing
EDIINT standards or in pushing aside SCMP. But please, let's be sane!

Gunther Schadow -----------------------------------
http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
[email protected] ---------------------- #include
<usual/disclaimer>