Re: [Netconf] Shepherd review of draft-ietf-netconf-nmda-restconf

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 19 April 2018 03:33 UTC

Return-Path: <mjethanandani@gmail.com>
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 17AF5127369 for <netconf@ietfa.amsl.com>; Wed, 18 Apr 2018 20:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UAukWK7XaSaC for <netconf@ietfa.amsl.com>; Wed, 18 Apr 2018 20:33:18 -0700 (PDT)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97DB127867 for <netconf@ietf.org>; Wed, 18 Apr 2018 20:33:17 -0700 (PDT)
Received: by mail-pl0-x22e.google.com with SMTP id t22-v6so2371812plo.7 for <netconf@ietf.org>; Wed, 18 Apr 2018 20:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KonD9co+41btpWO4olX0GyFbM4GkzTedhR8yuiTWVrw=; b=LiJjmJv2G/afX8OkOS5Rf0Xw78jefpuI/cenJy0FRrCiRZIjjc8EMJ5bd9r6M6xdLC PIQXmX1uMI29f6F+ThAkz9nWpV7K/XFCMc38bunujMvAyPUKnXiK6nFoEn9/gP517swp Z+5XlFgh75jrZTNhLZ3VOzIoo2Si+f8L3VMQ8Gdz/E1OK/F60osiXeIL7VDLCm3RzMFa 6NF6DYTzgU3Qhkz1ivrIGUwKElPJmkmmpCyYYLu6mp6QRJRfND1hoKcGuIg+LQGGOd2t bwfYoaZ8ZXyXiLZ3lm5SRS6xun4yyZw/rbFrsB2Fb0VYIUwXE8IPSJPpu10meh7O1/5g 0I8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KonD9co+41btpWO4olX0GyFbM4GkzTedhR8yuiTWVrw=; b=Oa7Q6GEzeTdp+qyR5dg/GiFjpYCQ4UhWI+9wOa1JH6yfKEi/PPOSsJQMnrOpi2ROWn /w5poCP8S0Y8Ngppfybg4BY+X9/wnGMgRHDNAVXxFVTvqLJrZTzgozRd/eNS7zJ4/l/A 8ybA7KEvTKi5H+7+Kg1QFdLhN4p5ADBimiqQJAlGZDiPqt8hNYLSzRP0RJ9kcgyJh75S 4r9UMHk61fekfmMPgBVw0KO309UtcpF+Ulp5bfzyU03ycjtrUQFHl7u5jJTedIY7xd0d TqttQBWzgnm8cAqURFrWCCXzxhAfpQOq4wvaKn3SHvmjjMHY9hVJTLcQvMPuK1eBl5RC ZuvA==
X-Gm-Message-State: ALQs6tA4n8zCgIjhhEG8WuNt+8yDqltDAILq6lKs7ERha/sdLtEMaf12 FDFOg+Qtq8Bw7FL0b6Mmy6l5OM4OM78=
X-Google-Smtp-Source: AIpwx48w9IZ9aQmUPVAet3KKKBMp1SypbXJBd/8d5MYs7SwCBdzrljtvws/+QaC1oXKQgA8bymqDcg==
X-Received: by 2002:a17:902:d20a:: with SMTP id t10-v6mr4484369ply.151.1524108797418; Wed, 18 Apr 2018 20:33:17 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:2409:b933:ba41:5698? ([2601:647:4700:1280:2409:b933:ba41:5698]) by smtp.gmail.com with ESMTPSA id w16sm6468641pfk.125.2018.04.18.20.33.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 20:33:16 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <85846A8F-EF67-4947-B0A3-A487A09E4C41@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BEEC50AE-AA12-415A-8436-91CDB5B54A4A"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 18 Apr 2018 20:33:13 -0700
In-Reply-To: <20180412.125301.1466306532315626303.mbj@tail-f.com>
Cc: netconf@ietf.org
To: Martin Bjorklund <mbj@tail-f.com>
References: <12BD2BFD-A04E-44B4-AE70-EFBC6D7CB841@gmail.com> <20180412.125301.1466306532315626303.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Ho8-Frs81cv36goKxRgTEQP-Z8g>
Subject: Re: [Netconf] Shepherd review of draft-ietf-netconf-nmda-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Thu, 19 Apr 2018 03:33:21 -0000


> On Apr 12, 2018, at 3:53 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Hi,
> 
> 
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> I have reviewed -03 version of draft-ietf-netconf-nmda-restconf. 
>> 
>> The document is well written, and is easy to read, but has issues
>> which should be addressed before the document is sent to IESG.
>> 
>> Nits.
>> 
>> Abstract:
>> 
>> s/REF Editor/RFC Editor/
> 
> Fixed.
> 
>> 1.0 Introduction:
>> 
>> The first comma in this sentence seems to be misplaced. 
>> 
>> “supported in each datastore and, finally,” ??
> 
> I removed the "finally,".
> 
>> 2. Datastore and YANG Library Requirements
>> 
>> Can we consolidate the RFC Editor instructions in one place, instead
>> of splitting them between here and Abstract.
> 
> I don't think this matters; these are just instructions to the RFC
> editor that will be removed.  If the RFC editor has a preference for
> either style I'd be happy to follow that.

The RFC editors have indicated that they would prefer RFC instructions for the entire draft appear in one place.

> 
>> Detailed comments:
>> 
>> Introduction:
>> 
>> The document states:
>> 
>> "This document updates [RFC8040 <https://tools.ietf.org/html/rfc8040>]
>> in order to enable RESTCONF clients to discover which datastores are
>> supported by the RESTCONF server, as well as determine which modules
>> are supported in each datastore and, finally, to interact with all the
>> datastores supported by the NMDA. Specifically, the update introduces
>> new datastore resources, adds a new query parameter, and requires the
>> usage of [I-D.ietf-netconf-rfc7895bis
>> <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netconf-rfc7895bis>]
>> by RESTCONF servers implementing the NMDA."
>> 
>> 
>> Questions:
>> 
>> 1) How does this draft enable RESTCONF clients to discover which
>> datastores are supported?
>> 
>> Is it the definition of the new datastores resource? If so, can that
>> be made explicit, by saying something like this in Section 3.1
> 
> No, it is the inclusion of the new YANG library that makes this
> possible.  I suggest we add a paragraph at the end of section 2:
> 
>  A RESTCONF client can discover which datastores and YANG modules the
>  server supports by reading the YANG library information from the
>  operational state datastore.

Ok.

> 
> 
>> OLD:
>> This document defines a set of new resources representing datastores
>> as defined in [I-D.ietf-netmod-revised-datastores
>> <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netmod-revised-datastores>].
>> 
>> NEW:
>> This document defines a set of new resources representing datastores
>> as defined in [I-D.ietf-netmod-revised-datastores
>> <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netmod-revised-datastores>]. This
>> resource
>> can be used to discover the datastores that are supported by the
>> server.
>> 
>> On the question of discovery of datastores itself, would the clients
>> use the HEAD or GET methods to query what datastores are supported? If
>> so, an example would be nice. Specifically, something that explains
>> what response and errors to expect if the datastore is supported, and
>> what response and errors to expect if the queried datastore is not
>> supported.
>> 
>> 2) How does the draft help determine which modules are supported by
>> each datastore?
> 
> See above, this is also covered by my proposed text.
> 
>> I went looking for text in the draft that talks about module discovery
>> under each datastore, but did not find any. Am I missing something?

I do not see this issue addressed. The document states in the Introduction that:

"as well as determine which modules are supported in each datastore"

Where in the draft are we talking about module discovery in each datastore? If this is covered somewhere else, we should either remove this sentence or refer to the draft that covers it.

Thanks.

>> 
>> 3) The part of the sentence “to interact with all the datastores
>> supported by the NMDA” seems incomplete.
> 
>> What interaction are we referring to? Is it the protocol operations on
>> the datastore? Is it the query parameters on the datastores?
> 
> Yes, both.  A client can interact by reading or writing the datastores.
> 
>> Section 3.2.1
>> 
>> What happens if the capability is not announced, but a “with-defaults”
>> query is issued?
> 
> If the server doesn't understand the query, it will reply as defined
> by RFC 8040, section 4.8.  This document doesn't change that behavior.
> 
>> Finally, what are the implications of explicit discovery of datastores
>> supported by a RESTCONF server? For example, if the above
>> “with-defaults” query is issued with the “content” query parameter set
>> to “nonconfig", default values from which datastore are returned?
> 
> I don't understand this question.  Neither of these query parameter
> controls from which datastore data is returned.
> 
>> Also, if the query parameter “content” is not present, RFC 8040 says
>> that the default value is “all”. Does “all” include operational
>> datastore data nodes, with or without the new capability? In other
>> words, do we need to redefine “all”?
> 
> No, RFC 8040 says that "all" means: "Return all descendant data
> nodes".  This document doesn't change that.
> 
> 
> /martin

Mahesh Jethanandani
mjethanandani@gmail.com