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

[Terry Manderson <[e-mail]>]

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" <[e-mail]> 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:
> s1.4: The document doesn't appear to use any RFC 2119 upper-cased words.
> If this is correct (and it probably is as the document isn't specifying
> requirements) then this para and the RFC2119 ref SHOULd be removed.

Great observation, yes RFC2119 can be removed.

> 
> 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.

> 
> 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.

> 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.

> 
> Abstract/s1 et seq: Need to expand RPKI

Ack.

> 
> ss1.1/1.3:  Although ROA is expanded in s1.1 as part of a document
> title, it would be helpful to include a definition in s1.3 as it is used
> a great deal in the other definitions.

Ack.

> 
> s1.3, para 1: Technically, I don't think you need the author's
> permission as it is an IETF draft, but it is polite.
> 

I'd like to err on the side of politeness :)

> s1.3, several places: s/in consideration/under consideration/

Ack

> 
> 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?

> 
> s2.1, para 1: s/stance/operational policy/?


nice :-)

> 
> s3.3: the two ASNs used in the example are visually easily confused.
> Might be better to use a more obviously different second ASN.

Sriram, are you able to change the text and the table to have one of the
ASNs be AS64511 for both sec 3.2 and 3.3?


> 
> s3.5: Might be useful to refer to the currently in progress
> draft-ietf-idr-as0 regarding AS0.

I'm easy. Sriram, Russ?

> 
> s4: The wording of the first sentence will have to be changed (or just
> removed) for the published RFC.

Ack

> 
> s5.2 and s5.3, first table, fourth line of body: s/YES/Yes/

Ack.

> 
> 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!)

> 
> s7.1: Could the terms Valid, Invalid and Not Found be usefully included
> in the definitions section?

Yes.

> 
> s7.1.6: see comment re s3.5 and RFC 6483.

Ack.

> 
> s7.1.7, 'comment' para: s/exit/exist/
> 

Ack.

Sriram, can you make the required changes as necessary to the holding
pattern copy assuming we all agree?

Cheers
Terry