Subject: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 14:13:33 -0800

Francesca Palombini has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

I am concerned by the use of SHOULD in this document. In several places (see 1.
below for what I identified as problematic SHOULDs) the document lacks text
about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who
formulated it very clearly:

If SHOULD is used, then it must be accompanied by at least one of:
(1) A general description of the character of the exceptions and/or in what
areas exceptions are likely to arise.  Examples are fine but, except in
plausible and rare cases, not enumerated lists. (2) A statement about what
should be done, or what the considerations are, if the "SHOULD" requirement is
not met. (3) A statement about why it is not a MUST.

I also have a number of non blocking comments and questions. I will appreciate
answers to my questions, to improve my understanding. If any clarification
comes out of it, I hope it will help improve the document.

Francesca

1. -----

FP: SHOULD lacking additional context:

   Within a SVCB RRSet, all RRs SHOULD have the same Mode.  If an RRSet

   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.

   In AliasMode, the SVCB record aliases a service to a TargetName.
   SVCB RRSets SHOULD only have a single resource record in AliasMode.
   If multiple are present, clients or recursive resolvers SHOULD pick
   one at random.

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

   Zone-file implementations
   SHOULD enforce self-consistency.

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client SHOULD attempt non-SVCB connection
   modes.

   If the client enforces DNSSEC validation on A/AAAA responses, it
   SHOULD apply the same validation policy to SVCB.

   If the client is unable to complete SVCB resolution due to its chain
   length limit, the client SHOULD fall back to the authority endpoint,
   as if the origin's SVCB record did not exist.

   For compatibility with clients that require default transports, zone
   operators SHOULD ensure that at least one RR in each RRSet supports
   the default transports.

   Global Scoped Entry Registry [Attrleaf].  The scheme SHOULD have an
   entry in the IANA URI Schemes Registry [RFC7595].  The scheme SHOULD
   have a defined specification for use with SVCB.

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

2. -----

   This subsection briefly describes the SVCB RR in a non-normative
   manner.  (As mentioned above, this all applies equally to the HTTPS
   RR which shares the same encoding, format, and high-level semantics.)

FP: I am not sure about why this section is described as non-normative but does
define requirements etc. Maybe it is normatively described somewhere else? Then
a pointer to that makes sense. Also why does this mention encoding and format
but there is no encoding specified.

3. -----

   format specific to the SvcParamKey.  Their definition should specify
   both their presentation format and wire encoding (e.g., domain names,
   binary data, or numeric values).  The initial SvcParamKeys and

FP: I have the feeling "should" is not the right term here, I suggest to change
to "must" or "is required to". Also, it would have been useful to me to add a
pointer to RFC 8499 in the terminology about "presentation format".

4. -----

 The value is then
   validated and converted into wire-format in a manner specific to each
   key.

FP: Section 15.4 states

   registration policy ([RFC8126], Section 4.4).  The Format Reference
   MUST specify how to convert the SvcParamValue's presentation format
   to wire format and MAY detail its intended meaning and use.  An entry

This covers the conversion, but does not cover the validation mentioned above.

5. -----

   SvcParams in presentation format MAY appear in any order, but keys
   MUST NOT be repeated.

FP: Seems to contradict

   SvcParamKeys SHALL appear in increasing numeric order.

6. -----

   If the client has an in-progress TCP connection to
   [2001:db8::2]:1234, it MAY proceed with TLS on that connection using
   ech="222...", even though the other record in the RRSet has higher
   priority.

FP: I believe this is descriptive of the example and should not use BCP 14 MAY.

7. -----

   For example, the following is a valid list of SvcParams:

   ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech

FP: I expected this to be a comma separated list.

8. -----

   length prefix.  In presentation format, the value is a single
   ECHConfigList encoded in Base64 [base64].  Base64 is used here to

FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than
"Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5))

9. -----

FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)"
should include a change controller field.

10. -----

Table 1

FP: The table reports that

   | 65280-65534 | N/A             | Private Use    | (This document) |

But that is not specified in the text above, that only talks about first come
first serve registration policy. That should be made consistent.

# Nits and Editorials

11. ------

When the "=" is omitted, the value is interpreted as empty.

FP: When the optional "=" SvcParamValue is omitted

12. -----

   All protocols employing "http://" or "https://" URLs SHOULD respect
   HTTPS RRs.  For example, clients that support HTTPS RRs and implement

FP: I am not sure how the first sentence is supposed to be implemented, hence
why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be
the clearest wording.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 3 Mar 2022 13:26:20 -0500

On Wed, Mar 2, 2022 at 5:13 PM Francesca Palombini via Datatracker <
[email-masked]> wrote:

> about why these are SHOULD and not MUST or MAY.

OK.  I've noted the instances you've identified at
https://github.com/MikeBishop/dns-alt-svc/issues/355

...

> comes out of it, I hope it will help improve the document.

I've attempted to answer questions inline, and tracked the other comments
at https://github.com/MikeBishop/dns-alt-svc/issues/372.

...

> define requirements etc. Maybe it is normatively described somewhere else?

Yes, this section highlights some requirements but does not include any
normative language.  Any normative requirements mentioned in this section
are defined normatively elsewhere in the document.

> Then
> a pointer to that makes sense.

OK, we can add more forward references to this section.  (Tracked at
https://github.com/MikeBishop/dns-alt-svc/issues/371.)

> Also why does this mention encoding and format

This section of the introduction is just an overview, for a reader who is
not familiar with SVCB.  The detailed specification of encodings, formats,
and other requirements is later in the document.

>    SvcParamKeys SHALL appear in increasing numeric order.

Ordering is unspecified in presentation format, but must be sorted in wire
format.

6. -----
> FP: I believe this is descriptive of the example and should not use BCP 14

This "MAY" is intended as an exception to "Clients SHOULD try
higher-priority alternatives first" in Section 3.

7. -----
> FP: I expected this to be a comma separated list.

Section 2.1 notes that "SvcParams are a whitespace-separated list".  The
SvcParamValue for "mandatory" is a comma-separated list ("key65444,ech").

12. -----
> why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not

There are many protocols that are "layered on top" of HTTP in some fashion,
e.g. generating an HTTP URL and performing an HTTP connection as part of
some process.  This text was originally written for WebSocket (wss://), but
it could also potentially apply to something like MTA-STS, which generates
an HTTP URL to fetch information about a mail server.

The SHOULD applies primarily to implementers of such protocols, who may
need to configure their HTTP implementations appropriately.

I think the word "respected" was used because HTTPS-record support is
optional for HTTP in general.  The point here is that HTTPS records are
applicable to such "embedded" instances of HTTP, and should not be ignored
merely because HTTP is not the "top layer" protocol.