[icnrg] FLIC and error reporting

Cenk Gündoğan <mail+ietf@gundogan.net> Tue, 04 August 2020 06:59 UTC

Return-Path: <mail+ietf@gundogan.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D4B3A0F1A for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 23:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.201
X-Spam-Level:
X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=gundogan.net
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 nhpS459xl-AX for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 23:59:08 -0700 (PDT)
Received: from mail.localdomain (trantor.gundogan.net [37.120.167.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40953A0F17 for <icnrg@irtf.org>; Mon, 3 Aug 2020 23:59:08 -0700 (PDT)
Received: from localhost (unknown [149.233.130.143]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id 4523335621 for <icnrg@irtf.org>; Tue, 4 Aug 2020 08:44:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1596523494; bh=kE0izCbSfySYmn5hCV1w7l265I+5MtfL6b3xz/VayZ0=; h=From:To:Subject:Date:From; b=do0+AS6vBEeU9wIMRpG0dUxVuGAZGS7xx1vntYyftYxjPjPP6uiMX3NEaFte8zOUN FMAKaCzy+6jWMVsVBSETU4ouiOMqtoDkr+Ybb3qS5d5hNdUWzKPu4fDsXdLFra+We/ Sdheq/wpfTJXgAwkdOCYqsy6greDBp+Zv8c/aSyWDemr5q7oaYpcU/l4KfDn7ljZDh bSAKrVUQ1ETvpm3Hs3LkdL7gJWi2QBJVpBRVNquv2RrkDV/uxCUoy4PMZlWisZvB4V B0TO1NkUUW6HW8x0dqK3Sy5MvuQ8Ap/uaEwUTXUeZMBsNUMPzKaFaIj0hnA6EacjXW pd1Zj1KKzrvhg==
User-agent: mu4e 1.4.12; emacs 26.3
From: Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?= <mail+ietf@gundogan.net>
To: icnrg@irtf.org
Date: Tue, 04 Aug 2020 08:59:05 +0200
Message-ID: <87y2mu522u.fsf@gundogan.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/xXoCZVruhrF5am2Z7CEjLUl-RLM>
Subject: [icnrg] FLIC and error reporting
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 06:59:10 -0000

Hello,

following yesterday's discussions and rereading the notes [1] and the
-02 draft version, I noticed that there are no references to error
reporting.

Certain operations (like traversing or seeking the tree) may yield
errors (pointer out-of-range [2] -EINVAL, denied access based on an ACL
-EPERM, locked data structure, e.g., during re-publishing or
deduplication -EAGAIN, ...). How does an error that concerns operations
on a manifest tree propagate back to the source?

One way would be to leverage the existing mechanism, which is

1) for CCNx: InterestReturn (with an 8-bit return code),
2) for NDN: AFAIK NDNLP provides the Interest NACK feature [3]

Another way would be to come up with an orthogonal error reporting
feature for manifests only, e.g., by using another PayloadType. The
advantage would be a more fine-grained control over error codes and
corrective actions. The disadvantage .. well, it can get more complex.

FWIW, error handling (in either way) and how it is mapped to CCNx/NDN
could probably be mentioned in the FLIC base draft.

Just my 2 cents ..

On a separate note, I wanted to thank the chairs and the FLIC experts
for yesterday's interim. I liked the format of having a focused and
technical discussion round.

Cheers,
Cenk

[1] https://codimd.ietf.org/icnrg-interim-2020-08-03
[2] https://tools.ietf.org/html/draft-irtf-icnrg-flic-02#section-4.2
[3] https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2#Network-NACK

--
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan@haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/