Re: [Last-Call] [netconf] Yangdoctors last call review of draft-ietf-netconf-http-client-server-06

Kent Watsen <kent@watsen.net> Mon, 19 April 2021 22:23 UTC

Return-Path: <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-000000@amazonses.watsen.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316EF3A47AC; Mon, 19 Apr 2021 15:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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 PFJrbmey_Hpi; Mon, 19 Apr 2021 15:23:20 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C2C3A4724; Mon, 19 Apr 2021 15:23:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618870987; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=H3FmrSu+Ltv2VchDpsHx3vXZOzPWkinJM3eZeXMg+fs=; b=GGcLaH+liAAOdusH7HGVAfLx9uqlwPGxbRWhMNHxpzEKZ2WeO2udHnWGkR50XW8X Ns7smQ/mGMfqdyIgqODSaemfFLhpkn6QLZG7aWjapF5s3o7i/e7QGqGqe8uasSblKIC oNe7uWngS9gBn/s8s00KD0CYgLcSYAE8/6l5vEvA=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent@watsen.net>
In-Reply-To: <161821556350.10432.14910369341748800490@ietfa.amsl.com>
Date: Mon, 19 Apr 2021 22:23:07 +0000
Cc: YANG Doctors <yang-doctors@ietf.org>, last-call@ietf.org, "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-http-client-server.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-000000@email.amazonses.com>
References: <161821556350.10432.14910369341748800490@ietfa.amsl.com>
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.19-54.240.48.92
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/raxvuLJYclqJLg3OwjqepFGCdAk>
Subject: Re: [Last-Call] [netconf] Yangdoctors last call review of draft-ietf-netconf-http-client-server-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 22:23:25 -0000

Hi Lada,

Thank you for your review!

Below are responses to your comments.

K.

> On Apr 12, 2021, at 4:19 AM, Ladislav Lhotka via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Ladislav Lhotka
> Review result: Ready with Nits
> 
> The document defines two YANG modules - ietf-http-client and ietf-http-server -
> that belong to a relatively complex set of modules. The modules are well
> designed and nicely documented, both in the descriptions and document text.

 :)


> **** Comments
> 
> - Sections 2.1.3 and 3.1.3: the sentence 'The "..." module does not contain any
> protocol-accessible nodes.' is misleading in that the modules do define data
> nodes that are intended to be protocol accessible after the corresponding
> grouping is used. I know this is a part of the NETCONF/YANG lingo, but another
> formulation that clearly says what's going on might be preferable.

I fixed this when I addressed the same comment made in the “tcp-client-server” draft.



> - Sections 2.2 and 3.2: the XML snippets use document elements "http-client"
> and "http-server", but these containers are not defined in the corresponding
> modules. This is confusing, my suggestion is to rewrite the examples in the
> JSON representation where no such top-level node is necessary.

Same solution as for the “tcp-client-server” draft, which is to simply remove the first and last lines, for the non-existent “container” statement.

Update: I was going to proactively-apply the same solution to the “ssh” and “tls” drafts, but I couldn’t because the top-level element defines additional prefixes.  This is where your “JSON” idea could help, though, for some reason, having a mix of XML/JSON in the suite of drafts is off-putting to me.  We could convert all the examples to JSON, but that’s a fair amount of work too…  

How about adding an XML-comment indicating that the top-level element doesn’t really exist?


> - Placeholders BBBB, CCCC and EEEE are defined in Editorial Note but never used

Fixed.


> **** Nits
> 
> - RFC 7950 is cited repeatedly (4 times) in a general context, e.g. whenever
> YANG 1.1 is mentioned. It should suffice to use the citation at the first
> appearance.

Fixed.  Also in the “ssh” and “tls” drafts.


K.