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

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 28 Jul 1999 08:24:53 -0400

Slapping an RFC number on half-baked protocols is indeed experimental.  So
why not make it so (pro-actively for CMC and retro-actively for CMP)?  And
what's wrong with progressing from Experimental to new I-D to Proposed when
the darn thing finally works?  I believe that vendors and early adopters
striving to be open-standards compliant are growing weary of being PKIX
guinea pigs (which seems tantamount to being played for suckers).

Bill

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Tuesday, July 27, 1999 8:28 PM
> To: 	[email-masked]
> Subject: 	RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
> At 02:37 PM 7/27/1999 -0700, Warwick Ford wrote:
> >      Internet-Drafts are draft documents valid for a maximum of six
> >      months and may be updated, replaced, or obsoleted by other
> >      documents at any time...
> 
> This doesn't prevent someone from doing an implementation; it prevents
> them 
> (or should prevent them) from shipping it as a product. There is a huge 
> difference. The reasons for CMC existing at all are needs that are stated 
> in the document. If these are real needs, there are probably developers
> who 
> would like to meet those needs.
> 
> >I think any I-D implementation requirement would be highly dubious.
> 
> We disagree here. I think I-D implementations help decide whether complex 
> protocols like CMC and CMP will possibly work.
> 
> >   I can
> >imagine that many implementors are awaiting stabilization of the spec.
> >(i.e., progression to Proposed Standard status) before even starting to
> >implement.
> 
> That may be true, and in general that's OK. However, CMC and CMP attack
> the 
> same problem and use many of the same technologies. Because we now know 
> that there are probable flaws in CMP, it might be wise to make sure that 
> similar problems are fixed in CMC before putting it on standards track.
> The 
> way the flaws were found was with interoperability testing, not by reading
> 
> the spec, as many of us did with CMP.
> 
> If you are correct in saying that developers aren't going to start 
> implementing until they see an RFC, then we should definitely put it out. 
> On the other hand, if there is already one or two developers with at least
> 
> partial implementations, testing could help avoid problems that have been 
> found with CMP.
> 
> >   Given the lengthy review this document has received (over at
> >least 2 years), I see no good reason for changing the usual procedures.
> 
> The "usual procedures" for complex protocols for which there are no known 
> implementations are often Experimental RFCs.
> 
> If you feel that CMC has absolutely none of the flaws found in the CMP 
> interoperability testing, that's fine, but I would want to know why you 
> feel that way. None of us thought that CMP would test as badly as it did, 
> given all the review that was done on it.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: "tog" <[email-masked]>
Date: Wed, 28 Jul 1999 07:40:36 -0700

Bill -
----- Original Message -----
From: Flanigan, Bill <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 28, 1999 5:24 AM
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt

> the darn thing finally works?

This implies that there might need to be a re-straifitcation of the concept
I-D into several working class documents, proposal, in-discussion-process,
RFC Candidate, etc... probably not a bad idea.

>I believe that vendors and early adopters

This is in and of itself a really important concept since what it says is
that the "Industry wants End-Use Solutions" and not complex "you figure out
how to use it yourself" stuff that  we have to put together so far per say.

My feeling is that you are exactly right on here. What this group needs more
than anything now in my opinion is the completion of the PKIX4
recommendation and also the creation of some use-model recommendations to go
with the core enablement we have already developed.

Todd