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/