Re: [dtn] DTN addressing, routing, and ownership

Rick Taylor <rick@tropicalstormsoftware.com> Mon, 13 July 2020 16:32 UTC

Return-Path: <rick@tropicalstormsoftware.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 EA27B3A146A for <dtn@ietfa.amsl.com>; Mon, 13 Jul 2020 09:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 koU9DiFCMQ9g for <dtn@ietfa.amsl.com>; Mon, 13 Jul 2020 09:32:12 -0700 (PDT)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997233A1425 for <dtn@ietf.org>; Mon, 13 Jul 2020 09:32:10 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0487.000; Mon, 13 Jul 2020 17:32:07 +0100
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "Jeremy.Mayer@dlr.de" <Jeremy.Mayer@dlr.de>, "Edward.Birrane@jhuapl.edu" <Edward.Birrane@jhuapl.edu>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: DTN addressing, routing, and ownership
Thread-Index: AQHWTVTx85boqEKc/0KX1l4tcd8Z7ajwYw9ggACsSIuAADE/cIAARK9GgABMkECAAJD44IAAVUhXgAAMdtCAAMyxRIACstXggAg0BAKAAQM/gIABjETAgACM80CAADFSkIADvs7AgAAaEOCAAArhdoAAH3vw
Date: Mon, 13 Jul 2020 16:32:06 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801F585C86C@tss-server1.home.tropicalstormsoftware.com>
References: <MN2PR13MB356748622EBD29B0028737E19F910@MN2PR13MB3567.namprd13.prod.outlook.com>, <095534b510e44eeebe2d02865eafd10d@jpl.nasa.gov> <MN2PR13MB3567754EE9D8D3C7D19DBD259F6F0@MN2PR13MB3567.namprd13.prod.outlook.com>, <631c36b735934d7eb0df5873536b6ee4@jpl.nasa.gov> <MN2PR13MB35671B6724A93836F3F94F2C9F6F0@MN2PR13MB3567.namprd13.prod.outlook.com> <6990ef88820a400f8c3be2c33310c5f6@jpl.nasa.gov>, <38A5475DE83986499AEACD2CFAFC3F9801F585B226@tss-server1.home.tropicalstormsoftware.com> <MN2PR13MB356752E2F1BBB69FDDA274E79F6C0@MN2PR13MB3567.namprd13.prod.outlook.com>, <0e03648eb66849a68193d5a2e1ebcf3e@jpl.nasa.gov> <MN2PR13MB35670F9E35992C2008683B2B9F6D0@MN2PR13MB3567.namprd13.prod.outlook.com>, <d52af6dc5d4b4ec5a1fb9473598ea579@jpl.nasa.gov> <MN2PR13MB3567A58E070E00DCE177002C9F640@MN2PR13MB3567.namprd13.prod.outlook.com> <df0be49bf9124bcdbb8e0e74c510c280@jpl.nasa.gov> <38A5475DE83986499AEACD2CFAFC3F9801F585C2CF@tss-server1.home.tropicalstormsoftware.com> <058a85379305497fa5fadde67b83f9ad@jpl.nasa.gov> <6becf7a7504540c38e6a16c25ec870bd@aplex01.dom1.jhuapl.edu> <38A5475DE83986499AEACD2CFAFC3F9801F585C7D1@tss-server1.home.tropicalstormsoftware.com>, <86815474597745198fbc50366b7e27a3@aplex01.dom1.jhuapl.edu> <54b9f12780ce4e778be3912d7945ae57@dlr.de>
In-Reply-To: <54b9f12780ce4e778be3912d7945ae57@dlr.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2a02:1648:4000:120:849b:b085:a1a8:1136]
Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801F585C86Ctssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/2zjGqgireS8Ged4g0uJeu2qO8wI>
Subject: Re: [dtn] DTN addressing, routing, and ownership
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: Mon, 13 Jul 2020 16:32:14 -0000

Hi Ed,

I'm with Jeremy on this.  HTTP makes a fine CLA as HTTP defines a transport already.   The http:// schema specifies the address *and* the transport.

@Jeremy: would your example be better as http+ipn:[ipn_parts]#[http_resource?query] ?

(One day I will finish my HTTP-REST CLA draft)

Rick

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Jeremy.Mayer@dlr.de
Sent: 13 July 2020 15:48
To: Edward.Birrane@jhuapl.edu; dtn@ietf.org
Subject: Re: [dtn] DTN addressing, routing, and ownership


Ed,

Throwing in my $0.02: I'm not entirely sure that http is a valid scheme from this perspective. I consider http (& webSockets, IMAP, carrier pigeon, etc) to be a "CLA++", where it's actually a last-hop convergence layer scheme.

Therefore, it might be preemptive to start creating "non-DTN-specific" scheme names. Instead, we should strongly consider the use of the oft-forgotten-yet-completely-valid '+' character within the scheme name for these types of use-cases. We can use that character to specify dtn/ipn (which essentially outline the behavior of BP) and the the associated CLA path. If we go this way, some schemes would look like: http+ipn://[http URL]#[ipn URI].



Thanks,

Jeremy

________________________________
From: dtn <dtn-bounces@ietf.org> on behalf of Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
Sent: Monday, July 13, 2020 3:57:29 PM
To: dtn@ietf.org
Subject: Re: [dtn] DTN addressing, routing, and ownership

One other comment on supported EID schemes:

The split between DEST and DST_PORT does indeed formally exist for the ipn EID scheme: node number and service number.  We could do the same sort of thing for the dtn scheme, but the WG has not yet reached consensus on the detailed syntax of dtn-scheme EIDs.  It's not that we haven't recognized this issue, it's that the issue is addressed in the EID schemes rather than in the protocol specification itself.

[EJB]  Looking at section 10.6 I see dtn: and ipn: as defined scheme names. Is there something that breaks if we also allow an http: scheme in this registry? For those simpler cases where late binding is *not* needed then a standard IP is fine, and otherwise a "host name" or loopback can be used for late binding instead.

[EJB] In no way am I suggesting to  not use dtn: or ipn:, but perhaps http: should also be included as a possibility?