Skip to main content

BGPsec Algorithms, Key Formats, and Signature Formats
RFC 8208

Yes

Alvaro Retana

No Objection

(Alia Atlas)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)

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

Alvaro Retana Yes

(Kathleen Moriarty; former steering group member) Yes

Yes (2016-12-13 for -16)
Thanks for your work on this and it's good to hear there are interoperable implementations (after reading the responses to other comments).

(Alexey Melnikov; former steering group member) No Objection

No Objection (2016-12-10 for -16)
Maybe I missed it, but I don't think the document is clear on why new algorithms are needed. Is this specified in one of referenced documents?

(Alia Atlas; former steering group member) No Objection

No Objection (for -16)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -16)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -16)

                            

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

No Objection (2016-12-12 for -16)
As noted by Jouni in his OPS DIR review, and acknowledged by Sean Turner
> o Section 7 IANA Considerations says on line 192:
>  "Infrastructure (RPKI) group.  The one-octet BGPsec Algorithm Suite”
>                                     ^^^^^^^^^
>  However, in the following table and text it says nothing about
>  values 0x10-0xff. Are these unassigned or reserved? This is a bit
>  confusing since the table lists values up to 0xF (one-nibble).

Sigh - that should be:

+------------+------------+-------------+---------------------+
 | 0x2-0xEF   | Unassigned | Unassigned  | This draft          |
+------------+------------+-------------+---------------------+
| 0xFF       | Reserved   | Reserved    | This draft          |
+------------+------------+-------------+---------------------+

(Deborah Brungard; former steering group member) No Objection

No Objection (for -16)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -16)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -16)

                            

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

No Objection (2016-12-12 for -16)
Just a thought: Would it be useful to add an IESG note saying something like in the sheperd write-up:
 "[...] there are published references
    that preceded the filing of the patent, especially those 
    mentioned in RFC6090.  RFC6090 notes that its descriptions
    "may be useful for implementing the fundamental algorithms without 
    using any of the  specialized methods that were developed in 
    following years.""
I know we usuall don't do things like this. But I'm wondering how someone who wants to implement this should figure this out otherwise....?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -16)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-12-13 for -16)
- As Randy commented, if the goal is to smallerise the
packets, it'd have been nice to use eddsa here but I assume
that wasn't practical due to the timing and the number of
RPKI elements that'd need to be defined for that? Is that
right? Did the WG consider using 25519 instead of p256?  If
not, is it worth asking, just in case everyone loves the
idea more than this?

- Documents like this are better with test vectors included
or referenced. Couldn't you add those or some pointers to
those?

- To answer Mirja's point: Anyone who knows RFC6090 knows
that it more or less only exists because of IPR silliness.
And sadly, even though 6090 only references documents that
predate relevant IPR filings by >20 years, even 6090 still
got an (IMO also silly) IPR declaration.  [1] Sheesh, but
whaddya gonna do? :-( Anyway, I don't think there's a need
to, or benefit from, adding text here about the well-known
situation with ECC IPR that I believe stymied deployment
for at least a decade.

   [1] https://datatracker.ietf.org/ipr/search/?rfc=6090&submit=rfc

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -16)