Re: [sidr] Current document status && directionz

[Randy Bush]

 draft-ietf-sidr-rtr-keying
>> i thought this was done
> this one maybe done, but has not hit WGLC. we can do that here, or
> there...  I'm agnostic at this point.

this is protocol, not ops

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Dec 1, 2016 at 1:51 AM, Declan Ma  wrote:

> Chris,
>
> I would like to take this thread to request for comments on how to move on
> SLURM.
>
> During the Seoul meeting, Tim suggested moving it to SIDROPS since SIDR is
> being closed.
>
> Yet I had the impression that the AD hopes keeping the list/structure
> going until current work items are done.
>
> Considering the only issue facing SLURM is the file format that Tim and
> Rudiger mentioned in the MIC, IMHO, if this WG won’t plan to move SLURM to
> SIDROPS, WGLC is desirable to bring about inputs and comments to conclude
> this work.
>
>
if we're just haggling on format... then let's try to finish here?
How about we give it until ~monday for comments here, then start WGLC if no
comments/movement?


>
> Di
>
>
> > 在 2016年12月1日，02:33，Christopher Morrow  写道：
> >
> > And again, restarting... post meeting and post travel refocusing :)
> >
> > On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
> > 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-delta-protocol (10/26 sent forward)
> >
> > draft-ietf-sidr-origin-validation-signaling
> > draft-ietf-sidr-publication
> > draft-ietf-sidr-rpki-oob-setup
> > draft-ietf-sidr-rpki-rtr-rfc6810-bis
> >
> >
> > I had thought I sent validation-reconsidered forward for processing, I'm
> doing that today:
> > draft-ietf-sidr-rpki-validation-reconsidered
> >
> >  Currently still active documents (6 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-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
> >
> > draft-ietf-sidr-rpki-tree-validation
> >
> > which leaves to be dealt with by Chicago 2 documents:
> > 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.
> >
> >
> > I still think this is good, I will be sending a request to the OPS-AD
> folk today to move:
> >  draft-ietf-sidr-bgpsec-rollover
> >  draft-ietf-sidr-lta-use-cases
> >  draft-ietf-sidr-route-server-rpki-light
> >  draft-ietf-sidr-rtr-keying
> >  draft-ietf-sidr-rpki-tree-validation
> >
> > to sidr-ops... If there are corrections/additions please send them along
> :)
> >
> > -chris
> >
> > -chris
> >
> > On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow 
> 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 

Re: [sidr] Current document status && directionz

[Declan Ma]

Chris,

I would like to take this thread to request for comments on how to move on 
SLURM.

During the Seoul meeting, Tim suggested moving it to SIDROPS since SIDR is 
being closed. 

Yet I had the impression that the AD hopes keeping the list/structure going 
until current work items are done. 

Considering the only issue facing SLURM is the file format that Tim and Rudiger 
mentioned in the MIC, IMHO, if this WG won’t plan to move SLURM to SIDROPS, 
WGLC is desirable to bring about inputs and comments to conclude this work.


Di 


> 在 2016年12月1日，02:33，Christopher Morrow  写道：
> 
> And again, restarting... post meeting and post travel refocusing :)
> 
> On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow 
>  wrote:
> 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-delta-protocol (10/26 sent forward)
>  
> draft-ietf-sidr-origin-validation-signaling
> draft-ietf-sidr-publication
> draft-ietf-sidr-rpki-oob-setup
> draft-ietf-sidr-rpki-rtr-rfc6810-bis
> 
> 
> I had thought I sent validation-reconsidered forward for processing, I'm 
> doing that today:
> draft-ietf-sidr-rpki-validation-reconsidered
> 
>  Currently still active documents (6 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-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
>  
> draft-ietf-sidr-rpki-tree-validation
>  
> which leaves to be dealt with by Chicago 2 documents:
> 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.
> 
> 
> I still think this is good, I will be sending a request to the OPS-AD folk 
> today to move:
>  draft-ietf-sidr-bgpsec-rollover
>  draft-ietf-sidr-lta-use-cases
>  draft-ietf-sidr-route-server-rpki-light
>  draft-ietf-sidr-rtr-keying
>  draft-ietf-sidr-rpki-tree-validation
> 
> to sidr-ops... If there are corrections/additions please send them along :)
> 
> -chris
>  
> -chris
> 
> On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow  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 

Re: [sidr] Current document status && directionz

[Randy Bush]

>> draft-ietf-sidr-bgpsec-ops

waiting to rev when iesg and whomever reviews are in.  if someone wants
an earlier push, shout.

>> draft-ietf-sidr-lta-use-cases

i thought this was post last call

>> draft-ietf-sidr-rtr-keying

i thought this was done

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

And again, restarting... post meeting and post travel refocusing :)

On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> 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-delta-protocol (10/26 sent forward)


> draft-ietf-sidr-origin-validation-signaling
> draft-ietf-sidr-publication
> draft-ietf-sidr-rpki-oob-setup
> draft-ietf-sidr-rpki-rtr-rfc6810-bis
>


I had thought I sent validation-reconsidered forward for processing, I'm
doing that today:

> draft-ietf-sidr-rpki-validation-reconsidered
>

 Currently still active documents (6 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-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
>

draft-ietf-sidr-rpki-tree-validation


> which leaves to be dealt with by Chicago 2 documents:
> 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.
>
>
I still think this is good, I will be sending a request to the OPS-AD folk
today to move:
 draft-ietf-sidr-bgpsec-rollover
 draft-ietf-sidr-lta-use-cases
 draft-ietf-sidr-route-server-rpki-light
 draft-ietf-sidr-rtr-keying
 draft-ietf-sidr-rpki-tree-validation

to sidr-ops... If there are corrections/additions please send them along :)

-chris


> -chris
>
> On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow 
> 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
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Tim Bruijnzeels]

Hi all,

> On 26 Oct 2016, at 17:35, Christopher Morrow  wrote:
> 
> which leaves to be dealt with by Chicago 2 documents:
> draft-ietf-sidr-rpki-tree-validation

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







___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

> 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Oct 26, 2016 at 11:18 PM, Randy Bush  wrote:

> > 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)
>
> an interesting view on progress of these documents is visible in
> 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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

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

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

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

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  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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Sandra Murphy]

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




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

> 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

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

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

i hereby ask

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Sep 8, 2016 at 1:47 PM, David Conrad  wrote:

> Chris,
>
> 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
>
> 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?


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

excellent, thanks for the clarifications.
-chris


> 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.
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[David Conrad]

Chris,

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



signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[David Conrad]

Chris,

On September 7, 2016 at 4:42:21 AM, Christopher Morrow 
(morrowc.li...@gmail.com) 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



signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Sep 8, 2016 at 9:32 AM, Heasley  wrote:

>
>
> Am 08.09.2016 um 00:42 schrieb Randy Bush :
>
> >> 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."
>
> 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."




> >
> > the iab did that and got a written agreement that the rirs would do so.
> > 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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Heasley]

Am 08.09.2016 um 00:42 schrieb Randy Bush :

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

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. 

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


> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

> 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Roque Gagliano (rogaglia)]

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"  wrote:

>At Sat, 3 Sep 2016 14:06:25 -0700,
>joel jaeggli  wrote:
>> 
>> [1 Re: Current document status && directionz ]
>> [1.1  ]
>> On 9/2/16 1:56 PM, Chris Morrow 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
>> 
>> 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.
>> 
>
>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.
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Roque Gagliano (rogaglia)]

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
Tail-f Solutions Architect Southern Europe
+41 76 449 8867


From: sidr <sidr-boun...@ietf.org<mailto:sidr-boun...@ietf.org>> on behalf of 
Andrew de la Haye <andr...@ripe.net<mailto:andr...@ripe.net>>
Date: Wednesday 7 September 2016 at 16:55
To: Christopher Morrow <morrowc.li...@gmail.com<mailto:morrowc.li...@gmail.com>>
Cc: "sidr@ietf.org<mailto:sidr@ietf.org>" <sidr@ietf.org<mailto:sidr@ietf.org>>
Subject: Re: [sidr] Current document status && directionz


On 07 Sep 2016, at 16:42, Christopher Morrow 
<morrowc.li...@gmail.com<mailto:morrowc.li...@gmail.com>> wrote:



On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein 
<s...@hactrn.net<mailto:s...@hactrn.net>> wrote:
At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
>
> (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?"


totally agree/understand.

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

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


yes, sorry I was trying to not point fingers at particular people/things :(

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.


ok

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.


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?

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.


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



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

yup.


___
sidr mailing list
sidr@

Re: [sidr] Current document status && directionz

[Rob Austein]

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?
> what checks/balances are there?"

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.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye  wrote:

>
> On 07 Sep 2016, at 16:42, Christopher Morrow 
> wrote:
>
>
>
> On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein  wrote:
>
>> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
>> >
>> > (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?"
>>
>>
> totally agree/understand.
>
>
>> > 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)
>>
>> I'm ignoring "upstairs", because that is also political.
>>
>>
> yes, sorry I was trying to not point fingers at particular people/things :(
>
>
>> 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.
>>
>>
> ok
>
>
>> 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.
>>
>>
> 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?
>
>
>> 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.
>>
>>
> 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
>
>
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.


> Andrew
>
>
>
>
>> Which brings us back to bad technical decisions and political reasons.
>> Sorry.
>>
>
> yup.
>
>
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Andrew de la Haye]

> On 07 Sep 2016, at 16:42, Christopher Morrow  wrote:
> 
> 
> 
> On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein  > wrote:
> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
> >
> > (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?"
> 
> 
> totally agree/understand.
>  
> > 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)
> 
> I'm ignoring "upstairs", because that is also political.
> 
> 
> yes, sorry I was trying to not point fingers at particular people/things :(
>  
> 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.
> 
> 
> ok
>  
> 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.
> 
> 
> 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?
>  
> 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.
> 
> 
> 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 


>  
> Which brings us back to bad technical decisions and political reasons.
> Sorry.
> 
> yup.
>  
> 
> ___
> sidr mailing list
> sidr@ietf.org 
> https://www.ietf.org/mailman/listinfo/sidr 
> 
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr



smime.p7s
Description: S/MIME cryptographic signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein  wrote:

> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
> >
> > (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?"
>
>
totally agree/understand.


> > 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)
>
> I'm ignoring "upstairs", because that is also political.
>
>
yes, sorry I was trying to not point fingers at particular people/things :(


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


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


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

yup.


>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Randy Bush]

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

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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Rob Austein]

At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
> 
> (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?"

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

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.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Tue, Sep 6, 2016 at 6:00 PM, Rob Austein  wrote:

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


> 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.
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Rob Austein]

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.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Roque Gagliano (rogaglia)]

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"
 wrote:

>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.
>
>On 9/5/2016 3:32 PM, Carlos M. Martinez wrote:
>> 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:
>> 
>>>
>>> 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
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Chris Morrow]

At Sat, 3 Sep 2016 14:06:25 -0700,
joel jaeggli  wrote:
> 
> [1 Re: Current document status && directionz ]
> [1.1  ]
> On 9/2/16 1:56 PM, Chris Morrow 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
> 
> 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.
> 

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.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Chris Morrow]

At Mon, 5 Sep 2016 19:54:53 -0300,
"Carlos M. Martinez"  wrote:
> 
> 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.

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.

> 
> On 9/5/2016 3:32 PM, Carlos M. Martinez wrote:
> > 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:
> > 
> >>
> >> 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
> >> sidr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Carlos M. Martinez]

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.

On 9/5/2016 3:32 PM, Carlos M. Martinez wrote:
> 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:
> 
>>
>> 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
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Carlos M. Martinez]

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:



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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[joel jaeggli]

On 9/2/16 1:56 PM, Chris Morrow 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

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

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




signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Current document status && directionz

[Chris Morrow]

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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr