> 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.
I think we need to get these question marks discussed before
Historically, the NAS-port-type is associated with the L1/L2
port over which the “access” service is provided. But with the new
use of RADIUS, this view is no longer applicable. Again, consider a Mobile IP
Home Agent node implementing RADIUS client for AAAing the MN’s
registration requests. The L1/L2 port that receives the MN registration request
has no significance, and it can be one of many types. Here, our thinking is,
the “logical” port is the “Mobile IP Home Agent”, and
that has nothing to do with the L1/L2 port.
What do people think?
From: Alper Yegin
Sent: Wednesday, May 18, 2011 2:58 PM
To: 'Stefan Winter'; 'Sanchez, Mauricio (HP Networking)'
Subject: RE: Final call for consensus poll for IANA #409959
NAS-Port-Type value request
I see the choice of terminology is causing trouble. The
terminology is coming from WMF, and it may not very well align with the ones
used in IETF.
WIMAX-HA-LMA: WiMAX HA and or LMA function.
example, this one above is for defining the interface between the Mobile IP HA
and the AAA server for AAAing Mobile IP service. With that explanation, does it
still not qualify for a NAS-port-type?
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Stefan Winter
Sent: Wednesday, May 18, 2011 10:17 AM
To: Sanchez, Mauricio (HP Networking)
Subject: Re: Final call for consensus poll for IANA #409959
NAS-Port-Type value request
At this time we find ourselves with a mixed result
between the in room sentiment at IETF 80 (which was negative to allocation) and
the subsequent consensus poll (which was neutral/positive to
allocation). As such, a final consensus poll is warranted to
establish rough consensus in either direction.
Please respond to this email by May 24, 2011 with either
a ‘yes’ (indicating allocation should occur) or a
‘no’ (indicating allocation should be denied). Please respond
regardless of whether you commented at IETF 80 or to the below consensus
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.
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.
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.
Leave alone that there are values which are a "function" - what would
that have to do with NAS-Port-Type?
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
values as follows:
TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function
TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking
TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2.
TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function.
TBD for WIMAX-DHCP : WIMAX DCHP service
for WIMAX- LBS : WiMAX location based service
TBD for WIMAX-WVS : WiMAX voice service