[dnsext] CLA RRTYPE in DNS, to complement IPN RRTYPE

Scott Johnson <scott@spacelypackets.com> Thu, 02 May 2024 23:02 UTC

Return-Path: <scott@spacelypackets.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54074C151091 for <dnsext@ietfa.amsl.com>; Thu, 2 May 2024 16:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 vPI19UDFRoLK for <dnsext@ietfa.amsl.com>; Thu, 2 May 2024 16:02:12 -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 1E187C151068 for <dnsext@ietf.org>; Thu, 2 May 2024 16:02:11 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1s2fPa-00015X-0U; Thu, 02 May 2024 23:00:22 +0000
Date: Thu, 02 May 2024 23:00:22 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: AWG-IPNSIG@googlegroups.com, ipnsigpwg@googlegroups.com
cc: dnsext@ietf.org
Message-ID: <6a926893-abf7-0087-cf21-b49b58ee1748@spacelypackets.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/M4fh0JrvyOv7QLeEb1dZT0Dqdyo>
Subject: [dnsext] CLA RRTYPE in DNS, to complement IPN RRTYPE
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2024 23:02:14 -0000

Hi All,

Please find below a draft RRTYPE Parameter Allocation Template for your 
review for the CLA RRTYPE, which will describe available CLAs on a node on 
a given domain.  If there is further comment on the IPN RRTYPE draft, or 
this CLA RRTYPE draft, please speak up and be heard.  Pending further 
comment, I plan to officially submit these on Friday.

Thanks,
ScottJ



                 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE

    When ready for formal consideration, this template is to be submitted
    to IANA for processing by emailing the template to dns-rrtype-
    applications@ietf.org.

    A. Submission Date:

    B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
    B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR

    C. Contact Information for submitter (will be publicly posted):
       Name: Scott M. Johnson Email Address: scott@spacelypackets.com
       International telephone number: +13868887311
       Other contact handles:

    D. Motivation for the new RRTYPE application.

       Bundle Protocol (RFC 9171) defines Convergence-layer adapter (CLA)
       as "a node component that sends and receives bundles on behalf of 
the
       Bundle Protocol Agent, utilizing the services of some 'integrated'
       protocol stack that is supported in one of the networks within which
       the node is functionally located."  Knowledge of these CLAs is an
       inherent requirement for inter-nodal BP communications.  The ability
       to query the DNS for a given node's supported CLAs would add
       significant utility to BP network operation.

    E. Description of the proposed RR type.

       A record using the proposed RRTYPE would consist of one character
       string, specifiying one CLA per record entry.  Multiple CLA
       records could exist for any given domain, indicating support for
       multiple CLA availability on the corresponding node. Examples of
       these CLA record strings include UDPv4, UDPv6, TCPv4, TCPv6,
       LTPv4, LTPv6. BSSPv4, BSSPv6, DCCP, STCPv4, and STCPv6.

    F. What existing RRTYPE or RRTYPEs come closest to filling that need
       and why are they unsatisfactory?

       The proposed CLA RRTYPE is most similar to TXT records, however
       there are multiple uses for TXT record types, which would add
       undue parsing burden to BP applications which seek to learn
       about CLAs available at a given node on a given domain to
       differentiate from other uses of the TXT RRTYPE.  The use of
       a CLA RRTYPE eliminates all ambiguity of purpose.

    G. What mnemonic is requested for the new RRTYPE (optional)?

       CLA

    H. Does the requested RRTYPE make use of any existing IANA registry
       or require the creation of a new IANA subregistry in DNS
       Parameters?

       Other than the addition of the CLA RRTYPE to the existing
       "Resource Record (RR) TYPEs" IANA Registry, no modifications
       are required.

    I. Does the proposal require/expect any changes in DNS
       servers/resolvers that prevent the new type from being processed
       as an unknown RRTYPE (see [RFC3597])?

       No.

    J. Comments: