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

[Robert Moskowitz <rgm-sec@xxxxxxxxxxxxxxx>]

At 02:05 PM 7/28/99 -0400, David P. Kemp wrote:

I think David captures much of our current standards/implement/deploy
philosophy today in the IETF.  If we could just get those pesty reporters
and users to leave us alone while we shake out the bugs.....  :)

What this means to me, however, is now that CMC IS in last call, there had
better be vendors committed to developing against it and THEY can estimate
time to testable code and thus plan for their workshops and we MIGHT expect
to see a report on CMC at DC.


>> 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).

Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com