Last Call Review of draft-ietf-sidr-usecases-05
review-ietf-sidr-usecases-05-genart-lc-davies-2012-12-19-00

Request Review of draft-ietf-sidr-usecases
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-12-14
Requested 2012-12-06
Authors Terry Manderson, Kotikalapudi Sriram, Russ White
Draft last updated 2012-12-19
Completed reviews Genart Last Call review of -05 by Elwyn Davies (diff)
Genart Telechat review of -05 by Elwyn Davies (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-sidr-usecases-05-genart-lc-davies-2012-12-19
Reviewed rev. 05 (document currently at 06)
Review result Ready with Nits
Review completed: 2012-12-19

Review
review-ietf-sidr-usecases-05-genart-lc-davies-2012-12-19

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sidr-usecases-05.txt
Reviewer: Elwyn Davies
Review Date: 19 December 2012
IETF LC End Date: 20 December 2012
IESG Telechat date: (if known) 20 December 2012

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.

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?

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?

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.

Abstract/s1 et seq: Need to expand RPKI

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.

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.

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

s1.3, last para: Possibly need to clarify *what* is originated?  s/that
is originated/for which a route is advertised/

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

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

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

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

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

s6.x: Given the 'make-before-break' principle, would it be sensible to
describe the add before the revoke in each case?

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

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

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