Hi all,
I approve the change in Appendix A.2.
As I m’ there, please find below some few nits I tagged when reviewing the
document:
* 1.1: nit
OLD:
This suggests that the lookup process be ignorant
of the details of the parent-side relationships (e.g., whether or not
there is a registrar.) This is addressed by parameterizing the
^^^^
NEW:
This suggests that the lookup process be ignorant
of the details of the parent-side relationships (e.g., whether or not
there is a registrar). This is addressed by parameterizing the
* “may optionally” is redundant. I suggest to drop “optionally” in the
following:
CURRENT:
The parent operator may then
(optionally) announce the notification endpoint in a delegation-
and
A scheme number may optionally have exactly one
mnemonic.
* 1.1: this is a PS
OLD: The solution proposed here
NEW: The solution specified here
* Section 2.1
(1)
Please add a caption/legend for the figure as this helps/eases external
referencing:
NEW:
Figure 1: DSYNC RDATA Wire Format
(2) Add a reference to the registry for the readers’ convenience:
CURRENT:
RRtype: The type of generalized NOTIFY that this DSYNC RR defines
the desired target address for (see the "Resource Record (RR)
TYPEs" registry).
Registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
(3) Point to where future values are maintained. The authoritative source is
the registry not the subset of values frozen in this description.
OLD:
Value 1 is described in
this document, and values 128-255 are Reserved for Private Use.
All other values are currently unassigned.
NEW:
Value 1 is described in
this document, and values 128-255 are Reserved for Private Use.
Other values are currently unassigned. Future assignments are
maintained the registry created in Section 6.2.
(4) Transport port number
OLD
Port: The port on the target host of the notification service.
NEW:
Port: The transport port number on the target host of the notification
service.
* Section 2.3
The address is not listed as such in the record. I suggest the following or
similar chane:
OLD:
address and port listed in that DSYNC record and using conventional
DNS transport [RFC1035].
NEW:
address and port number that corresponds to that DSYNC record and using
conventional
DNS transport [RFC1035].
* Section 4.2
The discovery is discussed in the previous sub-section, not the previous
section (i.e., section 3).
OLD:
the endpoints discovered as described in the previous section.
NEW:
the endpoints discovered as described in Section 4.1.
* Section 4.3
EDE is already introduced 4.2.1
OLD:
processing by sending a report query with an appropriate extended
DNS error (EDE) code
NEW :
processing by sending a report query with an appropriate
EDE code
Cheers,
Med
De : Warren Kumari <[email protected]>
Envoyé : jeudi 11 septembre 2025 23:57
À : Sarah Tarrant <[email protected]>
Cc : John R Levine <[email protected]>; Johan Stenstam
<[email protected]>; Peter Thomassen
<[email protected]>; RFC System <[email protected]>;
DNSOP ADs <[email protected]>; dnsop-chairs <[email protected]>; Tim
Wicinski <[email protected]>; auth48archive <[email protected]>;
Oli Schacher <[email protected]>
Objet : Re: [AD] AUTH48: RFC-to-be 9859
<draft-ietf-dnsop-generalized-notify-09> for your review
Hi there,
Warren has no authority here anymore - I'd suggest that Med should be
substituted.
W
On Thu, Sep 11, 2025 at 4:51 PM, Sarah Tarrant
<[email protected]<mailto:[email protected]>> wrote:
Hi John, Johan, Peter, and *Warren,
*AD review - Warren - Regarding the following nit from Peter:
Appendix A.2
OLD (current, after RFC editing)
[DNSSEC-AUTO]
NEW
[RFC8901]
(Rationale: the DNSSEC-AUTO draft was anticipated to be published before this
but was not; the currently correct informative reference therefore is RFC 8901.)
Please review the informative reference update and let us know if this change
is approved:
Removed: I-D.ietf-dnsop-dnssec-automation
Replaced with: RFC 8901 (which was already an informative reference)
Best viewed at:
https://www.rfc-editor.org/authors/rfc9859-auth48diff.html
https://www.rfc-editor.org/authors/rfc9859-auth48rfcdiff.html
-------------------------------------------------------------
Peter, John, and Johan - Thank you for your replies. We have updated the
document accordingly and have marked your approval on the AUTH48 status page
for this document (see https://www.rfc-editor.org/auth48/rfc9589).
We will await Warren's approval prior to moving this document forward in the
publication process.
The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9859.txt
https://www.rfc-editor.org/authors/rfc9859.pdf
https://www.rfc-editor.org/authors/rfc9859.html
https://www.rfc-editor.org/authors/rfc9859.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9859-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9859-auth48diff.html (AUTH48 changes only)
Note that it may be necessary for you to refresh your browser to view the most
recent version.
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9859
Thank you,
Sarah Tarrant
RFC Production Center
On Sep 11, 2025, at 5:28 AM, Johan Stenstam
<[email protected]<mailto:[email protected]>>
wrote:
Hi Sarah,
A) FYI, regarding:
We updated "native" to "built-in" and "traditional" to "original". Please
verify.
I approve this change.
B) Regarding:
Current:
Therefore, it is RECOMMENDED that the child delay sending
notifications to the recipient until a consistent public view of the
pertinent records is ensured.
Perhaps:
Therefore, it is RECOMMENDED that the child would delay sending
notifications to the recipient until a consistent public view of the
pertinent records could be ensured.
I approve this change.
Please review the document carefully to ensure satisfaction as we do not make
changes once it has been published as an RFC.
For a clear record, please send approvals after viewing the document in its
current form.
The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9859.txt
https://www.rfc-editor.org/authors/rfc9859.pdf
https://www.rfc-editor.org/authors/rfc9859.html
https://www.rfc-editor.org/authors/rfc9859.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9859-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9859-auth48diff.html (AUTH48 changes only)
I have reviewed the entire updated document and have no objections. That said,
I do agree with Peter that his suggested change would be an improvement (but it
is not a show-stopper):
CURRENT
For example, when receiving a NOTIFY(CDS) message for
"example.com<http://example.com/>"
with agent domain "errors.ns1.example.net<http://errors.ns1.example.net/>", and
when the requested DS
update is found to break the delegation, then the following report
query may be made (preferably over TCP):
NEW
For example, when receiving a NOTIFY(CDS) message for
"example.com<http://example.com/>"
with agent domain "errors.ns1.example.net<http://errors.ns1.example.net/>", and
when the requested DS
update is found to break the delegation, then the following report
query with EDE code 6 (DNSSEC Bogus) may be made, preferably over TCP:
Regards,
Johan Stenstam
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
