Top post only.. I agree with Sam's comments here.
Additionally, and not surprisingly, I'd also very much like to see my earlier comments on this document addressed before it warrants cycles for another full review on my part. Thanks, -danny On Nov 25, 2009, at 1:07 PM, Samuel Weiler wrote: > As best I can tell, the technical substance of sidr-repos-struct-03 is in > fine shape. That said, I found the document difficult to review, largely due > to the style of its writing. While I recognize that this may be merely a > matter of stylistic preference, I find the writing unnecessarily verbose and > unapproachable. > > I notice that the only two other WGLC reviews of this doc came from native > English speakers, one of whom has been deeply involved in the work for years. > I think the doc has not gotten adequate review, I think that is in large > part because of the writing. > > I think this document would benefit greatly from an editorial pass, probably > from a different editor. Assuming someone can be found to do that, I support > delaying the publication in the interest of producing a more readable > document. > > And, as I noted in my WGLC review of the architecture draft, I have some > reservations about pushing these docs out without having the validation > algorithm nailed down (including the handling of incremental deployment). In > the case of this document, noting that it has normative references to the > architecture and manifests docs, which are more likely to see changes from > changing the validation scheme, I don't see any harm in sending it forward. > > > Specific suggestions > > Danny McPherson's comments on ths draft from 3 December 2008 don't appear to > have been incorporated nor responded to on the list. (e.g. "complete set" is > still a strange phrasing, and the spelling nits haven't been fixed) > > Rsync is not mentioned in the intro. Instead of just referring to > "publication points", adding the concreteness of "rsync" at that stage would > help make the doc clearer. > > Section 1: "A Resource Certificate describes an action by an Issuer that > binds a list of IP address blocks and AS numbers to the Subject of a > certificate, identified by the unique association of the Subject's private > key with the public key contained in the Resource Certificate." "describes > an action"? Surely there's a better way to say that. > > I'm not sure that Section 2.2 paragraph on naming certificates is consistent > with section 4's guidance on persistent naming. Which may be more about how > hard it was to understand section 2.2 than about any real differences. > > > Nits > > The rsync reference appears to be truncated. > > Spelling: > s/performss/performs/ > s/Becuase/Because/ > s/Whn/When/ > s/traveral/traversal/ > (and there are surely others, including some that Danny pointed out) > > -- Sam > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
