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

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 17 May 2011 14:52:50 +0000

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

Thanks,
Mauricio

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Friday, April 08, 2011 11:31 AM
To: [email-masked]'
Subject: Consensus poll for IANA #409959 NAS-Port-Type value request

During IETF 80 one of the agenda topics discussed was whether to approve a request received by IANA for allocation of additional NAS-port-type values relating to Wimax as described below

Type of Assignment :
Nas-Port-Type 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
TBD for WIMAX- LBS  : WiMAX location based service
TBD for WIMAX-WVS : WiMAX  voice service

The snippet of meeting notes relating to this topic are show below:

---- <meeting note snippet begin>---------------------------

Request for registration for NAS-port-type.  Under 3575, falls under expert review.  This request is for NAS-port-type relating to WiMax
- Stefan comments that there's already type for WiFi so not sure why another one is needed, just one.
- Klaas comments that agrees with Stefan's comments.
- Nancy comments that looking at the current assignment is that there is only 1 allocation per mode.
- Bernard takes the general comment of only allocating one as the response to take back to the request.  Given consensus here, will verify that opinion in the reflector.

---- <meeting note snippet end>---------------------------

The sentiment in the room was clearly against approving this IANA request and at this time we would like to confirm this on the mailing list.

Please respond to this email and state whether you are in favor or against approving this IANA request.

Thanks,
MS

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 17 May 2011 16:17:08 +0000

Adding email from Avi describing expected usage of this new attributes.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Tuesday, May 17, 2011 7:53 AM
To: [email-masked]'
Subject: Final call for consensus poll for IANA #409959 NAS-Port-Type value request

Thanks,
Mauricio

Type of Assignment :

Thanks,
MS

Subject: [IANA #409959] Genreral Request for Assignements
From: Avi Lior <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alper Yegin <[email-masked]>
Date: Tue, 15 Mar 2011 17:39:35 +0000

 Hi Bernard,

Thank you for the review of the NAS-Port-Type IANA request for assignment.  In a previous email you were seeking answers to the following questions:
Bernard wrote:

Can someone answer the following questions?

1. What is different between WiMAX WiFi and normal IEEE 802.11?  We already have a number of IEEE 802.11 NAS-Port-types allocated and have proposed additional data for this.

2. Why do DHCP and a location service need NAS-Port-Type values?

3. Why should we just allocate a generic WiMAX NAS-Port and let additional data be included in a WiMAX Forum VSA?

The general answer to your question is as follows:

For a given session, the WIMAX AAA Server interacts with many different WiMAX network elements and also non-WiMAX network elements.  The approach taken by WiMAX is to have an explicit indication from the NAS as to the context of the RADIUS access-request.  The NAS-Port-Type is viewed as the attribute to provide that information.

WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiFi Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours over and above the "normal" wifi AP.  T

WRT 2) Again, WiMAX AAA needs to differentiate between the request from both these entities because the AAA behaviour is different when request comes from  a DHCP server vs., a Location Based Server.

WRT 3)  WiMAX would just be inventing our own NAS-Port-Type attribute.  We thought the idea is that we reuse attributes when we can. Since there doesn't seem to be a lack of number space associated with NAS-Port-Type there doesn't seem to be a reason to invent our own attribute.

-- Avi Lior
--Bridgewater Systems

---

From: Stefan Winter <[email-masked]>
Date: Wed, 18 May 2011 09:16:41 +0200

Hello,
 
>
> 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 poll. 
>

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

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 May 2011 12:56:52 +0200

> In summary: against allocation.

  I agree.

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 18 May 2011 14:57:50 +0300

Hello,

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.

For 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?

Alper

 

 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Winter
Sent: Wednesday, May 18, 2011 10:17 AM
To: Sanchez, Mauricio (HP Networking)
Cc: [email-masked]'
Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type
value request

Hello,

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

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? 

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 May 2011 10:59:32 +0200

Alper Yegin wrote:
> 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.

  I'm not sure how the second sentence follows from the first.

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

  Then how do we refer to the L1/L2 port?  Or is it even relevant?

  RFC 2865 says:

      An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
      attribute or both unless the type of access being requested does
      not involve a port or the NAS does not distinguish among its
      ports.

  So if the service being offered (Mobile IP) does not involve a port,
then the *standard* RADIUS solution is to not use NAS-Port-Type.
Instead, something else can be used.  Possibly Service-Type, or maybe
another attribute.

  This has been done for ~15 years with administrative logins.  The
administative login request contains "Service-Type = Administrative",
and often *no* NAS-Port-Type.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 23 May 2011 03:54:26 +0300

I think we need to get these question marks discussed before saying no.

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?

Alper

 

 

From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 2:58 PM
To: 'Stefan Winter'; 'Sanchez, Mauricio (HP Networking)'
Cc: [email-masked]'
Subject: RE: Final call for consensus poll for IANA #409959 NAS-Port-Type
value request

Hello,

Alper

 

 

Hello,

- voice service
- DHCP service
- location based service

Greetings,

Stefan Winter