Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
RFC 5940

Note: This ballot was opened for revision 06 and is now closed.

(Tim Polk) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I stumbled a bit over some (very) small points of language. If you have
a mind to, a little polish might enhance the reader-experience.

Also one question about tracking codepoints.

No need to discuss any of these nits with me. Just "Do The Right
Thing" (TM), and move on.

1. Are you adding choices as you say in the document title, or formats
   as you say in the Abstract? I think there is only choice to be made
   from a list of formats; and you are adding some more formats that 
   can be included in the list. This choice/format seems to run through
   the document.

2. In the Introduction

 | The intent 
 | is to provide information sufficient to determine whether the 
 | certificates and attribute certificates carried elsewhere in the CMS 
 | protecting content are revoked.

   a. Is this a compound noun: the "CMS protecting content", i.e. the
      CMS content that provides protection. Or a compound adjective
      applied to a noun: the content that protects CMS. Or adjectival:
      the certificate are carried elsewhere in the CMS and protect
      content. I think you can give this just one meaning by re-wording.

   b. "are revoked": is this "have been revoked", "are in a revoked 
      state", or "are to be revoked"?

3. In the Introduction

 | However, there may be more 
 | revocation status information than necessary or there may be less 
 | revocation status information than necessary.

   Is this *really* helpful? Necessary for what? The information may be
   where? Why is this a "however"?

4. In the Introduction

 | This document specifies two 
 | other formats: Online Certificate Status Protocol (OCSP) responses 
 | [OCSP] and Server-Based Certificate Validation Protocol (SCVP) 
 | responses [SCVP]. 
 |
 | Section 2 discusses the RevocationInformation structure.  Section 3 
 | defines a mechanism to carry OCSP responses.  Section 4 defines a 
 | mechanism to carry SCVP requests and responses. 

   Second para says SCVP req and rsp. First para only rsp.

5. Section 6

 | This document makes use of object identifiers.  These object 
 | identifiers are defined in an arc delegated by IANA to the PKIX 
 | Working Group.  No further action by IANA is necessary for this 
 | document or any anticipated updates. 

   Where are these object identifiers tracked to stop accidental
   double allocation and to allow reference back to defining documents?
   Does the PKIX WG have a registry? Why not use an IANA registry with
   the delegated allocation policy?

(David Harrington) No Objection

(Alexey Melnikov) No Objection

Comment (2010-05-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
4. SCVP Request and Response 

   Unlike OSCP, SCVP permits unprotected and protected responses, where 
   protected responses can be digitally signed or include message 
   authentication codes.  While this provides more flexibility, it 
   complicates when an SCVP response can be validated by entities other

I think the word "implementations" is missing after "complicates".

   than the entity that generated the SCVP request.

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Russ Housley) Recuse

(Sean Turner) Recuse