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

From: Kent Watsen <[email-masked]>
Date: Wed, 9 May 2018 01:29:42 +0000

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-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=XlKKQ9yScaldHxhsVmnkW8vDLpmTgU_4u2wD_WC6BDQ&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=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=ADVNhk_g5Zew9bG9F48_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=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=Hwcw85WOjJ9Duzi44YtoggL7NZpDaVVRlJVV6HeziKA&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 <[email-masked]>
> > Sent: Thursday, March 22, 2018 3:14 PM
> > To: Eric Voit (evoit) <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: [Netconf] mbj's WGLC comments on
> > subscribed-notifications-
> > 10
> >
> > Hi,
> >
> > [pruning to open issues]
> >
> >
> > "Eric Voit (evoit)" <[email-masked]> 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_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&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
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI8gu0PfaUJP79h_03knfp48GI&e=

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nPdmcQiJgwYaRYnXOWJQJmL0npaAmtTIQk4YNutZA1I&s=8_AkMiol4GBodtRocjI8gu0PfaUJP79h_03knfp48GI&e=

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 9 May 2018 16:26:05 +0000

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)

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]:
> 
> > 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.
> >
> > 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
> > 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=
> > 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
> > can create additional mini models for the RESTCONF / HTTP draft and
> > for other transports as they are built out.
> >
> 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=
> 
> > > > 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
> > > > Actually, the address is of type Host.  Of course for everyone
> > > > must eventually resolve to an IP address to make a connection.
> > > >
> > > > Yes, having alternative, indirect ways of *ultimately* getting to
> > > > IP address + port would help flexibility.
> > > >
> > > > 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.
> > >
> > > 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.
> > >
> > > This said, if the WG strongly believes that these nodes are
> > > important, here's a design that might work:
> > >
> > 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=
> 
> 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=
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 May 2018 17:48:47 +0000

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,

       +--rw subscriptions
          +--rw subscription* [id]
               +--rw id                 
               +--rw receivers
                  +--rw receiver* [name]
                       +--rw name    string
                       +--rw (transport)

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 

Eric

> [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 (evoit)" <[email-masked]>
Date: Wed, 9 May 2018 20:17:37 +0000

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

> 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

> I am trying to map your proposed structure onto the receivers list.  I think

> what you are suggesting is a design pattern like this:

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

> In any case as [2] progresses, [2] should be something developers wanting to

> use call home should use.

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

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

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

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

> > > draft-ietf-netconf-netconf- event-notifications is that it is quite

> > > easy to

> > If you feel strongly for please chime in before the end of the week.

> > If no one chimes in, let's close this issue.

> > > > > Thanks very much for the comments.  Thoughts are in line.  Also

> > > > > a few key areas marked with "****"

> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_

> > > > > ne

> > > > > >      call-home operations will be used to establish the

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

> > > > > >    identified with a "netconf-client" name and an "endpoint" name,

> not

> > > > > Yes, having alternative, indirect ways of *ultimately* getting

> > > > > to IP address + port would help flexibility.

> > > > > (1) our traffic counters are transport agnostic.  Displacing

> > > > > them to a transport draft reduces utility.

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

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

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

> > > il

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 May 2018 20:18:31 +0000

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

Yes, he mentioned issues related to keys, but he also mentioned the pattern [1] used by other

drafts, which is what I'm more focused on now…

> 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 name    string            +--rw name    string

My focus is not on the name so much as the lack of a 'choice'  statement.  Please see Section 3 in [1].

> Per IETF 100, transport is no longer under receivers.  It is under the subscription.  This is

> the current tree, with transport high up...

>                  +--rw address?                  inet:host

I see "transport" under subscription, but it is using an identity (not a choice).   Also, back to

"receiver", it's the configurable "address" leaf that I'm thinking needs to be under a 'choice'.   I

see you have an interesting 'when' expression referencing the "inline-address" identity, which

appears to address some of the "what if the transport doesn't support IP" issue…

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

I don't like publishing a data model that hand-waves over parts of the configuration, and it was this line

of thinking that caused update to the syslog draft.  Also, I don't recall seeing anywhere in this document

a statement that the configuration model is incomplete - did I miss it?

> (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.)

An address by itself may not a sufficient lookup key, as the server may have different services running

on different ports and, of course, all sorts of security parameters can vary.

>                     +--rw name    string

yes, this is what I'm thinking about.  The pattern described in [1] was designed to allow for such

augmentations, but I don't understand how it would work here.   Can this draft follow the pattern

now with, perhaps, only a "tcp" transport?  But even then, I don't see how the receiver can be

authenticated (per requirement), maybe that requirement should be removed so that an

unauthenticated "tcp" transport can be fully configured?

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

I'm not sure exactly what this means (maybe a tree diagram or example would help), but note that

each instance of ietf-tcp-client fully specifies its security parameters, though a *lot* of the really

redundant stuff is factored out via leafrefs to ietf-trust-anchors and ietf-keystore (assuming that

draft comes back).

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

True, and I do think that this document (or the transport-binding documents) will ultimately depend

on the various client/server drafts the WG has been working on.  There is no other game in town, so

to speak.  Though the question remains if this is now or later thing.

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

True, but then how is just an identity sufficient?   Let's say we finally get the netconf-client-server draft to

RFC, and so someone creates an identity for "netconf", but where would the "uses" grouping statement

go?

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

I'm okay with us coming up with an unauthenticated "tcp" transport now, leaving the crypto stuff

out for now, so long as we have a pattern that we can follow to augment in what we need later.

That said, note that the IESG made RFC 6587 HISTORIC and may not have much appetite for an

unauthenticated transport again…

BTW, restconf-notif defines bindings for RESTCONF, HTTP2, and HTTP1.1, but the restconf-client-server

draft only defines a binding for RESTCONF, have you put thought to how HTTP2 and HTTP1.1 can be

supported?  for all intents and purposes, I think that it's the same config, but I haven't looked into the

details either.

Kent  // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 15 May 2018 21:20:45 +0000

Hi Kent,
Hi Martin,

Kent's underlying desire in the thread below is to insert a transport case under /subscriptions/subscription/receivers/receiver to match design patterns used elsewhere.    If we really want to do this, the way this could be done with the current design with Kent's proposal would be something like:

       +--rw subscriptions
          +--rw subscription* [identifier]
             +--rw identifier                       
             +--rw transport                        transport   {configured}?
             +--rw receivers
                +--rw receiver* [name]
                   +--rw name                      string
                    +--rw (transport)                                    {configured}?
                           +--:(tcp)?
                           |   +--rw address                  inet:host
                           |    +--rw port?                        inet:port-number
                           +--------future transport case augmentations....

Benefits of this approach:

(1) The tcp case provides an initial option for of an easy equivalence to the capability of "destination-address" and "destination-port" which appears in OC-telemetry.yang.   And it follows the design pattern as it appears in the UDP case leaf "address" and "port" of ietf-syslog.yang.   Just placing an address and port into these models has proven simple and effective.  

(2) While we await ietf-netconf-server.yang, linkage to receiver details such security credentials that are held elsewhere on the publisher *can* initially be done using "address" within the tcp case.  (I.e., I don't see any issue with having as undefined how the authentication association is done in the transport independent draft.)  Note: per the thread below, it is important not have security credentials in this part of the subscription model as could be dozens of configured subscriptions aimed at the same receiver, and it would be confusing to the other users of these credentials to look them up within this configured subscriptions model.

(3) From this starting point, future case augmentations would allow us to augment cases to "(transport)" for the placement of call-home leafrefs to modules like ietf-netconf-server.yang.  This would allow model users and applications the ability to shift to using the leafref.

More in-line.   In the end, I will gladly salute whatever the WG decides.  It would be great to find a way complete this discussion. 

> From: Eric Voit, May 14, 2018 5:26 PM
> 
> From: Kent Watsen, May 14, 2018 4:19 PM
> 
> On 5/9/18, 4:17 PM, "Eric Voit (evoit)" <mailto:[email-masked]> wrote:
> 
> >> 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.
> 
> Yes, he mentioned issues related to keys, but he also mentioned the pattern
> [1] used by other drafts, which is what I'm more focused on now…
> 
> 
> > 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.,
> My focus is not on the name so much as the lack of a
> 'choice'  statement.  Please see Section 3 in [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)
> > 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
> I see "transport" under subscription, but it is using an identity (not a
> choice).   Also, back to "receiver", it's the configurable "address" leaf that I'm
> thinking needs to be under a 'choice'.   I see you have an interesting 'when'
> expression referencing the "inline-address" identity, which appears to address
> some of the "what if the transport doesn't support IP" issue…

Yes, this was one of Martin's proposals to cover the "what if.."

> >> 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.
> 
> I don't like publishing a data model that hand-waves over parts of the
> configuration, and it was this line of thinking that caused update to the syslog
> draft. 

This draft does not attempt to configure call home, and it shouldn't considering that:
 
(a) specific call home technologies need to be associated with specific transport 
(b) there is already adopted call home with this objective of configuring this info
(c) when the call home drafts are ready, we can augment a leafref under /subscriptions/subscription/receivers/receiver.

> Also, I don't recall seeing anywhere in this document a statement that
> the configuration model is incomplete - did I miss it?

As configuration can vary transport, such a statement on configuration if needed wouldn't be here.   If you look at draft-ietf-netconf-netconf-event-notifications Section 6.2, the description of the call home process is described there.   If you think it helpful, I can put in an informative reference to draft-ietf-netconf-netconf-client-server there.

> > *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.)
> 
> An address by itself may not a sufficient lookup key, as the server may have
> different services running on different ports and, of course, all sorts of security
> parameters can vary.

I liked having port as well.  Martin requested its removal as it could be populated with something which contradicts what is in the call home configuration.

With the tree proposal at the top, I think we could have "port" be optional.  And we would say in the description that it is only populated only if it is different than a call home value if it exists, or a default port number for the transport protocol.  This should provide clarity on when it would or wouldn't be populated.

> yes, this is what I'm thinking about.  The pattern described in [1] was designed
> to allow for such augmentations, but I don't understand how it would work
> here.   Can this draft follow the pattern now with, perhaps, only a "tcp"
> transport?  But even then, I don't see how the receiver can be authenticated
> (per requirement), maybe that requirement should be removed so that an

I see no issue with requiring authentication for the transport, without explicitly storing the keys in this model, or pointing to the keys in a different model.   

> > 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.
> 
> I'm not sure exactly what this means (maybe a tree diagram or example would
> help), but note that each instance of ietf-tcp-client fully specifies its security
> parameters, though a *lot* of the really redundant stuff is factored out via
> leafrefs to ietf-trust-anchors and ietf-keystore (assuming that draft comes
> back).

I believe the proposal at the top of this email helps avoid configuration redundancy.  

> to speak.  Though the question remains if this is now or later thing.

The structures are proposed here to allow for growth into a later solution.
 
> "uses" grouping statement

A place now exists in the proposal above.

> unauthenticated transport again…

Per above, I believe we can identify the tcp address and port, with an expectation that leafrefs are later augmentable to elements that are not currently modeled.
 
> supported?  for all intents and purposes, I think that it's the same config, but I

Configured subscriptions only use HTTP2.   The working plan is for the other identities to be used for operational datastore exposure.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 May 2018 14:44:14 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> Hi Kent,
> Hi Martin,
> 
> Kent's underlying desire in the thread below is to insert a transport
> case under /subscriptions/subscription/receivers/receiver to match
> design patterns used elsewhere.  If we really want to do this, the way
> this could be done with the current design with Kent's proposal would
> be something like:
> 
>        +--rw subscriptions

Is the idea still to configure the transport (and encoding) per
subscription?  If this is the case, I don't think this new proposal
adds anything.

This said, I would prefer a design that more closely follows the
"Outbound Connection" design pattern:

        +--rw subscriptions
           +--rw subscription* [identifier]
              +--rw identifier                       
              +--rw receivers
                 +--rw receiver* [name]
                    +--rw name                      string
                    +--rw (transport) {configured}?
                       +--:(tcp)?
                          +--rw tcp 
                             +--rw address       inet:host
                             +--rw port?         inet:port-number
                             +--rw encoding

IMO this is a more natural and simpler design.

The argument against this was (IIRC) that it is easier for the server
if the transport + encoding is fixed per subscription, b/c then the
server can prepare one payload that is sent to all subscribers.  But I
don't really buy this argument; if the operator needs different
transports / encodings the current (-12) design forces the operator to
create two subscriptions.  This means that the server has to filter
the data twice, and then still do two different encodings /
transports.

Also, unless there is a document that describes the "tcp" transport, I
strongly think it should be removed.  If not, how can this be
interoperable?

/martin

> (1) The tcp case provides an initial option for of an easy equivalence
> to the capability of "destination-address" and "destination-port"
> which appears in OC-telemetry.yang.  And it follows the design pattern
> as it appears in the UDP case leaf "address" and "port" of
> ietf-syslog.yang.  Just placing an address and port into these models
> has proven simple and effective.
> 
> (2) While we await ietf-netconf-server.yang, linkage to receiver
> details such security credentials that are held elsewhere on the
> publisher *can* initially be done using "address" within the tcp case.
> (I.e., I don't see any issue with having as undefined how the
> authentication association is done in the transport independent
> draft.)  Note: per the thread below, it is important not have security
> credentials in this part of the subscription model as could be dozens
> of configured subscriptions aimed at the same receiver, and it would
> be confusing to the other users of these credentials to look them up
> within this configured subscriptions model.
> 
> (3) From this starting point, future case augmentations would allow us
> to augment cases to "(transport)" for the placement of call-home
> leafrefs to modules like ietf-netconf-server.yang.  This would allow
> model users and applications the ability to shift to using the
> leafref.
> 
> More in-line.  In the end, I will gladly salute whatever the WG
> decides.  It would be great to find a way complete this discussion.
> 
> (c) when the call home drafts are ready, we can augment a leafref
> under /subscriptions/subscription/receivers/receiver.
> 
> 
> As configuration can vary transport, such a statement on configuration
> if needed wouldn't be here.  If you look at
> draft-ietf-netconf-netconf-event-notifications Section 6.2, the
> description of the call home process is described there.  If you think
> it helpful, I can put in an informative reference to
> draft-ietf-netconf-netconf-client-server there.
> 
> I liked having port as well.  Martin requested its removal as it could
> be populated with something which contradicts what is in the call home
> configuration.
> 
> With the tree proposal at the top, I think we could have "port" be
> optional.  And we would say in the description that it is only
> populated only if it is different than a call home value if it exists,
> or a default port number for the transport protocol.  This should
> provide clarity on when it would or wouldn't be populated.
> 
> I see no issue with requiring authentication for the transport,
> without explicitly storing the keys in this model, or pointing to the
> keys in a different model.
> 
> > > 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.
> > 
> > True, and I do think that this document (or the transport-binding
> > documents)
> > will ultimately depend
> > on the various client/server drafts the WG has been working on.  There
> > is no
> > other game in town, so
> > True, but then how is just an identity sufficient?   Let's say we
> > finally get the
> > netconf-client-server draft to
> > RFC, and so someone creates an identity for "netconf", but where would
> > the
> > "uses" grouping statement
> > go?
> 
> > > While it could be augmented, I believe “out of scope” awaiting the
> > > client-
> > server drafts is a cleaner path.
> > I'm okay with us coming up with an unauthenticated "tcp" transport
> > now,
> > leaving the crypto stuff
> > out for now, so long as we have a pattern that we can follow to
> > augment in
> > what we need later.
> > That said, note that the IESG made RFC 6587 HISTORIC and may not have
> > much
> > appetite for an
> Per above, I believe we can identify the tcp address and port, with an
> expectation that leafrefs are later augmentable to elements that are
> not currently modeled.
>  
> > BTW, restconf-notif defines bindings for RESTCONF, HTTP2, and HTTP1.1,
> > but
> > the restconf-client-server
> > supported?  for all intents and purposes, I think that it's the same
> > config, but I
> > haven't looked into the
> > details either.
> 
> Configured subscriptions only use HTTP2.  The working plan is for the
> other identities to be used for operational datastore exposure.
> 
> Eric
>  
> > Kent  // contributor
> > 
> > 
> > 
> > 
> > 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 18 May 2018 14:53:42 +0000

> From: Martin Bjorklund, May 18, 2018 8:44 AM
> 
> Is the idea still to configure the transport (and encoding) per subscription?  If
> this is the case, I don't think this new proposal adds anything.

The main things it adds is the ability to augment receiver specific transport parameters in subsequent drafts. 

Honestly, I don't really like the proposal either.   I believe the current draft is adequate.  I was just attempting to bridge Kent's proposal with your earlier proposal which was adopted after IETF 100 discussions.
 
> This said, I would prefer a design that more closely follows the "Outbound
> Connection" design pattern:
> 
>         +--rw subscriptions
> The argument against this was (IIRC) that it is easier for the server if the
> transport + encoding is fixed per subscription, b/c then the server can prepare
> one payload that is sent to all subscribers.  
>
> But I don't really buy this argument;
> if the operator needs different transports / encodings the current (-12) design
> forces the operator to create two subscriptions.  This means that the server
> has to filter the data twice, and then still do two different encodings /
> transports.

Yes, with (v12) design, both the encoding and transport cannot vary by subscription.  There were many reasons for this.  Some of these reasons were discussed as part of WG review of this topic in IETF 100, and during the following rough consensus call:
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html 
I am hoping this issue is not reopened as the in-room and subsequent email threads had no dissention.  

> Also, unless there is a document that describes the "tcp" transport, I strongly
> think it should be removed.  If not, how can this be interoperable?

With "tcp" I believe Kent is attempting to find some home for receiver address info prior to the availability of call home specifications.  Kent's thinking is not unreasonable as per point (1) below, OC-telemetry.yang and ietf-syslog.yang seem to have no issue with this simple design pattern.  

Eric

> > > >> 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
> > > Yes, he mentioned issues related to keys, but he also mentioned the
> > > pattern [1] used by other drafts, which is what I'm more focused on
> > > now…
> > >
> > >
> > > > 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.,
> > > >> 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)
> > > > 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
> > > I see "transport" under subscription, but it is using an identity
> > > (not a choice).   Also, back to "receiver", it's the configurable
> > > "address"
> > > leaf that I'm
> > > expression referencing the "inline-address" identity, which appears
> > > to address some of the "what if the transport doesn't support IP"
> > > issue…
> >
> > > > 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.
> > >
> > > I don't like publishing a data model that hand-waves over parts of
> > > the configuration, and it was this line of thinking that caused
> > > update to the syslog draft.
> >
> > > Also, I don't recall seeing anywhere in this document a statement
> > > that the configuration model is incomplete - did I miss it?
> >
> > > > *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.)
> > >
> > > An address by itself may not a sufficient lookup key, as the server
> > > may have different services running on different ports and, of
> > > course, all sorts of security parameters can vary.
> >
> > > yes, this is what I'm thinking about.  The pattern described in [1]
> > > was designed to allow for such augmentations, but I don't understand
> > > how it would work here.   Can this draft follow the pattern now
> > > with, perhaps, only a "tcp"
> > > transport?  But even then, I don't see how the receiver can be
> > > authenticated (per requirement), maybe that requirement should be
> > > removed so that an unauthenticated "tcp" transport can be fully
> > > configured?
> >
> > > > 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
> > > I'm not sure exactly what this means (maybe a tree diagram or
> > > example would help), but note that each instance of ietf-tcp-client
> > > fully specifies its security parameters, though a *lot* of the
> > > really redundant stuff is factored out via leafrefs to
> > > ietf-trust-anchors and ietf-keystore (assuming that draft comes
> > > back).
> >
> > > on the various client/server drafts the WG has been working on.
> > > There is no other game in town, so to speak.  Though the question
> > > remains if this is now or later thing.
> >
> > > >> Maybe this draft should leave the "transport" choice node empty,
> > > >
> > > finally get the netconf-client-server draft to RFC, and so someone
> > > creates an identity for "netconf", but where would the "uses"
> > > grouping statement go?
> >
> > > >> and let the netconf-notif and restconf-notif modules augment in
> > > >> their respective transport-specific config into the "transport"
> > > >> choice node here?
> > > >
> > > now, leaving the crypto stuff out for now, so long as we have a
> > > pattern that we can follow to augment in what we need later.
> > > That said, note that the IESG made RFC 6587 HISTORIC and may not
> > > have much appetite for an unauthenticated transport again…
> >
> > > BTW, restconf-notif defines bindings for RESTCONF, HTTP2, and
> > > HTTP1.1, but the restconf-client-server draft only defines a binding
> > > for RESTCONF, have you put thought to how
> > > HTTP2 and HTTP1.1 can be
> > > config, but I haven't looked into the details either.
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 May 2018 17:08:23 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > subscription?  If
> The main things it adds is the ability to augment receiver specific
> transport parameters in subsequent drafts.
> 
> Honestly, I don't really like the proposal either.  I believe the
> current draft is adequate.  I was just attempting to bridge Kent's
> proposal with your earlier proposal which was adopted after IETF 100
> discussions.
>  
> > if the
> Yes, with (v12) design, both the encoding and transport cannot vary by
> subscription.  There were many reasons for this.  Some of these
> reasons were discussed as part of WG review of this topic in IETF 100,
> and during the following rough consensus call:
> > strongly
> With "tcp" I believe Kent is attempting to find some home for receiver
> address info prior to the availability of call home specifications.

If we keep the -12 design, this is not an issue at all...

> Kent's thinking is not unreasonable as per point (1) below,
> OC-telemetry.yang and ietf-syslog.yang seem to have no issue with this
> simple design pattern.

... so I will not comment this for now, assuming we'll keep the -12
design.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 May 2018 20:02:12 +0000

Eric,

My proposal is indeed for this draft to rearrange itself to match the "Outbound Connections" pattern described in Section 3 of draft-schoenw-netmod-yang-pattern-00.txt.

This enables augmenting in the ietf-netconf-client (initiate) or ietf-netconf-server (call-home) models and their RESTCONF equivalents.   Ultimately, I would expect the netconf-notif and restconf-notif drafts to do this, not this draft, as you say.

For this draft, we need to discuss the "tcp" transport more.  I'm hoping that it can truly be just plain old TCP, which would require very little explanation, and potentially could be done in this draft (though it would be more consistent there to be another transport-binding draft for it).  That said, if you're trying to use "tcp" to really be something like ietf-netconf-server with all the security configuration left out, then you probably want something else (ietf-netconf-server-with-implicit-csps?) or, perhaps we could discuss modifying the ietf-ssh/tls client/server groupings themselves to make this happen.

I'm not tracking the -12 design Martin refers to, but I assume that all this is still inline to having a transport-per-encoding, which I think is what he wants, correct?

Kent // contributor

"Eric Voit (evoit)" <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13875.html&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=z3XeN5rmsrNHH6Mr6CBN3TfFqPxER3lZG4UdYSAS4y0&s=sxooJCUHG2mSKLd_wXaiEIevsOELvJ2Iw6-6wwvw6yM&e= 

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 18 May 2018 21:56:07 +0000

Kent,

> From: Kent Watsen, May 18, 2018 4:02 PM
> 
> Eric,
> 
> My proposal is indeed for this draft to rearrange itself to match the "Outbound
> Connections" pattern described in Section 3 of draft-schoenw-netmod-yang-
> pattern-00.txt.

While this "outbound connections" pattern is useful in some cases, it doesn't incorporate mechanisms to enforce that each independent receiver for a subscription must use the same transport (per the decision at IETF 100).  So we need to overlay additional mechanisms.  What is in my proposal is my attempt to bridge that gap.  Even though I prefer what is in the current -v12.

In the end, I don't care which answer we choose.  As long as we choose one.  

You proposed this new mechanism as contributor, which is great.  As WG chair, could you suggest how we close on the selection?  We have already have completed a rough consensus call on this design once.  If we do re-open, we should follow a plan to swiftly close again as well.

> This enables augmenting in the ietf-netconf-client (initiate) or ietf-netconf-
> server (call-home) models and their RESTCONF equivalents.   Ultimately, I
> would expect the netconf-notif and restconf-notif drafts to do this, not this
> draft, as you say.

I would expect that future iteration of netconf-notif might do this, as it is already in WGLC.   Perhaps restconf-notif could incorporate if client-server progresses in tandem.

> For this draft, we need to discuss the "tcp" transport more.  I'm hoping that it
> can truly be just plain old TCP, which would require very little explanation, and
> potentially could be done in this draft (though it would be more consistent
> there to be another transport-binding draft for it).  That said, if you're trying to
> use "tcp" to really be something like ietf-netconf-server with all the security
> configuration left out, then you probably want something else (ietf-netconf-
> server-with-implicit-csps?) or, perhaps we could discuss modifying the ietf-
> ssh/tls client/server groupings themselves to make this happen.

If we do reopen this design, my preference would be to drop "tcp", "address", and "port" since we apparently have no consensus.  Vendors can then do their own augmentations. where they will just put "address" and "port" back in somewhere under receivers. 

> I'm not tracking the -12 design Martin refers to, but I assume that all this is still
> inline to having a transport-per-encoding, which I think is what he wants,
> correct?

Martin has expressed that he is ok with the transport-per-encoding WG decision which came out of IETF 100.

Eric

> > > > Kent's underlying desire in the thread below is to insert a
> > > > transport case under
> > > > /subscriptions/subscription/receivers/receiver to match design
> > > > patterns used elsewhere.  If we really want to do this, the way
> > > > this could be done with the current design with Kent's proposal would be
> something like:
> > > >
> > > >        +--rw subscriptions
> > > The argument against this was (IIRC) that it is easier for the
> > > server if the transport + encoding is fixed per subscription, b/c
> > > then the server can prepare one payload that is sent to all
> > > subscribers.
> > >
> > > But I don't really buy this argument; if the operator needs
> > > different transports / encodings the current
> > > (-12) design
> > > forces the operator to create two subscriptions.  This means that
> > > the server has to filter the data twice, and then still do two
> > > different encodings / transports.
> >
> > -
> 2Darchive_web_netconf_current_msg13875.html&d=DwIGaQ&c=HAkYuh63rs
> uhr6
> > Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISla
> >
> JdcZo&m=z3XeN5rmsrNHH6Mr6CBN3TfFqPxER3lZG4UdYSAS4y0&s=sxooJCUHG
> 2mSKLd_
> > wXaiEIevsOELvJ2Iw6-6wwvw6yM&e= I am hoping this issue is not reopened
> > as the in-room and subsequent email threads had no dissention.
> >
> > > Also, unless there is a document that describes the "tcp" transport,
> > > I strongly think it should be removed.  If not, how can this be
> > > interoperable?
> >
> ... so I will not comment this for now, assuming we'll keep the -12 design.
> 
> 
> 
> /martin
> 
> 
> >
> > Eric
> >
> > > /martin
> > >
> > >
> > > > (1) The tcp case provides an initial option for of an easy
> > > > equivalence to the capability of "destination-address" and "destination-
> port"
> > > > which appears in OC-telemetry.yang.  And it follows the design
> > > > pattern as it appears in the UDP case leaf "address" and "port" of
> > > > ietf-syslog.yang.  Just placing an address and port into these
> > > > models has proven simple and effective.
> > > >
> > > > draft.)  Note: per the thread below, it is important not have
> > > > security credentials in this part of the subscription model as
> > > > could be dozens of configured subscriptions aimed at the same
> > > > receiver, and it would be confusing to the other users of these
> > > > credentials to look them up within this configured subscriptions model.
> > > >
> > > > (3) From this starting point, future case augmentations would
> > > > allow us to augment cases to "(transport)" for the placement of
> > > > call-home leafrefs to modules like ietf-netconf-server.yang.  This
> > > > would allow model users and applications the ability to shift to
> > > > using the leafref.
> > > >
> > > > > >> 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
> > > > > Yes, he mentioned issues related to keys, but he also mentioned
> > > > > the pattern [1] used by other drafts, which is what I'm more
> > > > > focused on now…
> > > > >
> > > > >
> > > > > > 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.,
> > > > > >> state that my thought is not to push this work towards [2]
> > > > > >> today, but more to ensure it follows the pattern.
> > > > > >>
> > > > > > 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
> > > > > expression referencing the "inline-address" identity, which
> > > > > appears to address some of the "what if the transport doesn't support
> IP"
> > > > > issue…
> > > >
> > > > > I don't like publishing a data model that hand-waves over parts
> > > > > of the configuration, and it was this line of thinking that
> > > > > caused update to the syslog draft.
> > > >
> > > > > Also, I don't recall seeing anywhere in this document a
> > > > > statement that the configuration model is incomplete - did I miss it?
> > > >
> > > > As configuration can vary transport, such a statement on
> > > > configuration if needed wouldn't be here.  If you look at
> > > > description of the call home process is described there.  If you
> > > > think it helpful, I can put in an informative reference to
> > > > > An address by itself may not a sufficient lookup key, as the
> > > > > server may have different services running on different ports
> > > > > and, of course, all sorts of security parameters can vary.
> > > >
> > > > I liked having port as well.  Martin requested its removal as it
> > > > could be populated with something which contradicts what is in the
> > > > call home configuration.
> > > >
> > > > populated only if it is different than a call home value if it
> > > > exists, or a default port number for the transport protocol.  This
> > > > should provide clarity on when it would or wouldn't be populated.
> > > >
> > > > > yes, this is what I'm thinking about.  The pattern described in
> > > > > [1] was designed to allow for such augmentations, but I don't
> understand
> > > > > authenticated (per requirement), maybe that requirement should
> > > > > be removed so that an unauthenticated "tcp" transport can be
> > > > > fully configured?
> > > >
> > > > without explicitly storing the keys in this model, or pointing to
> > > > the keys in a different model.
> > > >
> > > > > > 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
> > > > > example would help), but note that each instance of
> > > > > ietf-tcp-client fully specifies its security parameters, though
> > > > > a *lot* of the really redundant stuff is factored out via
> > > > > leafrefs to ietf-trust-anchors and ietf-keystore (assuming that
> > > > > draft comes back).
> > > >
> > > > > There is no other game in town, so to speak.  Though the
> > > > > question remains if this is now or later thing.
> > > >
> > > > > finally get the netconf-client-server draft to RFC, and so
> > > > > someone creates an identity for "netconf", but where would the "uses"
> > > > > grouping statement go?
> > > >
> > > > > >> and let the netconf-notif and restconf-notif modules augment
> > > > > >> in their respective transport-specific config into the "transport"
> > > > > >> choice node here?
> > > > > >
> > > > > I'm okay with us coming up with an unauthenticated "tcp"
> > > > > transport now, leaving the crypto stuff out for now, so long as
> > > > > we have a pattern that we can follow to augment in what we need
> later.
> > > > Per above, I believe we can identify the tcp address and port,
> > > > with an expectation that leafrefs are later augmentable to
> > > > elements that are not currently modeled.
> > > >
> > > > > HTTP1.1, but the restconf-client-server draft only defines a
> > > > > binding for RESTCONF, have you put thought to how
> > > > > HTTP2 and HTTP1.1 can be
> > > > > supported?  for all intents and purposes, I think that it's the
> > > > > same config, but I haven't looked into the details either.
> > > >
> > > > Configured subscriptions only use HTTP2.  The working plan is for
> > > > the other identities to be used for operational datastore exposure.
> > > >
> > > > Eric
> > > >
> > > > > Kent  // contributor
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
>