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 On 22/12/2011, at 8:46 AM, Murphy, Sandra wrote: > 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: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Christopher > Morrow [christopher.mor...@gmail.com] > Sent: Thursday, September 08, 2011 12:48 AM > To: sidr@ietf.org; sidr-cha...@ietf.org > 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 g...@apnic.net _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
