Re: [Netconf] YANG Doctor question: empty mandatory choice?

Martin Bjorklund <mbj@tail-f.com> Tue, 31 July 2018 14:51 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 476DA130EB3 for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 07:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-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 wYd5MHtdlWqL for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 07:51:05 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9326B130EAA for <netconf@ietf.org>; Tue, 31 Jul 2018 07:51:05 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 382AD1AE0426; Tue, 31 Jul 2018 16:51:03 +0200 (CEST)
Date: Tue, 31 Jul 2018 16:51:03 +0200 (CEST)
Message-Id: <20180731.165103.950825344221422538.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: j.schoenwaelder@jacobs-university.de, evoit=40cisco.com@dmarc.ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44B0A74E-CCF0-4E9B-846A-1F46E90AEB5E@juniper.net>
References: <44B0A74E-CCF0-4E9B-846A-1F46E90AEB5E@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/odXrux6ksVqqNh4G5gLPynObyv4>
Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 31 Jul 2018 14:51:07 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> [removing yang-doctors list, and updating subject line accordingly]
> 
> 
> >> > Why do all receivers of a subscription have to use the same transport?
> >> 
> >> This was something that Martin and Eric worked out before we did the first
> >> Last Call.  Eric doesn't seem to know the particular reason, other than 
> >> Martin seems to think it’s easier.
> >
> > No; I personally also prefer a design where each receiver has its own
> > transport + encoding.  
> 
> +1
> 
> 
> > The original model had a common "encoding" for
> > all receivers, and then a receiver-specific transport - I think this
> > is even worse,
> 
> Agreed.
> 
> 
> > and suggested to have transport + encoding defined
> > together preferrably receiver-specifc or else common for all
> > receivers.
> >
> > If the WG now believes that the transport + encoding should be done 
> > per receiver, this should be fairly easy to change.
> 
> I also prefer per receiver, and I think that doing so will simplify the
> model, as neither the mandatory "transport" nor the [not mandatory?]
> "encoding" leaves have to be specified.
> 
> In particular, my thoughts are that the "notif" model should provide
> for the encoding selection, if needed (it's not needed for NETCONF, 
> or COAP I imagine).  

I agree.  I think this would be a cleaner design.


/martin


> 
> In the case of RESTCONF, we could update the ietf-restconf-client and
> ietf-restconf-server models to include an "encodings" leaf-list, to 
> configure the RESTCONF server which encodings it should support.  We
> likely need to do something similar to configure which HTTP versions
> should be supported.  Now, in a general RC server, the server could 
> support both but, if the restconf-notif draft has its own list of 
> restconf-servers (i.e., it uses the "restconf-server-grouping" itself,
> see my July 19 email for a YANG example), then a constraint could be
> added limiting the number "supported" to just one.  Thus, when the RC
> server reboots, and connects to the receiver and *automatically* 
> (no client RPC) starts pushing notifications, it can know what 
> encoding to use.
> 
> I'm still unsure if its legal for an RC server to automatically push 
> notifications without a client-initiated RPC of any sort, and I'm 
> also uncertain if supporting *configured* subscriptions for NC or RC
> is needed (see my message July 20 email).  So, some of this may work
> itself out as we progress.
> 
> I know that we're not defining the *configured* notif drafts in this
> first effort, the we are publishing the SN draft with a configuration
> model, my only concern now is configuration model presented in the 
> SN draft.
> 
> 
> Kent // contributor
> 
>