Re: [Netconf] Anyone want just Configured Subscriptions?

[Andy Bierman <[e-mail]>]

On Sat, Jul 7, 2018 at 3:25 AM, Martin Bjorklund <[e-mail]> wrote:

> "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.
>
>
>
I am not a fan of standards that are useless unless and until
they are augmented with proprietary objects.

CallHome does not really work here because once it is completed
the NETCONF session is idle. The server is waiting for
the client to send an <rpc-request>.   There is nothing standard that
indicates
the client will just wait and the server will start sending notifications.

As a standard, this is unusable.
It assumes the client developer will know the magic port numbers in advance
in order to use each server (maybe port 40123 mean subscription 23 on
server X and port 40023 means a regular CallHome session. Network management
by ad-hoc port assignments seems fragile at best.



/martin
>
>

Andy


>
> > 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]>
> >
> >
>