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

[Erik Nygren <[e-mail]>]

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
>>
>
>