Sriram, I have discussed this by email with my co-author who is in
transit. Please find out reply interpolated below, with apologies for
delay.
-George
From: "Sriram, Kotikalapudi" <[email protected]>
Date: 3 November 2009 4:00:14 AM AEDT
To: "[email protected]" <[email protected]>
Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation
Comments on the -03 version:
Section 4.1 is a bit confusing because it does not seem to take ROA
prefix maxlength into consideration or fails to make any mention of
it.
Yes, you are right - it could be clearer that "More Specific than ROA"
in the table and the text that says "more specific than the ROA" means
a prefix length that is greater than the ROA's maxLength value. That
is clear in section 2, step 3, but not specifically reiterated in
section 4.1
Several of the statements in this section do not make it clear what
implication maxlength has on prefix matching. For example, does
definition of "covering aggregate" include the case when the update
(route) prefix length is longer than maxlength?
"Covering aggregate" is used twice in the draft - once in section 2 to
describe the set of ROAs that are potential candidates to validate a
route object, and again in section 4 to describe the validation of a
single route object. The context of use in the two sections is
different, and we (the authors) had felt that the text was sufficitly
clear, but evidently that was not a good assumption.
In my understanding, ROA prefix is not a _covering_ aggregate if the
update prefix length exceeds maxlength, unless purposefully defined
otherwise.
It would help if you gave an example here. We are lost in
understanding your question.
"Covering Aggregate" should be clearly defined in Section 2,
explicitly stating what role maxlength plays, before getting into
any description of algorithms.
The role of maxlength is clearly described in step 3 of section 2, but
your point about "covering aggregate" not being well defined is a good
point.
Perhaps an example would help with the text.
In my opinion, Section 2 already provides coverage for partial
deployment for the case of prefixes that are not included in any
ROA. Steps 1 and 2 of the algorithm on page 4 take care of this case
of partial deployment. So having a modified algorithm in Section 4
seems redundant. The discussion part of Section 4 is relevant and
can be suitably edited and moved to Section 2.
Section 4 does not present a modified algorithm. Section 4 explains
the derivation of the "unknown" outcome of step 2 of section 2.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
