Subject: [sidr] Current document status && directionz

From: Chris Morrow <[email-masked]>
Date: Fri, 02 Sep 2016 16:56:10 -0400

Howdy SIDR peeps,
(+bonus ops ad)

Following on the Berlin meeting we were trying to accomplish two
things:

  1) get all documents related to sidr protocols into wglc and then
  publication

  2) get all documents which are more operationally focused moved
  along to an ops group (sidr-ops or something akin to that)

With that in mind there are 8 documents in the publication queue:
  draft-ietf-sidr-as-migration
  draft-ietf-sidr-bgpsec-algs
  draft-ietf-sidr-bgpsec-ops
  draft-ietf-sidr-bgpsec-overview
  draft-ietf-sidr-bgpsec-pki-profiles
  draft-ietf-sidr-bgpsec-protocol
  draft-ietf-sidr-origin-validation-signaling
  draft-ietf-sidr-rpki-rtr-rfc6810-bis

and 11 still in progress. Of the 11 left Sandy and I think they
roughly break down like:

Documents which should move to the ops group:
  draft-ietf-sidr-bgpsec-rollover
  draft-ietf-sidr-lta-use-cases
  draft-ietf-sidr-route-server-rpki-light - authors notified/queried about this
  draft-ietf-sidr-rtr-keying

documents which should finish out in sidr:
  draft-ietf-sidr-delta-protocol
  draft-ietf-sidr-publication
  draft-ietf-sidr-rpki-oob-setup - pub request in flight
  draft-ietf-sidr-rpki-tree-validation
  draft-ietf-sidr-rpki-validation-reconsidered
  draft-ietf-sidr-slurm - authors recently updated
  draft-ietf-sidr-adverse-actions - wglc imminent

I think if there's no meaningful discussion on change for these
between now and 9/16/2016 (Sept 16th) we will assume this list is
correct. For documents in the 'move' list, if progress to publication
happens 'good!'. For all documents in the 'stays' list:
  1) we aim to have wglc by Seoul
  2) publication requests started on as many as possible

We plan to meet in Seoul, but not in Chicago (Mar 2017) where we
expect the ops group to exist and meet. We can progress documents in
SIDR after Seoul, but the WG should close out shortly after the new
year. (or that's the goal).

Thoughts?
-chris

---

From: joel jaeggli <[email-masked]>
Date: Sat, 3 Sep 2016 14:06:25 -0700

>   draft-ietf-sidr-rtr-keying

I think we good good feeback on the draft of a charter, I will start
work on taking this to the IESG, but as some point soon the time will
come to ask for community review of that proposal.

regards
joel

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 05 Sep 2016 15:32:56 -0300

Hi Chris,

I know we already discussed this over private email, but perhaps you can 
comment on the list on the future of the requested WG adoption call for 
the ‘all resources’ applicability statement draft.

thanks!

-Carlos

On 2 Sep 2016, at 17:56, Chris Morrow wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 5 Sep 2016 19:54:53 -0300

Here is the pointer to the document:

https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01

Apologies for my earlier laziness.

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Sep 2016 08:16:44 +0900

> https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01

you gotta love it.  the rirs do not have the social responsibility to
root at the iana.  and they do not have the guts to root at the nro.

so we are supposed to weaken the reliability of the system and deploy
a consistency checking hack as a patch?  how does that work in the
presence of make before break transfers etc?

what's wrong with this picture?  actually, what isn't wrong with it?

randy

---

From: Chris Morrow <[email-masked]>
Date: Tue, 06 Sep 2016 11:58:46 -0400

At Mon, 5 Sep 2016 19:54:53 -0300,
> Apologies for my earlier laziness.

no worries, yes Sandy and I chatted about this... err, I think the end
 result was: "is this an ops thing? should this go to ops? or should
 we just adopt it in SIDR and jam it through?"

I think sandy was due to send 'authors'(you/andy/etc) a mail about
this... oh and we're waiting on Alvaro to reply to this as well.

I'll mail an update to the list.

---

From: Chris Morrow <[email-masked]>
Date: Tue, 06 Sep 2016 12:06:47 -0400

At Sat, 3 Sep 2016 14:06:25 -0700,
joel jaeggli <[email-masked]> wrote:
> 
> [1 Re: Current document status && directionz <multipart/mixed (7bit)>]
> [1.1  <text/plain; windows-1252 (quoted-printable)>]

I also forgot to mention the all-res draft: 
  draft-rir-rpki-allres-ta-app-statement

is waiting for some AD comments to complete (with chairs I mean) to set location/direction.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Sep 2016 15:45:32 -0400

+1

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 6 Sep 2016 21:51:19 +0000

Carlos,

I guess what the RIRs are going to do is to create a CA hierarchy:
RIR_CA_0/0_(probably a hidden HSM) ‹> RIR_CA_RIR_RESOURCES (online HSM) ‹>
member_CA

This means that not much changed from the current situation multiple
self-signed certs, other than instead of getting the list of resources for
each RIR from the first CA certificated, I need to fetch the second level
CA cert.

Is this how you plan to implement this change?

Regards,
Roque

‹ 
Roque Gagliano
Tail-f Solutions Architect Southern Europe
+41 76 449 8867

On 06/09/16 00:54, "sidr on behalf of Carlos M. Martinez"
<[email-masked] on behalf of [email-masked]> wrote:

>> the Œall resources¹ applicability statement draft.
>> 
>> thanks!
>> 
>> -Carlos
>>

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Sep 2016 18:00:00 -0400

I guess one question here is the purpose of publishing this document:

a) If the purpose of asking the WG to publish is a hope that the WG
   will agree that this is a good idea, then I'm with Randy and Steve
   in the "hell no" camp.

b) If the purpose is to document something that the RIRs have
   unilaterally decided to do whether the IETF likes it or not, I
   guess we should thank them for documenting their intentions, and
   publish it with a big IETF / IESG disclaimer saying that it's a
   really bad idea but not something the IETF can prevent.  I suppose
   we could refuse to publish entirely in this case, but suspect that
   just makes it harder for newcomers to understand what happened.

My understanding was that we were already well into case (b) territory.

Carlos et al, please correct me if I'm wrong and the RIRs are willing
to back down on this.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 6 Sep 2016 22:48:07 -0400

>    will agree that this is a good idea, then I'm with Randy and Steve
(note, I do not care for this message about politics)

we're here because, I think, from the top down to the RIR there isn't a
hierarchy being created, right? the RIR folk are saying: "Ok, you all want
this thing, but upstairs hasn't created the root, so we're going to do the
best we can with making a root each that allows us to xfer between RIRs.
This is how it's being done, so you have some docs about the mechanics
involved and can build/guide from there"

is that not the case? (again, I don't care about the politics)

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Sep 2016 00:07:20 -0400

> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which are
pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"

> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also political.

Stripped of the politics, we're having this conversation because the
RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.  Or maybe it's more
than five, some of the RIRs have extra roots just for fun, but let's
take it as given for now that they'll collapse back down to five.

The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.  This is technically broken.

Generating a single RPKI root is not hard.  It can be done by a cron
job.  I ran one for years, for experimental purposes, entirely from
data already available to the RIRs.  The only real issue is which
database to believe when they disagree -- which is exactly the problem
the RIRs are trying to push onto the RPs with this document.

Which brings us back to bad technical decisions and political reasons.
Sorry.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Sep 2016 13:10:51 +0900

> is that not the case? (again, I don't care about the politics)

dear ostrich,  the problem is it is all about politics.  and politics is
what happens when two or more funny monkeys are involved.

despite many years of promises promises of a single root

  o the rirs have been at war with the iana this whole time.  i neither
    know nor care whose fault it is.  but their egos and lawyers are
    preventing an iana root.

  o the rirs have the nro, which could be a single root.  they seem to
    lack the fortitude and/or spirit of cooperation to root at the nro.

this was not how it was being done a year ago.  now the warring parties
are each declaring themselves god.  this is not an improvement, in fact
the opposite.  if we accept this draft, as rob says, it should be
labeled as highly toxic.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Sep 2016 10:42:10 -0400

> will loop back to politics as soon as one asks "why?"
totally agree/understand.

> I'm ignoring "upstairs", because that is also political.
yes, sorry I was trying to not point fingers at particular people/things :(

> take it as given for now that they'll collapse back down to five.
ok

> on the CA side.  This is technically broken.
I think it means that since there is no single root coming 'soon', the
RIR's are taking a step to move forward with rpki despite the 'no single
root' existing. Ideally they would have a method to keep from being out of
sync in their processing of requests/changes. Ideally that process would be
outlined in the document here so we'd be able to say: "Ok, as the rpki
lives on, how does X and Y and Z get done? what happens at X step 3 when
Carlos decides to take a very long lunch? how does the process move along?
what checks/balances are there?"

That's the part that you're referring to as KC's comment, I think?

> the RIRs are trying to push onto the RPs with this document.
I don't disagree that running a CA is 'simple'... I think though that if
the RIRs are in a position where there won't be a single root above them
'for a while' (it's been ~10 yrs at this point) but they feel they need to
move forward with something, is this direction acceptable? is it better to
document that decision and it's gotchas than to not move forward at all? or
to 'continue waiting for the single root' to arrive?

> Which brings us back to bad technical decisions and political reasons.

yup.

---

From: Andrew de la Haye <[email-masked]>
Date: Wed, 7 Sep 2016 16:55:37 +0200

> On 07 Sep 2016, at 16:42, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 
> On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <[email-masked] <mailto:[email-masked]>> wrote:
> I think it means that since there is no single root coming 'soon', the RIR's are taking a step to move forward with rpki despite the 'no single root' existing. Ideally they would have a method to keep from being out of sync in their processing of requests/changes. Ideally that process would be outlined in the document here so we'd be able to say: "Ok, as the rpki lives on, how does X and Y and Z get done? what happens at X step 3 when Carlos decides to take a very long lunch? how does the process move along? what checks/balances are there?"
> 
> I don't disagree that running a CA is 'simple'... I think though that if the RIRs are in a position where there won't be a single root above them 'for a while' (it's been ~10 yrs at this point) but they feel they need to move forward with something, is this direction acceptable? is it better to document that decision and it's gotchas than to not move forward at all? or to 'continue waiting for the single root' to arrive?

Chris,

fully agree, the intent is to provide unity and transparency on how the RIRs handle their respective trust anchors at this stage

Andrew 

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>
>

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Sep 2016 12:04:21 -0400

On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye <[email-masked]> wrote:

> fully agree, the intent is to provide unity and transparency on how the
> RIRs handle their respective trust anchors at this stage
>
>
ok, I'm glad I ddin't mis-interpret... now I'll wait on stephen/rob to pipe
back up :)
Maybe this doesn't go through a routing-area group as a document, maybe
this should really be in the ops-area group that comes out of SIDR?

Or maybe there's pushback that says: "Hey, I hear what you all in the rir
want, but it's not cool, please please let's dive back into the politics
stream and see how we get movement on what we all (probably?) want: a
single root for this system."

i'm just fishing for direction.

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Sep 2016 12:32:02 -0400

At Wed, 7 Sep 2016 10:42:10 -0400, Christopher Morrow wrote:
...
> I think it means that since there is no single root coming 'soon',

Because they have chosen to neither create one nor work out their
issues with the obvious external candidate.  Politics.

> the RIR's are taking a step to move forward with rpki despite the
> 'no single root' existing. Ideally they would have a method to keep
> from being out of sync in their processing of
> requests/changes. Ideally that process would be outlined in the
> document here so we'd be able to say: "Ok, as the rpki lives on, how
> does X and Y and Z get done? what happens at X step 3 when Carlos
> decides to take a very long lunch? how does the process move along?

So they're proposing a half-assed alternative instead of doing what
they should be doing and promised us they would be doing.  Politics.

> That's the part that you're referring to as KC's comment, I think?

No, KC's comment was the observation that this is a cost transfer and
a technically bad one: it's the RIRs pushing problems onto RPs instead
of solving those problems, and technically bad because the RPs have no
sane grounds for deciding which RIR to believe when RIRs disagree.

> I don't disagree that running a CA is 'simple'... I think though
> that if the RIRs are in a position where there won't be a single
> root above them 'for a while' (it's been ~10 yrs at this point)

They could have a single root next week if they wanted one badly
enough.  (Lack of) action speaks louder than words.  Politics.

Well, unless the current generation of RIR CA implementations don't
support the client side of the provisioning ("up-down") protocol,
which would be interesting in view of their long-standing promise to
move towards a single root.  I have no data on this other than that
it's been at least five years since the last time I participated in an
up-down interoperability test with RIR CA software in the client role;
I have no idea whether the RIRs have tested this since that time.

> but they feel they need to move forward with something, is this
> direction acceptable? is it better to document that decision and
> it's gotchas than to not move forward at all? or to 'continue
> waiting for the single root' to arrive?

Each RIR separately claiming ownership of 0-4294967295,0.0.0.0/0,::0/0
is not progress towards anywhere we want to go.

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 7 Sep 2016 19:56:01 +0000

Hi Andrew,

Taking into consideration your call for transparency, do you think the RIRs could add a section on the document where it is clearly stated what are the roadblocks to have a single root? I believe the document describes the problem and one technical feasible solution but not the full solution space. We need to understand that this is a decision from which we will most probably not turn back (we are basically deciding that there will never be a single root).

Finally, I can read in your email that you mention that this is a request from “the RIR folks”. Are you referring to RIR staff? The boards? The communities via a bottom-up process?

Best regards,
Roque

—
Roque Gagliano

From: sidr <[email-masked]<mailto:[email-masked]>> on behalf of Andrew de la Haye <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 7 September 2016 at 16:55
To: Christopher Morrow <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sidr] Current document status && directionz

On 07 Sep 2016, at 16:42, Christopher Morrow <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <[email-masked]<mailto:[email-masked]>> wrote:

ok

Chris,

Andrew

yup.

_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 7 Sep 2016 20:10:08 +0000

Hi Chris,

With regards to "draft-rir-rpki-allres-ta-app-statement², the question for
the WG acceptance should go back to the authors on their willingness to
take WG feedback.

If the aim is to work with the WG, I think the document describes a
current problem with inter-RIR address transfers and one (but maybe not
the one the WG would finally document) solution.

If the aim is for the RIRs to inform the rest of the world of a decision
they have taken, this should be an individual draft submission into the
Independent Submission Editor and not a SIDR WG item.

Regards,
Roque

On 06/09/16 18:06, "sidr on behalf of Chris Morrow" <[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Sep 2016 00:42:16 -0700

> Or maybe there's pushback that says: "Hey, I hear what you all in the
> rir want, but it's not cool, please please let's dive back into the
> politics stream and see how we get movement on what we all (probably?)
> want: a single root for this system."

the iab did that and got a written agreement that the rirs would do so.
nothing more is needed other than action.

randy

---

From: Heasley <[email-masked]>
Date: Thu, 8 Sep 2016 06:32:31 -0700

>> want: a single root for this system."

Or can the RIRs be removed from the equation? Why must we care what the RiRs want (fitting of many questions surrounding the RIRs)? Theyre essentially just agents of the IANA, its not inconceivable to replace them or separate duties.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Sep 2016 11:36:56 -0400

On Thu, Sep 8, 2016 at 9:32 AM, Heasley <[email-masked]> wrote:

> Or can the RIRs be removed from the equation? Why must we care what the
> RiRs want (fitting of many questions surrounding the RIRs)? Theyre
> essentially just agents of the IANA, its not inconceivable to replace them
> or separate duties.
>
>
sure... I think sriram may cover this in his document about the decision
processes which lead to where we are today.

I think, one way to look at the document and situation is this:
  o community folks for each RIR asked for RPKI to be supported
  o RIR folk put in some development $$/effort to do that
  o no single-root came forward
  o to make the RPKI work, specifically for xfers, or one way wrt
transfers, is to fake the root at each RIR.
  o rpki progress can still be made until single-root arrives, and then
some re-signing and probably rough work would have to happen to move under
the single-root.

sure lots of evil other things could be afoot, but I don't see evidence of
that.

again, perhaps it's worth the community folks (outside the ietf) just
saying:
  "I hear what you're saying, I like your want to keep this going forward,
but REALLY we need to sort out the issues around 'single-root' and get that
done.. the operational cost to not having a 'single-root' is just too
damned high."

<https://imgflip.com/i/1a8y83>

> > nothing more is needed other than action.

apologies for not being up on the chain-of-command, but this doesn't seem
like it's enough... we've been waiting, what are the blockers? why can't
this action move forward? (yes, politics, let's move that to anyother list
I  suppose)

-chris

---

From: David Conrad <[email-masked]>
Date: Thu, 8 Sep 2016 07:39:23 -1000

Chris,

On September 7, 2016 at 4:42:21 AM, Christopher Morrow ([email-masked]) wrote:
I don't disagree that running a CA is 'simple'... I think though that if the RIRs are in a position where there won't be a single root above them 'for a while' (it's been ~10 yrs at this point) but they feel they need to move forward with something, is this direction acceptable? is it better to document that decision and it's gotchas than to not move forward at all? or to 'continue waiting for the single root' to arrive?
For blood pressure spiking reasons, I have been trying to keep out of this discussion, but this put me over the edge.

As far as I am aware, ICANN as the IANA Internet Numbering Functions Operator, has been and continues to be willing to provide RPKI "single root" services. In point of fact, ages ago, I personally authorized non-trivial expenditures (including hiring staff) to set up and deploy a working RPKI root pilot to allow the RIRs to test working with a single root as directed by the IAB in https://www.iab.org/documents/correspondence-reports-documents/docs2010/iab-statement-on-the-rpki/:

"Thus, the IAB strongly recommends a single root aligned with the root of the address allocation hierarchy (now part of the IANA function). "

After said testbed deployment, I was informed that none of the RIRs were interested in participating in the tests.

I will admit a high level of amazement and not a small amount of disappointment at the fascinating level of complexity being created in order to avoid a single root.

This is not technical.  

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 8 Sep 2016 07:47:34 -1000

Chris,

sure... I think sriram may cover this in his document about the decision processes which lead to where we are today.

This is NOT accurate. ICANN, as the IANA Internet Numbering Functions Operator, did come forward and we were informed there was no interest from the RIRs for the IANA Internet Numbering Functions Operator to participate in testing a single root RPKI service.

  o to make the RPKI work, specifically for xfers, or one way wrt transfers, is to fake the root at each RIR.
  o rpki progress can still be made until single-root arrives, and then some re-signing and probably rough work would have to happen to move under the single-root.
[...]
apologies for not being up on the chain-of-command, but this doesn't seem like it's enough... we've been waiting, what are the blockers? why can't this action move forward? (yes, politics, let's move that to anyother list I  suppose)
I suspect if the Internet Numbering Community would be interested in a single root operated by the IANA Internet Numbering Functions Operator, all they need do is _ask_.

Regards,

-drc

(ICANN CTO, but speaking only for myself. Really)

P.S. In my previous note, I forgot to include the above disclaimer. I am not speaking for ICANN here.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Sep 2016 14:39:29 -0400

(I appreciate the corrections, and I really was trying to not be political
nor be mean to the political parts)

On Thu, Sep 8, 2016 at 1:39 PM, David Conrad <[email-masked]> wrote:

> For blood pressure spiking reasons, I have been trying to keep out of this
> discussion, but this put me over the edge.
>

sorry about that, not trying to get people angry, really.

> As far as I am aware, ICANN as the IANA Internet Numbering Functions
> Operator, has been and continues to be willing to provide RPKI "single
> root" services. In point of fact, ages ago, I personally authorized
> non-trivial expenditures (including hiring staff) to set up and deploy a
> working RPKI root pilot to allow the RIRs to test working with a single
> root as directed by the IAB in https://www.iab.org/documents/
> correspondence-reports-documents/docs2010/iab-statement-on-the-rpki/:
>
> "Thus, the IAB strongly recommends a single root aligned with the root of
> the address allocation hierarchy (now part of the IANA function). "
> After said testbed deployment, I was informed that none of the RIRs were
> interested in participating in the tests.
>
>
doh! ok, so some mixed signals, that sucks. and makes this confusing and
hard to fix... going forward though, what's the path? "get rir and
iana/icann to agree that this is important, set a schedule for deployment,
profit?"

> I will admit a high level of amazement and not a small amount of
> disappointment at the fascinating level of complexity being created in
> order to avoid a single root.
>
> This is not technical.
>
>
ok, so we're back to: "I hear what you are saying, we (community) really
need 'single root' please go make that happen."

it seems to me.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Sep 2016 14:40:50 -0400

On Thu, Sep 8, 2016 at 1:47 PM, David Conrad <[email-masked]> wrote:

> This is NOT accurate. ICANN, as the IANA Internet Numbering Functions
> Operator, did come forward and we were informed there was no interest from
> the RIRs for the IANA Internet Numbering Functions Operator to participate
> in testing a single root RPKI service.
>

ok, then that's distressing :( we can re-address the situation from the
rirs north through I bet?

> I suspect if the Internet Numbering Community would be interested in a
> single root operated by the IANA Internet Numbering Functions Operator, all
> they need do is _ask_.
>

excellent, thanks for the clarifications.
-chris

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Sep 2016 12:20:49 -0700

> ICANN, as the IANA Internet Numbering Functions Operator, did come
> forward and we were informed there was no interest from the RIRs for
> the IANA Internet Numbering Functions Operator to participate in
> testing a single root RPKI service.

this matches my memory.  i am told the rirs even sent a letter to the
iana saying, in pore politic terms, foad.

> single root operated by the IANA Internet Numbering Functions
> Operator, all they need do is _ask_.

i hereby ask

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Sep 2016 12:23:14 -0700

> going forward though, what's the path? "get rir and iana/icann to
> agree that this is important, set a schedule for deployment, profit?"
                                                              ^deploy,

> ok, so we're back to: "I hear what you are saying, we (community)
> really need 'single root' please go make that happen."

yeppers

randy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Sep 2016 17:01:45 -0400

The nice thing about working in organizations that pride themselves on openness, is the archives.

Some pointers I found.  A long history.  And this list is not necessarily complete.

NRO letters:
https://www.nro.net/wp-content/uploads/icann_singletrustanchor.pdf
https://www.nro.net/news/nro-communication-to-icann-on-rpki-global-trust-anchor

https://www.iana.org/about/presentations/20110915-manderson-ipcertification.pdf.  Some rather detailed design info.

ICANN-NRO letters
https://www.icann.org/en/system/files/correspondence/gerich-to-wilson-27sep13-en.PDF
https://www.icann.org/en/system/files/correspondence/wilson-to-gerich-12aug13-en.pdf

IAB minutes from 2013 that record the RIR’s reports about their participation and mention the testbed
https://www.iab.org/documents/minutes/minutes-2013/iab-minutes-2013-11-05/

(IIRC, the IETF was involved as well and Richard Barnes and Allisa Cooper (?) were tasked with IETF review of the testbed design - but I haven’t found that yet.)

—Sandy, speaking as a regular ol’ working group member