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

[Erik Nygren <[e-mail]>]

Bringing (hopeful) closure to this thread, we've published -11:

Diff of the changes:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-11.txt

The only things included are the two changes agreed on in this thread.
(We did not include the "hostname" => "domain name" clarification
mentioned above as there wasn't any feedback on it, so it wasn't
clear that we had consensus from the WG and were trying to minimize the
changes
as much as possible.)

Hopefully this puts us back on track.  Thank you to Warren for guiding
us through this exception process.

Best, Erik





On Thu, Sep 29, 2022 at 9:16 AM Erik Nygren <[e-mail]> wrote:

> One item discussed above that the authors would like to clarify is to be
> consistent
> about whether the alternative endpoint name (TargetName) is a hostname
> or a domain name.  In all but one place in the doc we refer to it as a
> "domain name"
> but there is one reference that calls it a "hostname".
>
> In particular in these current sentences:
>
> 1) An "alternative endpoint" is a hostname, port number, and other
> associated
>
> 2) TargetName: The domain name of either the alias target (for AliasMode)
> or the alternative endpoint (for ServiceMode).
>
> 3) TargetName is a <domain-name> ({{!RFC1035, Section 5.1}}),
>
> 4) In AliasMode, the TargetName will be the name of a domain that resolves
> to SVCB,
>
> We'd like to change the first of these to be:
>
> 1) An "alternative endpoint" is a domain name, port number, and other
> associated
>
> for consistency with the rest.
>
> As this isn't explicitly covered in Warren's summary we thought it worth
> checking here as well:
> https://mailarchive.ietf.org/arch/msg/dnsop/LhEufm0a8IjoXZ_ck0b9RTSkDTc/
>
> Best, Erik
>
>
>
>
>
>
>
>
> On Mon, Sep 12, 2022 at 9:51 AM Warren Kumari <[e-mail]> wrote:
>
>>
>> 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
>>>
>>
>>