Regarding SHALL vs MUST: https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/#:~:text=Use%20%E2%80%9Cmust%E2%80%9D%20not%20%E2%80%9Cshall,express%20a%20requirement%20or%20obligation.
I recognize they have the same meaning within IETF according to https://datatracker.ietf.org/doc/html/rfc2119 Feel free to ignore my comment. On Thu, Jan 18, 2024 at 9:46 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > Hi Jari, > > On Thu, Jan 18, 2024 at 3:43 AM Jari Arkko <jari.ar...@piuha.net> wrote: > >> In short, historical reasons. Dating back to early 2000s, the first >> document in the series was published as an RFC in 2006. At the time it was >> done via AD sponsoring, and EAP-AKA’ support seemed less mainstream than in >> later years :-) >> >> Since then we’ve done updates. Like we still do today. Status updates >> have been occasionally asked about but it has never been as high on the >> priority list as some of the other things, like getting documents published >> or the new features or security considerations added. >> >> I don’t see a huge need to update the status to PS but I also don’t >> object to it. However, if we do upgrade, then let’s make sure that we don’t >> break anything else, change the dependencies or update references, etc. >> > > I agree, and I'm saying here that I'd like us to take the time to do the > right thing rather than dragging out what may have been the wrong thing and > letting it snowball. > > >> > The use of "RECOMMENDED" in Section 7 is peculiar. As prescriptive >> > interoperability or security advice, to whom does it apply? >> >> It was meant as a recommendation from the authors to those who deploy and >> decide configurations, i.e., operators. It is not a code thing, there will >> be no software that is going to follow that recommendation, it would be >> human decision makers. >> >> I see that several people have reacted to this, would plain English work >> better than keywords? >> > > Yes, I think so. > > >> > BCP 26 strongly urges that a Specification Required registry has advice >> for the >> > Designated Experts, but this document contains none. Is there nothing >> to say >> > here? >> >> I think the authors believed this was a straightforward enough case that >> no further guidance would be needed. We can add text although that might be >> relatively generic, e.g., ensure that the referenced specification is >> clearly identified and stable, and that the proposed addition is reasonable >> for the given category of allocation. >> > > I mostly just wanted to ask the question. BCP 26 doesn't require it, but > its absence is often conspicuous, and usually when I ask this, the authors > manage to write something that's more than generic. > > >> The peer identifier SHALL comply >> > with the privacy-friendly requirements of [RFC9190]. >> > >> > ought to be a MUST? >> >> SHALL equals MUST, no? >> > > Yeah, I don't know why Orie said that. :-) > > Thanks, > > -MSK > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
