I'm not sure I agree with this document being Informational. ROAs
need to have some well-defined authorization semantic. Just like
information in BGP itself, ROAs communicate information between
domains, so the creators and consumers of ROAs need to know what
authorization is being communicated. In other words, what needs to be
standard is a validate(roa[], route) routine that says whether a given
set of ROAs authorize, deny, or ignore a given route.
Sriram is correct that AS-internal stuff should be Informational. The
AS-internal stuff we're talking about here is what an AS does with the
output of the validate(), basically a "deployment considerations"
document.
In terms of the documents in hand: As I read it, -roa-validation would
be a good basis for the Standards Track document I describe above if
we just remove Section 3, which talks about what you do with
validation outputs. -pfx-validate seems like a good candidate for the
Informational document. As a path forward, it would make sense to me
to focus -roa-validation on the specific validation semantics of a set
of ROAs (advancing it as Standards Track) and to focus -pfx-validate
on what an AS can do with these validation results (as Informational).
Finally, one specific note on -roa-validation and -roa-format. Before
I wrote this email, to make sure I understood things correctly, I
wrote a test implementation of the validation algorithm [1]. My
comment as an implementor is that the documents don't make it very
clear how to implement the algorithm described in Section 2 of -roa-
validation. For instance, it's not obvious that the length of the
prefix is specified implicitly as the length of the IPAddress BIT
STRING. In general, it would be helpful if Section 2 of the -roa-
validation document were more specific, phrasing things in terms of
the data elements in hand instead of more abstract concepts like
"covering aggregate" (which the developer has to interpret as
"shorter prefix, same bits").
Sorry to enter the discussion so late, but I hope this is helpful,
--Richard
[1] <http://geopriv.dreamhosters.com/roaver.cpp>
On Nov 22, 2010, at 10:46 PM, Geoff Huston wrote:
On 23/11/2010, at 10:59 AM, Sriram, Kotikalapudi wrote:
I would support the LC on draft-ietf-sidr-roa-validation-10
if it had informational status,
i.e., be advanced for publication as an Informational RFC.
That was indeed the intention: please note line 3 of the document:
Secure Inter-Domain Routing (SIDR) G.
Huston
Internet-Draft G.
Michaelson
Intended status: Informational
APNIC
Expires: May 15, 2011 November 11,
2010
thanks,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
