Hi,
On 9/8/25 16:12, Johan Stenstam wrote:
I would change the SHOULDs in 4.2 and 4.2.1 to MUST unless we can describe
situations where interop would be better if you don't.
I think MUST is too strong and SHOULD is the right emphasis in this case.
If MUST is too strong, when is it OK not to do that? We're telling people how
to interoprate, what should they do?
In 4.2 is it "unless the operator has external knowledge that the endpoint will scan
soon"? In 4.2.1 I can't think of plausible situations where you would do something
else.
[...]> But what if, for reasons we don’t know here, whoever is responsible for
sending notifications is simply unable to verify that the public view is
consistent? Should the sender then NOT send the notification? Or should it delay a
reasonable amount of time before sending? Or delay for a bit, then check again?
How many times? Forever?
I'm with Johan here. That's the reason for the SHOULD, because otherwise
senders who don't know all the secondary locations (which is not a completely
unreasonable scenarios when outsourcing secondaries) would effectively be
precluded from ever sending a notification.
So, I neither see a technical to change this away from what the WG consensus
was, nor a different reason for why the discussion should be re-opened.
Cheers,
Peter
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
