Dear Murray, Got it - I realise I wasn't clear with SHOULD - indeed the implementer has limited discretion on what can happen: send the DISCONNECT, close connection or drop the connection. I will discuss this with Ben but am happy to add the additional text about dropping the connection.
Kind regards, --Cigdem On Thu, 10 Mar 2022 at 15:23, Murray S. Kucherawy <superu...@gmail.com> wrote: > Hi Cigdem, > > On Thu, Mar 10, 2022 at 12:54 AM Cigdem Sengul <cigdem.sen...@gmail.com> > wrote: > >> Thank you for your review. Our thinking was as Ben explained. >> In the draft, we used MUST/MUST NOT for the behaviour that affected >> security, and SHOULD for desired behaviour. >> > > This doesn't match my understanding of how BCP 14 is supposed to be used. > MUST describes something obligatory for either interoperability, security, > or operational reasons, and SHOULD is something where the implementer has > limited discretion; when using SHOULD (or SHOULD NOT), it's desirable to > include text describing when one might legitimately do something other than > what's being stated. > > In this particular case, what I'm reading is paraphrased as: "In this > situation, there's exactly one thing you can legitimately do within this > protocol, and you SHOULD do that." This doesn't make sense to me. What > Ben is saying is that there is a second option, which is to simply close > the connection. If you want to leave this as a SHOULD, I suggest adding > text saying exactly that. > > Would the following revision make it more clear: >> "The Broker MUST NOT forward messages to unauthorized subscribers and >> SHOULD inform them of authorisation failure. >> The only way to inform the client, in this case, would be sending a >> DISCONNECT packet. >> Therefore, the Broker SHOULD send a DISCONNECT packet with the reason >> code '0x87 (Not authorized)'. " >> > > That's also less dissonant, yes. This was just discussed with Ben on the > IESG call and I'll let him guide you on which change is more aligned with > what you're trying to do. > > -MSK >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
