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
On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 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
On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote:
> > If no AliasMode record was processed, then $QNAME would be the
> > origin name PLUS the prefix(es) of type attrleaf ( underscore
> > thingies). Those won't be legitimate A/ owner names (and
> > shouldn't exist), and if a client
[cid:8771DFF1-513C-40BC-B5C7-093C04815944]
(With apologies for the duplicate message, sending again without line-break
issues.)
Dear colleagues,
ICANN’s Office of the Chief Technology Officer is pleased to announce that the
fifth ICANN DNS Symposium (IDS 2022) will be held on 15-16 November
On Sep 7, 2022, at 8:29 PM, Brian Dickson wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the
Hi all!
Gentle reminder to fill in the Doodle poll.
We will close the poll today, end-of-business day.
Best,
Suzanne, Tim and Benno
On 31/08/2022 19:56, Benno Overeinder wrote:
Dear DNSOP WG,
We are planning our second DNSOP WG interim meeting for 2022 in the week
of 26-30 September.
