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

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

I am closing this question.  All votes are for Option 2, which is reflected in the current draft.

Eric

From: Andy Bierman, June 25, 2018 1:22 PM


On Mon, Jun 25, 2018 at 5:45 AM, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:

To be clear, we’re discussing conformance requirements.  Options are:

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY



I support this option (I think this is in the draft now).
The configured subscriptions are likely less interoperable at this point because
the protocol, transport, and encoding could be proprietary.  There are also
call-home issues (magic proprietary port X means plain call-home,
magic port Y means subscription call-home).

The dynamic subscription is much more constrained by the NETCONF or RESTCONF
protocols, so it is more likely to be consistent across server implementations.

There is no extra burden for supporting an RPC in addition to edit-config.
(As edit-config itself is an RPC.) The RPC does not introduce parameters
that are not already in the configured subscriptions.

Andy



   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

I don’t really care, as long as there is a good reason for it.

Kent // contributor


On Jun 24, 2018, at 7:42 AM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:
Hello all,

this poll seems to ask only for "yes" votes, but maybe I am missing something obvious here, but I am also new to the domain of netconf.

In any case, I would like to voice a strong no wrt "only Configured Subscriptions". In complement, I would like to voice a strong yes wrt "Dynamic Subscriptions are not turned into an optional feature".

Drop-shipping or enrollment of YANG datastores should support resilient rendezvous, join or discovery prodedures. I am aware of call home and this seems to be an excellent lightweight basis to build more complex solutions on that will benefit significantly from available dynamic subscription features.

Viele Grüße,

Henk
On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)" <evoit=40cisco.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf.org<http://dmarc.ietf.org>> wrote:
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



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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