Hi Andy,
On 5/20/26 15:47, Andy Newton wrote:
> Linked to Andy's DISCUSS, whether this document is BCP or 'informational' is
> also another question. Some BCP-like RFC (e.g., RFC 9099) are informational
and
> do not rely on BCP14, only plain English "should".
I don't see Andy raising a question about the document status.
EV> Andy didn't indeed, I was simply linking this point to the previous one
If the language is to all be SHOULDs or RECOMMENDED, that does raise the
question about why the document isn't just an Informational instead of a BCP.
In my opinion, the Internet is better served with the "enforcement" of a BCP,
and hence why I am asking for many of the SHOULDs to be turned into MUSTs.
Fair. It used to be the case that there were only SHOULDs, which was an editing
error -- defining features of DS automation need to be MUST, of course.
The current revision -08 now contains 5 MUST provisions. Based on the currently
ongoing threads, at least two more are introduced:
- "When implementing these recommendations, operators MUST mitigate issues arising
from any particular deviation."
- "DS update requests MUST be executed at the next publication opportunity after
verification of their authenticity"
... in order for an implementation to claim compliance with this document.
We all agree that at toothless document is not very useful, and that MUSTs are
needed to make things enforceable. OTOH, not all SHOULDs can be must, as the
ecosystem operationally is so diverse that there are many cases where
idiosyncracies can legitimately justify deviation from certain provisions.
So long for now, I have a call coming up. I'll respond to your 13:38 UTC
message in the other thread later.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
