Skip to main content

Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
RFC 7909

Yes

Alvaro Retana

No Objection

(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) (was Discuss) Yes

Yes (2016-05-19)
Thank you for addressing my DISCUSS points.

(Alia Atlas; former steering group member) No Objection

No Objection (for -11)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -11)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2016-05-18 for -11)
I am also curious about the point in Stephen's discuss.

(Benoît Claise; former steering group member) No Objection

No Objection (for -11)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -11)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2016-05-18 for -11)
Al morton performed the opsdir review

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-05-16 for -11)
Thanks for a well-written document and addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06567.html

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -11)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2016-05-19)
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.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -11)

                            

(Terry Manderson; former steering group member) (was Discuss) No Objection

No Objection (2016-05-17 for -11)
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)