Re: [Gen-art] draft-ietf-ntp-autokey-06.txt
Russ - I've added the RFC Editor comments. I expect we'll need another rev before publication, which should incorporate those comments. - Ralph On Aug 19, 2009, at 4:58 PM 8/19/09, Russ Housley wrote: Ralph: Russ - would you be willing to clear your DISCUSS and capture Joel's new issues in a COMMENT? - Ralph On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote: This document is nearly ready for publication as an Informational RFC. While my comments have been resolved, some minor issues apparently crept in during the editing process.. These are small enough that they can probably be dealt with in notes to the RFC Editor if no other issues are found. However, they are sufficiently ambiguous that they should not be left for rediscovery by the RFC Editor. Two individual sentences became truncated (Section 7, first paragraph was created. = was. and section 8, third bullet the server.=the.) Can you post an RFC Editor note this one? We have experience that shows RFC Editor notes are read, but comments are almost always ignored. Section 8 on the Sign exchange previously said that the information was signed using the private key. Now it says that it is signed using the public key. As I understand it, the signature is generated with the private key to be verified with the public key. I am not sure what the right words in the paragraph would be. (I was happy with private key before since the signer used his own private key.) Again, I'd like to see an RFC Editor note for this one? In the paragraph on the extension field parser length calculation, with the text beginning: If greater than 22 an extension field is present. If the length is .. has two minor issues. I believe it would be clearer if it said If the remaining length is greater than 22 an extension field is present. If the remaining length is ... I'm fine with a comment for this one. Russ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mext-aero-reqs-04.txt
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-mext-aero-reqs-04.txt
Reviewer: Vijay K. Gurbani
Review Date: Aug 20, 2009
IESG Telechat date: Unknown
Summary: This draft is ready for publication as an Informational.
This was a very interesting draft to read.
The draft has 0 major issues, 0 minor issues, and 2 Nits/Editorial
comments.
Nits/Editorial comments
1) What is the Gatelink system? There are at least two
instances of it in the draft. Any reference or a short
sentence describing this would help the reader not
verbose in this particular domain.
2) Missing closing bracket ')' in Section 2.1.1, third paragraph,
third line; i.e., should be ... in Appendix A.)
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mext-aero-reqs-04.txt
[RESEND, forgot to CC the chairs ... sorry.]
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-mext-aero-reqs-04.txt
Reviewer: Vijay K. Gurbani
Review Date: Aug 20, 2009
IESG Telechat date: Unknown
Summary: This draft is ready for publication as an Informational.
This was a very interesting draft to read.
The draft has 0 major issues, 0 minor issues, and 2 Nits/Editorial
comments.
Nits/Editorial comments
1) What is the Gatelink system? There are at least two
instances of it in the draft. Any reference or a short
sentence describing this would help the reader not
verbose in this particular domain.
2) Missing closing bracket ')' in Section 2.1.1, third paragraph,
third line; i.e., should be ... in Appendix A.)
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
Francis Dupont wrote: In your previous mail you wrote: 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 ;) = well, I missed it (:-). Well I missed your response. Somebody had to tell me to respond so we're even ;) 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. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. Okay now I get it. We'll work on a revision to address this. - 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. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? The sentence in question is going to get deleted. - 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. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... I think this will end up getting deleted too. - 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. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. I don't think we're going to change this one. effective-clearance has no meaning when it's set to all-clearances. - 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. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). Fair enough. To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. We'll go through these to fix the ones that make sense after we incorporate the changes for the value text. francis.dup...@fdupont.fr PS: occurences of value: I delete the ones we got right ;) 3 The syntax for Authority Clearance Constraints certificate extension contains Clearance values that the CA or the AA asserts. = correct but IMHO misleading. I propose to remove the word values. Agreed 3 In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. = incorrect (no attribute, lower case SEQUENCE, upper case must, no multiple values). Sentence to be deleted. 4.1.1.2 If any of the Clearance attributes in the permitted-clearances contains more than one value, set effective-clearance to an empty list, set error code to multiple values in input, and exit with failure. = incorrect (no attribute, no multiple value) Sentence to be deleted.
Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
Francis, Good catch on Authority Clearance Constraints not asserting clearance as an attribute. We are fixing the I-D. -Original Message- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Sunday, August 16, 2009 12:44 PM To: Sean Turner Cc: gen-art@ietf.org; Santosh Chokhani; tim.p...@nist.gov Subject: Re: review of draft-ietf-pkix-authorityclearanceconstraints-02.txt In your previous mail you wrote: 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 ;) = well, I missed it (:-). * 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]. = fine 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. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. - 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. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? - 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. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... - 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. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. - 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. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. francis.dup...@fdupont.fr PS: occurences of value: Abstract The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. =
Re: [Gen-art] Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
The thread so far has gotten difficult to follow, so I'm going to try to reset the conversation. I think we have been disagreeing in 2 areas. The first is how much the document should say about how much semantic knowledge of sieve is expected for editors. On rereading the thread, I think we're expending a lot of energy here on something that really isn't that important. So I yield that point. OTOH, I think we've highlighted some interoperability could be important. First, I think we are talking past each other about applying requirements to sieve editors in general--that is, editors that do not implement this spec. I never intended my comments to apply to non-XML based sieve editors. It would be nice if they interoperated, but that's not what this draft is about. (For that matter, if there is any attempt to standardize their behavior beyond a hope that they all create correct sieve scripts, I am not aware of it. But I think the draft creates opportunities for failure between implementations of the xml format. Let me try to make my previous questions on work group more concrete. I see 3 interop scenarios entirely among implementations of this draft. Again, _all_ of my comments and questions _only_ concern the set of editors and processors that implement this draft. 1) Interop between an arbitrary xml-based editor and an arbitrary xml to native sieve processor - I think this is covered reasonably well, and is explicitly mentioned as a goal of the draft. 2) Interop among different xml-based editors - that is, can editor B operate on XML created by editor A, and can A operate on the result without losing data? (I am not expecting that B would be able to edit or render every feature supported by A). This is not well supported by the current draft due the fact editor B would be allowed to remove any metadata inserted by editor A. This could be fixed with a normative requirement to not delete metadata elements that you don't understand, and possibly not to delete elements from xml namespaces you don't understand. Failing that, it would help a lot to offer non-normative guidance that any metadata or extension namespace elements are likely to go AWOL between editing sessions. 3) Interop among different xml to sieve conversion processors - that is, can I take an sieve script in xml, convert it to native sieve with processor C and convert back to xml with processor D without losing data. Can I do the same converting from native sieve to XML and back to sieve? This scenario is jeopardized by the SHOULD (rather than MUST) level requirement to use the structured comment format to store metadata. This could be fixed by strengthening the requirement to a MUST. Failing that, it would help to include the motivation for making this a SHOULD rather than a MUST, and guidance on the consequences of not following the SHOULD. Does the work group expect to support scenarios 2 and/or 3? If the answer is no, then I think the draft needs a scope or applicability statement to that fact. Otherwise, I am afraid implementors will approach this with incorrect interoperability expectations. You mentioned that there were practical engineering considerations preventing MUST level requirements for scenarios 2 and 3--do those considerations still apply if we limit the discussion to XML-based editors and processors that implement this draft.? If the answer is yes to 2 or 3, then I think the draft needs the stronger normative language, or non-normative guidance I mention above. On Aug 18, 2009, at 7:54 PM, Ned Freed wrote: On Aug 16, 2009, at 11:01 AM, Ned Freed wrote: [...] it would be helpful to have a sentence or two somewhere (maybe in the intro) to explicitly say so. My confusion might be around the meaning of the term client in this context. No, I think your confusion is that you read a lot more into the text than it actually says. There's a pretty big difference between no semantic understanding whatsoever and an incomplete semantic understanding'. I think the confusion is that the text says very little one way or the other. You have assumptions in mind about the semantic knowledge of an editor that are not explicitly stated. On the contrary, we have made _no_ assumptions whatsoever about it. And the draft reflects that. You, OTOH, appear to have approached this with a set of assumptions I for one frankly don't comprehend in your head. Perhaps - and this is just speculation on my part - this is because, as you have stated, you haven't done much work using XML tools. If so, then you need to understand that this document assumes considerable familiarity with XML and the tools used to manipulate it. And given the topic of the document this is a perfectly reasonable assumption to make IMO. A reader that was not privy to the process of creating this draft may come with a
Re: [Gen-art] draft-ietf-ntp-autokey-06.txt
I cleared. At 07:39 AM 8/20/2009, Ralph Droms wrote: Russ - I've added the RFC Editor comments. I expect we'll need another rev before publication, which should incorporate those comments. - Ralph On Aug 19, 2009, at 4:58 PM 8/19/09, Russ Housley wrote: Ralph: Russ - would you be willing to clear your DISCUSS and capture Joel's new issues in a COMMENT? - Ralph On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote: This document is nearly ready for publication as an Informational RFC. While my comments have been resolved, some minor issues apparently crept in during the editing process.. These are small enough that they can probably be dealt with in notes to the RFC Editor if no other issues are found. However, they are sufficiently ambiguous that they should not be left for rediscovery by the RFC Editor. Two individual sentences became truncated (Section 7, first paragraph was created. = was. and section 8, third bullet the server.=the.) Can you post an RFC Editor note this one? We have experience that shows RFC Editor notes are read, but comments are almost always ignored. Section 8 on the Sign exchange previously said that the information was signed using the private key. Now it says that it is signed using the public key. As I understand it, the signature is generated with the private key to be verified with the public key. I am not sure what the right words in the paragraph would be. (I was happy with private key before since the signer used his own private key.) Again, I'd like to see an RFC Editor note for this one? In the paragraph on the extension field parser length calculation, with the text beginning: If greater than 22 an extension field is present. If the length is .. has two minor issues. I believe it would be clearer if it said If the remaining length is greater than 22 an extension field is present. If the remaining length is ... I'm fine with a comment for this one. Russ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 20 Aug 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-090820-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Assignments for August 27, 2009 Telechat
Hi all, Here's the link to the summary of assignments for the Aug 27, 2009 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-090827.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 27 Aug 2009 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
