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

[Andy Bierman <[e-mail]>]

On Thu, Jul 5, 2018 at 9:17 AM, Eric Voit (evoit) <[e-mail]> wrote:

> *From:* Balazs Lengyel, July 5, 2018 10:56 AM
>
> We would need dynamic subscriptions with Netconf transport yesterday, so
> for me the best solution is whatever delivers this soon.
> How about spiting just the Netconf transport draft into a document that is
> good enough for dynamic subscriptions, and later updating that to include
> configured subscriptions too. Would that be possible? Faster?
>
>
>
> <Eric> If everyone is ok with doing a –bis for configured subscriptions as
> soon as ietf-netconf-client-server, I would be ok with making the
> corresponding updates.  Looking at it now, making the needed deletions to
> NETCONF-Notif would be very quick to do.
>
>
>
> Then there is only one last open issue that I recall for the subscription
> drafts in WGLC: support for configured replay.  We will be going over that
> in Montreal.
>
>
>


Why does there need to be a dependency on the client-server module?
The only things missing from the "receiver" list are 2 leafs (host, port).



> Eric
>



Andy


> Configured subscriptions are less important for us.
>
> regards Balazs
>
>
>
> On 7/4/2018 9:40 PM, Andy Bierman wrote:
>
>
>
>
>
> On Tue, Jul 3, 2018 at 12:17 PM, Kent Watsen <[e-mail]> wrote:
>
> Since folks are leaning towards:
>
>
>
>    dynamic: MUST
>
>    configured: MAY
>
>
>
> We might also consider:
>
>
>
>    dynamic: MUST
>
>    configured: TBD
>
>
>
> Since the transport bindings (only needed for configured subscriptions)
> seem to depend on the client/server drafts, which aren't ready yet.
>
>
>
>
>
> The "receiver" list is rather proprietary since it has nothing in it about
> where or how to send packets,
>
> such as the destination socket, protocol, or message encoding.
>
> I don't see how configured subscriptions are useful as a standard without
> these details.
>
>
>
>
>
> Kent // contributor
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On 7/2/18, 6:50 PM, "Eric Voit (evoit)" <[e-mail]> wrote:
>
>
>
> 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]> 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].
> de> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_D1bd7UloKmwLO1YfE&e=>>
> 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]
> https://www.ietf.org/mailman/listinfo/netconf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Netconf mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> --
>
> Balazs Lengyel                       Ericsson Hungary Ltd.
>
> Senior Specialist
>
> Mobile: [phone]              email: [e-mail]
>
>