Re: [Gen-art] Genart last call review of draft-ietf-dnsop-svcb-https-07

[Ben Schwartz <[e-mail]>]

-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 <
[e-mail]> 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