Re: [netmod] ?==?utf-8?q? Notifications with state data reference

Michal Vaško <mvasko@cesnet.cz> Thu, 08 March 2018 08:08 UTC

Return-Path: <mvasko@cesnet.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6108126C19 for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 00:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cesnet.cz
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 bZBXxWTYLXqM for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 00:08:46 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0AC1205F0 for <netmod@ietf.org>; Thu, 8 Mar 2018 00:08:45 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id C9400602F0; Thu, 8 Mar 2018 09:08:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1520496522; bh=fAafP+2z8KWnB+vSDiEazXkg2NJCv5bksp/uSf31fc0=; h=In-Reply-To:From:Date:Cc:To:Subject; b=CgmT3JKCL5tHxItcgVZHpH7us8wkFrx4W0dN0KXAdsvSGdf2rcpCxO0ezic6VUcLt QA0B9y1SwG6LhEKCnEr/flc00yt0d7p++gvwI1MxdoKrLhTLZl5XVe2i7SYUD3C59O zw4mr2hf8KtMjRg2wZpeSMP9mCgSB5NpnDNTUVs4=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <20180307142111.ipxa4ux22c3hnbyq@elstar.local>
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
Date: Thu, 08 Mar 2018 09:08:42 +0100
Cc: "netmod" <netmod@ietf.org>
To: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
Message-ID: <15b6-5aa0ef80-9d-46597400@73667296>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/akjOgyMBuOeTIYIF2K5JiW5gJxA>
Subject: Re: [netmod] =?utf-8?b?Pz09P3V0Zi04P3E/ICBOb3RpZmljYXRpb25zIHdpdGgg?= =?utf-8?q?state_data_reference?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 08:08:48 -0000

Hi Juergen,
thanks for an answer. I realized that validation of such notifications could be difficult because of the reasons you mentioned so I was rather questioning the fact that it is allowed to have references to state data in notifications in the first place. Also, I am not sure it is as harmless as it seems.

What if there is a union in the notification that includes instance-identifier, for example. The client receives the notification from a replay and is unable to validate (resolve) this union leaf. In effect, I dare say the leaf (and likely the whole notification) becomes useless for the client as it simply cannot learn what value is actually stored there. Is all this really okay?

Kind regards,
Michal

On Wednesday, March 7, 2018 15:21 CET, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; wrote: 
 
> Dear Michal,
> 
> I think the short answer is that the server replays notifications as
> they were was recorded.
> 
> Operational state is about "in use" values and on many systems it is
> impossible to take a consistent snapshot of operational state and
> hence clients will have little chances to obtain consistent snapshots
> and to do meaningful validation of received notifications. (Clients
> would not only need a consistent snapshot to validate a received
> notification but they would also need a snapshot taken at the time the
> notification was generated.)
> 
> /js
> 
> On Wed, Mar 07, 2018 at 02:58:58PM +0100, Michal Vaško wrote:
> > Hi,
> > in ietf-hardware [1] there are notifications defined that include leafrefs pointing to state data leaves. When the notification is generated, it is validated with regard to the current state data and if successful, the notification is then stored for possible future replay. Now, what happens when a client actually asks for notification replay including this notification? A server is no longer capable of validating it before sending because the state data changed. The same goes for the client, it is unable to validate notifications received from replay. Was this intentional, should the validation be simply skipped in this case?
> > 
> > Thanks,
> > Michal
> > 
> > [1] https://tools.ietf.org/html/draft-ietf-netmod-entity-08#page-29
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> 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/>