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 IESG member
(was Discuss) Yes
Yes (2016-05-19)
Thank you for addressing my DISCUSS points.
Alia Atlas Former IESG member
No Objection
No Objection (for -11)

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -11)

                            
Ben Campbell Former IESG 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 IESG member
No Objection
No Objection (for -11)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -11)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-05-18 for -11)
Al morton performed the opsdir review
Kathleen Moriarty Former IESG 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 IESG member
No Objection
No Objection (for -11)

                            
Stephen Farrell Former IESG 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 IESG member
No Objection
No Objection (for -11)

                            
Terry Manderson Former IESG 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)