Subject: [Gen-art] review of draft-ietf-sidr-cp-16.txt

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Feb 2011 12:05:36 +0100

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-sidr-cp-16.txt
Reviewer: Francis Dupont
Review Date: 20110224
IETF LC End Date: 20110221
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - the document uses RFC{[wxyz]}4 as references in place of short
  titles of references, this is not good because:
  - it makes the reference hard to follow, i.e., the reader has
   to solve the indirection each time
  - it strongly binds the document livetimes to references'

 - 1 page 7: IMHO the document should clearly state it is about
  public key certificates (vs attribute certificates)

 - 1 page 7: in
  "In the interest of keeping the document as short as
   reasonable, a number of sections contained in the template are
                                                              ^^^
   were/have been?
   omitted from this policy because they did not apply to this PKI."
                                         ^^^ do?

 - 1.3.2 page 9: please check the 1.4.1 pointer
  (could be 1.5.1?)

 - 2.4 page 14 (and at other places): I learnt Latin so I have
  a concern with 'data is' (as data is the plural of datum).
  I leave this point to the RFC Editor who will fix or won't fix this...

 - 3.2.2 page 16: bedescribed -> be described

 - 3.2.4 page 16: please extend the SIA abbrev
  (it is its first occurrence)

 - 4.3.2 page 20:
  "The means by which a subscriber is notified is defined..."
                                               ^^ are?

 - 4.5.2 page 21: TA -> Trust Anchor (it is its only occurrence)

 - 13 page 40 (many times): ," -> ",
  (to conform to RFC standard style)

 - Authors' Addresses: +1 (617) xxx is not in an E.123 format,
  why not +1 617 xxx?

Regards

[email-masked]