[DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

Adam Wiethuechter <adam.wiethuechter@axenterprize.com> Wed, 26 June 2024 18:08 UTC

Return-Path: <adam.wiethuechter@axenterprize.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F82C180B5B; Wed, 26 Jun 2024 11:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OazVIsWMb_PD; Wed, 26 Jun 2024 11:08:25 -0700 (PDT)
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2103.outbound.protection.outlook.com [40.107.101.103]) (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 61FE5C180B52; Wed, 26 Jun 2024 11:08:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V1ppxtsJaEXly5/aPMdCXEtLZ7auZlBcEm41rbiJU9WcAEF3mx3y+4Wd6LGUbwVCPRWqytszsTHac0J173PRHrxKxEXn+NNvcn+iAfeZ2OMzibEvSoPPFQwEpJxiOYxxCdW7h/RclRuunlT7GahhxhTxC9gzh4uXjRwRxGHHrIFDRsiKYNmvSfAeYepuXfd5wU1qOvO38xQ0+HVqFOdlZzeNRdrSFAl5+7SjLrdPSfizZgBku53zVwqyeUUsFirIWCczLXIRKaTE8Stq07IQ25XOOlghE8TcokQf2MoXulpTwZu5YEHfTP6cRSBQJUZJeUjb3aSKNU0I0IHWaPfv4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q6hvfsCDOFo1c3C34+oYGMZDh1qhYWgo96aYQI9Ylhg=; b=iipEqiZIBcyE1z4EK5QIvwNg3kYhPph1I8jVtOmSq+bUYBm2habU5SpCqiWTWH93euMF8zWfMKES4yiIz3bjeYE+VlKEdUvMSfx/foqh63E/cSdgr+RWoJ+Iodf+LSqwJlEd7HnwcKkQFLxweXuW1jW/9PnwK0HyaofyOceicLv0gb4PwECbCCNUOL7ZgK9ruX7MYGjXtmLLGVMMTfFguR/wRfgrfRmkBp2owSSvlg9AucxyENLYE7xK6emdrzBC4Z2XDQ1XEcSA5Wz7ZJ7imHt69BRFG/d9RzxWBtgvgSaaM85pUzCrOYOHIkstvLhSdy3qvSFRs5iwYESST52C6A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=axenterprize.com; dmarc=pass action=none header.from=axenterprize.com; dkim=pass header.d=axenterprize.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q6hvfsCDOFo1c3C34+oYGMZDh1qhYWgo96aYQI9Ylhg=; b=OJxa/ftTNDbOWyXfNujbI0yCQyZdx26Ox/6Uf7T3VRmrGegYgEbhhVlUiG2dJyQGb/Yx4DE9viU3paJn6QMeStTnu/NHyPs12/LGU9IItX27/r5XDixlbmZUf2ELPO6O/lMeGT5OsNaCyM8nq/HBEUuBysNLnESgMo3XsTwYKcg=
Received: from SA3PR13MB6515.namprd13.prod.outlook.com (2603:10b6:806:398::14) by IA3PR13MB6980.namprd13.prod.outlook.com (2603:10b6:208:533::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.34; Wed, 26 Jun 2024 18:08:21 +0000
Received: from SA3PR13MB6515.namprd13.prod.outlook.com ([fe80::67ea:c40e:769f:aac2]) by SA3PR13MB6515.namprd13.prod.outlook.com ([fe80::67ea:c40e:769f:aac2%5]) with mapi id 15.20.7698.025; Wed, 26 Jun 2024 18:08:21 +0000
From: Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>, Scott Johnson <scott@spacelypackets.com>
Thread-Topic: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Thread-Index: AQHaxuZWMDG5jdlBAUGASuwCL+BEjbHYbMUAgADRqICAAEScgIAAxukAgAANxbM=
Date: Wed, 26 Jun 2024 18:08:21 +0000
Message-ID: <SA3PR13MB651540D3BA99F0E5AA18FFF188D62@SA3PR13MB6515.namprd13.prod.outlook.com>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <44BBD57B-752B-47FA-B5A5-D4F37BE60E9A@isc.org> <b3f42856-9460-2fa2-1088-185fda441f51@spacelypackets.com> <F2BD591F-8512-4E3E-ABA2-3DF3F34372CB@isc.org> <16835c41-0e6c-bde4-d197-847928171e55@spacelypackets.com> <047a01dac6b8$43d70ca0$cb8525e0$@gmail.com> <57ca71b8-aa29-8a07-5154-e6b9c44bc64a@spacelypackets.com> <AC5B89B2-DD53-4A36-9B87-4136EC288851@isc.org> <2dec1732-841e-dd38-85a8-3263b1c59885@spacelypackets.com> <C363E260-22EA-43E9-97B6-D7A403C205ED@isc.org> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=axenterprize.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA3PR13MB6515:EE_|IA3PR13MB6980:EE_
x-ms-office365-filtering-correlation-id: eecc9eed-ddc7-4bde-225d-08dc960af6a7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230038|366014|1800799022|4022899007|376012|38070700016;
x-microsoft-antispam-message-info: O6hHXR393YBgshyPGVBhACbETNQjrU1T2tJnnDoGVjtsP6Q96HR+EdpBJIBF+w1wkBJvOPB/16oKhRmE5h2UsWfFkGBpF7SBzdoCh0xsJXHKCou2ySF+IEfRukk9uzy0DkCVCMuHylxGu9IypbaerigidEOZgH4JixQMsy6XpcslRsi+b5hgr9ZJa5mnAkw5Fo2D33lYi3VxE1bavLVuyS+vBygIAbUUrC3C3UIHlD076JI95fL+u34qb4VkA9EnK6pUBwupUwntoJ1aIKBi+/3y9OvlSbE1344SFRLy3JEKDZj3vzOJ3bqtIrbxWA72AzdNMlVGEBacQM6inm/2Nnm3+mOi+qqDdsU6nTzpUpGcTLEqWB/E/wJBESR/P9U2JpMK8msB+vUcbcyLibDFbiHEO25yBNztvSkpod4mMvXyIynsNEdzWAfyjdtECwdlTS9PxOTD46vC/AI+JXfOen4zAya0GzZlMxUWr48zeaK6xBDz+lEuT+bXVRlZM7thsjfDC4ifFk/aMr7ARghawyaPqJoUZ080um0N31U73dw1ngKLtJqgw8HdjrIV7V/JPJDduwn0IVS/XYSatlsHRBTl+7LEPOPfNDkpN3D9a63E9jGnhCLNVLwLbViqd4/PuIMszt2WZfe0jGx7bOe0I5lDmfmh07tO9e7IMwuShK9dBB6cXkk7RHAIGO1MMeSBpjFUXyoE3nwSDwDIKAZj6KgK+i5DXg/EmbypNnRrhDJfF6Wcu2/IkqvskBLoB5RgN9ZlMup5ACe7X8Zh+p/3t2MSJF15rhka0qYmSKtDPjF243kVgLx4MnK21c3vS15m0TmfCu1DAIOfOiSKK94ZQbxFaIu3QYlLYItp4dnAmXAQSUOY8N5KKtYzxNijisd6ZQErK/sGjEBgQnXOW1Od9pG4B+RiscmAAVjo2H8ZZMOUNoSISvj9dYFN51uOIbCj3fKzFbLpdya2JWWaM1jwa/8Ka72HprOfRQadR9X+0dNxiL8ZU/g4DeobTpANsB4tls/67xm4iX1ZDSMMWhKBIJQg0t1lNeqdf6MY7XtdUhuH1dKrUGYvP/bPxE/bf14/ifbbkzXPIoGCu21Ho7TfURxLcKyEu9Iz8qKvZy4e5yA2xcFn4+b7xtZXfG1ZjyC57wr9L02aBlTQ5PstUy6Rnwhcgq/3XGNZdE5XTz1WIfw1fi5j635O6a6nwD29WcBtx/ja0wkP4UevL4NPS8Djfg6ZF/glMp/GCoq8tFS6TkEfu6s10nWtHg4VoJLTueMvKr+F8/TN4UYqPV4WZYY/73fym295OX3Wjo5I3l1724gncM2UXgcgZtPQXc7x6QaeFNJVVpnHh3QCq269iIBiMIujZbb2DeVXM5A5NDL7vq4=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR13MB6515.namprd13.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230038)(366014)(1800799022)(4022899007)(376012)(38070700016);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: fwb188eYTeVYL6GnkGlWWR+FVePUhaBkbeeZmb21eNPzjzTdRIX5JxaBD67vqHWWeAs3fvnau78Oc1xpdjXRmYrT1/uT6Z8b+E3qJYzzWEK2cb8K0XiF8U8g+1Or+gW/yc3PI/X3+GmDOILVJiCoCOi58XQ4EYqGpm0T6Ii9UIWUWnG0x7TkI143rTFMPp4h03ic6JGbKYmshLj1GLqByxpK2TLidbGkC28O2AWFqC5NVRLvSoDV6UDVITCXxxMJpIEyKg8yALSaPSYfmjnlOdu15M7N7fRPiOmnXgSy1FdZeQ55ZFDiuTWWKAkUbdxlox0lmSgXw6sIrvnbOGfnVJNINc4gk5tL1RTYCW6tnTGFP/ziprUFaUQexuGEz1NbXScYk7zU6vBdBesTpmu+kLmQrvhWTdcJViTEK6PXZKl2baP8+geSxkgNc4h/zVm7KpiEcGsbULVvjWnchUPwCW9C8qoB4rCc1d+Cw9A2rjaW6nb3Uxa4x98bLbuoC+9L7LJnRN+uuWrhS2RzX7hZYdjJnKvEbpYLTgiztBLr5JD4ANP1RnJm1c0AfCRtiUaSn5CVmGGngvSOeqZgjyVSSBMeFsK1Q31ivs6sxUAR0NUMIy5eW3BjZWNxVxE3U4F60FXGHCXlE1oo/Tlo6JHhPgAA0yqUoZs6Xvgsc2y9FGxgo2F1XkrrS8mjUM7bzoXtNIgrq1wXudLIhz//GvHuuE6vyr7MInDgMf98sz/7a4+va7fqSf153CloWWcXyMhSR6N6qu//yezHmvRIA2Oysq7J2AEsf1Mw7EfXVCantusjUj1WsXl9/K8ZHuWFDNct+P1c+YYk6GElfPEwf3LE2FCUWGqQjwcgMpjFXNqSsp6ESJ+hDYP0V51g0TJm2WasN9DR+pU2hA68fQuI5K4L4MbJZzp5cUmXRJpDMrmHNnqOJZsManycc1NP7LHznT4xZUO5wG1/75CQ37E+R76dUojGLW4q8SUI1Tdri8vNq1F238NP1mqRQyykMHg0SsCSx+RngG3OfHO9uaIMIEPbSmCjWu0JjjiKcrjHyEIUw0OyOUVfoUgKH5HTP9Wm2mHDRKz3+pjfWK9n4WROLNwnUaoN+3YG+N6Qw6kKkPvjWUs2m+dQWLmRsGm6Fj7aaBB6En0wmk0uQTlUlmjGUI3t8yRDb6z2GXW0ez2OoGKxwMGDoEICXdVjzzjgy0f0lbkp7mBiTzxf1v8QSTIyVbStqbuvDUlm7AA+IO7UmX5eGF2jG8XLqtJ+2d9sQ+gVZoSgsPKBLBVM/QZy1PzGD3iJ9oz3i9aiH24BhSw9qo4AOKtYFEg0JA8Ojl2ZMVN/g2aB8a+up6J5pfo6ahooAObb8zmJYSU6iIwWID6DfjSaKw7OEh9+Its7rgETDHT9ytZg15xK/IlJwWZlxIYWx50bAFo7P6hG+COmJLQcxIaxN3Bd35V+GN5wYm3RB1jLJKsZIpxk/+KB+RiFhrXA0SeLxCsmRK6PCjjQftzAOZdxPk6ky8AxWtGlXIjMv4yTkeKveooeqk5NHGEcqzNA7fhQxG170gVasjuMA+LWnBQHqCv+BGa08UzDQ4nXVBFovpOJLJ/RHoZWJ5ui4IZuJWxn6g==
Content-Type: multipart/alternative; boundary="_000_SA3PR13MB651540D3BA99F0E5AA18FFF188D62SA3PR13MB6515namp_"
MIME-Version: 1.0
X-OriginatorOrg: axenterprize.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA3PR13MB6515.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eecc9eed-ddc7-4bde-225d-08dc960af6a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2024 18:08:21.1536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 00ad0178-ead0-441e-96ff-0c72baf3a6fa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pjNG3occ0A3j73IT8tQFQaUEB0KYFcmrdz9nbgIympNmv1pQg2OUSEpNroFC8fjDKyHxOQdmYum/E7y6bK2HxZkNxLBKzBn9UfX+OTnvBQq9vsLjs/fW6zYqMVsVnReA
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR13MB6980
Message-ID-Hash: VH2WYNNP4VECFURIGWTGOS26YPY7XO2R
X-Message-ID-Hash: VH2WYNNP4VECFURIGWTGOS26YPY7XO2R
X-MailFrom: adam.wiethuechter@axenterprize.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/knhJkFNK8lnLO1Kmv-laDcN9AJI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi all,

+1 to Ricks comments on the DNS and using something in '.arpa'. Something about using RR types makes me feel like this is a heavy-handed approach.

The other interesting benefit to this for EIDs in '.arpa' is allowing both old a new easily. A flat EID would not work well in DNS IMO, but a hierarchized EID as proposed would. This also I think starts to give a framework to help solve the chain of trust issue Brian S. mentioned in a previous email.

For me I am getting deja vu as we are handling the work in DRIP the exact same way in DNS. HITs were a flat 96-bit space that we transformed in HHITs to a hierarchy of two levels; thus, allowing delegation properties in DNS under 'ip6.arpa'.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Rick Taylor <rick@tropicalstormsoftware.com>
Sent: Wednesday, June 26, 2024 1:11 PM
To: Scott Johnson <scott@spacelypackets.com>
Cc: Erik Kline <ek.ietf@gmail.com>; dnsop <dnsop@ietf.org>; sburleig.sb@gmail.com <sburleig.sb@gmail.com>; dtn@ietf.org <dtn@ietf.org>
Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

Hi Scott,

Thanks for the updated doc.   I've been thinking through what I understand is your use-case, and I wonder whether new RRTYPEs is really the right way to go.  As I see it, the less one has to update the DNS infrastructure of the Internet the better, so would this alternative mechanism work for you?:

The IETF creates a subdomain of  `ipn.arpa.` under which all ipn FQNNs in text format (reversed) may be registered, much like public IP addresses under `inet.arpa.`, e.g. ipn:1.2.x would be registered as `2.1.ipn.arpa.`.  This would allow any DNS capable host to resolve an ipn FQNN to DNS name.

Under this DNS name, one could have one or more regular SRV records of the form "_service._protocol.name", e.g. "_tcpcl._tcp.spacelypackets.com." that would allow an entity to discover that TCPCL is available, and of course "spacelypackets.com." (more correctly the target of the SRV record) can be resolved quite normally via an A or AAAA record to your BPA's IP address.

Of course one can sprinkle PTR and CNAME records throughout to add indirection and delegate authority, perhaps to ipn Allocators.  Also the "ipn.arpa." registration can be skipped altogether, and instead DNS-SD or DHCP/RA options can be used to discover the corresponding SRV record entries without requiring global registration.

This has the following advantages as I see it:
1. An ipn EID is now mapped to a Name that can be asserted using regular DNS-name based certificate services.
2. Existing DNS software does not need to be updated.  I can configure my ancient BSD box with BIND to do this now.
3. We don't need yet another binary encoding of ipn EIDs, it's just text.

However, I may have misunderstood your use-case, so this might not be viable alternative.

Thoughts?

Rick

P.S. I'm sure Brian Sipos has a more flexible solution using his EID Patterns under the `ipn.arpa` TLD, but I don't want to muddy the waters by trying to introduce it now


> -----Original Message-----
> From: Scott Johnson [mailto:scott@spacelypackets.com]
> Sent: 26 June 2024 06:19
> To: Rick Taylor
> Cc: Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> Protocol RFC9171
>
> Hi All,
>
> A new version of this draft (06) has been posted here:
> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>
> This includes edits from Scott Burleigh, as well as edits based on the
> feedback from Brian and Rick, but for the references to specs for existing
> CLAs in use in the wild.
>
> Happy to hear any further comments.
>
> Thanks,
> ScottJ
>
>
> On Wed, 26 Jun 2024, Scott Johnson wrote:
>
> > Hi Rick,
> >
> > On Tue, 25 Jun 2024, Rick Taylor wrote:
> >
> >> Hi Scott,
> >>
> >> Thanks for publishing this doc, it looks really interesting.
> >
> > You are welcome.  Thanks for taking the time to review.
> >
> >>
> >> One thing I am unclear about is what is the purpose of having a DNS
> >> record mapping a dtn or ipn Node ID to an IP address.
> >
> > That is not exactly what is happening.  I am mapping an IPN node number
> > to
> > domain name.  That domain name may or may not have IPv4 or IPv6
> > addresses also mapped to it, but that is irrelevant.
> >
> >> Is it so that 'routing' lookups can be performed at BPAs when a next
> >> hop for a particular EID is not known locally?
> >
> > That is an interesting concept perhaps worth exploring further, but no,
> > that was not my intention.
> >
> >> It would be great to have the rationale described in the document.
> >
> > Sure, but the whole thing might be out of scope for DTN WG; it addresses
> > application layer (outside the BPA) considerations.
> >
> > Consider that what BP excels at in robustness and extensibility, it
> > lacks in standardized applications.  One barrier to BP native
> > application authoring which has been identified is lack of an API.  This
> > is being explored in multiple directions, including userspace and kernel
> > API implementations. It is highly useful, when operating over the
> > underlying Internet, for an application to be able to collect all
> > necessary connectivity data via DNS query.
> >
> > A web browser, for example, does a DNS lookup before making a http
> > request.  At a minimum, this means Node Number and available CLA(s) in
> > addition to IP address when making a BP connection.  If BPSEC is
> > deployed, additional RRTYPES, such as a security context identifier
> > (CTX?) and public key (BSEC?) records might be appropriate to negotiate
> > such a connection, but they are out of scope for this draft.
> >
> > If the application then transmits that information via an API to the
> > BPA, the BPA can take action in the contact graph to perfect the
> > connection. This draft, and the RRTYPEs it describes, enable a preferred
> > component of an API structure to encourage application development.
> >
> >>
> >> I'm also a wondering if there out to be references to the relevant
> >> specifications for the CLA's in the RRTPE values: e.g. BSSP-v6 and
> >> STCP-v4?
> >
> > Sure, that would be great.  I am not aware of specification documents
> > for many of these, and for IPND (which I know is not a CLA, but provides
> > a useful discrete automated Node Number and CLA signaling system) there
> > is only the expired draft I posted last year.  What I do have for all of
> > them is running code.  I will dig about a bit for (perhaps archival)
> > spec documents on the other listed CLAs.
> >
> > Thanks,
> > Scott
> >
> >>
> >> Cheers,
> >> Rick
> >>
> >>> -----Original Message-----
> >>> From: Scott Johnson [mailto:scott@spacelypackets.com]
> >>> Sent: 25 June 2024 10:57
> >>> To: Erik Kline
> >>> Cc: dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> >>> Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> >>> Protocol RFC9171
> >>>
> >>> Hi Erik,
> >>>
> >>> Cross posted to DTN list for any such discussion, if they so desire.
> >>> The draft in question is here:
> >>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>>
> >>> Thanks,
> >>> ScottJ
> >>>
> >>> On Tue, 25 Jun 2024, Erik Kline wrote:
> >>>
> >>>> Speaking as the responsible AD for DTN, I think the DTN working
> >>>> group
> >>>> should probably have a discussion about what it wants to do (if
> >>>> anything) vis. DNS RRs.
> >>>>
> >>>> On Tue, Jun 25, 2024 at 08:27 Scott Johnson
> >>>> <scott@spacelypackets.com>
> >>>> wrote:
> >>>>       Hi Mark,
> >>>>
> >>>>       On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>
> >>>>      >
> >>>>      >
> >>>>      >> On 25 Jun 2024, at 16:36, Scott Johnson
> >>>>       <scott@spacelypackets.com> wrote:
> >>>>      >>
> >>>>      >> Hi Mark,
> >>>>      >>
> >>>>      >> Noted and changed.  Good stuff, thanks.  Updated draft
> >>>>       (04) at datatracker using that verbiage:
> >>>>      >>
> >>>>       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>>>      >>
> >>>>      >> Is it appropriate to add an acknowledgments section or
> >>>>       co-authors at this point?
> >>>>      >
> >>>>      > I’m not fussed either way.
> >>>>
> >>>>       (05) of the draft adds a "Contributors" section.
> >>>>
> >>>>      >
> >>>>      >> As well, should I be asking for WG adoption (DNSOP or
> >>>>       DTN WG), or as an Informational document, is Individual
> >>>>       submission sufficient?
> >>>>      >
> >>>>      > I’ll leave that for the chairs to answer.
> >>>>
> >>>>       Ack.  Thank you so much for your time and attention to this
> >>>>       document.
> >>>>
> >>>>       ScottJ
> >>>>
> >>>>      >
> >>>>      >> Thanks,
> >>>>      >> ScottJ
> >>>>      >>
> >>>>      >>
> >>>>      >> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>      >>
> >>>>      >>> Made the IPN description more specific.
> >>>>      >>>
> >>>>      >>>
> >>>>      >>>                                           Wire format
> >>>>       encoding shall
> >>>>      >>> be an unsigned 64-bit integer in network order.
> >>>>       Presentation format, for these
> >>>>      >>> resource records are either a 64 bit unsigned decimal
> >>>>       integer, or two 32 bit
> >>>>      >>> unsigned decimal integers delimited by a period with
> >>>>       the most significant 32 bits
> >>>>      >>> first and least significant 32 bits last.  Values are
> >>>>       not to be zero padded.
> >>>>      >>>
> >>>>      >>>> On 25 Jun 2024, at 15:22, Scott Johnson
> >>>>       <scott@spacelypackets.com> wrote:
> >>>>      >>>>
> >>>>      >>>> Hi Scott,
> >>>>      >>>>
> >>>>      >>>> Wire format of 64 bit unsigned integer it is for IPN.
> >>>>      >>>> Updated draft (03) incorporating all changes posted
> >>>>       at:
> >>>>      >>>>
> >>>>       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>>>      >>>>
> >>>>      >>>> Let me know if you see anything else, Mark, and
> >>>>       thanks!
> >>>>      >>>>
> >>>>      >>>>
> >>>>      >>>> ScottJ
> >>>>      >>>>
> >>>>      >>>>
> >>>>      >>>> On Mon, 24 Jun 2024, sburleig.sb@gmail.com wrote:
> >>>>      >>>>
> >>>>      >>>>> I've lost lock on the ipn-scheme RFC, but my own
> >>>>       assessment is that always sending a single 64-bit unsigned
> >>>>       integer would be fine.  The application receiving the
> >>>>       resource can figure out whether or not it wants to condense
> >>>>       the value by representing it as two 32-bit integers in
> >>>>       ASCII with leading zeroes suppressed and a period between
> >>>>       the two. Internally it's always going to be a
> >>>>       64-bitunsigned integer, from which a 32-bit "allocator"
> >>>>       number can be obtained by simply shifting 32 bits to the
> >>>>       right; if the result is zero then we're looking at an
> >>>>       old-style IPN node number.
> >>>>      >>>>>
> >>>>      >>>>> Scott
> >>>>      >>>>>
> >>>>      >>>>> -----Original Message-----
> >>>>      >>>>> From: Scott Johnson <scott@spacelypackets.com>
> >>>>      >>>>> Sent: Monday, June 24, 2024 8:26 PM
> >>>>      >>>>> To: Mark Andrews <marka@isc.org>;
> >>>>       sburleig.sb@gmail.com
> >>>>      >>>>> Cc: dnsop <dnsop@ietf.org>
> >>>>      >>>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support
> >>>>       Bundle Protocol RFC9171
> >>>>      >>>>>
> >>>>      >>>>> Hi Mark,
> >>>>      >>>>>
> >>>>      >>>>>
> >>>>      >>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>      >>>>>
> >>>>      >>>>>>
> >>>>      >>>>>>
> >>>>      >>>>>>> On 25 Jun 2024, at 10:32, Scott Johnson
> >>>>       <scott@spacelypackets.com> wrote:
> >>>>      >>>>>>>
> >>>>      >>>>>>> Hi Mark,
> >>>>      >>>>>>>
> >>>>      >>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>      >>>>>>>
> >>>>      >>>>>>>> An obvious correction “LTP--v6” -> “LTP-v6”
> >>>>      >>>>>>>
> >>>>      >>>>>>> Aha!  Good eye.
> >>>>      >>>>>>>
> >>>>      >>>>>>>>
> >>>>      >>>>>>>> For IPN why isn’t the wire format two network 64
> >>>>       bit integers?  That is 16 bytes.  Also 2^64-1 is 20
> >>>>       characters so 2 64-bit numbers separated by “." is 41
> >>>>       characters.  It’s not clear where then 21 comes from.
> >>>>      >>>>>>>
> >>>>      >>>>>>> EID is the basic unit of IPN naming, which is
> >>>>       indeed two 64 bit integers separated by a ".". We are
> >>>>       seeking to represent only the node-nbr component of an EID,
> >>>>       as the service-nbr component is loosely analagous to a UDP
> >>>>       or TCP port, for which there is one publicly defined
> >>>>       service in the registry, and a collection of space agencies
> >>>>       who lay claim to another chunk of them:
> >>>>      >>>>>>>
> >>>>       https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-
> service-
> >>> num
> >>>>      >>>>>>> bers As such, there is no gain in including the
> >>>>       second 64-bit
> >>>>      >>>>>>> integer, representing service-nbr in the DNS
> >>>>       records, and indeed, a loss of utility on the application
> >>>>       level.
> >>>>      >>>>>>>
> >>>>      >>>>>>> The node-nbr component is presently, under RFC7116,
> >>>>       a 64 bit unsigned integer.  There is a draft from the DTN
> >>>>       WG currently making it's way through the IESG which will
> >>>>       amend the IPN naming scheme. Perhaps I should add it to
> >>>>       normative references?
> >>>>      >>>>>>>
> >>>>       https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
> >>>>      >>>>>>>
> >>>>      >>>>>>> In effect it splits the node-nbr component into
> >>>>       two-32 bit integers; Allocator Identifier and Node Number
> >>>>       in the "Three-Element Scheme-Specific Encoding" of Section
> >>>>       6.1.2 over the above.  Section 6.1.1 describes the
> >>>>       "Two-Element Scheme-Specific Encoding" method which retains
> >>>>       the use of a single 64-bit integer.  Thus, a single 64 bit
> >>>>       integer (20 characters) or two 32-bit integers (10
> >>>>       characters each) delimited by a "."
> >>>>      >>>>>>> makes 21 characters maximum.  This preserves
> >>>>       forwards compatibility with the proposed amended scheme,
> >>>>       and does no harm if the scheme fails to achieve
> >>>>       standardization.
> >>>>      >>>>>>
> >>>>      >>>>>> Or just 8 bytes on the wire with both possible input
> >>>>       formats described.
> >>>>      >>>>>> Machines using the records will just be converting
> >>>>       ASCII values to a
> >>>>      >>>>>> 64 bit integer.  We may as well transmit it as
> >>>>       that.  Input validation
> >>>>      >>>>>> will need to do the conversion anyway to ensure both
> >>>>       fields will fit
> >>>>      >>>>>> into 32 bits in the “.” separated case and 64 bits
> >>>>       in the single value case.
> >>>>      >>>>>> Length along is not sufficient to prevent undetected
> >>>>       overflows.  The
> >>>>      >>>>>> only thing you need to determine is which format is
> >>>>       the initial
> >>>>      >>>>>> canonical presentation format.  That can be changed
> >>>>       with a later
> >>>>      >>>>>> update if needed.
> >>>>      >>>>>
> >>>>      >>>>> I am tagging in Scott Burleigh, co-author of RFC9171
> >>>>       on this point for clarification.
> >>>>      >>>>> Section 4.2.5.1.2 of same indicates:
> >>>>      >>>>>
> >>>>      >>>>> "Encoding considerations:
> >>>>      >>>>> For transmission as a BP endpoint ID, the
> >>>>       scheme-specific part of a URI of the ipn scheme SHALL be
> >>>>       represented as a CBOR array comprising two items. The first
> >>>>       item of this array SHALL be the EID's node number (a number
> >>>>       that identifies the node) represented as a CBOR unsigned
> >>>>       integer.
> >>>>      >>>>> The second item of this array SHALL be the EID's
> >>>>       service number (a number that identifies some application
> >>>>       service) represented as a CBOR unsigned integer. For all
> >>>>       other purposes, URIs of the ipn scheme are encoded
> >>>>       exclusively in US-ASCII characters."
> >>>>      >>>>>
> >>>>      >>>>> Having already established that we are transmitting
> >>>>       the node-nbr component only, and not a full EID, I am not
> >>>>       sure we are restricted to using only US-ASCII.  ScottB,
> >>>>       your opinion?  CBOR might also be an option, but that would
> >>>>       place a higher burden upon implementers, I think.  Integer
> >>>>       notation for wire format is fine by me.
> >>>>      >>>>>
> >>>>      >>>>>>
> >>>>      >>>>>>>> Limit CLA characters to Letter Digit Hyphen rather
> >>>>       than the full ASCII range.
> >>>>      >>>>>>>
> >>>>      >>>>>>> It is possible for a node to support multiple CLAs
> >>>>       on the same IP
> >>>>      >>>>>>> address and node number.  Will this change allow
> >>>>       multiple, comma
> >>>>      >>>>>>> delimited values to be expressed in the CLA
> >>>>       record?  If so, can you
> >>>>      >>>>>>> point me to an example so I can get the verbiage of
> >>>>       the draft right?
> >>>>      >>>>>>> If not, what do you recommend (in addition to my
> >>>>       defining that in the
> >>>>      >>>>>>> draft)?  I like the idea of limiting the usable
> >>>>       characters.
> >>>>      >>>>>>
> >>>>      >>>>>> Personally I would just use a TXT record wire format
> >>>>       with the
> >>>>      >>>>>> additional constraint that the values are restricted
> >>>>       to Letter, Digits
> >>>>      >>>>>> and interior Hyphens.  The input format matches the
> >>>>       TXT record with
> >>>>      >>>>>> the above character value constraints.  The
> >>>>       canonical presentation
> >>>>      >>>>>> form is space separated, unquoted, unescaped ASCII.
> >>>>       This allow for
> >>>>      >>>>>> long records to be split over multiple lines.
> >>>>       Descriptive comments in the zone file.
> >>>>      >>>>>> This take one extra octet over using comma separated
> >>>>       values.
> >>>>      >>>>>
> >>>>      >>>>> Sold to the man from ISC :)  This part works great;
> >>>>       thank you!  Updated draft pushed to datatracker at
> >>>>       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>>>      >>>>>
> >>>>      >>>>> Thanks,
> >>>>      >>>>> Scott
> >>>>      >>>>>
> >>>>      >>>>>
> >>>>      >>>>>>
> >>>>      >>>>>> e.g.
> >>>>      >>>>>>
> >>>>      >>>>>> example inputs
> >>>>      >>>>>>
> >>>>      >>>>>> @ CLA ( TCP-V4 ; TCP over IPv4
> >>>>      >>>>>>    TCP-V6 ) ; TCP over IPv6
> >>>>      >>>>>>
> >>>>      >>>>>> @ CLA “TCP-V4” TCP-V6
> >>>>      >>>>>>
> >>>>      >>>>>> Wire
> >>>>      >>>>>>
> >>>>      >>>>>> 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’
> >>>>       ‘6’
> >>>>      >>>>>>
> >>>>      >>>>>> Canonical presentation
> >>>>      >>>>>>
> >>>>      >>>>>> @ CLA TCP-V4 TCP-V6
> >>>>      >>>>>>
> >>>>      >>>>>>
> >>>>      >>>>>>> Thanks,
> >>>>      >>>>>>> Scott
> >>>>      >>>>>>>
> >>>>      >>>>>>>>
> >>>>      >>>>>>>> Mark
> >>>>      >>>>>>>>
> >>>>      >>>>>>>>> On 25 Jun 2024, at 08:19, Scott Johnson
> >>>>       <scott@spacelypackets.com> wrote:
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> Hi All,
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> After reading the recent discussion about WALLET,
> >>>>       I am hesitant to jump into the fray here, but this plainly
> >>>>       is the correct group to help me get my logic and syntax
> >>>>       right, so here goes:
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> I submitted requests to IANA for IPN and CLA
> >>>>       RRTYPEs, these representing the missing datasets necessary
> >>>>       to make a BP overlay network connection from data found by
> >>>>       DNS queries.
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> For those not familiar, BP is a store and forward
> >>>>       mechanism generally used in high latency situations where
> >>>>       there does not exist constant end-to-end connectivity.  It
> >>>>       was designed for deep space networking, however has network
> >>>>       segments and application uses which overlay the terrestrial
> >>>>       Internet.  There will arise similar use cases on the Moon
> >>>>       (in the reasonably near future) and Mars whereby low
> >>>>       latency, constant connectivity exists, thereby making use
> >>>>       of DNS in these situations viable.
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> My Expert Reviewer asked for an i-d, to clarify
> >>>>       the requests, and that said i-d be sent to this list for
> >>>>       review.
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> Please find the approptiate draft here:
> >>>>      >>>>>>>>>
> >>>>       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> Relevant IANA requests:
> >>>>      >>>>>>>>>
> >>>>       https://tools.iana.org/public-view/viewticket/1364843
> >>>>      >>>>>>>>>
> >>>>       https://tools.iana.org/public-view/viewticket/1364844
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> I have the BP community also reviewing this, but
> >>>>       they are generally in agreement as to use.
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> Thanks,
> >>>>      >>>>>>>>> Scott M. Johnson
> >>>>      >>>>>>>>> Spacely Packets, LLC
> >>>>      >>>>>>>>>
> >>>>      >>>>>>>>> _______________________________________________
> >>>>      >>>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
> >>>>       unsubscribe send an email
> >>>>      >>>>>>>>> to dnsop-leave@ietf.org
> >>>>      >>>>>>>>
> >>>>      >>>>>>>> --
> >>>>      >>>>>>>> Mark Andrews, ISC
> >>>>      >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>      >>>>>>>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>       marka@isc.org
> >>>>      >>>>>>>>
> >>>>      >>>>>>>> _______________________________________________
> >>>>      >>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
> >>>>       unsubscribe send an email to
> >>>>      >>>>>>>> dnsop-leave@ietf.org
> >>>>      >>>>>>
> >>>>      >>>>>>
> >>>>      >>>>>> --
> >>>>      >>>>>> Mark Andrews, ISC
> >>>>      >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>      >>>>>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>       marka@isc.org
> >>>>      >>>>>>
> >>>>      >>>>>>
> >>>>      >>>>>
> >>>>      >>>>> _______________________________________________
> >>>>      >>>>> DNSOP mailing list -- dnsop@ietf.org
> >>>>      >>>>> To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>      >>>
> >>>>      >>>
> >>>>      >>> --
> >>>>      >>> Mark Andrews, ISC
> >>>>      >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>      >>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>       marka@isc.org
> >>>>      >>>
> >>>>      >>> _______________________________________________
> >>>>      >>> DNSOP mailing list -- dnsop@ietf.org
> >>>>      >>> To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>      >
> >>>>      >
> >>>>      > --
> >>>>      > Mark Andrews, ISC
> >>>>      > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>      > PHONE: +61 2 9871 4742              INTERNET:
> >>>>       marka@isc.org
> >>>>      >
> >>>>      > _______________________________________________
> >>>>      > DNSOP mailing list -- dnsop@ietf.org
> >>>>      > To unsubscribe send an email to
> >>>>       dnsop-
> >>> leave@ietf.org_______________________________________________
> >>>>       DNSOP mailing list -- dnsop@ietf.org
> >>>>       To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>
> >>>>
> >>>>
> >
_______________________________________________
dtn mailing list -- dtn@ietf.org
To unsubscribe send an email to dtn-leave@ietf.org