Subject: [netmod] strawman REJECT Y51 support for long running commands

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 1 Jun 2014 17:20:26 +0200

A proper (that is less complex) solution requires specific protocol
support and thus this falls out of scope for YANG 1.1.

Speak up by June 10th if you disagree with this strawman proposal.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Tue, 10 Jun 2014 14:58:05 +0000

Is it fair to say that with the current Yang (1.0) support, the design
pattern specified in the original mail (attached for reference) is the
best way to represent this construct?

> support and thus this falls out of scope for YANG 1.1.

Does this mean that the suggested formulaic expansion in the attached mail
(which was intended to avoid the need for specific protocol support) is
missing some functionality or is limited in some way, or just that
performing the formulaic expansion is too complex?

(We have events of this form that need modelling, so in any case I'm
looking to validate the design pattern for consistency/completeness. In
lieu of native support, our best answer so far is to use the design
pattern described with an extension for interested implementations to link
the related primary RPC, cancellation RPC and notification.)

Thanks,
Peyman

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: 01 June 2014 16:20
> To: [email-masked]
> Subject: [netmod] strawman REJECT Y51 support for long running commands
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

Subject: [netmod] Yang 1.1 support for long-running commands
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 6 May 2014 21:58:45 +0000

Issue:

Currently, we cannot find a "clean" way to mode a long-running command (e.g. "ping", "traceroute") in Yang. This class of command requires the following:

-    A request to be made to trigger the command starting (e.g. an RPC).

-    Notifications to be returned (for a period) as partial results become available.

-    A request to be made to cancel the operation if required.

-    An indication that the operation has completed and no further results are pending.

So in Yang 1.0 this could be modelled as follows:

rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  output {

    leaf operation-id {

      type uint64;

      description "Correlates the request to 'ping-cancel' and 'ping-results'"

  }

}

rpc ping-cancel {

  input {

    leaf operation-id {

      type uint64;

      description "The ID for the operation to cancel, as returned by the ping request";

    }

  }

}

notification ping-results {

  leaf operation-id {

    type uint64;

    mandatory true;

    description "The ID for the request for which results are being returned";

  leaf result {

    type enumeration {

      enum success;

      enum timeout;

      enum unreachable;

    }

  }

  leaf operation-completed {

    type empty;

    description "Indicates that no further results are to be returned";

  }

}

However, it would be preferable to have an abbreviated form for this usage pattern, which would also allow for it to be implemented differently depending on the protocol.

Solution:

This could be done various ways, but one suggestion would be to define a "partial-output" RPC result, such that whenever it is used, the type of operation is as above.

rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  partial-output {

    leaf result {

      mandatory true;

      type enumeration {

        enum success;

        enum failed;

        enum unreachable;

      }

    }

  }

}

Depending on the protocol, this could be implicitly expanded to the above Yang 1.0 form (with the "cancel", operation-id and "operation-completed" being implicit based on a standard pattern), so all the extraneous parts that are common to this pattern are abstracted from the user.

[Note: If an "output" is also specified, that would be expected to be returned immediately in response to the input, in line with the existing RPC semantics.]

Alternative solution:

It would be possible to implement this as an extension, though that would require a fifth type of operation to be defined as part of the extension.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:25:00 +0200

> best way to represent this construct?

I can't say whether this is the best or just some way to do it.
 
> performing the formulaic expansion is too complex?

It is unclear whether notification channels are the proper way to
deliver partial results. CMIP back in last century had something
called linked responses, translated into NETCONF, you invoke an rpc
but you receive not just one rpc-reply but multiple linked rpc-reply
elements (which can also solve issues with very long rpc-replys).
 
> the related primary RPC, cancellation RPC and notification.)

One concern is usually access control. If you use notification
channels for partial results, you might get into odd access control
configuration issues (since allowing an RPC now also involves allowing
at least some notifications). Hence, a solution that can build on
protocol support may not use notifications this way.

/js