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

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 21 Dec 2011 21:46:14 +0000

Review and comment in the last call period was rather limited.  The authors produced a revised version and not all commenters have responded to the revised version to say they are satisfied.

I reviewed the document to see if comments were addressed.  I have comments - see below.  

I have communicated the comments to the authors and they are producing a revised draft.

Note that some of these comments are due to errors in the facts of the use cases.  Certainly just typos, but in the use cases themselves, so in the very subject of the draft.  Many of these have been in the draft for a while - so there is reason to believe that the wg has not been paying attention.

(One process question to the authors - I think it is likely that we will be asked questions as to why the examples do not use the documentation blocks as supplied by rfc5737.  This has come up before and mentioning the reasoning in the draft might ease process.)

--Sandy, speaking as wg chair

I believe the use case in section 3.7 is incorrect.  The example is attempting to restrict the 10.1.128.0/17
prefix from being announced, and uses an AS0 ROA to do that.  But due to the max length in the ROA for 10.1.0.0/16, the 10.1.128.0/17 would already be considered invalid.  OK, that's not actually an error, it is just an odd example - the AS0 ROA is not needed.  Would it be difficult to construct an example where the AS0 ROA was necessary in order to prevent advertisement?

6.2 and 6.3 talk about 10.1.0.0/ 8.  By my understanding, 10.1.0.0/8 is the same as 10.0.0.0/8 - bits beyond the mask have no effect.

The following from 7.2.* are all based on my understanding of the "/22" type notation and what it means to be a covering ROA.

7.2.3 says that 10.1.0.0/22 is a parent of 10.1.4.0/24.  That is not true.

7.2.4 says that a route 10.1.4.0/24 is valid when a ROA for 10.1.0.0/22 with a matching AS exists.  Same problem - I don't think the ROA covers the route.

7.2.5 says a route 10.1.4.0/24 is Unknown if the only covering ROA is 10.1.0.0/22 and it expires.  Same problem.

7.2.6 seems to get it right.  (Parent is 10.1.4.0/22, which *DOES* cover 10.1.4.0/24.)

7.2.7 says that 10.1.0.0/22 is a parent of 10.1.4.0.  Same problem.

7.2.8 says that the route to 10.1.4.0/24 is OK when a covering ROA expires because there is a ROA for 10.1.0.0/22.  Same problem.

The problem is repeated often and no one has complained about this.  And it was the same way in the previous version, so this has been around for awhile.

My other source of complaints is the definitions section.  English Nazi alert, skip rest of message if such bores you.

Why do we need definitions of aggregate, covering aggregate, and covering prefix?  I do not see a significant source of difference between the text of definitions - although I also find the text for the definitions rather odd, see below.

The definition of "specific prefix" sounds like "more specific prefix" to me.

There are many terms used in the document that are undefined.  "less specific", "more specific", subprefix, "covering ROA".  There's an equivalence in the use of allocation and prefix, so for example parent is defined as "an allocation from which the subject prefix is a child" and child is defined as "a Sub-allocation that has resulted from an Allocation" (their capitalization), without ever saying that allocations are a set of prefixes.

The wording of the definitions is a bit odd:

   Specific route - A route that has a longer prefix mask length in the
   presence of another route with a smaller mask length.

   Aggregate route - A route that has a shorter prefix mask length in
   the presence of a specific route.

   Covering Aggregate - A route that has a shorter prefix mask length
   relative to a route in consideration.

What does "in the presence of" mean?  I imagine it means something like "in comparison to".

>From this definition, 12.0.0.0/8 is an aggregate of 192.7.0.0/16 - the definition is given in terms of only the mask length without mentioning the necessary match in the common mask bits.

In the definition of aggregate route, does "specific route" have the meaning as defined directly above?  In which case, what is the "another route" whose presence determines the specific route?  Given that the definition of specific route is itself circular, I suspect that these two definitions are circular - specific means longer prefix than the aggregate, aggregate means a shorter prefix than the specific.

But that means that "aggregate route" is a relation between routes, not an absolute.  But then why do we need both "aggregate route" and "covering aggregate"?  Does the difference lie in the use of "relative to a route in consideration" instead of "in the presence of a specific route"?

The terms used in the text are used as I understand them, so likely those who understand these terms will ignore the definitions section.  But those who do not already understand the terms might be really confused by these definitions.  IMHO.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Christopher Morrow [[email-masked]]
Sent: Thursday, September 08, 2011 12:48 AM
To: [email-masked]; [email-masked]
Subject: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt

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>
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Dec 2011 17:30:59 -0500

>    Specific route - A route that has a longer prefix mask length in
>    the presence of another route with a smaller mask length.
> 

jgs worked hard on this in pfx-validate in order to get a nice set of
syntax and semantics.  might be wise to steal.

randy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 22 Dec 2011 11:56:26 +1100

And why not use the documentation prefix(es) and documentation AS(es) in this draft. rather than 10/8 etc. That's what they are there for.

Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Dec 2011 22:32:07 -0500

> And why not use the documentation prefix(es) and documentation AS(es)
> in this draft. rather than 10/8 etc. That's what they are there for.

the draft in $subject uses 10/8.  i think sandy was pointing out that
the ips and asns in rfc 5737 might be more appropriate.  is the latter
what you mean by "documentation xxx?"

so what is it you are suggesting?  i suspect you are agreeing with sandy
but can not parse.  my error, likely, too much good theater and food.

randy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 22 Dec 2011 14:37:48 +1100

> but can not parse.  my error, likely, too much good theater and food.

I think the set is RFC5737, RFC3849, and RFC5398.

That is what I am suggesting.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Dec 2011 23:09:59 -0500

> That is what I am suggesting.

thanks.  seems great to me, for the little that's worth.

i should not try to think at this hour, especially working while
jabbering with a generous friend being remote hands in ashburn colo.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 21 Dec 2011 21:59:57 -0800

The draft uses RFC1918 address space as there are only three(3) IPv4 blocks
made available by RFC 5737 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24
(TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3). Given that the key part of
the use cases really revolves around the prefix length and MaxLen - the bits
that make up the address part are meaningless.

So if we were to construct the use cases around /24s, and then
sub-allocate/assign /25's and /26's in the document, I posit the document
would be less meaningful to a reader. (I don't see too many cases of /26's
in BGP, yes from time to time, but not in numbers and not routinely)

I feel more comfortable saying that using 10/8 provides deeper and more
meaningful examples.

As for the ASNs, I originally started writing the draft using ASNs from
RFC5398, however a few ASNs from outside the range 64496 - 64511 crept in.
They can be cleaned up easily enough without having to rejig the document.

There are no use cases using IPv6 and its documentation prefix from RFC3849.
A quick discussion between authors wayback suggested a KISS principle.

Cheers
Terry

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 22 Dec 2011 15:13:43 +0000

I agree that using the standard documentation prefixes would be best, but I was actually pointing to the previous discussion of the use of documentation prefixes.

On 8 Sep, Randy (http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html) said:

>look at rfc 5737 IPv4 Address Blocks Reserved for Documentation

and on 8 Sep, Terry (http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html) replied:

>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 was suggesting that the authors make the argument that the documentation prefixes are insufficient for this draft's purpose *in the draft* to avoid making the same argument as the document progresses.  

--Sandy

________________________________________
From: Geoff Huston [[email-masked]]
Sent: Wednesday, December 21, 2011 10:37 PM
To: Randy Bush
Cc: sidr wg; Murphy, Sandra
Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt

Geoff

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Dec 2011 10:15:37 -0500

> I was suggesting that the authors make the argument that the
> documentation prefixes are insufficient for this draft's purpose *in
> the draft* to avoid making the same argument as the document
> progresses.

<doh>!

---

From: Terry Manderson <[email-masked]>
Date: Thu, 22 Dec 2011 15:41:42 -0800

> 
> and on 8 Sep, Terry
> (http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html) replied:
> 
> I was suggesting that the authors make the argument that the documentation
> prefixes are insufficient for this draft's purpose *in the draft* to avoid
> making the same argument as the document progresses.
> 

And that seems like a perfectly reasonable thing to do :-)

Cheers
Terry