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

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Jun 2018 00:40:15 +0000

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?

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

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

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.

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

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?

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

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

> Eric

Kent // contributor

> "Eric Voit (evoit)" <[email-masked]> wrote:
> > > From: Martin Bjorklund, May 18, 2018 8:44 AM
> > >
> > > "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
> > > >           +--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_mail
> > -
> 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:[email-masked]>
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Jun 2018 21:24:56 +0000

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

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

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

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

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

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

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

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

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

> >> ietf-netconf-server with all the security configuration left out,

> >> then you probably want something else

> >> (ietf-netconf-server-with-implicit-csps?)

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

> 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

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

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 Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:

> > > > "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:

> > > > > this could be done with the current design with Kent's proposal

> > > > > would be

> > > > subscription?  If this is the case, I don't think this new

> > > > proposal adds anything.

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

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

> > > OC-telemetry.yang and ietf-syslog.yang seem to have no issue with

> > > this simple design pattern.

> > > > > equivalence to the capability of "destination-address" and

> > > > > "destination-

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

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

> > > > > > On 5/9/18, 4:17 PM, "Eric Voit (evoit)"

> > > > > > <mailto:[email-masked]>

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

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

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

> > > > > > > under the subscription.  This is the current tree, with

> > > > > > > transport high

> > > > > > appears to address some of the "what if the transport doesn't

> > > > > > support

> > > > > > >> sufficient for configuration.  I thought the receiver

> > > > > > >> needed to

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

> > > > > (c) when the call home drafts are ready, we can augment a

> > > > > leafref under /subscriptions/subscription/receivers/receiver.

> > > > > > > *CAN* provide the requisite information needed to look up

> > > > > > > the remote host authentication and proper call home information

> for

> > > > > > > this information today without integrating useful but

> > > > > > > complex

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

> > > > > > yes, this is what I'm thinking about.  The pattern described

> > > > > > in [1] was designed to allow for such augmentations, but I

> > > > > > don't

> > > > > without explicitly storing the keys in this model, or pointing

> > > > > to the keys in a different model.

> > > > > > > emphasize the need for separate the subscription model as

> > > > > > > all the details for such authentication and transport

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

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

> > > > > later solution.

> > > > > > someone creates an identity for "netconf", but where would the

> "uses"

> > > > > > >> and let the netconf-notif and restconf-notif modules

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

> "transport"

> > > > > > > While it could be augmented, I believe “out of scope”

> > > > > > > awaiting the

> > > > > > > Especially as we shouldn’t repeat this info for each and

> > > > > > >every subscription.

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

> > > > > > That said, note that the IESG made RFC 6587 HISTORIC and may

> > > > > > not have much appetite for an unauthenticated transport again…

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Jun 2018 23:56:49 +0000

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.

Kent // contributor

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

Hi Kent,

Hi Martin,

In line.

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Compiles to:

  +--rw subscriptions

    +--rw subscription

        +--rw receivers

           +--rw receiver* [name]

              +--rw name                    string

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

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

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

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 20 Jun 2018 12:52:28 +0000

Hi Kent,

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

Hi Eric,

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

  prefix nsnp;

  import ietf-netconf-server { prefix ncs; }

   description

    leaf netconf-endpoint {

      type leafref {

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

      }

      description

    }

  }

}

Eric

Kent // contributor

Hi Kent,

Hi Martin,

In line.

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Compiles to:

  +--rw subscriptions

    +--rw subscription

        +--rw receivers

           +--rw receiver* [name]

              +--rw name                    string

Eric

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Jun 2018 15:39:39 +0000

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)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Hi Eric,

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Eric

Kent // contributor

Hi Kent,

Hi Martin,

In line.

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Compiles to:

  +--rw subscriptions

    +--rw subscription

        +--rw receivers

           +--rw receiver* [name]

              +--rw name                    string

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 20 Jun 2018 18:11:44 +0000

From: Kent Watsen, June 20, 2018 11:40 AM

<Eric>  Yes, this will be possible.   Reasons would include: alternative transports (COMI, UDP), HTTP2 configured subscriptions (which might use ietf-restconf-server), or no need for a publisher to include the configured subscriptions feature.

<Eric> The original thread was trying to enforce a single transport across the receivers of a configured subscription, and where objects specific to that transport could be augmented to those receivers.   The design pattern in the example augmentation below seems to do that.  This design pattern should hold whether a leafref is augmented in, or a group is augmented in.   This design pattern also works with the existing SN model.  I don’t know of an alternate proposal which meets these requirements.

If this makes sense, the question becomes when to apply this design pattern on top of SN.   I agree there are interesting questions you raise above.  These questions appear to be bound to NETCONF call-home, and therefore the answers should be more closely aligned with draft-ietf-netconf-netconf-event-notifications rather than SN itself.

That is the driver behind my “ietf-netconf-subscribed-notifications-plus.yang” below.  Whether it augments in a  leafref or a group, this snippet of YANG provides a template for transport specific augmentations.  And using this template, how to embody NETCONF call home for subscriptions  could be delivered in a timeframe concurrent with “ietf-netconf-server.yang”.

Noe: If you wanted, a possible alternative to concurrent module delivery might be a single model.  To do this you would include a “subscription support” feature within “ietf-netconf-server.yang”.    The needed augmentation to "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could then be made there.  (Note: that augmentation of course would be refined to meet the call-home questions/considerations from this thread, such as being aimed to its own instance of the netconf-server-grouping.)

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.

<Eric> Looking closer, perhaps a better place for the receiver leafref would be a choice of:
/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name/ncs:ssh/ncs:endpoints/ncs:endpoint/ncs:name
or
/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name/ncs:tls/ncs:endpoints/ncs:endpoint/ncs:name

But again, I am fine with anything which doesn’t insert redundant data as part of the receiver call home configuration.

Eric

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

Hi Kent,

Hi Eric,

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Eric

Kent // contributor

Hi Kent,

Hi Martin,

In line.

  prefix nsnp;

   description

    leaf netconf-endpoint {

      type leafref {

      }

      description

    }

  }

}

Compiles to:

  +--rw subscriptions

    +--rw subscription

        +--rw receivers

           +--rw receiver* [name]

              +--rw name                    string

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 21 Jun 2018 15:35:49 +0000

Search for <Kent> below.

// contributor

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

<Kent> I should've be more specific: is it possible that a device would use netconf-notif (where your leafref is defined) but not implement ietf-netconf-server?   Similarly, restconf-notif would presumably have a leafref to ietf-restconf-server, etc.

<kent-orig> 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?
 
<Eric> The original thread was trying to enforce a single transport across the receivers of a configured subscription, and where objects specific to that transport could be augmented to those receivers.

<Kent> Sorry, can you go over this again.  What is the stated goal?  I recall Martin wanting the same encoding across receivers, but the same transport too?  I assume you don't mean "same transport" but "same kind of transport"?  So, if one receiver of a subscription uses netconf-notif, they all must use netconf-notif?

<Eric> The design pattern in the example augmentation below seems to do that.  This design pattern should hold whether a leafref is augmented in, or a group is augmented in.   This design pattern also works with the existing SN model.  I don’t know of an alternate proposal which meets these requirements.

<Kent> unsure.
 
<Eric> If this makes sense, the question becomes when to apply this design pattern on top of SN.   I agree there are interesting questions you raise above.  These questions appear to be bound to NETCONF call-home, and therefore the answers should be more closely aligned with draft-ietf-netconf-netconf-event-notifications rather than SN itself.

<Kent> agreed, most of this regards what's in the transport-binding drafts (netconf-notif, etc.), but I'm wanting to do this to prove out that the SN model.
 
<Eric> That is the driver behind my “ietf-netconf-subscribed-notifications-plus.yang” below.  Whether it augments in a  leafref or a group, this snippet of YANG provides a template for transport specific augmentations.  And using this template, how to embody NETCONF call home for subscriptions  could be delivered in a timeframe concurrent with “ietf-netconf-server.yang”.    

<Kent> I understand you're trying to say "let's not worry about how ietf-netconf-server works with this now".  I appreciate the desire to defer what we can.  I will again say, as co-chair, that I'm okay with us moving without having a draft that depends on ietf-netconf-server or the ietf-restconf-server modules.  That said, I don't understand what value the *conf-notif drafts have if they don't.  It seems that these drafts should depend on the ietf-*conf-server modules, but in order to get something to market faster, we want them to depend on something more like the ietf-*conf-no-crypto-server (right?), which the SN has further reduced to a single "address" leaf, which might be fine, but I don't think it should be in the SN model, since the ietf-*conf-server modules already define an address field, which would be redundant.

<Eric> Noe: If you wanted, a possible alternative to concurrent module delivery might be a single model.  To do this you would include a “subscription support” feature within “ietf-netconf-server.yang”.    The needed augmentation to "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could then be made there.  (Note: that augmentation of course would be refined to meet the call-home questions/considerations from this thread, such as being aimed to its own instance of the netconf-server-grouping.)  

<Kent> If I understand correctly, this would be a way to flag the call-home connection as being for SN, which addresses the I raised about how that would be known.  This is possible, and it might work well, but rather than put it into the ietf-*conf-server models directly, I think it would be better for the *conf-notif drafts to augment in the flag.

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

 
<Kent> No, just pointing to /ncs:netconf-server/ncs:call-home/ncs:netconf-client should work, since the instance can have only one transport (ssh or tls) defined at a time.  That said, if your requirement is that they must all be ssh or must all be tls, we have a bigger issue.   FYI, the list of "endpoints" is there for HA reasons - they're a pool of failover endpoints the server can try - is that concept consistent with the SN draft?

/kw

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 21 Jun 2018 16:59:26 +0000

> From: Kent Watsen, June 21, 2018 11:36 AM
> 
> Search for <Kent> below.
> 
> // contributor
> 
> 
> <kent-orig> 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?
>
> <Eric>  Yes, this will be possible.   Reasons would include: alternative transports
> (COMI, UDP), HTTP2 configured subscriptions (which might use ietf-restconf-
> server), or no need for a publisher to include the configured subscriptions
> feature.
> 
> <Kent> I should've be more specific: is it possible that a device would use
> netconf-notif (where your leafref is defined) but not implement ietf-netconf-
> server?   Similarly, restconf-notif would presumably have a leafref to ietf-
> restconf-server, etc.

Yes.  Cases would include:
(a) platform doesn't support configured subscriptions
(b) vendor has not yet implemented ietf-netconf-server, and uses something else.

As the draft-ietf-netconf-server-model is currently expired, I believe it safe to assume (b) will be common.

> <kent-orig> 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?
> 
> <Eric> The original thread was trying to enforce a single transport across the
> receivers of a configured subscription, and where objects specific to that
> transport could be augmented to those receivers.
> 
> <Kent> Sorry, can you go over this again.  What is the stated goal?  I recall
> Martin wanting the same encoding across receivers, but the same transport
> too?  I assume you don't mean "same transport" but "same kind of transport"?
> So, if one receiver of a subscription uses netconf-notif, they all must use
> netconf-notif?

Yes.   This was a WG decision driven through IETF 101.

https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html

> <Eric> The design pattern in the example augmentation below seems to do
> that.  This design pattern should hold whether a leafref is augmented in, or a
> group is augmented in.   This design pattern also works with the existing SN
> model.  I don’t know of an alternate proposal which meets these
> requirements.
> 
> <Kent> unsure.

I should have said is that there is no alternate proposal.  

What I am not sure about if one can even be defined with YANG using explicit case structure.
 
> <Eric> If this makes sense, the question becomes when to apply this design
> pattern on top of SN.   I agree there are interesting questions you raise
> above.  These questions appear to be bound to NETCONF call-home, and
> therefore the answers should be more closely aligned with draft-ietf-netconf-
> netconf-event-notifications rather than SN itself.
> 
> <Kent> agreed, most of this regards what's in the transport-binding drafts
> (netconf-notif, etc.), but I'm wanting to do this to prove out that the SN
> model.
> 
> <Eric> That is the driver behind my “ietf-netconf-subscribed-notifications-
> plus.yang” below.  Whether it augments in a  leafref or a group, this snippet of
> YANG provides a template for transport specific augmentations.  And using this
> template, how to embody NETCONF call home for subscriptions  could be
> delivered in a timeframe concurrent with “ietf-netconf-server.yang”.
> 
> <Kent> I understand you're trying to say "let's not worry about how ietf-
> netconf-server works with this now".  I appreciate the desire to defer what we
> can.  I will again say, as co-chair, that I'm okay with us moving without having a
> draft that depends on ietf-netconf-server or the ietf-restconf-server modules.
> That said, I don't understand what value the *conf-notif drafts have if they
> don't.  

Per cases (a) & (b) above, there is value.

>It seems that these drafts should depend on the ietf-*conf-server
> modules, but in order to get something to market faster, we want them to
> depend on something more like the ietf-*conf-no-crypto-server (right?), which
> the SN has further reduced to a single "address" leaf, which might be fine, but I
> don't think it should be in the SN model, since the ietf-*conf-server modules
> already define an address field, which would be redundant.

I believe there is utility in address.  But at this point I am ok with removing "address".  And any vendors wanting to support (b) can then add proprietary augmentations to do this.

> <Eric> Noe: If you wanted, a possible alternative to concurrent module delivery
> might be a single model.  To do this you would include a “subscription
> support” feature within “ietf-netconf-server.yang”.    The needed
> augmentation to
> "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could then be
> made there.  (Note: that augmentation of course would be refined to meet the
> call-home questions/considerations from this thread, such as being aimed to
> its own instance of the netconf-server-grouping.)
> 
> <Kent> If I understand correctly, this would be a way to flag the call-home
> connection as being for SN, which addresses the I raised about how that would
> be known.  This is possible, and it might work well, but rather than put it into
> the ietf-*conf-server models directly, I think it would be better for the *conf-
> notif drafts to augment in the flag.

The best two choices I see are:
(1) Make an augmentation to the *conf-notif models.  This could be done via new drafts, and the model within. 
(2) Add the flag to *conf-server models.  This eliminates the need for future updates to the *conf-notif drafts.  It also keeps call-home specifics in one place.

Both choices allow us to support (a) & (b) now.

> <kent-orig> 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.
> 
> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client/ncs:name/ncs:ssh/ncs:endpoints/ncs:endpoint/ncs:name
> or
> /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client/ncs:name/ncs:tls/ncs:endpoints/ncs:endpoint/ncs:name
> 
> <Kent> No, just pointing to /ncs:netconf-server/ncs:call-home/ncs:netconf-
> client should work, since the instance can have only one transport (ssh or tls)
> defined at a time.  That said, if your requirement is that they must all be ssh or
> must all be tls, we have a bigger issue. 

There is no such requirement for all ssh or tls.  So it looks like such a future leafref might work.

>  FYI, the list of "endpoints" is there for
> HA reasons - they're a pool of failover endpoints the server can try - is that
> concept consistent with the SN draft?

I don't see any conflict.   In fact it should be a nice benefit of pointing to *conf-server.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Jun 2018 20:30:20 +0000

Hi Eric,

>(b) vendor has not yet implemented ietf-netconf-server, and uses something else.

(a) is this a valid case?  - I thought this conversion only regards configured subscriptions.  No
leafref or equivalent would be needed to support a dynamic subscription.  Right?

(b) this seems like a possibility, but then I think this make the case for why a leafref to the global *conf servers definitions won't always work.  This is why I was thinking before that your modules might themselves *use* the *conf-server-groupings (while pruning out unneeded parts, e.g., the "listen" subtree), so that it's independent of what the system has implemented at the global level.

> As the draft-ietf-netconf-server-model is currently expired, I believe it safe to assume (b) will be common.

Good grief, the WG abandoned that draft two years ago during a factoring effort.  The current draft is here, and it's very much alive; there was big update a couple weeks ago.  Here's the latest: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-06.

> 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=k7VsSkN2Q165UV6B4VmVssEhPOMrwj4K7_BDR5wHSc0&s=Q6QpnXZg_HVNPxTCTjdf20mC56AQyCPM55K_23ouVeQ&e=

Okay, I see it, weak, but it's there.

I completely understand why we'd want the same encoding, but not so much same protocol, since each receiver has its own distinct instance of the protocol anyway, so it doesn't seem to make a difference, i.e. no runtime optimization.  Did you ever figure it out?

BTW, in that thread, I see Einar mentioning that the multiple receives are there to support HA/redundancy.  As I understand this, this would be duplicated-delivery to multiple receivers, which would be merged into some centralized datastore, where all the duplicates would be removed.  Is this your understanding too?  FWIW, the ietf-*conf-server modules also enable each call-home connection to a logical "netconf-client" composed of multiple endpoints, for HA purposes, but these endpoints are connected to one at a time.  So, when thinking about incorporating the ietf-*conf-servers, will having these two HA mechanisms in play at the same time cause any conflict?  Would it make sense to remove the multi-receiver HA config in SN and instead rely and the *-conf-server's HA mechanism + dynamic-subscriptions to fill in any gaps between reconnects?

> What I am not sure about if one can even be defined with YANG using explicit case structure.
 
<Kent> what do you mean by "explicit case structure"?  I don't see any in the example you shared previously...

> Per cases (a) & (b) above, there is value.

There is a difference between a server not *implementing* a ietf-*conf-server 
module and the *conf-notif not *using* the *conf-server-grouping statements.
My suggestion has been, that the *conf-notif drafts should have their own lists
of netconf-servers (via "uses" statements), and thereby not be dependent on the
existence of a global ietf-*conf-server instance (which may not exist).

Separately, there is the issue of how to get something to RFC status faster
than the client-server drafts (assuming that is a good idea).  My first thought,
mentioned before, is that we could define "no-crypto" variants of the modules,
thus ensuring that all the patterns are consistently applied, while not having
a dependency on those other modules.  This is hard to discuss currently because
ietf-netconf-subscribed-notifications and ietf-http-subscribed-notifications
don't actually enable configuring the transports yet…

> I believe there is utility in address.  But at this point I am ok with removing
> "address".  And any vendors wanting to support (b) can then add proprietary
> augmentations to do this.

The "address" leaf would be perfect in another circumstance, but it's redundant
in conjunction with the ietf-*conf usage, which already have an "address" leaf,
per "endpoint" no less.  My guess is that the "address" leaf needs to disappear
from the SN module, thereby allow each transport to augment in exactly what it
needs.

>> connection as being for SN, which addresses the issue I raised about how that
>> would be known.  This is possible, and it might work well, but rather than put
>> it into the ietf-*conf-server models directly, I think it would be better for
>> the *conf-notif drafts to augment in the flag.
>
> (2) Add the flag to *conf-server models.  This eliminates the need for future
>     updates to the *conf-notif drafts.  It also keeps call-home specifics in one place.
>

I like (1) more, as it then ties the existence of the flag to the *implementation*
of the corresponding *conf-server module.  

That said, I have to say that I'm not entirely sure if I understand if what is planned
is legal.  For instance, in a normal NETCONF call-home situation, the NETCONF session
begins with both sides sending <hello> messages and then the server waiting for the
client to send RPCs, which might include a 5277 <create-subscription>, after which
the <notifications> begin to flow.  Is this the same here, or are you expecting the 
<notification> messages to start flowing immediately?

> I don't see any conflict.   In fact it should be a nice benefit of pointing to *conf-server.

Great!

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 22 Jun 2018 22:39:05 +0000

Hi Kent,

> From: Kent Watsen, June 22, 2018 4:30 PM
> 
> Hi Eric,
> 
> 
> >> <kent-orig> 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?
> >>
> >> (COMI, UDP), HTTP2 configured subscriptions (which might use
> >> ietf-restconf- server), or no need for a publisher to include the
> >> configured subscriptions feature.
> >>
> >> <Kent> I should've be more specific: is it possible that a device
> >> would use netconf-notif (where your leafref is defined) but not implement
> ietf-netconf-
> (a) is this a valid case?  - I thought this conversion only regards configured
> subscriptions.  No leafref or equivalent would be needed to support a dynamic
> subscription.  Right?

Correct.  But your question was "can you use netconf-notif without a leafref to...".    Needing both drafts is absolutely the case for dynamic subscription support, and ietf-netconf-server would not be needed here.
 
> (b) this seems like a possibility, but then I think this make the case for why a
> leafref to the global *conf servers definitions won't always work.

Agree that nothing here will always work.  Deployments commonly will have a heterogeneous mixture of model ecosystem models.

This actually makes a *very* strong case for why the leafref should be added as an augmentation from the *conf-server models.  That way leafref augmentations are explicitly tied to the actual implementation of the model against which they refer.

> This is why I
> was thinking before that your modules might themselves *use* the *conf-
> server-groupings (while pruning out unneeded parts, e.g., the "listen" subtree),
> so that it's independent of what the system has implemented at the global
> level.

If you have 500 subscriptions, you then have to populate 500 identical groupings.  And yes this is possible.  But it makes the part of me which likes Normalized data quite uncomfortable.

But as I said before, it the WG wants such redundancy, fine.  Either choice need not impact decisions as part of LC.

> Good grief, the WG abandoned that draft two years ago during a factoring
> effort.  The current draft is here, and it's very much alive; there was big update
> a couple weeks ago.  Here's the latest: https://tools.ietf.org/html/draft-ietf-
> netconf-netconf-client-server-06.

Ahh.  I guess that is what I get for searching Google using the name of the YANG model...

> >> <kent-orig> 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?
> >>
> >> <Eric> The original thread was trying to enforce a single transport
> >> across the receivers of a configured subscription, and where objects
> >> specific to that transport could be augmented to those receivers.
> >>
> >> <Kent> Sorry, can you go over this again.  What is the stated goal?
> >> I recall Martin wanting the same encoding across receivers, but the
> >> same transport too?  I assume you don't mean "same transport" but "same
> kind of transport"?
> >> So, if one receiver of a subscription uses netconf-notif, they all
> >> must use netconf-notif?
> >
> JdcZo&m=k7VsSkN2Q165UV6B4VmVssEhPOMrwj4K7_BDR5wHSc0&s=Q6QpnX
> Zg_HVNPxTC
> > Tjdf20mC56AQyCPM55K_23ouVeQ&e=
> 
> 
> I completely understand why we'd want the same encoding, but not so much
> same protocol, since each receiver has its own distinct instance of the protocol
> anyway, so it doesn't seem to make a difference, i.e. no runtime optimization.
> Did you ever figure it out?

I have seen many subscriptions use a single NETCONF transport session.

In any case my proposal was to support transport per receiver.   The WG voted very clearly to use a common transport at and after IETF 101.   The WG document was changed accordingly.  I consider this issue closed.

> BTW, in that thread, I see Einar mentioning that the multiple receives are there
> to support HA/redundancy.  As I understand this, this would be duplicated-
> delivery to multiple receivers, which would be merged into some centralized
> datastore, where all the duplicates would be removed.  Is this your
> understanding too? 

Some implementations can choose to do this.  M

> FWIW, the ietf-*conf-server modules also enable each
> call-home connection to a logical "netconf-client" composed of multiple
> endpoints, for HA purposes, but these endpoints are connected to one at a
> time.  So, when thinking about incorporating the ietf-*conf-servers, will having
> these two HA mechanisms in play at the same time cause any conflict?  Would
> it make sense to remove the multi-receiver HA config in SN and instead rely
> and the *-conf-server's HA mechanism + dynamic-subscriptions to fill in any
> gaps between reconnects?

Multi-receiver is not just for HA.  And some HA will want multiple live connections.  But where it is used for single-live HA in NETCONF and RESTCONF, future implementations could choose to use *-conf-server for this function.  

> >> <Eric> The design pattern in the example augmentation below seems to
> >> do that.  This design pattern should hold whether a leafref is augmented in,
> or a

The explicit case structure was your proposed design pattern. But this pattern doesn't work.  Because you can't enforce a single transport.

As there is no alternate proposal, I am asserting WG consensus that the explicit case structure is not supported.  Which is the same consensus which came out of WG 101 on this particular topic.

> >> therefore the answers should be more closely aligned with
> >> draft-ietf-netconf- netconf-event-notifications rather than SN itself.
> >>
> >> <Kent> agreed, most of this regards what's in the transport-binding
> >> drafts (netconf-notif, etc.), but I'm wanting to do this to prove out
> >> that the SN model.
> >>
> >> plus.yang” below.  Whether it augments in a  leafref or a group, this
> >> snippet of YANG provides a template for transport specific
> >> augmentations.  And using this template, how to embody NETCONF call
> >> home for subscriptions  could be delivered in a timeframe concurrent with
> “ietf-netconf-server.yang”.
> >>
> >> <Kent> I understand you're trying to say "let's not worry about how
> >> ietf- netconf-server works with this now".  I appreciate the desire
> >> to defer what we can.  I will again say, as co-chair, that I'm okay
> >> with us moving without having a draft that depends on ietf-netconf-server
> or the ietf-restconf-server modules.
> >> That said, I don't understand what value the *conf-notif drafts have
> >> if they don't.
> >
> of netconf-servers (via "uses" statements), and thereby not be dependent on
> the existence of a global ietf-*conf-server instance (which may not exist).

While technically correct, there are several reasons why this is problematic.
(1) redundancy (see the 500 above)
(2) availability of the group means that a platform will have exposed *conf-server.   Explaining that a model is only available for its grouping would be quite a confusing deviation.
 
And in any case, these questions are all viable model augmentations which can be performed after *conf-server progresses.  Therefore no matter the disposition, there is need be no impact to SN at this time.

> Separately, there is the issue of how to get something to RFC status faster than
> the client-server drafts (assuming that is a good idea).  My first thought,
> thus ensuring that all the patterns are consistently applied, while not having a
> dependency on those other modules.  This is hard to discuss currently because

I would rather jettison the 'address' object.  This makes for a strong separation of interests for call home.  

> >> modules, but in order to get something to market faster, we want them
> >> to depend on something more like the ietf-*conf-no-crypto-server
> >> (right?), which the SN has further reduced to a single "address"
> >> leaf, which might be fine, but I don't think it should be in the SN
> >> model, since the ietf-*conf-server modules already define an address field,
> which would be redundant.
> >
> > I believe there is utility in address.  But at this point I am ok with
> > removing "address".  And any vendors wanting to support (b) can then
> > add proprietary augmentations to do this.
> 
> The "address" leaf would be perfect in another circumstance, but it's
> redundant in conjunction with the ietf-*conf usage, which already have an
> "address" leaf, per "endpoint" no less.  My guess is that the "address" leaf
> needs to disappear from the SN module, thereby allow each transport to
> augment in exactly what it needs.

Let's do that and end this thread.  We have a viable solution.

> >> <Eric> Noe: If you wanted, a possible alternative to concurrent
> >> module delivery might be a single model.  To do this you would include a
> “subscription
> >> "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could
> >> then be made there.  (Note: that augmentation of course would be
> >> refined to meet the call-home questions/considerations from this
> >> thread, such as being aimed to its own instance of the
> >> netconf-server-grouping.)
> >>
> >> connection as being for SN, which addresses the issue I raised about
> >> how that would be known.  This is possible, and it might work well,
> >> but rather than put it into the ietf-*conf-server models directly, I
> >> think it would be better for the *conf-notif drafts to augment in the flag.
> >
> > (1) Make an augmentation to the *conf-notif models.  This could be done via
> new
> >     drafts, and the model within.

Per the point at the beginning of the email, adding it *conf-server seems much cleaner.    You only can add the leafref if the *conf-server model is available.  The analysis and decision on this can be safely move later in any case.   

> That said, I have to say that I'm not entirely sure if I understand if what is
> planned is legal.  For instance, in a normal NETCONF call-home situation, the
> NETCONF session begins with both sides sending <hello> messages and then
> the server waiting for the client to send RPCs, which might include a 5277
> <create-subscription>, after which the <notifications> begin to flow.  Is this the
> same here, or are you expecting the <notification> messages to start flowing
> immediately?

A subscription started notification will be sent after the hellos are successful.   Can you point to something in RFC 6241 which says a <notification> can't be sent until an RPC is sent from the client?
 
Eric

> >> <Eric> Looking closer, perhaps a better place for the receiver leafref would
> be a
> >> choice of:
> >> But again, I am fine with anything which doesn’t insert redundant data as
> part
> >> of the receiver call home configuration.
> >>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Jun 2018 19:42:51 +0000

> Correct.  But your question was "can you use netconf-notif without a leafref to...".
> Needing both drafts is absolutely the case for dynamic subscription support, and
> ietf-netconf-server would not be needed here.

I read the above a few times, but I'm having a hard time understanding it.  Can
say it differently or provide an example?

> Agree that nothing here will always work.  Deployments commonly will have a 
> heterogeneous mixture of model ecosystem models.
>
> This actually makes a *very* strong case for why the leafref should be added as
> an augmentation from the *conf-server models.  That way leafref augmentations
> are explicitly tied to the actual implementation of the model against which they refer.

Not in the *conf-server models, the augments go into the *conf-notif models, I
assume that is what you meant.

> If you have 500 subscriptions, you then have to populate 500 identical groupings.

No, you have one grouping, with 500 /netconf-server/call-home/netconf-client
instances.

>  And yes this is possible.  But it makes the part of me which likes Normalized
>  data quite uncomfortable.
>

I don't believe that is a WG-preference thing, so much as an outcome of the current
design, which is that each receiver for each subscription has its own state-machine
and protocol messages.  There is no sharing; no two receives can use the same 
RFC 6241 NETCONF session, which effectively translates to each receiver having its 
own /netconf-server/call-home/netconf-client instance, right?

>> >> /ncs:netconf-server/ncs:call-home/ncs:netconf-client instances,
>> > <mangled URL removed>
> In any case my proposal was to support transport per receiver.   The WG voted 
> very clearly to use a common transport at and after IETF 101.   The WG document
> was changed accordingly.  I consider this issue closed.

You didn't answer the question, which is essentially what benefit having a single
protocol provides?   Looking at the thread, I see Martin asked a similar question
which was never answered either.

> Some implementations can choose to do this.

Yes, but I would consider it a poor choice relative to the reconnection-strategy 
in the ietf-*conf-server modules.  That said, I don't necessary object, I'm just 
hoping this isn't the primary motivation for the SN model supporting multiple
receivers.

> Multi-receiver is not just for HA.  And some HA will want multiple live 
> connections.  But where it is used for single-live HA in NETCONF and RESTCONF,
> future implementations could choose to use *-conf-server for this function.  

Agreed. A subscription having a single receiver that is a /netconf-server/call-\
home/netconf-client instance can still be HA using the built-in reconnection
logic.  Is this what you meant by single-live HA?

> The explicit case structure was your proposed design pattern. But this pattern
> doesn't work.  Because you can't enforce a single transport.

Maybe it can and, even if it can't at the YANG-level, it doesn't mean that a
server can't enforce it during <edit-config> processing.

> As there is no alternate proposal, I am asserting WG consensus that the explicit
> case structure is not supported.  Which is the same consensus which came out 
> of WG 101 on this particular topic.

I don't think that we should put too much weight on this decision.  It was made
before the Last Call for which we're digging into many things.  I'm just trying
to understand the motivation behind this decision.  How is forcing the same 
transport for all receivers of a subscription a "good" thing?

> (1) redundancy (see the 500 above)

This is a non-issue (see above)

> (2) availability of the group means that a platform will have exposed *conf-server.
> Explaining that a model is only available for its grouping would be quite a
> confusing deviation.

No, it's easy, this is the difference between a module being *implemented* or
not.  The implementation status of each module is yang-library.

> And in any case, these questions are all viable model augmentations which can
> be performed after *conf-server progresses.  Therefore, no matter the disposition,
> there is need be no impact to SN at this time.

Already, there has been an impact to SN, as we removed the "address" leaf.  But
I agree that this fork in the discussion is primarily impacting the *conf-notif
drafts (not SN), I'm just using this thread for convenience sake, since all the
drafts are so connected.

> of interests for call home.  

+1

> Let's do that and end this thread.  We have a viable solution.

Agreed.

> Per the point at the beginning of the email, adding it *conf-server seems much
> cleaner.    You only can add the leafref if the *conf-server model is available.
> The analysis and decision on this can be safely move later in any case.   

We agree above that the ietf-*conf-server module may not be *implemented*, and
yet subscriptions still need to be configured, so then what they are leafref-ing
becomes the issue.   This is why I'm suggesting the netconf-notif YANG module 
*use* the netconf-server-group itself.  This way, when the netconf-notif draft
is implemented, its own definition comes into play.  When done this way, the 
flag would no longer be needed since the entire netconf-server instance would 
be SN-specific.

>> <create-subscription>, after which the <notifications> begin to flow.  Is this 
>> the same here, or are you expecting the <notification> messages to start flowing
>> immediately?
>
> A subscription started notification will be sent after the hellos are successful.
> Can you point to something in RFC 6241 which says a <notification> can't be sent
> until an RPC is sent from the client?
 
It's not a very good reference, but I found this (emphasis added):

   o  client: Invokes protocol operations on a server.  In addition, a
      client can *subscribe* to receive notifications from a server.

We should ask the WG.  All I know is that it's always been that the client does
something to initiate server behavior.  Admittedly, this is kind of a new thing,
and it might be okay, but I think it warrants review by others.

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 25 Jun 2018 21:27:20 +0000

> From: Kent Watsen, June 25, 2018 3:43 PM
> 
> >> >> 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?
> >> >>
> >> >(b) vendor has not yet implemented ietf-netconf-server, and uses
> >> >something
> >> else.
> >>
> >> (a) is this a valid case?  - I thought this conversion only regards
> >> configured subscriptions.  No leafref or equivalent would be needed
> >> to support a dynamic subscription.  Right?
> >
> > Needing both drafts is absolutely the case for dynamic subscription
> > support, and ietf-netconf-server would not be needed here.
> 

Dynamic subscriptions over NETCONF requires draft-ietf-netconf-netconf-event-notifications.   With these deployments, there there is no call home, there is no configuration, and there need be no ietf-netconf-server.yang leafref (or use of ietf-netconf-server.yang grouping).

> >> (b) this seems like a possibility, but then I think this make the
> >> case for why a leafref to the global *conf servers definitions won't always
> work.
> >
> > Agree that nothing here will always work.  Deployments commonly will
> > have a heterogeneous mixture of model ecosystem models.
> >
> > This actually makes a *very* strong case for why the leafref should be
> > added as an augmentation from the *conf-server models.  That way
> > leafref augmentations are explicitly tied to the actual implementation of the
> model against which they refer.
> 

My assertion is a good solution would be updating ietf-netconf-server.yang per what is below.  Note that an answer even further below regarding the sharing of a single NETCONF session across multiple subscriptions and typical RFC6241 protocol interactions is assumed.  But we could also insert your ietf-netconf-server.yang grouping just as effectively where the leafref is seen.

Anyway here are the following changes which would be made to ietf-netconf-server.yang 

  feature subscription-support {
    description
        "The 'subscription-support' feature indicates that the NETCONF server
         supports configured subscriptions over call-home connections.";
       reference
        "RFC xxxx: Customized Subscriptions to a Publisher's Event Streams";
     }

   if-feature "subscription-support";

With such a construct, it is impossible to add a leafref (or grouping) within ietf-subscribed-notifications unless ietf-netconf-server.yang exists.

> >> This is why I
> >> was thinking before that your modules might themselves *use* the
> >> *conf- server-groupings (while pruning out unneeded parts, e.g., the
> >> "listen" subtree), so that it's independent of what the system has
> >> implemented at the global level.
> >

Yes.    But I don't know why someone would voluntarily do add 500 repeated elements to a configuration datastore.

> >  And yes this is possible.  But it makes the part of me which likes
> > Normalized  data quite uncomfortable.
> >
> > But as I said before, it the WG wants such redundancy, fine.  Either
> > choice need not impact decisions as part of LC.
> 
> I don't believe that is a WG-preference thing, so much as an outcome of the
> current design, which is that each receiver for each subscription has its own
> state-machine and protocol messages.  There is no sharing; no two receives can
> use the same RFC 6241 NETCONF session, which effectively translates to each
> receiver having its own /netconf-server/call-home/netconf-client instance,
> right?

This is incorrect.    Protocol and state-machine messages have been decoupled from the transport session.

I am not sure why you think that subscriptions are unable to use a common NETCONF session?   Implementations of dynamic NETCONF subscriptions have been doing this for years.    Subscription multiplexing of configured and dynamic subscriptions over a common transport is a pre-requisite for solution scalability.

> >> >> instance of the netconf-server-grouping (perhaps with the
> >> >> top-level /listen tree pruned out), so then it's clear that these
> >> >> netconf-server
> >> >> <Eric> The original thread was trying to enforce a single
> >> >> transport across the receivers of a configured subscription, and
> >> >> where objects specific to that transport could be augmented to those
> receivers.
> >> >>
> >> >> I recall Martin wanting the same encoding across receivers, but
> >> >> the same transport too?  I assume you don't mean "same transport"
> >> >> but "same
> >> kind of transport"?
> >> I completely understand why we'd want the same encoding, but not so
> >> much same protocol, since each receiver has its own distinct instance
> >> of the protocol anyway, so it doesn't seem to make a difference, i.e. no
> runtime optimization.

Please see the slides from IETF 100 where this was debated.   
https://datatracker.ietf.org/meeting/100/materials/slides-100-netconf-draft-ietf-netconf-yang-pushsubscribed-notifications-03
Slide 6

Also please see the meeting minutes :
https://datatracker.ietf.org/meeting/100/materials/minutes-100-netconf-01 

and recording (starts at 16:55) which are quite clear on the decision criteria and decision reached.

> >> BTW, in that thread, I see Einar mentioning that the multiple
> >> receives are there to support HA/redundancy.  As I understand this,
> >> this would be duplicated- delivery to multiple receivers, which would
> >> be merged into some centralized datastore, where all the duplicates
> >> would be removed.  Is this your understanding too?
> >

It isn't

> >> FWIW, the ietf-*conf-server modules also enable each call-home
> >> connection to a logical "netconf-client" composed of multiple
> >> endpoints, for HA purposes, but these endpoints are connected to one
> >> at a time.  So, when thinking about incorporating the
> >> ietf-*conf-servers, will having these two HA mechanisms in play at
> >> the same time cause any conflict?  Would it make sense to remove the
> >> multi-receiver HA config in SN and instead rely and the
> >> *-conf-server's HA mechanism + dynamic-subscriptions to fill in any gaps
> between reconnects?
> >
> > Multi-receiver is not just for HA.  And some HA will want multiple
> > live connections.  But where it is used for single-live HA in NETCONF
> > and RESTCONF, future implementations could choose to use *-conf-server
> for this function.
> 

Yes

> >> >> <Eric> The design pattern in the example augmentation below seems
> >> >> to do that.  This design pattern should hold whether a leafref is
> >> >> augmented in,
> >> or a
> >> > What I am not sure about if one can even be defined with YANG using
> >> > explicit
> >> case structure.
> >>
> >> <Kent> what do you mean by "explicit case structure"?  I don't see
> >> any in the example you shared previously...
> >
> > The explicit case structure was your proposed design pattern. But this
> > pattern doesn't work.  Because you can't enforce a single transport.
> 

That is true.  If you wish to champion this alternate proposal, please call the interim.

> > As there is no alternate proposal, I am asserting WG consensus that
> > the explicit case structure is not supported.  Which is the same
> > consensus which came out of WG 101 on this particular topic.
> 
> I don't think that we should put too much weight on this decision.  It was
> made before the Last Call for which we're digging into many things.  I'm just
> trying to understand the motivation behind this decision.  How is forcing the
> same transport for all receivers of a subscription a "good" thing?

Per above, the decision was made in the room at IETF 100 per the recording and minutes above.  And the subsequent email debate.  There was lots of healthy debate.

> This is a non-issue (see above)

This is still an issue, as the drafts in WGLC support a single NETCONF session for all subscriptions and normal protocol operations.

> not.  The implementation status of each module is yang-library.

Yes, what you say is possible.  It is also more complex.

> Already, there has been an impact to SN, as we removed the "address" leaf.

I will remove the leaf after the thread is successfully concluded.

> But
> than
> a
> > I would rather jettison the 'address' object.  This makes for a strong
> separation
> > of interests for call home.
> 
> +1
> 
> 

So can we take out address and finally be done?   That would be a good thing.

> >> >     updates to the *conf-notif drafts.  It also keeps call-home specifics in
> one
> >> place.
> >> >

The NETCONF-Notif draft needs to be implemented now for dynamic subscriptions.

An update to NETCONF-notif for configured subscriptions is possible to insert the call-home leafref (or insert new grouping).   But this update becomes unnecessary if ietf-netconf-server.yang is augmented as described above.

> and it might be okay, but I think it warrants review by others.

You are welcome to make the request. 

Eric

> > >> defined at a time.  That said, if your requirement is that they must all be
> ssh
> > or

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2018 10:10:45 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > > Correct.  But your question was "can you use netconf-notif without a
> > > leafref
> > to...".
> Dynamic subscriptions over NETCONF requires
> draft-ietf-netconf-netconf-event-notifications.  With these
> deployments, there there is no call home, there is no configuration,
> and there need be no ietf-netconf-server.yang leafref (or use of
> ietf-netconf-server.yang grouping).
> 
> My assertion is a good solution would be updating
> ietf-netconf-server.yang per what is below.  Note that an answer even
> further below regarding the sharing of a single NETCONF session across
> multiple subscriptions and typical RFC6241 protocol interactions is
> assumed.  But we could also insert your ietf-netconf-server.yang
> grouping just as effectively where the leafref is seen.
> 
>         "Remote client which need to initiate the NETCONF transport if an
>         existing NETCONF session from that client is not available.";
>     }
>   }
> 
> With such a construct, it is impossible to add a leafref (or grouping)
> within ietf-subscribed-notifications unless ietf-netconf-server.yang
> exists.
> 
> > >> This is why I
> Yes.  But I don't know why someone would voluntarily do add 500
> repeated elements to a configuration datastore.
> 
> I am not sure why you think that subscriptions are unable to use a
> common NETCONF session?  Implementations of dynamic NETCONF
> subscriptions have been doing this for years.  Subscription
> multiplexing of configured and dynamic subscriptions over a common
> transport is a pre-requisite for solution scalability.

I don't think muliplexing of configured and dynamic subscriptions over
a single session is possible.  If this is the intention of the current
design, the document needs to explain how this is supposed to be done.

Multiplexing multiple configured subscriptions over a single transport
session could be possible, but the document doesn't mention this.
Again, if this is the intention, it needs to be properly described in
the document.

This said, "session sharing" can be acheived with the current design,
as well as with the alternative design where the protocol is defined
per receiver rather than per subscription.  But it won't be
interoperable unless it is described.

/martin

> > You didn't answer the question, which is essentially what benefit
> > having a
> > single
> > protocol provides?  Looking at the thread, I see Martin asked a
> > similar
> > question
> > >> >> group is augmented in.  This design pattern also works with the
> > >> >> existing
> > SN
> Per above, the decision was made in the room at IETF 100 per the
> recording and minutes above.  And the subsequent email debate.  There
> was lots of healthy debate.
> 
> > >> There is a difference between a server not *implementing* a
> > >> ietf-*conf-
> > server
> > >> My suggestion has been, that the *conf-notif drafts should have their
> > >> own
> > lists
> > >> of netconf-servers (via "uses" statements), and thereby not be
> > >> dependent
> > on
> This is still an issue, as the drafts in WGLC support a single NETCONF
> session for all subscriptions and normal protocol operations.
> 
> > > (2) availability of the group means that a platform will have exposed
> > > *conf-
> > server.
> > > And in any case, these questions are all viable model augmentations
> > > which
> > can
> > >> > (1) Make an augmentation to the *conf-notif models.  This could be
> > >> > done
> > via
> > >> new
> > > Per the point at the beginning of the email, adding it *conf-server
> > > seems
> > much
> > We agree above that the ietf-*conf-server module may not be
> > *implemented*,
> > and
> > *use* the netconf-server-group itself.  This way, when the
> > *netconf-notif draft
> An update to NETCONF-notif for configured subscriptions is possible to
> insert the call-home leafref (or insert new grouping).  But this
> update becomes unnecessary if ietf-netconf-server.yang is augmented as
> described above.
> 
> 
> > >> the same here, or are you expecting the <notification> messages to
> > >> start
> > flowing
> > >> immediately?
> > >
> > > Can you point to something in RFC 6241 which says a <notification>
> > > can't be
> > sent
> > > >> client should work, since the instance can have only one transport
> > > >> (ssh or
> > > tls)
> > > > I don't see any conflict.  In fact it should be a nice benefit of
> > > > pointing to
> > > *conf-server.
> > >
> > > Great!
> > >
> > >
> > > Kent // contributor
> > >
> > 
> > 
> > 
> > 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jun 2018 17:08:53 +0000

> From: Martin Bjorklund, June 26, 2018 4:11 AM
> 
> > > >> >> ietf-netconf-server, rather than ietf-netconf-client.  And
> > > >> >> I'll grant you that it's infinitely more likely that 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
> > > >> >> <Eric> Yes, this will be possible.  Reasons would include:
> > > >> >> alternative
> > > >> transports
> > > >> >> ietf-restconf- server), or no need for a publisher to include
> > > >> >> the configured subscriptions feature.
> > > >> >>
> > > >> >> <Kent> I should've be more specific: is it possible that a
> > > >> >> device would use netconf-notif (where your leafref is defined)
> > > >> >> but not implement
> > > >> ietf-netconf-
> > > >> >> server?  Similarly, restconf-notif would presumably have a
> > > >> >> leafref to
> > > >> >> ietf-
> > > >> >> restconf-server, etc.
> > > >> >
> > > >> (a) is this a valid case?  - I thought this conversion only
> > > >> regards configured subscriptions.  No leafref or equivalent would
> > > >> be needed to support a dynamic subscription.  Right?
> > > >
> > > > Correct.  But your question was "can you use netconf-notif without
> > > > a leafref
> > > to...".
> > > > Needing both drafts is absolutely the case for dynamic
> > > > subscription support, and ietf-netconf-server would not be needed here.
> > >
> > > I read the above a few times, but I'm having a hard time
> > > understanding it.  Can say it differently or provide an example?
> >
> > > > Agree that nothing here will always work.  Deployments commonly
> > > > will have a heterogeneous mixture of model ecosystem models.
> > > >
> > > > This actually makes a *very* strong case for why the leafref
> > > > should be added as an augmentation from the *conf-server models.
> > > > That way leafref augmentations are explicitly tied to the actual
> > > > implementation of the
> > > Not in the *conf-server models, the augments go into the *conf-notif
> > > models, I assume that is what you meant.
> >
> > > >> *conf- server-groupings (while pruning out unneeded parts, e.g.,
> > > >> the "listen" subtree), so that it's independent of what the
> > > >> system has implemented at the global level.
> > > >
> > > > If you have 500 subscriptions, you then have to populate 500
> > > > identical
> > > groupings.
> > >
> > > >  And yes this is possible.  But it makes the part of me which
> > > > likes Normalized  data quite uncomfortable.
> > > >
> > > > But as I said before, it the WG wants such redundancy, fine.
> > > > Either choice need not impact decisions as part of LC.
> > >
> > > I don't believe that is a WG-preference thing, so much as an outcome
> > > of the current design, which is that each receiver for each
> > > subscription has its own state-machine and protocol messages.  There
> > > is no sharing; no two receives can use the same RFC 6241 NETCONF
> > > session, which effectively translates to each receiver having its
> > > own /netconf-server/call-home/netconf-client
> > > instance,
> > > right?
> >
> I don't think muliplexing of configured and dynamic subscriptions over a single
> session is possible.  
>
> If this is the intention of the current design, the document
> needs to explain how this is supposed to be done.

What is your concern?

> Multiplexing multiple configured subscriptions over a single transport session
> could be possible, but the document doesn't mention this.
> Again, if this is the intention, it needs to be properly described in the
> document.

What is missing?  The subscribed-notification draft section 2.5.1 and Figure 9 describe how each receiver is pushed their own state notifications.  (I.e., the state machine is per-receiver.  It is not per-subscription, nor is it per-transport.)

> This said, "session sharing" can be acheived with the current design, as well as
> with the alternative design where the protocol is defined per receiver rather
> than per subscription.  

Agree.  Any issues with NETCONF transport multiplexing of subscriptions should be independent of the receiver YANG model.

> But it won't be interoperable unless it is described.

Likely NETCONF specific concerns would land in the NETCONF-notif.  I am happy to make any needed clarifications.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2018 20:42:40 +0200 (CEST)

> > needs to explain how this is supposed to be done.

Suppose a client connects to a server and starts a dynamic
subscription.  Can this session somehow be used for a configured
subscription?  I assume not.

> What is missing?  The subscribed-notification draft section 2.5.1
> and Figure 9 describe how each receiver is pushed their own state
> notifications.  (I.e., the state machine is per-receiver.  It is
> not per-subscription, nor is it per-transport.)

If there are two different subscriptions configured, each has its own
list of receivers.  Under which circumstances will the server decide
to use a single transport session for these two different
subscriptions?  I can't see any text about this in the document.

> Likely NETCONF specific concerns would land in the NETCONF-notif.  I am happy to make any needed clarifications.

I think you will need specific text in both subscribed-notifications
and in the transport drafts, if this is what you want to support.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jun 2018 19:30:40 +0000

> From: Martin Bjorklund, June 26, 2018 2:43 PM
> 
> > > > > >> >> 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
> > > > > >> >> ietf-restconf- server), or no need for a publisher to
> > > > > >> >> include the configured subscriptions feature.
> > > > > >> >>
> > > > > >> >> device would use netconf-notif (where your leafref is
> > > > > >> >> defined) but not implement
> > > > > >> ietf-netconf-
> > > > > >> >(b) vendor has not yet implemented ietf-netconf-server, and
> > > > > >> >uses something
> > > > > >> else.
> > > > > >>
> > > > > >> regards configured subscriptions.  No leafref or equivalent
> > > > > >> would be needed to support a dynamic subscription.  Right?
> > > > > >
> > > > > > Correct.  But your question was "can you use netconf-notif
> > > > > > without a leafref
> > > > > to...".
> > > > deployments, there there is no call home, there is no
> > > > configuration, and there need be no ietf-netconf-server.yang
> > > > leafref (or use of ietf-netconf-server.yang grouping).
> > > >
> > > > > >> (b) this seems like a possibility, but then I think this make
> > > > > >> the case for why a leafref to the global *conf servers
> > > > > >> definitions won't always
> > > > > work.
> > > > > >
> > > > > > Agree that nothing here will always work.  Deployments
> > > > > > commonly will have a heterogeneous mixture of model ecosystem
> models.
> > > > > >
> > > > > > That way leafref augmentations are explicitly tied to the
> > > > > > actual implementation of the
> > > > > Not in the *conf-server models, the augments go into the
> > > > > *conf-notif models, I assume that is what you meant.
> > > >
> > > > ietf-netconf-server.yang per what is below.  Note that an answer
> > > > even further below regarding the sharing of a single NETCONF
> > > > session across multiple subscriptions and typical RFC6241 protocol
> > > > interactions is assumed.  But we could also insert your
> > > > ietf-netconf-server.yang grouping just as effectively where the leafref is
> seen.
> > > >
> > > >       "This augmentation allows NETCONF specific parameters to be
> exposed
> > > >       for a receiver.";
> > > >     leaf netconf-endpoint {
> > > >       type leafref {
> > > > With such a construct, it is impossible to add a leafref (or
> > > > grouping) within ietf-subscribed-notifications unless
> > > > ietf-netconf-server.yang exists.
> > > >
> > > > > >> This is why I
> > > > > >> *conf- server-groupings (while pruning out unneeded parts,
> > > > > >> e.g., the "listen" subtree), so that it's independent of what
> > > > > >> the system has implemented at the global level.
> > > > > >
> > > > > I don't believe that is a WG-preference thing, so much as an
> > > > > outcome of the current design, which is that each receiver for
> > > > > each subscription has its own state-machine and protocol
> > > > > messages.  There is no sharing; no two receives can use the same
> > > > > RFC 6241 NETCONF session, which effectively translates to each
> > > I don't think muliplexing of configured and dynamic subscriptions
> > > over a single session is possible.
> > >
> > > If this is the intention of the current design, the document needs
> > > to explain how this is supposed to be done.
> >
> > What is your concern?
> 
> Suppose a client connects to a server and starts a dynamic subscription.  Can
> this session somehow be used for a configured subscription?  I assume not.

Why not?

> > > Multiplexing multiple configured subscriptions over a single
> > > transport session could be possible, but the document doesn't mention
> this.
> > > Again, if this is the intention, it needs to be properly described
> > > in the document.
> >
> > What is missing?  The subscribed-notification draft section 2.5.1 and
> > Figure 9 describe how each receiver is pushed their own state
> > notifications.  (I.e., the state machine is per-receiver.  It is not
> > per-subscription, nor is it per-transport.)
> 
> If there are two different subscriptions configured, each has its own list of
> receivers.  Under which circumstances will the server decide to use a single
> transport session for these two different subscriptions?

If the "transport", "address", "port" are the same, then a single transport session can be used.  

During the reviews however, you and Kent have argued away both "port" and  "address" from being objects under the receiver.  So vendor specific augmentations will be needed to identify "address" and "port".  (Unless you are now ok with letting these objects back into the draft, just for the purposes of enable this a common receiver transport session identification.)  The other option is to have a future leafref augmented to ietf-netconf-server.yang as described above.

>  I can't see any text about this in the document.

I have added the following to the NETCONF-Notif document section on configured subscriptions:

"It is possible to have multiple configured subscriptions sharing a common transport to a single receiver.  The method of identifying that a receiver happens to be the same as used with another subscription is left up to implementers of this specification."

The text above can be changed if you are ok with adding "address" and "port" back into the draft.

> > > This said, "session sharing" can be acheived with the current
> > > design, as well as with the alternative design where the protocol is
> > > defined per receiver rather than per subscription.
> >
> > Agree.  Any issues with NETCONF transport multiplexing of subscriptions
> should be independent of the receiver YANG model.
> >
> I think you will need specific text in both subscribed-notifications and in the
> transport drafts, if this is what you want to support.

I have added text to NETCONF-notif per above.

For subscribed-notifications, I have added the sentence to the first paragraph of the "configured subscriptions" section:

"Multiple configured subscriptions MUST be supportable over a single transport session."

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2018 22:13:11 +0200 (CEST)

> > this session somehow be used for a configured subscription?  I assume not.

How would a server know that a certain configured receiver is the same
as an ongoing session?  And as a client, suppose I just opened a
session to send one request and then I plan to close the sesssion.  I
probably don't want notifs on this session as well.

> transport session can be used.

What if the encoding is different?  What if the users are different?
Etc.  The point is that maybe there are cases when this can be done,
but you need to spell this out.

> During the reviews however, you and Kent have argued away both
> "port" and "address" from being objects under the receiver.  So
> vendor specific augmentations will be needed to identify "address"
> and "port".

I expect such objects to be added by the transport docs, not by
vendors (except for vendor-specific transports).

> (Unless you are now ok with letting these objects back
> into the draft, just for the purposes of enable this a common
> receiver transport session identification.)  The other option is to
> have a future leafref augmented to ietf-netconf-server.yang as
> described above.

> "It is possible to have multiple configured subscriptions sharing a
> common transport to a single receiver.  The method of identifying
> that a receiver happens to be the same as used with another
> subscription is left up to implementers of this specification."

I don't think this helps.  It means that the client has no way of
knowing on which sessions to expect notifs.

> "Multiple configured subscriptions MUST be supportable over a single

See above.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jun 2018 23:00:34 +0000

> From: Martin Bjorklund, June 26, 2018 4:13 PM
> Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
> 
> > > > > > > >> >> 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.
> > > > > > > >> >> 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
> > > > > > > >> >> <Kent> I should've be more specific: is it possible
> > > > > > > >> >> that a device would use netconf-notif (where your
> > > > > > > >> >> leafref is
> > > > > > > >> >> server?  Similarly, restconf-notif would presumably
> > > > > > > >> >> have a leafref to
> > > > > > > >> >> ietf-
> > > > > > > >> >> restconf-server, etc.
> > > > > > > >> >
> > > > > > > >> >(b) vendor has not yet implemented ietf-netconf-server,
> > > > > > > >> >and uses something
> > > > > > > >> else.
> > > > > > > >>
> > > > > > > >> (a) is this a valid case?  - I thought this conversion
> > > > > > > >> only regards configured subscriptions.  No leafref or
> > > > > > > >> equivalent would be needed to support a dynamic subscription.
> Right?
> > > > > > > >
> > > > > > > > subscription support, and ietf-netconf-server would not be
> > > > > > > > needed
> > > here.
> > > > > > >
> > > > > > > >> (b) this seems like a possibility, but then I think this
> > > > > > > >> make the case for why a leafref to the global *conf
> > > > > > > >> servers definitions won't always
> > > > > > > work.
> > > > > > > >
> > > > > > > > This actually makes a *very* strong case for why the
> > > > > > > > leafref should be added as an augmentation from the *conf-server
> models.
> > > > > > ietf-netconf-server.yang per what is below.  Note that an
> > > > > > answer even further below regarding the sharing of a single
> > > > > > NETCONF session across multiple subscriptions and typical
> > > > > > RFC6241 protocol interactions is assumed.  But we could also
> > > > > > insert your ietf-netconf-server.yang grouping just as
> > > > > > effectively where the leafref is
> > > seen.
> > > > > >
> > > > > >         "The 'subscription-support' feature indicates that the
> > > > > > NETCONF
> > > server
> > > > > > > >> *conf- server-groupings (while pruning out unneeded
> > > > > > > >> parts, e.g., the "listen" subtree), so that it's
> > > > > > > >> independent of what the system has implemented at the global
> level.
> > > > > > > >
> > > > > > > > If you have 500 subscriptions, you then have to populate
> > > > > > > > 500 identical
> > > > > > > groupings.
> > > > > > >
> > > > > > Yes.  But I don't know why someone would voluntarily do add
> > > > > > 500 repeated elements to a configuration datastore.
> > > > > >
> > > > > > > >  And yes this is possible.  But it makes the part of me
> > > > > > > > which likes Normalized  data quite uncomfortable.
> > > > > > > >
> > > > > > > outcome of the current design, which is that each receiver
> > > > > > > for each subscription has its own state-machine and protocol
> > > > > > > messages.  There is no sharing; no two receives can use the
> > > > > > > same RFC 6241 NETCONF session, which effectively translates
> > > > > > > to each receiver having its own
> > > > > > > /netconf-server/call-home/netconf-client
> > > > > > > instance,
> > > > > > > right?
> > > > > >
> > > > > > This is incorrect.  Protocol and state-machine messages have
> > > > > > been decoupled from the transport session.
> > > > > >
> > > > > > I am not sure why you think that subscriptions are unable to
> > > > > > use a common NETCONF session?  Implementations of dynamic
> > > > > > NETCONF subscriptions have been doing this for years.
> > > > > > Subscription multiplexing of configured and dynamic
> > > > > > subscriptions over a common transport is a pre-requisite for solution
> scalability.
> > > > >
> > > > > I don't think muliplexing of configured and dynamic
> > > > > subscriptions over a single session is possible.
> > > > >
> How would a server know that a certain configured receiver is the same as an
> ongoing session?  And as a client, suppose I just opened a session to send one
> request and then I plan to close the sesssion.  I probably don't want notifs on
> this session as well.

This is a valid scenario.  And while a fix for the current solution would be quite easy to do in text (i.e., through defining expectations of client behavior), it is not necessary to force this complexity on the client.  So instead I propose updating the first paragraph of NETCONF-notif, section 6.2 to the following:

"When a configured subscription enters the "valid" state, there is no guarantee a usable NETCONF transport session is currently in place with each associated receiver.     As a result, the first configured subscription to a specific receiver MUST establish a NETCONF transport session via NETCONF call home [RFC8071] , section 4.1.  This transport session MUST then be used by additional configured subscriptions targeting that the same receiver.   This same receiver is identifiable on the publisher as one which targets the same address and port used to establish the existing NETCONF call home connection. This transport session MAY also be used by dynamic subscriptions and/or non-subscription related NETCONF operations originated by the NETCONF client.

Until a "subscription-started" state change notification is successfully sent for a configured subscription, that subscription's receiver MUST remain in either the "connecting" or the "timeout" state."

> > > > > Again, if this is the intention, it needs to be properly
> > > > > described in the document.
> > > >
> > > If there are two different subscriptions configured, each has its
> > > own list of receivers.  Under which circumstances will the server
> > > decide to use a single transport session for these two different
> subscriptions?
> >
> What if the encoding is different?  

When there really is a different encoding for NETCONF (which is currently not supported in accordance with you earlier comments), we have the option of adding "encoding" to the list of properties which demand a different transport.  However as there are not multiple encodings for NETCONF here, it is easy to ignore for now, especially as an implementation can simply define a different port for the target connection should the receiver really want different encoding someday.  

> What if the users are different?

As you can identify specific ports with different call home, this will cover different users if a receiver can't de-multiplex.  

> Etc.  The point is that maybe there are cases when this can be done, but you
> need to spell this out.

For receiver configuration data right now, we just have receiver "name" which is a string.   There is no need to tell vendors how to do call home configuration as this isn't really in scope.  Solutions here will come soon enough with Kent's draft.

> > During the reviews however, you and Kent have argued away both "port"
> > and "address" from being objects under the receiver.  So vendor
> > specific augmentations will be needed to identify "address"
> > and "port".
> 
> I expect such objects to be added by the transport docs, not by vendors
> (except for vendor-specific transports).

Per the parallel thread with Kent, I fully support augmenting the call home document when it is ready.   

I think what we have now is fine.   Note: we can always re-add "address" and "port" back to SN if enough people want to re-insert explicit receiver identification within the YANG model, and not leave it up to vendors.   But we have already argued this one sufficiently.  I would rather just declare the current solution sufficient.

> > (Unless you are now ok with letting these objects back into the draft,
> > just for the purposes of enable this a common receiver transport
> > session identification.)  The other option is to have a future leafref
> > augmented to ietf-netconf-server.yang as described above.
> 
> >
> > common transport to a single receiver.  The method of identifying that
> > a receiver happens to be the same as used with another subscription is
> > left up to implementers of this specification."
> 
> I don't think this helps.  It means that the client has no way of knowing on
> which sessions to expect notifs.

You are right that it won't be in the YANG file.  But that is the result when you argued "address" and "port" out of receivers.  So for now the configuration is buried in vendor specific call home information.  That information of course can be referenced by vendor specific additions. 

I think it best to leave it as is.   And at some point we will have the ietf-netconf-server.yang model which will allow the vendor specific part go away.

Eric
 
> > > > > design, as well as with the alternative design where the
> > > > > protocol is defined per receiver rather than per subscription.
> > > >
> > > > Likely NETCONF specific concerns would land in the NETCONF-notif.
> > > > I am
> > > happy to make any needed clarifications.
> > >
> > For subscribed-notifications, I have added the sentence to the first paragraph
> of the "configured subscriptions" section:
> >

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Jun 2018 01:46:53 +0000

>> I read the above a few times, but I'm having a hard time understanding it. 
>> Can you say it differently or provide an example?
>
> Dynamic subscriptions over NETCONF requires draft-ietf-netconf-netconf-event-
> notifications.   

Where is the dependency?  I don't see anywhere in the 3 RPCs and associated 
error-info definitions that have a reference to the identity in that draft.

> With these deployments, there there is no call home, there 
> is no configuration, and there need be no ietf-netconf-server.yang leafref (or
> use of ietf-netconf-server.yang grouping).

True.

> My assertion is a good solution would be updating ietf-netconf-server.yang 
> per what is below.  Note that an answer even further below regarding the 
> sharing of a single NETCONF session across multiple subscriptions and typical
> RFC6241 protocol interactions is assumed.  But we could also insert your 
> ietf-netconf-server.yang grouping just as effectively where the leafref is seen.
>
>        "Remote client which need to initiate the NETCONF transport if an existing
> NETCONF session from that client is not available.";
>    }
>  }
>
> With such a construct, it is impossible to add a leafref (or grouping) within
> ietf-subscribed-notifications unless ietf-netconf-server.yang exists.

True, and thanks for providing a concreate example.  Though I thought we concluded
before that there might be cases where the global netconf-server isn't implemented?
Now you're okay making that a requirement?  (I'm okay with that, if it works)

FWIW, I think that an import statement can also assert that a dependent module is
implemented.  For instance, in the below case, the xpath in the leafref forces
that the module is implemented:

  module ietf-netconf-subscribed-notifications {
    prefix nsn;
    import ietf-netconf-server { prefix ncs; }
    import ietf-subscribed-notifications { prefix sn; }
 
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      if-feature "subscription-support";
      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.";
      }
    }
    ...
  }

I prefer this arrangement because it gives tangible meaning for what it means
to *implement* the netconf-subscribed-notifications module.

> elements to a configuration datastore.

At first I was going to point out that, even if using to global netconf server
container, there would still be 500 /netconf-server/call-home/netconf-client
instances, but in looking ahead, I'm wondering if I misunderstand the intended
relationship between transports, subscriptions, and receivers.

If it turns out that receivers from different subscriptions can leafref the 
same /netconf-server/call-home/netconf-client, then the 500 becomes 1, and 
the duplicate data-entry concern goes away.

>> state-machine and protocol messages.  There is no sharing; no two receivers can

As mentioned above, I'm wondering if I misunderstand the intended relationship
between transports, subscriptions, receivers, and maybe publishers too.  Can
you put together a diagram that describes these relationships?

> I am not sure why you think that subscriptions are unable to use a common
> NETCONF session?   Implementations of dynamic NETCONF subscriptions have
> been doing this for years.    Subscription multiplexing of configured and
> dynamic subscriptions over a common transport is a pre-requisite for
> solution scalability.

I think because its underspecified in the SN draft, and there was confusion
with the address and port leafs, and ietf-netconf-subscribed-notifications
only defines an identity (no configuration data model).

>> >> <snip/>
>> > In any case my proposal was to support transport per receiver.   The WG
>> > voted very clearly to use a common transport at and after IETF 101.  The
>> > WG document was changed accordingly.  I consider this issue closed.
>> 
>> You didn't answer the question, which is essentially what benefit having a
>> single protocol provides?   Looking at the thread, I see Martin asked a
>> similar question which was never answered either.
>
> <mangled url snipped/>
> <mangled url snipped/>

Okay, the answer is that its considered "simpler" to use a single kind
(not instance) of transport.  So, the outcome is, if one receiver of a 
subscription is using a NETCONF-based transport, then all the other 
receivers of that subscription MUST also be using a NETCONF-based 
transport, albeit a different instance of a NETCONF-based transport 
(as it would be redundant otherwise).  Correct?

Assuming this is the case, my question is, why is this "simpler"?  I mean,
assuming an event occurs that a subscription matches, the publisher will
encode a notification message to send, and then iterate over its list of
receivers, sending the same encoded-message to each.  But why is it less
simple if different transports (netconf, restconf, etc.) are used?

BTW, separately, I kind of but not really understand why there is a desire
for the fixed encoding for all the receivers in a subscription.  I understand
the efficiency angle (see prev paragraph), but I get stuck on the idea that,
if there is a *need* to send a different encoding (e.g., "encode-json"),
another encoded message structure is going to have to be created anyway; it
seems like the same number of instructions from that perspective.  Then it
goes to looping over one-subscription-tree or one-tree-per-encoding.  Okay,
then, what makes it better?  The only thing I can come up with is that it
might be difficult otherwise to express in YANG what encoding is being used
for that receiver.  For instances, if there is a leafref to /restconf-server\
/call-home/restconf-client, nowhere is there an "encoding" field.  Hmmm, 
maybe the encodings a restconf server supports could be specified at a 
higher level (e.g., /restconf-server/encodings/...), and then it would be
known, on a per-receiver basis, what encoding is used (netconf is always
xml, restconf is per configuration).  Anyway, I'm just wondering if this
is why the encoding for all the receivers in a subscription must be the
same, or is it something else?

>> hoping this isn't the primary motivation for the SN model supporting multiple

Okay.

>> logic.  Is this what you meant by single-live HA?

Okay.

> That is true.  If you wish to champion this alternate proposal, please call

In this particular fork in the thread, I think that we're discussing the merits
if leafref-ing vs using a grouping.  If it is the case that the same transport
can be used across subscriptions, then 1) it swings things back to leafref 
approach being needed and 2) this fork in the thread is done.  [Assuming that
it’s a leafref, we still need to finalize if it's a leafref to the global
server instance or some SN-specific instance.]

> Per above, the decision was made in the room at IETF 100 per the recording
> and minutes above.  And the subsequent email debate.  There was lots of
> healthy debate.

What I know is that this was before the LC, back when these drafts were 
pretty difficult to understand and details about how to configure the
transports were missing.

Regardless, to the question about how it is a "good" thing (what this fork
in the thread is about), I determine above that the WG wanted "simpler".

>> >> There is a difference between a server not *implementing* a ietf-*conf-
>> >> server module and the *conf-notif not *using* the *conf-server-grouping
>> >> statements.  My suggestion has been, that the *conf-notif drafts should
>> >> have their own lists of netconf-servers (via "uses" statements), and
>> >> thereby not be dependent on the existence of a global ietf-*conf-server
>> >> instance (which may not exist).
>> >
> This is still an issue, as the drafts in WGLC support a single NETCONF session
> for all subscriptions and normal protocol operations.

As said before, sharing the same transport across subscriptions wasn't clear
to me before.  Still, even as 500 becomes 1, there remains the discussion if
it's the one is the global server instance or some SN-specific server instance.

>> > *conf-server.  Explaining that a model is only available for its 
>> > grouping would be quite a confusing deviation.
>> 
>> No, it's easy, this is the difference between a module being *implemented*
>> or not.  The implementation status of each module is yang-library.
>

Not just possible, it is actually how it happens.  The client-server modules
are highly sensitive to implementation status.  FWIW, I never expect the
ietf-*conf-client modules to ever be implemented, and the ietf-*conf-server
modules to be implemented "sometimes".  FWIW, the global server instances
we keep talking about only happen *if* the ietf-*conf-server modules are
implemented.   

>> > which can be performed after *conf-server progresses.  Therefore, no
>> > matter the disposition, there is need be no impact to SN at this time.
>> 

Okay.

> <big snip/>

Yes, take out the address leaf but I think that, if we want to progress the
SN draft along with a transport binding definition that doesn't depend on
the ietf-*conf-server modules, then we might define something else like:

  module ietf-netconf-no-crypto-subscribed-notifications {
    prefix nncsn;
    import ietf-subscribed-notifications { prefix sn; }

    container implicit-netconf-receivers {
      list implicit-netconf-receiver {
        key name;
        leaf name { ... }
        leaf address { ... }
        leaf port { ... }
      }
    }
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      if-feature "subscription-support";
      when 'derived-from(../../../transport, "nsn:netconf")';   
      leaf netconf-endpoint {
        type leafref {
          path "/nncsn:implicit-netconf-receivers/nnccs:implicit-netconf-"
               + "receiver/nnccs:name";
        }
      }
    }
    ...
  }

I don't quite understand how the server is supposed to know how to configure
the call-home parameters or the transport parameters, but at least this
would be on par with what you had before.

>> <big snip/> 

From above, and I can't ascertain why this is, when dynamic subscriptions don't
appear to utilize the "netconf" identity in any way...

> An update to NETCONF-notif for configured subscriptions is possible to insert
> the call-home leafref (or insert new grouping).   But this update becomes 
> unnecessary if ietf-netconf-server.yang is augmented as described above.

Perhaps, but it seems unnatural to do it this way.  What makes sense to me is 
for the module that claims to be the transport-binding module to provide the
configuration for binding the transport.

>> >> <create-subscription>, after which the <notifications> begin to flow.  Is 
>> >> this the same here, or are you expecting the <notification> messages to start
>> >> flowing immediately?
>> >

Eric, you are the Editor.  But beware, this could blow up and we decide to
drop the netconf and restconf protocols bindings entirely and only focus 
on transport bindings for things like gRPC and udp-pub-channel.  If NC/RC
are needed, then the server could configure a standard call-home connection
(via the ietf-*conf-server modules) from which the client can issue a start
a dynamic subscription.  Just thinking this might be a better win.

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 27 Jun 2018 03:31:00 +0000

Martin, 
one question specifically to you below. (search for **Martin)

Kent, 
in line...

> From: Kent Watsen, June 26, 2018 9:47 PM
> 

The dependency is a document requirements dependency: deployment of NETCONF based dynamic subscriptions requires support of both relevant requirements sections 5, 7, & 8 from draft-ietf-netconf-netconf-event-notifications in addition to draft-ietf-netconf-subscribed-notifications.  

> Now you're okay making that a requirement?  (I'm okay with that, if it works)

I am ok with making it a requirement for drafts subsequent to the current draft-ietf-netconf-netconf-event-notifications.   Either a revision to draft-ietf-netconf-netconf-event-notifications, or an update to the ietf-netconf-server.yang.

> to *implement* the netconf-subscribed-notifications module.

I understand.  As long as we make the choice as to where to land this future leafref after the current draft-ietf-netconf-subscribed-notifications completes, I am good.

> the duplicate data-entry concern goes away.

Exactly.  This has always been the objective.

> > This is incorrect.    Protocol and state-machine messages have been
> decoupled
> > from the transport session.
> 

A configured subscription on a publisher can have many receivers.

A configured subscription on a publisher may only use one type of transport (and one type of encoding).

A configured receiver can receive information from multiple configured subscriptions on a single transport session from a publisher.

> only defines an identity (no configuration data model).

In a parallel thread to Martin, I have added a sentence aimed here.   Beyond that, configuration data model forces choice of the identity for the configured subscription.

Yes
 
> simple if different transports (netconf, restconf, etc.) are used?

As can be heard in the recording, and seen on dozens of WG emails, these issues were deeply debated.  As can been seen my slight preference actually was different transports.  And that is how earlier versions of the model covered the issue.  However the WG chose a single transport for rational reasons at and after IETF 100.  The issue was closed and the drafts updated accordingly.  
 
> then, what makes it better? 

Some implementations have claimed it is easy to bind the subscription with the encoding, and difficult to perform filtering before the encoding.  So it is better to force this separation.

> The only thing I can come up with is that it

I believe leafref is good.  And as long as the leafref is inserted after the current drafts in WGLC complete, I am good.

> it's the one is the global server instance or some SN-specific server instance.

Same comment as above.

> we keep talking about only happen *if* the ietf-*conf-server modules are

I have seen implementations of YANG models without having a yang-library.   I prefer a yang-library of course.

>           path "/nncsn:implicit-netconf-receivers/nnccs:implicit-netconf-"

**Martin, are you ok with this.   If you are and there are no other objections, I will add this and we can be done with this thread.  Which would be progress.   Otherwise, let's just leave things as they are.

BTW: adding back address and port also solves the "how do we have a common transport across multiple configured receivers".

> would be on par with what you had before.

Yes.

> *implemented*, and

No, but non-YANG  Sections 5, 7, & 8 is needed.  Plus many of the examples.

> configuration for binding the transport.

At this point we do have a relatively minor difference of option which need not impact the closing the current draft-ietf-netconf-netconf-event-notifications.

> >> > Can you point to something in RFC 6241 which says a <notification> can't
> be
> >> sent

Things are far easier with HTTP based transports, because you must get an explicit OK from a subscription-started before sending any <notification>.  See RESTCONF-notif for configured subscriptions which used no RESTCONF at all for this function.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 28 Jun 2018 22:13:12 +0000

> The dependency is a document requirements dependency: deployment of NETCONF
> based dynamic subscriptions requires support of both relevant requirements
> sections 5, 7, & 8 from draft-ietf-netconf-netconf-event-notifications in
> addition to draft-ietf-netconf-subscribed-notifications.  

Sure, I get this, but we're talking about if there is YANG-level dependency,
for which I believe we've concluded that the answer is "no".

What this means is, for servers that only want to support NETCONF-based 
dynamic subscriptions (no configured subscriptions), then the 
ietf-netconf-subscribed-notifications module can be listed in yang-library
as *not implemented*.  And for servers that want to support NETCONF-based 
configured subscriptions, then ietf-netconf-subscribed-notifications can
be listed in yang-library as *implemented*.

Looking at the thread that led up to this point, this means that it would
be okay for ietf-netconf-subscribed-notifications to have a leafref to a
global /netconf-server/call-home/netconf-client, while not forcing the
implementation of the ietf-netconf-server module, for servers that only
want to support dynamic subscriptions.

And, to the question that started this fork in the thread "is it possible
that a device wants to use SN but doesn't *implement* ietf-netconf-server",
the answer is "yes".

> I am ok with making it a requirement for drafts

Okay, assuming we resolve the "I'm not entirely sure if I understand if
what is planned is legal" issue discussed below.

> ...subsequent to the current draft-ietf-netconf-netconf-event-notifications.

This is TBD, per the discussion below, but we can try...

>   Either a revision to draft-ietf-netconf-netconf-event-notifications, or
> an update to the ietf-netconf-server.yang.

Right.   But if the dependency only goes one way, then I think the choice
is made for us already. 

> I understand.  As long as we make the choice as to where to land this future
> leafref after the current draft-ietf-netconf-subscribed-notifications completes,
> I am good.

Pending the discussion below...

> Exactly.  This has always been the objective.

Okay.  Sorry for being slow to get this.  Please take a close look at SN draft
to ensure this is super clear there.

> A configured receiver can receive information from multiple configured subscriptions on a single transport session from a publisher.

I'd like to have statements like these in the SN draft.  Maybe as part 
of the term definitions, but that might be too much information (busy)
for terms. The info could be sprinkled throughout the doc, but I wonder
if that might not already be the case and, if so, then it didn't work
out too well before (witness my confusion here), so perhaps some other 
section would be better?

> In a parallel thread to Martin, I have added a sentence aimed here.   Beyond
> that, configuration data model forces choice of the identity for the configured
> subscription.

In that thread, you wrote:

"""

"""

This is a good sentence (assuming the discussion regarding *why* this is simpler pans out),
but shouldn't it be in the SN document (not netconf-notif)?

> As can be heard in the recording, and seen on dozens of WG emails, these
> issues were deeply debated.  As can been seen my slight preference actually
> was different transports.  And that is how earlier versions of the model
> covered the issue.  However the WG chose a single transport for rational
> reasons at and after IETF 100.  The issue was closed and the drafts
> updated accordingly.  
 
Eric, I'm asking for a technical answer.  In a nutshell, what are
the "rational reasons"?   Yes, I recall your having a preference for
heterogeneous transports...

> Some implementations have claimed it is easy to bind the subscription with
> the encoding, and difficult to perform filtering before the encoding.  So
> it is better to force this separation.

Okay.  (but see next paragraph).

>> same, or is it something else?

I just sent a question to the WG regarding if ietf-restconf-server should
have a way configure which encodings it supports.  If this pans out, the
impact here is that we might want a "must" statement to ensure that the
selected encoding is supported by the leafref-ed /rcs:restconf-server/
instance.

> I believe leafref is good.  And as long as the leafref is inserted after
> the current drafts in WGLC complete, I am good.

Yes, leafref seems needed.  Whether the leafref is global vs. local, and to what
the leafref points to, are still TBD.

>> the one is the global server instance or some SN-specific server instance.
>
>Same comment as above.

Which is that you're okay with the *conf-notif drafts necessitating the existence
of /*conf-server/ instances (i.e., the ietf-*conf-server module is implemented)
and, of course, you're hoping that this dependency can be introduced in some
future bis version of the *conf-notif drafts.

> I prefer a yang-library of course.

From a SDO perspective, yang-library is expected to be implemented (it's a
MUST in RFC 8040 and in nmda-restconf).  We should fully assume that the
server implements yang-library.  That said, if I were the implementer of
a receiver that does a dynamic subscription, I would probably write the
code to just send the establish-subscription request and check to see 
if the server returned an <rpc-error>, without first checking if the
module is listed in yang-library...

> **Martin, are you ok with this.   If you are and there are no other 
> objections, I will add this and we can be done with this thread.  Which
> would be progress.   Otherwise, let's just leave things as they are.
>
> BTW: adding back address and port also solves the "how do we have a
> common transport across multiple configured receivers".

Look at the YANG again, it first defines protocol accessible nodes for
"receivers" (i.e., distinct transports), and then it augments in a
leafref to an instance in that list.  I think this is more explicit
than rules around matching address and port values.

>> I don't quite understand how the server is supposed to know how to
>> configure the call-home parameters or the transport parameters, but
>> at least this would be on par with what you had before.
>
> Yes.

If we do it, the *conf-notif draft would have to explain such details
in text, since they'd be missing from the YANG module...

>> From above, and I can't ascertain why this is, when dynamic subscriptions
>> don't appear to utilize the "netconf" identity in any way...
>

From above, it seems that we can key everything off if the *conf-notif 
module listing in yang-library is implemented.

For servers that only support NETCONF-based dynamic subscriptions (no 
configured subscriptions), then the ietf-netconf-subscribed-notifications
module can be listed in yang-library as *not implemented*.  

For servers that only support NETCONF-based configured subscriptions, 
then ietf-netconf-subscribed-notifications can be listed in yang-library
as *implemented*.

Good?

> At this point we do have a relatively minor difference of option which need
> not impact the closing the current draft-ietf-netconf-netconf-event-notifications.

I assume you meant "opinion", and I agree that it's relatively minor, but I think
that you meant that it doesn't impact the closing of the SN draft, as it certainly
impacts the closing of the notif drafts, right?

>>> >> >> That said, I have to say that I'm not entirely sure if I understand
>>> >> >> if what is planned is legal.  For instance, in a normal NETCONF call
>>> >> >> -home situation, the NETCONF session begins with both sides sending
>>> >> >> <hello> messages and then the server waiting for the client to send
>>> >> >> RPCs, which might include a 5277 <create-subscription>, after which
>>> >> >> the <notifications> begin to flow.  Is this the same here, or are 
>>> >> >> you expecting the <notification> messages to start flowing 
>>> >> >> immediately?
>> >> >
>> >> > A subscription-started notification will be sent after the hellos are
>> >> > successful.  Can you point to something in RFC 6241 which says a 
>> >> > <notification> can't be sent until an RPC is sent from the client?
>> >>
>> >> We should ask the WG.  All I know is that it's always been that the
>> >> client does something to initiate server behavior.  Admittedly, this
>> >> is kind of a new thing, and it might be okay, but I think it warrants
>> >> review by others.
>> >
>> (via the ietf-*conf-server modules) on which the client can start a dynamic
>> subscription.  Just thinking this might be a better win.
>
> Things are far easier with HTTP based transports, because you must get an
> explicit OK from a subscription-started before sending any <notification>.
> See RESTCONF-notif for configured subscriptions which used no RESTCONF at
> all for this function.

I'm unsure if I understand this.  Can you explain how/why this is so?

Also, going forwards, please try call out sections when you can.  It took
me awhile (too long) to see that you meant (I think) section 4.2.

BTW, in one possible outcome of the current discussions in play, is that
there may be a multiplicity of "notif" modules, such as:

  ieft-netconf-notif
  ieft-netconf-wo-crypto-notif  // better name needed
  ieft-restconf-notif
  ieft-restconf-wo-crypto-notif // better name needed
  ietf-https-notif              // unsure about this one
  ietf-grpc-notif
  ietf-udp-notif
  etc.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Jun 2018 10:10:57 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> as *not implemented*.

No, since the server must implement the rpcs, the module must be
listed as "implemented" (the feature "configured" would not be
advertised though).

/martin

> And for servers that want to support NETCONF-based

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Jun 2018 10:33:56 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > > > > > >  augment
> > > > > > >  "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"
> > {
> > an
> > as an
> This is a valid scenario.  And while a fix for the current solution
> would be quite easy to do in text (i.e., through defining expectations
> of client behavior), it is not necessary to force this complexity on
> the client.  So instead I propose updating the first paragraph of
> NETCONF-notif, section 6.2 to the following:
> 
> "When a configured subscription enters the "valid" state, there is no
> guarantee a usable NETCONF transport session is currently in place
> with each associated receiver.  As a result, the first configured
> subscription to a specific receiver MUST establish a NETCONF transport
> session via NETCONF call home [RFC8071] , section 4.1.  This transport
> session MUST then be used by additional configured subscriptions
> targeting that the same receiver.  This same receiver is identifiable
> on the publisher as one which targets the same address and port used
> to establish the existing NETCONF call home connection.

This is not enough / correct.  You also need to take the user name
into account.

> This transport
> session MAY also be used by dynamic subscriptions and/or
> non-subscription related NETCONF operations originated by the NETCONF
> client.
> 
> Until a "subscription-started" state change notification is
> successfully sent for a configured subscription, that subscription's
> receiver MUST remain in either the "connecting" or the "timeout"
> state."
> 
> When there really is a different encoding for NETCONF (which is
> currently not supported in accordance with you earlier comments), we
> have the option of adding "encoding" to the list of properties which
> demand a different transport.  However as there are not multiple
> encodings for NETCONF here, it is easy to ignore for now, especially
> as an implementation can simply define a different port for the target
> connection should the receiver really want different encoding someday.
> 
> As you can identify specific ports with different call home, this will
> cover different users if a receiver can't de-multiplex.

The solution must be robust enough to correctly handle all cases that
it allows to be confgigured.

Anyway, if this whole issue is handled in the transport documents, I
am happy.  Some transports will likely support this, and some will
not.

> For receiver configuration data right now, we just have receiver
> "name" which is a string.  There is no need to tell vendors how to do
> call home configuration as this isn't really in scope.  Solutions here
> will come soon enough with Kent's draft.
> 
> I think what we have now is fine.  Note: we can always re-add
> "address" and "port" back to SN if enough people want to re-insert
> explicit receiver identification within the YANG model

No!  That would be a big mistake, since address and port are not
enough for receiver identification.  Hopefully you agree by now.

> , and not leave
> it up to vendors.  But we have already argued this one sufficiently.
> I would rather just declare the current solution sufficient.
> 
> You are right that it won't be in the YANG file.  But that is the
> result when you argued "address" and "port" out of receivers.

See above.

/martin

> So for
> now the configuration is buried in vendor specific call home
> information.  That information of course can be referenced by vendor
> specific additions.
> 
> I think it best to leave it as is.  And at some point we will have the
> ietf-netconf-server.yang model which will allow the vendor specific
> part go away.
> 
> Eric
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Jun 2018 11:05:56 +0200 (CEST)

Hi,

> one question specifically to you below. (search for **Martin)

See inline

> > From: Kent Watsen, June 26, 2018 9:47 PM

[...]

> **objections, I will add this and we can be done with this thread.
> **Which would be progress.  Otherwise, let's just leave things as they
> **are.

No, but it might be that I don't really understand what you propose.

What is "NETCONF no crypto"?  Comparing with "ietf-netconf-server"
model, you don't have the "server-identity".  How can this be secure?

Is the reason for this to avoid a dependency to
"draft-ietf-netconf-netconf-client-server" from
"draft-ietf-netconf-netconf-event-notifications"?

I would rather keep this dependency and ensure the WG finishes the
client-server model.  (This work was adopted by the WG in 2014 which
is even earlier than the notif drafts...)

> > configure
> > >> yet subscriptions still need to be configured

I think it is ok to require an implementation of configured
subscriptions that use the standard "nsn:netconf" transport to also
implement the ietf-netconf-server module.  If a vendor doesn't want
this, it can define another transport identity.

/martin

> > >> leafref-
> > ing
> > >> *netconf-notif
> > draft
> > >> is implemented, its own definition comes into play.  When done this
> > >> way,
> > the
> > >> flag would no longer be needed since the entire netconf-server
> > >> instance
> > would
> > >> be SN-specific.
> > >
> > > insert
> At this point we do have a relatively minor difference of option which
> need not impact the closing the current
> draft-ietf-netconf-netconf-event-notifications.
> 
> > >> >> planned is legal.  For instance, in a normal NETCONF call-home
> > >> >> situation,
> > the
> > >> >> this the same here, or are you expecting the <notification> messages
> > >> >> to
> > start
> > >> >> flowing immediately?
> > >> >
> > >> > can't
> > >> client
> > does
> > >> something to initiate server behavior.  Admittedly, this is kind of a
> > >> new
> > thing,
> Things are far easier with HTTP based transports, because you must get
> an explicit OK from a subscription-started before sending any
> <notification>.  See RESTCONF-notif for configured subscriptions which
> used no RESTCONF at all for this function.
> 
> Eric
> 
> > > Eric
> > 
> > Kent // contributor
> > 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Jun 2018 11:09:16 +0200 (CEST)

> This is not enough / correct.  You also need to take the user name

Sorry, you're right, this is correct for the NETCONF case.

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 29 Jun 2018 13:58:56 +0000

> listed as "implemented" (the feature "configured" would not be

The rpcs are in ietf-subscribed-notifications, from the SN draft.  

* For servers that only support dynamic subscriptions:

  - ietf-subscribed-notifications:
      - implemented, but "configured" feature not supported

  - ietf-netconf-subscribed-notifications:
      - listed in yang-library as not implemented

* For servers that support both, both modules are implemented, and
  the "configured" feature is supported.

* For servers that only support configured subscriptions.  
  If this pans out, then I assume:

  - ietf-subscribed-notifications:
      - implemented, but "dynamic" feature not supported
        (note: this entails adding new feature "dynamic")

  - ietf-netconf-subscribed-notifications:
      - implemented

> /martin

Kent