Hi Elwyn, I have carefully read all the comments in this thread. Thank you for your review and comments -- very helpful. I have a good understanding of all the changes I need to make. I will spin a new version by Wednesday (12/26) evening or Thursday a.m. Will run it by Terry and Russ first and then post it here in this thread as an attachment.
Happy Holidays. Sriram ________________________________________ From: Elwyn Davies [[email protected]] Sent: Friday, December 21, 2012 7:06 AM To: Terry Manderson Cc: General Area Review Team; [email protected] Subject: Re: Gen-art LC/Telechat review of draft-ietf-sidr-usecases-05.txt Hi, Terry. That's all fine by me. Have a great Christmas! Elwyn On Thu, 2012-12-20 at 17:02 -0800, Terry Manderson wrote: > On 20/12/12 11:23 AM, "Elwyn Davies" <[email protected]> wrote: > > > 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. > > I hear you, I will come back to you after Xmas with some expanded draft text > for s2.1. > > > > > >>> 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). > > That works for me. > > >> > >>> > >>> 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? > > No. I feel it is better to remain silent in the usecases. A requirements > document (should one ever be set as a charter deliverable) would define that > behaviour, which would then be reinforced by the RPKI architecture. > > I personally feel it is better to bis this document should change be needed. > > > >> work for you? > > > > Maybe 'through two or more' but basically 'yes, thanks'. > > Works for me. > > >> > > >>> 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. > > > > Ack. Will run draft text past co-authors and bring back post xmas. > > Terry _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
