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
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
