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

sburleig.sb@gmail.com Thu, 27 June 2024 18:06 UTC

Return-Path: <sburleig.sb@gmail.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 31E74C14CF18; Thu, 27 Jun 2024 11:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=gmail.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 e5sDOCwtBbig; Thu, 27 Jun 2024 11:06:16 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607C6C14F6A8; Thu, 27 Jun 2024 11:06:16 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-6bce380eb96so5434445a12.0; Thu, 27 Jun 2024 11:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719511576; x=1720116376; darn=ietf.org; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=pc//LZ/y73ixGd63u178KLTduGN53HrYwS54P+7PAbY=; b=D1fx5A517+0mx67rANjPxfeW2PSpLkGr6utnYpfV784IW75poKjFaDfotxRBuSpv0x bDGiO3ItcZwdSpecw3tkJ/tUiL7euOQCkPYFxAZaaGo+IQ+iKVC4oph3WnBH0iH74gXv xhXJu2IRc6GN3iB75e2eJlqOvnZF/fEjd72YzlxyeeA4YqtER8e8rGxJfbVQIl/OTkeh TPBfvtuU5poKKvgahVHtpTpv6pwQD0fY+dxL+1NvNrjMqsQE90nwTJSCEeK1eOIzskII slX1tPUc0NXo+Txybwq26BAW3o9ZVYncBg8qKGnXzJwyf7PXH6pcqu+NbebN4XfQoGgJ 1Uug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719511576; x=1720116376; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pc//LZ/y73ixGd63u178KLTduGN53HrYwS54P+7PAbY=; b=QLxMwJr9JxTwyyDmik8GVFHaPIT+EEDcr1Xcq+w3IVt8dR4nfTeHhOFb+U5EX7vZ9g bc04EGn7v5WlHbS2xuiYB1t8Pd9/WqEqYYtF1pkydRhvtiIaCTOoQKJ4i9n47kJxVCf5 /9Ib+QoigKFKOylzHmAcT365QVA9TzR8sEvS97LMAJBt1sI+DNmTu7RdXQhDWZ7WZrjZ JcFE9jKtjlOJPwYV8qMOwkYq7HR4Rs/0ZMcyVpkSbzideKvmTZl2+2iuMgNZC1nEQckm uokaLMaTyLZvqFJY4c2akQb5ySvYb5j4FV372QDk1acUZmvKYSsE39aAH8NfvDNtZZK8 pyUA==
X-Forwarded-Encrypted: i=1; AJvYcCUse+7u8Jq65bCif4UikN/mbuj5fP4rsPhVoD5+LFauNUHjMQJcl1M06OC7IOImTAbPWyBMvjNnsCc3ii9fXSzQye5mOaEmV6bp9okr
X-Gm-Message-State: AOJu0Yx25mSBvxpJRDAWpTrf743TE4WsBD+NfzWkCEikZqa96mJup3QZ Jq8uQ4F2C4n43FGAc2+//OdaunEEKB2w6/FRtlG4xWRk3mJiawgBLjORGQ==
X-Google-Smtp-Source: AGHT+IE76EYeAHbIiPQ0rWg5L5zV1448NBsSmHK2/5MBd6CN2A43uIy/xW1Azms2SUcWNz2Qt2k9lA==
X-Received: by 2002:a05:6a20:96db:b0:1b5:ba37:9dac with SMTP id adf61e73a8af0-1bcf80269bfmr13708918637.57.1719511575524; Thu, 27 Jun 2024 11:06:15 -0700 (PDT)
Received: from Dorothy (syn-072-134-194-038.res.spectrum.com. [72.134.194.38]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-72c6a3139f1sm15649a12.20.2024.06.27.11.06.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2024 11:06:15 -0700 (PDT)
From: sburleig.sb@gmail.com
To: 'Rick Taylor' <rick@tropicalstormsoftware.com>, 'Scott Johnson' <scott@spacelypackets.com>, 'Mark Andrews' <marka@isc.org>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@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> <24b5ed89-c7fa-8d2d-826b-f8e08779b6d8@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F98027373928B@tss-server1.home.tropicalstormsoftware.com> <f354954d-f41b-f1af-314c-7db6e4d86191@spacelypackets.com> <A8F570D7-CD30-4693-88EF-C6B977E95590@isc.org> <643022e2-e234-d380-5a79-74213a5b3c90@spacelypackets.com> <38A 5475DE83986499AEACD2CFAFC3F9802737395BC@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9802737395BC@tss-server1.home.tropicalstormsoftware.com>
Date: Thu, 27 Jun 2024 11:06:15 -0700
Message-ID: <113401dac8bc$b412aaa0$1c37ffe0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFoWr7+aU56ksKDHbi6mFLYL+kACQHFTOo6AazQI3QBXpl2DwGfsKUKAml71QwChvQnLQFHkkLtAfqotakCtrUdcwH+n8Z7AnOUZV4B2FHagwDryDVXAN3Jz8oBulag2QMpBskYsc4xjRA=
Content-Language: en-us
Message-ID-Hash: FHXGNFDDSA6LZ7LWLBGHTGSTUIYYQDYP
X-Message-ID-Hash: FHXGNFDDSA6LZ7LWLBGHTGSTUIYYQDYP
X-MailFrom: sburleig.sb@gmail.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>, 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/wO98HivJRed2Me7XxPfGvgIznAo>
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, Rick.  I would not fight to the death over this, but I am skeptical that having domain names map to node numbers encoded in CBOR, rather than to node numbers expressed as unsigned integers, would be advantageous.

My understanding is that RFC 9171 and later https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ define the CBOR encoding for BP ipn-scheme endpoint IDs.  Scott has indicated several times that he doesn't propose to return EIDs as resources; all he wants returned from a DNS lookup by domain name is the fully qualified node number (allocator number followed by node number) to which that name maps.

Section 6.1.1 of the dtn-ipn-update draft explains that the encoding of an FQNN is a 64-bit unsigned integer and explains how that integer value is constructed.  One could CBOR-encode that value, which would tell the recipient "Here's an unsigned integer" and indicate the number of octets occupied by that integer value.  But it would seem simpler (both in the definition and for implementations) to state in the resource record definition that "The value returned is a 64-bit unsigned integer", so that the recipient instantly knows how to handle it.

It is true that the CBOR representation could compress the returned value in many cases, but I would not expect that to be a significant advantage in DNS lookup traffic, which shouldn't be extremely heavy.

Again, not a life-or-death consideration for me, but I would prefer the simpler mechanism.

Scott

-----Original Message-----
From: Rick Taylor <rick@tropicalstormsoftware.com> 
Sent: Thursday, June 27, 2024 1:32 AM
To: Scott Johnson <scott@spacelypackets.com>; Mark Andrews <marka@isc.org>
Cc: Erik Kline <ek.ietf@gmail.com>; dnsop <dnsop@ietf.org>; sburleig.sb@gmail.com; dtn@ietf.org
Subject: RE: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

Hi Both,

Comments inline...

> -----Original Message-----
> From: Scott Johnson [mailto:scott@spacelypackets.com]
> Sent: 27 June 2024 04:36
> To: Mark Andrews
> Cc: Rick Taylor; Erik Kline; dnsop; sburleig.sb@gmail.com; 
> dtn@ietf.org
> Subject: Re: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support 
> Bundle Protocol RFC9171
> 
> Hi Mark,
> 
> On Thu, 27 Jun 2024, Mark Andrews wrote:
> 
> >> I broached the possibility of CBOR in discussion on DNSOP before 
> >> DTN was CCed, making the above point to Scott Burleigh.  Our 
> >> conclusion there, along with Mark Andrews, was that the current 
> >> verbiage is the current best course of action.  I have no personal 
> >> objection to wire format for the IPN RRTYPE being CBOR, if ScottB 
> >> and Mark agree that there is gain to be had over using 64-bit unsigned int.
> >>
> >> That said, it is unclear if appropriate CBOR functions/libraries 
> >> already exist/are used inside nameserver implementations. If not, 
> >> that could substantially delay deployment, and/or add burden to 
> >> implementers.  There is an active draft which specifically treats 
> >> CBOR encoding of RRs ( 
> >> https://datatracker.ietf.org/doc/draft-lenders-dns-cbor section 
> >> 3.2.1), but that document is still an Individual Draft at this point as well.
> >>
> >> Mark, ScottB, opinions?
> >
> > What real benefit would CBOR bring over a raw 8 byte value other 
> > than saying it was entered via X or X.X?
> 
> This would be my criteria exactly.  If we can save bytes, ok; lets 
> consider it.  If not, then why?

My point wasn't about saving bytes (but of course one doesn't want to go overboard and explode the total length) - as Scott B pointed out, this isn't a resource constrained use-case.

My point is about familiarity and commonality.  By the time someone has got their head around EIDs, NodeIds, Node Numbers, FQNNs, introducing yet another binary encoding to save some bytes seems a mistake.

RFC9171 (the source document for all of BP) has a well-defined CBOR encoding, which is updated in a forwards-compatible way in https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ (currently with IESG), so why not re-use it?  It has been intentionally designed such that if in the future NodeIds are expanded again (because 640K is never enough) the format is highly unlikely to need changing.  There is also following work within the WG adding 'wildcard' support, whilst still maintaining a consistent, efficient, self-descriptive format.

If the RRTYPE is encoding a 'data type' defined by a IETF, I would expect there to be a good reason to deviate from the IETF standard binary encoding.

Additionally I think it might make the RRTYPE defining document simpler: You can just normatively reference ipn-update.  

Cheers,
Rick