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 protected] [[email protected]] on behalf of Christopher Morrow [[email protected]] Sent: Thursday, September 08, 2011 12:48 AM To: [email protected]; [email protected] 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 protected] https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
