Re: CMC Comments

Nada,

Many thanks for the detailed review of CMC and CMMF.  Responses below.

Mike

At 03:00 PM 8/17/98 +0200, Nada Kapidzic Cicovic wrote:
>A couple of comments on CMC:
>
>- Section 2 - abstract identifies ietf-pkix-request@xxxxxxxxxx as the
>address of PKIX mailing list. This is no longer true and a link to
>ietf-pkix-request@xxxxxxx should be stated instead.

Will correct.

>
>- Section 3 - protocol overview states that "CMMF message bodies secured by
>CMS are encapsulated either as PKIData content type or Data content type."
>However, subsequent sections talk only about PKIData and do not mention
>Data content type and how it is to be used. Is this an error in section 3,
>or should the subsequent sections be changed with the intended usage of the
>Data content type?

The above text will be changed to read:

"Within this document, PKIData is the abstract symbolic name for one or
more messages selected from either CMMF or CRMF.  When encapsulated using
CMS, the OID by which PKIData is identified is either id-data content type
or the id-pkix-crs content type."


>
>- A couple of typos are present in the same section. Write:
>      - "encapsulated" instead of "encapulsated" in the first sentence of
>the                                                  section.
>      - "Processing system ..." instead of "Processing systems ..." at the
>                               beginning of page 1 (shouldn't this be page
2?)
>      - "5) Takes action ..." instead of "5) Take action ..."
>A general comment would be to run a spell checker on the whole document.

Will correct.

>
>- "CertResponse" should be replaced with "CertRep" (in the section 3.1).

Will correct.

>
>- The first sentence in 3.2 is very confusing: 
>"The inner-most content type used encapsulate PKIData (i.e. CRMF or CMMF
>message bodies) is either id-pkix-crs or id-data." 
>I suppose it should read: 
>"The inner-most content type used encapsulate PKIData (i.e. CRMF or CMMF
>message bodies) in either id-pkix-crs or id-data." 
>Perhaps a rewrite would be the best choice.

Maybe because the sentence is missing a critical word or two.  Will change to:

"The inner-most content type used to encapsulate PKIData (i.e. one or more
CRMF or CMMF message bodies) is either id-pkix-crs or id-data."


>
>- Section 4.4 has two references to other sections which seem to be wrong.
>The first reference to section 4.3 seems weird to me,

The reference should be section 3.2, pointing the reader back to the
discussion about id-data vs. id-pkix-crs.

Will change

"This message body is then identified as a contentType as defined in
section 4.3, yielding PKIData."

to

"This message body is then encoded into a SEQUENCE as defined in section
3.2, using either id-data or id-pkix-crs as the contentType."

>and the second
>reference to 5.3 is wrong (there is no section 5.3) and should probably
>read 4.3.

Correct.  This should be section 4.3

>
>- on page 5 it is stated that id-pkix-crs is defined in PKIXCERT. However,
>PKIXCERT does not contain the referenced definition.

Hmm.  It was at one point.  I'll have to discuss with Russ, Tim and the
chairs how best to establish this value.

>
>- id-pkidata does not seem to be defined either.

id-pkidata is and will be defined in CMC as follows:

id-pkiData ::= OBJECT IDENTIFIER ( id-pkix-crs | id-data )

This is the ASN.1 equivalent of the text in section 3.2.

>
>- In Section 4.5.1 on page 8 legacy value is stated for some message types.
>Should they be supported as well? Additional text might help specifying the
>actions regarding legacy values. 

Will do.

>
>- Sections 4.7 - 4.8.7 contain a couple of typos, e.g. a sign ' is replaced
>with a sequence M-^R. A couple of other similar errors exist too.

OK. Will fix.

>
>- References chapter should be updated to contain details of all documents
>referred to in the draft. I've found the following references missing in
>the references section, but existing in the text: CRS, CMMF, EES.

OK.  Will fix.

>
>
>I hope my comments are not coming late. I was not aware that CMMF and CMC
>were ready for the last call.

Not too late at all.  Again, thanks.

>
>
>Regards,
>
>Nada
>
>