On Wed, Mar 2, 2022 at 5:13 PM Francesca Palombini via Datatracker < [email protected]> wrote:
> > ---------------------------------------------------------------------- > 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. OK. I've noted the instances you've identified at https://github.com/MikeBishop/dns-alt-svc/issues/355 ... > 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. > I've attempted to answer questions inline, and tracked the other comments at https://github.com/MikeBishop/dns-alt-svc/issues/372. ... > ---------------------------------------------------------------------- > 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? 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 > but there is no encoding specified. > 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. > 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. > Ordering is unspecified in presentation format, but must be sorted in wire format. 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. > This "MAY" is intended as an exception to "Clients SHOULD try higher-priority alternatives first" in Section 3. 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. > Section 2.1 notes that "SvcParams are a whitespace-separated list". The SvcParamValue for "mandatory" is a comma-separated list ("key65444,ech"). 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. > 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
