Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

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.hoffman@icann.org> wrote:

> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni <ietf-dane@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
>