Skip to main content

Last Call Review of draft-laurie-pki-sunlight-07
review-laurie-pki-sunlight-07-genart-lc-dupont-2013-02-18-00

Request Review of draft-laurie-pki-sunlight
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-02-26
Requested 2013-01-31
Authors Ben Laurie , Adam Langley , Emilia Kasper
I-D last updated 2013-02-18
Completed reviews Genart Last Call review of -05 by Francis Dupont (diff)
Genart Last Call review of -07 by Francis Dupont (diff)
Genart Telechat review of -09 by Francis Dupont (diff)
Secdir Last Call review of -05 by Jeffrey Hutzelman (diff)
Assignment Reviewer Francis Dupont
State Completed
Request Last Call review on draft-laurie-pki-sunlight by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 12)
Result Almost ready
Completed 2013-02-18
review-laurie-pki-sunlight-07-genart-lc-dupont-2013-02-18-00
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-laurie-pki-sunlight-07.txt
Reviewer: Francis Dupont
Review Date: 20130208
IETF LC End Date: 20130226
IESG Telechat date: unknown

Summary: Almost Ready

Major issues: None

Minor issues:
 - section 2 is not enough accurate, for instance:
  * the critical [k1:k2] notation is introduced after its first use, IMHO
   it is the primary one, i.e., [n] is a short hand for [0:n]
  * the largest power of two must be strictly smaller, not just smaller.
   Without this critical detail recursion rules don't work for n = 2^m
 Unfortunately there is no wikipedia or equivalent web page where to refer to
 so the document is the place where all gory details have to be...

 - the Maximum Merge Delay (MMD) is an important parameter but I can't find
  where is the way users get its value, nor any recommendation for it.

Nits/editorial comments:
 - 1 page 4: CA is not a well known abbrev so please introduce it
  (cf 

http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

)

 - 1 page 4: it is a general mechanism but what are its constraints at
  the exception of the intended usage. For instance is the mechanism
  applicable to any end entity public key certificate? or larger??

 - 1 page 5: misbehaviours -> misbehaviors
  (and 3.3 page 16, and others too)

 - 1 page 5: e.g. -> e.g.,

 - 2.1.1 page 6: i.e. -> i.e.,

 - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list"
  is IMHO a bit uncommon even I can understand it.

 - 2.1.4 page 10: using a key of at least 2048 bits. ->
  using a public key of at least 2048 bits. (or a modulus as it is for RSA?)

 - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not
  ASN.1 itself, nor C?

 - 3.1 page 12: accomodate -> accommodate

 - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they
  are insipid and stupid :-)

 - 3.1 page 13: submmited -> submitted

 - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';'

 - 4.6 page 22: honour -> honor

 - 4.6 page 22: convering -> covering? 

BTW if the document creates new OID perhaps they should be put in an annex?

Regards

Francis.Dupont at fdupont.fr

PS: I noted there are still some LC comments in the ML.