On Mon, May 17, 2021 at 5:36 PM Ben Schwartz <bemasc=
40google....@dmarc.ietf.org> wrote:
>
>
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> 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:
>>>>
>>> ...
>
>> 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.
>>>
>> ...
>
>> 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..."
>>
>
> I find this format, with multiple lines and multiple integers per binding,
> much more difficult to read or write than the current draft, especially
> since the elements of each binding can potentially be spread across a zone
> file (perhaps by accident) in arbitrary order.
>
>
I concur with Ben here. Thank you for spelling out and proposing this
alternative, but this seems much less usable
and understandable by a typical user, either for zone publication or for
reading diagnostic output from tools
like "dig" or for talking about in other drafts specifying SVCB.
Side-note: some precursors to SVCB and earlier discussions in the working
group
proposed using a standardized format such as CBOR for encoding the
SvcParams but
that approach was discarded as bringing in a bunch of its own baggage and
being too
different from typical DNS usage.
An approach HTTP took was to define "Structured Field Values for HTTP"
(rfc8941)
which may be more complexity than is needed here, but perhaps there
is a similar approach that could work for SVCB of defining explicit types
for SvcParamValues?
Another approach could be seeing if there was a way to require
everything to use a limited character set and require escaping
for things outside of these constraints. For example, alpn values
with a limited set of token characters would be allowed as strings,
but anything else would need escaping. Would require base64 encoding
of SvcParamValues wanting characters outside of "non-special"
be easier to parse, perhaps with a prefix to indicate that a string is
base64 type?
Are there other similar things that would keep the format similar to the
existing
format but reduce the number of parser special-cases needed?
Erik
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
