Re: [netconf] SN and indirection

Martin Bjorklund <> Fri, 30 August 2019 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EADB71209A5 for <>; Fri, 30 Aug 2019 08:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PYxEKysD6onF for <>; Fri, 30 Aug 2019 08:03:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 57FED1208C6 for <>; Fri, 30 Aug 2019 08:03:44 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id 4AFCC1AE0187; Fri, 30 Aug 2019 17:03:42 +0200 (CEST)
Date: Fri, 30 Aug 2019 17:03:42 +0200
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
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 15:03:54 -0000

Kent Watsen <> wrote:
> >>> (*) 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.
> Excellent.
> 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?

I didn't mean as a pre-condition, but if the WG thinks it can be done
I'm all for it.

> 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

I agree.

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

If we don't have a generic indirection, I would like the current
https-notif solution better if it didn't put 'receivers' at the
top-level, but instead augmented it into '/sn:subscribers', and
renamed it to 'https-receivers'.  Further, the 'receiver-ref' should
probably be called 'https-receiver-ref' or something.

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

I watched the session on youtube, but I must admit that I don't
understand the problem.  Is there a description of the problem
somewhere?  If not, this belongs to a separate thread.