Subject: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Sep 2011 00:48:05 -0400

Hello work-group-readers,
The authors did some significant work on this doc, it seems to have
settled into a groove, could we get some input on where this stands?
This is a WGLC for the document which should end: 09/22/2011 (Sept 22,
2011 for those with the other flavor of clocks).

document link: <http://tools.ietf.org/html/draft-ietf-sidr-usecases-02>

The abstract:
"This document provides use cases, directions, and interpretations for
   organizations and relying parties when creating or encountering RPKI
   object scenarios in the public RPKI in relation to the Internet
   routing system."

Please have a final read/comment and let's move things along.

Thanks!
-Chris
<friendly neighborhood co-chair>

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Sep 2011 08:42:36 +0200

i do not think this document is at all ready for publication.  someone
with time and energy to clean up the wording needs to spend a half day
with the poor thing.

---

1.2 i believe that redefining AS and ASN are ill-advised.  just refer
elsewhere.  we readlly do not want to go there.  e.g. there are a lot of
ASs which are not under a single administrative control.

if you insist on defining it, i would probably s/route/as-path/

Aggregate Route makes an assumption that 'more general' and 'specific'
are well definined.  maybe try something like shorter and longer
netmask, or greater or smaller prefix mask length.

'Covering Aggregate' uses 'cover' in its definition, which makes it
pretty useless.

'Multi-homed prefix' is 'originated via'.  is it transited via/through
or originated by/from?

...

   3.1.  Single Announcement

   An organization (Org A with ASN 64496) has been allocated the prefix
   192.168.2.0/24.  It wishes to announce the /24 prefix from ASN 64496
   such that relying parties interpret the route as intended.

look at rfc 5737 IPv4 Address Blocks Reserved for Documentation

i could go on and on.  essentially this document is sloppy and needs to
be seriously cleaned up.

randy

---

From: Terry Manderson <[email-masked]>
Date: Thu, 8 Sep 2011 02:49:02 -0700

Hi Randy,

It strikes me that this is the first time you have read this draft despite
the several calls to the WG to do so. That's not bad exactly... just
unexpected.

> with time and energy to clean up the wording needs to spend a half day

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..

>From time to time authors choose to use non rfc5737 address blocks as the
examples can't often be adequately described or remain uniform with the
documentation prefixes.

> i could go on and on.

Please do.. send to me off list if you choose.

Cheers
Terry

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Sep 2011 11:59:02 +0200

hi terry,

> 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.

> 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 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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 8 Sep 2011 10:05:22 -0400

On Sep 8, 2011, at 5:59 AM, Randy Bush wrote:

>    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…

W

>  i admit that i have not read it for a year or
>    so.
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Sep 2011 10:42:58 -0400 (Eastern Daylight Time)

But in your presentation at the wg meeting you noted that few in the room 
had read it, with a wry comment that a last call might be necessary to 
make that happen.  (I agree that it seems to be the modus operandi, here 
and IETF wide.)  So it looks to me like your prediction came through.

This is an individual comment.

--Sandy, regular ol' member

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 8 Sep 2011 11:06:15 -0400

Steve Kent had reviewed and extensively commented on the document about a year ago. 
His comments were all incorporated and substantially benefited the document.
Thanks once again to Steve.  

In addition, as I recall we had earlier received comments from Danny, Curtis and Sam.

But, yes, we need more readers.
Thanks to Warren and any others who have it in their stack and plan to get to it
before the WGLC deadline! All your reviews and comments will be much appreciated.

Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sandra Murphy [[email-masked]]
Sent: Thursday, September 08, 2011 10:42 AM
To: Terry Manderson
Cc: Christopher Morrow; [email-masked]; [email-masked]
Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt

---

From: "t.petch" <[email-masked]>
Date: Thu, 8 Sep 2011 18:12:08 +0200

---- Original Message -----
From: "Sandra Murphy" <[email-masked]>
To: "Terry Manderson" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, September 08, 2011 4:42 PM

> and IETF wide.)  So it looks to me like your prediction came through.

How IETF wide it is depends on how many I-Ds the WG has, and perhaps how that
compares to how many it should have.  Some WGs work on one (or two or three)
I-Ds
and then everyone reads everything.  When the WG has 25, then yes, I am
behind the curve and might even wait until IETF LC to raise issues.

And particularly for SIDR, I think that there are more than are needed, that
bits have been tacked on as the work has progressed, making it hard to
understand the (lack of an?) overall plan, even for one who reads every
e-mail to the SIDR list, to find where something is defined, or what to
read to get an understanding of a particular aspect of sidr.

Perhaps these comments are not addressed to you as an individual.

Tom Petch

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Sep 2011 16:44:09 -0400

> 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