Francis,
Thanks for your review. Responses inline.
spt
Francis Dupont wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pkix-authorityclearanceconstraints-02.txt
Reviewer: Francis Dupont
Review Date: 2009-08-10
IETF LC End Date: 2009-08-14
IESG Telechat date: unknown
Summary: Not Ready
Major issues: the I-D is too hard to read
Minor issues:
- IMHO a transition paragraph is needed at the end of the Introduction
in order to introduce technical dependencies:
* clearance attribute is in fact from 3281bis (this is obvious when
one reads the ASN.1 module appendix but it should be mentioned as
soon as possible)
I agree that's why it's in the last sentence of the 1st paragraph in the
intro ;)
* the processings augment the RFC 5280 section 6 (so the text is
understable only with this section in mind)
It says this in section 4.1 and 5.1, but we could move something to the
intro to explain that we're augmenting the 5280/3281bis processing
rules. How about:
This document augments the certification path validation rules for PKCs
in [RFC5280] and ACs in [RFC3281bis].
The whole idea is to prepare a first reader (IMHO it is a problem when
a document needs to be read more than once to get a good idea about
what it specifies :-).
- another issue is the multiple values in a Clearance attribute.
The Clearance attribute syntax of section 2 is in fact for an
AttributeValue type and doesn't include multiple values (only
multiple SecurityCategory). Of course the Attribute in AC can
contains multiple values, so the text often uses the term "value"
in a very ambiguous way.
We restrict the number of times clearance can be included in a
certificate to one or zero. We also restrict it to be single valued.
Are you referring to the Authority Clearance Constraint extension that
can include multiple values?
Nits/editorial comments:
- Abstract page 2: TA and AA abbrevs are useless, CA abbrev must be
expanded. Note abbrevs are useless in abstracts if they aren't
possible keywords or very common (the RFC Editor has a list of
common abbrevs with very common, cf PS). In no case the Abstract
can introduce an abbrev for the body.
We'll expand abbreviations on their first occurrence in the main body. I
think they're all expanded by the end of the Introduction
- ToC page 3: Author's Addresses -> Authors' Addresses
Fixed.
- Introduction 1: please introduce abbrevs (PKC, PKI, CA, AA, TA)
Fixed.
- 3 page 6: I don't understand this statement:
"In
addition, each Clearance attribute in the SEQUENCE must not contain
more than one value."
perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)?
SEQUENCE refers to the ASN.1 construct for the extension. We didn't
capitalize sequence previously so we'll switch it to lower case. Note
the must ought to be MUST.
- 4.1.1.2 page 8: ,, -> ,
Fixed.
- 4.1.1.2 page 8: can't understand:
If any of the Clearance attributes in the permitted-clearances
contains more than one value
This check makes sure there is only one value in permitted-clearances.
- 4.1.1.3 page 8: 6. -> 6 (for uniformity among the text)
Fixed.
- 4.1.1.5.1 page 9:
in "If the permitted-clearances has special value of all-clearances, exit
with success." what about the effective-clearance (unchanged?)
There's no need to set this value as it's the special case where it
matches all.
- 5.1.1 page 11: [RFC5280 -> [RFC5280]
Fixed.
- 8 page 15: what is id-TBSL?
It stands for To Be Supplied Later. I guess now would be a good time ;)
I need to get an OID from Russ we'll add this in the next version.
- Author's Addresses page 19:
Author's Addresses -> Authors' Addresses
EMail/Email: choose one of them (EMail seems to be the standard)
Fixed.
Regards
[email protected]
PS: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
PPS: it should be fine to get an implementation report (not required
for Proposed Standards but in this case it should show there is no
trivial mistakes in the processing stuff).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
