Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 1 Aug 2018 16:03:56 +0000

> From: Kent Watsen, July 31, 2018 8:01 PM
> 
> 
> >> In the case of RESTCONF, we could update the ietf-restconf-client and
> >> ietf-restconf-server models to include an "encodings" leaf-list, to
> >> configure the RESTCONF server which encodings it should support.
> >
> > RESTCONF uses SSE for notification delivery. What you have in mind is
> > likely the HTTP/2 push transport defined in
> > draft-ietf-netconf-restconf-notif
> 
> Not really.  The thought extends beyond the notifications work.  In general,
> servers are able to be tuned as to which protocols, algorithms, etc. are
> supported.  For instance, NGINX has a parameter for if HTTP2 is enabled.
> Similarly, it seems that a server may be configured, for local policy reasons, to
> support just xml or just json.  The idea is that, if we add these tuning params to
> the ietf-restconf-[client|server] models, then those tuning params might be
> used to enable the encoding selection for *configured* restconf-notif
> subscriptions. Just an idea.
> Really, this is an open restconf-client-server draft issue, and only a restconf-
> notif draft issue when we do the bis on that draft.
> 
> 
> 
> > which I think should not be called
> > RESTCONF just because it uses some version of HTTP.
> 
> Agreed.  The "restconf-notif" draft should really only speak about the
> RESTCONF protocol.

The current RESTCONF-notif draft includes dynamic and configured subscriptions.    The draft likely should be split, one for dynamic (RESTCONF) and configured (HTTP2).   

>  That the YANG module in the draft is called "ietf-http-
> subscribed-notifications" surprises me.

The augmentations in the model are only relevant for configured, so HTTP seemed more applicable.
 
> Actually, the names of the YANG "notif" modules in general seem less than
> ideal.  I appreciate that RFC 6470 took the name "ietf-netconf-notifications",
> and these drafts are trying to follow that naming convention, but maybe we
> should choose a more concise pattern like ietf-notifications-<transport>:
> 
>   ietf-notifications-netconf
>   ietf-notifications-restconf
>   ietf-notifications-coap
>   ietf-notifications-http2

This works for me.
 
> or maybe ietf-notifications-<transport>[-<encoding>]:
> 
>   ietf-notifications-netconf
>   ietf-notifications-restconf-xml
>   ietf-notifications-restconf-json
>   ietf-notifications-coap
>   ietf-notifications-http2-xml
>   ietf-notifications-http2-json

I think creating different identities for XML & JSON encodings which are themselves dependent on a  specific transport would be confusing.

Eric

> > /js
> Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Aug 2018 15:11:54 +0000

I am sympathetic to Eric's and Einar's observation that a given subscription, having multiple receivers, is likely to have all the receivers using the same transport and encoding.

The thought behind this is that, assuming there are multiple distinct applications, each application will selfishly create its own subscription; it will not try to see if there is another existing subscription that matches its needs.

Thus, in effect, the *only* purpose for there being a *list* of receivers is for enabling high availability, which I think is okay.  I wish the text was clearer about this objective.

What I object to is the way that this restriction is currently implemented using identities, which requires the "notif" models to do something right.  Better would be a "must" expression that says the count of the descendants is exactly one.  Can you do that?

Kent // contributor

===== original message =====

I am wondering why we are reopening the issue of multiple encodings/transports per receiver vs per subscription?  

Having single transport / encoding per subscription is a simpler design (feedback from implementors; simplifies dealing with any error conditions due to encoding that would affect one receiver but not others in the same subscription; Einar has explained this in the past) and, while I am in general a fan of general design, there does not seem to be business requirements and scenarios that demand this - and even if there were, this would constitute merely an optimization (since if you have different receivers who want different encodings/tranport, you can always simply create another subscription).  

If in the future there is really desire to add this as an additional feature, we can put this into a -bis version.  (Adding stuff will be easier than taking things away.)  Let's just be done.  

--- Alex

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Martin
> Bjorklund
> Sent: Tuesday, July 31, 2018 7:51 AM
> To: [email-masked]
> Cc: evoit=[email-masked]; [email-masked]
> Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?
> 
> Kent Watsen <[email-masked]> wrote:
> > [removing yang-doctors list, and updating subject line accordingly]
> >
> >
> > >> > Why do all receivers of a subscription have to use the same
> transport?
> > >>
> > >> This was something that Martin and Eric worked out before we did
> > >> the first Last Call.  Eric doesn't seem to know the particular
> > >> reason, other than Martin seems to think it’s easier.
> > >
> > > No; I personally also prefer a design where each receiver has its
> > > own transport + encoding.
> >
> > +1
> >
> >
> > > The original model had a common "encoding" for all receivers, and
> > > then a receiver-specific transport - I think this is even worse,
> >
> > Agreed.
> >
> >
> > > and suggested to have transport + encoding defined together
> > > preferrably receiver-specifc or else common for all receivers.
> > >
> > > If the WG now believes that the transport + encoding should be done
> > > per receiver, this should be fairly easy to change.
> >
> > I also prefer per receiver, and I think that doing so will simplify
> > the model, as neither the mandatory "transport" nor the [not
> > mandatory?] "encoding" leaves have to be specified.
> >
> > In particular, my thoughts are that the "notif" model should provide
> > for the encoding selection, if needed (it's not needed for NETCONF, or
> > COAP I imagine).
> 
> I agree.  I think this would be a cleaner design.
> 
> 
> /martin
> 
> 
> >
> > configure the RESTCONF server which encodings it should support.  We
> > likely need to do something similar to configure which HTTP versions
> > should be supported.  Now, in a general RC server, the server could
> > support both but, if the restconf-notif draft has its own list of
> > restconf-servers (i.e., it uses the "restconf-server-grouping" itself,
> > see my July 19 email for a YANG example), then a constraint could be
> > added limiting the number "supported" to just one.  Thus, when the RC
> > server reboots, and connects to the receiver and *automatically* (no
> > client RPC) starts pushing notifications, it can know what encoding to
> > use.
> >
> > I'm still unsure if its legal for an RC server to automatically push
> > notifications without a client-initiated RPC of any sort, and I'm also
> > uncertain if supporting *configured* subscriptions for NC or RC is
> > needed (see my message July 20 email).  So, some of this may work
> > itself out as we progress.
> >
> > I know that we're not defining the *configured* notif drafts in this
> > first effort, the we are publishing the SN draft with a configuration
> > model, my only concern now is configuration model presented in the SN
> > draft.
> >
> >
> > Kent // contributor
> >
> >
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Mh0UuTFvh9TpmFzzMMON07C4WQIwjRJLM-OT62OJZe4&s=PPy3uCUVVJa-GwAfmUexA9cX31IWHhlMHlAGMcPdnyY&e=

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2018 08:25:14 -0700

On Thu, Aug 2, 2018 at 8:11 AM, Kent Watsen <[email-masked]> wrote:

>
> I am sympathetic to Eric's and Einar's observation that a given
> subscription, having multiple receivers, is likely to have all the
> receivers using the same transport and encoding.
>
> The thought behind this is that, assuming there are multiple distinct
> applications, each application will selfishly create its own subscription;
> it will not try to see if there is another existing subscription that
> matches its needs.
>
> Thus, in effect, the *only* purpose for there being a *list* of receivers
> is for enabling high availability, which I think is okay.  I wish the text
> was clearer about this objective.
>
> What I object to is the way that this restriction is currently implemented
> using identities, which requires the "notif" models to do something right.
> Better would be a "must" expression that says the count of the descendants
> is exactly one.  Can you do that?
>

Is there a way to make multiple receivers per subscription
optional-to-implement
(another YANG feature?)

Anyone implementing configured subscriptions is forced to support multiple
receivers.
Does that mean it is harmful to the Internet if only 1 receiver per
subscription is allowed?

I was told this feature is required because it is too much of a burden on
the client to
create a separate subscription for each receiver.  IMO this is nonsense,
but I won't
implement configured subscriptions anyway.

> Kent // contributor

Andy

> I am wondering why we are reopening the issue of multiple
> encodings/transports per receiver vs per subscription?
>
> Having single transport / encoding per subscription is a simpler design
> (feedback from implementors; simplifies dealing with any error conditions
> due to encoding that would affect one receiver but not others in the same
> subscription; Einar has explained this in the past) and, while I am in
> general a fan of general design, there does not seem to be business
> requirements and scenarios that demand this - and even if there were, this
> would constitute merely an optimization (since if you have different
> receivers who want different encodings/tranport, you can always simply
> create another subscription).
>
> If in the future there is really desire to add this as an additional
> feature, we can put this into a -bis version.  (Adding stuff will be easier
> than taking things away.)  Let's just be done.
>
> --- Alex
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> Mh0UuTFvh9TpmFzzMMON07C4WQIwjRJLM-OT62OJZe4&s=PPy3uCUVVJa-
> GwAfmUexA9cX31IWHhlMHlAGMcPdnyY&e=
>
>
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 2 Aug 2018 16:04:42 +0000

Inline...

On 2 Aug 2018, at 16:11, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

einarnn> Absolutely. I see very few real world cases where it is likely that we will see same subscription with different receivers using different encodings. It is a step too far IMO.

einarnn> This is the likely outcome if you are in a multi-manager scenario anyway. We shouldn’t be trying to optimise anything related to thinking that distinct consumers will try to reuse others’ subscriptions in a spirit of good citizenship. It just won’t, pragmatically, happen. What would be way more likely to happen to support this is that the distribution out to multiple distinct consumers will happen by way of middleware put in place by the customer.

einarnn> Agreed. Let’s just move past this issue

Cheers,

Einar

Kent // contributor

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Martin
Bjorklund
Sent: Tuesday, July 31, 2018 7:51 AM
To: [email-masked]<mailto:[email-masked]>
Cc: evoit=[email-masked]<mailto:evoit=[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?

Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
[removing yang-doctors list, and updating subject line accordingly]

+1

Agreed.

/martin

Kent // contributor

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Mh0UuTFvh9TpmFzzMMON07C4WQIwjRJLM-OT62OJZe4&s=PPy3uCUVVJa-GwAfmUexA9cX31IWHhlMHlAGMcPdnyY&e=

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

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 2 Aug 2018 16:10:50 +0000

On 2 Aug 2018, at 16:25, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 2, 2018 at 8:11 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Is there a way to make multiple receivers per subscription optional-to-implement
(another YANG feature?)

einarnn> Speaking for Cisco, we’re just putting a deviation in that initially the max size of the receivers list is 1. I think having multiple receivers be a feature would complicate the model. I see no need for a feature here.

Anyone implementing configured subscriptions is forced to support multiple receivers.
Does that mean it is harmful to the Internet if only 1 receiver per subscription is allowed?

einarnn> Clearly it’s not harmful :-)

I was told this feature is required because it is too much of a burden on the client to
create a separate subscription for each receiver.  IMO this is nonsense, but I won't
implement configured subscriptions anyway.

einarnn> I know I’m an advocate of this feature, but it’s nothing to do with the burden on a client related to creating >1 configured subscription. It’s to do with efficiency for me for the use cases related to HA. We have feedback from customers that they want to see the devices be able to send the same feed to >1 (usually 2) consumers to deal with HA/redundancy and to allow for receiver-determined network path diversity. This gives options needed (IMO) options for how customers address this.

Cheers,

Einar

Kent // contributor

Andy

--- Alex

> From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin
> Bjorklund
> Cc: evoit=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Kent Watsen <kwatsen@juniper..net<mailto:[email-masked]>> wrote:

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 2 Aug 2018 18:21:31 +0200

Hello all,

this discussion seems to be about dynamic subscriptions as "each 
application will selfishly create its own subscription". Configured 
subscriptions would benefit from a list of multiple receivers at the 
time of unboxing, I think. And that would be about resilient 
subscriptions or HA features in redundancy groups of receivers.

That said, wrt dynamic subscriptions, constrained-node environment YANG 
servers/datastores would benefit from minimizing the number of 
subscription state to be maintained. Also, the amount of potential 
useful sets of subscription characteristic is smaller with smaller 
things. Looking these up would be a valid alternative, I'd assume?

Viele Grüße,

Henk

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2018 09:23:15 -0700

On Thu, Aug 2, 2018 at 9:10 AM, Einar Nilsen-Nygaard (einarnn) <
[email-masked]> wrote:

>
>
> On 2 Aug 2018, at 16:25, Andy Bierman <[email-masked]> wrote:
>
>
>
>> What I object to is the way that this restriction is currently
>> implemented using identities, which requires the "notif" models to do
>> something right.  Better would be a "must" expression that says the count
>> of the descendants is exactly one.  Can you do that?
>>
>
>
> einarnn> Speaking for Cisco, we’re just putting a deviation in that
> initially the max size of the receivers list is 1. I think having multiple
> receivers be a feature would complicate the model. I see no need for a
> feature here.
>
> einarnn> I know I’m an advocate of this feature, but it’s nothing to do
> with the burden on a client related to creating >1 configured subscription.
> It’s to do with efficiency for me for the use cases related to HA. We have
> feedback from customers that they want to see the devices be able to send
> the same feed to >1 (usually 2) consumers to deal with HA/redundancy and to
> allow for receiver-determined network path diversity. This gives options
> needed (IMO) options for how customers address this.
>
>
It is trivial to support this use-case with 2 subscriptions.
The burden on the client is probably less, since the model would be simpler.

Andy

>> > Kent Watsen <kwatsen@juniper..net <[email-masked]>> wrote:
>> > https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HA
>> kYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EP
>> oOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Mh0UuTFvh9TpmFzzMMON07C4WQIwjR
>> JLM-OT62OJZe4&s=PPy3uCUVVJa-GwAfmUexA9cX31IWHhlMHlAGMcPdnyY&e=
>>
>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Aug 2018 09:30:17 -0700

On Thu, Aug 2, 2018 at 9:04 AM, Einar Nilsen-Nygaard (einarnn) <
einarnn=[email-masked]> wrote:

> Inline...
>
> On 2 Aug 2018, at 16:11, Kent Watsen <[email-masked]> wrote:
>
>
> einarnn> Absolutely. I see very few real world cases where it is likely
> that we will see same subscription with different receivers using different
> encodings. It is a step too far IMO.
>
> einarnn> This is the likely outcome if you are in a multi-manager scenario
> anyway. We shouldn’t be trying to optimise anything related to thinking
> that *distinct* consumers will try to reuse others’ subscriptions in a
> spirit of good citizenship. It just won’t, pragmatically, happen. What
> would be way more likely to happen to support this is that the distribution
> out to multiple distinct consumers will happen by way of middleware put in
> place by the customer.
>

OK, I do not want to hold up dynamic subscriptions.
I do not agree with the design practice of empty mandatory choice.
It looks like a band-aid for a broken development process, not good
architecture.

Is it really such a complex problem to define a case with an address/port
end-point?
Sorry I missed the rationale for why removing such an obvious data model
for an endpoint
so it can be replaced with proprietary augments instead.  What are vendors
using to model
an endpoint that is so different from host/port?

Cheers,

Andy

> From: Netconf [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Martin
> Bjorklund

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Aug 2018 18:51:08 +0000

> Agreed. Let’s just move past this issue

But what about this comment?

I'm not that familiar with XPath expressions, but would something like this work?

            must "count(distinct-values(//sn:receivers/sn:receiver)) = 1"

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 3 Aug 2018 20:32:11 +0000

From: Kent Watsen, August 3, 2018 2:51 PM

I don’t know how this would work as what you would be checking to see is if the augmented transport choice case types are common across all receivers.

Based on empty mandatory choice being ok, I have posted a new –v15 of SN.

https://www.ietf.org/internet-drafts/draft-ietf-netconf-subscribed-notifications-15.txt

If someone figures the XPATH to do what Kent suggests above, it can be seamlessly added.   But if nothing comes up, we can still progress using the earlier proposed solution.

Eric

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 05 Aug 2018 11:21:50 +0200 (CEST)

> an endpoint that is so different from host/port?

For NETCONF, you would have a leafref to a call-home endpoint, as
defined in the ietf-netconf-server model.  In addition to the address
/ port, it has certificates and keys.

/martin

> > using identities, which requires the "notif" models to do something right..