Re: [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]>]

Hi Kent,

I am trying to map your proposed structure onto the receivers list.  I think what you are suggesting is a design pattern like this:

       +--rw subscriptions
          +--rw subscription* [id]
               +--rw id                 
               +--rw receivers
                  +--rw receiver* [name]
                       +--rw name    string
                       +--rw (transport)
                         +--:(ssh) {ssh-call-home}?
                          |  +--rw ssh
                         |     ...
                          +--:(tls) {tls-call-home}?
                             +--rw tls

There was some discussion early on with respect to using your client/server models as inspiration.  However they were not a clean match, and actually the WG stepped back from this path when there was a decision at & after IETF 100 to simplify things and have a common transport across all receivers of a configured subscription.  

For more, see https://etherpad.tools.ietf.org/p/notes-ietf-100-netconf?useMonospaceFont=true   Issue SN#4 

Also it feels more modular to maintain transport specific call home details in a place like module ietf-netconf-server  This avoids storing call home information for every receiver in the subscriptions table.  The good news is that with the current design, it is possible to augment a leafref to various call-home transport options when that draft progresses.  And I believe Martin suggested this as an approach in this thread.

Eric

In any case as [2] progresses, [2] should be something developers wanting to use call home should use.


> From: Kent Watsen, May 8, 2018 9:30 PM
> 
> 
> Sorry, just looking at this now while listening to the minutes.  I think we should
> look at [1] for inspiration.  This is the pattern that the various client/server and
> syslog documents used.  For instance, notice in [2]:
> 
>   module: ietf-netconf-server
>       +--rw netconf-server
>          +--rw listen {listen}?
>             ...
>          +--rw call-home {call-home}?
>             +--rw netconf-client* [name]
>                +--rw name                  string
>                +--rw endpoints
>                   +--rw endpoint* [name]
>                      +--rw name    string
>                      +--rw (transport)
>                         +--:(ssh) {ssh-call-home}?
>                         |  +--rw ssh
>                         |     ...
>                         +--:(tls) {tls-call-home}?
>                            +--rw tls
>                               ...
> 
> See how there is a 'choice' with a case for each transport?  "Endpoint" here is
> like your "receiver"...
> 
> [1] https://tools.ietf.org/id/draft-schoenw-netmod-yang-pattern-00.txt
> [2] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-
> 05#section-4.1
> 
> Kent // contributor
> 
> 
> 
> > From: Eric Voit, April 3, 2018 8:25 PM
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__youtu.be_KJtg-2DJ
> > -2D6CZM-3Ft-3D27m39s&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXc
> >
> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwY
> aRYnX
> >
> OWJQJmL0npaAmtTIQk4YNutZA1I&s=XlKKQ9yScaldHxhsVmnkW8vDLpmTgU_4
> u2wD_WC6
> > BDQ&e= 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_netconf-2Dwg_notif-2Dnetconf_blob_master_draft-2Dietf-
> 2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n
> PdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=ADVNhk_g5Zew9bG9
> F48_mtfHGr46qSglpAL4AKzJFNY&e=
> > 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?
> 
> There hasn't been anyone with an opinion or an alternative to Martin's
> approach.    As a result, above it what I put into v12:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetconf-2Dsubscribed-
> 2Dnotifications&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n
> PdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=Hwcw85WOjJ9Duzi44
> YtoggL7NZpDaVVRlJVV6HeziKA&e=
> 
> If you feel strongly for please chime in before the end of the week.  If no one
> chimes in, let's close this issue.
> 
> Eric
> 
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ne
> > > > tconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> 2D&d=DwICAg&c=HAkYu
> > > > h63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2
> > > >
> gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I
> &s
> > > > =Do-8-gNbbkSGICRHwztUIZKhbaErQvFYlrCnmrlKvGQ&e=
> > > 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.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXc
> >
> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwY
> aRYnX
> >
> OWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI8gu0PfaUJP79h_03
> knfp4
> > 8GI&e=
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n
> PdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI
> 8gu0PfaUJP79h_03knfp48GI&e=
>