Re: [netmod] kw review of draft-liu-netmod-yang-schedule

Hi,

I read this draft.
I really do not like mixing metadata that could apply to any data node
(such as scheduling) into the data model.  In your solution, in order to
schedule some config, the grouping has to be used in the data model.

I think the existing solution in RFC 7758 is better because it does not
require alterations to all the data models in order to work.

Andy

On Fri, Sep 23, 2016 at 7:08 AM, Xufeng Liu <xufeng.liu.ietf@gmail.com>
wrote:

> Hi Kent and All,
>
>
>
> Based on comments, we have submitted updated version
> https://datatracker.ietf.org/doc/draft-liu-netmod-yang-schedule/
>
>
>
> Thanks,
>
>
>
> - Xufeng
>
>
>
> *From:* netmod [mailto:netmod-bounces@ietf.org] *On Behalf Of *Xufeng Liu
> *Sent:* Thursday, April 14, 2016 4:03 PM
> *To:* Kent Watsen <kwatsen@juniper.net>; netmod@ietf.org
> *Subject:* Re: [netmod] kw review of draft-liu-netmod-yang-schedule
>
>
>
> Hi Kent,
>
>
>
> Thanks for the valuable comments.
>
>
>
> Best,
>
>
>
> - Xufeng
>
>
>
> *From:* netmod [mailto:netmod-bounces@ietf.org <netmod-bounces@ietf.org>] *On
> Behalf Of *Kent Watsen
> *Sent:* Monday, April 4, 2016 10:54 AM
> *To:* netmod@ietf.org
> *Subject:* [netmod] kw review of draft-liu-netmod-yang-schedule
>
>
>
>
>
> [As a contributor]
>
>
>
> While it's clear what this document is trying to achieve at a high level,
> it is unclear why the solution is needed.   A "motivation" section
> explaining why this should be standardized would be nice.
>
> *[Xufeng] Agree.*
>
>
>
> When reading this draft, I was reminded of my long expired draft
> https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00.
> That draft provided a more general solution, in that it enabled sub-trees
> to be enabled/disabled for any reason.  It was primarily focused on
> supporting comments, but it did call out that expressions could include
> time, though it didn't flush out that thought to any extent.
>
>
>
> Other than draft-kwatsen-conditional-enablement being a more generic
> solution, another difference is that this draft enables the module-designer
> to specify where in the data model the grouping is used, whereas my old
> draft let the client enabled/disabled nodes anywhere in the data model,
> potentially producing nonsensical results, though we have to assume that
> the server would fail any invalid results.
>
> *[Xufeng] Agree that it is more generic solution, though the intention and
> mechanism are a bit different. I think that the described technique is
> still useful, and I’d support it to proceed.*
>
>
>
> Regarding this solution, I have some specific questions:
>
>
>
> 1) why is the "schedule" node a list?  How is a list to be processed?
> Are there any overlapping issues?
>
> *[Xufeng] The list is used so that a series of schedules (such as
> durations) can be specified. If several durations are specified, the object
> is configured in all these durations, inclusively. If two durations are
> overlapped, the union is used, so that the result is one longer duration.
> Do you see any problem here?*
>
>
>
> 2) does the "schedule-id" leaf have any useful purpose other than being
> the list's key?
>
> *[Xufeng] Its only purpose is to be the key.*
>
>
>
> 3) the "schedule-duration" node's pattern matches XSD's "duration" type,
> is it the intent to process it as such?
>
> *[Xufeng] Yes.*
>
>
>
> 4) the draft-ietf-netconf-server-model draft originally had a
> duration-like value, but the WG consensus was at the time was to instead
> use an unsigned integer value with a "units" value (e.g., seconds, minutes,
> etc.).  The claim was that, when large values where needed (e.g.,
> 3600-seconds instead of 1-hour), that the client could always do the math.
> Any thoughts on that?
>
> *[Xufeng] The integer value is surely an alternative, though the fixed
> “units” might be limiting. For example, why should we pick “seconds”
> instead of “minutes”? What should be proper range of the integer? In this
> case, I think ISO 8601 format is more convenient and flexible than asking
> the client to do the math all the time (which may not be adequate). Also,
> the duration is used along with a data-time leaf which is also in ISO 8601
> format, so that the style and processing are consistent.*
>
>
>
> 5) are there any issues with the "repeat-interval" node?  I'm specifically
> thinking about the interval being expressed in terms of hours and days in
> the context of daylight savings and leap year...
>
> *[Xufeng] Heard some criticisms on the IOS 8601 expressions. There could
> be some issues, but are they significant enough to stop us from using it?
> The behaviors could be defined and clarified, couldn’t they? What do you
> think?*
>
>
>
> Nit: some examples in the draft would've been nice.
>
> *[Xufeng] Sure we will do.*
>
>
>
> Thanks,
>
> Kent
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>