[Gen-art] Gen-art last call review of draft-ietf-pkix-rfc5272-bis

[Elwyn Davies <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-pkix-rfc5272-bis-05
Reviewer: Elwyn Davies
Review Date: 5 September 2011
IETF LC End Date: 29 August 2011 (sorry)
IESG Telechat date: (if known) -

Summary:  Probably ready with nits.  I cannot trace one of the added 
pieces of ASN.1 in
the body into the appendix but this may be a problem with my 
understanding of ASN.1.  There is also one possible missing cross 
reference between the updated base RFCs

Major issues:

Minor issues:

Nits/editorial comments:
General: The TBDs for the OIDs in the body are not linked to the 
numbered TBDs in the ASN.1 appendices,

General:  There are a number of acronyms (e.g., RA) that are defined in 
the base (to be updated) RFCs.  I think the definitions (and 
derivations) probably need to be duplicated here (in a separate 
terminology section?)  Thus may be irrelevant if the document is merely 
going to be used as instructions for updates to the base RFCs.

General: There are a number of places where there are instructions 
embedded in alleged new sections. The distinction could be improved by 
adding (say)
'New Text starts here:'

General: There are a few places where it would be desirable to use 
non-breaking hyphens to avoid ASN.1 names being split across lines.

Abstract/s1: It would be useful to give a summary of the general areas 
of the deficiencies.  Presently its not clear why one might want to read 
this doc. This is probably a summary of ss2.1, 3.1 and 4.1)

[Note for s2.3, para 2:  Presumably the change from referencing s6.3.1.3 
to s6.1.3 is an appropriate correction of a typo in the original.]

s2.6, para 2:
> This control is designed to
>    be used in a couple of different cases where an RA has done some
>    additional processing on the certificate request such as key
>    generation and needs to respond with both the original response
>    message from the certificate issuer as well as in the response the RA
>    is generating.  
This seems a bit offhand.  Is it sufficient to accurately to define 
where it is used?

s2.6:  I don't see the ASN.1 for id-cmc-responseBody in the Appendix.  
Is this a bug?

s2.11:  Is the port referred to here the same as the one being allocated 
in s3.1?  If so it would probably be helpful to have a reference to  the 
updated RFC 5273.