On Sep 8, 2011, at 10:05 AM, Warren Kumari wrote:

> 
> On Sep 8, 2011, at 5:59 AM, Randy Bush wrote:
> 
>> hi terry,
>> 
>>> It strikes me that this is the first time you have read this draft despite
>>> the several calls to the WG to do so.
>> 
>> this version, yes.  read a year or so ago, and it was structurally so
>> off my map that i did not do more than scan.
>> 
>>> That's not bad exactly... just unexpected.
>> 
>> in one sense, it's what wglc is all about.  and this is just not high on
>> my radar.
>> 
>>> I'm less interested in your abrupt critique and certainly much more
>>> interested in constructive reviews of which you started below and then
>>> gave up..
>> 
>> apologies, but the multiple hours needed would not come up on my
>> priority stack for a long while.  i would hope the authors would know
>> how to be more precise.
>> 
>> as i said privately to the chairs
>> 
>>   ... that docco is *really* sloppy.  i am kinda wondering why no one
>>   else has raised the rather amazing editorial issues.  no one
>>   bothered to read it?
> 
> 
> I'll happily admit to not having responded to the WGLC because I didn't read the document…
> 
> I have placed it on my ToRead pile, but it will take some time to propagate up the stack…


Alrighty, I took an initial pass at this, but believe that it needs:
A: a second, much deeper reading and 
B: some work to make it more ledgible.

The base content seems good (and I support it moving forward), but I found the language and wording to be difficult to follow and feel that it should be cleaned up --  it feels a bit like there were multiple editors?


Some initial notes:
Comments:

1: 
I found the Abstract to be basically unparsable. Sooo many words, so little punctuation.
Suggest removing "in relation to the Internet routing system." or liberally sprinkling with  commas.


2: 
Throughout the paper you use the term "as intended" (e.g:
"It wishes to announce the /24 prefix from ASN 64496 such that relying parties interpret the route as intended.")

I found this tricky to parse - suggest explaining what you mean by "as intended" (or changing that to "as a valid route" or something).

3: 
Suggest sorting / grouping the Definitions (and probably pointing at existing definitions for things like AS) and cleaning up the definitions a bit. For example, 65534 is a valid ASN, but is not "officially registered".


4: 
Section 2.1: The first sentence is very hard to parse.
How about: 
"It is important that replying parties (RP) or relying party routing software adopt a 'make before break' stance." instead?
Also, it is really necessary to specify "or relying party routing software"? It's unlikely that the parties themselves would do anything, it's understood (I think) that it's the software working on their behalf.

Section 2.1:  Last sentence, first paragraph.
"For
   all of the cases in this document it is assumed that RPKI objects
   validate (or otherwise) in accordance with [I-D.ietf-sidr-res-certs],
   [I-D.ietf-sidr-arch], [I-D.ietf-sidr-roa-validation] unless otherwise
   stated.
"
The "(or otherwise)" is confusing - actually, to be honest I don't really understand what you were trying to say here.


Section 5.1:
Title: "Parent does not do RPKI".
Suggest rewording this -- not sure how, but the "do" seems vague.


Section 6:
The first sentence is confusing (to me). 
My suggestion (only slightly better):
Based on the previous section it should be easy to deduce what new ROAs need to be created and what existing ones need to be maintained (or revoked).

Nits:
Section 2.1:
O: it should be recognised that a prefix holder
P: it should be recognized that a prefix holder
C: s/recognised/recognized/.


Section 3.10 and also in Section 3.11: 
O: It is currently not possible for an upstream to make a valid aggregate annoucement of indepentant prefixes.  
P: It is currently not possible for an upstream to make a valid aggregate announcement of independent prefixes.  
C: s/annoucement/announcement/, s/indepentant/independent/


3.11:
O: following resources which were acquired
P: following resources that were acquired
C: restrictive clause.


Section 5.1:
O: "An organization (Org A with ASN 64511) is multi-homed has been assigned the prefix"
C: "An organization that..." or "is multi-homed and has..."


Section 5.2:
O: Org B with ASN 64511 and and Org C 
P: Org B with ASN 64511 and Org C 
C: You have an 'and' and an 'and', making an 'and and' and all you need is an 'and' :-)


Section 6.3: 
O: Organization A may optionally provide ROA coverage for Organisation B
P: Organization A may optionally provide ROA coverage for Organization B
C: s/Organisation/Organization/ -- consistency.

Section 7.1:
O: The use cases described here can be potentailly used as test cases
P: The use cases described here can be potentially used as test cases
C: s/potentailly/potentially/

Section 7.1.1:
O: This is a straight forward prefix-origin validation use case;
P: This is a straightforward prefix-origin validation use case;
or
P: This is the standard prefix-origin validation use case;
or something!

Section 7.1.6:
O: and it turns out that there exit ROAs for more specifics which, if combined, 
P: and it turns out that there exist ROAs for more specifics that, if combined, 
C: s/exit/exist/
C: s/which/that/ - restrictive / non-restrictive rule.

Section 7.1.11: 
O: In fact, the update in consideration would have received an Invalid staus 
P: In fact, the update in consideration would have received an Invalid status 
C: s/staus/status/



----

I'll try reread before WGLC cutoff.

W




> 
> W
> 
>> i admit that i have not read it for a year or
>>   so.
>> 
>>   please view my comments as just that.  i do not formally object to
>>   the doc being passed to the iesg.  imiho, they probably deserve
>>   it. :)
>> 
>> randy
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>