On Thu, May 13, 2021 at 10:25 AM Ben Schwartz <bem...@google.com> wrote:
>
>
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <bem...@google.com> wrote:
>>
>>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
>>
> Breaking the binding into pieces creates many new opportunities for error,
> such as having multiple TargetNames in a single binding. It corresponds to
> a multimap datastructure instead of a standard map. Every attribute of
> each binding would naturally be an unordered collection, which is a bad fit
> for attributes that are required to be singular, or an ordered list, or
> anything other than a set.
>
> Switching to a zone file format that is simpler to parse would go a long
>> way to improving those.
>>
>
>
> Considering alternative formats is an intriguing exercise, but I do not
> think it is likely to result in improvements to SVCB.
>
So, my first alternative format (for splitting out key/value pairs)
involved adding another component to the record format, which (as you
noted) allowed for multiple instances of TargetName.
Here it is again for reference:
> Encode everything using the following mechanism:
> Priority Enumeration Key Value
> One of the "Keys" would be Target, with a corresponding Value of FQDN.
> All of the records with the same value for "enumeration" belong together,
> and form a single SvcParameter list.
> For the AliasForm, both the Priority and Enumeration would be 0, and only
> a single Target,Value pair are permitted.
> To take one example from the draft, and re-encode it thusly:
> $ORIGIN svc.example. ; A hosting provider.
> pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
> HTTPS 2 . alpn=h2 ech="abc..."
> pool 300 IN A 192.0.2.2
> AAAA 2001:db8::2
> h3pool 300 IN A 192.0.2.3
> AAAA 2001:db8::3
> This would become (for brevity, encoding just a list of RDATA values for
> all of the "pool HTTPS" records):
> 1 1 target "h3pool"
> 1 1 alpn "h2,h3"
> 1 1 ech "123..."
> 2 2 target "."
> 2 2 alpn "h2"
2 2 ech "abc..."
So, taking your observations about TargetName into account, and borrowing
from the overloading of Priority to signal AliasMode, here's an alternative
that I think addresses most of the concerns.
Priority {AliasTarget | ServiceTarget | KeyName}
{ServiceBindingPriorityValue | Value}
where
Priority == 0 => AliasMode
Priority >0, <128 => ServiceMode
Priority > 128 => ServiceBinding key-value record
The same example would be encoded (again with only RDATA values):
> 1 target "h3pool" 128
> 128 alpn "h2,h3"
> 128 ech "123..."
> 2 target "." 129
129 alpn "h2"
129 ech "abc..."
The Priority values are sortable (as required), and sorting all the records
has the side-effect of grouping the key/value pairs.
If desired, the key/value pairs can be sorted by the first two fields
(priority and key) to check for uniqueness before use.
The look-up of keys and values, or the recombining into some arbitrary
structure (whatever the output of parsing the wire format from the current
proposal is), seems straightforward.
The parsing of each record's presentation (zone) format is as simple as
whatever each individual parameter's format requires/allows.
And, there is no longer any ability to introduce duplicate target names in
a single record reconstruction, as the ServiceMode record is distinct from
the key/value set.
If necessary, the presentation and wire formats for key/value records could
add an extra "." to avoid burning the Code Point already allocated. That
"." would simply be ignored, and add one byte (I think) to the wire format,
plus the other relative inefficiencies already noted.
I think this is sufficiently different from the earlier encoding, to be
worth consideration.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
