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

["Xufeng Liu" <[e-mail]>]

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:[e-mail]] On Behalf Of Xufeng Liu
Sent: Thursday, April 14, 2016 4:03 PM
To: Kent Watsen <[e-mail]>; [e-mail]
Subject: Re: [netmod] kw review of draft-liu-netmod-yang-schedule

 

Hi Kent,

 

Thanks for the valuable comments. 

 

Best,

 

- Xufeng

 

From: netmod [mailto:[e-mail]] On Behalf Of Kent Watsen
Sent: Monday, April 4, 2016 10:54 AM
To: [e-mail] <mailto:[e-mail]> 
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