[Netconf] IETF 101 SN Question 1: Proper designation of receiver (was RE: mbj's WGLC comments on subscribed-notifications-10)

["Eric Voit (evoit)" <[e-mail]>]

At IETF 101, during the subscribed-notifications review, everyone in the room seemed good with having a string which acted as the key for a list of configured receivers: 
https://youtu.be/KJtg-J-6CZM?t=27m39s 
What was unresolved was that we still needed to choose the preferred way to enforce each receiver initiating a call-home using the configured subscription's transport.

Further below in the thread, Martin proposes a structure to accomplish this.  Please note however that a natural outcome of Martin's suggestion is the placing of a small YANG model within draft-ietf-netconf-netconf-event-notifications which just defines an identity for "NETCONF".  Specifically:

  identity netconf {
    base sn:transport;
    base sn:inline-address;
    description
      "NETCONF is used as a transport for notification messages and
       state change notifications.";
  }

(  For the full min-model with all the boilerplate, see:
https://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-netconf-netconf-event-notifications-10.txt   )

The benefit of having this very short model in draft-ietf-netconf-netconf-event-notifications is that it is quite easy to enforce the proper call home mechanism for NETCONF based receivers.   Another benefit is that we also can create additional mini models for the RESTCONF / HTTP draft and for other transports as they are built out.

Does anyone have issue with this approach?

Eric



> From: Martin Bjorklund <[e-mail]>
> Sent: Thursday, March 22, 2018 3:14 PM
> To: Eric Voit (evoit) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Netconf] mbj's WGLC comments on subscribed-notifications-
> 10
> 
> Hi,
> 
> [pruning to open issues]
> 
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > Hi Martin,
> >
> > Thanks very much for the comments.  Thoughts are in line.  Also a few
> > key areas marked with "****"
> >
> > Note that changes shown below are also included in this working
> > version
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-
> netcon
> > f-subscribed-notifications-11.txt
> >
> > > Martin Bjorklund, March 15, 2018 5:12 AM
> > >
> > > Hi,
> > >
> > > Here are my WGLC comments on
> > > draft-ietf-netconf-subscribed-notifications-10.
> > >
> > > In general, I think ths document has improved a lot, it is now
> > > easier to follow.
> > >
> > >
> > >
> > > Major issue
> > > -----------
> > >
> > > o  list receiver
> > >
> > >    In the YANG model, the "receiver" list is indexed by ip and port.
> > >
> > >    How is the server supposed to use this simple list of ip/port?
> > >
> > >    We get a hint from the document in 2.5.2:
> > >
> > >      transport specific
> > >      call-home operations will be used to establish the connection
> > >
> > >    But it is not clear that this list of ip/port helps.
> >
> > Actually, the address is of type Host.  Of course for everyone must
> > eventually resolve to an IP address to make a connection.
> >
> > However what I think what you are ultimately trying to do is make sure
> > the choice of index doesn't preclude future mechanisms for referencing
> > receivers beyond address+Port.  And this likely is a good idea.
> >
> > >    The document
> > >    draft-ietf-netconf-netconf-client-server provides configuration for
> > >    call home for NETCONF.  In that document, the receiver is
> > >    identified with a "netconf-client" name and an "endpoint" name, not
> > >    ip/port. (draft-ietf-netconf-restconf-client-server has a similar
> > >    structure for RESTCONF).
> >
> > Yes, having alternative, indirect ways of *ultimately* getting to IP
> > address + port would help flexibility.
> >
> > >    The best solution would have been to have leafrefs to these
> > >    datamodels, but if we do that now, it would introduce a delay b/c
> > >    of the dependency.
> > >
> > >    The second best solution (I think) is to change this list to have
> > >    just a "name" as the single key, and nothing else, and write that
> > >    transport-specific modules can add to this in the future.
> >
> > I am fine with name as a single key.  However "nothing else" injects a
> > few problems:
> >
> > (1) our traffic counters are transport agnostic.  Displacing them to a
> > transport draft reduces utility.
> 
> Yes; my mistake, I didn't mean to exclude the counters / state / action.  Just
> host/port.
> 
> > (2) forcing the acquisition of host or ip address only from the
> > transport draft creates unnecessary complexity for people who are able
> > to simply configure host+Port, should it be available in that form
> > already?  So why not simply leave those in as a transport agnostic
> > option of last resort should it be available to populate?
> 
> I think it is a bad idea to include open-ended objects just b/c "maybe
> someone would like to use them for something".  For interoperability, it is
> important that all objects we define have clear semantics, and that it clear
> how to use them.
> 
> In this case, none of the standard transports will need these nodes (unless
> the client-server models are severly changed).  If someone defines a
> transport in the future that needs these objects, it is trivial to do, and it will
> be done in a more robust way.
> 
> This said, if the WG strongly believes that these nodes are important, here's
> a design that might work:
> 
>   identity inline-address {
>     description
>       "A transport identity can derive from this identity in order
>        to allow inline definition of the host address in the
>        'receiver' list";
>     }
>   }
> 
>   ...
> 
>   leaf address {
>     when 'derived-from(../../../transport, "sn:inline-address")';
>     ...
>   }
> 
> The you can define your transport like this:
> 
>   identity my-udp-based-transport {
>     base sn:transport;
>     base sn:inline-address;
>   }
> 
> I would prefer to simply leave this out though.