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

[Kent Watsen <[e-mail]>]

Listening to the audio from 101, it seemed that Martin's objection was primarily that the current draft didn't follow the pattern that other drafts are using [1].

Without actually understanding the proposal below, I'll only state that my thought is not to push this work towards [2] today, but more to ensure it follows the pattern.  

FWIW, in the syslog draft, we used to have a "tcp" transport type, which was really just an address/port pair, so maybe something like:

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

Wait, now I'm confused, how is only specifying an "address" sufficient for configuration.  I thought the receiver needed to authenticated.  -12 says:

   For both configured and dynamic subscriptions the publisher MUST
   authenticate and authorize a receiver via some transport level
   mechanism before sending any updates.

How is the crypto and auth configured?  Maybe this draft should leave the "transport" choice node empty, and let the netconf-notif and restconf-notif modules augment in their respective transport-specific config into the "transport" choice node here?

Kent


===== original message =====

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://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.tools.ietf.org_p_notes-2Dietf-2D100-2Dnetconf-3FuseMonospaceFont-3Dtrue&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mlgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=Ze41zuqNT4PBN99cA4dADgxy-xBKLFfzyfivvhJTidM&e=   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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dschoenw-2Dnetmod-2Dyang-2Dpattern-2D00.txt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mlgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=5fSSDwLs3xnRhTaHRh0avYzXVp9vyEiBN6yPU5q7RWI&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dnetconf-2Dclient-2Dserver-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mlgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=LiWhNYvJYwT22pvItpCUzPNZH7-sJqJR3eGI8vji9Wc&e=
> 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=
>