Re: [dtn] EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))

Loiseau lucien <loiseau.lucien@gmail.com> Tue, 10 December 2019 02:47 UTC

Return-Path: <loiseau.lucien@gmail.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A5412002F for <dtn@ietfa.amsl.com>; Mon, 9 Dec 2019 18:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5JEtGEmsARVq for <dtn@ietfa.amsl.com>; Mon, 9 Dec 2019 18:47:29 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CF812001A for <dtn@ietf.org>; Mon, 9 Dec 2019 18:47:29 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id r14so7018071qke.13 for <dtn@ietf.org>; Mon, 09 Dec 2019 18:47:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SkTZr3jvUzCNtvxrSG430tN9v+6FTLv8UFEM7OtJStk=; b=As5uY2of5nSOBuVsJnaw9GE4yAy6ZxqjPRSdRCBDOdWDzdtWA0XIdAvrdEvv7JGqiB 2tWS9wD03J8fLT+ogX1P4eHO2nzxkn0f3gwVB4AVk3WlrktKbHrDz8ZbQp0FEXLx5MG8 YXNr0BToDlxpiw0mS0ZzkUw8SgO2m5ZwBqLT6JdXPQSoA9mfljtrYNOHmWyLX83+hWqh zXS8TL+t7XUkt0UHmro7AOG68QuKNJnF5PwxjX7ps4Y2WDYHN00NgXooGYlvIZKgKkXS vGFk5loCOPJQyCN72GdHfIVzt99ye4EzqxkLizWmzTSU9CuCuaNExRDwJqkrXCyAS+np ceag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SkTZr3jvUzCNtvxrSG430tN9v+6FTLv8UFEM7OtJStk=; b=GbYUAsWsRhmwd+uVYAPMuCAt9DcXFpAE0iEeLc4XmaK2Ce9v93ZfigTLJXbK+Mna2r 9pb4TM38nLfPosiArsqpPqYlwQ24ff6rJQTptLiUCpNcZID1o1p3aHJPzHiKNI3vvjrT Rq4A3GgfQ3Sye/+gS6Za8fwXRbnBL1NA6EnSCu4vSBjMcfAhVbr6MoXO8u58mOmGMXSS L/WzMBP6cTsHbaKbSG3VfTyhRD+tc7yy4KNctb7LkMOTaOkYlexDp0zkya6oyQ6oN9iQ /sYmX7IMIu06+PDPugAjoPVJZX7ykWSO524P+8NoXhNPgBxkfrfQKy/v0Jz14oQMb8jx y7Xg==
X-Gm-Message-State: APjAAAWfr6QASeLQZSTCNoExV23ussfwd3IVZI0JWkKawyDqOaV1AI0x vbbRXfWJF6n5RWNBwazoNFUHwlBkm9LgFncj5j4=
X-Google-Smtp-Source: APXvYqxN69j7FQEsc1QMotsZ3ElR193MjZqzbXhE+D4ckftRmNNK7iAx7wRGG8M9wPfw9c5yziG0O7owKUWwB/v+7sY=
X-Received: by 2002:ae9:e306:: with SMTP id v6mr30545859qkf.162.1575946048209; Mon, 09 Dec 2019 18:47:28 -0800 (PST)
MIME-Version: 1.0
References: <7B25D10D-6849-49A4-97A4-D91A84ECAA9E@nasa.gov>
In-Reply-To: <7B25D10D-6849-49A4-97A4-D91A84ECAA9E@nasa.gov>
From: Loiseau lucien <loiseau.lucien@gmail.com>
Date: Tue, 10 Dec 2019 10:47:17 +0800
Message-ID: <CANoKrvbWr7ANmCVfO0yboeAUYjddP6rt7-Up6BDt6C0zM30-Kg@mail.gmail.com>
To: "Clark, Gilbert J. (GRC-LCN0)" <gilbert.j.clark@nasa.gov>
Cc: Brian Sipos <BSipos@rkf-eng.com>, "dtn@ietf.org" <dtn@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006386f3059950880a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/BPtXxFFqxiTIb3vB6wYDHm7dg9Q>
Subject: Re: [dtn] EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 02:47:31 -0000

Hi,

I agree that this may be beneficial for device with strong computing
limitation. Still the RFC doesn't say how to deal with a scheme that has no
encoding definition. Assuming that because this node doesn't know such
definition it should drop this bundle would go against the late binding
principle (maybe this scheme is only relevant once it has reached a certain
region).

If we don't want to have string representation for EID, maybe we could
reserve an IANA number for unknown or experimental EID scheme (say 254). In
that case, encoding of an unknown EID would be the 2-tuples consisting of
cbor integer 254 followed by a cbor text string representation of the
entire EID (scheme included otherwise this information is lost). Node
unwilling to perform string processing would simply drop or forward blindly
this bundle to a more capable node.

What do you think?

On Mon, Dec 9, 2019 at 4:51 PM Clark, Gilbert J. (GRC-LCN0) <
gilbert.j.clark@nasa.gov> wrote:

> Hi,
>
>
>
> Extracting a very small piece of this text for additional conversation and
> transplanting into a new thread here…
>
>
>
> *So we would have to wait for IANA to approve the scheme and then update
> the code in all of bundle node, seems like a lot of unnecessary
> bureaucracy, why not just a string for encoding EIDs?*
>
>
>
> The benefit of encoding this way is that it avoids string processing in
> the general case.  I personally see this as a feature, not a bug.
>
>
>
> Cheers,
>
> Gilbert
>
>
>
> The views expressed in this mail reflect the opinions of the author.  They
> are, therefore, not intended to reflect official positions of NASA or the
> U.S. Government.
>
>
>


--
Lucien Loiseau