Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

Martin Bjorklund <mbj@tail-f.com> Wed, 30 October 2019 08:32 UTC

Return-Path: <mbj@tail-f.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 480DE1200F4 for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 01:32:36 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Oakwwj_KTaGn for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 01:32:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA501200B5 for <netconf@ietf.org>; Wed, 30 Oct 2019 01:32:34 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 34FAE1AE0388; Wed, 30 Oct 2019 09:32:30 +0100 (CET)
Date: Wed, 30 Oct 2019 09:32:00 +0100 (CET)
Message-Id: <20191030.093200.966070125623058715.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: mnot@mnot.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016df4ad340a-3b990c99-95f8-40c3-9ff0-6f627826bd94-000000@email.amazonses.com>
References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <802B82C7-56D8-4341-9416-2C2CFFECAA3C@mnot.net> <0100016df4ad340a-3b990c99-95f8-40c3-9ff0-6f627826bd94-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vXURlnjp5GcB0uIkzYj26Gf3V6k>
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04
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: Wed, 30 Oct 2019 08:32:38 -0000

Hi,

Kent Watsen <kent+ietf@watsen.net>; wrote:
> Hi Mark,
> 
> I just re-read all your (and Patrick's) messages from before and was
> unable to see anything actionable that wasn't addressed.

I have searched the archives but couldn't find these messages.  Can
you send a link to them?  I would like to understand Mark's concerns.


/martin

> Can you
> please provide concrete examples for the concerns you have?
> 
> Since last time, there is now a second consumer of this draft:
> draft-ietf-netconf-https-notif.  Hopefully, now looking at both
> consumers (the other being draft-ietf-netconf-restconf-client-server)
> you will get a clearer picture of what is trying to be accomplished
> here.
> 
> While not stated anywhere, the goal is somewhat restricted to support
> HTTP-based APIs (e.g., RESTful protocols) more so than webservers or
> browsers.  Maybe this is what you're perceiving as being "an arbitrary
> profile"?  FWIW, there are implementations (running code), which
> suggests the model here is close to what is needed for HTTP-based
> APIs.
> 
> This draft defines only YANG "grouping" statements.  Grouping
> statements don't define protocol-accessible nodes, just a potential
> for its nodes to exist.  The grouping statements MUST be "used" by
> another YANG module, which MAY augment/refine the grouping as needed.
> The model is purposely incomplete for this reason.
> 
> As an example, assume a higher-level model wishes to define
> configuration for an HTTP client, but wishes to use some other
> (potentially proprietary) authentication scheme, not Basic.  To
> achieve this, the higher-level model could 1) "use" the
> `ietf-http-client` grouping, 2) NOT define the "basic-auth" feature
> (and hence Basic is not configurable), while 3) augmenting-in the data
> model for configuring the client-specific authentication scheme
> (enabling that authentication model to be configured).
> 
> Kent // contributor
> 
> 
> 
> > On Oct 21, 2019, at 7:34 PM, Mark Nottingham <mnot@mnot.net>; wrote:
> > 
> > Mahesh,
> > 
> > I've had a quick look at the draft, and I don't think it substantially
> > addresses the feedback we gave earlier. It appears to create an
> > arbitrary profile of HTTP and embodies several anti-patterns for its
> > use.
> > 
> > As a result, I personally do not support the adoption of this draft.
> > 
> > Regards,
> > 
> > 
> >> On 22 Oct 2019, at 9:52 am, Mahesh Jethanandani
> >> <mjethanandani@gmail.com>; wrote:
> >> 
> >> Hi WG,
> >> 
> >> The author has posted a -04 version of the draft, and believes that it
> >> ready for WG adoption.
> >> 
> >> This starts a 2 week poll ending on November 4, to decide whether this
> >> document should be made a WG document or not. Please reply to this
> >> email whether or not you support adoption of this draft by the
> >> WG. Indications that the draft has been read will be also be
> >> appreciated.
> >> 
> >> Thanks.
> >> 
> >> Mahesh Jethanandani
> >> mjethanandani@gmail.com
> >> 
> >> 
> >> 
> > 
> > --
> > Mark Nottingham   https://www.mnot.net/
> > 
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>