Also note that sending to draft-ietf-ltans-xmlers.all@xxxxxxxxxxxxxx resulted in a "user unknown" delivery failure report for tobias.gondrom@xxxxxxxxxxxx . That's not the address listed for him in the draft, either the address in the draft forwards to a dead address, or the tools alias for the draft is incorrect. In either case, something is broken somewhere. Thanks! Ben. 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 <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-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? > > -- general: I'd like to see at least one complete example. > > -- 3.1.2, 1st paragraph: "exact time (obtained from trusted time source) of Time-Stamping." > > How exact? > > -- 3.1.2, paragraph before example: "The Attribute type must be used" > > Normative? > > -- 3.1.3, 1st paragraph: > > Is that a normative SHOULD? Can you offer examples or an explanation of when thus might not be possible? > > -- 3.1.3, 2nd paragraph: "Following values SHOULD be used as identifiers for the Type attribute" > > Just should? Don't you mean to say the type MUST be something in the IANA registry? > > -- 4.1, last paragraph "must be valid at the present time" > > Normative? > > -- 4.1.1, general: > > (comments also apply to the Canonicalization method URL) > > What does the URI represent? Does that point to the actual definition of the algorithm? Can I make up arbitrary ones? Is there a registry? What schemes are allowed and/or reasonable? > > Are there any required-to-support algorithms? > > -- 4.1.1, 2nd paragraph: "those must be used as defined in [RFC3275] and [RFC4051]" > > Normative? > > -- 4.1.1, last paragraph: > > What do you mean by equal? The same algorithm? One of equal strength? How do you determine relative strength? > > -- 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? > > -- 7, 1st paragraph: "have to be considered by verifying components" > > Normative? > > -- 7, 4th paragraph: > > should "recommended" and "must" be normative? > > 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? > > -- 7, last paragraph: "Time-Stamps should have the same or higher quality" > > Normative? > > > > > > > > > -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. > > -- General: The pagination and vertical spacing seem strange. > > -- 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. > > -- 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? > > -- 1.1, first paragraph: "Such data and non-repudiable proof of existence must endure for long periods of time, even when information to prove data existence and integrity weakens or ceases to exist." > > That seems to say the proof must continue to exist past it's own existence. I assume that is not the intent. > > -- "digital signatures defined in [RFC5652] for example do not provide absolute reliability" > > Missing commas around "for example" > > -- 2nd paragraph: "All integrity and authenticity related techniques used today suffer from the same problem of time related reliability degradation including techniques for Time-Stamping, which are generally recognized as data existence and integrity proof mechanisms." > > I find it hard to parse that sentence. > > -- "Some of the problems might not even be technically related like a decomposing Time-Stamping authority." > > Technically related to what? Do you mean to say "might not even be of a technical nature..."? Also, I'm not sure I understand "decomposing" in this context. > > -- 3rd paragraph: " introduced for example by" > > Missing commas > > -- "long term signature syntaxes like [RFC5126]" > > Missing words? (i.e. .... syntaxes like those defined in...) > > -- "Long term signature syntaxes and processing rules address mostly the long term endurance of digital signatures..." > > Seems self-redundant > > -- 4th paragraph: > > Please expand XMLERS on first mention. Also, this is not consistent with the acronym used in the abstract. > > -- 6th paragraph: "support for example import" > > commas > > -- section 1.2, first paragraph > > Multiple missing articles > > -- 3rd paragraph: "Evidence Record maintains a close relationship to Time-Stamping techniques" > > I doubt it "maintains" anything. It think you mean to say "is closely related to..." > > -- 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. > > -- 1.2, 5th paragraph: "collected evidence data must be monitored and renewed before such events occur" > > monitored by whom? > > -- 1.3, 2nd paragraph: > > "multitude" connotes a large number. I think you just mean "set". Also, why the parentheses? > > -- 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? > > Also, the draft needs a definition for "canonical form" > > -- 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. > > -- section 2, first paragraph: "unit of data, which is to be used" > > I think you mean "unit of data that is to be used" > > -- section 2, 1st paragraph: "Time-Stamp Tokens obtained from the Time-Stamping Authority (TSA)" > > Obtained by whom? > > -- section 2, 2nd paragraph "number of reasons" > > More than one example would be nice. > > -- 2.1, 1st paragraph: "CRLs or OCSP" > > Expand on first mention > > -- 2.1, paragraph made up of "<CanonicalizationMethod> is a required element that specifies the canonicalization algorithm applied over the archive data in case of XML data objects, <ArchiveTimeStampSequence> or <TimeStamp> element prior to performing digest value calculations." > > Sentence does not make sense. Are therre missing words? > > -- 2.2, 3rd paragraph after numbered list: "the application not defined in this draft" > > I'm not sure what you mean. Is there a specific application defined elsewhere, or are you just trying to say it is out of scope? > > -- 2.2, 2nd to last paragraph: > > I'm not sure what this is an example of. It just looks like a continuation of the section text. > > -- "provide also evidence" > > also provide evidence > > -- 3.1.1, third to last paragraph "When a single Time-Stamp is obtained for a set of archive objects, a hash tree MUST be constructed to generate a single hash value to bind all archive objects from that group and then a reduced hash tree MUST be extracted from the hash tree for each archive object respectively (see Section 3.2.1)." > > Meaning obscured by passive voice. Who or what MUST generate and/or extract hash trees? > > -- 3.1.1, 2nd to last paragraph: "For example, the text value" > > Is this a second example, or a continuation of the previous one? > > -- 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? > > -- 3.1.2, paragraph before example: "in particular, e.g." > > "in particular" or "e.g", not both. > > -- 3.2.1, 2nd paragraph: "This is the case:" > > Confusing. Do you mean to say "The values are unequal when either of the following are true:"? > > -- 3.2.1, 1st bullet list entry "is having" > > has > > -- 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? > > -- "The leaves represent the digest values of the archive objects:" > > It looks like you mean this sentence to introduce the following list, but it doesn't seem to do so. > > -- List entry 3: Need to define N. Is this the order of the tree? > > -- 3.3, list item 2: "If an additional proof is necessary that the Archive Time-Stamp relates to a data object group (e.g. a document and all its digital signatures), it can also be verified that only the hash values of the given data objects are in the first hash value list." > > I don't understand this sentence > > -- 3.3, numbered list: > > Is there a need to distinguish between kinds of negative results? > > -- 4.1.2, last paragraph: "it is recommended to use c14n- 20010315." > > Reference? > > -- 4.2 "Archive Time-Stamps have to be renewed " > > by whom? > > -- section 7, "Secure Algorithms", etc > > Should these be numbered subsections? > > -- 7, 1st paragraph: "have to be considered by verifying components" > > They need to be considered by people, not components, right? Also, is this a verification issue or a generation issue? > > -- 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) > > -- 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. > > > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf