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 <war...@kumari.net> 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 <erik+i...@nygren.org>
> 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 <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
>>
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
