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

> From: Kent Watsen, May 9, 2018 1:49 PM

>

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



Martin's point in and post IETF 101 was that address and port was not a good key for a receiver.  Plus, where we have address, that we shouldn't use port because that connection information shouldn't be repeated (possibly with errors) across independent subscriptions.



In the end, the final proposal embodied in the draft was one made by Martin.  This proposal does allow for a very clean match to your client-server drafts as both the endpoints and receivers are keyed by name.  I.e.,

    +--rw endpoint* [name]          +--rw receiver* [name]

       +--rw name    string            +--rw name    string



> 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



Per IETF 100, transport is no longer under receivers.  It is under the subscription.  This is the current tree, with transport high up...



      +--rw subscriptions

         +--rw subscription* [identifier]

            +--rw identifier                       subscription-id

            +--rw transport                        transport   {configured}?

            +--rw receivers

               +--rw receiver* [name]

                  +--rw name                      string

                  +--rw address?                  inet:host



> Wait, now I'm confused, how is only specifying an "address" sufficient for

> configuration.  I thought the receiver needed to authenticated.  -12 says:



Receivers need to be authenticated.  But this draft does not attempt configure the keys and mechanisms to perform that step.  Other sources of data are needed.



There are two ways to do this:

(1) The "address" is of type inet:host which when used with the configured subscription's transport *CAN* provide the requisite information needed to look up the remote host authentication and proper call home information for that receiver.   (Note: address is one simplistic option to get to this information today without integrating useful but complex structures.)

(2) When the client-server drafts are ready, a leafref can be augmented into:

      +--rw netconf-client

         +--rw initiate {initiate}?

            +--rw netconf-server* [name]

               +--rw name                  string

               +--rw endpoints

                  +--rw endpoint* [name]

                     +--rw name    string



All the transport specific complexities/variations here emphasize the need for separate the subscription model as all the details for such authentication and transport configuration.  This complexity need not be replicated and repeated under each and every subscription.



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



Yes this is absolutely a need.  But not specific to subscriptions.   In the end, a lot of protocols need these specifics.   I am certainly looking to your keystore related drafts to standardize such mechanisms.



> Maybe this draft should leave the

> "transport" choice node empty,



There isn't any transport choice node.  Just the identity.



> and let the netconf-notif and restconf-notif

> modules augment in their respective transport-specific config into the

> "transport" choice node here?



While it could be augmented, I believe “out of scope” awaiting the client-server drafts is a cleaner path.  Especially as we shouldn’t repeat this info for each and every subscription.



Eric



> 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=m

> lgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=Ze41zuqNT4PBN99cA4dA

> Dgxy-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=HAkYuh6

> > 3rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaG

> >

> TvjISlaJdcZo&m=mlgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=5fSSD

> wLs3

> > xnRhTaHRh0avYzXVp9vyEiBN6yPU5q7RWI&e=

> > [2]

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht

> > ml_draft-2Dietf-2Dnetconf-2Dnetconf-2Dclient-2Dserver-

> 2D&d=DwIGaQ&c=HA

> > kYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2g

> >

> sBYaGTvjISlaJdcZo&m=mlgnwyfQ9f4k26oqQICp5jBIZ1kB9w8T5l5YnoyGBgU&s=

> LiWh

> > NYvJYwT22pvItpCUzPNZH7-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-2

> > > DJ

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

> > > il

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

> >

>

>