Re: [Gen-art] Gen-art LC/Telechat review of draft-ietf-sidr-usecases-05.txt

["Sriram, Kotikalapudi" <[e-mail]>]

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 [[e-mail]]
Sent: Friday, December 21, 2012 7:06 AM
To: Terry Manderson
Cc: General Area Review Team; [e-mail]
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" <[e-mail]> 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