Subject: [sidr] two stranded docuemnts - stake time

From: Chris Morrow <[email-masked]>
Date: Thu, 21 Jul 2016 11:36:28 +0100

We are going to officially stake:
  1)     draft-ietf-sidr-slurm
  2)     draft-ietf-sidr-lta-use-cases

These are not being progressed currently, and won't be in the future
it seems. We'll do the process bits next week to remove them from
SIDR's work queue.

-chris

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 21 Jul 2016 11:59:52 -0400

> On Jul 21, 2016, at 6:36 AM, Chris Morrow <[email-masked]> wrote:
> 
> 

Hasn’t had energy in a while, but not so long that I can say there’s no possibility of resurrection.  (e.g., keyroll had a two year gap in there.  But then the need was clear.)

> it seems. We'll do the process bits next week to remove them from

I’d like to hear from the authors (we’ve heard from Randy) whether they have a possibility of continuing.

And I’d think the wg has to declare there’s no interest - if there’s a reason, and a new author volunteers…

—Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 21 Jul 2016 12:37:27 -0400

> On Jul 21, 2016, at 11:59 AM, Sandra Murphy <[email-masked]> wrote:
> 
> 

Chris, I suppose that’s what you meant by “the process bits”

—Sandy

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Jul 2016 13:42:07 -0400

Sandy & Chris,

I believe Chris' declaration is premature.

I anticipate that Dr. Ma may want to take over slurm, with David's 
permission.

With a few minor tweaks the use cases doc can be done.

Steve

---

From: Chris Morrow <[email-masked]>
Date: Thu, 21 Jul 2016 23:20:02 +0100

At Thu, 21 Jul 2016 13:42:07 -0400,
> With a few minor tweaks the use cases doc can be done.

ok, let's put some dates around the 2 items then:
  1) use-cases - decide on tweaks & rev-document: Aug 1
                 review and WGLC  Aug 14
                 send to IESG Sept 1

  2) Get hand-over on SLURM - Aug 1
                 New revision Aug 14
                 Discussion and next steps Sept 1

Propose alternate dates, 'no-date' is not valid as an answer... we
need to march toward conclusion.

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Jul 2016 09:16:31 +0200

>   1) use-cases - decide on tweaks & rev-document: Aug 1

do we have a concise issue list (other than steve not liking the style
used)?  not sure i will make the 1 aug dreadline if i have to sift
through the mailing list, whine, whine, whine.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Jul 2016 08:21:23 +0100

> through the mailing list, whine, whine, whine.
My hope is that steve can (or was already going to) respond with
issues-list, so we can move along.
I presume, since he stated the issue list was short he had it on
top-of-mind :)

Steve, is there a list you were working from? could you either:
  1) send to list
  2) send to co-authors
  3) send to chairs for distribution

thanks!
-chris

---

From: Declan Ma <[email-masked]>
Date: Fri, 22 Jul 2016 11:48:58 +0200

Sandy & Chris,

Thank Steve for recommending me to take over SLURM. 

With David’s permission, I would be happy to assume responsibility for SLURM.

I think SLURM is quite important to RPKI operation in term of local network. 

SLURM provides a simple way to enable INR holders to establish a local, customized view of the RPKI, by overriding RPKI repository data if needed.

In particular, I was exchanging notes with David earlier on the use of multiple SLURM files among others, which I believe is worth more text in the next version of SLURM.

Di

> 在 2016年7月21日，19:42，Stephen Kent <[email-masked]> 写道：
> 
> Sandy & Chris,
> 
> I anticipate that Dr. Ma may want to take over slurm, with David's permission.
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Jul 2016 11:48:30 -0400

Chris,

Here is my message to the SIDR list from 6/16:

    I read the latest version of this document and have a few comments,
    some of which I have made before, to no avail ;-).

    I still find the wording of the three examples in Section 4 to be
    unnecessarily informal. I’ve provided suggested text for previous
    versions of this document that probably is still applicable, since
    the examples do not seem to have changed much. It seems preferable
    to describe the first motivating case without reference to a
    specific RIR. (Including a parenthetical note about the historical
    precedent of a Dutch court order involving RIPE is relevant and
    might be included.) There is language in the adverse actions
    document that could be used here to be more formal, less folksy.
    Since adverse actions is now a Wg document, one might even cite
    sections of it to support the examples. In the second example, the
    term “borrowed” is not defined. I think I know what is implied, and
    it seems inappropriate to possibly condone advertisement of address
    space allocated to another party, just because that party is not
    advertising the space to the global Internet. Why not just stick
    with private address space in this example? The third example is a
    six-line, run-on sentence, so it’s not easy for a reader to be
    certain what the example really implies.

    The Notes section (5) seems to offer an analysis of requirement for
    potential solutions to address the use cases. Maybe a better section
    title is warranted.

    David’s SLURM document describes a mechanism that seems to address
    the local, customized view requirements described in Section 4.
    (David says that it addresses the second and maybe third uses cases,
    but I think he was modest in his assertion.) SLURM could support the
    first use case, if the community decided on a mechanism to
    distribute SLURM files in response to a CA being compelled to modify
    RPKI data. (It would be easy to ad a digital signature to the files,
    to provide authentication and integrity, but the there’s the little
    issue of key management and a suitable trust model …) The design
    accommodates merging of multiple SLURM files, meeting that
    requirement as stated in this section. Note that SLURM does not
    require modifying ROAs or GB records. It is a post-processing
    mechanism using “local” configuration data that overrides the global
    data acquired from the RPKI. This suggests that some of the comments
    in Section 5 are not accurate, e.g., ones that allude to the
    problems posed by not having keys to sign ROAs, etc. Although there
    is a need to achieve the effect of modifying, creating and/or
    replacing ROAs and GB records, that effect does not have to involve
    signatures on the affected data, as suggested in the first and third
    paragraphs of Section 5.

    Typos:

    … to be a formally formally defined set … (repeated word)

    … 'recipes' should be mergable (mergeable?)

    The Security Considerations text seems unduly negative. The approach
    being proposed here is not violating global security, because the
    results are intended to be local. How about the following wording:

    The use cases described in Section 4, and the notes for suggested
    solution approaches in Section 5, are not intended to undermine the
    security provided by the RPKI. Rather they identify potential
    obstacles to widespread adoption of the RPKI, and suggest changes
    that would enable network operators to generate custom “views” of
    the RPKI for use on a local basis. Providing the ability to create
    local RPKI views does not adversely affect global routing security.

---

From: David Mandelberg <[email-masked]>
Date: Sat, 23 Jul 2016 19:58:32 -0400

Di, enjoy. You have my permission to take over SLURM. Let me know if
there's anything I can do to help.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Chris Morrow <[email-masked]>
Date: Sun, 24 Jul 2016 18:24:45 +0100

At Fri, 22 Jul 2016 11:48:30 -0400,
Stephen Kent <[email-masked]> wrote:
> 
> [1  <text/plain; utf-8 (8bit)>]
> Chris,
> 

great, thanks!

> [2  <text/html; utf-8 (8bit)>]
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 28 Jul 2016 14:36:40 +0200

Hi all,

I believe SLURM is useful work.

I know that RPSTIR has an implementation, but the RIPE NCC RPKI Validator (yes, we need a cool name..) has been implementing the same semantics for a long time (years) - using a different format. I do not know whether rcynic has implemented similar. Rob?

Two implementation have implemented similar behaviour independently. In any case I think there is benefit in having a common format and semantics defined, and I supported adoption.

But.. I do have concerns and questions about the *current* format defined in the document. It represents the RPSTIR implementation. I have been meaning to discuss and comment as an RP implementor but unfortunately have not been able to do so, due to other priorities. Going forward I appreciate that Declan Ma volunteers to take on the work as author, but I think it would be best to have author representatives of each of the three RPs to ensure that the resulting configuration file and semantics are understood by all and feasible to implement by all.

In short I would like to volunteer to co-author and would kindly ask Rob if he would be willing. I have no problems with moving this to sidr-ops and having the discussion on content then and there.

Tim

> On 24 Jul 2016, at 01:58, David Mandelberg <[email-masked]> wrote:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 28 Jul 2016 16:32:10 +0200

Hi,

> On 22 Jul 2016, at 17:48, Stephen Kent <[email-masked]> wrote:
> 
> It seems preferable to describe the first motivating case without reference to a specific RIR.

Although I appreciate that Randy is trying to explain the case in terms anyone can understand, it would be preferable to keep it general.

> (Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.)

If there was such a precedent, but there isn't. I have raised this before, but again...

The incident you refer to is in fact a case where the FBI asked the Dutch police to enforce an order issued by a US court, which would demand that the RIPE NCC take all measures to ensure that the suspect’s IP address registration was not transferred or amended.

And while the RIPE NCC initially carried out this order (to freeze, not remove/modify etc) it also immediately sought legal advice, and following that advice it was concluded that there was no legal basis for the order.

So, as far as precedents go, this is a different case altogether (freeze contact information, not remove/modify routing information), and actually points in the opposite direction.

More details here:
https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/summons-of-the-ripe-ncc-against-the-state-of-the-netherlands

Tim

---

From: Declan Ma <[email-masked]>
Date: Thu, 28 Jul 2016 23:03:53 +0800

> 在 2016年7月28日，22:32，Tim Bruijnzeels <[email-masked]> 写道：
> 
> Hi,
> 

And adverse actions I-D offers expressions to support the example. Sections of it might be cited as well. 

Di