Re: [dnsext] [EXTERNAL] AWG-IPNSIG CLA RRTYPE in DNS, to complement IPN RRTYPE

["Torgerson, J. Leigh (US 332C)" <[e-mail]>]

My $0.02 Scott:

There is no bssp CLA anymore.  LTP? Not sure where v4 and v6 nomenclature comes from.  We have a lot of different CLAs for BP, not to mention LTP has its own set of underlying CLAs. Space links for instance. It is also possible to send data from point A to point B directly over LTP without even making use of the BP layer. 

Some clarification would be useful to see what you're trying to do here.. I may be off base, but here are my initial thoughts:

The reason DNS works for internet protocols is that there are a ton of specs that everyone takes for granted as standards, so they do not have to be detailed in a DNS record.  The assumption is that everyone has a compliant link layer underneath IP etc. So you need a mapping of entity names to IP addresses and so forth, and DNS does that well. Then you may start adding IP nodes to the IP network and know that if you refer to them by some sort of name, they'll route.

However, DNS is a singularly awful place to try to track BP information. One needs a ton of other information to set up a DTN overlay network, and most of it is not something DNS would help you sort out, nor is DNS the place where I'd ever go to set up a DTN network in space. I don’t care if some DNS record says some DTN node that is running a host with an IP address has certain convergence layer adapters that speak TCP, UDP, RTP or whatever..  That is insufficient for me to stand up a DTN network or add a new node to an existing DTN overlay network.

I'm not sure what the motivation for the proposed draft is, but DTN is an overlay network that does not have to have anything to DO with the internet or DNS. A DTN network may have many many nodes over RF or optical links that never have any IP addresses. There is a DNS-like DTN Node Registry Database under development now, and between CCSDS and the SANA (which is under IANA), the process of standardizing DTN node information and where the repositories is under active consideration now.  These ideas and the interplay between IP and DTN probably need more coordination and socialization with the CCSDS community.

For purely terrestrial use of DTN, a close coupling of DTN node data and internet DNS records may be warranted I imagine, but not for Solar System Internetworking. Wasn't that something the DTN naming scheme was made for? Web-like URIs for nodes, and there you could map nodes to specific IP addresses quite conveniently. But not so with space networking. I'd recommend discussing some of this with the CCSDS System Engineering or Space Internetworking Services area folks. IPNSIG shouldn't diverge from the purpose of developing an Interplanetary Network, and if DTN is part of that, it's unlikely we'll use DNS; and a solar-system-wide DNS system is unlikely.

Can you explain a bit more about your RRTYPE proposal?? I may have totally misunderstood the purpose and reason for this proposal.. 

Thanks
Leigh

J. Leigh Torgerson 
Space Communications Networking Architect 
Protocol Technology Lab Manager 
Communications Architectures & Research (332) 
Jet Propulsion Laboratory 
4800 Oak Grove Drive M/S: 238-420 
Pasadena, CA 91109 
Office: [phone] 
Email: [e-mail] <mailto:[e-mail]> 






On 5/2/24, 4:02 PM, "[e-mail] <mailto:[e-mail]> on behalf of Scott Johnson" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:


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-
[e-mail] <mailto:[e-mail]>.


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: [e-mail] <mailto:[e-mail]>
International telephone number: [phone]
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:


-- 
You received this message because you are subscribed to the Google Groups "AWG IPNSIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [e-mail] <mailto:[e-mail]>.
To view this discussion on the web visit https://urldefense.us/v3/__https://groups.google.com/d/msgid/awg-ipnsig/6a926893-abf7-0087-cf21-b49b58ee1748 <https://urldefense.us/v3/__https://groups.google.com/d/msgid/awg-ipnsig/6a926893-abf7-0087-cf21-b49b58ee1748>*40spacelypackets.com__;JQ!!PvBDto6Hs4WbVuu7!NkQNb5caJuVQUNYxOhEGrvVZoz-g9KNMiYaSr-DlithrY_K60ZYZG_q4gf_g3gSZZyQUlD3nztCoc5vR0PNo5Bq5HS5LUOIR$ .