On Dec 3, 2008, at 5:33 PM, David Conrad wrote:
...
Either IANA is acting in some capacity as a trust anchor and as a
result there ARE IANA considerations
- OR -
IANA is not acting in in some capacity as a trust anchor in which
case the absence of IANA considerations is appropriate, but section
6.3 needs to be revised to make explicit that IANA is NOT involved
in the RPKI trust hierarchy.
David -
As I read the draft, the IANA's role as a trust anchor is no different
than any of the RIR's (i.e. each acting as their own trust anchor for
their own RPKI hierarchy):
S 6.3:
"This observation motivates a two-tier trust anchor model for the
RPKI. The top tier trust anchor for each RIR (and IANA) will be a
self-signed certificate that contains no resource extensions. ... "
Setting aside the relative merits of having each RIR and IANA using
a separate RPKI hierarchy, it's somewhat understandable that there
is no IANA Considerations section, since there is no new requirements
for namespace management being put or changed on the IANA, per BCP26.
As written, the IANA might, at its discretion, decide to make use of
res certs, but that's not mandatory for this document to be useful.
While there is no new namespace of identifiers to be managed, I think
that it might be valuable to document the communities expectations for
the IANA in an "IANA Considerations" section. Per the current draft,
this wouldn't necessary mention any IANA role as a trust anchor but
instead simply be note to the effect that "This document defines a
standard profile for certificates supporting validation of assertions
of right-to-use for Internet numbering resources, and that the IANA
should provide support for such assertions for the Internet numbering
resources which it manages."
/John
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
