Subject: Re: [Netconf] YangPush now

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Mon, 16 Jul 2018 23:10:52 +0000

Hi,

As an implementor of the drafts, I suggest enough already: we've been going down this path for quite some time.

Please publish both sets (dynamic and configured, and SN and YP) together.

Thanks,

Tim

> Hi,
> 
> It might be useful (at least to me), if the draft authors could explicitly indicate what their preference is, and also which of the choices below they think would lead to the work completing most quickly.
>
> Thanks,
> Rob
>
>
> On 12/07/2018 19:48, Kent Watsen wrote:
> I would like to strongly +1 retaining the configured subscriptions 
> (not necessarily in the Push draft itself for the sake of expediting 
> WGLC or
> modularity)
> Ah, so here's another hum question: with or without yang push.
>
> hums now are:
>
>  1. dynamic subscriptions ~ configured subscriptions
>   a. dynamic first, then configured (published sequentially)
>  b. dynamic and configure together (published in parallel)
>
>   2. subscribed-notifications ~ yang-push
>     a. SN first, then YP  (published sequentially)
>     b. SN and YP together (published in parallel)
>
> Eric/Alex: please include a slide with this somewhere in your preso.
>
> Thanks,
> Kent // chair

_______________________________________________
Netconf mailing list
mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

-- 
Cisco Systems Canada Co.
2000 Innovation Drive
Kanata, ON, Canada, K2K 3E8
Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2018 07:50:30 +0200

I do not think that configured subscriptions have been fully worked
out. Nor do I see how I configure something that actually works.
Since you have implemented this, perhaps you can help me to understand
how all this actually works with the text in the current IDs.

/js

On Mon, Jul 16, 2018 at 11:10:52PM +0000, Tim Jenkins (timjenki) wrote:
> [email-masked]

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

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Tue, 17 Jul 2018 13:20:55 +0000

Juergen,

To flip this around, I don’t understand where the difficulties are.

But here’s what I see:

  1.  The format of the update notifications should be the same whether the subscription is dynamic or configured for a given transport and encoding. I believe we have that.
  2.  There are some differences in out of band notifications when I last read the drafts in details; these were explained by the different connection setup contexts. But this is otherwise unrelated to configured subscriptions.
  3.  Since the transport specific details are now separate from the base line drafts, it allows transport specific behaviour to decide how the connections (for configured subscriptions) are to be setup. We have usable variations of “call home” or “dial out” or whatever you want to call it for the cases we need. Admittedly, we do have to provide augmentations for some of the protocols, but then, that’s the intent of the design.

BTW, my comment below was sent last week. I have no idea how/why it arrived on the list after the IETF meeting yesterday.

Tim

From: Juergen Schoenwaelder <[email-masked]>
Reply-To: Juergen Schoenwaelder <[email-masked]>
Date: Tuesday, July 17, 2018 at 1:50 AM
To: "Tim Jenkins (timjenki)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] YangPush now

/js

[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2018 19:20:36 +0200

I see several pieces but I do not see how the pieces give me a
workable solution nor do I see how such a solution gives me
interoperability.

If I configure a subscription, how does the flow of notifications work
over NC and RC? How do I configure where the connection goes?  What is
the RC resource that provides me the notification stream?  How will
all of this work if the endpoints in the future want to negotiate
different encodings?

Since you said you implemented this: What exactly did you implement,
what did not leave out, what did have to add to make it work?

/js

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Tue, 17 Jul 2018 18:53:08 +0000

Please see embedded, with prefix [Tim]. Note some editing of the original to separate the questions.

On 2018-07-17, 1:21 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

[Tim] Even with your questions below, it's still not clear to me what would be missing. 
    
    over NC and RC?

[Tim] NETCONF message flows are described in draft-ietf-netconf-subscribed-notifications, Appendix A.3.   RESTCONF is not in WGLC yet, but can be seen at draft-ietf-netconf-restconf-notif, Appendix B.2

    How do I configure where the connection goes?

[Tim] Since we don't implement netconf-server.yang, we do vendor specific stuff to link each receiver to our local call home/dial-out configuration.  There are lots of moving parts here, and we don't expect interoperability for quite a while.  This lack of interoperability is not a result of these subscription drafts though, so waiting for or making a model dependency to pending IETF work in this space will only make things more confusing and add further unnecessary delay to the process.

    What is
    the RC resource that provides me the notification stream?

[Tim] Current NETCONF implementation doesn't need this.  RESTCONF isn't used for configured subscriptions.

   How will

[Tim] Configured subscriptions aren't negotiable. However, negotiation is defined in the drafts for dynamic subscriptions. I think you can find more on that using a search of the text "configurable-encoding" within the YANG model of draft-ietf-netconf-subscribed-notifications.

[Tim] As configured subscriptions are not available in a public release at this point, I am not ready to give a full answer.
For dynamic subscriptions, you can see what is currently available at <https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1681>. Search on "push", for example <https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1681/ietf-yang-push.yang>. We have been deferring upgrading our IETF model version until this work is released from WGLC.  We don't want to make our users iterate model versions when the functional difference is quite low.
    
    /js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2018 21:32:24 +0200

> [Tim] NETCONF message flows are described in draft-ietf-netconf-subscribed-notifications, Appendix A.3.   RESTCONF is not in WGLC yet, but can be seen at draft-ietf-netconf-restconf-notif, Appendix…

There is no A.3 in draft-ietf-netconf-subscribed-notifications. Perhaps
you mean draft-ietf-netconf-netconf-event-notifications-10. No, this
example does not help me understand how notification messages flow. It
only shows how I create a configured subscription.
 
> [Tim] Since we don't implement netconf-server.yang, we do vendor specific stuff to link each receiver to our local call home/dial-out configuration.  There are lots of moving parts here, and we don…

So you agree that the solution is incomplete.
 
> [Tim] Current NETCONF implementation doesn't need this.  RESTCONF isn't used for configured subscriptions.

Well, I do not really know how NETCONF notifications flow. There were
comments raised concerning the use of call home and the need to have a
<hello> exchange etc. There are pieces, but not a workable solution.
 
> [Tim] Configured subscriptions aren't negotiable. However, negotiation is defined in the drafts for dynamic subscriptions. I think you can find more on that using a search of the text "configurable…

So this again seems to depend on transports that are not ready yet. I
am also not sure that you want to replace negotiation of encodings in
the protocols with explicit configuration in the first place but that
is at the end just a minor inconvenience issue. In RC, the client can
easily send an Accept header to negotiate the encoding. If NC does
ever support multiple encodings, this will likely be negotiated
dynamically via the <hello> exchange.

/js

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Tue, 17 Jul 2018 20:50:05 +0000

On 2018-07-17, 3:33 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

[Tim2] Correction to what I put above: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications#appendix-A.3.1 

    So you agree that the solution is incomplete.
[Tim2] Please re-read what I wrote. At no point did I say "the solution" is incomplete.

...

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Jul 2018 14:05:41 -0700

Hi,

I agree with Juergen that there are TBD features in SN.
I also agree with the co-authors that it would be too much work to refactor
now.
It should be faster to complete SN then split it and start over.

The main issues here seem to be:
 1) no end-point for the configured receiver
 2) CallHome procedures and server requirements such as
     processing normal NC or RC requests on the session
 3) no MUST or SHOULD implement values for transport

I would like to get YANG Push done but not at the expense of the review
cycles.
There is nothing stopping the WG from working faster (e.g. virtual interim).
Just declaring everything done gets it out of the WG faster,
but may not mean the RFC will be out faster.

Andy

Andy

On Tue, Jul 17, 2018 at 10:20 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> >   1.  The format of the update notifications should be the same whether
> the subscription is dynamic or configured for a given transport and
> encoding. I believe we have that.
> >   2.  There are some differences in out of band notifications when I
> last read the drafts in details; these were explained by the different
> connection setup contexts. But this is otherwise unrelated to configured
> subscriptions.
> >   3.  Since the transport specific details are now separate from the
> base line drafts, it allows transport specific behaviour to decide how the
> connections (for configured subscriptions) are to be setup. We have usable
> variations of “call home” or “dial out” or whatever you want to call it for
> the cases we need. Admittedly, we do have to provide augmentations for some
> of the protocols, but then, that’s the intent of the design.
> >
> > BTW, my comment below was sent last week. I have no idea how/why it
> arrived on the list after the IETF meeting yesterday.
> >
> > Tim
> >
> > --
> > Cisco Systems Canada Co.
> > 2000 Innovation Drive
> > As an implementor of the drafts, I suggest enough already: we've been
> going down this path for quite some time.
> > > It might be useful (at least to me), if the draft authors could
> explicitly indicate what their preference is, and also which of the choices
> below they think would lead to the work completing most quickly.
> > >
> > > Thanks,
> > > Rob
> > >
> > >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Jul 2018 03:41:19 +0000

From: Andy Bierman, July 17, 2018 5:06 PM

Hi,

I also agree with the co-authors that it would be too much work to refactor now.
It should be faster to complete SN then split it and start over.

<Eric> There should not be any endpoint in SN.   Endpoint specifics would need to be exposed in the transport document.

Note that we tried for years to have something transport independent for receivers in SN.   I.e., there was an endpoint “address” in the SN from 00-v13.   Kent and Martin argued it out of the SN draft.  For more on this, there is plenty extensive email alias archive on this subject.   As a result, with v14, “address” is gone.

To summarize Kent & Martin’s argument which led to the v14 change: current endpoint “address” might be confused with call home.  We won’t agree with anything that might conflict with call home.  It is better to do nothing if we can’t agree on something.  By doing nothing, vendors can augment in what is needed.

For v14 we didn’t just ignore the hole removing “address” made of course.  Many email iterations over the last several months have proposed YANG augmentation code for those people who *do* want a leafref to netconf-server.yang now.  So if it makes this “endpoint completeness” issue go away, I would happily put an informational appendix into NETCONF-notif.  This appendix would include the necessary augmentations to the leafref which Kent and I worked through.

But we should go no farther than an informational appendix on this.  The current solution of doing nothing is actually a far more compelling answer than the inserting a mandatory (but then deviated away) leafref to an unimplemented ietf call home model.   This would allow the “solution is complete” answer to match to what dominates the industry: vendors who have their own key and call home infrastructure.

This is described in draft-ietf-netconf-netconf-event-notifications, section 5.2.

This is on purpose.  IoT is not going to want a NETCONF transport default.   The current draft allows identities to be added for transports supported by a platform.  It is not possible to configure a transport the platform doesn’t have.

I would like to get YANG Push done but not at the expense of the review cycles.
There is nothing stopping the WG from working faster (e.g. virtual interim).

If the WG chairs agreed to a final set of issues as input to the meeting.  And agreed to abide by what came out of this interim as binding, final consensus, it might be a possibility.

Topics #1 & #2 above are transport specific.  It would seem getting SN & YP to review beyond the WG should speed the final process.

Eric

Andy

Andy

On Tue, Jul 17, 2018 at 10:20 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
I see several pieces but I do not see how the pieces give me a
workable solution nor do I see how such a solution gives me
interoperability.

/js

On Tue, Jul 17, 2018 at 01:20:55PM +0000, Tim Jenkins (timjenki) wrote:
> From: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
> Reply-To: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
> To: "Tim Jenkins (timjenki)" <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> > Ah, so here's another hum question: with or without yang push..
> >
> > hums now are:
> >
> mailto:[email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Jul 2018 23:51:58 -0700

Hi,

I do not see much standards value in the configured subscriptions, from a
client developer's POV.
They are optional to implement and require vendor-specific details to be
usable.

I can't think of any use-cases where the receiver has perfect knowledge of
the
configured subscriptions (and is therefore ready to start receiving
notifications
on those subscriptions without any operations) yet cannot invoke
<establish-subscription>
once the CallHome session is established.  This seems to be a subjective
design choice.

I am OK with the configured subscriptions only because I have no intention
of
implementing it at this time.  I can see how other reviewers within the
IETF may not be willing
to give such a free pass.

There is no rule that says  standard has to be complete and cannot depend
on other pieces
still under development.  Seems to me YANG Push will be stuck in MISREF
state for awhile anyway,
but all these external dependencies are by design choice, so the WG must be
OK with the
delays that this will cause.

Andy

On Tue, Jul 17, 2018 at 8:41 PM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Andy Bierman, July 17, 2018 5:06 PM
>
>
>
> Hi,
>
>
>
> <Eric> There should not be any endpoint in SN.   Endpoint specifics would
> need to be exposed in the transport document.
>
>
>
> Note that we tried for years to have something transport independent for
> receivers in SN.   I.e., there was an endpoint “address” in the SN from
> 00-v13.   Kent and Martin argued it out of the SN draft.  For more on this,
> there is plenty extensive email alias archive on this subject.   As a
> result, with v14, “address” is gone.
>
>
>
> To summarize Kent & Martin’s argument which led to the v14 change: current
> endpoint “address” might be confused with call home.  We won’t agree with
> anything that might conflict with call home.  It is better to do nothing if
> we can’t agree on something.  By doing nothing, vendors can augment in what
> is needed.
>
>
>
> For v14 we didn’t just ignore the hole removing “address” made of course.
> Many email iterations over the last several months have proposed YANG
> augmentation code for those people who *do* want a leafref to
> netconf-server.yang now.  So if it makes this “endpoint completeness” issue
> go away, I would happily put an informational appendix into NETCONF-notif.
> This appendix would include the necessary augmentations to the leafref
> which Kent and I worked through.
>
>
>
> But we should go no farther than an informational appendix on this.  The
> current solution of doing nothing is actually a far more compelling answer
> than the inserting a mandatory (but then deviated away) leafref to an
> unimplemented ietf call home model.   This would allow the “solution is
> complete” answer to match to what dominates the industry: vendors who have
> their own key and call home infrastructure.
>
>
>
>
>
> This is on purpose.  IoT is not going to want a NETCONF transport default.
>   The current draft allows identities to be added for transports supported
> by a platform.  It is not possible to configure a transport the platform
> doesn’t have.
>
>
>
> If the WG chairs agreed to a final set of issues as input to the meeting.
> And agreed to abide by what came out of this interim as binding, final
> consensus, it might be a possibility.
>
>
>
> Topics #1 & #2 above are transport specific.  It would seem getting SN &
> YP to review beyond the WG should speed the final process.
>
>
>
> Eric
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> <https://maps.google.com/?q=2000+Innovation+Drive+%0D%0A+Kanata,+ON,+Canada,+K2K+3E8&entry=gmail&source=g>
> <https://maps.google.com/?q=2000+Innovation+Drive+%0D%0A+Kanata,+ON,+Canada,+K2K+3E8&entry=gmail&source=g>
> <https://maps.google.com/?q=2000+Innovation+Drive+%0D%0A+Kanata,+ON,+Canada,+K2K+3E8&entry=gmail&source=g>
> <https://maps.google.com/?q=2000+Innovation+Drive+%0D%0A+Kanata,+ON,+Canada,+K2K+3E8&entry=gmail&source=g>
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2018 15:32:00 +0200

> To summarize Kent & Martin’s argument which led to the v14 change: current endpoint “address” might be confused with call home.  We won’t agree with anything that might conflict with call home.  It…

So the standard is unusable without vendor augmentations, which are
likely then not interoperable. If you go forward with this, I think
this needs to be spelled out clearly in the document writeup so that
the IESG can think about this.
 
> But we should go no farther than an informational appendix on this.  The current solution of doing nothing is actually a far more compelling answer than the inserting a mandatory (but then deviated…

Clearly, an address alone is not sufficient. What is needed is a
concrete link to the configuration models. Right now we have:

   The method of identifying the targeted recevier IP address, port, and
   security credentials are left up to implementers of this
   specification.  For implementation guidance and a YANG model for this
   function, please look to
   [I-D.draft-ietf-netconf-netconf-client-server].

I am not sure this is concrete enough. What exactly does one have to
augment in?

> This is described in draft-ietf-netconf-netconf-event-notifications, section 5.2.

And I commented that I disagree with the solution and there was
discussion on the mailing. Ignoring comments does not make them go
away. I believe you can't simply overwrite call-home steps and I
believe after call-home NC starts and NC starts with a <hello>
exchange. And then, is it reasonable to throw notifications at the
client without having its consent? A poor client not expecting to
receive notifications will likely close the session and you likely
call the poor client again, potentially forming an ugly loop.

> This is on purpose.  IoT is not going to want a NETCONF transport default.   The current draft allows identities to be added for transports supported by a platform.  It is not possible to configure…

I do not buy the IoT argument. What is wrong with requiring that a
NETCONF server must support at least the NETCONF transport and that
a RESTCONF server must support at the RESTCONF transport?

/js

PS: There were also issues raised concerning the "RESTCONF transport"
    which really is not a RESTCONF transport but some new HTTP/2
    transport. I think this also needs to be resolved before that
    document can move.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Jul 2018 09:41:00 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, July 18, 2018 9:32 AM
> 
> receivers in SN.   I.e., there was an endpoint “address” in the SN from 00-
> v13.   Kent and Martin argued it out of the SN draft.  For more on this, there
> is plenty extensive email alias archive on this subject.   As a result, with v14,
> “address” is gone.
> >
> > To summarize Kent & Martin’s argument which led to the v14 change:
> current endpoint “address” might be confused with call home.  We won’t
> agree with anything that might conflict with call home.  It is better to do
> nothing if we can’t agree on something.  By doing nothing, vendors can
> augment in what is needed.
> 
> So the standard is unusable without vendor augmentations, 

Every solution needs to define boundaries to its scope.  Here it is reasonable to spit subscription configuration from transport connection / keystore configuration.   We have designed the solution so that transport implementations can layer in what they need.   I think it would be great if the industry implements draft-ietf-netconf-netconf-client-server when that document completes.   Until then, reality is that solutions must integrate with embedded vendor embodiments RFC-8071. 

> which are likely then not interoperable.

Yes.  Vendor model based configuration is needed until IETF model based configuration completes its definition and implementation. 

> If you go forward with this, I think this needs to be
> spelled out clearly in the document writeup so that the IESG can think
> about this.

That is what I was hoping would be accomplished with the text:

   The method of identifying the targeted receiver IP address, port, and
   security credentials are left up to implementers of this
   specification.  For implementation guidance and a YANG model for this
   function, please look to
   [I-D.draft-ietf-netconf-netconf-client-server].

> > For v14 we didn’t just ignore the hole removing “address” made of
> course.  Many email iterations over the last several months have proposed
> YANG augmentation code for those people who *do* want a leafref to
> go away, I would happily put an informational appendix into NETCONF-
> notif.  This appendix would include the necessary augmentations to the
> leafref which Kent and I worked through.
> >
> complete” answer to match to what dominates the industry: vendors who
> have their own key and call home infrastructure.
> 
> Clearly, an address alone is not sufficient. What is needed is a concrete link
> to the configuration models. Right now we have:
> 

Either the IP address, port, and security credentials, or a leafref pointing to these objects.
 
> And I commented that I disagree with the solution and there was discussion
> on the mailing. Ignoring comments does not make them go away. I believe
> you can't simply overwrite call-home steps 

I don't recall that the issue of this solution not being permitted to refine call-home steps being raised before. 

> I believe after call-home NC
> starts and NC starts with a <hello> exchange. 

Agree. 

> And then, is it reasonable to
> throw notifications at the client without having its consent? A poor client
> not expecting to receive notifications will likely close the session and you
> likely call the poor client again, potentially forming an ugly loop.

To cover this, there is the following text in Section 5 of draft-ietf-netconf-netconf-event-notifications:

   publisher SHOULD place the receiver into the
   "timeout" state after a predetermined number of either failed call
   home attempts or NETCONF sessions remotely terminated by the
   receiver.

   Until NETCONF transport with a receiver has been established, and a
   "subscription-started" state change notification has been
   successfully sent for a configured subscription, that subscription's
   receiver MUST remain in either the "connecting" or the "timeout"
   state.

> The current draft allows identities to be added for transports supported by
> a platform.  It is not possible to configure a transport the platform doesn’t
> have.
> >
> 
> NETCONF server must support at least the NETCONF transport and that a
> RESTCONF server must support at the RESTCONF transport?

Ahh.  I thought you meant that there should be a default transport for SN alone.    SN in section 1.0 & the end of 5.3 points to transport documents for such guidance.

Then looking at Section 1.0 in draft-ietf-netconf-netconf-event-notification: 

   This document provides a binding for events streamed over the NETCONF
   protocol [RFC6241] as per
   [I-D.draft-ietf-netconf-subscribed-notifications].  In addition, as
   [I-D.ietf-netconf-yang-push] is itself built upon
   [I-D.draft-ietf-netconf-subscribed-notifications], this document
   enables a NETCONF client to request and receive updates from a YANG
   datastore located on a NETCONF server.

Eric

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Thu, 19 Jul 2018 13:43:17 +0000

Please see [Tim] below.

From: Andy Bierman <[email-masked]>
Date: Wednesday, July 18, 2018 at 2:52 AM
To: "Eric Voit (evoit)" <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>, "Tim Jenkins (timjenki)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] YangPush now

Hi, 

I do not see much standards value in the configured subscriptions, from a client developer's POV.
They are optional to implement and require vendor-specific details to be usable.
[Tim] I agree that for configured subscriptions, we will need to match to vendor-specific implementation specifics for the foreseeable future.

I can't think of any use-cases where the receiver has perfect knowledge of the
configured subscriptions (and is therefore ready to start receiving notifications
on those subscriptions without any operations) yet cannot invoke <establish-subscription>
once the CallHome session is established.  This seems to be a subjective design choice.
[Tim] From the beginning of the specifications, configured subscriptions didn’t require the use of YANG RPCs.   Cisco’s DNAC controller operates without invoking YANG RPCs, and uses configured subscriptions today.

I am OK with the configured subscriptions only because I have no intention of 
implementing it at this time.  I can see how other reviewers within the IETF may not be willing
to give such a free pass.

There is no rule that says  standard has to be complete and cannot depend on other pieces
still under development.  Seems to me YANG Push will be stuck in MISREF state for awhile anyway,
but all these external dependencies are by design choice, so the WG must be OK with the
delays that this will cause.  
[Tim] In the current drafts, there are no external dependencies to non-RFC call home specifications.  I believe the authors’ intents for this is to avoid such a MISREF.

Andy

Hi,

 

 

 

 

 
 
Eric

Andy

 
Andy

On Tue, Jul 17, 2018 at 10:20 AM, Juergen Schoenwaelder <[email-masked]> wrote:
I see several pieces but I do not see how the pieces give me a
workable solution nor do I see how such a solution gives me
interoperability.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2018 08:02:07 -0700

On Thu, Jul 19, 2018 at 6:43 AM, Tim Jenkins (timjenki) <[email-masked]>
wrote:

> Cc: Juergen Schoenwaelder <[email-masked]>, "Tim
> Jenkins (timjenki)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> [Tim] I agree that for configured subscriptions, we will need to match to
> vendor-specific implementation specifics for the foreseeable future.
>
>

This makes the module look like a just another proprietary YANG module to
clients.

> [Tim] From the beginning of the specifications, configured subscriptions
> didn’t require the use of YANG RPCs.   Cisco’s DNAC controller operates
> without invoking YANG RPCs, and uses configured subscriptions today.
>
>

Standards are much more useful on the client-side if there is at least one
known
value that can be used for each object.  This module standardizes what to
push,
not really how to push.  In theory that can be defined elsewhere and this
module
just reflects which method is in use.

Andy

> [Tim] In the current drafts, there are no external dependencies to non-RFC
> call home specifications.  I believe the authors’ intents for this is to
> avoid such a MISREF.
>
>
> Andy
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jul 2018 16:12:00 +0000

To address some of the concerns being raise here, I suggest the following:

1. make the augmentation of a "notif" model mandatory (see the '+' lines
   below), to ensure that there is always something more than just a name
   being configured per receiver.

      container receivers {
        list receiver {
          key "name";
          min-elements 1;
          leaf name {
            type string;
          }
   +      choice transport {
   +        mandatory true;
   +        description
   +          "Defines the transport-specific configuration data
   +           for the selected transport.";
   +      }

2. modify netconf-notif to augment-in the ietf-netconf-server grouping:

  module ietf-netconf-notifications {
    prefix nn;
    import ietf-netconf-server { prefix ncs; }
    import ietf-subscribed-notifications { prefix sn; }

    // define a *local* netconf-server instance
    container "netconf-server" {
      uses "ncs:netconf-server-grouping" {
        // prune out the "listen" subtree
        refine "listen" {
          if-feature "never-supported-feature";
        }
        // disable dependency on the "call-home" feature
        refine "call-home" {
          if-feature "true"; // needed? (see 7950, s7.20.2, P3)
                             // valid? (unsure)
        }
      }
    }

    // add leafref to above locally-configured call-home instances
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      leaf netconf-endpoint {
        type leafref {
          path "/nn:netconf-server/nn:call-home/nn:netconf-client/nn:name";
        }
      }
    }
  }

3. do the identical thing to the restconf-nofif draft:

  module ietf-restconf-notifications {
    prefix rn;
    import ietf-restconf-server { prefix rcs; }
    import ietf-subscribed-notifications { prefix sn; }

    // define a *local* restconf-server instance
    container "restconf-server" {
      uses "rcs:restconf-server-grouping" {
        // prune out the "listen" subtree
        refine "listen" {
          if-feature "never-supported-feature";
        }
        // disable dependency on the "call-home" feature
        refine "call-home" {
          if-feature "true"; // needed? (see 7950, s7.20.2, P3)
                             // valid? (unsure)
        }
      }
    }

    // add leafref to above locally-configured call-home instances
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      leaf restconf-endpoint {
        type leafref {
          path "/rn:restconf-server/rn:call-home/rn:netconf-client/rn:name";
        }
      }
    }
  }

Doing so would fill in the missing piece folks are asking to see.  Yes, 
it introduces a normative reference to the client/server work, but it is
consistent with the result from Monday's NETCONF "dynamic ~ configured"
discussion and, besides, that work seems almost done now.

There still might be an issue regarding the server pushing notifications
immediately after the NC/RC session starts, but I feel that by having a
*conf-server instance inside the "notif" model, we can more easily claim
that the behavior is okay.

The current restconf-notif draft is more https-focused, but I feel that,
if there is a goal to have a plain-https transport, then that should be
defined in a separate "https-notif" draft.

Currently the restconf-client-server model does not enable the 
configuration of the "http-version" to be used.  I cringe to say this,
but we might consider introducing an "https-client-server" draft that
the "restconf-client-server" draft could be refactored to depend on.
If this were done, then said "https-notif" draft could use the "https-
client-grouping", and thus be consistent with the pattern we're 
establishing here.

To address the interoperability issue, it seems we either: 1) define
a super-simple mandatory-to-implement "notif" layer (I would recommend
https-client for this) or 2) a good mandatory-to-implement "notif"
layer (e.g., binary over DTLS and per line-card, per the udp-pub-channel
draft), or 3) do nothing, leaving it to the market to decide, similar
to how RFC 8040 doesn't require a specific encoding (XML, JSON, etc.)

Kent  // contributor

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2018 09:55:43 -0700

>    +           for the selected transport.";

The notion of an empty mandatory choice really stretches the definition of
YANG Conformance.
This says you cannot possible implement the SN module without some other
module augmenting it.
Yet there is no way in YANG (besides import) to say the module bar needs to
be present
if module foo is present.

>           if-feature "true"; // needed? (see 7950, s7.20.2, P3)

The use of constant (true or false) values for if-feature are not supported
and
the use of dummy features that are always supposed to be a constant value
seems to abuse the intent of YANG features.

Refactoring the groupings would be the cleanest solution.

>           path "/rn:restconf-server/rn:call-home/rn:netconf-client/rn:

The problem with identityref leafs is that the client has no clue what the
server will support. The problem gets much worse for the client dealing
with a mandatory empty choice.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Jul 2018 19:00:19 +0000

From: Andy Bierman, July 19, 2018 12:56 PM

On Thu, Jul 19, 2018 at 9:12 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

      container receivers {
        list receiver {
          key "name";
          min-elements 1;
          leaf name {
            type string;
          }
   +      choice transport {
   +        mandatory true;
   +        description

The notion of an empty mandatory choice really stretches the definition of YANG Conformance.
This says you cannot possible implement the SN module without some other module augmenting it.
Yet there is no way in YANG (besides import) to say the module bar needs to be present
if module foo is present.

<Eric> One other issue is there is a “transport” leaf at the subscription level which would be redundant with the choice at the receiver level.  Placing it there enforces a decision the WG made at a previous IETF that transport would not vary by receiver.

Extending this, in previous discussions on the mailing list on this topic, I have not seen XPATH able to enforce the same transport case is selected across all receivers.

The use of constant (true or false) values for if-feature are not supported and
the use of dummy features that are always supposed to be a constant value
seems to abuse the intent of YANG features.

<Eric> This refactoring point would suggest that there could be meaningful changes to the netconf-server model.  Which would delay everything.   Better to do a –bis version of NETCONF-Notif when the call home is ready

Andy

<Eric> Per previous discussions on this, I have no problem with the client/server work.

However I do have a problem with establishing this normative dependency due to:
(a) the potential time delay (see Andy’s refactoring point above, the text below, and the fact that netconf-server type drafts have yet to enter WGLC.)
(b) relevance of all this depends on vendors adoption timeframes for netconf-server.

All these point can safely be considered by a –bis draft if call home model standardization considerations are left out of the current set of drafts in WGLC.

Eric

Kent  // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jul 2018 22:58:08 +0000

> The notion of an empty mandatory choice really stretches the definition
> of YANG Conformance.  This says you cannot possible implement the SN
> module without some other module augmenting it.

Correct.

> Yet there is no way in YANG (besides import) to say the module bar
> needs to be present if module foo is present.

Why is this a problem?  Servers will do the right thing, and the draft
is clearer for it.

> The use of constant (true or false) values for if-feature are 

Wasn't sure about that. Is there another way to achieve the same?

> and the use of dummy features that are always supposed to be a
> constant value seems to abuse the intent of YANG features.

This was discussed on the NETMOD list in the last few days.  See
the "removing a node from a grouping" thread.  I agree that it's
not ideal, but it appears to be legal.   Just filed yang-next#48
to track this for future improvement.

> Refactoring the groupings would be the cleanest solution.

Not always possible, such as in this case.

> The problem with identityref leafs is that the client has no clue 
> what the server will support. The problem gets much worse for the
> client dealing with a mandatory empty choice.

How so?  If the server implements the notif module, the augment
shows up, right?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 12:14:19 +0200

>    [I-D.draft-ietf-netconf-netconf-client-server].

I said this is to vague for me to understand. Repeating the pointer does
not help me to understand. If this I-D has a clear solution, why not put
it in place?

>    receiver MUST remain in either the "connecting" or the "timeout"

    <-- call home -->
 C: <hello>
 S: <hello>
 S: <notification>
    <-- session terminated -->

The server believes 'notification has been successfully sent'. The other
alternative would be a client that throws away notification messages not
expected:

    <-- call home -->
 C: <hello>
 S: <hello>
 S: <notification> // -> discarded
 S: <notification> // -> discarded
 S: <notification> // -> discarded
    [...]

Both scenarioes are problematic. This is why I suggested that there
needs to be some mechanism that tells the server that the client is
willing to receive configured subscriptions before the server throws
<notification> messages at the client. You will find differnet ideas
in the mailing list archive.

>    datastore located on a NETCONF server.

Yes. But this text does not say that 'if a NETCONF server supports
configured subscriptions, then it MUST implement the notification
transport as defined in section 5.2 (or whatever the section will be).
This way, a NETCONF client using configured subscriptions would know
one transport that actually works (if the details are fully worked
out). Perhaps this is not what people really want, so I will start
another thread to figure this out.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 20 Jul 2018 18:47:48 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, July 20, 2018 6:14 AM
> 
> I said this is to vague for me to understand. Repeating the pointer does not
> help me to understand. If this I-D has a clear solution, why not put it in
> place?

The recommended solution is for vendors to augment in their own leafrefs into existing vendor specific call home configurations.   Alternatively, solutions can be integrated within non-YANG based configuration structures.  This is how our configured subscription implementation works.  

To clarify the recommended solution, I have updated the reference above to:

The method of identifying the targeted receiver IP address, port, and security credentials are left up to implementers of this specification.  For implementation guidance on how a leafref might constructed to accomplish this function, consider the following augmentation which would need to be made if the necessary connection parameters are maintained with ietf-netconf-client.yang as specified by [I-D.draft-ietf-netconf-netconf-client-server].

  import ietf-netconf-client { prefix ncc; }
  import ietf-subscribed-notifications { prefix sn; }
  import ietf-netconf-subscribed-notifications { prefix nsn; }

  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
   when 'derived-from(../../../transport, "nsn:netconf")';   
   leaf netconf-endpoint {
      type leafref {
        path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server/ncc:endpoints/ncc:endpoint/ncc:name";
      }
      description
        "Points to a remote NETCONF client intended to support a particular configured subscription.";
    }
  }
  
> Both scenarioes are problematic. 

Agree that there are these two scenarios.  

The first scenario isn't elegant, but I don't see it as problematic.  Per SN, transport loss places all receivers back into their connecting state.   And the NETCONF-Notif text quoted above shows that multiple session terminations places the subscription into "timeout" so that something can figure out what is wrong.

The second scenario requires that NETCONF Call home is successfully configured with the right credentials on both sides of the connection, and that the receiver's NETCONF client implementation is unable to terminate a session receiving unwanted notification traffic.  This is a concern, but an implementer at least has some protections by controlling the call home connectivity parameters tied to a specific receiver.   (See continue reasoning below)

> This is why I suggested that there needs to
> be some mechanism that tells the server that the client is willing to receive
> configured subscriptions before the server throws <notification> messages
> at the client. You will find differnet ideas in the mailing list archive.

In talking about this issue in the past, suggestions were made that the NETCONF client could advertise its capabilities for supporting configured subscriptions as part of the hello exchange.  And that can be a partial(*) solution to the problem.  However there was pushback to this based on NETCONF client to server implementations not typically exchanging and interpreting the results of NETCONF client asserted capabilities.  

(*) the reason it is partial is that even if the client advertises support for NETCONF configured subscriptions, there is still the possibility that something goes wrong with the receiver's receiving process with the second scenario above.  In which case you still need to have a way to terminate the incoming notification stream by pulling down the NETCONF session.  Still, there are obviously benefits of client capability signaling as an extra layer of misconfiguration protections included.

Looking at what is in the v10 draft, there are some protections for both your scenarios above.  But certainly it is not robust.   And certainly having the client advertise configured receiver support would be nice, but this would require more development.   As based on the amount of development,  we used the design philosophy of "it is better to start with an 80% solution than a 120% solution :-)."  

I agree that the current protection could have an improved description.  So I have placed the following text into the NETCONF-Notif security considerations section:

" For a configured subscription, if NETCONF call home has been configured with the working credentials, yet that the receiver's NETCONF client implementation is both unable to process inbound notifications and unable to terminate a session receiving unwanted traffic, then the receiver may receive unwanted event records.  To minimize this risk, a publisher implementation should use dedicated call home connectivity port numbers and credentials specific to configured subscriptions.  This will minimize the chance that an unplanned NETCONF receiver will receive configured subscription notifications unexpectedly."
 
> > Ahh.  I thought you meant that there should be a default transport for SN
> alone.    SN in section 1.0 & the end of 5.3 points to transport documents
> for such guidance.
> >
> This way, a NETCONF client using configured subscriptions would know one
> transport that actually works (if the details are fully worked out). 

Added the text to the top of configured subscriptions section:

"To allow the configuration of NETCONF for configured subscription transport, a publisher MUST support the YANG module defined in Section 8.  Advertisement of this module will indicate support the "netconf" transport identity, and therefore the ability to use NETCONF as the selected transport.".

> Perhaps
> this is not what people really want, so I will start another thread to figure
> this out.

See the thread.  Wil reply to it.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jul 2018 16:14:16 +0200

>         "Points to a remote NETCONF client intended to support a particular configured subscription.";

So why do we create a _standard_ that says take the other standard and
then roll your own non-standard module to make them work together?
   
> The second scenario requires that NETCONF Call home is successfully configured with the right credentials on both sides of the connection, and that the receiver's NETCONF client implementation is u…

There is nothing in NETCONF that requires a client to terminate a
session if the client receives an unexpected message. The control of
call home parameters is no answer (first this is out of hands for the
implementor and second the problem is likely a misconfiguration in the
first place that leads to something not useful). I do not think your
answers provide a solution - I am not interested in justifications.
 
> (*) the reason it is partial is that even if the client advertises support for NETCONF configured subscriptions, there is still the possibility that something goes wrong with the receiver's receivi…

Simply pushing data to a receiver before checking that the receiver is
willing and able to consume the data is in my view not good protocol
design. There are cases where this is unavoidable but here we do have
a client and server talking to each other that can do better.

> Looking at what is in the v10 draft, there are some protections for both your scenarios above.  But certainly it is not robust.   And certainly having the client advertise configured receiver suppo…

There was also another proposal, namely to have the client request the
start of notifications (like you would do with RC and SSE). I do not
buy the 80% solution argument for an excuse of poor protocol design.

> " For a configured subscription, if NETCONF call home has been configured with the working credentials, yet that the receiver's NETCONF client implementation is both unable to process inbound notif…

Well, I would rather fix the issue than pushing the problem ultimately
to operators.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 24 Jul 2018 23:56:00 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, July 23, 2018 10:14 AM
> 
> > > I said this is to vague for me to understand. Repeating the pointer
> > > does not help me to understand. If this I-D has a clear solution,
> > > why not put it in place?
> >
> > The recommended solution is for vendors to augment in their own
> leafrefs into existing vendor specific call home configurations.
> Alternatively, solutions can be integrated within non-YANG based
> configuration structures.  This is how our configured subscription
> implementation works.
> >
> security credentials are left up to implementers of this specification.  For
> implementation guidance on how a leafref might constructed to accomplish
> this function, consider the following augmentation which would need to be
> made if the necessary connection parameters are maintained with ietf-
> netconf-client.yang as specified by [I-D.draft-ietf-netconf-netconf-client-
> server].
> >
> >         path "/ncc:netconf-client/ncc:initiate/ncc:netconf-
> server/ncc:endpoints/ncc:endpoint/ncc:name";
> >       }
> >       description

My reading of your request was to make the current draft text less vague.   Hopefully providing an example augmentation based on a referenced standard-in-progress removes this ambiguity.   

I would hope that when the other standard is ready, it doesn't take something non-standard to bind them.  There are earlier threads on how this might be done.

> > > > To cover this, there is the following text in Section 5 of
> > > > draft-ietf-netconf-
> > > netconf-event-notifications:
> > > >
> > > The server believes 'notification has been successfully sent'.  The
> > > other alternative would be a client that throws away notification
> > > messages not
> > > expected:
> > >
> > >     <-- call home -->
> > >  C: <hello>
> > >  S: <hello>
> > The first scenario isn't elegant, but I don't see it as problematic.  Per SN,
> transport loss places all receivers back into their connecting state.   And the
> NETCONF-Notif text quoted above shows that multiple session terminations
> places the subscription into "timeout" so that something can figure out
> what is wrong.
> >
> > The second scenario requires that NETCONF Call home is successfully
> configured with the right credentials on both sides of the connection, and
> that the receiver's NETCONF client implementation is unable to terminate a
> session receiving unwanted notification traffic.  This is a concern, but an
> implementer at least has some protections by controlling the call home
> connectivity parameters tied to a specific receiver.   (See continue reasoning
> below)
> 
> There is nothing in NETCONF that requires a client to terminate a session if
> the client receives an unexpected message. The control of call home
> parameters is no answer (first this is out of hands for the implementor and
> second the problem is likely a misconfiguration in the first place that leads
> to something not useful). I do not think your answers provide a solution - I
> am not interested in justifications.

A solution based on the correct call home parameter configuration does work.  But other than that, I agree with you: the current NETCONF configured subscription solution does take some valid error conditions out of the hands of implementers, and places them in the hands of operators.  

The biggest question I see is whether implementers want to do the leg-work needed to building out the client capability advertisement capability to protect against these failure scenarios.   It would be great if NETCONF implementers signaled they are ready to pick this up.  

> > > This is why I suggested that there needs to be some mechanism that
> > > tells the server that the client is willing to receive configured
> > > subscriptions before the server throws <notification> messages at
> > > the client. You will find differnet ideas in the mailing list archive.
> >
> > In talking about this issue in the past, suggestions were made that the
> NETCONF client could advertise its capabilities for supporting configured
> subscriptions as part of the hello exchange.  And that can be a partial(*)
> solution to the problem.  However there was pushback to this based on
> NETCONF client to server implementations not typically exchanging and
> interpreting the results of NETCONF client asserted capabilities.
> >
> > (*) the reason it is partial is that even if the client advertises support for
> NETCONF configured subscriptions, there is still the possibility that
> something goes wrong with the receiver's receiving process with the second
> scenario above.  In which case you still need to have a way to terminate the
> incoming notification stream by pulling down the NETCONF session.  Still,
> there are obviously benefits of client capability signaling as an extra layer of
> misconfiguration protections included.
> 
> Simply pushing data to a receiver before checking that the receiver is willing
> and able to consume the data is in my view not good protocol design. There
> are cases where this is unavoidable but here we do have a client and server
> talking to each other that can do better.
> 
> > Looking at what is in the v10 draft, there are some protections for both
> your scenarios above.  But certainly it is not robust.   And certainly having
> the client advertise configured receiver support would be nice, but this
> would require more development.   As based on the amount of
> development,  we used the design philosophy of "it is better to start with
> an 80% solution than a 120% solution :-)."
> 
> start of notifications (like you would do with RC and SSE). I do not buy the
> 80% solution argument for an excuse of poor protocol design.

The other proposal is absolutely a valid way to do this.  And as Andy and others have pointed out, the current dynamic <establish-subscription> RPC can be kicked off by such a process.   

However the call flow has more error conditions.   As a result, three years ago during scoping of the current suite of IETF subscription drafts, this proposal was determined to be out-of-scope.  This decision was not necessarily a bad choice as I have seen proprietary non-NETCONF configured subscription deployments thrive without a publisher requesting that a client invoke the <establish-subscription>.

As a result of the decision several years ago, no one has proposed an IETF standards based call flow to invoke a client based <establish-subscription>.  It would be excellent if someone wanted to propose a draft for this.   
 
> > I agree that the current protection could have an improved description.
> So I have placed the following text into the NETCONF-Notif security
> considerations section:
> >
> > " For a configured subscription, if NETCONF call home has been configured
> with the working credentials, yet that the receiver's NETCONF client
> implementation is both unable to process inbound notifications and unable
> to terminate a session receiving unwanted traffic, then the receiver may
> receive unwanted event records.  To minimize this risk, a publisher
> implementation should use dedicated call home connectivity port numbers
> and credentials specific to configured subscriptions.  This will minimize the
> chance that an unplanned NETCONF receiver will receive configured
> subscription notifications unexpectedly."
> 
> Well, I would rather fix the issue than pushing the problem ultimately to
> operators.

Your position is a valid one for sure.   I have not yet heard of operator wanting to attempt these more robust configuration protection mechanisms yet.  And as noted above, this is not a key use case for the deployments I am seeing yet.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jul 2018 20:21:33 -0700

Hi,

IMO there is a good enough plan in place to complete the configured
subscriptions.
The co-authors have done enough revisions. It is time to finish the drafts.

We should let vendors experiment and also try to create a standard binary
protocol.

Andy

On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <[email-masked]> wrote:

> > >         "Points to a remote NETCONF client intended to support a
> particular
> > configured subscription.";
> > >     }
> > >   }
> >
> My reading of your request was to make the current draft text less vague.
>  Hopefully providing an example augmentation based on a referenced
> standard-in-progress removes this ambiguity.
>
> I would hope that when the other standard is ready, it doesn't take
> something non-standard to bind them.  There are earlier threads on how this
> might be done.
>
> session if
> A solution based on the correct call home parameter configuration does
> work.  But other than that, I agree with you: the current NETCONF
> configured subscription solution does take some valid error conditions out
> of the hands of implementers, and places them in the hands of operators.
>
> The biggest question I see is whether implementers want to do the leg-work
> needed to building out the client capability advertisement capability to
> protect against these failure scenarios.   It would be great if NETCONF
> implementers signaled they are ready to pick this up.
>
> willing
> The other proposal is absolutely a valid way to do this.  And as Andy and
> others have pointed out, the current dynamic <establish-subscription> RPC
> can be kicked off by such a process.
>
> However the call flow has more error conditions.   As a result, three
> years ago during scoping of the current suite of IETF subscription drafts,
> this proposal was determined to be out-of-scope.  This decision was not
> necessarily a bad choice as I have seen proprietary non-NETCONF configured
> subscription deployments thrive without a publisher requesting that a
> client invoke the <establish-subscription>.
>
> As a result of the decision several years ago, no one has proposed an IETF
> standards based call flow to invoke a client based
> <establish-subscription>.  It would be excellent if someone wanted to
> propose a draft for this.
>
> Your position is a valid one for sure.   I have not yet heard of operator
> wanting to attempt these more robust configuration protection mechanisms
> yet.  And as noted above, this is not a key use case for the deployments I
> am seeing yet.
>
> Eric
>
> > /js
> >
> > --

---

From: Robert Wilton <[email-masked]>
Date: Thu, 26 Jul 2018 10:15:18 +0100

I basically agree with Andy.

I appreciate from the comments that the configured subscriptions is not 
usable using standards transports yet, but it still seems that it would 
be more invasive to rip configured subscriptions out at this point in 
time.  I think as a WG we really want to get this document published 
otherwise it will be obsolete before it even has an RFC number.  We can 
fix up the configured subscriptions afterwards, and then publish a bis 
version that puts everything together.

Thanks,
Rob

On 26/07/2018 04:21, Andy Bierman wrote:
> We should let vendors experiment and also try to create a standard 
> binary protocol.
>
>
> Andy
>
>
>
> On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Juergen,
>
>     > > > >    specification.  For implementation guidance and a YANG
>     model for
>     > this
>     > > > >    function, please look to
>     > > To clarify the recommended solution, I have updated the
>     reference above
>     > to:
>     > >
>     specification..  For
>     > >   augment
>     "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>     > >         "Points to a remote NETCONF client intended to support
>     a particular
>     My reading of your request was to make the current draft text less
>     vague.   Hopefully providing an example augmentation based on a
>     referenced standard-in-progress removes this ambiguity.
>
>     I would hope that when the other standard is ready, it doesn't
>     take something non-standard to bind them.  There are earlier
>     threads on how this might be done.
>
>     A solution based on the correct call home parameter configuration
>     does work..  But other than that, I agree with you: the current
>     NETCONF configured subscription solution does take some valid
>     error conditions out of the hands of implementers, and places them
>     in the hands of operators.
>
>     The biggest question I see is whether implementers want to do the
>     leg-work needed to building out the client capability
>     advertisement capability to protect against these failure
>     scenarios.   It would be great if NETCONF implementers signaled
>     they are ready to pick this up.
>
>     The other proposal is absolutely a valid way to do this. And as
>     Andy and others have pointed out, the current dynamic
>     <establish-subscription> RPC can be kicked off by such a process.
>
>     However the call flow has more error conditions.   As a result,
>     three years ago during scoping of the current suite of IETF
>     subscription drafts, this proposal was determined to be
>     out-of-scope.  This decision was not necessarily a bad choice as I
>     have seen proprietary non-NETCONF configured subscription
>     deployments thrive without a publisher requesting that a client
>     invoke the <establish-subscription>.
>
>     As a result of the decision several years ago, no one has proposed
>     an IETF standards based call flow to invoke a client based
>     <establish-subscription>.  It would be excellent if someone wanted
>     to propose a draft for this.
>
>     Your position is a valid one for sure.   I have not yet heard of
>     operator wanting to attempt these more robust configuration
>     protection mechanisms yet.  And as noted above, this is not a key
>     use case for the deployments I am seeing yet.
>
>     Eric
>
>     > /js
>     > 
>     > --
>     > Fax:   +49 421 200 3103       
>      <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 Jul 2018 17:47:52 +0000

<chair hat on>

I think that we're iterating towards consensus.
From a conformance perspective:

    Dynamic: MUST
    Configured: MAY (but also NOT POSSIBLE until a transport model is defined)

    Notes:
      - Vendor-specific transport models can be used until standard-models are developed.
      - No mandatory-to-implement transport will exist; thus, interoperability is at risk.
      - Unclear how a future *bis* could introduce a mandatory-to-implement transport.

I *think* that this is okay. At least it seems similar to RESTCONF not having a
mandatory-to-implement encoding.  Any objections? - speak up now!

Assuming no objections, to close the issues discussed in Montreal, we're waiting
for the following updates:

   yang-push: <unsure if any changes are needed here>
   sub-notif: modify config model to mandate a transport
   netconf-notif: modify to only reflect netconf for dynamic subscriptions
   resconf-notif: modify to only reflect restconf for dynamic subscriptions
                                and also only regard *restconf* (not http/x[.y])

or (my preference, if possible):

   yang-push: <unsure if any changes are needed here>
   sub-notif: modify config model to mandate a transport…and, somehow,
                        modified to not require a "notif" draft at all for just dynamic
                         subscriptions (shouldn't it just be normal NC/RC behavior at
                         that point, and thus nothing to define?)

For folks that want these drafts to move faster, we look forward to your thorough
reviews.  Please note that simply writing "I support" or equivalent doesn't help
ensure that the text is accurate (witness what happened last time with these drafts).

There are nearly 150 pages here. Realistically, at 7.5 pages/hour (a medium-to-light
edit, which I hope is all that is needed at this point), complete reviews might take two
and a half days, uninterrupted.  The chairs would like to see a few such reviews, either
after the updates to these drafts have been posted, or when the next (and hopefully
final) Last Call is issued.

Thanks,
Kent

On 7/26/18, 5:15 AM, "Netconf on behalf of Robert Wilton" <[email-masked]<mailto:[email-masked]> on behalf of rwilton=[email-masked]<mailto:rwilton=[email-masked]>> wrote:

I appreciate from the comments that the configured subscriptions is not usable using standards transports yet, but it still seems that it would be more invasive to rip configured subscriptions out at this point in time.  I think as a WG we really want to get this document published otherwise it will be obsolete before it even has an RFC number.  We can fix up the configured subscriptions afterwards, and then publish a bis version that puts everything together.

Thanks,
Rob

IMO there is a good enough plan in place to complete the configured subscriptions.
The co-authors have done enough revisions. It is time to finish the drafts.

We should let vendors experiment and also try to create a standard binary protocol.

Andy

On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Juergen,

> security credentials are left up to implementers of this specification..  For

> am not interested in justifications.

A solution based on the correct call home parameter configuration does work..  But other than that, I agree with you: the current NETCONF configured subscription solution does take some valid error conditions out of the hands of implementers, and places them in the hands of operators.

Eric

> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=mzX6_2ZrzEpIEW1D4vVLFrCNSlKInzy2cwBddGrlbhg&e=>>

Netconf mailing list

https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=9Ys6soB849hZqMrZoA-PCyOMrNucuiZgMhIgoT8Tsbw&e=>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 26 Jul 2018 19:41:35 +0000

Hi Kent,

> From: Kent Watsen, July 26, 2018 1:48 PM
> 
> <chair hat on>
> ...

This would be a tweak from case A2 from the WG session slides.   Personally I have no issue with this version of A2.  You and I have already scoped the changes.  Plus I don't know of anyone who has an issue with A2.   But we left the WG session with case A1 being selected.   

Procedurally how long must we wait before such a scope change becomes WG consensus?  Are there mandatory people you feel must chime in to support the change?

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 Jul 2018 21:29:04 +0000

> This would be a tweak from case A2 from the WG session slides.   Personally
> I have no issue with this version of A2.  You and I have already scoped the
> changes.  Plus I don't know of anyone who has an issue with A2.   But we
> left the WG session with case A1 being selected.

True, but recall we only did so because the previous A2 was deemed not 
viable, and no one stepped forward to work on A3.  A1 wasn't really
"selected" in my view.  But with the insertion of a mandatory transport
into SN config model, it becomes viable again from a spec perspective,
even if not immediately viable from a market perspective.

> Procedurally how long must we wait before such a scope change becomes WG
> consensus?  Are there mandatory people you feel must chime in to support
> the change?

As explained before the meeting, the goal was to have a snap-decision on
how to sequence the work.  Regardless which sequence chosen, the same
consensus-based result should be achieved in time.  As such, the chairs
didn't feel the need to confirm this "sequencing" decision on the list.

That said, it seems that Andy and Robert are today aligning with this
approach, and I know that you and myself (as a contributor) also support
this approach...and I know of no objectors, all of which looks like
consensus to me.  [Also note that this is probably the only path that
might get these drafts to LC before Bangkok.]

That said:

  1) my preference is to have *no* netconf-notif or restconf-notif drafts
     if possible and, if it is, then this reduced netconf-notif scope is
     a moot point...as dynamic subscriptions just work, for both NC and
     RC automatically.

  2) however, if netconf-notif MUST be defined, or else NC-based dynamic
     subscriptions are undefined, then it follows that RC-based dynamic
     subscriptions are also undefined, unless a restconf-notif is also
     published.  And since the WG treats both protocols symmetrically,
     I added RC-notif (for dynamic-only) as also being a needed.  Makes
     sense and should be fairly easy, right?  [hint: it's just restconf]

We should see if (1) is possible, and if not, go for (2).  This shouldn't
require any more consensus than we have already.  That said, as always, if
anyone objects, please speak now!

Thanks,
Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 19:18:38 +0000

> From: Kent Watsen, July 26, 2018 5:29 PM
<snip>
>      a moot point...as dynamic subscriptions just work, for both NC and

I just took a cut at looking at what is removed for configured subscriptions from NETCONF-notif,  The result is at:
https://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-netconf-netconf-event-notifications-11-configured-removed.txt 

To me there are normative requirements specific to NETCONF where I believe we need to go with Option 2.

>      sense and should be fairly easy, right?  [hint: it's just restconf]

I think this makes sense.   There will still be some decisions to make as Section 3.4 of current RESTONF-notif asserts HTTP2 as preferred for dynamic subscriptions (because it gets rid of SSE, and enables QoS features.)  Section 3.5 shows what could be done with existing RESTCONF over HTTP1.1 and SSE, which I believe is Andy's preferred method. 

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 29 Jul 2018 17:30:02 +0200 (CEST)

Hi,

Hi think the plan to finish and publish SN + YP + netconf-notifs w/o
support for configured subscriptions is ok.  I assume that as soon as
these documents are sent to the IESG for publication, the WG
immediately starts to work on configured subscriptions for netconf.

However, I would have preferred to remove configured subscriptions
from SN and YP, b/c I beleive that this would be faster (essentially
echoing what Balazs wrote in the first email in this thread).  If we
keep configured subscriptions in these docs, they will take additional
time to finish b/c the text needs clarifications.

See more inline below.

>         interoperability is at risk.

I don't think this is true.  This is a generic model designed to be
used wih a variety of transports.  Even if we had one or more
transport models ready, noone would have been mandatory.

> I *think* that this is okay. At least it seems similar to RESTCONF
> not having a mandatory-to-implement encoding.  Any objections? -
> speak up now!
> 
> Assuming no objections, to close the issues discussed in Montreal,
> we're waiting for the following updates:
> 

The transport leaf is already marked as mandatory.  I think this is
good enough.

>    netconf-notif: modify to only reflect netconf for dynamic subscriptions

Agreed.

>                                 and also only regard *restconf* (not http/x[.y])

I would prefer to wait with this docuement; it hasn't been discussed
much, and I haven't seen a single review on the ML.

>               that point, and thus nothing to define?)

This is not possible, since for NETCONF, the <notification> elements
will now be sent after an <establish-subscription>, rather than just
<create-subscription>.  There are similar issues for RESTCONF.

/martin

> For folks that want these drafts to move faster, we look forward to
> your thorough reviews.  Please note that simply writing "I support"
> or equivalent doesn't help ensure that the text is accurate (witness
> what happened last time with these drafts).
> 
> There are nearly 150 pages here. Realistically, at 7.5 pages/hour (a
> medium-to-light edit, which I hope is all that is needed at this
> point), complete reviews might take two and a half days,
> uninterrupted.  The chairs would like to see a few such reviews,
> either after the updates to these drafts have been posted, or when
> the next (and hopefully final) Last Call is issued.
> 
> Thanks,
> Kent
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 29 Jul 2018 08:41:24 -0700

> time to finish b/c the text needs clarifications.
I agree

> transport models ready, noone would have been mandatory.

This WG is very server-centric.  It shows up most often in the way that
identityref leafs are standardized.  YANG just says any identity with
matching bases
is valid, but this is no help to a client developer.

Consider the possibility that the client developer is not looking for
opportunities to rewrite the same functionality over and over, but
rather looking for opportunities to reuse the same code across all servers.
Supposedly standards make that possible.

That is possible when there is at least one mandatory-to-implement API that
is complete enough to be useful.

Andy

> > On 7/26/18, 5:15 AM, "Netconf on behalf of Robert Wilton" <
> [email-masked]<mailto:[email-masked]> on behalf of
> rwilton=[email-masked]<mailto:rwilton=40cisc
> [email-masked]>> wrote:
> >
> >
> usable using standards transports yet, but it still seems that it would be
> more invasive to rip configured subscriptions out at this point in time.  I
> think as a WG we really want to get this document published otherwise it
> will be obsolete before it even has an RFC number.  We can fix up the
> configured subscriptions afterwards, and then publish a bis version that
> puts everything together.
> >
> > Thanks,
> > Rob
> >
> >
> > > > > >    specification.  For implementation guidance and a YANG model
> for
> > > this
> > > > > >    function, please look to
> > > > To clarify the recommended solution, I have updated the reference
> above
> > > to:
> > > >
> vague.   Hopefully providing an example augmentation based on a referenced
> work..  But other than that, I agree with you: the current NETCONF
> leg-work needed to building out the client capability advertisement
> capability to protect against these failure scenarios.   It would be great
> if NETCONF implementers signaled they are ready to pick this up.
> >
> buy the
> > The other proposal is absolutely a valid way to do this.  And as Andy
> and others have pointed out, the current dynamic <establish-subscription>
> RPC can be kicked off by such a process.
> >
> > As a result of the decision several years ago, no one has proposed an
> IETF standards based call flow to invoke a client based
> to
> operator wanting to attempt these more robust configuration protection
> mechanisms yet.  And as noted above, this is not a key use case for the
> deployments I am seeing yet.
> >
> > Eric
> >
> > > /js
> > >
> > > --
> > > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_
> 9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=mzX6_2ZrzEpIEW1D4vVLFrCNSlKInzy2cwB
> ddGrlbhg&e=>>
> >
> >
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/netconf<https://
> urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> mailman_listinfo_netconf&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_
> 9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=9Ys6soB849hZqMrZoA-
> PCyOMrNucuiZgMhIgoT8Tsbw&e=>
> >
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jul 2018 20:07:47 +0200

> > time to finish b/c the text needs clarifications.

Yep. And my concerns are with the protocol (-notif) documents, except
some weirdness with the configured subscriptions YANG model, which
messes up the difference between subscription concerns, receiver
concerns, and transport concerns (but perhaps we are moving towards
fixing this in another thread).

/js