Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 23 June 2021 21:03 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE713A404D; Wed, 23 Jun 2021 14:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.875
X-Spam-Level: **
X-Spam-Status: No, score=2.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_SBL_CSS=3.335, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 4dQIzNI1gEBp; Wed, 23 Jun 2021 14:02:56 -0700 (PDT)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19B83A4053; Wed, 23 Jun 2021 14:02:54 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::146]) by relay.sandelman.ca (Postfix) with ESMTPS id 1BBBB1F455; Wed, 23 Jun 2021 21:02:53 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 31AED1A01E3; Wed, 23 Jun 2021 17:02:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>, "anima@ietf.org" <anima@ietf.org>
cc: "Fries, Steffen" <steffen.fries@siemens.com>, "Werner, Thomas" <thomas-werner@siemens.com>
In-reply-to: <0100017a2e9f69ee-5d037ce3-62dd-4825-922c-8a08b545d166-000000@email.amazonses.com>
References: <3a31e33678484625b9f4f3810e673e56@siemens.com> <0100017a1b4d2e94-aeaaa06e-8dc0-4163-a747-692e72b0d75c-000000@email.amazonses.com> <8407.1624138175@localhost> <0100017a2e9f69ee-5d037ce3-62dd-4825-922c-8a08b545d166-000000@email.amazonses.com>
Comments: In-reply-to Kent Watsen <kent+ietf@watsen.net> message dated "Mon, 21 Jun 2021 12:50:37 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 23 Jun 2021 17:02:52 -0400
Message-ID: <11325.1624482172@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/17_sDQjsfyo3OE__WchWy8kTXs8>
Subject: Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2021 21:03:01 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
    >> We really just want container csr-support, csr-generation, csr, ???
    >> 
    >> Maybe we could chat about this more.
    >> We have a regular Thursday 9:30 EST design team.
    >> 
    >>>> The alternative would be to define an own module modeled in a similar.
    >> 
    >>> You can do this.
    >> 
    >> I think that we can have some common mindshare here.

    > One option would be to move stuff into ietf-crypto-types…as that module
    > already defines a number of grouping statements for handy structures.
    > That said, these structures are not context-free…they are very much
    > entwined in a specific dialog that is rather specific to bootstrapping
    > processes.  [FWIW,  just adding “cmc” and “cmp" typedefs to
    > crypto-types, alongside the existing “csr” (e.g., “p10”) typedef, might
    > be a good thing]

Understood.

    > Another option would be to move stuff into grouping statements, in the
    > same module, that are immediately.  In theory this would have no impact
    > to the on-the-wire format.  However, it’s somewhat late in the process
    > to entertain this, as the draft is in the AD queue (AD-review was just
    > posted today) and no doubt we would dicker over how many groupings to
    > create and whether they should be put into another draft to whitewash
    > out the SZTP-stint.  Is it proper to reset a NETCONF publication for
    > another WG?  Rob?

If we can do this at this point, that would I think, be best for all of us.

If it's just at AD, then it hasn't gotten IESG reviews yet, and there could
be many weeks of back and forth yet to go.

The horse trading shouldn't take more than 30 minutes of real-time
discussion, maybe way less.  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [