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

[Warren Kumari <[e-mail]>]

Hi all,

Firstly, and most importantly, thank y'all for keeping this civil, friendly
and productive; I really appreciate it.

I've (informally) checked with the IESG on the proposed change in the
PR and also including Erik's proposed operational note ("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.") and everyone seems fine with it.

So, I'm ask the authors to cut a new version with these changes in
(basically, accept the PR and add the proposed text) and I will then email
the IESG with a diff to get "official" consensus on the change.

Dealing with process exception handling is always stressful, so thanks all
again for keeping this moving along nicely.
Also, a reminder that while we *can* make changes after approval (and
before RFC publication) we really really avoid doing so, and so this should
only happen under exceptional circumstances[0].

W

[0]: I'm not convinced that this situation rose to the "exceptional
circumstances" bar, but seeing as I'd already paused it (not knowing what
all the issues were) and because the changes are clarifications, I'm
willing to accepting it.

On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren <[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
>> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>