Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

[Kent Watsen <[e-mail]>]

Okay, glad to see that you embrace using ietf-netconf-server, rather than ietf-netconf-client.  And I'll grant you that it's infinitely more likely that the ietf-netconf-server module would be implemented (i.e., the top-level /ncs:netconf-server container exists), more so than the ietf-netconf-client module would be implemented.  The WG created the top-level /ncc:netconf-client container more for the sake of symmetry than for having a use-case for when it would be implemented.  I think the question to ask is, is it possible that a device wants to use SN but doesn't *implement* ietf-netconf-server?

Even though it seems like ietf-netconf-server might always be implemented, I do not yet think it is okay for this data model to have a leafref to one of the globally-configured /ncs:netconf-server/ncs:call-home/ncs:netconf-client instances, since that instance would be expected to use normal NETCONF interactions (i.e. client-driven); it could be a problem if the server started sending <subscription-started> messages right away.  For this reason, maybe the SN data model needs to have its own instance of the netconf-server-grouping (perhaps with the top-level /listen tree pruned out), so then it's clear that these netconf-server instances are specifically for subscriptions?

I also have an issue with the proposed leafref because it leaves open the possibility that two subscriptions could point to the same /ncs:netconf-server/ncs:call-home/ncs:netconf-client instance, which would likely cause protocol and state machine problems.  The same could occur even with the suggestion at the end of the previous paragraph.  I don't have a good answer for how to resolve this problem yet using YANG, but it seems like something the server could enforce when the subscriptions are being configured (i.e. return <rpc-error> for an <edit-config>).

Kent // contributor


On 6/20/18, 8:52 AM, "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Kent,

From: Kent Watsen, June 19, 2018 7:57 PM


Hi Eric,

In your example below, why are you augmenting in a leafref, as opposed to doing something like "uses netconf-client-grouping;"?   The idea is that each instance of a publisher *is* a netconf-client, or a restconf client, or whatever, as opposed to the having a reference to some external client instance.

<Eric> It is certainly possible to augment in the grouping rather than a leafref.

However this augmentation is going under each subscription.  So it seems reasonable to use a leafref to point to a reusable definition rather than to make each subscription to repeat the same parameters.  Also as a common NETCONF connection could be reused for non-publisher uses, it would seem to be better not to include this call-home information under anything which is subscription-specific.

Per a parallel thread from you, I agree that referring to the ietf-netconf-server.yang model is a better match for this purpose.  Based on that, the leafref would be to “/netconf-server/call-home/netconf-client/name”.  And the result would be an augmentation of ietf-netconf-subscribed-notifications.yang to:




module ietf-netconf-subscribed-notifications-plus {



  prefix nsnp;



  import ietf-netconf-server { prefix ncs; }

  import ietf-subscribed-notifications { prefix sn; }

  import ietf-netconf-subscribed-notifications { prefix nsn; }



  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {

   when 'derived-from(../../../transport, "nsn:netconf")';

   description

      "This augmentation allows NETCONF specific parameters to be exposed for a receiver.";

    leaf netconf-endpoint {

      type leafref {

        path "/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name";

      }

      description

        "Remote client which need to initiate the NETCONF transport if an existing NETCONF session from that client is not available.";

    }

  }



}



Eric


Kent // contributor


On 6/12/18, 5:24 PM, "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:


Hi Kent,

Hi Martin,



In line.



Also, Kent if my recommended solution below doesn't sway you, can you set up a virtual interim so that the WG can close on this (and any other concerns) before Montreal?





> From: Kent Watsen, June 11, 2018 8:40 PM

>

> Hi Eric,

>

> Following-up on this thread after some delay.

>

> K.

>

> ===== original message =====

>

> > Kent,

> >

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

>

> augment-in a "must" expression?



Several reasons why I wouldn't recommend this:



(a) Augmenting a "must" expression into an existing node isn't supported by YANG 1.1.    (Note: it is possible to augment a 'when' statement, assuming you are then adding a new leaf/node.)



(b) I don't know how you would design and then augment a subscription-level 'when' constraint which would enforce a common transport subtree choice across all receivers.



(c)  A common transport "choice" selection across multiple subtrees was not part of the requirements underpinnings of your referenced design pattern.





What I do recommend is a future augmenting-in of transport specific leafrefs containing 'when' statements bound to transport (e.g., to draft-ietf-netconf-netconf-client-server).   For example the following yang model could augment NETCONF receiver specific parameters.  These parameters could even be beyond any ietf-netconf-subscribed-notifications.yang:



module ietf-netconf-subscribed-notifications-plus {



  prefix nsnp;



  import ietf-netconf-client { prefix ncc; }

  import ietf-subscribed-notifications { prefix sn; }

  import ietf-netconf-subscribed-notifications { prefix nsn; }



  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {

   when 'derived-from(../../../transport, "nsn:netconf")';

   description

      "This augmentation allows NETCONF specific parameters to be exposed for a receiver.";

    leaf netconf-endpoint {

      type leafref {

        path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server/ncc:endpoints/ncc:endpoint/ncc:name";

      }

      description

        "Remote client which need to initiate the NETCONF transport if an existing NETCONF session from that client is not available.";

    }

  }



}



Compiles to:

  +--rw subscriptions

    +--rw subscription

        +--rw receivers

           +--rw receiver* [name]

              +--rw name                    string

              +--rw nsnp:netconf-endpoint?   leafref



As the leaf netconf-endpoint can only appear when there is netconf transport, I don't know what isn't covered by this.  And if you really wanted to, you could even add your 'choice' and 'case' nodes to the augmentation above if you wanted to force the previous design pattern you referenced.  But that would be unnecessary.  And we wouldn't have to decide on this question during the current review cycle.



BTW: if you want to play with such augmentations, files to work from can be seen at:
https://github.com/netconf-wg/notif-netconf/tree/master/augmenting%20ietf-netconf-subscribed-notifications.yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_notif-2Dnetconf_tree_master_augmenting-2520ietf-2Dnetconf-2Dsubscribed-2Dnotifications.yang&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=B-1eb8IYfvgrKJnbpBxKGZcmqc-oRQyBVKCp084zgRQ&s=BGDTRJygO395p1zi78UZF9aZXIWCTmEsBuXVzIC_u0o&e=>



> > What is in my proposal is my attempt to bridge that gap.  Even though

> > I prefer what is in the current -v12.

>

> Please see about using the outbound connection pattern.  At least model it and

> bring it to the list and perhaps discuss in Montreal, or a virtual interim before.

> This is a significant decision.  I'm sure it seems like a pain, but having reworked

> some of my own models to conform to it, I have to admit that the models

> improved.

>

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

>

> of course.



Hopefully you like what is above.  If not can you call a virtual interim before Montreal if that is what is necessary to close this issue?



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

>

> I don't know what rough consensus call you refer to, was this particular issue

> discussed?  Regardless, in order to close this issue now, my recommendation is

> to model it out and see if there are any problems



Hopefully the arguments above cover this.



> if no, then it’s a win,

> otherwise, there will be more discussion.  What I'm looking for is more detail

> around how the other transports will be configured.  I believe that the plan is

> to eventually use the ietf-netconf-server and ietf-restconf-server models,

> right?  Maybe we can see how that looks now?



Hopefully the example above shows how to leafref into different models.

> From a chair perspective, Mahesh and I observe that a lot of changes have

> occurred during this cycle.  Once the current threads have all been driven to

> ground, then we will want to ask the WG if they now think that the drafts are

> ready, which may trigger another last call.



I thought we are still within last call?    Maybe this is a procedural question based on the draft version number?



Certainly we have had many excellent voices and votes heard during the current round of comments.   Requiring all people to voice and vote again if they have already communicated they are comfortable would seem unnecessarily burdensome.



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

>

> That the draft is in last call is not a problem.  A draft can go through more than

> one, and usually that is needed most when a lot of changes occurred.  Anyway,

> just know that the process is more iterative/agile than waterfall.



I understand the process can be more agile.   As I have not let any comments sit more than a couple days, and as nobody has voted 'no', I am not seeing issue with the current last call.   Again, maybe this is just a procedural question?



> To the point as if it's in this version or next, we need to discuss

> it more.   For instance, perhaps we could put it in this one and

> then use a feature statement to hide all the crypto details when the feature

> isn't supported?

>

> Notice already that ietf-netconf-server has feature statements "ssh-call-home"

> and "tls-call-home" and, it appears that neither has to be supported, albeit the

> "transport" choice is "mandatory true", but another transport definition (tcp-

> call-home?) could be augmented-in.  This seems to give what you want (avoid

> configuring crypto now) while also being in-line with these other drafts.  What

> do you think?



I believe my proposal above works.  It also allow for the augmentation of new transport types.   I do not know how the alternative design is supportable given limitations of the YANG 1.1 augment statement.



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

>

> In the netconf-notif draft, or this one?  I think we'd want it to be in netconf-

> notif, as that's the transport-binding draft.  Okay then, so that draft would

> have a note that the additional configuration would need to be provided by

> external mechanisms?



My first preference would be to keep things as they are.   I believe the proposal above meets all the constraints.  I know of no other proposal which does.



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

>

> Right, but in order to satisfy that, would we need a "must" expression or

> something else?



There is such a ‘must’ constraint.  Right now the YANG model only exposes "encoding" for configured subscriptions via:

when 'not(../transport) or derived-from(../transport, "sn:configurable-encoding")';



You can see this constraint in the model:

https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-13.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-2Dnetconf-2Dsubscribed-2Dnotifications-2D13.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=B-1eb8IYfvgrKJnbpBxKGZcmqc-oRQyBVKCp084zgRQ&s=w2JBIolqb0viBFx1wIeb52JZV_8aBCnbMka3aZzA0Uw&e=>



It is possible to get more fancy & complex with the encoding constraints.  For example if you want to add yet another constraints which limits the set of configurable encodings which might be allowed for a specific transport on a particular publisher.  For a proposal on how this might be done check out the thread:

https://www.ietf.org/mail-archive/web/netconf/current/msg14650.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg14650.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=B-1eb8IYfvgrKJnbpBxKGZcmqc-oRQyBVKCp084zgRQ&s=e6t52otBIVUtUnBvTx_rpEE4u2VWAaRvHZq3ZWheVxQ&e=>

But just because we can get more complex doesn’t mean we should.   In no way am I recommending adopting this complexity, as it requires new managed objects.



Eric



> > Eric

>

> Kent // contributor

>

>

>

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

> > > > From: Martin Bjorklund, May 18, 2018 8:44 AM

> > > >

> > > > "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> 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

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

> > > >

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

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

> > >

> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma

> > > il

> > > -

> >

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

> > >

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

> >

> >

> > >

> > > Eric

> > >

> > > > /martin

> > > >

> > > >

> > > > > 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:[e-mail]>

> > > > > > wrote:

> > > > > >

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

> > > > > >

> > > > > > 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 endpoint* [name]          +--rw receiver* [name]

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

> > > > > >

> > > > > >

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

> > > > > >

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

> > > > >

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

> > > > > >

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

> > > > >

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

> > > > > >

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

> > > > >

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

> > > > >

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

> > > > > >

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

> > > > >

> > > > > The structures are proposed here to allow for growth into a

> > > > > later solution.

> > > > >

> > > > > > >> Maybe this draft should leave the "transport" choice node

> > > > > > >> empty,

> > > > > > >

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

> > > > >

> > > > > A place now exists in the proposal above.

> > > > >

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

> > > > > >

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

> > > > >

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

> > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > >

> >

>

>

>

>