> On 20 Jun 2023, at 23:35, Dick Franks wrote:
>
> On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote:
>> 8
>
>>
>> The change was from -03 to -04 and discussed in the WG IIRC. The specific
>> sentence your refer to was a lingering oversight in the changes from -03 to
>> -04. I have consulted
On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote:
>8
>
> The change was from -03 to -04 and discussed in the WG IIRC. The specific
> sentence your refer to was a lingering oversight in the changes from -03 to
> -04. I have consulted many developers on this, and so far I had no push back.
>
> > ex
Correction
Deleting that one sentence changes the meaning of the proposal from
explicitly querying the authoritative server for the appropriate
report channel to a dependence on authoritatives attaching an
-(unsolicited) EDNS0 report channel option to each and every query.
+(unsolicited
> On 20 Jun 2023, at 21:39, Dick Franks wrote:
>
> On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote:
>> 8
>
>>> On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>> 8
>
>>> I have one nit.
>>>
>>> In the Example in section 4.2., a request still "includes an empty ENDS0
>>> report channel". Th
On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote:
>8
> > On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>8
> > I have one nit.
> >
> > In the Example in section 4.2., a request still "includes an empty ENDS0
> > report channel". The third paragraph of that same section states something
> > simi
It appears that Peter Thomassen said:
>My take is that the parent should create a _signal subdomain (preferably as a
>delegation). The per-child target can be queried by prepending, e.g.
>
> _notify.example._signal.parent. IN NOTIFY CDS scheme port
> scanner.registrar.example.
>
>This way,
I’ve just come across this message (I have been out a bit recently)…sorry is
this is late.
These are suggestions…
For the situation where a (an active) nameserver is not configured to answer a
query it received (which is the case where my use of lame delegation comes
from), I’d suggest the fol
From: DNSOP on behalf of Vladimír Čunát
Date: Tuesday, June 20, 2023 at 6:01 AM
To: "dnsop@ietf.org"
Subject: [Ext] Re: [DNSOP] Coming soon: WG interim meeting on the definition of
"lame delegation"
>On 19/06/2023 17.00, Masataka Ohta wrote:
>>I can't see any problem with "lame" delegation th
Hi Wes,
On 6/9/23 19:43, Wes Hardaker wrote:
For lame delegations, I think discussion is needed further. It's
unclear from the draft at the moment (and I think it needs to be very
clear) about what to do with servers that are lame. It discusses
whether or not CDS/CDNSKEY/CSYNC are supposed to
On Tue, 20 Jun 2023, Peter Thomassen wrote:
My thoughts on this as in how to decide who does what, is...
in EPP, there is a section that I've coded to look like...
The usual drop downs are Yes/No and may require a reason
Create a new action, "DS Managed by", give it three options
Y=t
Hi Mark,
On 6/13/23 16:43, Mark Elkins wrote:
There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up
On 6/20/23 17:48, Paul Wouters wrote:
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed to overloading).
Agreed.
That's not what th
On 6/20/23 17:51, Paul Wouters wrote:
parent. IN NOTIFY CDS scheme port scanner.parent.
Why a new RRtype ?
Why more stuff in the APEX?
Why not:
_notify_cds.parent. IN CNAME targetservice.parent.
targetservice.parent. IN A .
targetservice.parent. IN .
Pers
On Tue, 20 Jun 2023, Matthijs Mekking wrote:
If there are different targets for different children of the same parent,
then a generic NOTIFY record like below won't work anyway.
parent. IN NOTIFY CDS scheme port scanner.parent.
Why a new RRtype ?
Why more stuff in the APEX?
Why not:
On Tue, 20 Jun 2023, John Levine wrote:
It appears that Matthijs Mekking said:
Hi,
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed
Hi,
On 6/20/23 17:37, Matthijs Mekking wrote:
A note on where to send CDS and CSYNC notifications. I sort of
understand why the NOTIFY record includes a RRtype field, but will
parental entities really have a different target for receiving notifies
for CDS and CSYNC?
I've talked to Peter at som
On 6/20/23 17:14, John Levine wrote:
It appears that Matthijs Mekking said:
Hi,
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed t
It appears that Matthijs Mekking said:
>Hi,
>
>I like this draft because of it tackles the issues of wasteful CDS
>polling and it uses NOTIFY, a mechanism that is well known, already
>exists in implementations, and actually feels like a good fit (as
>opposed to overloading).
Agreed.
>A note
Dear WG,
We have agenda, slides and meeting details for Meetecho, Zulip, etc.,
available on datatracker:
https://datatracker.ietf.org/meeting/interim-2023-dnsop-01/session/dnsop
Best,
-- Benno
On 06/06/2023 16:19, IESG Secretary wrote:
The Domain Name System Operations (dnsop) WG will hold
On Tue, 20 Jun 2023 at 12:14, Willem Toorop wrote:
>8
> In the Example in section 4.2., a request still "includes an empty ENDS0
> report channel". The third paragraph of that same section states
> something similar: "As support for DNS error reporting was indicated by
> a empty EDNS0 report chan
Thank Dick!
> On 16 Jun 2023, at 18:33, Dick Franks wrote:
>
> All
>
> I have reviewed the document which appears to be almost ready for
> submission to IESG.
>
>
> Subsection 6.1.1 uses QNAME to refer to two different entities.
> The opening sentence needs to say nothing more than that the r
Hoi Willem,
> On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>
> Op 08-06-2023 om 11:59 schreef Benno Overeinder:
>> Dear DNSOP WG,
>>
>> The authors and the chairs feel this document has reached the stage where
>> it's ready for Working Group Last Call.
>>
>> This starts a Working Group Last
Op 08-06-2023 om 11:59 schreef Benno Overeinder:
Dear DNSOP WG,
The authors and the chairs feel this document has reached the stage
where it's ready for Working Group Last Call.
This starts a Working Group Last Call for:
draft-ietf-dnsop-dns-error-reporting.
Dear all,
I find this is a ver
On 19/06/2023 17.00, Masataka Ohta wrote:
I can't see any problem with "lame" delegation than a "secondary"
or "slave" server, because of the history of racial discrimination
in US.
Honestly, I'm personally still failing understand the problem of using
slightly offending word when referring t
24 matches
Mail list logo
