RE: LAST CALL: draft-ietf-pkix-cmc-05.txt

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:phoffman@imc.org]
> Sent: 	Wednesday, July 28, 1999 12:54 PM
> To: 	ietf-pkix@imc.org
> Subject: 	Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
> 
> At 01:47 PM 7/28/1999 +0100, Keith Brady wrote:
> >I'm not sure we're actually that far from having working interop. Not all
> >of Bob's report is doom and gloom and we expect better results at the
> next
> >one.
> 
> This is good to hear. However, I understand that the issues are not bad 
> implementations, but lack of clarity in the RFC. The reason I brought this
> 
> up with respect to CMC is that we now have a track record of lack of 
> clarity getting in the way of interoperability. We should take the 
> opportunity to fix it (if it exists in CMC) before it goes on standards 
> track. We as a Working Group owe that to the developer and user
> communities.
> 
> Having run many interop events, I can assure you that if you didn't
> achieve 
> interoperability after two concerted efforts, the spec has problems.
> That's 
> why I queried about current implementors of CMC. If there are any, they
> can 
> attest to whether or not the spec is implementable from. If there are more
> 
> than one, and even informal testing has happened, they can attest to 
> whether or not the spec is clear.
 
The following is my understanding of what happened at the CMP interop trials
(from discussion with someone who was there).  In a number of cases (not
all, by any means, but quite a few), Party1 and Party2 would be trying to
interoperate and the conversation would go something like this:

   Party1:  Here's the problem.  You're doing it like this and we're doing
it like that.  Why in the world are you doing it this way?

   Party2:  Because the spec says to do it this way.  Look here on page xxx.

   Party1:  Oh.  I guess I hadn't seen that part.  O.K., we'll fix it.

Many times, when people actually looked at what the spec mandated
(especially in Appendix B), problems were resolved.  I think Bob's document
did not reflect much of this and the result was that others (who weren't at
the trials) ended up with the impression that the specification was the
source of all the problems.

Reading the spec can actually go a long way toward getting an implementation
right.  :-)  At the first interop trial a number of people had not read all
of it, or had not read it carefully enough, or whatever.  By the second
interop trial the situation had improved and much progress was made.  So,
while I would be the first to admit that the specification is not perfect
(it's hard to find one that is!), I think we need to be a little bit careful
with off-the-cuff statements like "lack of clarity" and "the spec has
problems".


In any case, all of this points out the importance of interoperability
testing and I'm glad that Bob has made the effort to organize these events.
He has suggested doing the same with other PKIX protocols, which is a great
idea.  Does this have to happen before an I-D can go to Proposed Standard?
It would definitely be nice, but I don't think it's a requirement.

Carlisle.