IETF Logo Mail Archive

[netmod] Notifications with state data reference

Michal Vaško <mvasko@cesnet.cz> Wed, 07 March 2018 13:59 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 7494E1273B1 for <netmod@ietfa.amsl.com>; Wed, 7 Mar 2018 05:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 ZpciDhZIIJcp for <netmod@ietfa.amsl.com>; Wed, 7 Mar 2018 05:59:02 -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 484BB12422F for <netmod@ietf.org>; Wed, 7 Mar 2018 05:59:01 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id ED033602EC; Wed, 7 Mar 2018 14:58:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1520431138; bh=0kgYBMARvUI49q0sY4L/ST90eIT8ZaJDfKdf9TEiUC0=; h=To:Date:Subject:From; b=1l2nIQkTVIfEI1o8BKMhUS5fpvT55oNEwE0AOK9W907zc3plAH3Vwuqbk+STrHYFm COnO70QevFrqkkWHq7Q7EE0YMBmCzONtfzIu1DphMx2xlsz3zH3KNGbwyU1btoXuDT 8xraARCpf+SArhkdyCTJa+l4GVGaSbS8bpH9977o=
Content-Type: text/plain; charset="utf-8"
To: netmod <netmod@ietf.org>
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Wed, 07 Mar 2018 14:58:58 +0100
Message-ID: <3b2-5a9ff000-ef-7e1ee400@19283128>
X-Forward: 147.229.12.224
From: Michal Vaško <mvasko@cesnet.cz>
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SvRGOCubnTGAryj-YArVUPrjp5Y>
Subject: [netmod] Notifications with 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: Wed, 07 Mar 2018 13:59:04 -0000

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

v2.23.0 | Report a Bug | By Email