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

["Clark, Gilbert J. (GRC-LCN0)" <[e-mail]>]

I don’t have a strong opinion for or against an IANA reservation described below.  If it would be useful, that seems fine.

However, in response to “RFC doesn’t say how to deal with a scheme that has no encoding definition”, my reading of the draft in this instance would go as follows:

Per 5.4, “Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 4.”

In Figure 4, listed under 6.1.1, reason code 5 is listed as “Destination endpoint ID unintelligible.“

As such, in the event that a destination EID is unintelligible (e.g. unknown scheme), my expectation would be that forwarding would be contraindicated and section 5.4.1 would apply.  In the event the scheme for a different EID isn’t understood, then I think it becomes an implementation question … but given that CBOR specifies the length of the field, I do not think it would have a negative impact on bundle decoding in the abstract.  As such, I think the behavior in such a case could be safely addressed as an implementation detail.

I expect someone will correct the above if / as needed, but … this is my interpretation of the current version of the draft.

-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.


From: Loiseau lucien <[e-mail]>
Date: Monday, December 9, 2019 at 9:47 PM
To: "Clark, Gilbert J. (GRC-LCN0)" <[e-mail]>
Cc: Brian Sipos <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: EID encoding (Was: Re: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID))

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) <[e-mail]<mailto:[e-mail]>> 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