Re-,
We can always speculate about how this will/should be implemented/deployed, but
I’m afraid that this won’t be ideal as we would expect. Unfortunately, the
wire-format create more troubles than it solves for this specific case.
Avoiding adherence with the underlying discovery library while
On Thu, Oct 5, 2023 at 9:21 AM Ben Schwartz wrote:
> Instead, clients should be instructed to ignore any keys that they don't
> intend to use (as is always the case in SVCB), and IKE/DNR servers can
> memcpy their responses directly from the SVCB RDATA.
>
My IKE implementation will not just
In general, IKE and DHCP CPEs shouldn't be manually configured with DNS
SvcParams. These SvcParams are adjustable metadata under the control of the
DNS server operator, which may change its configuration over time (adding or
removing protocols and endpoints, etc.). Instead, the CPE should
Hi Ben,
The ossification is what we wanted to avoid with passing the representation
format at the first place. I see that risk now with the wire format and I’m
really concerned about that, especially for CPEs :-(
We can’t impose that the configuration parameters are always supplied as binary
I think adding columns to the registry is likely to have the opposite effect:
implementers will feel that they are required to use a special implementation
of SvcParams, rather than simply passing the blob around. This will create
severe ossification: DNS servers won't be able to activate new
Hi Tommy, all,
One comment on this part:
> the binary format for the parameters, and it doesn’t require the IKE
> implementation to do any parsing, etc. on that.
Actually, it should because we have some restriction on params in DNR/IKE.
Blindly passing the information to DNS libraries may
As with DNR, I definitely think we should be using the wire format here (for
communicating on the wire). The IKE option here would carry the binary format
for the parameters, and it doesn’t require the IKE implementation to do any
parsing, etc on that.
Since it looks like there’s good
As I said over the other side, I prefer presentation format. Here that is even
more true than over at the dhcp server because ike daemons (server AND client)
tend to not implement dns wire format.
Presentation format would be to reject this change.
But whichever is picked, if I am in the
Hi all,
This document is already in AUTH48-DONE but still not published yet because of
a normative dependency (see more about the cluster at
https://www.rfc-editor.org/auth48/C461).
A late issue was raised about the encoding of the service parameters
(representation format vs wire format).
