There seem to be two topics: 1) Victor's clarification makes sense, although the wording is a little awkward and perhaps we can improve that sentence. The section was already implying that meaning (ie, that the fallback addition of the QNAME was for the AliasMode case) but clarifying this in a more normative way seems worthwhile and not a technical change. I'd propose we refine this PR and incorporate it as the "clarifying sentence" that Warren was willing to accept.
2) There is the issue of whether attrleaf labels are valid owner names for A/AAAA records. This document does not seem like the place to land that, and it seems like it may be open for interpretation as different implementations may have interpreted it differently. If anything, we might add a non-normative sentence like: "Some implementations may not allow A or AAAA records on names starting with an underscore due to various interpretations of RFCs. This could be an operational issue when the TargetName contains an attrleaf label, as well as using an TargetName of "." when the owner name contains an attrleaf label." This wouldn't be a normative change but just an operational warning --- would this be acceptable to include at this stage? Further clarification of this seems worth a draft in its own right since the existing RFCs are inconsistent on this topic and there is room for multiple interpretations, as shown in some implementations. On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman <paul.hoff...@icann.org> wrote: > On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > This is a bug fix, the proposed behaviour makes no sense when $QNAME > > is the unaltered (attrleaf prefixed) starting point. The current > > meaning was not intended. If the edit can be made without any > > major process, just a note to the RFC editor, it'll save errata, > > and possible confusion later. > > A technical change made after the IESG review requires, at a minimum, > another IESG review. The IESG could ask for another IETF review, if they > want. It's up to Warren, the responsible AD, to decide if that's "major > process". > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop