Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr

Kent Watsen <kent+ietf@watsen.net> Fri, 07 August 2020 21:02 UTC

Return-Path: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@amazonses.watsen.net>
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 272873A0AB6 for <netconf@ietfa.amsl.com>; Fri, 7 Aug 2020 14:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 u9y6cFmrwt-8 for <netconf@ietfa.amsl.com>; Fri, 7 Aug 2020 14:02:02 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4B93A0AB0 for <netconf@ietf.org>; Fri, 7 Aug 2020 14:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596834121; h=From:Message-Id:Content-Type:Mime-Version:Date:Subject:In-Reply-To:To:References:Feedback-ID; bh=nXbAiI00+XMwUrtuAwu/KDMWQbh+BoEQvafo0PwiSO0=; b=WCl1pGwR77iJZ5vGn/rezJU3JqVFRd6irgawS3w2y43+fuYxI035mRQAcvd0rJob xIw2MQk2oq37H1wTv4j8ss45coX9KRgrLlGBADyPH0qtPySgAbTJpbj0uVk0UUs08yW SHi1iNJBfQ/MGAGVuOW0kw6J+Exs3Cbw9aKXNi0Q=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_06E2940F-2F20-481D-B790-D43F485694BA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 7 Aug 2020 21:02:01 +0000
In-Reply-To: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com>
To: "netconf@ietf.org" <netconf@ietf.org>
References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.08.07-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ZI8GtKuKQTGVC-6w0mDIrIgyPmw>
Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr
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: Fri, 07 Aug 2020 21:02:04 -0000

[as a contributor and co-author]


Per the request below:

1) is the problem important for the NETCONF WG to solve?

I believe that it is important to enable the SZTP bootstrapping process to be able to configure an LDevID certificate.  As the presentation mentioned, it is the ONLY way to enable use cases whereby the device must join a dynamically-provisioned network slice.  The ability to do this was requested by a 3rd-party (my co-authors may have more to say about this).

And I believe that the NETCONF WG is the appropriate WG for this work, having defined RFC 8572 (SZTP).


2) is the draft a suitable basis for the work?

I believe the current version of the draft is a more than a reasonable start.  I would say that it's practically ready for Last Call (all sections were filled in), but I’m aware that my co-authors believe that one or two more CSR-types should be added to reflect real-world CA deployments.


3) regarding Juergen’s questions:

  a) I am willing to substantially review the drafts.
  b) I am willing to contribute to the discussion of any issue.
  c) I plan to implement the technology defined.


Kent


> NETCONF WG,
> 
> Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:
> 
>    Title: Conveying a CSR in an SZTP Bootstrapping Request
>    Link: https://tools.ietf.org/html/ <https://tools.ietf.org/html/>draft-kwatsen-netconf-sztp-csr
>    Abstract:
> 
>       This draft extends the "get-bootstrapping-data" RPC defined in
>       RFC 8572 to include an optional certificate signing request (CSR),
>       enabling a bootstrapping device to additionally obtain an identity
>       certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
>       "onboarding information" response provided in the RPC-reply.
> 
> 
> In particular, please discuss adoption-suitability as it regards to the following questions:
> 
>     1) is the problem important for the NETCONF WG to solve?
>     2) is the draft a suitable basis for the work?
> 
> 
> PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.
> 
> NETCONF Chairs
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf