Given the request below to preserve the current wire format for both HTTPS
and SVCB, I think this raises some interesting options and questions:
- My understanding of SVCB is that it is intended to be the "parent"
type for both HTTPS and other future "mappings" over SVCB.
- HTTPS is the first "instantiation" of an SVCB-compatible record type.
Given those two statements, would it not then make sense to separate out
the following:
- HTTPS and SVCB zone file encoding schemes
- HTTPS will be, in effect, "set in stone" by the whatever RFC
defines it, and can have a zone file format that is tailored to the
pre-defined parameters used for HTTPS (and excluding new HTTPS
parameters,
modulo an update to an HTTPS RFC)
- SVCB should not be set in stone, and be extensible, and thus may
have need for a more flexible zone file format
- Regardless of whether the zone file formats differ, splitting the
current draft into two drafts (one for SVCB and one for HTTPS) makes a lot
of sense.
- Updates to HTTPS should not require touching SVCB
- RR-specific RFCs are the norm
- Decoupling them removes any artificial constraints on their
respective zone file formats
- Overly-generalized RRs was one of the major problems with SRV, and
we should take advantage of that lesson. There is no benefit to burdening
the zone file format of HTTPS with general-purpose machinery.
- Referencing the wire format of SVCB reduces the unique elements of
an HTTPS draft, allowing it to focus on the things that make HTTPS unique.
- The decision to split them into two drafts should not in and of itself
depend on what the specific contents of the HTTPS draft (i.e. details of
that draft) are.
- Even if the HTTPS zone file format does not change, there is still
valid reason to split them into two drafts.
- This also provides a sensible template for future SVCB-compatible
drafts.
- Any potential for burning a code point for the early allocation for
HTTPS should not automatically impact the code point for SVCB. Splitting
the draft into two formalizes that, and reduces any perceived issues with
causing a code point to be consumed by revisions to either draft.
I'll follow up with some more specific suggestions about the zone file
format for HTTPS.
I don't really have major problems with SVCB, as the use case I'm primarily
concerned with is HTTPS.
Also, vendor/operator support for HTTPS and SVCB should also be decoupled.
It should be anticipated that some vendors will support HTTPS but not
support SVCB.
Brian
On Wed, May 19, 2021 at 1:34 PM Brian Dickson <brian.peter.dick...@gmail.com>
wrote:
>
>
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpa...@apple.com> wrote:
>
>> I wanted to chime in on this discussion as a client-side implementor who
>> has already widely deployed support for SVCB/HTTPS.
>>
>> The current format, where the parameters are structured as a list within
>> a single RR, is certainly simpler and less error prone for processing. Much
>> of the information contained as parameters within the SVCB RR are useful
>> for higher-level “application” logic. Within our deployment, the DNS stub
>> resolver daemon receives the RR and does the parsing, and passes up the
>> parameters bundle as a blob that is more or less opaque, to the layer that
>> handles actual connection processing (doing happy eyeballs, protocol
>> selection).
>>
>> Processing the content of SVCB parameters must be handled atomically: the
>> ALPN, ECH config, and any other information must be handled clearly as a
>> unit and not have any chance of being broken up. Lots of code is already
>> based on processing RRs as chunks of data, and requiring anyone looking at
>> the information to stitch the parameter list back together based on
>> multiple RRs that must be in a particular order adds complexity and invites
>> in bugs and errors.
>>
>> I’d strongly encourage sticking with the wire image we’ve already been
>> using and deploying.
>>
>
> Would it be accurate to say that as long as the wire format of both SVCB
> and HTTPS do not change, your client implementation(s) would not be
> impacted by any changes to zone file format?
>
> I.e. you don't implement any server code, so what the zone format is does
> not affect you, and how the wire format gets produced from the zone format
> is not relevant to you?
>
> Thank you for the details on how your client uses the wire format and the
> way those impact the end client systems.
>
> Brian
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
