Peter,
Thank you again for your reply and happy to clear my DISCUSS as the blocking
issues are solved in the -08.
About the “should” for sure your example is a good one where explaining the
“bypass consequences” is useless.
Regards
-éric
From: Peter Thomassen <peter=40desec...@dmarc.ietf.org>
Date: Tuesday, 11 March 2025 at 02:56
To: Eric Vyncke (evyncke) <evyn...@cisco.com>, The IESG <i...@ietf.org>
Cc: draft-ietf-dnsop-generalized-not...@ietf.org
<draft-ietf-dnsop-generalized-not...@ietf.org>, dnsop@ietf.org
<dnsop@ietf.org>, tjw.i...@gmail.com <tjw.i...@gmail.com>,
peter.van.d...@powerdns.com <peter.van.d...@powerdns.com>
Subject: Re: [DNSOP] Re: Éric Vyncke's Discuss on
draft-ietf-dnsop-generalized-notify-07: (with DISCUSS and COMMENT)
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
