Subject: Re: [Netconf] netconf call home connection type

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Sep 2018 10:54:36 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> Also, it seems that, if we want YP+SN to be able to use call-home 
> for configured subscriptions, then we need to update the SN draft
> to A) define the "activate-configured-subscription" RPC

I started to write that I don't think this belongs to the SN draft,
since it is NETCONF-specific.  But after thinking some more about it I
think it makes sense to define this operation in the SN draft.

For RESTCONF (not a new HTTP protocol) this rpc could be used
by augmenting a 'location' leaf to its output.

It is probably useful for any protocol that does RPCs.  But for a
notif-specific transport like a UDP-based protocol, that doesn't do
normal RPCs at all, an "activate-configured-subscription" RPC doesn't
make sense.  But that is ok.

> and B)
> define an identity off of the base "call-home-reason" identity
> defined in the aforementioned I-D.  This is needed before any
> notif draft can define support for "configured" subscriptions,
> right?

Yes, but if we define this identity now in SN it would delay SN.
Better to define it later either in SN-bis or directly in a separate
document.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Sep 2018 20:41:18 +0000

Hi Martin,

Catching up on mail from last week.

> make sense.  But that is ok.

Right, but there is an issue of timing.  There is a question if this
is needed now or if it can be added in a SN-bis.  Adding the RPC would
easy, but adding the identity (rfc8071bis?) would be more involved.

Note that said RPC would be used for call-home connections (i.e., where
the roles are reversed), but unlikely to be used for regular connections
(i.e., when the publisher is the NC/RC-client).  The RPC would need to
be documented as only being relevant to call-home connections.

> Better to define it later either in SN-bis or directly in a separate

So, configured subscriptions in SN is known to be broken for call-home
connections?  Should the SN draft identify this as a known limitation?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2018 09:33:07 +0200 (CEST)

> be documented as only being relevant to call-home connections.

Yes.

> connections?  Should the SN draft identify this as a known limitation?

If we have the rpc, it is less broken.  I would prefer to define the
rpc in SN now.  Since we decided to work out the details for
configured subscriptions now in SN, I don't think we can ignore this
issue.

The identity is less important imo.  And of course, the identity is of
no use until the "call-home-reason" data model has been defined...

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Sep 2018 19:20:45 +0000

> configured subscriptions now in SN, I don't think we can ignore this

Agreed.  Without the "reason" identity, an operator could still know
that certain call-home connections (e.g., to a server or port) are only
for configured-subscriptions.  But, without an "activate-configured-
subscription" RPC, there would be no way to start the flow of event
notifications.  Can you please help raise the need for an RPC in your
SN LC review?  

> no use until the "call-home-reason" data model has been defined...

Yes, less important for the reason mentioned above.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Sep 2018 12:35:59 -0700

> notifications.  Can you please help raise the need for an RPC in your

It may be hard to separate implementation details from the standard details.

IMO configured subscription delivery connections could very well be 1 way
and the receiver may not be designed to send anything to the publisher
(like SNMP).

This is completely different than CallHome, where the purpose is to
establish
a NETCONF or RESTCONF session (neither of which allows ANY server-initiated
operations). So this "activate-configured-subscription" RPC is needed for
CallHome,
not really for all configured subscriptions.

> Yes, less important for the reason mentioned above.

Andy

>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>