Hi, > (me) In detail: My reservations against doing the WiFi > Interworking are the same as in the meeting (i.e. why is "WiMAX > Wifi" different from normal WiFi, which has a NAS-Port-Type > already), but I don't care too much. > > (Avi)Because the behaviour in WiMAX is different then when the AAA is > performing 'normal' WiFi operations. > Anyway you seem to care a lot. I care less about this one value than about all the others I wrote something about in the remainder of my mail. Unfortunately, you didn't respond to these AFAICT. On-topic again: I just don't get what "behaviour is different" means. Is the type of network access being provisioned (i.e. what the user gets after authenticating) compatible to the IEEE 802.11 standard (and/or any of the amendments)? If so, it's WiFi, and WiFi already has a NAS-Port-Type. If it's not, maybe WiMAX should get a new NSA-Port-Type. I think I can guesstimate where the desire for a separate NAS-Port-Type for WiMAX-WiFi would come from, even if the actual network access is plain WiFi. I am (sortof) facing the same desire for my eduroam hotspots: when doing AAA for eduroam, the business logic may be a different one from when doing just-some-other-WiFi on the same NAS. I would be delighted to have an IETF-approved tag "this is *eduroam* WiFi" so I could apply my different business logic depending on whether I want to service an eduroam login, or a something-else login that comes in from the same NAS. Still, that desire is wrong :-) A protocol isn't there to support one particular implementor's internal business logic; its purpose is to make interoperable (cross-organisation) standards. NAS-Port-Type has a clear semantics: an implementation which sees this value can expect the network access type to be IEEE 802.11. If you want to express something more fine-grained than just the NAS-Port-Type, why use the attribute NAS-Port-Type with wrong semantics for it. From a quick look into the draft "RADIUS attributes for IEEE 802 Networks", there are some candidates: Mobility-Domain-Id, Network-Id-Name ? Not sure about the semantics of either, but that document in general looks like a much more natural fit to express what *exact* WiFi properties to expect within the NAS-Port-Type of IEEE-80211. So, I would really call for a litmus test: is the network access being provisioned compatible to IEEE 802.11(a/b/g/n/whatever)? Yes: NAS-Port-Type exists; no new allocation, look into other attributes. No: Consider issuing a new NAS-Port-Type for this. That question is a technical one, and I would hope it has a clear answer :-) Greetings, Stefan > > > For the other types, my feeling is much stronger against > allocation. As per Avi's mail, there are > > - voice service > - DHCP service > - location based service > > The word "service" in these is a brightly blinking indicator that > this is not about a port type, but a service type. So allocating a > NAS-*Port*-Type here just doesn't seem to fit semantically. > > Service Type does not work. I wish it would. But its overloaded. For > example if I want to say Authenticate-Only for Voice Service I would > not be able to do so. > > > > There is also "WiMAX Pre-Release 8 ..." stuff. This would at best > be a temporary thing; when Release 8 is out, this NAS-Port-Type > would just be a burnt integer. I don't think that's right. > > Temporary thing hmmm. > Burnt Integer — seriously. > > > > Leave alone that there are values which are a "function" - what > would that have to do with NAS-Port-Type? > > Seems to me that NAS-Port type IS the way you specify the type of > service connection and hence service the request is about. > > > > Given that all these values are to be registered as a block, and > the majority of the proposed values have a big question mark for > me, I can't help but say No. > > Greetings, > > Stefan Winter" > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Attachment:
signature.asc
Description: OpenPGP digital signature