Re: [Anima] ANIMA: WG call for consensus BRSKI "endpoint path" modification (was: Re: Status of renaming endpoint path?)

[Toerless Eckert <[e-mail]>]

+1

As contributor i hereby state that i support the change:

The proposed change would allow to better decouple further evolution of EST without
BRSKI (not having to bothre about what BRSKI added when you do not use it), and vice versa.
For example Registrar/MASA being a pure BRSKI/Voucher channel would not be impacted by
EST legacy anymore.

The change could also help to simplify implementations, although it not clear to
me how big the simplifications would be. To the best of my (limited) implementation
experience, if EST and BRSKi where to be implemented separately, the URL routing
to those two implementations could be simpler, by routing all /.well-known/est 
URLs to BRSKI instead of having to enumerate the BRSKI URLs under /.well-known/est
explicitly.

To the best of my understanding, BRSKI implementations so far are still experimental,
so this change would not have a relevant negative impact on products.

I therefore can see no technical downside.

Thanks
    Toerless

On Tue, Sep 01, 2020 at 03:59:06AM +0200, Toerless Eckert wrote:
> Dear ANIMA WG
> 
> This email starts a 2 week call for consensus to modify draft-ietf-anima-bootstrapping-keyinfra
> such that new well-known URIs introduced by BRSKI will use a /.well-known/brski
> prefix instead of the pre-existing /.well-known/est prefix.
> 
> The proposed change can be seen at the following rfcdiff URL:
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-43&url2=draft-richardson-anima-brski-renamed-00
> 
> This consensus call will end on September 14, 23:59 UTC
> This consensus call is ONLY for said change and not for any other aspects of BRSKI.
> 
> If you have any objections to this change, please explain them by replying to
> this email during this period. If you agree with these changes please say so as well.
> 
> FYI: What would happen afterwards ?
> 
> a) If ANIMA does not have consensus, nothing more would happen, BRSKI would continue
>    stay unchanged in RFC editor queue waiting to be released by ACP draft 
> 
> b) If ANIMA WG has rough consensus on this change:
> 
> - Warren Kumari or Robert Wilton would start a 2 week IETF consensus call on the subject.
> - When not successful, see a)
> 
> -  When successful:
> 
> - BRSKI authors would rev' the BRSKI document with the proposed text change,
> - the responsible AD (Warren) would update the YES on the document
> - Mark Nottingham as the responsible expert for the impacted IANA registry would
>   have to agree on the proposed registry change (which according to prior emails
>   he seems to be)
> - IESG would approve the change, the rev'ed version of BRSKI would go into RFC Editor queue
> 
> According to Warrens prior emails (see below), this whole process should take ca. 5 weeks,
> which is shorter than the current queue length of RFC-editor, and that is still
> predicating that ACP draft is approved quickly by IESG (see below)
> 
> Hopefully i did no misrepresent any of the FYI steps.
> 
> Thank you very much
>     Toerless (for the ANIMA WG chairs).
> 
> P.S.: appended Warrens prior summary.
> 
> P.S.2.: Warren: I didn't send this mail earlier because from your writeup below it sounded
> as if my top priority should still be to work through 1922 lines of "this should be easy to fix"
> DISCUSS/COMMENTS from IESG against ACP to shorten the time BRSKI would have to wait in RFC
> editor queue - with or without this modification. But the increasing grouching level on
> the mailing list about this subject told me that this priorization was wrong. I apologize.
> 
> In-Reply-To: <[e-mail]>
> 
> On Mon, Aug 31, 2020 at 05:01:53PM -0400, Warren Kumari wrote:
> > Hi all,
> > 
> > Back in late July Steffan sent:
> > https://mailarchive.ietf.org/arch/msg/anima/jjusQdqzS3G4WbczolCxF0_YmQQ/
> > regarding renaming "Handling of endpoint path names (from BRSKI-AE
> > discussion today)".
> > 
> > Michael has a document ready to do this:
> > https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-43&url2=draft-richardson-anima-brski-renamed-00
> > 
> > Brian was concerned that this might add an unknown additional delay:
> > https://mailarchive.ietf.org/arch/msg/anima/3Ov2s8XxQ6pnQMp6PTd9_yDc-D0/
> > 
> > Luckily, if the WG does want to do this, we should be able to make it
> > happen without adding any delay (but we are running out of time...).
> > 
> > If the chairs kick off a consensus call, asking for objections **on
> > this change only**, then I can do a 2 week IETF LC, also asking for
> > objections **on this change only**.
> > 
> > I've already (mid-August) confirmed that the IESG is OK with this
> > process, so it would take [however long the Chairs choose to do the WG
> > consensus call for (1 week? 2 weeks?) ]  + [2 weeks IETF consensus
> > call] +[a few days of slop] = ~5 weeks...
> > 
> > This document is gated on (at least)
> > draft-ietf-anima-autonomic-control-plane (which will take some time to
> > wind its way through the RFC Ed process) so if this were to occur
> > soon, there would be no added delay...
> > 
> > Just FYI...
> > W
> > 
> > -- 
> > I don't think the execution is relevant when it was obviously a bad
> > idea in the first place.
> > This is like putting rabid weasels in your pants, and later expressing
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
> > 
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> 
> -- 
> ---
> [e-mail]
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]