Subject: [sidr] draft-ietf-sidr-lta-use-cases-01

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 13:06:51 -0400

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).