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

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: "Flanigan, Bill" <flanigab@ncr.disa.mil>
> 
> 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


"Half-baked protocols" is pretty strong language.  The CMP interoperability
status could be the result of:
1) errors in the protocol, which would prevent a single compliant
    implementation from functioning correctly,
2) ambiguities in the protocol, in which two compliant implementations
    would not necessarily interoperate, and
3) errors or omissions in the implementations which cause them to be
    non-compliant with the protocol specifications as written.

Identifying and correcting instances of 2) is clearly one of the functions
of the IETF standards track.

Early adopters should probably refer to RFC2026:

   "Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
                                         ^^^^^^^
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended."

One can only strive to be standards-compliant when there is a Standard
(not a Proposed or Draft Standard) to comply with.  How would
designating CMC or CMP as Experimental or I-D assist early adopters in
not feeling like guinea pigs?  If your boss tells you to implement a
prototype (as a vendor) or pilot (as a user), your choice is to ignore
him and do nothing until there is a Standard, or implement the
specifications that are available.  If you are an early adopter, you
are a guinea pig, whether you adopt an Experimental RFC or a Proposed
Standard RFC.

We in the DMS and now DoD PKI arena are very much guinea pigs, and
there is nothing constructive we can do about it except continue to
design, implement and test.  Other PKIX constituents are in the same
boat.  There's nothing wrong with that; it's part of being in an Open
process (or a democracy, or a free-market economy, or whatever).