Re: [netconf] SN and indirection

Kent Watsen <> Fri, 30 August 2019 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 359621200FD for <>; Fri, 30 Aug 2019 06:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 xCoaUSBZxMlZ for <>; Fri, 30 Aug 2019 06:39:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BD1E1200B3 for <>; Fri, 30 Aug 2019 06:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1567172380; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bMbEYXDTOa4LIsL6i2hXH1FJSwcu3Hr8kDfjJNxVmjk=; b=DFXmalMmMnfVfYpwT8QIy/3ncVZzzFdyS3g5MnJZrJMlt1rAXVDpGZH1MBnRCqZ/ AZFVYH+3B/P8r/Szh30hZ/DlIqDGFwp97mdChDZ0odkkYwgPYCT78HbPHmib4Gy1Wry X9Xh5btn+pDxTMWrwLhEwwtN2gKPWRpHO0mFtNOU=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7144858E-3E59-4D36-B09B-121D50F7E202"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 30 Aug 2019 13:39:39 +0000
In-Reply-To: <>
Cc: "" <>
To: Martin Bjorklund <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.30-
Archived-At: <>
Subject: Re: [netconf] SN and indirection
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Aug 2019 13:39:44 -0000

>>> (*) An observation: This module introduces a level of indirection for
>>> receivers; something we should have done in the
>>> subscribed-notifications model directly.  Perhaps we should revisit
>>> that model and add the indirection there instead.
>> What is meant by “revisit”?  SN is in Auth48.  Pull it back or start a
>> bis now?
> I meant a bis.


Back to the adoption call, do you mean as a pre-condition to defining any configured subscription notif transports and, perhaps, multi-stream originators too?    You wrote "perhaps" above, but in the spirit of pinning a plan down, what does the WG want to do here?

FWIW, there are currently no uses of the static configuration defined in SN, as only dynamic subscriptions are currently supported, so changing the static configuration structure defined in SN now should be relatively easy, that is, easier than doing it later.

My personal opinion is that the indirection introduced in https-notif is likely to be desired by all notif transports for configured subscriptions, but it's unclear to me if the leverage to be had by consolidating the pattern into SN is significantly better than the copy/pasting the pattern into each notif draft, especially when considering that we're not likely to ever have more than a few such notif drafts.  It may be that the only justifiable reason for consolidating the pattern into SN would be to enable some cross notif-transport configuration (i.e., the indirection can span notif transports), but I'm struggling to see how this might manifest, some examples would help.  Separately, patching the SN configuration model to support multi-stream originators is an obvious fix for that problem, but hopefully the design team the chairs proposed in Montreal can devise a clever solution that isn't so obtrusive.