Telechat Review of draft-ietf-sidr-usecases-05
review-ietf-sidr-usecases-05-genart-telechat-davies-2012-12-20-00

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" <elwynd at dial.pipex.com> 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