Re: [Netconf] Anyone want just Configured Subscriptions?

[Martin Bjorklund <[e-mail]>]

"Eric Voit \(evoit\)" <evoit=[e-mail]> wrote:
> From: Andy Bierman, July 5, 2018 1:44 PM
> 
> 
> On Thu, Jul 5, 2018 at 10:31 AM, Eric Voit (evoit)
> <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Andy,
> 
> From: Andy Bierman, July 5, 2018 12:26 PM

[...]

> Of course it interacts poorly with CallHome, because the receiver list
> is used INSTEAD of CallHome,
> not with CallHome. CH is for initiating a new NC or RC session, so a
> "special" version of it
> that doesn't initiate a session would be a misuse.  I guess the
> concept of SNMP Trap Receiver is
> not that clear to the NETCONF WG.
> 
> <Eric> Agree.

I am confused.  The intention is to use the "receiver" list AND call
home, right?   IMO, the "receiver" list is a transport indenpendent
construct, and depending on the transport, it is augmented with
necessary parameters; in the case of NETCONF call-home will be used.
In the case of UDP some other parameters will be used.  Etc.


/martin


> Current path allows augmentation of leafrefs to NETCONF
> CH once client-server completes.  For our implementation, we will be
> augmenting in address and port now.  This will be a vendor specific
> augmentation of course.
> 
> Eric
> 
> 
> To make progress, I am ok with anything here but stalemate.  And if
> only supporting dynamic subscriptions results in progress, that is ok
> with me.
> 
> Eric
> 
> 
> 
> 
> Andy
> 
> 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]<mailto:[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]<mailto:[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]<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<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]<mailto:[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]<mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> --
> 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> 
> Senior Specialist
> 
> Mobile: [phone] email:
> [e-mail]<mailto:[e-mail]>
> 
>