Subject: Re: [sidr] Working Group Last Call for draft-ietf-sidr-repos-struct-03.txt

From: Rob Austein <[email-masked]>
Date: Mon, 23 Nov 2009 17:07:39 -0500

I have read this document (and implemented something that I think is
compatible with it) and support it going forward.

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 25 Nov 2009 15:07:01 -0500 (EST)

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