Dear Milan, Please find below our responses about your comments contained into the DOC file. In another post we'll try to comment the rest of your email. Best regards and enjoy Tokio! Oscar & Jesus ***Pag 4, line 28: MS1: I'd rather not deal with authorization in an OCPS resquirements document. JLG: OK we should clearly separate OCSP and AuthZ, however let's tell the readers that OCSP may be used as a Validation mechanism able to deny access to users (blacklisting through invalidation) prior to let them into the Authz process itself. ***Pag 5, line 28: MS3: IMO there's a significant terminological difference between a "relying party" (any party relying on the PKI) and an "OCPS client" (software used by some relying parties to get some information) JLG: Maybe the definition for both terms should be provided in an introductory manner, but we may be able to specify that "Relying Party" will be used instead through the document. ***Pag 5, line 32: MS4: DO we need this sentence? That's the same meanign of "issuer" as everywhere and always... JLG: I'm not getting your point here, are you saying to use "issuer" instead of "appropiate OCSP Responder"? ***Page 6, line 32: MS6: Can we reach this goal in the near future? I think some transition period with CRL-only clients JLG: Agree with you, however I don't know where in the document such period should be proposed. Anyone in the list with experience from previous GGF recommendations managing with the introduction of new mechanisms/protocols? Maybe if in that paragraph we change the MUST for a SHOULD? However let's note that section 4 applies to OCSP and its use in relying parties; most of the features explained in this section can't be applied to CRLs because they just weren't intended to. ***Pag 7, line 32: MS7: I'd preferably skip the certificate suspension discussion (the previous three paragraphs). Let's define the usage of OCSP within our current environment and take care of the modification of the environment separately. JLG: I see two points here: in first place and as an analogy with the Proxy revocation topic, we could ommit any comments about the certificateHold status until more practical experience is achieved. On the other hand, it may be useful to warn CAs about the potential implications of setting such status for "temporally" revoked certificates because in our experience sometimes it is used indiscriminately. What do you think?