Re: [netconf] AD review of draft-ietf-netconf-sztp-csr

Kent Watsen <kent+ietf@watsen.net> Mon, 28 June 2021 19:36 UTC

Return-Path: <0100017a541f840f-85559421-e84c-4bdf-8e3e-89299c35b756-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 916BF3A0BC1; Mon, 28 Jun 2021 12:36:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 m2r6wjBlj1qC; Mon, 28 Jun 2021 12:36:31 -0700 (PDT)
Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07AD3A0BEF; Mon, 28 Jun 2021 12:36:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1624908989; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=7KWAMACXAV0ksWXJ5TbVv+Kakjgq1dN9f8Jyd8w3vk4=; b=HfMp1AqC9Np5oalb5HqbmHLnKrdBKzXopUQfGpfUGMUQy3yl+IYaXNaIb6161Rc6 eSTGB7Uf0h2O6+/0ghQAUpwVgENx5SG8dXji7YIyJ4RUvRBmMoVqnF+cEleMQ1GKp4p TTxM1bHZpIgWs3BxeoZAWxq3Cy8ffbP31PsGFRQU=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <DM4PR11MB5438CA53561F81165429C3ABB5069@DM4PR11MB5438.namprd11.prod.outlook.com>
Date: Mon, 28 Jun 2021 19:36:29 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-sztp-csr@ietf.org" <draft-ietf-netconf-sztp-csr@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100017a541f840f-85559421-e84c-4bdf-8e3e-89299c35b756-000000@email.amazonses.com>
References: <DM4PR11MB543889219C08694C147C6DA4B50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a2f082e6a-1197e3c8-f8be-4d59-ba1c-8d39029a31fc-000000@email.amazonses.com> <DM4PR11MB543824369BA6920C7FA67BDEB50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a3ea111a8-680c5610-bc55-4a82-b7fd-7715656f4924-000000@email.amazonses.com> <DM4PR11MB54383EB098E3344A85A2DAA5B5079@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a3fcc223f-c6d25440-0346-4b41-9fa4-fad32b3e3b75-000000@email.amazonses.com> <DM4PR11MB5438CA53561F81165429C3ABB5069@DM4PR11MB5438.namprd11.prod.outlook.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.06.28-54.240.48.95
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/_h4GFEWDZxpVx6aYJVVaNTW_Bu0>
Subject: Re: [netconf] AD review of draft-ietf-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: Mon, 28 Jun 2021 19:36:40 -0000

Hi Rob,


> Hi Kent,
> 
> Thanks for the extra details/explanation.  Please see inline …

<snip>

 
> I hadn’t picked up on that nuance, and I agree that this makes an out of band approach less efficient and less helpful.

No problem.

 
> Not necessary.  I’m happy with your explanation as to why having it inband pragmatically makes more sense.

Okay.


 
> I still think we should put “csr-support” and “csr” under a "choice” though, as the use-case for sending both at the same time is very small and it seems wrong to encourage/suggest it’s a good idea or to ask servers to have to support the case.
> 
>  
> 
> Agreed.

Update made the to my local copy.  


> My understanding is more along these lines:

<big snip>

> I suspect that most RFCs today, handle the split between (1) and (2) in an adhoc way, by having the introduction describe briefly reference the docs that fit into (1).

Agreed, but it is not for now  ;)

I just move RFC 3688 to Normative (RFC 6020 was already Normative)


> PS: there’s a separate email thread (Reuse of SZTP-CSR YANG definition in BRSKI-AE) regarding this document that is pending your feedback.  Ideally I can collect that and thus apply all updates in one shot.
> 
> Sorry, I had missed this thread.  I’ve now replied.

I’ll post an update with both sets of changes. 

In the meanwhile, here's the Git commit: https://github.com/netconf-wg/sztp-csr/commit/1bb76e45163ec6a9d06657dcf689798e4409c712



> Thanks,
> Rob
> 

Cheers,
Kent