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 > > > > > >
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- [Netconf] IETF 101 SN Question 1: Proper designat… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)