Re: [Anima] We want BRSKI and ACP!

Warren Kumari <warren@kumari.net> Wed, 11 March 2020 16:06 UTC

Return-Path: <warren@kumari.net>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A903A0B5C for <anima@ietfa.amsl.com>; Wed, 11 Mar 2020 09:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gyWT4_qptTB for <anima@ietfa.amsl.com>; Wed, 11 Mar 2020 09:06:33 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281493A0B6B for <anima@ietf.org>; Wed, 11 Mar 2020 09:06:32 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id 66so2518818otd.9 for <anima@ietf.org>; Wed, 11 Mar 2020 09:06:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0DTSFYnDEq/n5EHI0ifRJpf1Zx4L4OZZPQZ9Q6lvxi8=; b=RsqC+WtmJxk353fW71fpNEKqgU6//aCRJyCF2DA4DDlWqa8YqtkYGvIYJb+Kzkt0ov 6+8K6pgcaQyJBGrE3D9fp6PhF9iakoAY9x7LseLmvUqjB9v5iafwvDp0sA4Tg1DeUbeZ IOfX84ZhNOIYpWevpjck03Idpsp77QvSc8P+ayh8PA2OZsJgH4K45mJnUQAs0TELq7QZ m632Tx583ebAdFB/BuVwbduHfoBXfSJ/1KhtG8tijoiRw5AeBJVHZAsTBOpZiFA6RwY0 WIuVhc7mSwqnPeMl0gJhDmasYcs4hD8jIIgFh+wpN5m4tAhm8x21F4u4rdKqUjR0c2JI cc4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0DTSFYnDEq/n5EHI0ifRJpf1Zx4L4OZZPQZ9Q6lvxi8=; b=BtWDxVTPbzS5iGNpwKkVAlC08jvFCmSQq5rEFYszxT4YG0wVRIAUqoa2zCMoIWAEU2 cdUFKN8SVEdO0tUeh4EHY5lNfLcHZJMGC0eD0M904G+Z2dLaEGX73uRrSHO20L5nhRZG UFE0AWfPHf/rAFwWNtpdghPSg+9I4saqbD1h6MHkRCfVjYJTza2E/hP3CtS9N1ykYKjn LPjOL7WD+zGshC7MQ9TuOzFjDCJe96s02FcTDj07LT3b12sw/Ao9fDIGa2xBdjke10Vf QO7tunLWmG+piXnzPVVfOjr/LwFConSlUwyn09BnKnVCoyvUssqT8D19FnuJf8QKOUWB x/vw==
X-Gm-Message-State: ANhLgQ33L3olP1zprJ5yZnXeaTOorKa9JsvjhfFoF2/I0axG18XZ5Dg3 K3AZ3c/ROe3eEQSHSkrodkZfGdI5wZxwaaO8cazf2Q==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsuwcC/hhpW7fDHYGNfj/9T00CClE429Hy63hGh?= =?utf-8?q?E39RKhl8iCP+a4/fNUShlLscTObSX87QpnCDDfCv00XTKEo=3D?=
X-Received: by 2002:a9d:443:: with SMTP id 61mr2624317otc.357.1583942790494; Wed, 11 Mar 2020 09:06:30 -0700 (PDT)
MIME-Version: 1.0
References: <8e18470b-1d6a-19f1-efb2-bc2e72ef2665@gmail.com> <6011.1583935076@localhost>
In-Reply-To: <6011.1583935076@localhost>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 11 Mar 2020 12:05:53 -0400
Message-ID: <CAHw9_iKved_kSmL4yd_fgbLqxpGoO=PU4cycuo1Y3wiHGcuk+w@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Anima WG <anima@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uROT2CWZC9v3pBUb8asJvjq1vG0>
Subject: Re: [Anima] We want BRSKI and ACP!
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 16:06:36 -0000

[ + Benjamin ]

On Wed, Mar 11, 2020 at 9:58 AM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
>
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     > Could those on the hook for the ACP and BRSKI drafts, which have been
>     > very seriously delayed, update the WG with the plan for getting them
>     > approved? It seems to me that there has been endless nitpicking, of the
>     > kind that is appropriate for full Standard status, but very surprising
>     > for Proposed Standard where there is no expectation of perfection.
>
> I don't know what kind of plan I can relate: It seems to be above my pay grade.
>
> For BRSKI, since IETF106, all DISCUSSes, except Ben Kaduk's desire to have
> the examples redone have been cleared.


Yes, Alissa cleared on 2020-01-24.
Ben checked, and updated his DISCUSS on 2020-01-03, asking for the
examples to be updated. He then updated again on 2020-02-24 pointing
out errors.

> I had originally tagged redoing that
> for AUTH48 time, since all IANA allocations would be done by then.
> All allocations have been done at this point, and in January I redid the
> examples in the non-normative Appendix with the right OIDs.  Ben found some
> errors (one repeated certificate), and so I generated the examples again.

I would not classify Ben's DISCUSS as "endless nitpicking" - he
reviewed the changes, and updated on 2020-02-24 - here is the current
ballot:
"Thanks for the updated examples using the allocated MASA URL extension OID!

Unfortunately, I think there are still some inconsistencies in the
examples to resolve:

The MASA cert/key is identical to the "manufacturer key pair for IDevID
signatures" (C.1.1 and C.1.2).  (It shows the MASA Subject CN, so maybe
just the included file was typo'd?)  The example IDevID cert shows an
issuer name that doesn't match the cert given.
(Also the MASA cert doesn't have a randomized serial number but the
registrar one does.)

The registrar-to-MASA voucher request in C.2.2 seems to have a CMS
SignedData with the SignerIdentifier identifying the "Unstrung Fountain
Root" (i.e,. the root CA used for these examples) instead of the
expected "fountain-test.example.com".  Am I misreading the ASN.1 dump?
(We do seem to send both certificates.)

The voucher response from MASA to Registrar seems to be signed by the
"highway-test.example.com CA" (which would be the "manufacturer key pair
for IDevID signatures" that we don't have in the -35 since the MASA
certificate is repeated), not the MASA's cert from C.1.1."

The authors quickly updated the document and posted a new version on
2020-02-26 ( ~2 weeks ago). As you can guess, the past few weeks have
been busy - as well as discussions around cancelling (or not) IETF
107, there has been a big push to clear outgoing ADs documents, so
that there is a clean handoff to the incoming ADs.

I'm expecting Benjamin (who I have CCed) to review the changes again soon.


>
> I then asked Jim Schaad and Max Pritikin (a BRSKI co-author, who has been
> redirected on other important Cisco work), to validate.  Max reviewed, and
> this resulted in an additional clarifiying sentence committed to the github.
> (I thought I posted it on Monday, I don't seem to have. I will do that now.
>
> Warren Kumari has taken over as the sponsoring AD.

Indeed -- I took over from Ignas on 2020-01-27 (~ 1.5 months ago) --
since then, Alissa has cleared her DISCUSS, and the authors have
published 2 new versions (it is now at -37).
Ben had asked for some updates, and these have been folded in, and the
new issues should be reviewed soon.

Since IETF 106, there have been 6 new revisions of the document,
Benjamin has reviewed and updated his DISCUSS 3 times, Alissa has
cleared her DISCUSS (Roman cleared just before the meeting), and I see
~36 emails on the draft (some off-topic, and a number of off-list
pokings, etc).

So, yes, I understand that this is really frustrating, and I fully
agree that there have been many many delays that should not have
occurred - but, I think that there is now significant progress
happening...

W

>
>     > Can we expect these drafts to be approved in the next one or two weeks,
>     > for example? If not then, when?
>
> I know that ACP has gone through a similar set of DISCUSSes, and I think that
> they are mostly all done.
> I don't see an update from Ben.
>
> https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/
> says that most have No Objections, rather than Yes. Three YES are needed to
> override a DISCUSS.
> I guess this document has been in front of the IESG since 2018 when Terry was
> an AD!
>
> I think that the WG participants need to actively engage the DISCUSSes and
> the choices that the WG has made.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>


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