Geoff Huston wrote:
Firstly, the semantics of the two objects differ. A ROA is an "authority" granted by a prefix holder that nominates an AS as a potential originating AS. The key observation here is that the AS holder is not necessarily aware of this ROA, or even necessarily aware that such an authority has been granted or published, let alone be prepared to announce the prefix as originating from this AS. The AS holder cannot cause such an authority to be removed or revoked. In contrast, a Route Object is a statement by an AS holder to the effect that the AS is currently, or may in the future, announce a particular prefix as originating from this AS.
Randy Bush wrote:
this is completely false. a route: object is a statement by the prefix owner of what as may announce, just like a roa; surprise surprise.
I disagree that my characterization of a Route Object is "completely false." A route object is not simply a statement by the prefix holder of what an AS may announce, but includes the explicit authorization of the AS holder. The basis for this interpretation of the authority model of a route object is based on: 1 - my interpretation of the text in RFC2725, Section 6, page 8, para 3, which states: "The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix." 2 - Section 2.5.5 of the RIPE Database Update Reference Manual (http://www.ripe.net/db/support/update-reference-manual.pdf) is consistent with the RFC in requiring that route object creation must satisfy several authentication criteria, including that: "It must match the authentication specified in the aut-num object referenced by the "origin:" attribute of the route object submission." 3 - The RIPE IRR code at ripedb/src/modules/au/au_rpsl.c, in the routine called route_rpsl_create() where aut-num authentication is explicitly checked. If I were to edit my original posting commenting on this proposal to clarify the argument I was making, I would change the last sentence quoted above to read: "In contrast, a Route Object is a statement by an AS holder, corroborated by the prefix holder, to the effect that the AS is currently, or may in the future, announce a particular prefix as originating from this AS." In reviewing the remainder of my original comment I do not believe that this edit alters the overall argument put forward, namely that in my view there are disadvantages to this proposal, arising from the observation that the explicit authorization of the AS holder is missing in the creation of the synthetic RPSL Route Object from a ROA (as the AS holder is not required to sign a ROA), and that this differs significantly from the authentication criteria used in the IRR context for route object creation. This difference causes consequent issues with the appropriate interpretation and use of these synthetic route objects, particularly in the case of filter construction, in the manner described in my original comment on this topic. Geoff Disclaimer: To be perfectly clear, yet again, to those who may otherwise misconstrue the context of these comments, the above is a personal comment, and in no way is intended to reflect any position of the APNIC Secretariat, now or in the future.