[Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

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

Per below, Kent is interested to know if anyone wants to support a Publisher of just Configured Subscriptions.   This would turn Dynamic Subscriptions into an optional feature.

So does anyone want this?  If a few people say yes, I will tweak the document.

Eric




<Kent8> I understand that supporting dynamic subscriptions is currently a requirement.  I am challenging that requirement.  Why is it a requirement?  Does it have to be a requirement?

What if an IoT device only wants to support configured subscriptions and having code to support dynamic is wasting space?    FWIW, I realize that not supporting dynamic subscriptions also means that it would be impossible to filling in gaps introduced by a reboot, but maybe that's a decision that the vendor can/should make for themselves?

<Eric9> In RFC-5277, all you have is dynamic subscriptions.  So support for that older spec by definition makes dynamic subscriptions mandatory.  Beyond that, newer specifications like RFC-7923 as well as sections of other documents like RFC-7921, section 7.6 identify dynamic subscriptions as mandatory for a subscription service.  So at least some use cases exist where such dynamic support is mandatory.

<Kent9> Does it?   I mean, this draft doesn't obsolete 5277, so it seems that server can optionally support one or the other or both, and when it supports this draft, can't it use a feature statement to limit dynamic subscriptions?

<Eric10> Per below, I am ok to make dynamic subscription support optional (even if I don’t believe this is the right decision).  Part of the fix in the YANG Model description text would be to note that either dynamic or configured must be supported.

With your IoT publisher use case above you are asserting that dynamic subscriptions are not needed for configured subscription only publishers – i.e., there are a class of publishers which have been driven by use cases not considered by the documents referenced above.  So who has documented the need configured subscription only publishers?   I can’t point to such documentation (beyond IoT case above).  Is such a possibility worth slowing down this spec?     In the end making the fix for this specification which you seem to want is itself really quite trivial: we can make both dynamic and configured subscriptions optional.  The reason I have been resisting it is that this solution (a) leads to more complexity for implementers as yet another feature would have to be advertised as optional, (b) this waters down the mandatory capabilities support of the YANG module, and (c) we would need to include some a constraint that at least one of the two optional features needs to be supported.  Also for (c) AFAIK, features don’t support the application of such constraints, so it would have to be done in the feature descriptions themselves.

I guess the text above is a long way of saying that if you assert the optional dynamic subscription is mandatory to progress the document, I will make the change.  But the change will impose complexity costs which to me are hard to justify.

<Kent10> why don't you ask the WG?  "Should we support servers having only configured subscriptions (i.e. no dynamic subscriptions)?"  FWIW, the ietf-*conf-server modules have features around both the "listen" and "call-home" subtrees.  Heck, you might think "listen" would be mandatory (per RFC 6241), but still we support the possibility of a server only supporting call-home…



<Kent9> that's a reasonable answer, but mind you that it was your IoT use-case originally.   I'd like to get other opinions.  Yes, trivial to add now, hard to add later, more flexibility for servers, almost no additional effort for clients.  FWIW, I'm planning to add a feature statement for "periodic connections" in the ietf-[net|rest]conf-client-server drafts for similar reasons, that the server just might not want to support them, and I don't want the minimal bar to be higher than needed.

<Eric10> Lets go with whatever opinions people have.  I will adapt accordingly.   Do you want me to start an independent thread?

<Kent10> yes, please ask the WG