Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request

From: Avi Lior <[email-masked]>
Date: Sat, 4 Jun 2011 23:28:53 -0400

See inline….

-- Avi Lior
--Bridgewater Systems

On 22-05-11 05:29 , "Bernard Aboba" <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Alan and Stefan:  against allocation.

Alan DeKok said:

> In summary: against allocation.

I agree.

Stefan Winter said;

"In summary: against allocation.

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.
Because the behaviour in WiMAX is different then when the AAA is performing 'normal' WiFi operations.
Anyway you seem to care a lot.

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"

---

From: Stefan Winter <[email-masked]>
Date: Mon, 06 Jun 2011 10:31:55 +0200

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.

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

>     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.
>     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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Jun 2011 10:37:19 +0200

Stefan Winter wrote:
> If it's not, maybe WiMAX should get a new NSA-Port-Type.

  IMHO, the "NSA" port type attribute should encode a zero-width bit
field with fixed value "tapped". :)

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>