Subject: [icnrg] FLIC and error reporting

From: Cenk Gündoğan <[email-masked]>
Date: Tue, 04 Aug 2020 08:59:05 +0200

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: [email-masked]
Web: https://www.inet.haw-hamburg.de/

---

From: Marc Mosko <[email-masked]>
Date: Tue, 4 Aug 2020 07:34:19 +0000

There are two types of errors (at least). One is a TLV structural error.  In those cases, you likely want to discard the object and maybe report it locally, but I would not send more network traffic due to it, apart from maybe re-requesting it.  Another type is some sort of traversal error like you mention.  That falls squarely in application space, I think, and should be handled by whatever error reporting mechanism a publisher has (if any).  I do not think InterestReturn is appropriate (you have an error in data, not interest, anyway).  I would not try to use a network control message to report application logic error.

If a particular application has a secure consumer back channel (not just interests), then there could be a protocol for a consumer to give feedback.  But I do not think plain, unsecured Interests are the way to do it.

Marc

On 8/3/20, 11:59 PM, "icnrg on behalf of Cenk Gündoğan" <[email-masked] on behalf of mail=2Bietf=[email-masked]> wrote:

    Hello,

    Just my 2 cents ..

    Cheers,
    Cenk

    --
    Cenk Gündoğan