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

Scott Johnson <scott@spacelypackets.com> Mon, 24 June 2024 22:20 UTC

Return-Path: <scott@spacelypackets.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 7542BC1CAF40 for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2024 15:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 fyEIwJR4ZOOS for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2024 15:20:03 -0700 (PDT)
Received: from www.spacelypackets.com (www.spacelypackets.com [IPv6:2602:fdf2:bee:feed::ee]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B647C180B7B for <dnsop@ietf.org>; Mon, 24 Jun 2024 15:20:01 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1sLs26-00072Q-18 for dnsop@ietf.org; Mon, 24 Jun 2024 22:19:30 +0000
Date: Mon, 24 Jun 2024 22:19:30 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: dnsop@ietf.org
Message-ID: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Message-ID-Hash: WC5O6PBU5YPLY3N56ELPNNW6RYHCK24T
X-Message-ID-Hash: WC5O6PBU5YPLY3N56ELPNNW6RYHCK24T
X-MailFrom: scott@spacelypackets.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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] 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/82KvWi04aDO_aTTogPpBwS3B-JM>
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,

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