On Sep 7, 2022, at 8:29 PM, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > Once SVCB resolution has concluded, whether successful or not, > > +if at least one AliasMode record was processed, > > SVCB-optional clients SHALL append to the priority list an > > endpoint consisting of the final value of $QNAME, the authority > > endpoint's port number, and no SvcParams. (This endpoint will be > > attempted before falling back to non-SVCB connection modes. This ensures > > that > > SVCB-optional clients will make use of an AliasMode record whose TargetName > > has > > A and/or AAAA records but no SVCB records.) > >> What happens under the current wording, before the addition above? That is, >> if no AliasMode record was processed, is the addition along the lines of >> "you can only add this if you have it, and if no AliasMode record was >> processed, you don't have it"? Or does the addition solve the problem "if no >> AliasMode record was processed, the thing you append will be harmful"? >> > Yes. > > If no AliasMode record was processed, then $QNAME would be the origin name > PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be > legitimate A/AAAA owner names (and shouldn't exist), and if a client did that > it would be harmful (to the client), at least a little bit harmful (trying > something that won't work.)
If this proposed change is only for something that is a bit harmful to the client (trying something that won't work), then I don't think this reaches the bar for making a change after IETF and IESG evaluation. The amount of process work that is necessary to make this technical change far outweighs the advantage to clients who are unaware of the problem that this thread has exposed. A draft with a discussion of this one problem would go a long way to alerting client authors of this problem. The same draft could also talk about the other issues that sparked this larger thread. Such a draft is not limited to "change this sentence to that": it could have a discussion of the various things that client developers are discovering. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
