Re: [Netconf] YangPush now

["Eric Voit (evoit)" <[e-mail]>]

From: Andy Bierman, July 19, 2018 12:56 PM

On Thu, Jul 19, 2018 at 9:12 AM, Kent Watsen <[e-mail]<mailto:[e-mail]>> 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.

<Eric> One other issue is there is a “transport” leaf at the subscription level which would be redundant with the choice at the receiver level.  Placing it there enforces a decision the WG made at a previous IETF that transport would not vary by receiver.

Extending this, in previous discussions on the mailing list on this topic, I have not seen XPATH able to enforce the same transport case is selected across all receivers.


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.

<Eric> This refactoring point would suggest that there could be meaningful changes to the netconf-server model.  Which would delay everything.   Better to do a –bis version of NETCONF-Notif when the call home is ready



    // 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.

<Eric> Per previous discussions on this, I have no problem with the client/server work.

However I do have a problem with establishing this normative dependency due to:
(a) the potential time delay (see Andy’s refactoring point above, the text below, and the fact that netconf-server type drafts have yet to enter WGLC.)
(b) relevance of all this depends on vendors adoption timeframes for netconf-server.

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.)


All these point can safely be considered by a –bis draft if call home model standardization considerations are left out of the current set of drafts in WGLC.

Eric


Kent  // contributor



_______________________________________________
Netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf