Here is a slightly deeper dive into this alternative scheme (for zone file/presentation and wire format), in terms of both the encoding, and the specification document itself (and as a result, the IANA components).
I re-read (several times) the current -05 version of the draft. I found it difficult to follow and understand several aspects of the "automatically mandatory", "mandatory", and mandatory usage in the document, both syntactically and semantically. The actual binding specifications also were either incomplete or confusing, with respect to the mandatory/"mandatory" things. (Default values for alpn, plus the "alpn" parameter, and "no-default-alpn" were similarly a bit hard to follow, and/or hard to surmise from only the binding entry.) The list of parameters within a binding, versus across bindings, was also somewhat ambiguous, which for subsequent bindings (e.g. from new RFCs after this become an RFC) could be confusing or even result in conflicting bindings. Here are some specific suggestions, including incorporating the updated proposed encodings: - Use the term MTI (mandatory to implement) - MTI parameters would be "alpn", (maybe) "no-default-alpn", and (maybe) "port" - The IANA table in 14.3.2 really needs an MTI column in addition to the other columns - For each binding registry, an additional table column specific to that registry should be included/added: "non-negotiable", i.e. MTI for this binding. - Replace the "mandatory" thing, with an "optional" flag to be optionally appended to any parameters that are not "non-negotiable". - This also removes the need to have a sorted list of mandatory attributes - Each binding will have a list of non-negotiable attributes, which can be used for validating the "optional" flag on both the authority side and the client. - Any parameter that is not non-negotiable, but does not have the optional flag, must be supported by the client for the parent HTTPS/SVCB record to be accepted by the client. - The binding tables then become lists of parameter sub-types that the specific binding uses, marked as optional-allowed or non-negotiable. The binding table incorporates all the MTI sub-types as well. - The binding tables obviously still need default values (if appropriate), e.g. for ALPN. The HTTPS binding would then consist of: - Default ALPN of "http/1.1" - MTI of "alpn" - NN of "port" - NN of "no-default-alpn" - Optional of "ecn" - Optional of "ip4hint" - Optional of "ip6hint" And an HTTPS referenced record (included by reference from record with SvcPriority between 1 and 127), would have the following rules: - Any "optional" parameter MUST be implemented by the client, UNLESS the "optional" flag is present in the HTTPS referenced record - This rule applies to "ecn", "ip4hint", and "ip6hint" records (each has its own "optional" flag, and that flag is only applicable to the parameter associated with the main HTTPS record linking to the parameter). I'll follow up with examples, that correspond to the examples in the original document. Brian 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: >>> >>>> 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