[Anima] WARREN: PLS reply: another fix to BRSKI in RFC editor queue.

Toerless Eckert <tte@cs.fau.de> Tue, 10 November 2020 15:49 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 064FB3A07CE for <anima@ietfa.amsl.com>; Tue, 10 Nov 2020 07:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.868
X-Spam-Level:
X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 jqYv40a5C92e for <anima@ietfa.amsl.com>; Tue, 10 Nov 2020 07:49:52 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7E63A07C3 for <anima@ietf.org>; Tue, 10 Nov 2020 07:49:52 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 85C9D548019; Tue, 10 Nov 2020 16:49:46 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7E26D440059; Tue, 10 Nov 2020 16:49:46 +0100 (CET)
Date: Tue, 10 Nov 2020 16:49:46 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: warren@kumari.net
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>
Message-ID: <20201110154946.GA32717@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/RDklJbTRLR1KPzqj9pBusT0yGbg>
Subject: [Anima] WARREN: PLS reply: another fix to BRSKI in RFC editor queue.
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: Tue, 10 Nov 2020 15:49:55 -0000

Warren:

MichalR would like to push a a draft-ietf-bootstrap-remote-keyinfra-45 update
to datatracker because we missed out IANA request text for the GRASP objectives
used by BRSKI. This only makes sense when you will then immediately approve
the update, and we can accordingly trigger IANA to add the registry entries.

Otherwise we would AFAIK have just an extended discuss later on towards AUTH48.

Target Diff here:
  https://github.com/anima-wg/anima-bootstrap/commit/622ab481b84c55782d0e0fbe5d3526063c5dbc9c

Please advise if / how to go ahead with this (e.g.: upload after embargo lift,
then you will approve ?)

Cheers
    Toerless

On Fri, Nov 06, 2020 at 10:12:10PM -0500, Michael Richardson wrote:
> 
> Toerless Eckert <tte@cs.fau.de> wrote:
>     > Kiding aside: Who needs to take which action now ?
> 
> I think that Warren needs to approve this update.
> 1) He could green-light an update/upload to the DT despite the embargo.
> 2) Probably needs to tell the RFC-editor that this change is approved.
> 3) Notify IANA that we missed an instruction.
> 
> If the RPC has already started editing the document (crossed fingers for
> yes), then the diff will be more valuable to them than an updated XML.
> 
> The lone diff is at:
> 
> https://github.com/anima-wg/anima-bootstrap/commit/622ab481b84c55782d0e0fbe5d3526063c5dbc9c
> 
>     > On Fri, Nov 06, 2020 at 04:15:21PM -0500, Michael Richardson wrote:
>     >>
>     >> Toerless Eckert <tte@cs.fau.de> wrote:
>     >> > Am i completeley confused, or did we miss until now the IANA request in BRSKI for
>     >> > the new entries AN_Proxy and AN_join_registrar ?
>     >>
>     >> I dunno what happened.
>     >> But, you are exactly right.
>     >> Who to blame? when in doubt? clearly, BLAME CANADA.
>     >>
>     >> It wasn't until my third reading of:
>     >> grasp-15, section 6, https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-15#section-6
>     >>
>     >> that I saw that GRASP actually does create a _GRASP Objective Names Tables_.
>     >> I was going to complain that there was no registry created, but it just
>     >> didn't have it's own heading:
>     >>
>     >> GRASP Objective Names Table.  The values in this table are UTF-8
>     >> strings which MUST NOT include a colon (":"), according to
>     >> Section 2.10.1.  Future values MUST be assigned using the
>     >> Specification Required policy defined by [RFC8126].
>     >>
>     >> To assist expert review of a new objective, the specification should
>     >> include a precise description of the format of the new objective,
>     >> with sufficient explanation of its semantics to allow independent
>     >> implementations.  See Section 2.10.3 for more details.  If the new
>     >> objective is similar in name or purpose to a previously registered
>     >> objective, the specification should explain why a new objective is
>     >> justified.
>     >>
>     >> > I was just checking IANA actions for ACP and did not see these two in the GRASP
>     >> > registry:
>     >>
>     >> > https://www.ietf.org/archive/id/draft-ietf-anima-bootstrapping-keyinfra-44.txt
>     >>
>     >> > Not sure about the process, e.g.: if "specification required" (GRASP registry)
>     >> > mandates the IANA text in the BRSKI RFC... I fear it does ? If three is an easier
>     >> > way as having Warren approve another rev... ?
>     >>
>     >> I think that the text has to go in.
>     >> Warren needs to approve the change, and IANA needs to review, and then the
>     >> text needs to go in now or at AUTH48, depending upon where the RPC really is.
>     >>
>     >> I have version -45 ready to post, diffs are at:
>     >>
>     >> I think that this is non-constroversial, does not require a WG LC, and can
>     >> slide in at AUTH48, but as it required IANA review, it's better if it happens
>     >> sooner.
>     >>
>     >> It looks like the YANG is now 2-3 characters too long in places, so I've also
>     >> rewrapped that.  The base64 in the examples will also need to be reflowed
>     >> ick.
>     >>
>     >> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-44&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/master/dtbootstrap-anima-keyinfra.txt
>     >>
>     >> --
>     >> ]               Never tell me the odds!                 | ipv6 mesh networks [
>     >> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>     >> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>     >> Sandelman Software Works Inc, Ottawa and Worldwide
>     >>
>     >>
>     >>
>     >>
> 
> 
> 
>     > --
>     > ---
>     > tte@cs.fau.de
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
tte@cs.fau.de