Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 15 June 2018 09:43 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 6C57D12F1A2 for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 02:43:09 -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] 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 RhYyTY390UpG for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 02:43:07 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id 746F5126DBF for <netconf@ietf.org>; Fri, 15 Jun 2018 02:43:07 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 80A14223CFAE; Fri, 15 Jun 2018 11:43:06 +0200 (CEST)
Date: Fri, 15 Jun 2018 11:43:06 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: evoit@cisco.com, alexander.clemm@huawei.com, alex@clemm.org, netconf@ietf.org
Message-ID: <20180615094306.g74vryjmxqb43nqf@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, evoit@cisco.com, alexander.clemm@huawei.com, alex@clemm.org, netconf@ietf.org
References: <f6f66d0c0a444f2bb0fc770082450037@XCH-RTP-013.cisco.com> <20180614.203959.786029239464099510.mbj@tail-f.com> <25128264f24c483ab55bd92bb6d70dd7@XCH-RTP-013.cisco.com> <20180615.104929.1328233118054958131.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180615.104929.1328233118054958131.mbj@tail-f.com>
User-Agent: NeoMutt/20180512
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qukvWk6xV-PYHWmplipaV5trMIs>
Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12
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: Fri, 15 Jun 2018 09:43:10 -0000

On Fri, Jun 15, 2018 at 10:49:29AM +0200, Martin Bjorklund wrote:
> 
> Can we first agree on the basic terminology in
> subscribed-notifications?
> 
> First question: are server and publisher potentially different entites
> or not?
> 
> Looking at restconf-notif, it seems to me that the publisher is an
> HTTP2 client, i.e., a different entity than the RESTCONF server.

There is a difference between transport client/server roles and the
NETCONF/RESTCONF client server roles, see the call home work.
 
> Is this correct:
> 
> NETCONF:
>    subscriber is a NETCONF client
>    publisher is a NETCONF server
>    receiver is a NETCONF client
> 
> RESTCONF
> 
>    subscriber is a RESTCONF client
>    (NOTE 1)
>    publisher is a HTTP2 client
>    receiver is a HTTP2 server
> 
> UDP
> 
>    subscriber is a NETCONF/RESTCONF client
>    publisher is a UDP client
>    receiver is a UDP server

I am not sure what UDP client and UDP server really means, perhaps
'UDP sender' and 'UDP receiver' are more appropriate here since there
is not much more than that. That said, I am concerned that such a
plain UDP transport may struggle getting approved by the IESG due to
security and privacy concerns that are taken somewhat seriously by the
IESG (but it also depends a bit on who is on the IESG at the time you
hit it). If it will be necessary to mandate say DTLS in order to get
IESG approval, then you get a more significant client and server role
back at the security layer.

Given that there are a large number of message queue middleware
systems out there, does it really make sense to try to create a
special purpose baby with (compared to the grown ups) rather limited
functionality? Are we not hitting the 'oh there are N different
standards, lets create another one to replace them and at the end we
have N+1' syndrome?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>