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

"Eric Voit (evoit)" <> Thu, 21 June 2018 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65BFD130E42 for <>; Thu, 21 Jun 2018 09:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G--AzKoJ8No2 for <>; Thu, 21 Jun 2018 09:59:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F3C4130E9C for <>; Thu, 21 Jun 2018 09:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11328; q=dns/txt; s=iport; t=1529600369; x=1530809969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7xvD5PFg1FA6tapWhIoTCXQu4bnM0hNaCBZU2Y6lfMo=; b=XjufJbwYeYZ44lK9MJOxmSfTae4VaoQH1M8JtH1pgLr8qK4Le3Oyw7uK 4HDjy8elw7Z//ACx/y4FoACVsbu+1QwRrtN7mj3saqYwRCV1/jdNJu9As 6z+gL5TvnedGgL7vASjSPmbFIJDkeAxjp0dDbJVeA+hqqo7wVUtrBxnbd s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgDG2Ctb/4sNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNvlESCBZUAgXkLI4QDRgIXgmQhNhYBAgEBAQE?= =?us-ascii?q?BAQJtHAyFKAEBAQECASMRRQULAgEGAg4HBQIJHQICAjAVEAIEAQ0Ngx6Bdwg?= =?us-ascii?q?Pjy+bR4IciEZoBYELhhmBMIFUP4EPghF+gUGBVwIBgT8BAQgtI4JHglUCh02?= =?us-ascii?q?EdYEmiz4JAohfhieNSZE5AhETAYEkJAEwgVJwFTuCZ4IhF4hZhT5vAY1ygR+?= =?us-ascii?q?BGgEB?=
X-IronPort-AV: E=Sophos;i="5.51,252,1526342400"; d="scan'208";a="411519492"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 16:59:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5LGxRLi009982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2018 16:59:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 21 Jun 2018 12:59:26 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 21 Jun 2018 12:59:26 -0400
From: "Eric Voit (evoit)" <>
To: Kent Watsen <>, Martin Bjorklund <>
CC: "" <>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yAgABaRoCAAFIXAP//0cbAgCYz3oCAALf2gIALzo6AgACF3OCAAIGQgP//v4TQgAHRv4D//78WkA==
Date: Thu, 21 Jun 2018 16:59:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jun 2018 16:59:33 -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.

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

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.


> /kw