IETF Logo Mail Archive

Re: [dtn] DTN URI structure and patterns

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Wed, 10 June 2020 14:14 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
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 746033A08CA for <dtn@ietfa.amsl.com>; Wed, 10 Jun 2020 07:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, 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=jpl.nasa.gov
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 IixYfihYiCvy for <dtn@ietfa.amsl.com>; Wed, 10 Jun 2020 07:14:11 -0700 (PDT)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85E83A08C9 for <dtn@ietf.org>; Wed, 10 Jun 2020 07:14:11 -0700 (PDT)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 05AE8UUH040375; Wed, 10 Jun 2020 07:14:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=RzelDQIXfCmfLpsh/hoqj7PtdCmik3yjXb/BmQRX6R4=; b=jpyvF4hyHDZLv3FrQ4G5+yG3hFF7+3cX0BnfiRAOaFcoQhmgad5FhfJFQvKXx6oea9t4 2ZrckNLJ/7c/hcS8K9nE2RqASYq04KTRE8Q8ncJo225hQcaM1ofhtXr2eTo2B8023awZ qitmALk9XVV10dz+9t0v/GCfGfz8ni9RwdNMmxruZgKZSGTMJML25YhWQ+W+WactAPtk vonggf43ATUpcsFXpRy2Cd+on5rV96fO3S9PvQ/+7wf2hFK9hOXeKAZLNCuEXHxAVRuF WwA5Km3ca7MAjwnm4Zg7EdbgFPZ17ASAkkXVFby1DaqY51QJEh/kG2nZ0p330+l1WNN1 Lw==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa02.jpl.nasa.gov with ESMTP id 31gaasj7c1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 07:14:10 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 05AEE9xp004156 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Wed, 10 Jun 2020 07:14:09 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Wed, 10 Jun 2020 07:14:09 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1979.003; Wed, 10 Jun 2020 07:14:09 -0700
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Brian Sipos <BSipos@rkf-eng.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: DTN URI structure and patterns
Thread-Index: AQHWPqDjYNbtlIxIuEqnQyU2Nk02wKjR4yDw
Date: Wed, 10 Jun 2020 14:14:09 +0000
Message-ID: <71e3c286d9754a83a099e2a96127df6f@jpl.nasa.gov>
References: <CH2PR13MB3575C420FCF4E0F0D60363E79F820@CH2PR13MB3575.namprd13.prod.outlook.com>
In-Reply-To: <CH2PR13MB3575C420FCF4E0F0D60363E79F820@CH2PR13MB3575.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_71e3c286d9754a83a099e2a96127df6fjplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-10_08:2020-06-10, 2020-06-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=906 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006100107
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/rQX4uAbrXYPRQmywV0aOGG-tYOI>
Subject: Re: [dtn] DTN URI structure and patterns
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: Wed, 10 Jun 2020 14:14:14 -0000

Hi, Brian.  I think the intent was to acknowledge that one or more BP EID URI schemes could be defined in the future with scheme-specific part syntax that included wild-carding, but no such scheme definitions have been standardized yet as far as I know.  The definitions of those new schemes would be where we would answer your questions.

Scott

From: dtn <dtn-bounces@ietf.org> On Behalf Of Brian Sipos
Sent: Tuesday, June 9, 2020 2:20 PM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] DTN URI structure and patterns

All,
In RFC4838 [1] there is mention of the potential to "provision for wildcarding some portion of an EID" but none of the DTN-scheme URIs that I've come across or the structure in BPbis [2] really indicate what wildcarding would look like or how it would operate.
Is wildcarding currently in use for DTN-scheme URIs?
What exactly would the wildcard cover; a portion of the "node-name" or "demux" part, or both, or something else?

It's also not clear what the expected "node-name" structure of a DTN-scheme URI is supposed to look like or behave like. I've seen some examples with pseduo-domain-names used for node names, but are these actually structured names or just opaque "1*VHCAR" as [2] indicates?
Are node names "one.net" and "two.net" in any way related? Do existing tools use some relationships like these?

These questions are coming up as a result of looking at what PKIX on a DTN would look like and trying to head off some struggles which have already caused lots of pain in PKIX for DNS names [3].

[1] https://tools.ietf.org/html/rfc4838#section-3.3
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-24#section-10.7
[3] https://tools.ietf.org/html/rfc6125#section-7.2

v2.23.0 | Report a Bug | By Email