Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
draft-ietf-sidr-rpsl-sig-12

I am also curious about the point in Stephen's discuss.

Al morton performed the opsdir review

Thanks for a well-written document and addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06567.html

Thanks all for chatting about my discuss, I think the
outcome is good.

--- OLD COMMENTS below, I didn't check 'em, feel
free to chat more or not, as you think best.

- If you keep the potential for http(s) URIs then I think
more text is needed in the security considerations but
it looks like you're taking that out for now so I guess
that's ok. 

- 2.1, I don't see why it's useful to allow variation in the
fields of the signature attribute e.g. why "MAY" the version
not be 1st?

- 2.1, "t=" and "x=" any limits on precision here?
(Non-)support for fractional seconds can be a source for
non-interop if not. The "All times MUST be converted to" is
also actually a little ambiguous as you don't say to do that
before signing;-)

- 2.1, "a=" did you want a lowercase "must" there?

- Are steps 2 and 3 in 3.1 order-sensitive? I think you
might sometimes need to do 2 after 3, or re-do 2 maybe or
else leading whitspace could be an issue. Maybe say that
sometimes you need to do step 2 >1 time?  

- 3.1, oops, an ambiguity - in "The following steps MUST be
applied in order..." does "in order" mean "in the order
below" or "so as to"? I assume the latter.

- 3.1: In general I think you'd be better if you pointed at
specific bits of text in all the RFCs mentioned in 3.1 -
it's maybe easy to get wrong otherwise, esp. if we don't yet
have >1 implementation. 

- 3.1, step 6: names are all ASCII right? just checking

- 3.2, step 1 - given 3.3 step 2, you're missing a step to
"publish the cert" at the c= location as well.

one nit:

"MUST reject the signature and threat the object as a regular" I think you mean `s/threat/treat`

Misc comments:

* Thank you for the very clear canonicalisation requirements!

* For route6 objects, where two resource holder's signatures considered such that it might address the inability to properly sign the RPSL when one holder possesses the ASN and another possesses the prefix? (just a comment, nothing more)