On 02/12/2008, at 5:52 PM, Pradosh Mohapatra (pmohapat) wrote:
| > | > As others have suggested, when "I have been allocated
| > | 203.10.60.0/22",
| > | > I issue an ROA for 203.10.60.0/22-22. That automatically means
| > that
| > | > there can't be any other advertisements for this prefix or its
| > more
| > | > specifics (unless I suballocate a more specific block and a
new
| > ROA
| > | > gets added to the repository for that]. Is there any case
| > | that's not
| > | > handled by doing this?
| > | >
| > |
| > | That's your _assumption_ of the sematics of a ROA. What
reference
| > | material or working group draft can you cite for semantic
| > | interpretation of a ROA?
| > | draft-ieft-sidr-roa-validation? I don't think so. The
| point of hte
| > | BOA draft it that it challenges this assumption by taking the
| > | position that such route aorigination authorities are explicitly
| > | scoped to the authority described in the object, without the
| > | implicit inclusion of any other authority or denial.
| >
| > So are you saying that an entity who is not owner of prefix
| 10/8 can
| > issue an ROA for it and it would be present in/added to the RPKI
| > repository?
| >
|
| The best answer I can give here is please read the sidr
| drafts. Your question really makes me suspect that you have
| not done so.
I have. Your response above prompted the question.
WG Chair Hat OFF.
Good to hear. In which case you would be well aware that a person who
is not the current right of use holder of an address prefix cannot
generate a valid RPKI object of any form and sign the object with an
RPKI signature using that prefix. So I fail to understand how an an
entity who is not owner of prefix 10/8 can issue an ROA for it that
would be considered valid in the RPKI, and if its invalidly signed
then whether it is in an RPKI repository publication point or not is
irrelevant. But as we've all read the drafts we all knew that anyway.
So I'm not sure why its worth repeating here.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
