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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 3 May 2017 13:56:52 +0000

(Moving lots of people to 'BCC' so that this thread can traverse NETCONF & NETMOD filters as Walker originally intended.)

One more comment, see <<Eric>>

From: Alexander Clemm, May 2, 2017 8:35 PM

Hi Walker, thank you for your review and comments, and Eric, for your excellent response, to which I have little to add except a few small items inline <ALEX>
--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, May 02, 2017 9:52 AM
To: Zhengguangying (Walker) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'Balazs Lengyel' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ambika Prasad Tripathy (ambtripa) <[email-masked]<mailto:[email-masked]>>; 'Kent Watsen' <[email-masked]<mailto:[email-masked]>>; Hector Trevino (htrevino) <[email-masked]<mailto:[email-masked]>>; Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>>; Guopeipei (Peipei Guo) <[email-masked]<mailto:[email-masked]>>; Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>>; 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>; 'Chisholm, Sharon' <[email-masked]<mailto:[email-masked]>>; Yangang <[email-masked]<mailto:[email-masked]>>; Alexander Clemm <[email-masked]<mailto:[email-masked]>>; 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; Tim Jenkins (timjenki) <[email-masked]<mailto:[email-masked]>>; 'Scharf, Michael (Nokia - DE)' <[email-masked]<mailto:[email-masked]>>; Rohit pobbathi <[email-masked]<mailto:[email-masked]>>; 'MehmetErsue' <[email-masked]<mailto:[email-masked]>>; Mahesh Jethanandani (mahesh) <[email-masked]<mailto:[email-masked]>>
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

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.
<ALEX> One other aspect beyond the receiver:  When you indicate "time is enough to send all the data in a cycle", are you referring to a scenario where the interval in which to send data is too short to allow for transmission of all the data?  In such a case, a publisher would fall further and further behind.  Really, this is a case where a publisher should basically suspend or abort the subscription, as it can't keep up.  We should state this clearly in the text.  The tricky part is of course that some of it may be of temporal nature due to, for example, a temporary increase in list size or a large number of updates, which may subside later - this would be reason to initially suspend (and later resume), before terminating the subscription outright.  Again, we will update the text more clearly.
</ALEX
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.

<ALEX> We currently state: "Subscriptions created by configuration operations cannot be modified [respectively deleted] via this RPC."

You are suggesting to be stronger than that, i.e. not allow a dynamic subscription to be touched by any transport session other than the one over which it was created.  I am not sure of this, can you elaborate a bit further?  Basically this would imply needing to keep track of which session created which object or dynamic subscription, something the framework does not currently keep track of (but that is perhaps a bit i2rs-ish). </ALEX>

<<Eric>> It is true that the YANG model doesn't expose identifiers for the transport session which is used for a dynamic subscription.  But these bindings will still be known within the publisher.  So it is viable to enforce such a constraint.  I believe it improves security as well.   If there is an administrator which needs to tear down the dynamic subscription, the kill-subscription RPC is available.

<</Eric>>

--- Alex (done with comments)

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]

---

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Tue, 2 May 2017 13:24:50 +0000

Hi Alex, Eric and all,

   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.
2.      In YANG model, "leaf period" 's unit is timeticks(1/100s), it difficult to understand for user, suggest to change the unit to millisecond.
3.      for the "leaf dampening-period ", it's better to give one maxmum value, otherwise it may can not effective
4.      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.\
5.      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".
6.      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"
7.      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.

Thanks & Regards
Walker (Guangying zheng)

[X]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 2 May 2017 16:51:55 +0000

Hi Walker,

Hi Alex, Eric and all,

Thanks & Regards
Walker (Guangying zheng)

[X]

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 3 May 2017 00:34:53 +0000

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, May 02, 2017 9:52 AM
To: Zhengguangying (Walker) <[email-masked]>; [email-masked]; [email-masked]; 'Balazs Lengyel' <[email-masked]>
Cc: [email-masked]; [email-masked]; Ambika Prasad Tripathy (ambtripa) <[email-masked]>; 'Kent Watsen' <[email-masked]>; Hector Trevino (htrevino) <[email-masked]>; Einar Nilsen-Nygaard (einarnn) <[email-masked]>; Guopeipei (Peipei Guo) <[email-masked]>; Alberto Gonzalez Prieto (albertgo) <[email-masked]>; 'Andy Bierman' <[email-masked]>; 'Chisholm, Sharon' <[email-masked]>; Yangang <[email-masked]>; Alexander Clemm <[email-masked]>; 'Susan Hares' <[email-masked]>; Tim Jenkins (timjenki) <[email-masked]>; 'Scharf, Michael (Nokia - DE)' <[email-masked]>; Rohit pobbathi <[email-masked]>; 'MehmetErsue' <[email-masked]>; Mahesh Jethanandani (mahesh) <[email-masked]>
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

Hi Walker,

Thanks & Regards
Walker (Guangying zheng)

[X]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 12:00:14 -0700

On Tue, May 2, 2017 at 9:51 AM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Zhengguangying (Walker), May 2, 2017 9:25 AM
>
> Hi Alex, Eric and all,
>
>
>
> 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.
>

I am not calling for the removal of configured subscriptions but IMO they
are
not needed because callhome is required anyway. It requires less config
in the server (to just configure callhome).  The client can invoke
<establish-subscription>
right away.  The server does not need to remember the subscription details
as config.
It doesn't buy you very much.

It also seems to introduce extra work on the client to maintain its
subscription details
in the server.

Andy

> 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.
>
>
>
> 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?
>
> 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)
>
>
>
>
>
>
>
>
>
>
>

---

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Mon, 8 May 2017 08:18:20 +0000

Hi Eric, Alex

   Thanks for your your excellent response, for some doubt I have add small items inline <walker> .

Walker

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: 2017年5月3日 21:57
To: Alexander Clemm; Zhengguangying (Walker)
Cc: [email-masked]; [email-masked]
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

(Moving lots of people to ‘BCC’ so that this thread can traverse NETCONF & NETMOD filters as Walker originally intended.)

Hi Walker,

   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?
<walker>  It’s good to clarify the mechanism suggested.
 >>If there are other specific behaviors needed for call-home behavior, what are they?
Call-home feature need some additional parameters, where we need specify here or just add a reference to call-home configuration ?
>> Are these something that can vary by transport protocol and implementation?
I think it need.  New transport protocol can add there choice/case.
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?
<walker> does not have one use case now, just think it may be better.
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."
<walker>ok, I agree.
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.
<ALEX> One other aspect beyond the receiver:  When you indicate “time is enough to send all the data in a cycle”, are you referring to a scenario where the interval in which to send data is too short to allow for transmission of all the data?  In such a case, a publisher would fall further and further behind.  Really, this is a case where a publisher should basically suspend or abort the subscription, as it can’t keep up.  We should state this clearly in the text.  The tricky part is of course that some of it may be of temporal nature due to, for example, a temporary increase in list size or a large number of updates, which may subside later – this would be reason to initially suspend (and later resume), before terminating the subscription outright.  Again, we will update the text more clearly.
</ALEX
<walker> I think Alex’s suggestion is better. And as Eric mentioned the server can give one error reason when send suspend notification, it can be define clearly in text.
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?
<walker> yeah, I think your suggestion is good, we can add one feature.
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.
<walker> Both will be ok, may be we can here others ‘ opinions firstly.
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.

<ALEX> We currently state: “Subscriptions created by configuration operations cannot be modified [respectively deleted] via this RPC.”

<<Eric>> It is true that the YANG model doesn’t expose identifiers for the transport session which is used for a dynamic subscription.  But these bindings will still be known within the publisher.  So it is viable to enforce such a constraint.  I believe it improves security as well.   If there is an administrator which needs to tear down the dynamic subscription, the kill-subscription RPC is available.

<</Eric>>

<walker> I think it’s better to describe it clearly in text, otherwise someone else may be different understanding.

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)

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 8 May 2017 16:04:00 +0000

Hi Walker,

Thanks.  Some thoughts added.  See: <:Eric:>

From: Zhengguangying, May 8, 2017 4:18 AM

Hi Eric, Alex

Walker

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: 2017年5月3日 21:57
To: Alexander Clemm; Zhengguangying (Walker)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

Hi Walker,

<:Eric:> As the mechanism is likely to be tied to transport, we can improve the definitions in the two transport documents.
Call-home feature need some additional parameters, where we need specify here or just add a reference to call-home configuration ?
<:Eric:> Could you list any additional subscription specific parameters?  Maybe you are thinking security credentials?   I have been hoping this security functions could be accomplished via existing device security tooling, and much of this tooling shouldn’t be subscription specific.
I think it need.  New transport protocol can add there choice/case.
<:Eric:> How about via identities?  Right now, HTTP2 and NETCONF are viable transports included by identity in the “protocol” object.
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?
<walker> does not have one use case now, just think it may be better.
<:Eric:> Let’s await a use case before changing.  If we allow the encoding of millisecond-level definition, platforms will perceive they need to support such intervals.  And as millisecond level is far more likely to run into internal platform level scheduling issues, there would be push-back.  I am hoping we can avoid that complication.
2.       …
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.
<ALEX> One other aspect beyond the receiver:  When you indicate “time is enough to send all the data in a cycle”, are you referring to a scenario where the interval in which to send data is too short to allow for transmission of all the data?  In such a case, a publisher would fall further and further behind.  Really, this is a case where a publisher should basically suspend or abort the subscription, as it can’t keep up.  We should state this clearly in the text.  The tricky part is of course that some of it may be of temporal nature due to, for example, a temporary increase in list size or a large number of updates, which may subside later - this would be reason to initially suspend (and later resume), before terminating the subscription outright.  Again, we will update the text more clearly.
</ALEX
<walker> I think Alex’s suggestion is better. And as Eric mentioned the server can give one error reason when send suspend notification, it can be define clearly in text.
<:Eric:> Updated the text, and passed the edit token to Alex.  Alex, if you think it doesn’t cover your thoughts, tweak as necessary.
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".
…
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.
<walker> Both will be ok, may be we can here others ‘ opinions firstly.
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.

<</Eric>>

<:Eric:> The subscribed-notifications section 4.1 modify and 4.2 delete subscription text says “The <****-subscription> operation permits changing the terms of an existing dynamic subscription previously established on that transport session.”   Let me know if something else is needed.

Eric

…

Thanks & Regards
Walker (Guangying zheng)

---

From: "Alexander Clemm" <[email-masked]>
Date: Mon, 8 May 2017 23:38:17 -0700

Hi,

I think we are basically in agreement, and we will update the text.  (As
Eric mentioned, I am currently holding the edit token.)

One comment re: call-home.  I don’t think anything else is needed here,
really; clearly call-home is something we had in mind all along for
configured subscriptions and I think the spec contains everything that is
needed but if you think something is missing, please point it out.  Also, on
timeticks, I agree with Eric we should keep in place what we have now unless
we come across a good reason (e.g. use case) for changing.

Cheers

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Monday, May 8, 2017 9:04 AM
To: Zhengguangying (Walker) <[email-masked]>; Alexander Clemm
<[email-masked]>
Cc: Liubin (Nickylba) <[email-masked]>; Zhuzhiguo (Zhuzhiguo,
CSD) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [netmod] hi Alex, Eric and design team guys some comments for
YANG-push and subscribed-notifications, please help to confirm

Hi Walker,

Hi Eric, Alex

   Thanks for your your excellent response, for some doubt I have add small
items inline <walker> .

Walker

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: 2017年5月3日 21:57
To: Alexander Clemm; Zhengguangying (Walker)
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]>
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push
and subscribed-notifications, please help to confirm

(Moving lots of people to ‘BCC’ so that this thread can traverse NETCONF &
NETMOD filters as Walker originally intended.)

Hi Walker, thank you for your review and comments, and Eric, for your
excellent response, to which I have little to add except a few small items
inline <ALEX>

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, May 02, 2017 9:52 AM
To: Zhengguangying (Walker) <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:ludwig@clemm.
org> ; [email-masked] <mailto:[email-masked]> ; 'Balazs Lengyel'
<[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> ; Ambika Prasad Tripathy (ambtripa)
<[email-masked] <mailto:[email-masked]> >; 'Kent Watsen'
<[email-masked] <mailto:[email-masked]> >; Hector Trevino
(htrevino) <[email-masked] <mailto:[email-masked]> >; Einar
Nilsen-Nygaard (einarnn) <[email-masked] <mailto:[email-masked]> >;
Guopeipei (Peipei Guo) <[email-masked] <mailto:[email-masked]>
>; Alberto Gonzalez Prieto (albertgo) <[email-masked]
<mailto:[email-masked]> >; 'Andy Bierman' <[email-masked]
<mailto:[email-masked]> >; 'Chisholm, Sharon' <[email-masked]
<mailto:[email-masked]> >; Yangang <[email-masked]
<mailto:[email-masked]> >; Alexander Clemm <[email-masked]
<mailto:[email-masked]> >; 'Susan Hares' <[email-masked]
<mailto:[email-masked]> >; Tim Jenkins (timjenki) <[email-masked]
<mailto:[email-masked]> >; 'Scharf, Michael (Nokia - DE)'
<[email-masked] <mailto:[email-masked]> >; Rohit
pobbathi <[email-masked] <mailto:[email-masked]> >;
'MehmetErsue' <[email-masked] <mailto:[email-masked]> >; Mahesh
Jethanandani (mahesh) <[email-masked] <mailto:[email-masked]> >
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push
and subscribed-notifications, please help to confirm

Hi Walker,

Hi Alex, Eric and all,

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

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.

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?

<:Eric:> As the mechanism is likely to be tied to transport, we can improve
the definitions in the two transport documents.

 >>If there are other specific behaviors needed for call-home behavior, what
are they?

Call-home feature need some additional parameters, where we need specify
here or just add a reference to call-home configuration ?

<:Eric:> Could you list any additional subscription specific parameters?
Maybe you are thinking security credentials?   I have been hoping this
security functions could be accomplished via existing device security
tooling, and much of this tooling shouldn’t be subscription specific.

<:Eric:> How about via identities?  Right now, HTTP2 and NETCONF are viable
transports included by identity in the “protocol” object.

<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?

<:Eric:> Let’s await a use case before changing.  If we allow the encoding
of millisecond-level definition, platforms will perceive they need to
support such intervals.  And as millisecond level is far more likely to run
into internal platform level scheduling issues, there would be push-back.  I
am hoping we can avoid that complication.

2.       …

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.\

<ALEX> One other aspect beyond the receiver:  When you indicate “time is
enough to send all the data in a cycle”, are you referring to a scenario
where the interval in which to send data is too short to allow for
transmission of all the data?  In such a case, a publisher would fall
further and further behind.  Really, this is a case where a publisher should
basically suspend or abort the subscription, as it can’t keep up.  We
should state this clearly in the text.  The tricky part is of course that
some of it may be of temporal nature due to, for example, a temporary
increase in list size or a large number of updates, which may subside later
- this would be reason to initially suspend (and later resume), before
terminating the subscription outright.  Again, we will update the text more
clearly.

</ALEX

<walker> I think Alex’s suggestion is better. And as Eric mentioned the
server can give one error reason when send suspend notification, it can be
define clearly in text.

<:Eric:> Updated the text, and passed the edit token to Alex.  Alex, if you
think it doesn’t cover your thoughts, tweak as necessary.

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> 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.

<ALEX> We currently state: “Subscriptions created by configuration
operations cannot be modified [respectively deleted] via this RPC.”
You are suggesting to be stronger than that, i.e. not allow a dynamic
subscription to be touched by any transport session other than the one over
which it was created.  I am not sure of this, can you elaborate a bit
further?  Basically this would imply needing to keep track of which session
created which object or dynamic subscription, something the framework does
not currently keep track of (but that is perhaps a bit i2rs-ish). </ALEX>

<<Eric>> It is true that the YANG model doesn’t expose identifiers for the
transport session which is used for a dynamic subscription.  But these
bindings will still be known within the publisher.  So it is viable to
enforce such a constraint.  I believe it improves security as well.   If
there is an administrator which needs to tear down the dynamic subscription,
the kill-subscription RPC is available.

<</Eric>>

<walker> I think it’s better to describe it clearly in text, otherwise
someone else may be different understanding.

<:Eric:> The subscribed-notifications section 4.1 modify and 4.2 delete
subscription text says “The <****-subscription> operation permits changing
the terms of an existing dynamic subscription previously established on that
transport session.”   Let me know if something else is needed.

Eric

…

Thanks & Regards

Walker (Guangying zheng)