On Wed, May 19, 2021 at 7:01 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> > > On Wed, May 19, 2021 at 3:00 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman <paul.hoff...@icann.org> >> wrote: >> >>> Are these still just idle ideas you are tossing out (as you indicated >>> earlier), or meant to be serious proposals? If the latter, what is the >>> significant improvement over the current draft? I ask because it feels like >>> you are suggesting moving the inherent complexity of the semantics of SCVB >>> around, but not noticeably reducing it overall. Unless there is a >>> significant reduction in complexity, I don't see the value of grinding on >>> this further. (I say this as someone who is not happy with the current >>> level of complexity of the semantics, but don't see a way to reduce it.) >>> >>> --Paul Hoffman >> >> >> It is meant to be a serious proposal. >> The improvement is in the clarity and parse-ability of the HTTPS record >> in zone file format, including reducing the complexity of the >> HTTPS-specific semantics, without changing the actual wire format semantics >> or complexity per se. >> >> I'm working on the details of that, but it will necessarily be its own >> work-in-progress. I hope to get something stable based on feedback... I >> don't expect to get it 100% right on the first pass. >> >> The first pass should hopefully illustrate the benefits at least, and >> justify keeping list activity ongoing. >> > > Here is a very very brief version of HTTPS (call it HTTPS RRTYPE version 2 > pre-alpha-1, I suppose) ServiceForm RDATA (following the SvcPriority and > TargetName): > > - Make the "mandatory" field a derived (calculated) value, not an > actual component of the zone format > - no-default-alpn is a flag and excluded from the derived "mandatory > set" (i.e. automatically mandatory) - no change, semantically > - port is numeric, if present, and excluded from the derived > "mandatory set" (i.e. automatically mandatory) - no change, semantically > - ech, ipv4hint, and ipv6hint are string values (space separated list > of values for *hint), and additionally marked as either mandatory or > optional (syntax TBD) - conditionally added to "mandatory set" > - alpn is a space-separated list of string values, and additionally > marked as either mandatory or optional - conditionally added to "mandatory > set". > - The HTTPS RDATA itself is an ordered sequence of values, with > placeholder empty values occupying the respective position, using the empty > string ( "" ) if a parameter is not used > - Thus, the RDATA is positional in nature, very similar to the SOA > zone file format, and does not require any use of "key=" components at all > - The sequence of values in the RDATA is "no-default-alpn", "port", > "ech", "ipv4hint", "ipv6hint", "alpn" > - The placement of alpn as the last element of the RDATA allows it to > be a list of an arbitrary number of strings, rather than a singleton, which > avoids the escaping characters issue. > - The zone file format and parsing are deterministic and > bidirectionally congruent. > - The proposed marker(s) for either "optional" or "mandatory" are "~" > for optional, and "+" for mandatory (similar to usage in SPF) > > Note that, similar to the SOA record, most hand-editing of zone files > would involve copying the commented blank form, and changing whatever needs > to be specified according to the actual intention of the domain owner. > > Here are some of the examples from the original draft, re-imagined with > the new zone file encoding. > NB: new zone format, but representing identical corresponding wire > formats to the original examples: > > alpn=h2,h3-19 mandatory=ipv4hint,alpn ipv4hint=192.0.2.1 > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "" ; ech - not present > "192.0.2.1" ; ipv4hint, mandatory (not marked with "~") > "" ; ipv6hint - not present > "h2" "h3-19" ; list of alpn values, mandatory (not marked with "~") > ) > > alpn="f\\\\oo\\,bar,h2" > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "" ; ech - not present > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "~foo,bar" "h2" ; list of alpn values, optional (marked with "~" on > first string meaning optional) > ) > > ipv6hint="2001:db8::1,2001:db8::53:1" > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "" ; ech - not present > "" ; ipv4hint - not present > "~2001:db8::1,2001:db8::53:1" ; ipv6hint, optional (per initial "~") > "" ; alpn - not present > ) > > port=53 > ( "" ; no-default-alpn is "no" aka not-present > "53" ; port > "" ; ech - not present > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "" ; alpn - not present > ) > > (No parameters other than priority and target) > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "" ; ech - not present > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "" ; alpn - not present > ) > > alpn=h2,h3 ech="123..." > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "~123..." ; ech, not mandatory (marked with "~" > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "~h2" "h3" ; list of alpn values, optional (marked with "~") > ) > > alpn=h2 ech="abc..." > ( "" ; no-default-alpn is "no" aka not-present > "" ; port - not present > "~abc..." ; ech, optional (not marked with "~") > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "~h2" ; (list of) alpn value(s), optional (marked with "~") > ) > > ech="111..." ipv6hint=2001:db8::1 port=1234 > ( "" ; no-default-alpn is "no" aka not-present > "1234" ; port > "111..." ; ech, optional (not marked with "~") > "" ; ipv4hint - not present > "~2001:db8::1" ; ipv6hint, optional (marked with "~") > "" ; alpn - not present > ) > > port=8002 ech="..." > ( "" ; no-default-alpn is "no" aka not-present > "8002" ; port > "~..." ; ech, optional (marked with "~") > "" ; ipv4hint - not present > "" ; ipv6hint - not present > "" ; alpn - not present > ) > > Compactness in a zone file format is not a feature, it is (IMNSHO) a bug. > Clarity and unambiguous parsing, and round-trip (zone->wire->zone) identity > are attributes that should be major considerations. > > Unless I'm missing something, this appears to remove the ability for extensibility by adding additional SvcParams in the future? That is a major feature and "selling point" of HTTPS and SVCB records (and is even why "mandatory" exists) so I would not be in-favor of a proposal that removes the ability for future extensibility. Best, Erik
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
