Subject: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 03:58:09 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would like to thank Joe for the Opsdir review.

I just have some minor comments (I'm not a DNS expert):

In 2.3,
   to indicate that "foo://api.example.com:8443" is aliased to
   "svc4.example.net".  The owner of example.net, in turn, could publish
   this record:

   svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
       alpn="bar" port="8004" ech="..." )

   to indicate that these services are served on port number 8004, which
   supports the protocol "bar" and its associated transport in addition
   to the default transport protocol for "foo://".

I can understand how this record indicates that it supports protocol "bar", but
it is not obvious to me how this record also indicates that it also supports
"foo://".

2.4.1.  SvcPriority

   RRSets are explicitly unordered collections, so the SvcPriority field
   is used to impose an ordering on SVCB RRs.  SVCB RRs with a smaller
   SvcPriority value SHOULD be given preference over RRs with a larger
   SvcPriority value.

Would it be helpful for this text to indicate under what conditions this SHOULD
is not a MUST?  Which is perhaps related to the text in section 5.1?

   The primary purpose of AliasMode is to allow aliasing at the zone
   apex, where CNAME is not allowed.  In AliasMode, the TargetName will
   be the name of a domain that resolves to SVCB, AAAA, and/or A
   records.  (See Section 6 for aliasing of SVCB-compatible RR types.)
   The TargetName SHOULD NOT be equal to the owner name, as this would
   result in a loop.

It was unclear to me that this is a SHOULD NOT rather than a MUST NOT.  I.e.,
are there some circumstances where it is useful to not comply with this.

   In AliasMode, records SHOULD NOT include any SvcParams, and
   recipients MUST ignore any SvcParams that are present.

Again, I wasn't sure why this isn't a MUST NOT rather than a SHOULD NOT?

Finally, thank you for providing the examples in 11.3, I found them to be
particularly helpful.

Regards,
Rob

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 3 Mar 2022 15:10:47 -0500

The fact that this endpoint is for use with the "foo://" scheme must be
communicated out of band in some fashion.  When this endpoint is used with
that scheme, it indicates the specified information.

2.4.1.  SvcPriority
> is not a MUST?

Yes, I think we will clarify this (
https://github.com/MikeBishop/dns-alt-svc/issues/355).

Broadly, this is not a MUST because it is fundamentally a performance
heuristic, and sophisticated clients tend to get very opinionated about the
precise heuristics they use (e.g. racing connections in parallel,
prioritizing connections that might be faster for other reasons).

>   Which is perhaps related to the text in section 5.1?
>

Yes.

> are there some circumstances where it is useful to not comply with this.

No, loops are never useful.  However, some BIND authors felt that a MUST
NOT would impose a requirement on them to check for loops during zone file
parsing.

We've received a few comments about this so it will likely be revised.

> Again, I wasn't sure why this isn't a MUST NOT rather than a SHOULD NOT?

This is a "SHOULD NOT" to match the "MUST ignore".  We felt that having
them both be "MUST" would be illogical, and wanted to ensure that we kept
the option of placing extensions on alias records in a future revision.

> Finally, thank you for providing the examples in 11.3, I found them to be

You're welcome!