Also note that sending to [email protected] resulted in a "user unknown" delivery failure report for [email protected] . 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
