Subject: [sidr] wg adoption call for draft-tbruijnzeels-sidr-validation-local-cache-02

From: Sandra Murphy <[email-masked]>
Date: Wed, 9 Dec 2015 18:08:14 -0500

As noted in the minutes, the authors of draft-tbruijnzeels-sidr-validation-local-cache-02 request that the working group adopt this work as a wg work item.

A working group adoption poll starts now and will end 14 days from now on 23 December.

Please respond on the list to say whether you support adoption of this work as a working group work item AND whether you will participate in the discussion.

Remember that working group consensus to adopt the work needs responses, not just absence of objection, so speak up.

--Sandy, speaking as one of the wg co-chairs

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Dec 2015 08:21:31 +0900

have read.  support adoption

randy

---

From: Rob Austein <[email-masked]>
Date: Tue, 15 Dec 2015 12:42:46 -0500

At Wed, 9 Dec 2015 18:08:14 -0500, Sandra Murphy wrote:
> 
> As noted in the minutes, the authors of
> draft-tbruijnzeels-sidr-validation-local-cache-02 request that the
> working group adopt this work as a wg work item.
...
> Please respond on the list to say whether you support adoption of
> this work as a working group work item AND whether you will
> participate in the discussion.

I have read this and support adoption.

I found myself walking down this same road when I started thinking
about how to implement RRDP, so I think we need this.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 15 Dec 2015 18:04:17 -0300

Read and support.

On 12/9/15 8:08 PM, Sandra Murphy wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Dec 2015 17:25:24 -0500

I think we ought to have a document that describes how an RP can manage 
a local
cache, since we usually say that we expect RPs to do so. However, this 
document
seems to be a description of only one implementation's approach to local 
cache
management. I'd be more comfortable with a document that is co-authored by
the developers of the three major RP implementations.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 16 Dec 2015 11:30:47 +0100

Hi Steve, group,

I agree that it would be useful to have a standards track document co-authored by the three major implementors.

But this document is intended as an informational track document to describe our implementation only, so that:
- it can be scrutinised
- we can refer to it to explain how our implementation works
- it can server as an example, not standard, on how this can work

It may very well be that parts of this exercise are useful to feed into another, standards track and implementation agnostic, document later. I believe that Rob already expressed interest in this - long term, but he can correct me of course :)

In short: I see your point, but I don't believe the efforts are mutually exclusive.

Tim

> On 15 Dec 2015, at 23:25, Stephen Kent <[email-masked]> wrote:
> 
> I think we ought to have a document that describes how an RP can manage a local
> cache, since we usually say that we expect RPs to do so. However, this document 
> seems to be a description of only one implementation's approach to local cache

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Dec 2015 11:43:10 -0500

Just read it (it’s only 9 pages) and support adoption.

spt

> On Dec 09, 2015, at 18:08, Sandra Murphy <[email-masked]> wrote:
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Dec 2015 17:36:07 -0500

Tim,

Since, as you reminded me, this is Informational, I agree that this
doc need not be co-authored  as I had suggested. But the intro must
emphasize that it just documenting what RIPE has chosen to do, and
that it does not claim to be a set of recommended local cache management
design notes.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 17 Dec 2015 09:57:16 +0100

Hi Steve,

> that it does not claim to be a set of recommended local cache management

I agree. And I have no objections to a name change of the document either.. maybe:

ripe-ncc-rpki-validation-implementation

Tim