Re: [Netconf] a joint discussion on dynamic subscription

Martin Bjorklund <mbj@tail-f.com> Thu, 14 June 2018 13:38 UTC

Return-Path: <mbj@tail-f.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 AB207130E21 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 06:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nGr_wkG4nrTY for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 06:38:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22299130E1D for <netconf@ietf.org>; Thu, 14 Jun 2018 06:38:26 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 34ABD1AE01AA; Thu, 14 Jun 2018 15:38:25 +0200 (CEST)
Date: Thu, 14 Jun 2018 15:38:24 +0200 (CEST)
Message-Id: <20180614.153824.1029993696264171685.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180614095701.74rqetmhark3tzpd@anna.jacobs.jacobs-university.de>
References: <20180614.091828.21142123428745204.mbj@tail-f.com> <20180614.103746.8291316293283106.mbj@tail-f.com> <20180614095701.74rqetmhark3tzpd@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/t8r3ZtWQAvfB-yNzQrgwASAYCXk>
Subject: Re: [Netconf] a joint discussion on dynamic subscription
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: Thu, 14 Jun 2018 13:38:28 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, Jun 14, 2018 at 10:37:46AM +0200, Martin Bjorklund wrote:
> > 
> > Also, I think it would be useful to draw a picture that demonstrates
> > the roles:
> > 
> >       subscriber/client    receiver
> >           |                   ^
> >           | (1)               | (3)
> >           |                   |
> >           |                   |
> >           v        (2)        |
> >         server  ----------> publisher
> > 
> > (1) is creation of the subscriptionE; dynamic or configured
> > (2) is implementation specific
> > (3) is the delivery of notifications / event records
> > 
> > NOTE: the subscriber and receiver MAY be the same entity
> > NOTE: for some transports, if (1) is dynamic, (3) is sent over the
> >       same session as (1)
> > NOTE: for some transports, the sevrer and publisher are the same entity
> 
> So why do we need the distinct role of a publisher?
> 
> > If we can agree on an architectural picture like this, the different
> > transport docs can refer to this architecture and be defined related
> > to it.   For example, the netconf transport doc can state that the
> > publisher is always the same entity etc.
> 
> So we introduce the role of a publisher because of some transports
> that do have a server?

I assume you mean "do not".  Yes, that's my understanding.  But I
might be wrong.  Eric and Alex?

> If the publisher is truely distinct entity from
> the server (and the state it has), we may get interesting security
> considerations to write.

Isn't this what the UDP transport does?  It uses a NETCONF/RESTCONF
server to set up the subscription, then UDP to send the notifications.


/martin