Re: [Netconf] YangPush now

[Kent Watsen <[e-mail]>]

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.";
   +      }


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

    // 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";
        }
      }
    }
  }


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