Document: draft-ietf-ltans-xmlers-11 Reviewer: Ben Campbell Review Date: 2010-02-01 IESG Telechat date: 2010-02-03 Summary: This draft is mostly ready for publication as a proposed standard. However, I still have some minor comments and editorial comments that were not addressed from my last-call review of version 08. Note: I included the unaddressed and partially addressed items from my last-call review below. I removed the parts that I believe to be addressed. I recognize that the authors may rightly choose to ignore some or all of my comments, but I saw no response one way or another on most of the remaining comments, except when noted otherwise below. Thanks! Ben. ______________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art On Jan 6, 2011, at 5:32 PM, Ben Campbell wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments you > > may receive. > > > > Document: draft-ietf-ltans-xmlers-08 > > Reviewer: Ben Campbell > > Review Date: 11-01-06 > > IETF LC End Date: 11-01-11 > > > > Summary: > > > > This draft is on the right track for proposed standard, but I think it > > needs more editing prior to publication. > > > > Note that I have not attempted to verify the XML schema or examples. These > > should be mechanically verified prior to publication, if they have not > > already been done so. > > > > -Major issues: > > > > None > > > > -Minor issues: > > > > -- General: I'd like to see some more architectural background. Who are > > the actors? What are their roles? You mention the time stamp authorities, > > but not much else. Who are the verifiers? How to Certificate Authorities > > fit in? I don't see anything to address this specifically > > > > -- general: I'd like to see at least one complete example. I don't see anything to address this > > > > -- 3.1.2, 1st paragraph: "exact time (obtained from trusted time source) > > of Time-Stamping." > > > > How exact? I don't see anything to address this. You mention a "trusted time source", so I guess that covers part of it--but how much precision is needed? Do things break if you are off a few seconds? Minutes? Hours? Days? etc. [...] > > > > -- 3.1.3, 1st paragraph: > > > > Is that a normative SHOULD? Can you offer examples or an explanation of > > when thus might not be possible? Fixed case, but I don't see any further explanation [...] > > > > -- 4.1.1, last paragraph: > > > > What do you mean by equal? The same algorithm? One of equal strength? How > > do you determine relative strength? "Equal" part addressed. No change to address the relative strength question. > > > > -- 4.2.1, last paragraph: "The new ATS and its hash tree MUST use the same > > digest algorithm as the preceding one" > > > > Does this imply they can't change to a new algorithm? What if an algorithm > > becomes deprecated over time? Not addressed. > > > > -- 7, 1st paragraph: "have to be considered by verifying components" > > > > Normative? Text changed to "verification process", but no response on whether "have to" means MUST. [...] > > > > Why different TSAs? Wouldn't different algorithms be good enough? Are you > > assuming a given TSA is limited to a single algorithm at a time? Not addressed in 10 > > -Nits/editorial comments: > > > > -- General: The draft could really use another editing pass to check for > > punctuation errors and awkward style. There's lots of missing or misused > > commas, missing articles, passive voice that obscures actors, etc. It > > looks like sections were edited in isolation from each other, with > > redundant assertions (how many times do you need to open with "time stamps > > prove the existence of data at a particular time"), inconsistent use of > > acronyms, etc. I will highlight some examples, but they are by no means > > exhaustive. > > > > Much of this could be handled by the RFC editor, but its best to minimize > > their work load, and better to minimize the opportunity for outside > > editors to misconstrue your meaning. > > The author indicated that they had AD guidance to leave this for the RFC editor. [...] > > > > -- Abstract : "This document specifies XML syntax and processing rules for > > creating evidence for long-term non- repudiation of existence of data." > > > > I assume this is for non-repudiation of more than just the "existence" of > > the data, right? Also, please expand the acronyms in the abstract. Fixed, however I note the acronym ERS-XML is inconsistent with the usage in the rest of the document (XMLERS). > > > > -- section 1: "define XML Schema and processing rules for Evidence Record > > Syntax in XML format. The document is related to initial ASN.1 syntax" > > > > Missing articles. Also, since you use an acronym for this later, why not > > declare it here? > > Not fixed in -10. should read "the Evidence Record...". Also, you expanded XML and ASN.1, but still failed to declare the acronym for "Evidence Record Syntax in XML" You do so later in the document, but this is the first actual mention in the body of the draft. [...] > > -- 4th paragraph: > > > > Please expand XMLERS on first mention. Also, this is not consistent with > > the acronym used in the abstract. Expansion added, but still inconsistent with the acronym in the abstract as of version 10. Also see previous comment above about no expansion in 1st paragraph. [...] > > > > -- 1.2, 4th paragraph: "packed into a structure called a "hash tree"" > > > > The text appears to be trying to introduce the concept of a "hash tree", > > but that's already been mentioned several times. Not fixed.(actually paragraph 5, not 4, sorry) Issue is exaggerated by the new text about hash trees in the previous paragraph. > > > > -- 1.2, 5th paragraph: "collected evidence data must be monitored and > > renewed before such events occur" > > > > monitored by whom? Not addressed. [...] > > > > -- 1.3, definition of "canonicalization" > > > > This seems like a definition of "canonicalization rules". Wouldn't > > "canonicalization" refer to the act of following the rules, rather than > > the rules themselves? Not addressed. > > > > Also, the draft needs a definition for "canonical form" Not addressed. > > > > -- section 2, first paragraph: > > > > It would be nice to have definitions of integrity and non-reputability in > > the terminology section. Maybe even "existence" as used in the context. Not addressed [...] > > > > -- 3.1.2, 1st paragraph "Since at the time being there is no standard" > > > > Won't is statement become false when this draft is published as an RFC? Not addressed. [...] > > > > -- 3.2.1, paragraph before 2nd numbered list: "is built from bottom to the > > root." > > > > Leaves to the root, or bottom to top. Also, who builds it? first part fixed, but not the second (unless you count the language "You MUST use...", but that doesn't describe who is actually responsible for doing this) [...] > > > > -- List entry 3: Need to define N. Is this the order of the tree? Partial fix. I think you mean to say something like "grouped according to the order of the tree" [...] > > -- 3.3, numbered list: > > > > Is there a need to distinguish between kinds of negative results? There's some new text here in entry 5, but I don't think the question is answered. You say "exit with a negative result" for multiple possible error conditions. Is it necessary to communicate _why_ there's a negative result, or merely the fact that there was one? [...] > > > > -- section 8, 1st paragraph: "namespace has been registered in the IANA > > XML Registry." > > > > It's already been registered, or are you instrucing IANA to register it? > > (repeats several times in section) Not addressed > > > > -- Appendix A, general: > > > > Why is this in an appendix? It seems central to the draft. lots of readers > > will stop reading when they get to the references sections. > > > > Not addressed