[DNSOP] Sub-field encoding scheme discussion (possibly 3597-bis)

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 21 May 2021 19:47 UTC

Return-Path: <brian.peter.dickson@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 E451A3A1E4E for <dnsop@ietfa.amsl.com>; Fri, 21 May 2021 12:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqxsCFua_nmW for <dnsop@ietfa.amsl.com>; Fri, 21 May 2021 12:47:10 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E7D3A1E4B for <dnsop@ietf.org>; Fri, 21 May 2021 12:47:09 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id a2so31316479lfc.9 for <dnsop@ietf.org>; Fri, 21 May 2021 12:47:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cnWFdftG+YaxwXQvW9vvzT2GBZEY5F/TzNPtNPn5G/U=; b=PnHNE8r8wF00jqz+eyL12gFvQ4QubZTW46MNfeQPL/M1n5BfuMMPOnyMyhxKZ929wI TtxfNwBJAPiqKdzpnHXGubtpe/AzWj/F55MiIbf5T7XzKBzh3IeCRemNvts9SMVPQj04 1NF92ANM91Ise2eAKITL5UUhWYEM5DFGNuF7xSPyZlLMzEG9u7gMrEYNpTVxnC4v1CAs xoLW6qvvM5hugAvchfllb6sHV3v+Hk7auQ7cZIZm8mriW+ALVg1/rDeNhWlm5TmnktRV zQfggquj3izY7xvBZ4tMCVW9fsFmstHux7oJFkXxU9zzO6u86kjsqwtpCj+LPH2PDX6K 0z4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cnWFdftG+YaxwXQvW9vvzT2GBZEY5F/TzNPtNPn5G/U=; b=s30XsJva6tNLGbGz37AHv51Y5/f43AdPk6erNwq8bwK6jKBNhJY2R+rJE0J/5pkUXy GaURN38V6/WeW6sOtLeng5ERd99rpGu1GtVSs4FJDMMdVSDn8qembI9UQ/yQBaQge5dy 3CV3kWxcZrJAd51iZRa4eXNFu0joLkxg0GMnNSMs33zaK3n2lAqBrkRZYUkvfAg3iLOP HoWVPTfMLqswOvvobR/Oi1zu/jjjqRR3seBi9DhaWX03eC+6ynRQAqvjFNL/ATCCE+xn m0WX5fanZhN+d2uiuVOXelW0lDTmC/EM0BWcO9L4Kmlf70zHsCjG+Gc06c3fUBayshPm lTrA==
X-Gm-Message-State: AOAM530wpsPLD5HWDIzkTpqM0UOm07TG9hwPM2IuprMkwyPYVvr9mCw1 beCuA/DWXNofcMQM0xDEL30B+q4OXm65aTn54AwUV0mbDGc=
X-Google-Smtp-Source: ABdhPJxG/gI3kM8d3odMGJwOO+5S1cE9RJ7eUjyN9WLWJ89YDWeNDPhCCl185LP8ZBL5If8oTXDNL/84U3X0o82JaIE=
X-Received: by 2002:ac2:42d1:: with SMTP id n17mr3226064lfl.318.1621626426664; Fri, 21 May 2021 12:47:06 -0700 (PDT)
MIME-Version: 1.0
References: <7ADF1FB2-97A4-4C49-8F25-8BF03BE01640@hopcount.ca> <20210512213903.D5F1F7AA827@ary.qy> <CAMOjQcFJjcsvaREF0fr+2GTY4zTy5CxSxR16BEp=Nc-K9WJ0Tg@mail.gmail.com> <CAH1iCipAVKVCuH2ME=+YpeJyijrKCtzJaU3bRFyy1f48EB33iw@mail.gmail.com> <CAHbrMsCjWgV7nc575L_qdvr7HdoEVKqkXRwLdXA2L5NiCgdvwA@mail.gmail.com> <CAH1iCipW_-BSMQZ-S+m18pyzfxTGsCrmG9Pc-b35_VRiLhxh4w@mail.gmail.com> <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com> <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com> <CAHbrMsAW_wtKmRDYKZVUrFLZYuM_DqoS-8VRMf-O0Z8WpPBfbg@mail.gmail.com> <CAKC-DJj3nPAZp=qpwjBJ_3yG_EO-q-bcJbaizUNw9uq6deVZjg@mail.gmail.com> <C3734365-D5F7-4F9A-A463-5EFBB841A583@apple.com> <CAH1iCiod61M5aHnF_qrpP6=Oc3nBL+McaSui5NUnLd1GbS=okw@mail.gmail.com> <CAH1iCipcjnHdBcc7VCpLr9rP6vbbTHKYPHtqBkQu_achzpohcg@mail.gmail.com> <D10F7DCD-71AE-4AFC-9835-C9E1F03D831F@icann.org> <CAH1iCiphr71C0MjhP-amR4S5FpDzKc4qkDvsU3qMXhdLNhiwyw@mail.gmail.com> <CAH1iCiqSFk0XP_We+cUfe0xFvmDMusPc3weHxSK-e5CLT6jLwg@mail.gmail.com> <CAKC-DJhH=OK_mraWK1pVEx6a_hiPSPF-KQwd+mDy_2mg_a17CQ@mail.gmail.com> <CAH1iCip=Y0MTh4=ATqWPdWSDot4dmBge96Y-cdL86hk3dk3ddg@mail.gmail.com> <9a138693-60a0-4b75-99f5-6a7544f935a0@www.fastmail.com> <CAH1iCirdY4HWj1o8X3mEkPJODrQZ391YsuC75Hs5m5G4PM3ATA@mail.gmail.com> <1A6728DB-72CB-425E-90D7-38159DC8D4FB@fl1ger.de> <CAMOjQcF=K_Dkya7yamKECxHjmsEVHmLyoaoF3KRnCXqPde4wSw@mail.gmail.com> <91F79DA0-4BD9-414C-973D-024F3583F3EB@fl1ger.de> <CAH1iCioNaPJUbKojB3jMhQpv+k3XquzL8qeH_9tZDHrUCSTKHw@mail.gmail.com>
In-Reply-To: <CAH1iCioNaPJUbKojB3jMhQpv+k3XquzL8qeH_9tZDHrUCSTKHw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 21 May 2021 12:46:54 -0700
Message-ID: <CAH1iCiqBN3WbFUxX2BPt02kdkeAXtHQVSo0D8dULS4GbpD2h1g@mail.gmail.com>
To: WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001eab5b05c2dc535c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MPRVqTMiW5N55bjufbWFHXiooqo>
Subject: [DNSOP] Sub-field encoding scheme discussion (possibly 3597-bis)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 19:47:13 -0000

I think there is a need for something similar to RFC3597, except for fields
in a record rather than a BLOB for the record itself.
RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
not for complex RRs.

Context: there is a general problem on sub-field encodings (i.e. which has
arisen from new drafts failing to observe RFC5507's recommendations.)
An example use case would be adding extensions to any RRTYPE which uses TLV
wire format, and for which no semantically-meaningful encoding of new types
within the RRTYPE RDATA in presentation format exists.

Here's a short list of things I think such a scheme should have:

   - A set of defined presentation-format <-> wire-format (bidirectional)
   transformations
   - The optional inclusion of a type code (the T in TLV) if the resource
   record format is TLV
   - A method of applying a label to a field (for use by user-interfaces,
   or for hand-edited zone file clarity)

Such a scheme would facilitate more-complex RRTYPEs, and be more
zone-file-friendly than RFC3597

Here's what I think would work:

keyNNNN:label:mapping=value


with the following alternate formats:

label=value -- requires label be understood by the server, including both
the corresponding key number and mapping

label:mapping=value -- if the LHS does not begin with "keyNNNN", it is not
a TLV encoding in wire format, only a field value encoding

keyNNNN::mapping=value -- no label included
keyNNNN=value -- no label included, default generic mapping
keyNNNN:label=value -- label available, default generic mapping


The presentation format of "value" would itself be subject to the rules
specified by the "mapping" used.

For backward compatibility to any existing implementations, the
specification of "keyNNNN" and "mapping" should both be optional, with the
existing mapping as the default.
This would facilitate migration of zone files between implementations which
are "extension-aware" and "extension-unaware" for any given extension of an
RRTYPE

For purposes of examples, here are some suggested mappings:

uint16 - single integer with no leading zeros, maps to 16-bit unsigned
value, must be a singleton

uint16List - comma-separated list of integers between 0-65535, maps to the
same (unsorted) sequence of 16-bit unsigned values; TLV length specifies
total length; use in non-TLV context requires a uint16 length

uint16SortedList - comma-separated list of integers between 0-65535, maps
to a sorted sequence of 16-bit unsigned values; TLV length specifies total
length; use in non-TLV context requires a uint16 length
base64 - base-64 encoded blob, maps to whatever binary it decodes to, must
be a singleton

base64List - list of base-64 encoded items, comma separated in presentation
format; a sequence of 16-bit length/value pairs in wire format; TLV length
specifies total length; use in non-TLV context requires a uint16 length

flag - has no value in presentation format, has no data in wire format as a
TLV (implicitly a singleton), or a uint16 representation of 0 or 1 in the
non-TLV use case

ipv4 - an IPv4 address in the same format as an A record (both presentation
and wire formats)

ipv4list - one or more ipv4 values - if multiple, space separated and
double-quote delimited; maps to a sequence of IPv4 addresses (A record wire
encoding); TLV length specifies total length; use in non-TLV context
requires a uint16 length
ipv6 - an IPv6 address in the same format as an AAAA record (both
presentation and wire formats)
ipv6list - one or more IPv6 addresses  - if multiple, space separated and
double-quote delimited; maps to a sequence of iPv6 addresses (AAAA record
wire encoding);  TLV length specifies total length; use in non-TLV context
requires a uint16 length
CSV - one or more strings, separated by commas, enclosed in double quotes,
as follows:

inside quotes is encoded as the subset of printable-ASCII characters in the
range of decimal 32 to decimal 126 with escaped (backslash) double-quote,
escaped escape (double backslash), and also permitting other 8-bit values
as escaped-decimal values \DDD
maps to sequence of (length | value) where each length is uint8 and
length(value) is between 1 and 255 inclusive.
mapped value of one string from the list is the contents of the substituted
string (e.g. with escape substitutions performed) without the enclosing
quotes
TLV length specifies total length; use in non-TLV context requires a uint16
length

FQDN - a domain name; maps to wire-encoding for a domain name


Discussion/feedback is welcome.
If there is interest, I will write this up as an ID.

Brian