Hi Sriram, Terry. The new draft covers almost everything in the review and is fine with one exception.
On ree-reading the draft and Terry's reponse to my original comment about 'make-before-break', I have come to the conclusion that this phrase is possibly confusing. Arguably you actually have a 'break-before-make' policy! So if I (now) understand correctly the following explanation: > > 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!) > the timeline for the transition between one ROA and a new one would be Time BGP FIB Event ROA Event Route Validation status T0 Route R1 recvd (initially?) NotFound T0+ Route R1 installed NotFound T1 ROA1 covering R1 recvd Valid T2 ROA1 revoked NotFound T3 ROA2 recvd Invalid (or Valid) T3+ Route R1 removed (for the Invalid case) So to my mind the treatment of the toutes might be described as 'optimistic acceptance' or 'negative vetting' (as routes are only thrown out if explicit negative evidence is received) but the ROA mechanism/policy is definitely break the old ROA before issuing a new one to avoid having conflicting ones in existence. It may be that: - not using the term 'make-before-break' but rather using Terry's words would avoid 'interpretation'. - explaining that seeing contradictory ROAs in a router is bad news and one should check for revocations - presumably the RPKI infrastructure would prevent a DoS attack here. Best wishes for the New Year, Elwyn On Thu, 2012-12-27 at 16:20 -0500, Sriram, Kotikalapudi wrote: > Hi Elwyn, Terry: > > Please find attached the revised -06 version .txt file and also the rfc-diff > file (-05 vs. -06). > I think I have captured all the comments you two have gone over, > and also included are minor comments from Barry, Stewart, others. > Please let me know if I missed anything. > > Elwyn: Please let me know if need to upload a -06 version to the the IETF > submissions page > at some pioint. Thanks again for all your commnets and help. > > Sriram > > ________________________________________ > From: Sriram, Kotikalapudi [[email protected]] > Sent: Wednesday, December 26, 2012 12:17 AM > To: Elwyn Davies; Terry Manderson > Cc: General Area Review Team; [email protected] > Subject: RE: Gen-art LC/Telechat review of draft-ietf-sidr-usecases-05.txt > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
