-last-call Thanks for the detailed review, Dale. I've posted a proposed change to incorporate most of your comments: https://github.com/MikeBishop/dns-alt-svc/pull/335
On Sat, Aug 14, 2021 at 7:34 AM Dale Worley via Datatracker <
nore...@ietf.org> wrote:
> Technical issues:
>
> Whereas SRV records have both a priority and weight field, SVCB
> records have only a priority field. (This point is not addressed in
> section C.1.)
I've proposed some text on that point for section C.1, but I don't think we
need a Weight field. As you noted, it doesn't seem to have been widely
used within SRV.
In SVCB, weighted load balancing can be added in the future as a SvcParam
if there is demand, so it seemed wise to exclude it from the base
specification for simplicity.
>
> 2.2. RDATA wire format
>
> When the list of SvcParams is non-empty (ServiceMode)
>
> Actually, an AliasMode record can have a non-empty SvcParams, it
> simply SHOULD NOT. The subtle case is whether an AliasMode record
> with non-empty SvcParams is governed by this section (which requires
> the SvcParams to be properly formatted and "If any RRs are malformed,
> the client MUST reject the entire RRSet") or by section 2.4.2 ("In
> AliasMode, ... recipients MUST ignore any SvcParams that are
> present.") I recommend stiffening the requirement so that AliasMode
> records MUST NOT have SvcParams (and having the zone file processor
> enforce it).
>
I've removed the confusing parenthetical, but otherwise I would prefer not
to change the normative requirements here. While we don't have any clear
use case or semantics for AliasMode SvcParams, I think it's conceivable
that we could discover some in the future, and it might help if current
implementations just ignore them.
>
> 8.1. Query names for HTTPS RRs
>
> Reusing the service name also allows ...
>
> I assume this means "Using one record for both HTTP and HTTPS allows ..."
>
No this is about using the same QNAME for HTTPS that we currently use for A
and AAAA. Clarified.
>
> D.2. ServiceForm
>
> Is this "ServiceMode"?
>
Yes, fixed.
> This section uses "vector" in three places where "form" or "example"
> would likely be better.
>
"Test vector" is a standard phrase in this context, e.g.
https://datatracker.ietf.org/doc/html/rfc6716#appendix-A.4
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
