Hi, Terry. Thanks for the swift reply. Looks like all is well with most of he comments. I guess the main consclusion would be that you maybe need to put in a bit more explanation of the context to which make-before-break applies as per your explanation to me below. Excised the various 'acked' bits.. couple more comments in line. Regards, Elwyn On Wed, 2012-12-19 at 16:53 -0800, Terry Manderson wrote: > Hi Elwyn, > > Thanks for your review. While Sriram holds the pen at this stage, I will > reply here. > > > On 20/12/12 6:17 AM, "Elwyn Davies" wrote: > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > > > > > Summary: > > This doucment is almost ready for publication. There are a couple of > > very minor issues (glorified nits really) and a number of real nits. > > > > Major issues: > > > > Minor issues: > > > > s2.1, para 1: > >> assumed to be intended (i.e., considered > >> unsuspicious) unless proven otherwise by the existence of a valid > >> RPKI object. > > It is possible that I don't understand the problem, but this appears to > > be trying to prove a negative by the existence of something. What RPKI > > object would have to exist to make the route suspicious? > > Essentially a valid RPKI ROA object would need to exist that proves a route > is suspicious. Because the RPKI+ROA is a "bolt on after the fact" security > effort, you can do no more. Simply routing exists now, the RPKI would be > deployed in the future. So any route that is seen must be considered > intended unless proven otherwise. I see now.. perhaps you could add something like: ... valid RPKI object that explicitly invalidates the route (see Section 7 for examples). > > > > > s6.2: Can the make-before-break principle be applied to the resource > > certificate for Org B? Presumably this would mean overlapping existence > > of resource certs for Org A and Org B so that the ROA add can occur > > before the revoke. Is this a problem? > > > > The preference, I believe (and my co-authors can correct me) is that two > different resource certificates (unless one in subordinate to the other) > should never exist. > > This problem is an open issue in SIDR related to the grandfathering topic. > So for now the usecase should be that overlap cannot occur. Do you think this needs explicit mention? > > > Nits/editorial comments: > > > > Abstract/a1: The opening sentence is a bit obscure: > > > >> This document provides use cases, directions, and interpretations for > >> organizations and relying parties when creating or encountering RPKI > >> object scenarios in the public RPKI. All of the above are discussed > >> here in relation to the Internet routing system. > >> > > Maybe better: > > This document describes a number of use cases together with directions and > > interpretations for > > organizations and relying parties when creating or encountering RPKI > > object scenarios in the public RPKI. All of the above are discussed > > here in relation to the Internet routing system. > > Nicer, Thanks. :-) > > > > s1.3, last para: Possibly need to clarify *what* is originated? s/that > > is originated/for which a route is advertised/ > > Does > > Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a route is > originated to two or more Autonomous Systems. > > work for you? Maybe 'through two or more' but basically 'yes, thanks'. > > > > > s2.1, para 1: s/stance/operational policy/? > > > nice :-) > > > > s3.5: Might be useful to refer to the currently in progress > > draft-ietf-idr-as0 regarding AS0. > > I'm easy. Sriram, Russ? > > > > > s6.x: Given the 'make-before-break' principle, would it be sensible to > > describe the add before the revoke in each case? > > ahh.. I think we have a disconnect. make before break is considered in the > routing sense that a route is considered o.k. (UNKNOWN) unless proven > otherwise, this means you can remove ALL RPKI object for a route, and it > will still exist happily until a new and conflicting RPKI ROA is created.. > And we are working to that. Not necessarily making a new valid object before > breaking the old valid object. That would then imply ownership of a prefix > can then be in two places at the same time. And like the transfer of title > for a house, overlap tends to be considered a bad thing. (co-authors, chime > in here!) > See initial comment.. this is a useful explanation and some words to this effect would avoid others with equally bad understanding of the RPKI scenario making the same mistake. Regards, Elwyn > Sriram, can you make the required changes as necessary to the holding > pattern copy assuming we all agree? > > Cheers > Terry