On Mon, May 17, 2021 at 2:46 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> I re-read (several times) the current -05 version of the draft. I found it > difficult to follow and understand several aspects of the "automatically > mandatory", "mandatory", and mandatory usage in the document, both > syntactically and semantically. > I'm sorry this wasn't clear. The text at the top of Section 7 defines the terminology In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not function correctly for clients that ignore this SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys that are "automatically mandatory", i.e. mandatory if they are present in an RR. ... > Here are some specific suggestions, including incorporating the updated > proposed encodings: > > - Use the term MTI (mandatory to implement) > - MTI parameters would be "alpn", (maybe) "no-default-alpn", and > (maybe) "port" > - The IANA table in 14.3.2 really needs an MTI column in addition > to the other columns > > In the HTTPS protocol mapping as presently defined, there are no MTI parameters. A compliant client implementation might not have any supported parameters. We could add a row for this in the table, but its value would be "none". (Future mappings may indeed have MTI parameters.) As the table notes, the "automatically mandatory" parameters are "no-default-alpn" and "port". A client that doesn't support any parameters would ignore any record that contains these parameters. > > - For each binding registry, > > Mapping documents are IETF-controlled, not IANA-controlled, so there isn't a "registry" per se. an additional table column specific to that registry should be > included/added: "non-negotiable", i.e. MTI for this binding. A "service binding" is a single SVCB RR; I presume you mean the "mapping", a document that defines how to use SVCB in some context. It sounds like "non-negotiable" is a synonym for "automatically mandatory". I'm certainly open to changing the draft's terminology. "non-negotiable" might be clearer, although I'm not sure what negotiation it's describing. > > - Replace the "mandatory" thing, with an "optional" flag to be > optionally appended to any parameters that are not "non-negotiable". > - This also removes the need to have a sorted list of mandatory > attributes > - Each binding will have a list of non-negotiable attributes, which > can be used for validating the "optional" flag on both the authority > side > and the client. > - Any parameter that is not non-negotiable, but does not have the > optional flag, must be supported by the client for the parent HTTPS/SVCB > record to be accepted by the client. > > It sounds like this "optional" flag is exactly the inverse of the present "mandatory" indication. The present structure was chosen in part to simplify the zone file and wire formats, by avoiding an additional mark that must be written or parsed on every SvcParam. Additionally, for compatibility, it seems likely that the great majority of parameters will either be automatically mandatory (as specified in the mapping document) or optional (especially if they are introduced later), so making parameters mandatory unless marked otherwise seems like the wrong default. > > - The binding tables then become lists of parameter sub-types that the > specific binding uses, marked as optional-allowed or non-negotiable. The > binding table incorporates all the MTI sub-types as well. > > I'm not sure what you're describing, but note that new parameters can be defined over time, and we do not want every new parameter draft to Update the SVCB RFC. The proposed parameter registration policy is first-come-first-served, with the understanding that clients will normally ignore new parameters that they do not recognize. > > - The binding tables obviously still need default values (if > appropriate), e.g. for ALPN. > > The HTTPS binding would then consist of: > > - Default ALPN of "http/1.1" > - MTI of "alpn" > > Note that declaring alpn to be "MTI" would have no effect. As presently defined for HTTPS, the "alpn" SvcParamKey only adds advertised protocols. If you prefer to stick to the default protocol (TLS over TCP), you can "implement" the alpn parameter by ignoring it. > > - aNN of "port" > - NN of "no-default-alpn" > - Optional of "ecn" > - Optional of "ip4hint" > - Optional of "ip6hint" > > And an HTTPS referenced record (included by reference from record with > SvcPriority between 1 and 127), would have the following rules: > > - Any "optional" parameter MUST be implemented by the client, UNLESS > the "optional" flag is present in the HTTPS referenced record > > It seems you are drawing distinctions between "mandatory to implement", "non-negotiable", "optional", and "flagged optional". I don't believe this is a simpler formulation than the current draft. By working through an alternative formulation, I think you've shown that the complexity is irreducible. I continue to prefer the current draft, as it provides the correct behavior in ordinary cases with simple inputs like 1 . alpn="h2,h3" ech=... >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop