Okay, that sounds like confirmation to me. All good then!
On 10-01-2025 11:29, Kazunori Fujiwara wrote:
From: Matthijs Mekking
I would use city.ise.mie.example instead, unless you have confirmation
that JPRS is fine with using .jp as an example here.
JP domain names have second-level, third-l
> From: Matthijs Mekking
> I would use city.ise.mie.example instead, unless you have confirmation
> that JPRS is fine with using .jp as an example here.
JP domain names have second-level, third-level, and fourth-level delegations,
but are provided through a single jp zone.
The structure of jp dom
Hi Peter,
On 09-01-2025 21:31, Peter Thomassen wrote:
Hi Matthijs,
Thank you for your helpful review! Please find some responses below:
On 1/9/25 14:09, Matthijs Mekking wrote:
Section 3
-
"There MUST NOT be more than one DSYNC record for each combination of
rrtype and scheme."
I w
On Jan 9, 2025, at 15:52, Peter Thomassen wrote:
>
> Hi Ed, (author hat off)
>
> On 12/24/24 21:23, Edward Lewis wrote:
>> I don’t think the generic TLD restrictions are the bottleneck.
>
> It is a known fact that several gTLDs [1,2] want to do CDS-based automation
> and have implementations
Hi Ed, (author hat off)
On 12/24/24 21:23, Edward Lewis wrote:
I don’t think the generic TLD restrictions are the bottleneck.
It is a known fact that several gTLDs [1,2] want to do CDS-based automation and
have implementations ready, and are waiting for ICANN's blessings for
deployment.
[1
Hi Mauricio,
Thank you for your review!
On 12/20/24 22:41, Mauricio Vergara Ereche wrote:
I support this draft.
I would only like to see a bit more consideration on section 5 about how to
deter malicious attempts from forged/spoofed addresses that might trigger
amplification attacks in the f
Hi Matthijs,
Thank you for your helpful review! Please find some responses below:
On 1/9/25 14:09, Matthijs Mekking wrote:
Section 3
-
"There MUST NOT be more than one DSYNC record for each combination of rrtype and
scheme."
I wonder what the argument is for this. Doesn't this prevent
Late to the party, but I also support this draft. I read the latest
version and I like it. Some comments below. Apologies if there are
duplicate comments.
Best regards,
Matthijs
Section 2.1
---
I notice that notifies for DNSKEY have been removed since the initial
implementation. I g
On Tue, 7 Jan 2025 17:24:57 +0100
Peter Thomassen wrote:
> Hi Stefan,
Hello Peter,
> Thanks for your feedback. The below fixes will be included in the
> revised submission that will be published soon (probably today or
> tomorrow).
Thank you for your work, my reactions are below.
> On 12/27/
Hi Q,
Thanks for this feedback, which we will address as follows in the next revision:
On 12/13/24 15:34, Q Misell wrote:
In general I SUPPORT this draft progressing to an RFC, baring one (hopefully)
easily addressable nit:
§ 2.3 should be clearer on if a scheme is RRTYPE specific, or always h
Hi Stefan,
Thanks for your feedback. The below fixes will be included in the revised
submission that will be published soon (probably today or tomorrow).
On 12/27/24 12:09, Stefan Ubbink wrote:
In section 3.2 (Child-specific Method) it says:
"It is also possible to publish child-specific recor
All
Welcome to 2025! The WGLC wraps up for generalized-notify tomorrow Friday
January 3rd. Now there are some open questions, but I am aware the authors
are still on holiday until Monday (which the chairs are more than
happy with). Open questions will be addressed early next week.Others
are
On Thu, 12 Dec 2024 06:53:06 -0500
Tim Wicinski wrote:
> This starts a *four week* Working Group Last Call for
> draft-ietf-dnsop-generalized-notify
> "Generalized DNS Notifications"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-generali
On Dec 24, 2024, at 14:01, John Levine wrote:
>
>
> See RFC 1996, section 4.8.
>
Ahh - but I’d have tagged 4.7. The query ID, whose relationship to NOTIFY is a
bit different from regular queries.
> Remember that the notification is just a hint. Whatever receives the NOTIFY
> might decide
>
On Tue, 24 Dec 2024, Edward Lewis wrote:
Remember that the notification is just a hint. Whatever receives the NOTIFY
might decide
to try the update on its own, so I don't see any new issues here. You're right
that if a
CDS key roll doesn't happen, there is no way to tell the child what the prob
It appears that Edward Lewis said:
>My first concern is that if the entries under _deleg.$parent will “leak” the
>registrar (when applicable) of a name for names
>that are run by operators that are not also registrars for the name. I don’t
>know if this is a business concern.
It's a business
On Dec 12, 2024, at 06:53, Tim Wicinski wrote:
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/
I have voiced reservations about this approach in the past, keep that in mind
when reviewing what I have here.
Between sec
I support publication of this draft. The opportunities to improve on poll
mechanisms with push based update are widespread and I think will be
beneficial to timely updates between parent and child.
G
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscrib
I strongly support this draft and urge its adoption as a Proposed
Standard. This is a significant step forward that will make it possible to
deploy efficient coordination mechanisms between child zones and parent
zones.
Steve Crocker
--
Sent by a Verified
sender
_
I support this draft.
I would only like to see a bit more consideration on section 5 about how to
deter malicious attempts from forged/spoofed addresses that might trigger
amplification attacks in the future, as this could lead to multiple queries
being sent out.
Thank you,
Mauricio
On Thu, Dec
Hi,
Am 19.12.2024 um 17:35 schrieb Oli Schacher:
Hi
I support the draft progressing to an RFC. Switch (.ch / .li ) is
considering an implementation for our DS automation process based on
this draft.
I support the draft. We're also currently working on an implementation
for ironDNS.
Best
All
This is just a reminder of the Working Group Last Call
for draft-ietf-dnsop-generalized-notify that is ongoing.
It will continue through the new year and will end January 3, 2025. The
Chairs would like to hear from the working group on this document.
thanks
tim
On Thu, Dec 12, 2024 at 6:53
I would like to see the Generalized Notify document proceed.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
Hi
I support the draft progressing to an RFC. Switch (.ch / .li ) is
considering an implementation for our DS automation process based on
this draft.
Best regards
Oli
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le
Moin,
In general I SUPPORT this draft progressing to an RFC, baring one
(hopefully) easily addressable nit:
§ 2.3 should be clearer on if a scheme is RRTYPE specific, or always has
the same meaning in the protocol.
Good work from the authors, looking forward to seeing this deployed!
Q
--
25 matches
Mail list logo
