Re: [netmod] hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

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

Hi Walker,

Thanks very much for the comments.   Some thoughts in-line.

From: Zhengguangying (Walker), May 2, 2017 9:25 AM

Hi Alex, Eric and all,

   I reviewed the latest Draft and have some comments, please help to confirm, thanks.

   For draft-ietf-netconf-yang-push-06:
1.       In section 4.1, the configured subscription receivers not sepcify which mechnism to connect to client, it's better define clearly, specify it should be call home protocol.
<Eric> I totally agree call home is necessary.  The two transport drafts currently have the call-home specified within them.  As we define the transport protocol per receiver, the appropriate call home mechanism for a platform transport should be automatically selectable.  I will clarify/improve the text in the subscribed-notifications draft to indicate this.
Is there something else needed at the protocol independent level?   At this point I don't know of any transport-independent call home behaviors unspecified, other than the need to add a context statement saying call home is necessary if transport isn't available for a queued push update message.  I don't think we should over specify this right now.  This is because for some transport connection types, call home doesn't need to be always-on.  E.g., HTTP implementations have the potential to scale differently than NETCONF if a configured subscription transport can be established ad-hoc only when a push-update is ready to go.   If there are other specific behaviors needed for call-home behavior, what are they?  Are these something that can vary by transport protocol and implementation?
In YANG model, "leaf period" 's unit is timeticks(1/100s), it difficult to understand for user, suggest to change the unit to millisecond.
<Eric> The common YANG types of RFC 6021 defines timeticks.  I am hoping not to change typedefs which are compliant with that RFC.   *However* if you see a business need to move to Milliseconds because you need a more granular time that hundredths of a second, we should discuss that.  Especially as hundredths is what SMIv2 uses, we should have some use cases which needs the extra granularity before making the change.  Do you have use cases which need millisecond-level subscription periods?
2.       for the "leaf dampening-period ", it's better to give one maxmum value, otherwise it may can not effective
<Eric> I think this what we are trying to say in the draft.  How about I improve the leaf dampening-period definition to:
"The shortest time duration which is allowed between the creation of independent yang object update messages.  Effectively this is the amount of time that needs to have passed since the last update."
3.       If the time is not enough to send all the data in a cycle, how to deal with the remaining data? Just postpone the next cycle or do not send the remaining data? If you do not send the remaining data, it may cause the remaining data can not be monitored.\
<Eric> Marshalling data into messages is treated differently within the publisher than the transmitting of updates.  If for some reason not all the data can be assembled into a push update or push-change-update message, the "updates-not-sent" flag should be set.  The receiver can then determine what to do.   Note: It is perfectly acceptable to have sequential push-change-updates queued and in the process of being sent (in- order).  I will add text to this to help clarify the yang-push draft.
4.       How to declare which path support "on-change"? Current draft defined all path not support "on-change" as default, if all "configure" leaf support "on-change" how I should do? Add extension for all "configure" leaf? It looks too complex, whether we can support one simple mode, such as define by type? then I can define all "configure" lead support "on-change".
<Eric> There is a good discussion in here.    The answer currently in the draft is that you should make a deviations file which lists entries for each parent node of each model which should support on-change.  So this doesn't need to be done for every leaf (as the values are inherited down the subtree.)  You are right that having a deviations file list this for every configuration node would add some complexity, including for model maintenance.
If you want a default behavior mode for a platform implementation, would you rather propose feature rather than an extension?  We could create a feature which enables all configuration=true nodes to be on-change subscribable. Maybe an extension titled "on-change-for-configuration"?  We then must decide what is the interaction between this and the existing "notifiable-on-change" extension.  To reduce conflicts/confusion, I would suggest that the feature has precedence.   Balazs, any thoughts on this?
5.       I think "subscription-status" attributes not enough , when subscirption status is suspend ,we need "suspend reason", " suspend time". When subscription resume, we need "resume time".
<Eric> This information will be available in the log as both the suspend and resume trigger the creation of a notification with a timestamp.  Does it need to be available via standard exposed codes in the yang model?   I don't really have any problem adding this, but there currently isn't any historical information exposed in the model.  It is all current state.   I would love to hear others' opinions on this one.
or "Modify-subscription " and "Delete-subscription ", we should give the limitition: Subscriptions established via RPC can only be Modified/deleted via RPC using   the same transport session used for subscription establishment.
<Eric> This is true.  As these RPCs are augmented from definitions is "subscribed notifications" which include that text, is that not sufficient?  In some cases we have the information only in one document to reduce the overall amount of text.

For draft-ietf-netconf-subscribed-notifications-02:
1.       In A.1.  ietf-netconf-netconf-event-noti, the draft name should not be "[I-D.ietf-netconf-restconf-notif]", it should be "draft-ietf-netconf-netconf-event-notifications-01", right?
<Eric> Excellent catch.  Thanks!
2.       In "section 1.  Introduction" there have two repeated item "o  Ability to subscribe to event notifications using two mechanisms: dynamic and configuration subscriptions."
<Eric> This text is from the document "draft-ietf-netconf-netconf-event-notifications" which is not ready for review at this time.
Eric

Thanks & Regards
Walker (Guangying zheng)

[X]