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.
I would take the same position on draft-ietf-sidr-pfx-validate-00
after it is revised further to reflect recent new comments on the list.
(I do have another concern that the two documents overlap
substantially in core content even though they present it differently,
but that is a different issue.)
My reasons for supporting the documents as Informational RFCs
(as opposed to Normative RFCs):
These documents offer algorithms that are meant to
be used internally in routers, the outcome of which are used
for local decision within an AS to assist path selection, and the
origin validation outcomes are not communicated to other ASes in eBGP.
ISPs together with their vendors may use ROA information
in path selection with modified or other enhanced algorithms
for origin validation as they find suitable.
So the relying parties (RPs) may use these documents as guides but
may not like to be bound to them as a normative IETF standard or RFC.
One may argue that we need to have agreed upon semantics
about how ROAs will be interpreted in origin validation.
In final full deployment state, the validation states are Valid or Invalid;
those two validation states are unambiguously agreed upon
interpretations (in the full deployment state).
But during partial deployment, there is ambiguity anyway.
Some routers will accept "Unknown"; some may not.
Some routers may accept "Invalid" if there is no other
update with higher validation state; some may reject them outright, and so on.
Some RPs may like to treat prefix-length violations less punitively
if the origin AS is matched (during partial deployment).
Some ISP routers may assign "Valid" state to customers' prefixes even when
they do not have ROAs just because the {prefix, Origin AS} associations
are well known for their own customers.
Partial deployment period may be quite prolonged.
This is where the RP may need to have the flexibility.
I feel that the documents (published as Information RFCs) would be
excellent for providing general agreed upon understanding
about the possible origin validation approaches based on ROAs
but should not strictly bind the relying parties to the recommendations
(especially, under partial deployment scenarios).
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
