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

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 25 June 2018 21:27 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722C130E4C for <netconf@ietfa.amsl.com>; Mon, 25 Jun 2018 14:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP1aRQe8LYhQ for <netconf@ietfa.amsl.com>; Mon, 25 Jun 2018 14:27:23 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186E9130DF1 for <netconf@ietf.org>; Mon, 25 Jun 2018 14:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32466; q=dns/txt; s=iport; t=1529962042; x=1531171642; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NvFW43+P1Phdd9iL3tD8crXTnqdVB52SWQMdnprDs3c=; b=d266hkDqO2dqIk/eCMx8Jhi7DmiYo/wRn49XYBaglohbY+PO83AmtnmW WXPuM6RSBshHCWq4CuKQFMng3S5AOxd84AQL34SDfXkVYoObdFvItZvHa UmjCSXbox58g7d91RrhqJ5Eh+i3paRb9SiGr1Q78PbKWJ9F05bcNInxsi I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfAQD0XDFb/5RdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYMqAQEBASFifzKDb5RFggWVChSBZgsnhEUCF4J2ITUXAQIBAQEBAQECbRwMhSgBAQEDARoDBhFFBQsCAQgOBwUCCAEdAgICMBUQAgQBDQ0TgwuBdwgPrCWCHIhHgRMFgQuGMYEwgVY/gQ+Behd+gUGBNSICA4EqARIBBwJQgkeCVQKMR4xoCQKFfIJkhieBSIQGgmqFGYd0gjCHIgIREwGBJB4BNmFxcBU7gmqCIheIWYU+jgGBH4EaAQE
X-IronPort-AV: E=Sophos;i="5.51,271,1526342400"; d="scan'208";a="404810271"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2018 21:27:21 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w5PLRKt8012432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2018 21:27:21 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Jun 2018 17:27:20 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 25 Jun 2018 17:27:20 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yAgABaRoCAAFIXAP//0cbAgCYz3oCAALf2gIALzo6AgACF3OCAAIGQgP//v4TQgAHRv4D//78WkABEsRYAAAapTSAAjo35gAAIQuKQ
Date: Mon, 25 Jun 2018 21:27:20 +0000
Message-ID: <c034b39204074d36abdc9f57a6d7537b@XCH-RTP-013.cisco.com>
References: <0c1b4c46d2de4190af83488dff293181@XCH-RTP-013.cisco.com> <20180518.144414.334141005925835002.mbj@tail-f.com> <fbb940135ccb465eb3f5b95d1fb53721@XCH-RTP-013.cisco.com> <20180518.170823.427077888694872498.mbj@tail-f.com> <595D0676-7DBD-4339-A551-374FBED705EC@juniper.net> <4a1e2f7367d54d088e517f7f6614765a@XCH-RTP-013.cisco.com> <ED90F588-9BCC-49C6-B8FF-18554247BD7F@juniper.net> <0a3b0b0b29e246b98c684d13162e15a8@XCH-RTP-013.cisco.com> <B8385EF7-C565-4F63-90AC-A4B36679B406@juniper.net> <c3b9cd55b30647e582d905320562a0eb@XCH-RTP-013.cisco.com> <CFB4FA41-C614-4604-B869-267533368335@juniper.net> <73ec3c52ffde452cae47642ce5ff2dd2@XCH-RTP-013.cisco.com> <DA6A819A-680E-4524-A5B7-E2E36466FA8D@juniper.net> <cd9b7871b2ce4ad9987b6d782e6bcc3d@XCH-RTP-013.cisco.com> <38D9AA27-DFFE-4BA3-9B9A-F33BD24B9C21@juniper.net> <5682ba83228f41e6b6a04a866b3dc49d@XCH-RTP-013.cisco.com> <2BE57A46-2D39-46D8-B751-203681C23F43@juniper.net>
In-Reply-To: <2BE57A46-2D39-46D8-B751-203681C23F43@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/STAE7uGpvWDhJ-wPK5yqp5L8RmY>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jun 2018 21:27:29 -0000

> From: Kent Watsen, June 25, 2018 3:43 PM
> 
> >> >> <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.
> >>
> >> (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?

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.
> 
> Not in the *conf-server models, the augments go into the *conf-notif models, I
> assume that is what you meant.

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 

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

  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";
     }

 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.";
    }
  }

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

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.

> 
> >> >> <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.
> >> >
> >> > <mangled URL removed>
> >>
> >>
> >> 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?
> >
> > 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.
> 
> 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.

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

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

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

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.

> >> >> <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.
> >>
> >> 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).
> >
> > While technically correct, there are several reasons why this is problematic.
> > (1) redundancy (see the 500 above)
> 
> 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.

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

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

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

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

> 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.
> 
> 
> >> 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 would rather jettison the 'address' object.  This makes for a strong
> separation
> > of interests for call home.
> 
> +1
> 
> 
> >> >> 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.
> >>
> >> 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.
> 
> Agreed.

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


> >> >> <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 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.
> >> >
> >> > 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.
> >>
> >> I like (1) more, as it then ties the existence of the flag to the
> *implementation*
> >> of the corresponding *conf-server module.
> >
> > 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.

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.


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

You are welcome to make the request. 

Eric

> > Eric
> 
> Kent // contributor
> 
> 
> 
> > >> <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.
> > >>
> > >> <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.
> > >>
> > >> <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?
> > >
> > > I don't see any conflict.   In fact it should be a nice benefit of pointing to
> > *conf-server.
> >
> > Great!
> >
> >
> > Kent // contributor
> >
> 
> 
> 
>