Re: [icnrg] FLIC and error reporting

[Marc Mosko <[e-mail]>]

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" <[e-mail] on behalf of mail=2Bietf=[e-mail]> wrote:

    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: [phone] - 8426
    Mail: [e-mail]
    Web: https://www.inet.haw-hamburg.de/