Hi Éric,
On 3/7/25 04:46, Eric Vyncke (evyncke) wrote:
See below for EVY> and more comments. In short, the proposed changes address my
current blocking DISCUSS issues :-)
Looking forward for your revised I-D (note that next week I will be away from
keyboard so no urgency for a revised I-D).
Great! Enjoy your vacation. A new revision has been posted a few days ago.
### Section 4.3
Where is a 'valid NOTIFY' defined in `Upon receipt of a (potentially forwarded)
valid NOTIFY(CDS) `?
The previous sentence talks about an invalid case (where a NOTIFY relates to
several domains); it was intended to imply in this sentence that we're now
describing the handling of valid NOTIFYs (i.e., the ones that are not invalid
as previously described).
EVY> So, the only invalid case is when there are more than 1 child zone ? This
was not super clear to be honest and your new text is addressing my concern.
There are other invalid cases, as we build on the RFC 1996 NOTIFY mechanism,
and whatever is declared invalid there is also invalid here. In Section 4, we
reference this:
NOTIFY messages for delegation maintenance MUST be formatted as
described in [RFC1996], with the qtype field replaced as appropriate.
So, I think we do not need to enumerate all conceivable format errors here.
(The case of having multiple domains listed in the NOTIFY is mentioned
explicitly because it could be tempting to think that that would work.)
### Section 2.3
All text is normative in a PS, but why not stressing the "should" by using a
"SHOULD" in `message should be sent to the address and port listed` ?
Please explain also why some DNS servers could bypass this "should".
Only uppercase keywords are to be interpreted as described in BCP 14. The "should" here
expresses the parent's intention, and is not a normative statement. ("We publish a DSYNC
record which child operators should use to nudge us to update the delegation.")
We therefore don't think it should (haha) be uppercase, nor does it need to be
explained when it can be bypassed.
EVY> beside the smile above ;-) all the text is really normative, i.e., the
“should” should (aha ;-) ) have some bypass explanations.
I don't agree with that. As a more obvious example, if the introduction said that "according
to a survey, domain owners think that DNSSEC configuration should be less of a hassle", I have
a very hard time convincing myself that this "should" is normative and needs to be
capitalized; I also don't think it would need an explanation of when it doesn't apply, even though
it appears in a PS document.
The point is that it isn't behavior specification, but closer to indirect speech. That's
similar to the case at hand ("The parent publishes a notification endpoint via DSYNC
record to indicate that [they think that] child operators should nudge them when there's
something to do.")
T'is just for the record; it doesn't matter because we have new text below that
you said avoids the problem.
EVY> the proposed new text avoids the problem, so all is good
Due to a race condition between the submission and processing your response, it
hadn't been included. I've updated my local copy so it's included in the next
iteration.
Thanks,
Peter + co-authors
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
