Subject: Re: [sidr] Current document status && directionz

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Oct 2016 11:35:24 -0400

Restarting this thread, with some updates :)

Preparing for Seoul in a few weeks time, with the intent that we do not
meet face-to-face in Chicago, have all current 'protocol' related docs to
the IESG/done and meet instead in sidr-ops if there are agenda items at
that time :)

Currently we have the following in IESG/pub-request status (13 documents):
draft-ietf-sidr-adverse-actions
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-publication
draft-ietf-sidr-rpki-oob-setup
draft-ietf-sidr-rpki-rtr-rfc6810-bis
draft-ietf-sidr-delta-protocol (10/26 sent forward)
draft-ietf-sidr-rpki-validation-reconsidered (10/26 sent forward)

Currently still active documents (8 documents):
draft-ietf-sidr-bgpsec-rollover
draft-ietf-sidr-lta-use-cases
draft-ietf-sidr-route-server-rpki-light
draft-ietf-sidr-rpki-tree-validation
draft-ietf-sidr-rpki-validation-reconsidered
draft-ietf-sidr-rtr-keying
draft-ietf-sidr-slurm

(this reflects the changes since the last email, included below)

I believe we're still planning to move (and have agreement from authors):
 draft-ietf-sidr-bgpsec-rollover
 draft-ietf-sidr-lta-use-cases
 draft-ietf-sidr-route-server-rpki-light
 draft-ietf-sidr-rtr-keying

which leaves to be dealt with by Chicago 2 documents:
draft-ietf-sidr-rpki-tree-validation
draft-ietf-sidr-slurm

I think this is good, I believe (and of course I should be corrected if
wrong)
  slurm - more work inbound and discussion planned in Seoul
  tree-validation - I thought moved to sidr-ops, but don't have docs to
back that up.

-chris

On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow <[email-masked]> wrote:

>
> 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
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Oct 2016 12:18:12 +0900

> draft-ietf-sidr-rpki-validation-reconsidered (10/26 sent forward)

an interesting view on progress of these documents is visible in
https://datatracker.ietf.org/doc/ad/alvaro.retana/

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Oct 2016 23:35:07 -0400

> https://datatracker.ietf.org/doc/ad/alvaro.retana/

yes, the chairs posed the question: "Err, did we sink your battleship with
too many docks?" to alvaro, he's still using his snorkel to swim out of the
trench... he'll get there  he says :)

(and basically we did our job pushing documents forward and working through
the discussions.... 'we' here == 'working-group' not 'me'  Thanks to the WG
folk for doing some hard work and focusing)

-chris

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Oct 2016 12:37:36 +0900

> yes, the chairs posed the question: "Err, did we sink your battleship
> with too many docks?" to alvaro, he's still using his snorkel to swim
> out of the trench... he'll get there he says :)

it would seem desirable to get them through the iesg before closing sidr
and transitioning to sidrops.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 31 Oct 2016 16:15:54 +0100

Hi all,

> On 26 Oct 2016, at 17:35, Christopher Morrow <[email-masked]> wrote:
> 

You may have just seen the -03 version posted.

This version now includes a scope section to make it clear that:

   This document describes how the RIPE NCC RPKI Validator version 2.23
   has been implemented.  Source code to this software can be found
   here: [github].  The purpose of this document is to provide
   transparency to users of (and contributors to) this software tool, as
   well as serve to be subjected to scrutiny by the SIDR Working Group.
   It is not intended as a document that describes a standard or best
   practices on how validation should be done in general.

The full name of the document "RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator" was always clear on the scope. And we mentioned it at various occasions. The short name "RPKI Tree Validation" may be somewhat confusing - we are open to suggestions btw.. plus, if the IETF (SIDR-OPS most likely) wants to take on the work of making a general validation document, we would be happy to contribute to it in separate document.

We really value the feedback that we got from the working on this document. Although not all feedback is reflected in the current implementation (and therefore in the main body of the document) - we have included these discussions in the Security Considerations section. We believe that none of these issues qualify as showstoppers to the software described at this time, but we may well address them in future releases.

There was some discussion at the last IETF about how to deal with a document like this. It describes a moving target. Our implementation is subject to change after all.

We prefer to tackle it by going for last call on this document describing version 2.23 as soon as is allowed by IETF, in the SIDR WG. As far as we are concerned this is done. Of course if there is any remaining unclarity we will address.

If and when future releases of our software include significant changes in the validation algorithm, we plan to document transparently. Pragmatically speaking we believe that minor things can be documented in the README of future releases (.. works like RFC-### with these exceptions). For bigger changes however, or whenever our code stabilises again, we would probably seek to either update the existing document, or create a new document. We would prefer to run any such work through SIDR-OPS once established, but individual submission is also an option.

In the end what matters to us most is that we have a clear description of how the code works, and provide full transparency on considerations.

Kind regards

Tim & Oleg