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

["Einar Nilsen-Nygaard (einarnn)" <[e-mail]>]

Inline...

On 2 Aug 2018, at 16:11, Kent Watsen <[e-mail]<mailto:[e-mail]>> 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.

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.

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.

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.

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.

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

Cheers,

Einar


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:[e-mail]] On Behalf Of Martin
Bjorklund
Sent: Tuesday, July 31, 2018 7:51 AM
To: [e-mail]<mailto:[e-mail]>
Cc: evoit=[e-mail]<mailto:evoit=[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?

Kent Watsen <[e-mail]<mailto:[e-mail]>> 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



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.  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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf