I appreciate the changes Randy made to the -00 version of this doc.
However, I have a few concerns about the current version.
The end of Section 3 states:
For the purposes of this exploration, we refer to this localized view
as a 'Local Trust Anchor', mostly for historical reasons, but also
because implementation would likely be the local distribution of one
or more specialized trust anchors, [RFC6481].
Since this is supposed to be a requirements (aka use cases) doc, we ought
not prejudice the doc by presuming how the requirements will be satisfied.
Also, there are two docs that, together, probably address the requirements
I think we are trying to characterize, and they do not rely on the LTA model
that was proposed long ago.
Section 4 is a set of folksy, almost parable-style examples. I think the
doc should
provide clear definitions of the requirements, not examples from which
the reader
is expected to extract the underlying requirements. Examples are fine
as ways to
help illustrate a requirement, but are not a substitute for a clear
statement
of a requirement.
I offered re-worded examples in response to the -00 version of the use
cases doc.
They try to avoid extraneous comments and use very simple text (see
below). Still,
they were just examples based on Randy's -00 text. I suggest we try to
develop simple,
clear requirements statements that align with the examples Randy and I
have offered.
Section 5 correctly notes that what we are trying to "fix" are ROAs, not
certs. But,
if we are to avoid pre-judging solutions, we ought to remove the
discussion of the
need to modify Resource certs, GB records, etc.
Steve
-----
Case 1:
ISP C find that its CA certificate has been be revoked (or modified to
removed resources) by the RIR (or ISP) that issued it. ISP C believes
that this revocation was either an error by RIR staff, or that the RIR
has been compelled to revoke the certificate by a law enforcement agency
in the jurisdiction where the RIR operates. ISP C would like other ISPs
to be able to ignore the certificate revocation (or modification), at
their discretion.
Case 1 also encompasses a larger case, e.g., when all of the ISPs with a
country require protection for an RIR action of this sort, coordinated
at a national level. We cannot assume that the country operates an NIR.
Case 2:
ISP B makes use of private address space (RFC 1918) or makes use of
address space allocated to some other party , but which is not announced
globally). ISP B makes use of the RPKI internally, as well as for global
routing. ISP B would like its use of private address space to work
internally with routers that make use of RPKI data.
Case 3:
An organization, A, is authorized to control routing of traffic from a
set of ISPs to the rest of the Internet. (For example, A may want
traffic to selected addresses to be redirected to other addresses, or be
dropped.)Because these ISPs want to use the RPKI, A needs a way to
coordinate their use of the RPKI (insupport of A's traffic management
goal).
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
