On Thu, Feb 16, 2023 at 6:20 AM Alan DeKok <al...@deployingradius.com> wrote:
> > It is RECOMMENDED that vendor-defined TLS-based EAP methods use the > > above definitions for TLS 1.3. There is no compelling reason to use > > different definitions. > > > > Why isn't this MUST if there's no compelling reason to do otherwise? > > We don't have change control over vendor-defined TLS methods. > You do have control over what's compliant with this specification though. > > In Section 3.1: > > > > In other weds, [...] > > > > I think you meant "words". > > > > The outer identity SHOULD use an anonymous NAI realm. [...] > > > > I suggest you add a sentence or two explaining why an implementer might > > legitimately choose not to do this. > > I'll reference RFC 7542 (NAI), which goes over these issues in detail. > Perhaps: > > The outer identity SHOULD use an anonymous NAI realm, which allows for > both user privacy, and for the EAP session to be routed in an AAA > framework as described in [RFC7542] Section 3. Where NAI realms are > not used, packets will not be routable outside of the local > organization. > Is there any legitimate reason for an implementer to decide to deviate from the SHOULD and still expect to interoperate? The text you're suggesting sounds a lot like a MUST to me. > i.e. follow the recommendation and work with others, or don't follow it > and you're on your own. > So does that. > > This practice is NOT RECOMMENDED. User accounts for an organization > > should be qualified as belonging to that organization, and not to an > > unrelated third party. There is no reason to tie the configuration > > of user systems to public realm routing, that configuration more > > properly belongs in the network. > > > > This formulation is curious; you first give implementers an "out" with > NOT > > RECOMMENDED, and then basically argue that it should be a MUST NOT. I > suggest > > revisiting this pattern anywhere you've used it. If you prefer to keep > it, I > > suggest changing the prose a bit to explain why one might choose to > deviate > > from the advice presented. > > TBH I don't see any valid reasons for deviating from the advice given. > It's more that this document cannot mandate (a) changes from historical > practices defined in previous documents, and (b) what people do in their > own private environment. > > It's really "If you want your systems to work on the Internet, here's > what you do. If you don't care about that, you're on your own. Go figure > it out yourself". > I think this point should be made clear, i.e., that this is only a SHOULD because of backward compatibility with previous documents. In fact, I suggest using "MUST, unless ..." Private environments, I would imagine, are always free to interoperate or not, so I'm not too worried about the (b) case. -MSK
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
