Re: [Netconf] Anyone want just Configured Subscriptions?

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> 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.

I see.  But is there really anything in 6241 that prohibits this?
Wouldn't it be ok if the new netconf-notif draft specifies this
behavior?

If it can't be solved in this way, we'd have to define a new rpc
<start-all-subscribed-subscriptions>


/martin





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