Re: [Netconf] YangPush now

Andy Bierman <andy@yumaworks.com> Thu, 19 July 2018 16:55 UTC

Return-Path: <andy@yumaworks.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 79078130DD1 for <netconf@ietfa.amsl.com>; Thu, 19 Jul 2018 09:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 OponvYR08M9p for <netconf@ietfa.amsl.com>; Thu, 19 Jul 2018 09:55:46 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 47F94130EEB for <netconf@ietf.org>; Thu, 19 Jul 2018 09:55:46 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id y200-v6so68440lfd.7 for <netconf@ietf.org>; Thu, 19 Jul 2018 09:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ATjmqS1hJqj1VS9j5GoJE7EDUUiX6E6+6yJEDcHU2zs=; b=IlfEtqZ+ragxW10OY/M+Eltwi0JWjx71KdkmeQBIHujAkS1bgy5kebvtad4IB4OaYC v6D72cM2W40eut+efRWWJkmYuHtakyydLpKadZbbpskj2KzLzYJgulfY9ucXvvLFthnX YCScB6lfS2In2fLYgcQrG9foSjRzB1TMgwtOIJ9Tdo2ft72StFfiiwHIvW6/XTAeR9SH YEPlW5GSXi8sbg+1y5lFVprlJQxEoDlouD+nIVVOgZYSoxEOxNO3x2M0/zhjYRe6ueRw 1kiWZqBkLsQAozXkmo/JpVc8sDayWGb1IY9lh4LurWzyetyG7iuuFPACobP2I6FA4Kte G02g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ATjmqS1hJqj1VS9j5GoJE7EDUUiX6E6+6yJEDcHU2zs=; b=E2OOSpm8r8+4AwFyEHxiVIjcaVuL9/9lhCP/OHFlrbcS/WhTXLNmb1LbMDUayPoXeo 1okutGIfWNNa+WzzFpGJiWKOTfrp+vjP0eMK9HbYV5J7TwcaoKLrc7J36SrZrJIn/d+C RYY8FGUXPEQJp2PPoqe4sl4XuhP/nZ1HCwlxbnmafjGc9ZPfZg0tkJBFvjSxj72UwM06 06pRZ1bM9tVQs3AUjUEGEKFbfvPbOSyannFgtjQF2ZbFyAMcDUERhppKcUE7+GDbtuTt xRtr4O7eooWW+yFv4h5XnJKxXLkj/T5BfHp8Bfb2WMb2w97I5KaSXTrOz/xKq7ekjVxv 4U8Q==
X-Gm-Message-State: AOUpUlE/jNFTlrMNPDYfeYANIp0VHmVQiOLE1eeVznN6q2SqUv2kuqjD 4pZssmPPI0uE8ArP8lxdQnegX28nAbmdkxmdEbrwlsRg
X-Google-Smtp-Source: AAOMgpftIp6WJKL6Bol4f6OgreyhnksVnzJuttO2uADMwK4hORhDDQpocYGy3ZhEBJ4k2aE/NZDW8OYS36U4Gts2tYE=
X-Received: by 2002:a19:518a:: with SMTP id g10-v6mr6991412lfl.78.1532019344407; Thu, 19 Jul 2018 09:55:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 09:55:43 -0700 (PDT)
In-Reply-To: <85CBFD6B-CBEE-47C5-83ED-FD37007B78A3@juniper.net>
References: <2E1BAD12-EFF2-4E35-B232-57A4C4490989@cisco.com> <20180717055030.7bmzlychtznf3mso@anna.jacobs.jacobs-university.de> <18622ABD-DB9F-406C-836F-64649F3D8FF6@cisco.com> <20180717172036.hhuoq6fzs7ctblpf@anna.jacobs.jacobs-university.de> <CABCOCHS8cfqKLaQe9M4tu-2zkZ5=6-a2FEv+idJwZiW_btx_Zw@mail.gmail.com> <a54850668bfb4483b89f4c2b15bf5f44@XCH-RTP-013.cisco.com> <CABCOCHSxTh7J1Kys1B+sNC2dWuJKr_L7cJgO9T+E+-_+k9H-6w@mail.gmail.com> <5366188A-111C-49ED-95AF-82A5171750CC@cisco.com> <85CBFD6B-CBEE-47C5-83ED-FD37007B78A3@juniper.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 19 Jul 2018 09:55:43 -0700
Message-ID: <CABCOCHRRGjZSjWOEj_XXGQLAOeRhiO9avuhShh_xpLk_=CZZ3g@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d010c405715d0c2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8Bkv5uvtfWP--4i1D_lwyQ1LqI0>
Subject: Re: [Netconf] YangPush now
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: Thu, 19 Jul 2018 16:55:51 -0000

On Thu, Jul 19, 2018 at 9:12 AM, Kent Watsen <kwatsen@juniper.net> wrote:

>
> To address some of the concerns being raise here, I suggest the following:
>
> 1. make the augmentation of a "notif" model mandatory (see the '+' lines
>    below), to ensure that there is always something more than just a name
>    being configured per receiver.
>
>       container receivers {
>         list receiver {
>           key "name";
>           min-elements 1;
>           leaf name {
>             type string;
>           }
>    +      choice transport {
>    +        mandatory true;
>    +        description
>    +          "Defines the transport-specific configuration data
>    +           for the selected transport.";
>    +      }
>
>
>

The notion of an empty mandatory choice really stretches the definition of
YANG Conformance.
This says you cannot possible implement the SN module without some other
module augmenting it.
Yet there is no way in YANG (besides import) to say the module bar needs to
be present
if module foo is present.


2. modify netconf-notif to augment-in the ietf-netconf-server grouping:
>
>   module ietf-netconf-notifications {
>     prefix nn;
>     import ietf-netconf-server { prefix ncs; }
>     import ietf-subscribed-notifications { prefix sn; }
>
>     // define a *local* netconf-server instance
>     container "netconf-server" {
>       uses "ncs:netconf-server-grouping" {
>         // prune out the "listen" subtree
>         refine "listen" {
>           if-feature "never-supported-feature";
>         }
>         // disable dependency on the "call-home" feature
>         refine "call-home" {
>           if-feature "true"; // needed? (see 7950, s7.20.2, P3)
>                              // valid? (unsure)
>         }
>       }
>     }
>
>


The use of constant (true or false) values for if-feature are not supported
and
the use of dummy features that are always supposed to be a constant value
seems to abuse the intent of YANG features.

Refactoring the groupings would be the cleanest solution.




>     // add leafref to above locally-configured call-home instances
>     augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>       leaf netconf-endpoint {
>         type leafref {
>           path "/nn:netconf-server/nn:call-home/nn:netconf-client/nn:
> name";
>         }
>       }
>     }
>   }
>
>
> 3. do the identical thing to the restconf-nofif draft:
>
>   module ietf-restconf-notifications {
>     prefix rn;
>     import ietf-restconf-server { prefix rcs; }
>     import ietf-subscribed-notifications { prefix sn; }
>
>     // define a *local* restconf-server instance
>     container "restconf-server" {
>       uses "rcs:restconf-server-grouping" {
>         // prune out the "listen" subtree
>         refine "listen" {
>           if-feature "never-supported-feature";
>         }
>         // disable dependency on the "call-home" feature
>         refine "call-home" {
>           if-feature "true"; // needed? (see 7950, s7.20.2, P3)
>                              // valid? (unsure)
>         }
>       }
>     }
>
>     // add leafref to above locally-configured call-home instances
>     augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>       leaf restconf-endpoint {
>         type leafref {
>           path "/rn:restconf-server/rn:call-home/rn:netconf-client/rn:
> name";
>         }
>       }
>     }
>   }
>
>

The problem with identityref leafs is that the client has no clue what the
server will support. The problem gets much worse for the client dealing
with a mandatory empty choice.


Andy



>
> Doing so would fill in the missing piece folks are asking to see.  Yes,
> it introduces a normative reference to the client/server work, but it is
> consistent with the result from Monday's NETCONF "dynamic ~ configured"
> discussion and, besides, that work seems almost done now.
>
> There still might be an issue regarding the server pushing notifications
> immediately after the NC/RC session starts, but I feel that by having a
> *conf-server instance inside the "notif" model, we can more easily claim
> that the behavior is okay.
>
> The current restconf-notif draft is more https-focused, but I feel that,
> if there is a goal to have a plain-https transport, then that should be
> defined in a separate "https-notif" draft.
>
> Currently the restconf-client-server model does not enable the
> configuration of the "http-version" to be used.  I cringe to say this,
> but we might consider introducing an "https-client-server" draft that
> the "restconf-client-server" draft could be refactored to depend on.
> If this were done, then said "https-notif" draft could use the "https-
> client-grouping", and thus be consistent with the pattern we're
> establishing here.
>
> To address the interoperability issue, it seems we either: 1) define
> a super-simple mandatory-to-implement "notif" layer (I would recommend
> https-client for this) or 2) a good mandatory-to-implement "notif"
> layer (e.g., binary over DTLS and per line-card, per the udp-pub-channel
> draft), or 3) do nothing, leaving it to the market to decide, similar
> to how RFC 8040 doesn't require a specific encoding (XML, JSON, etc.)
>
>
>
> Kent  // contributor
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>