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

Kent Watsen <kent+ietf@watsen.net> Tue, 29 June 2021 20:49 UTC

Return-Path: <0100017a59889ad9-f6e6f999-bc15-437e-b802-18e11330e81b-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 F39AF3A098D; Tue, 29 Jun 2021 13:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 BUWVHmfxi38M; Tue, 29 Jun 2021 13:49:24 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C84B3A0991; Tue, 29 Jun 2021 13:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1624999762; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=UwbNk82y4kPCHDbos/2ykhnDVJ/njO5b6gf7KNfKAXk=; b=QIiDciMO3TqZkIhTWNG6RYdZwLHsffWMwtYaN40s23l/NY0HkmE1ynh9VwtVQUnZ 3Qf5k6Ephh1kZCiwT8o6qq2Jh7k5UCDsQ2UCNEhUst9uubIJOtVL+NXfgoqn6gEu9rv rMW7+1GR4UbkzjOUk6C279RWxsLdFh56cQjq1Hyw=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100017a59889ad9-f6e6f999-bc15-437e-b802-18e11330e81b-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_191A7E7D-A4BF-4904-AE22-A83EA92124C3"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 29 Jun 2021 20:49:22 +0000
In-Reply-To: <DM4PR11MB543824369BA6920C7FA67BDEB50A9@DM4PR11MB5438.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-sztp-csr@ietf.org" <draft-ietf-netconf-sztp-csr@ietf.org>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <DM4PR11MB543889219C08694C147C6DA4B50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a2f082e6a-1197e3c8-f8be-4d59-ba1c-8d39029a31fc-000000@email.amazonses.com> <DM4PR11MB543824369BA6920C7FA67BDEB50A9@DM4PR11MB5438.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.06.29-54.240.48.94
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/osFlO1xTjejY-uKCIBpM3RxUsyc>
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: Tue, 29 Jun 2021 20:49:26 -0000

Hi Rob,

Since been spinning on the below thread since we had it and am wondering if if would be best to ask for an HTTP expert review?   Please advise.

The reason being is that a close reading of "300 Multiple Choices" suggests that it’s used by an HTTP-server to indicate when there are multiple choices for a resource, whereas in this exchange, the “csr-support” node in the client’s POST effectively indicates that *it* has multiple choices for the server to choose from…

I’m beginning to wonder to the document might need to define a custom HTTP status code to properly indicate the semantics of the response…

Kent // contributor



>>> 2. Section 2.2:
>>>  Assuming the SZTP-server wishes to prompt the SZTP-client to provide
>>>  a CSR, then it would respond with an HTTP 400 (Bad Request) error
>>>  code:
>>> 
>>> I wonder whether returning a 400 "Bad Request" error is really the best
>> return code, i.e.,
>>> it wasn't clear to me whether this requesting the capabiltiies is really an
>> error.
>>> Did you consider potentially using other return codes?  Possibly:
>>> 300 Multiple Choices,
>>> 403 Fobidden,
>>> 406 Not Acceptable
>> 
>> I did before look at all the 4xx codes.  I was initially drawn to 412
>> Precondition Failed, but noted that it is specific to HTTP request header
>> fields.   As for the others you mention, the semantics of 403 Forbidden is that
>> the request should not be repeated, which isn’t out case, and 406 Not
>> Acceptable regards the use of the HTTP “Accept” headers, which aren't in
>> play here either.  That said, 300 Multiple Choices does appear to be a better
>> if not perfect option, so I made that change in my local copy.
>> 
> Ack.