On Tue, 7 Jan 2025 17:24:57 +0100 Peter Thomassen <peter=40desec...@dmarc.ietf.org> 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/24 12:09, Stefan Ubbink wrote: > > In section 3.2 (Child-specific Method) it says: > > "It is also possible to publish child-specific records, where the > > wildcard label is replaced by the child's FQDN with the parent > > zone's labels stripped." > > > > I think it would be better to have a text like: "It is also > > possible to publish child-specific records, where instead of the > > wildcard label, a child's FQDN with the parent zone's labels > > stripped, in used." > > Good suggestion, we now have: > > It is also possible to publish child-specific records, where in > place of the wildcard label, the child's FQDN with the parent zone's > labels stripped is used. That's a good replacement of the original text. > > In section 4 the text contains "parent registry", where most of the > > rest of the text uses "parent operator". Is this intentional? I > > would think using "parent operator" everywhere in the document > > would make it better. > > Registry is usually avoided because it is not a DNS term. OTOH, in > Section 4, "operator" doesn't seem right to me, because the zone > operator could be some entity different from the registry, which is > why we used "registry". But you're right, it's an ugly inconsistency. > > We've fixed it by using "parent side" in this section (e.g., "the > child DNS operator generally is unaware of whether the parent side > consumes CDS records or prefers CDNSKEY"). Hope that addresses the > concern! Yes, thank you. > > In section 4.2.1 I wonder why MUST the agent domain be a > > subordinate or equal to one of the NS hostnames? > > Maybe I am missing a good reason why it cannot be just a hostname > > listing for reports. > > I added: > > This is to prevent malicious > senders from causing the NOTIFY recipient to send unsolicited > report queries to unrelated third parties. I thought that would be the reason, I think it makes more clear. > > Section 4.3 (Processing of NOTIFY Messages): > > Would it be useful to add "The report query will be out of bound of > > the NOTIFY query and response sequence" or similar to the section > > that talks about the EDNS0 Report-Channel? > > Fair! We added: > > Reporting may be done > asynchronously (outside of the NOTIFY transaction). Thank you. -- Stefan Ubbink DNS & Systems Engineer Present: Mon, Tue, Wed, Fri SIDN | Meander 501 | 6825 MD | ARNHEM | The Netherlands T +31 (0)26 352 55 00 https://www.sidn.nl
pgpJoNcc8XE2f.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
