[radext] #99: AD Review of RADIUS Crypto-Agility Requirements

["radext issue tracker" <[e-mail]>]

#99: AD Review of RADIUS Crypto-Agility Requirements

 Hi,

 This is the AD review of
 draft-ietf-radext-crypto-agility-requirements-06.txt. The document is in
 good shape. Because of the relative broad applicability and security
 impact of the document, I will send it to IETF Last Call, although as a
 WG document targetting Informational status this would not have been
 mandatory. I have a number of comments and questions which I request to
 be taken into consideration together with the other IETF LC comments.

 The technical comments are marked T and the Editorial comments are
 marked E.

 T1. I am a little concerned by the fact that the second paragraph of
 section 1.2 speaks in terms of 'compliance', 'unconditional compliance'
 and 'conditional compliance' with 'this specification' which is actually
 an Informational document. Is this really needed? We tend to avoid such
 strict language in IETF documents.

 T2. In section 4.2 I see the following:

    Guidance on acceptable algorithms can be found in [NIST-SP800-131A];
    it is RECOMMENDED that mandatory-to-implement cryptographic
    algorithms be chosen from among those classified as "Acceptable" with
    no known deprecation date.

 I acknowledge that the NIST document is rather new, but such documents
 have a timely nature by definition and may change faster than we want
 this RFC to change. I would suggest to include at least a note saying
 that if [NIST-SP800-131A] its successors need to be taken as reference.
 Or, if we do not want to assume the risk of a blank check we should
 observe that this recommendation is valid at the time of the publication
 of this document.

 T3. Also in section 4.2 I see the following:

    In addition to the goals referred to above, [RFC4962] Section 2
    describes additional security requirements, which translate into the
    following requirements for RADIUS crypto-agility solutions:

 It may be my understanding but I could not find in section 2 of
 [RFC4962] the requirements that translate into 'strong, fresh, session
 key' and 'Limit key scope'. Can you explain me what I am missing?


 E1. Idnits complains:

   == You're using the IETF Trust Provisions' Section 6.b License Notice
 from
      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
      http://trustee.ietf.org/license-info/)

 E2. I am wondering what the scope of section 1.3 is. Maybe it's my
 English, but why is the section named 'The Charge'? Do you mean 'Scope'?
 It looks to me that dropping this section or making it (or a shorter
 version) part of Section 1.4 as background information would be better.

 E3. Page 5, second paragraph s/can selected/can be selected/

 Thanks and Regards,

 Dan

-- 
-----------------------------------+----------------------------------------
 Reporter:  dromasca@…             |       Owner:            
     Type:  defect                 |      Status:  new       
 Priority:  major                  |   Milestone:  milestone1
Component:  Crypto-Agility         |     Version:  1.0       
 Severity:  Submitted WG Document  |    Keywords:            
-----------------------------------+----------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/99>
radext <http://tools.ietf.org/radext/>


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

Envelope-to: [e-mail]
Delivery-date: Tue, 31 May 2011 17:48:48 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_55761cc7-1773-4e04-b789-710905b549e7_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: AD review of draft-ietf-radext-crypto-agility-requirements-06.txt
Date: Tue, 31 May 2011 10:47:52 -0700
MIME-Version: 1.0

--_55761cc7-1773-4e04-b789-710905b549e7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> T1. I am a little concerned by the fact that the second paragraph of
> section 1.2 speaks in terms of 'compliance'=2C 'unconditional compliance'
> and 'conditional compliance' with 'this specification' which is actually
> an Informational document. Is this really needed? We tend to avoid such
> strict language in IETF documents.=20

[BA] This language appears to be boilerplate in AAA requirements RFCs and B=
CPs (see RFC 2989 Section 1.1=2C RFC 4962 Section 1.1=2C etc.)
=20
> T3. Also in section 4.2 I see the following:=20
>=20
>    In addition to the goals referred to above=2C [RFC4962] Section 2
>    describes additional security requirements=2C which translate into the
>    following requirements for RADIUS crypto-agility solutions:
>=20
> It may be my understanding but I could not find in section 2 of
> [RFC4962] the requirements that translate into 'strong=2C fresh=2C sessio=
n
> key' and 'Limit key scope'. Can you explain me what I am missing?=20

[BA] Looks like a typo -- should this refer to Section 3?


 		 	   		  =

--_55761cc7-1773-4e04-b789-710905b549e7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
<br>&gt=3B T1. I am a little concerned by the fact that the second paragrap=
h of<br>&gt=3B section 1.2 speaks in terms of 'compliance'=2C 'unconditiona=
l compliance'<br>&gt=3B and 'conditional compliance' with 'this specificati=
on' which is actually<br>&gt=3B an Informational document. Is this really n=
eeded? We tend to avoid such<br>&gt=3B strict language in IETF documents. <=
br><br>[BA] This language appears to be boilerplate in AAA requirements RFC=
s and BCPs (see RFC 2989 Section 1.1=2C RFC 4962 Section 1.1=2C etc.)<br>&n=
bsp=3B<br>&gt=3B T3. Also in section 4.2 I see the following: <br>&gt=3B <b=
r>&gt=3B    In addition to the goals referred to above=2C [RFC4962] Section=
 2<br>&gt=3B    describes additional security requirements=2C which transla=
te into the<br>&gt=3B    following requirements for RADIUS crypto-agility s=
olutions:<br>&gt=3B <br>&gt=3B It may be my understanding but I could not f=
ind in section 2 of<br>&gt=3B [RFC4962] the requirements that translate int=
o 'strong=2C fresh=2C session<br>&gt=3B key' and 'Limit key scope'. Can you=
 explain me what I am missing? <br><br>[BA] Looks like a typo -- should thi=
s refer to Section 3?<br><br><br> 		 	   		  </body>
</html>=

--_55761cc7-1773-4e04-b789-710905b549e7_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 31 May 2011 15:15:55 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Subject: Last Call: <draft-ietf-radext-crypto-agility-requirements-06.txt> (Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)) to Informational RFC
CC: <[e-mail]>
Reply-To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 31 May 2011 08:15:18 -0700

The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)'
  <draft-ietf-radext-crypto-agility-requirements-06.txt> as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[e-mail] mailing lists by 2011-06-14. Exceptionally, comments may be
sent to [e-mail] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-crypto-agility-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-crypto-agility-requirements/


No IPR declarations have been submitted directly on this I-D.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 31 May 2011 14:23:49 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AD review of draft-ietf-radext-crypto-agility-requirements-06.txt
Date: Tue, 31 May 2011 16:20:59 +0200
Message-ID: <[e-mail]>
Thread-Topic: AD review of draft-ietf-radext-crypto-agility-requirements-06.txt
Thread-Index: AcwfnfbiXoVuHvf9SGKKcyufKR9JBQ==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "radext mailing list" <[e-mail]>

Hi,=20

This is the AD review of
draft-ietf-radext-crypto-agility-requirements-06.txt. The document is in
good shape. Because of the relative broad applicability and security
impact of the document, I will send it to IETF Last Call, although as a
WG document targetting Informational status this would not have been
mandatory. I have a number of comments and questions which I request to
be taken into consideration together with the other IETF LC comments.=20

The technical comments are marked T and the Editorial comments are
marked E.=20

T1. I am a little concerned by the fact that the second paragraph of
section 1.2 speaks in terms of 'compliance', 'unconditional compliance'
and 'conditional compliance' with 'this specification' which is actually
an Informational document. Is this really needed? We tend to avoid such
strict language in IETF documents.=20

T2. In section 4.2 I see the following:

   Guidance on acceptable algorithms can be found in [NIST-SP800-131A];
   it is RECOMMENDED that mandatory-to-implement cryptographic
   algorithms be chosen from among those classified as "Acceptable" with
   no known deprecation date.=20

I acknowledge that the NIST document is rather new, but such documents
have a timely nature by definition and may change faster than we want
this RFC to change. I would suggest to include at least a note saying
that if [NIST-SP800-131A] its successors need to be taken as reference.
Or, if we do not want to assume the risk of a blank check we should
observe that this recommendation is valid at the time of the publication
of this document.=20

T3. Also in section 4.2 I see the following:=20

   In addition to the goals referred to above, [RFC4962] Section 2
   describes additional security requirements, which translate into the
   following requirements for RADIUS crypto-agility solutions:

It may be my understanding but I could not find in section 2 of
[RFC4962] the requirements that translate into 'strong, fresh, session
key' and 'Limit key scope'. Can you explain me what I am missing?=20


E1. Idnits complains:=20

  =3D=3D You're using the IETF Trust Provisions' Section 6.b License =
Notice
from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

E2. I am wondering what the scope of section 1.3 is. Maybe it's my
English, but why is the section named 'The Charge'? Do you mean 'Scope'?
It looks to me that dropping this section or making it (or a shorter
version) part of Section 1.4 as background information would be better.=20

E3. Page 5, second paragraph s/can selected/can be selected/

Thanks and Regards,

Dan=20


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


Envelope-to: [e-mail]
Delivery-date: Mon, 23 May 2011 09:00:27 +0000
Message-ID: <[e-mail]>
Date: Mon, 23 May 2011 10:59:32 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Alper Yegin <[e-mail]>
CC: 'Stefan Winter' <[e-mail]>,  "'Sanchez, Mauricio \(HP Networking\)'" <[e-mail]>, [e-mail]
Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 23 May 2011 00:55:59 +0000
From: "Alper Yegin" <[e-mail]>
To: "'Alper Yegin'" <[e-mail]>, "'Stefan Winter'" <[e-mail]>, "'Sanchez, Mauricio \(HP Networking\)'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Date: Mon, 23 May 2011 03:54:26 +0300
Message-ID: <001201cc18e3$faf75de0$f0e619a0$@[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CC18FD.204495E0"
Thread-Index: AcwVK+qQQhIZi151TGKm8fHGMqZxgQAJg9gQAORO2dA=
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0013_01CC18FD.204495E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> 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 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:[e-mail]] 
Sent: Wednesday, May 18, 2011 2:58 PM
To: 'Stefan Winter'; 'Sanchez, Mauricio (HP Networking)'
Cc: '[e-mail]'
Subject: RE: Final call for consensus poll for IANA #409959 NAS-Port-Type
value request

 

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.

TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   function.

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Winter
Sent: Wednesday, May 18, 2011 10:17 AM
To: Sanchez, Mauricio (HP Networking)
Cc: '[e-mail]'
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 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



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

 

 


------=_NextPart_000_0013_01CC18FD.204495E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&gt; </span>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.<br>
<br>
<span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think we need to get these question marks discussed =
before
saying no.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Historically, the NAS-port-type is associated with the =
L1/L2
port over which the &#8220;access&#8221; 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&#8217;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 &#8220;logical&#8221; port is the &#8220;Mobile IP Home =
Agent&#8221;, and
that has nothing to do with the L1/L2 port.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>What do people think?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Alper<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'> Alper Yegin
[mailto:[e-mail]] <br>
<b>Sent:</b> Wednesday, May 18, 2011 2:58 PM<br>
<b>To:</b> 'Stefan Winter'; 'Sanchez, Mauricio (HP Networking)'<br>
<b>Cc:</b> '[e-mail]'<br>
<b>Subject:</b> RE: Final call for consensus poll for IANA #409959
NAS-Port-Type value request<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hello,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'>TBD for
WIMAX-HA-LMA: &nbsp;WiMAX HA and or =
LMA&nbsp;&nbsp;&nbsp;function.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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?<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Alper<o:p></=
o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p>&nbsp;<=
/o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p>&nbsp;<=
/o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'> [e-mail] =
[mailto:[e-mail]]
<b>On Behalf Of </b>Stefan Winter<br>
<b>Sent:</b> Wednesday, May 18, 2011 10:17 AM<br>
<b>To:</b> Sanchez, Mauricio (HP Networking)<br>
<b>Cc:</b> '[e-mail]'<br>
<b>Subject:</b> Re: Final call for consensus poll for IANA #409959
NAS-Port-Type value request<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Hello,<br>
&nbsp; <o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>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).&nbsp;&nbsp; As such, a final consensus poll is warranted to
establish rough consensus in either direction. =
&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>Please respond to this email by May 24, 2011 =
with either
a &#8216;yes&#8217;&nbsp; (indicating allocation should occur) or a
&#8216;no&#8217; (indicating allocation should be denied).&nbsp; Please =
respond
regardless of whether you commented at IETF 80 or to the below consensus
poll.&nbsp; </span><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
In summary: against allocation.<br>
<br>
In detail: My reservations against doing the WiFi Interworking are the =
same as
in the meeting (i.e. why is &quot;WiMAX Wifi&quot; different from normal =
WiFi,
which has a NAS-Port-Type already), but I don't care too much.<br>
<br>
For the other types, my feeling is much stronger against allocation. As =
per
Avi's mail, there are<br>
<br>
- voice service<br>
- DHCP service<br>
- location based service<br>
<br>
The word &quot;service&quot; 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.<br>
<br>
There is also &quot;WiMAX Pre-Release 8 ...&quot; 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. <br>
<br>
Leave alone that there are values which are a &quot;function&quot; - =
what would
that have to do with NAS-Port-Type? <br>
<br>
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.<br>
<br>
Greetings,<br>
<br>
Stefan Winter<br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Nas-Port-Typ=
e
values as follows:<br>
TBD for WIMAX-3GPP-PRIF:&nbsp;&nbsp;WiMAX Pre-Release 8 IWK Function<br>
TBD for WIMAX-WIFI-IWK: &nbsp;WiMAX &nbsp;&nbsp;WIFI Interworking<br>
TBD for WIMAX-SFF: Signaling Forwarding Function&nbsp;&nbsp;for =
LTE/3GPP2.<br>
TBD for WIMAX-HA-LMA: &nbsp;WiMAX HA and or =
LMA&nbsp;&nbsp;&nbsp;function.<br>
TBD for WIMAX-DHCP : WIMAX DCHP service<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>TBD
for WIMAX-&nbsp;LBS &nbsp;: WiMAX location based service<br>
TBD for WIMAX-WVS : WiMAX&nbsp;&nbsp;voice service<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0013_01CC18FD.204495E0--


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


Envelope-to: [e-mail]
Delivery-date: Sat, 21 May 2011 21:31:19 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_3e21d07d-89e5-4607-add6-affec974e9de_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Date: Sat, 21 May 2011 14:29:54 -0700
MIME-Version: 1.0

--_3e21d07d-89e5-4607-add6-affec974e9de_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I agree with Alan and Stefan:  against allocation.=20

Alan DeKok said:

> In summary: against allocation.


I agree.

Stefan Winter said=3B

"In summary: against allocation.

   =20

    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=2C which has a NAS-Port-Type already)=2C but I don't care
    too much.

   =20

    For the other types=2C my feeling is much stronger against allocation.
    As per Avi's mail=2C there are

   =20

    - voice service

    - DHCP service

    - location based service

   =20

    The word "service" in these is a brightly blinking indicator that
    this is not about a port type=2C but a service type. So allocating a
    NAS-*Port*-Type here just doesn't seem to fit semantically.

   =20

    There is also "WiMAX Pre-Release 8 ..." stuff. This would at best be
    a temporary thing=3B when Release 8 is out=2C this NAS-Port-Type would
    just be a burnt integer. I don't think that's right.=20

   =20

    Leave alone that there are values which are a "function" - what
    would that have to do with NAS-Port-Type?=20

   =20

    Given that all these values are to be registered as a block=2C and the
    majority of the proposed values have a big question mark for me=2C I
    can't help but say No.

   =20

    Greetings=2C

   =20

    Stefan Winter"

   =20
 		 	   		  =

--_3e21d07d-89e5-4607-add6-affec974e9de_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
I agree with Alan and Stefan:&nbsp=3B against allocation. <br><br>Alan DeKo=
k said:<br><br>&gt=3B In summary: against allocation.
<br><br>I agree.<br><br>Stefan Winter said=3B<br><br><font style=3D"" color=
=3D"#000000">"In summary: against allocation.<br>
    <br>
    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=2C which has a NAS-Port-Type already)=2C but I don't care
    too much.<br>
    <br>
    For the other types=2C my feeling is much stronger against allocation.
    As per Avi's mail=2C there are<br>
    <br>
    - voice service<br>
    - DHCP service<br>
    - location based service<br>
    <br>
    The word "service" in these is a brightly blinking indicator that
    this is not about a port type=2C but a service type. So allocating a
    NAS-*Port*-Type here just doesn't seem to fit semantically.<br>
    <br>
    There is also "WiMAX Pre-Release 8 ..." stuff. This would at best be
    a temporary thing=3B when Release 8 is out=2C this NAS-Port-Type would
    just be a burnt integer. I don't think that's right. <br>
    <br>
    Leave alone that there are values which are a "function" - what
    would that have to do with NAS-Port-Type? <br>
    <br>
    Given that all these values are to be registered as a block=2C and the
    majority of the proposed values have a big question mark for me=2C I
    can't help but say No.<br>
    <br>
    Greetings=2C<br>
    <br>
    Stefan Winter"<br>
    </font><br> 		 	   		  </body>
</html>=

--_3e21d07d-89e5-4607-add6-affec974e9de_--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 18 May 2011 11:58:54 +0000
From: "Alper Yegin" <[e-mail]>
To: "'Stefan Winter'" <[e-mail]>, "'Sanchez, Mauricio \(HP Networking\)'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Date: Wed, 18 May 2011 14:57:50 +0300
Message-ID: <002c01cc1552$d42f6840$7c8e38c0$@[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CC156B.F97CA040"
Thread-Index: AcwVK+qQQhIZi151TGKm8fHGMqZxgQAJg9gQ
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_002D_01CC156B.F97CA040
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.

TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   function.



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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Winter
Sent: Wednesday, May 18, 2011 10:17 AM
To: Sanchez, Mauricio (HP Networking)
Cc: '[e-mail]'
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 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




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

 

 


------=_NextPart_000_002D_01CC156B.F97CA040
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hello,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>TBD
for WIMAX-HA-LMA: &nbsp;WiMAX HA and or =
LMA&nbsp;&nbsp;&nbsp;function.<br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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?<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Alper<o:p></=
o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p>&nbsp;<=
/o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p>&nbsp;<=
/o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan =
Winter<br>
<b>Sent:</b> Wednesday, May 18, 2011 10:17 AM<br>
<b>To:</b> Sanchez, Mauricio (HP Networking)<br>
<b>Cc:</b> '[e-mail]'<br>
<b>Subject:</b> Re: Final call for consensus poll for IANA #409959
NAS-Port-Type value request<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Hello,<br>
&nbsp; <o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>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).&nbsp;&nbsp; As such, a final consensus poll is warranted to
establish rough consensus in either direction. =
&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'color:#1F497D'>Please respond to this email by May 24, 2011 =
with either
a &#8216;yes&#8217;&nbsp; (indicating allocation should occur) or a
&#8216;no&#8217; (indicating allocation should be denied).&nbsp; Please =
respond
regardless of whether you commented at IETF 80 or to the below consensus
poll.&nbsp; </span><o:p></o:p></p>

</div>

<p class=3DMsoNormal><br>
In summary: against allocation.<br>
<br>
In detail: My reservations against doing the WiFi Interworking are the =
same as
in the meeting (i.e. why is &quot;WiMAX Wifi&quot; different from normal =
WiFi,
which has a NAS-Port-Type already), but I don't care too much.<br>
<br>
For the other types, my feeling is much stronger against allocation. As =
per
Avi's mail, there are<br>
<br>
- voice service<br>
- DHCP service<br>
- location based service<br>
<br>
The word &quot;service&quot; 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.<br>
<br>
There is also &quot;WiMAX Pre-Release 8 ...&quot; 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. <br>
<br>
Leave alone that there are values which are a &quot;function&quot; - =
what would
that have to do with NAS-Port-Type? <br>
<br>
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.<br>
<br>
Greetings,<br>
<br>
Stefan Winter<br>
<br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Nas-Port-Typ=
e
values as follows:<br>
TBD for WIMAX-3GPP-PRIF:&nbsp;&nbsp;WiMAX Pre-Release 8 IWK Function<br>
TBD for WIMAX-WIFI-IWK: &nbsp;WiMAX &nbsp;&nbsp;WIFI Interworking<br>
TBD for WIMAX-SFF: Signaling Forwarding Function&nbsp;&nbsp;for =
LTE/3GPP2.<br>
TBD for WIMAX-HA-LMA: &nbsp;WiMAX HA and or =
LMA&nbsp;&nbsp;&nbsp;function.<br>
TBD for WIMAX-DHCP : WIMAX DCHP service<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>TBD
for WIMAX-&nbsp;LBS &nbsp;: WiMAX location based service<br>
TBD for WIMAX-WVS : WiMAX&nbsp;&nbsp;voice service<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_002D_01CC156B.F97CA040--


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


Envelope-to: [e-mail]
Delivery-date: Wed, 18 May 2011 10:57:59 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 May 2011 12:56:52 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
CC: "Sanchez, Mauricio (HP Networking)" <[e-mail]>,  "'[e-mail]'" <[e-mail]>
Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stefan Winter wrote:
> In summary: against allocation.

  I agree.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 18 May 2011 07:17:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 May 2011 09:16:41 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Sanchez, Mauricio (HP Networking)" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request
Content-Type: multipart/alternative; boundary="------------060000060907050905000106"

This is a multi-part message in MIME format.
--------------060000060907050905000106
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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


--------------060000060907050905000106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hello,<br>
    <o:p>&nbsp;</o:p>
    <blockquote
cite="mid:[e-mail]"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">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).&nbsp;&nbsp; As such, a final
            consensus poll is warranted to establish rough consensus in
            either direction. &nbsp;<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Please
            respond to this email by May 24, 2011 with either a &#8216;yes&#8217;&nbsp;
            (indicating allocation should occur) or a &#8216;no&#8217; (indicating
            allocation should be denied).&nbsp; Please respond regardless of
            whether you commented at IETF 80 or to the below consensus
            poll.&nbsp; </span><br>
        </p>
      </div>
    </blockquote>
    <br>
    In summary: against allocation.<br>
    <br>
    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.<br>
    <br>
    For the other types, my feeling is much stronger against allocation.
    As per Avi's mail, there are<br>
    <br>
    - voice service<br>
    - DHCP service<br>
    - location based service<br>
    <br>
    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.<br>
    <br>
    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. <br>
    <br>
    Leave alone that there are values which are a "function" - what
    would that have to do with NAS-Port-Type? <br>
    <br>
    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.<br>
    <br>
    Greetings,<br>
    <br>
    Stefan Winter<br>
    <br>
    <blockquote
cite="mid:[e-mail]"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal">Nas-Port-Type values as follows:<br>
          TBD for WIMAX-3GPP-PRIF:&nbsp;&nbsp;WiMAX Pre-Release 8 IWK Function<br>
          TBD for WIMAX-WIFI-IWK: &nbsp;WiMAX &nbsp;&nbsp;WIFI Interworking<br>
          TBD for WIMAX-SFF: Signaling Forwarding Function&nbsp;&nbsp;for
          LTE/3GPP2.<br>
          TBD for WIMAX-HA-LMA: &nbsp;WiMAX HA and or LMA&nbsp;&nbsp;&nbsp;function.<br>
          TBD for WIMAX-DHCP : WIMAX DCHP service<o:p></o:p></p>
        <p class="MsoNormal">TBD for WIMAX-&nbsp;LBS &nbsp;: WiMAX location based
          service<br>
          TBD for WIMAX-WVS : WiMAX&nbsp;&nbsp;voice service<o:p></o:p></p>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------060000060907050905000106--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 17 May 2011 16:19:31 +0000
From: "Sanchez, Mauricio (HP Networking)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 17 May 2011 16:17:08 +0000
Subject: RE: Final call for consensus poll for IANA #409959 NAS-Port-Type value request 
Thread-Topic: Final call for consensus poll for IANA #409959 NAS-Port-Type value request 
Thread-Index: AcwUoY87yOeEstuvSo6vISljQJ5ggQADC95g
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_004_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_"
MIME-Version: 1.0

--_004_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_
Content-Type: multipart/alternative;
	boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_"

--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Tuesday, May 17, 2011 7:53 AM
To: '[e-mail]'
Subject: 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 sent=
iment at IETF 80 (which was negative to allocation) and the subsequent cons=
ensus poll (which was neutral/positive to allocation).   As such, a final c=
onsensus poll is warranted to establish rough consensus in either direction=
.

Please respond to this email by May 24, 2011 with either a 'yes'  (indicati=
ng allocation should occur) or a 'no' (indicating allocation should be deni=
ed).  Please respond regardless of whether you commented at IETF 80 or to t=
he below consensus poll.

Thanks,
Mauricio


From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Friday, April 08, 2011 11:31 AM
To: '[e-mail]'
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 anothe=
r 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 on=
ly 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 opinio=
n in the reflector.

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

The sentiment in the room was clearly against approving this IANA request a=
nd 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


--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c=
olor:#1F497D'>Adding email from Avi describing expected usage of this new a=
ttributes.&nbsp; <o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'=
color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style=3D'border:none;b=
order-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNorm=
al><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Fr=
om:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-se=
rif"'> [e-mail] [mailto:[e-mail]] <=
b>On Behalf Of </b>Sanchez, Mauricio (HP Networking)<br><b>Sent:</b> Tuesda=
y, May 17, 2011 7:53 AM<br><b>To:</b> '[e-mail]'<br><b>Subjec=
t:</b> Final call for consensus poll for IANA #409959 NAS-Port-Type value r=
equest <o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</=
o:p></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>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 (whic=
h was neutral/positive to allocation).&nbsp;&nbsp; As such, a final consens=
us poll is warranted to establish rough consensus in either direction. &nbs=
p;<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>=
<o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F49=
7D'>Please respond to this email by May 24, 2011 with either a &#8216;yes&#=
8217;&nbsp; (indicating allocation should occur) or a &#8216;no&#8217; (ind=
icating allocation should be denied).&nbsp; Please respond regardless of wh=
ether you commented at IETF 80 or to the below consensus poll. &nbsp;<o:p><=
/o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nb=
sp;</o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>Than=
ks,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'=
>Mauricio <o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#=
1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'col=
or:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style=3D'border:none;bord=
er-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal>=
<b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:=
</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif=
"'> [e-mail] [mailto:[e-mail]] <b>O=
n Behalf Of </b>Sanchez, Mauricio (HP Networking)<br><b>Sent:</b> Friday, A=
pril 08, 2011 11:31 AM<br><b>To:</b> '[e-mail]'<br><b>Subject=
:</b> Consensus poll for IANA #409959 NAS-Port-Type value request<o:p></o:p=
></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=
=3DMsoNormal>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 <o:p></o:p></p><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Type of Assignment :=
<br>Nas-Port-Type values as follows:<br>TBD for WIMAX-3GPP-PRIF:&nbsp;&nbsp=
;WiMAX Pre-Release 8 IWK Function<br>TBD for WIMAX-WIFI-IWK: &nbsp;WiMAX &n=
bsp;&nbsp;WIFI Interworking<br>TBD for WIMAX-SFF: Signaling Forwarding Func=
tion&nbsp;&nbsp;for LTE/3GPP2.<br>TBD for WIMAX-HA-LMA: &nbsp;WiMAX HA and =
or LMA&nbsp;&nbsp;&nbsp;function.<br>TBD for WIMAX-DHCP : WIMAX DCHP servic=
e<o:p></o:p></p><p class=3DMsoNormal>TBD for WIMAX-&nbsp;LBS &nbsp;: WiMAX =
location based service<br>TBD for WIMAX-WVS : WiMAX&nbsp;&nbsp;voice servic=
e<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNor=
mal>The snippet of meeting notes relating to this topic are show below:<o:p=
></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>-=
--- &lt;meeting note snippet begin&gt;---------------------------<o:p></o:p=
></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Request=
 for registration for NAS-port-type.&nbsp; Under 3575, falls under expert r=
eview.&nbsp; This request is for NAS-port-type relating to WiMax<o:p></o:p>=
</p><p class=3DMsoNormal>- Stefan comments that there&#8217;s already type =
for WiFi so not sure why another one is needed, just one.<o:p></o:p></p><p =
class=3DMsoNormal>- Klaas comments that agrees with Stefan&#8217;s comments=
.<o:p></o:p></p><p class=3DMsoNormal>- Nancy comments that looking at the c=
urrent assignment is that there is only 1 allocation per mode.<o:p></o:p></=
p><p class=3DMsoNormal>- Bernard takes the general comment of only allocati=
ng one as the response to take back to the request.&nbsp; Given consensus h=
ere, will verify that opinion in the reflector.<o:p></o:p></p><p class=3DMs=
oNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>---- &lt;meeting note sni=
ppet end&gt;---------------------------<o:p></o:p></p><p class=3DMsoNormal>=
<o:p>&nbsp;</o:p></p><p class=3DMsoNormal>The sentiment in the room was cle=
arly against approving this IANA request and at this time we would like to =
confirm this on the mailing list. &nbsp;<o:p></o:p></p><p class=3DMsoNormal=
><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Please respond to this email and=
 state whether you are in favor or against approving this IANA request.&nbs=
p; <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoN=
ormal>Thanks,<o:p></o:p></p><p class=3DMsoNormal>MS <o:p></o:p></p><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=

--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_--

--_004_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_
Content-Type: message/rfc822

Received: from mail200.messagelabs.com (mail200.messagelabs.com
 [216.82.254.195])	by mx.perfora.net (node=mxus0) with ESMTP (Nemesis)	id
 0MRnhx-1PWinr3eK9-00T7qC for [e-mail]; Tue, 15 Mar 2011 13:39:39
 -0400
Received: (qmail 27728 invoked from network); 15 Mar 2011 17:39:37 -0000
Received: from mail.bridgewatersystems.com (HELO
 webmail.bridgewatersystems.com) (72.35.6.119)  by
 server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2011
 17:39:37 -0000
Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by
 m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 15 Mar 2011
 13:39:36 -0400
From: Avi Lior <[e-mail]>
To: "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>, Alper Yegin
	<[e-mail]>
Date: Tue, 15 Mar 2011 17:39:35 +0000
Subject: [IANA #409959] Genreral Request for Assignements
Thread-Topic: [IANA #409959] Genreral Request for Assignements
Thread-Index: AcvjN/PfETWqJsnhRbCJ3Q5584NJVA==
Message-ID: <[e-mail]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.35.6.119]
x-msg-ref: server-5.tower-200.messagelabs.com!1300210776!92153259!1
x-env-sender: [e-mail]
x-viruschecked: Checked
x-starscan-version: 6.2.9; banners=-,-,-
Content-Type: multipart/alternative;
	boundary="_000_C9A51C9711D20avibridgewatersystemscom_"
MIME-Version: 1.0

--_000_C9A51C9711D20avibridgewatersystemscom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 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 ad=
ditional 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 WiM=
AX network elements and also non-WiMAX network elements.  The approach take=
n 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 attribut=
e to provide that information.

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




WRT 2) Again, WiMAX AAA needs to differentiate between the request from bot=
h 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 do=
esn't seem to be a reason to invent our own attribute.




-- Avi Lior
--Bridgewater Systems


--_000_C9A51C9711D20avibridgewatersystemscom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>
<div>
<div>&nbsp;Hi Bernard,</div>
<div><br>
</div>
<div>Thank you for the review of the NAS-Port-Type IANA request for assignm=
ent. &nbsp;In a previous email you were seeking answers to the following qu=
estions:</div>
<div><span class=3D"Apple-style-span" style=3D"font-family: Times; font-siz=
e: medium; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-=
spacing: 2px; ">
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">Bernard wrote:</span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">Can someone answer the follo=
wing questions?<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">1. What is different between=
 WiMAX WiFi and normal IEEE 802.11?&nbsp; We already have a number of IEEE =
802.11 NAS-Port-types allocated and have proposed
 additional data for this.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">2. Why do DHCP and a locatio=
n service need NAS-Port-Type values?&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">3. Why should we just alloca=
te a generic WiMAX NAS-Port and let additional data be included in a WiMAX =
Forum VSA?</span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span style=3D"font-=
size: 10pt; font-family: Tahoma, sans-serif; ">The general answer to your q=
uestion is as follows:</span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;">For a given session, the WIMAX AAA Serv=
er interacts with many different WiMAX network
 elements and also non-WiMAX network elements. &nbsp;The approach taken by =
WiMAX is to have an explicit indication from the NAS as to the context of t=
he RADIUS access-request. &nbsp;The NAS-Port-Type is viewed as the attribut=
e to provide that information.</span></font></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;">WRT 1) the WiMAX AAA needs to be able t=
o differentiate between a normal WiFi Access and
 a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviou=
rs over and above the &quot;normal&quot; wifi AP. &nbsp;T</span></font></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;"><br>
</span></font></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;">WRT 2) Again, WiMAX AAA needs to differ=
entiate between the request from both these entities
 because the AAA behaviour is different when request comes from &nbsp;a DHC=
P server vs., a Location Based Server.</span></font></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;">WRT 3) &nbsp;WiMAX would just be invent=
ing our own NAS-Port-Type attribute. &nbsp;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.</span></font></p>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple=
-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-sty=
le-span" style=3D"font-size: 13px;"><br>
</span></font></p>
</span></div>
<div>
<div>
<div>-- Avi Lior</div>
<div>--Bridgewater Systems</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_C9A51C9711D20avibridgewatersystemscom_--

--_004_9BC2F7926B33FE4AB10D69891D58FC1C5C72F204E4GVW0671EXCame_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 17 May 2011 14:54:37 +0000
From: "Sanchez, Mauricio (HP Networking)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 17 May 2011 14:52:50 +0000
Subject: Final call for consensus poll for IANA #409959 NAS-Port-Type value request 
Thread-Topic: Final call for consensus poll for IANA #409959 NAS-Port-Type value request 
Thread-Index: AcwUoY87yOeEstuvSo6vISljQJ5ggQ==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F203A9GVW0671EXCame_"
MIME-Version: 1.0

--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F203A9GVW0671EXCame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At this time we find ourselves with a mixed result between the in room sent=
iment at IETF 80 (which was negative to allocation) and the subsequent cons=
ensus poll (which was neutral/positive to allocation).   As such, a final c=
onsensus poll is warranted to establish rough consensus in either direction=
.

Please respond to this email by May 24, 2011 with either a 'yes'  (indicati=
ng allocation should occur) or a 'no' (indicating allocation should be deni=
ed).  Please respond regardless of whether you commented at IETF 80 or to t=
he below consensus poll.

Thanks,
Mauricio


From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Friday, April 08, 2011 11:31 AM
To: '[e-mail]'
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 anothe=
r 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 on=
ly 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 opinio=
n in the reflector.

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

The sentiment in the room was clearly against approving this IANA request a=
nd 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


--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F203A9GVW0671EXCame_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c=
olor:#1F497D'>At this time we find ourselves with a mixed result between th=
e in room sentiment at IETF 80 (which was negative to allocation) and the s=
ubsequent consensus poll (which was neutral/positive to allocation).&nbsp;&=
nbsp; As such, a final consensus poll is warranted to establish rough conse=
nsus in either direction. &nbsp;<o:p></o:p></span></p><p class=3DMsoNormal>=
<span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNor=
mal><span style=3D'color:#1F497D'>Please respond to this email by May 24, 2=
011 with either a &#8216;yes&#8217;&nbsp; (indicating allocation should occ=
ur) or a &#8216;no&#8217; (indicating allocation should be denied).&nbsp; P=
lease respond regardless of whether you commented at IETF 80 or to the belo=
w consensus poll. &nbsp;<o:p></o:p></span></p><p class=3DMsoNormal><span st=
yle=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=3DMsoNormal=
><span style=3D'color:#1F497D'>Mauricio <o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=
=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div=
><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in=
 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fami=
ly:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;f=
ont-family:"Tahoma","sans-serif"'> [e-mail] [mailto:own=
[e-mail]] <b>On Behalf Of </b>Sanchez, Mauricio (HP Networ=
king)<br><b>Sent:</b> Friday, April 08, 2011 11:31 AM<br><b>To:</b> 'radius=
[e-mail]'<br><b>Subject:</b> Consensus poll for IANA #409959 NAS-Po=
rt-Type value request<o:p></o:p></span></p></div></div><p class=3DMsoNormal=
><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>During IETF 80 one of the agenda=
 topics discussed was whether to approve a request received by IANA for all=
ocation of additional NAS-port-type values relating to Wimax as described b=
elow <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>Type of Assignment :<br>Nas-Port-Type values as follows:<br>TBD for=
 WIMAX-3GPP-PRIF:&nbsp;&nbsp;WiMAX Pre-Release 8 IWK Function<br>TBD for WI=
MAX-WIFI-IWK: &nbsp;WiMAX &nbsp;&nbsp;WIFI Interworking<br>TBD for WIMAX-SF=
F: Signaling Forwarding Function&nbsp;&nbsp;for LTE/3GPP2.<br>TBD for WIMAX=
-HA-LMA: &nbsp;WiMAX HA and or LMA&nbsp;&nbsp;&nbsp;function.<br>TBD for WI=
MAX-DHCP : WIMAX DCHP service<o:p></o:p></p><p class=3DMsoNormal>TBD for WI=
MAX-&nbsp;LBS &nbsp;: WiMAX location based service<br>TBD for WIMAX-WVS : W=
iMAX&nbsp;&nbsp;voice service<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp=
;</o:p></p><p class=3DMsoNormal>The snippet of meeting notes relating to th=
is topic are show below:<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:=
p></p><p class=3DMsoNormal>---- &lt;meeting note snippet begin&gt;---------=
------------------<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p>=
<p class=3DMsoNormal>Request for registration for NAS-port-type.&nbsp; Unde=
r 3575, falls under expert review.&nbsp; This request is for NAS-port-type =
relating to WiMax<o:p></o:p></p><p class=3DMsoNormal>- Stefan comments that=
 there&#8217;s already type for WiFi so not sure why another one is needed,=
 just one.<o:p></o:p></p><p class=3DMsoNormal>- Klaas comments that agrees =
with Stefan&#8217;s comments.<o:p></o:p></p><p class=3DMsoNormal>- Nancy co=
mments that looking at the current assignment is that there is only 1 alloc=
ation per mode.<o:p></o:p></p><p class=3DMsoNormal>- Bernard takes the gene=
ral comment of only allocating one as the response to take back to the requ=
est.&nbsp; Given consensus here, will verify that opinion in the reflector.=
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorm=
al>---- &lt;meeting note snippet end&gt;---------------------------<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>The s=
entiment in the room was clearly against approving this IANA request and at=
 this time we would like to confirm this on the mailing list. &nbsp;<o:p></=
o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Plea=
se respond to this email and state whether you are in favor or against appr=
oving this IANA request.&nbsp; <o:p></o:p></p><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p><p class=3DMsoNormal>Thanks,<o:p></o:p></p><p class=3DMsoNorma=
l>MS <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body>=
</html>=

--_000_9BC2F7926B33FE4AB10D69891D58FC1C5C72F203A9GVW0671EXCame_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 17 May 2011 10:13:10 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: New RADEXT WG co-chair
Date: Tue, 17 May 2011 12:11:55 +0200
Message-ID: <[e-mail]>
Thread-Topic: New RADEXT WG co-chair
Thread-Index: AcwUetmKGAQZH7CCSd2mi/Vk8zq0Yg==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "radext mailing list" <[e-mail]>

Hi,=20

Please Jouni Korhonen as the new co-chair of the RADEXT WG, replacing
Bernard Aboba.=20

Thanks again to Bernard for the exceptional service. I hope that his new
responsibilities will allow him enough time to remain a valuable
contributor.=20

Congratulations to Jouni. The nomination takes effect immediately. I
expect Jouni, Mauricio and Bernard to work a fast and smooth transition.


Thanks and Regards,

Dan=20

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


Envelope-to: [e-mail]
Delivery-date: Fri, 13 May 2011 18:03:40 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_d1ef83fb-64f3-489d-a84b-a71d825d94e1_"
From: Bernard Aboba <[e-mail]>
To: Stefan Winter <[e-mail]>, "[e-mail]" <[e-mail]>
CC: <[e-mail]>
Subject: RE: [radext] #93: Compliance with Crypto-Agility Requirements
Date: Fri, 13 May 2011 11:02:44 -0700
MIME-Version: 1.0

--_d1ef83fb-64f3-489d-a84b-a71d825d94e1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This material might be appropriate for inclusion in an Appendix so that it =
wouldn't clutter the main text.=20

Interesting point with respect to TLS_RSA_WITH_3DES_EDE_CBC_SHA.  Since lat=
er TLS RFCs provide recommendations on implementations of algorithms that w=
ould be "Acceptable" with
no known deprecation date=2C would it make sense for the document to incorp=
orate that guidance (even though it only requires earlier versions of  TLS)=
?=20

> Date: Fri=2C 13 May 2011 15:51:13 +0200
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]=3B [e-mail]
> Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements
>=20
> Dear radext issue tracker=2C all=2C
>=20
> below is a discussion of all the requirements. It is somewhat verbose=3B =
I
> wonder if it should go into the document in its entirety or if a
> condensed "I believe it's allright" statement would be enough.
>=20
> Note that I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a
> two-key or a three-key 3DES algorithm. This condition would be the only
> one that could downgrade the proposal from "unconditionally compliant"
> to "conditionally compliant". Note also that there's a proposed
> mitigation for that in the text below.
>=20
> Here goes:
>=20
> The Requirements
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 4.2: Security Services
>=20
> MUST support the negotiation of cryptographic algorithms for per-packet
> integrity/authentication protection.
> -> Check=2C TLS allows negotiation of cipher suites and thus cryptographi=
c
> algorithms.
>=20
> MUST support per-packet replay protection for all RADIUS message types.
> -> Check=2C TLS allows for replay protection.
>=20
> MUST specify mandatory-to-implement cryptographic algorithms for each
> defined mechanism.
> -> Check=2C see section 2.3.2
>=20
> MUST avoid security compromise=2C even in
>    situations where the existing cryptographic algorithms utilized by
>    RADIUS implementations are shown to be weak enough to provide little
>    or no security
> -> Check=2C the RADIUS shared secret is of no cryptographic significance
>=20
> RECOMMENDED that mandatory-to-implement cryptographic
>    algorithms be chosen from among those classified as "Acceptable" with
>    no known deprecation date.
> -> UNKNOWN:
> The mandatory-to-implement alogrithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA=2C
> is a three-key Triple DES Encryption and Decryption algorithm ** IS THIS
> TRUE??? **=2C
> which is classified as "Acceptable" without deprecation date in the
> document in question.
> Can be mitigated=3B TLS 1.2 makes TLS_RSA_WITH_AES_128_CBC_SHA
> mandatory-to-implement=2C
> which fulfills the NIST "Acceptable" in any case. Could raise TLS
> requirements to strictly 1.2 and above.
>=20
> RECOMMENDED that solutions provide support for confidentiality
> -> Check=2C encryption of entire RADIUS packets is supported.
>=20
> MUST support the negotiation of cryptographic algorithms for encryption.
> -> Check=2C TLS allows negotiation of cipher suites and thus cryptographi=
c
> algorithms.
>=20
> REQUIRED to generate fresh session keys for use between the RADIUS
> client and server
> -> Check=2C TLS session keys fulfill requirement.
>=20
> RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to
> session keys
> negotiated between the RADIUS client and server.
> -> Check=2C TLS supports PFS when negotiating appropriate ciphers.
>=20
> RECOMMENDED that a RADIUS crypto-agility solution
>      support X.509 certificates for authentication between the NAS and
>      RADIUS server.
> -> Check.
>=20
> SHOULD also support pre-shared key credentials.
> -> Check.
>=20
> 4.3: Backwards Compatibility
>=20
> MUST demonstrate backward compatibility with existing RADIUS
> implementations.
> -> Check=2C there are multiple implementations which support RADIUS and
> RADIUS/TLS=2C
>    and can act as a translator between the two
>=20
> After legacy mechanisms have been compromised=2C secure algorithms MUST b=
e
> used=2C
> so that backward compatibility is no longer possible.
> -> Check=2C RADIUS clients always need to manually configured (IP and
> shared secret needed)=2C
> and can thus be de-configured after the compromise.
>=20
> 4.4: Interoperability and Change Control
>=20
> MUST indicate a willingness to cede change control to the IETF.
> -> Check=2C change control is at IETF.
>=20
> MUST be interoperable between independent implementations based purely
> on the
> information provided in the specification.
> -> Check=2C at least one implementation was created according to draft
> specs only.
>=20
> 4.5: Scope of Work
>=20
> Crypto-agility solutions MUST apply to all RADIUS packet types
> -> Check=2C crypto-agility is achieved on transport layer=2C and agnostic=
 to
> RADIUS content.
>=20
> message data exchanged with Diameter SHOULD NOT be affected.
> -> Check=2C the solution is Diameter-agnostic.
>=20
> MUST discuss any inherent assumptions about=2C or limitations on=2C
> client/server operations or deployment
>=20
> -> Believed to be a check=2C as I don't think I have unarticulated
> assumptions in my head=2C
>    hence nothing to be discussed.
>=20
> SHOULD provide recommendations for transition of deployments from legacy
> RADIUS to
>    crypto-agile RADIUS.
> -> Check=2C see Security Considerations.
>=20
> Issues regarding cipher-suite negotiation=2C
>    legacy interoperability and the potential for bidding down attacks=2C
>    SHOULD be among these discussions.
> -> Check=2C see Security Considerations.
>=20
> 4.6: Applicability of Automated Key Management Requirements
>=20
> As a result=2C support for Automated Key Management is RECOMMENDED within=
 a
>    RADIUS crypto-agility solution.
> -> Check=3B TLS supports PFS and thus supports AKM.
>=20
> automated key management is REQUIRED for RADIUS crypto-agility
>    solutions that use cryptographic modes of operation that require
>    frequent key changes.
> -> Check.
>=20
>=20
>=20
> Am 29.04.2011 18:48=2C schrieb radext issue tracker:
> > #93: Compliance with Crypto-Agility Requirements
> >
> >  The Crypto-Agility Requirements document now in WG last call (see
> >  http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requiremen=
ts )
> >  includes the following in Section 1.4:
> >
> >     In the initial phase=2C crypto-agility solutions adopted by the wor=
king
> >     group will be published on the Experimental Track.  Experimental
> >     Track documents should contain a description of experimental
> >     deployments and implementations in progress=2C as well as an evalua=
tion
> >     of the proposal against the requirements described in this document=
.
> >
> >
> >  The RADSEC document currently does not include this information.
> >
>=20
>=20
> --=20
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
> 6=2C rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>=20
> Tel: [phone]
> Fax: [phone]
>=20
>=20
 		 	   		  =

--_d1ef83fb-64f3-489d-a84b-a71d825d94e1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
This material might be appropriate for inclusion in an Appendix so that it =
wouldn't clutter the main text. <br><br>Interesting point with respect to T=
LS_RSA_WITH_3DES_EDE_CBC_SHA.&nbsp=3B Since later TLS RFCs provide recommen=
dations on implementations of algorithms that would be "Acceptable" with<br=
>no known deprecation date=2C would it make sense for the document to incor=
porate that guidance (even though it only requires earlier versions of&nbsp=
=3B TLS)? <br><br>&gt=3B Date: Fri=2C 13 May 2011 15:51:13 +0200<br>&gt=3B =
From: [e-mail]<br>&gt=3B To: [e-mail]<br>&gt=
=3B CC: [e-mail]=3B [e-mail]<b=
r>&gt=3B Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirem=
ents<br>&gt=3B <br>&gt=3B Dear radext issue tracker=2C all=2C<br>&gt=3B <br=
>&gt=3B below is a discussion of all the requirements. It is somewhat verbo=
se=3B I<br>&gt=3B wonder if it should go into the document in its entirety =
or if a<br>&gt=3B condensed "I believe it's allright" statement would be en=
ough.<br>&gt=3B <br>&gt=3B Note that I'm not sure whether TLS_RSA_WITH_3DES=
_EDE_CBC_SHA is a<br>&gt=3B two-key or a three-key 3DES algorithm. This con=
dition would be the only<br>&gt=3B one that could downgrade the proposal fr=
om "unconditionally compliant"<br>&gt=3B to "conditionally compliant". Note=
 also that there's a proposed<br>&gt=3B mitigation for that in the text bel=
ow.<br>&gt=3B <br>&gt=3B Here goes:<br>&gt=3B <br>&gt=3B The Requirements<b=
r>&gt=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>&gt=3B <br>&gt=
=3B 4.2: Security Services<br>&gt=3B <br>&gt=3B MUST support the negotiatio=
n of cryptographic algorithms for per-packet<br>&gt=3B integrity/authentica=
tion protection.<br>&gt=3B -&gt=3B Check=2C TLS allows negotiation of ciphe=
r suites and thus cryptographic<br>&gt=3B algorithms.<br>&gt=3B <br>&gt=3B =
MUST support per-packet replay protection for all RADIUS message types.<br>=
&gt=3B -&gt=3B Check=2C TLS allows for replay protection.<br>&gt=3B <br>&gt=
=3B MUST specify mandatory-to-implement cryptographic algorithms for each<b=
r>&gt=3B defined mechanism.<br>&gt=3B -&gt=3B Check=2C see section 2.3.2<br=
>&gt=3B <br>&gt=3B MUST avoid security compromise=2C even in<br>&gt=3B    s=
ituations where the existing cryptographic algorithms utilized by<br>&gt=3B=
    RADIUS implementations are shown to be weak enough to provide little<br=
>&gt=3B    or no security<br>&gt=3B -&gt=3B Check=2C the RADIUS shared secr=
et is of no cryptographic significance<br>&gt=3B <br>&gt=3B RECOMMENDED tha=
t mandatory-to-implement cryptographic<br>&gt=3B    algorithms be chosen fr=
om among those classified as "Acceptable" with<br>&gt=3B    no known deprec=
ation date.<br>&gt=3B -&gt=3B UNKNOWN:<br>&gt=3B The mandatory-to-implement=
 alogrithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA=2C<br>&gt=3B is a three-key Tri=
ple DES Encryption and Decryption algorithm ** IS THIS<br>&gt=3B TRUE??? **=
=2C<br>&gt=3B which is classified as "Acceptable" without deprecation date =
in the<br>&gt=3B document in question.<br>&gt=3B Can be mitigated=3B TLS 1.=
2 makes TLS_RSA_WITH_AES_128_CBC_SHA<br>&gt=3B mandatory-to-implement=2C<br=
>&gt=3B which fulfills the NIST "Acceptable" in any case. Could raise TLS<b=
r>&gt=3B requirements to strictly 1.2 and above.<br>&gt=3B <br>&gt=3B RECOM=
MENDED that solutions provide support for confidentiality<br>&gt=3B -&gt=3B=
 Check=2C encryption of entire RADIUS packets is supported.<br>&gt=3B <br>&=
gt=3B MUST support the negotiation of cryptographic algorithms for encrypti=
on.<br>&gt=3B -&gt=3B Check=2C TLS allows negotiation of cipher suites and =
thus cryptographic<br>&gt=3B algorithms.<br>&gt=3B <br>&gt=3B REQUIRED to g=
enerate fresh session keys for use between the RADIUS<br>&gt=3B client and =
server<br>&gt=3B -&gt=3B Check=2C TLS session keys fulfill requirement.<br>=
&gt=3B <br>&gt=3B RECOMMENDED to support Perfect Forward Secrecy (PFS) with=
 respect to<br>&gt=3B session keys<br>&gt=3B negotiated between the RADIUS =
client and server.<br>&gt=3B -&gt=3B Check=2C TLS supports PFS when negotia=
ting appropriate ciphers.<br>&gt=3B <br>&gt=3B RECOMMENDED that a RADIUS cr=
ypto-agility solution<br>&gt=3B      support X.509 certificates for authent=
ication between the NAS and<br>&gt=3B      RADIUS server.<br>&gt=3B -&gt=3B=
 Check.<br>&gt=3B <br>&gt=3B SHOULD also support pre-shared key credentials=
.<br>&gt=3B -&gt=3B Check.<br>&gt=3B <br>&gt=3B 4.3: Backwards Compatibilit=
y<br>&gt=3B <br>&gt=3B MUST demonstrate backward compatibility with existin=
g RADIUS<br>&gt=3B implementations.<br>&gt=3B -&gt=3B Check=2C there are mu=
ltiple implementations which support RADIUS and<br>&gt=3B RADIUS/TLS=2C<br>=
&gt=3B    and can act as a translator between the two<br>&gt=3B <br>&gt=3B =
After legacy mechanisms have been compromised=2C secure algorithms MUST be<=
br>&gt=3B used=2C<br>&gt=3B so that backward compatibility is no longer pos=
sible.<br>&gt=3B -&gt=3B Check=2C RADIUS clients always need to manually co=
nfigured (IP and<br>&gt=3B shared secret needed)=2C<br>&gt=3B and can thus =
be de-configured after the compromise.<br>&gt=3B <br>&gt=3B 4.4: Interopera=
bility and Change Control<br>&gt=3B <br>&gt=3B MUST indicate a willingness =
to cede change control to the IETF.<br>&gt=3B -&gt=3B Check=2C change contr=
ol is at IETF.<br>&gt=3B <br>&gt=3B MUST be interoperable between independe=
nt implementations based purely<br>&gt=3B on the<br>&gt=3B information prov=
ided in the specification.<br>&gt=3B -&gt=3B Check=2C at least one implemen=
tation was created according to draft<br>&gt=3B specs only.<br>&gt=3B <br>&=
gt=3B 4.5: Scope of Work<br>&gt=3B <br>&gt=3B Crypto-agility solutions MUST=
 apply to all RADIUS packet types<br>&gt=3B -&gt=3B Check=2C crypto-agility=
 is achieved on transport layer=2C and agnostic to<br>&gt=3B RADIUS content=
.<br>&gt=3B <br>&gt=3B message data exchanged with Diameter SHOULD NOT be a=
ffected.<br>&gt=3B -&gt=3B Check=2C the solution is Diameter-agnostic.<br>&=
gt=3B <br>&gt=3B MUST discuss any inherent assumptions about=2C or limitati=
ons on=2C<br>&gt=3B client/server operations or deployment<br>&gt=3B <br>&g=
t=3B -&gt=3B Believed to be a check=2C as I don't think I have unarticulate=
d<br>&gt=3B assumptions in my head=2C<br>&gt=3B    hence nothing to be disc=
ussed.<br>&gt=3B <br>&gt=3B SHOULD provide recommendations for transition o=
f deployments from legacy<br>&gt=3B RADIUS to<br>&gt=3B    crypto-agile RAD=
IUS.<br>&gt=3B -&gt=3B Check=2C see Security Considerations.<br>&gt=3B <br>=
&gt=3B Issues regarding cipher-suite negotiation=2C<br>&gt=3B    legacy int=
eroperability and the potential for bidding down attacks=2C<br>&gt=3B    SH=
OULD be among these discussions.<br>&gt=3B -&gt=3B Check=2C see Security Co=
nsiderations.<br>&gt=3B <br>&gt=3B 4.6: Applicability of Automated Key Mana=
gement Requirements<br>&gt=3B <br>&gt=3B As a result=2C support for Automat=
ed Key Management is RECOMMENDED within a<br>&gt=3B    RADIUS crypto-agilit=
y solution.<br>&gt=3B -&gt=3B Check=3B TLS supports PFS and thus supports A=
KM.<br>&gt=3B <br>&gt=3B automated key management is REQUIRED for RADIUS cr=
ypto-agility<br>&gt=3B    solutions that use cryptographic modes of operati=
on that require<br>&gt=3B    frequent key changes.<br>&gt=3B -&gt=3B Check.=
<br>&gt=3B <br>&gt=3B <br>&gt=3B <br>&gt=3B Am 29.04.2011 18:48=2C schrieb =
radext issue tracker:<br>&gt=3B &gt=3B #93: Compliance with Crypto-Agility =
Requirements<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B  The Crypto-Agility Requirem=
ents document now in WG last call (see<br>&gt=3B &gt=3B  http://tools.ietf.=
org/html/draft-ietf-radext-crypto-agility-requirements )<br>&gt=3B &gt=3B  =
includes the following in Section 1.4:<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B   =
  In the initial phase=2C crypto-agility solutions adopted by the working<b=
r>&gt=3B &gt=3B     group will be published on the Experimental Track.  Exp=
erimental<br>&gt=3B &gt=3B     Track documents should contain a description=
 of experimental<br>&gt=3B &gt=3B     deployments and implementations in pr=
ogress=2C as well as an evaluation<br>&gt=3B &gt=3B     of the proposal aga=
inst the requirements described in this document.<br>&gt=3B &gt=3B<br>&gt=
=3B &gt=3B<br>&gt=3B &gt=3B  The RADSEC document currently does not include=
 this information.<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B <br>&gt=3B -- <br>=
&gt=3B Stefan WINTER<br>&gt=3B Ingenieur de Recherche<br>&gt=3B Fondation R=
ESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale et de la Re=
cherche<br>&gt=3B 6=2C rue Richard Coudenhove-Kalergi<br>&gt=3B L-1359 Luxe=
mbourg<br>&gt=3B <br>&gt=3B Tel: [phone]<br>&gt=3B Fax: [phone]<b=
r>&gt=3B <br>&gt=3B <br> 		 	   		  </body>
</html>=

--_d1ef83fb-64f3-489d-a84b-a71d825d94e1_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 13 May 2011 13:51:56 +0000
Message-ID: <[e-mail]>
Date: Fri, 13 May 2011 15:51:13 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: [e-mail]
CC: radext issue tracker <[e-mail]>,  [e-mail]
Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF05D2C03D61F3FB2081A5336"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF05D2C03D61F3FB2081A5336
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear radext issue tracker, all,

below is a discussion of all the requirements. It is somewhat verbose; I
wonder if it should go into the document in its entirety or if a
condensed "I believe it's allright" statement would be enough.

Note that I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a
two-key or a three-key 3DES algorithm. This condition would be the only
one that could downgrade the proposal from "unconditionally compliant"
to "conditionally compliant". Note also that there's a proposed
mitigation for that in the text below.

Here goes:

The Requirements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

4.2: Security Services

MUST support the negotiation of cryptographic algorithms for per-packet
integrity/authentication protection.
-> Check, TLS allows negotiation of cipher suites and thus cryptographic
algorithms.

MUST support per-packet replay protection for all RADIUS message types.
-> Check, TLS allows for replay protection.

MUST specify mandatory-to-implement cryptographic algorithms for each
defined mechanism.
-> Check, see section 2.3.2

MUST avoid security compromise, even in
   situations where the existing cryptographic algorithms utilized by
   RADIUS implementations are shown to be weak enough to provide little
   or no security
-> Check, the RADIUS shared secret is of no cryptographic significance

RECOMMENDED that mandatory-to-implement cryptographic
   algorithms be chosen from among those classified as "Acceptable" with
   no known deprecation date.
-> UNKNOWN:
The mandatory-to-implement alogrithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA,
is a three-key Triple DES Encryption and Decryption algorithm ** IS THIS
TRUE??? **,
which is classified as "Acceptable" without deprecation date in the
document in question.
Can be mitigated; TLS 1.2 makes TLS_RSA_WITH_AES_128_CBC_SHA
mandatory-to-implement,
which fulfills the NIST "Acceptable" in any case. Could raise TLS
requirements to strictly 1.2 and above.

RECOMMENDED that solutions provide support for confidentiality
-> Check, encryption of entire RADIUS packets is supported.

MUST support the negotiation of cryptographic algorithms for encryption.
-> Check, TLS allows negotiation of cipher suites and thus cryptographic
algorithms.

REQUIRED to generate fresh session keys for use between the RADIUS
client and server
-> Check, TLS session keys fulfill requirement.

RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to
session keys
negotiated between the RADIUS client and server.
-> Check, TLS supports PFS when negotiating appropriate ciphers.

RECOMMENDED that a RADIUS crypto-agility solution
     support X.509 certificates for authentication between the NAS and
     RADIUS server.
-> Check.

SHOULD also support pre-shared key credentials.
-> Check.

4.3: Backwards Compatibility

MUST demonstrate backward compatibility with existing RADIUS
implementations.
-> Check, there are multiple implementations which support RADIUS and
RADIUS/TLS,
   and can act as a translator between the two

After legacy mechanisms have been compromised, secure algorithms MUST be
used,
so that backward compatibility is no longer possible.
-> Check, RADIUS clients always need to manually configured (IP and
shared secret needed),
and can thus be de-configured after the compromise.

4.4: Interoperability and Change Control

MUST indicate a willingness to cede change control to the IETF.
-> Check, change control is at IETF.

MUST be interoperable between independent implementations based purely
on the
information provided in the specification.
-> Check, at least one implementation was created according to draft
specs only.

4.5: Scope of Work

Crypto-agility solutions MUST apply to all RADIUS packet types
-> Check, crypto-agility is achieved on transport layer, and agnostic to
RADIUS content.

message data exchanged with Diameter SHOULD NOT be affected.
-> Check, the solution is Diameter-agnostic.

MUST discuss any inherent assumptions about, or limitations on,
client/server operations or deployment

-> Believed to be a check, as I don't think I have unarticulated
assumptions in my head,
   hence nothing to be discussed.

SHOULD provide recommendations for transition of deployments from legacy
RADIUS to
   crypto-agile RADIUS.
-> Check, see Security Considerations.

Issues regarding cipher-suite negotiation,
   legacy interoperability and the potential for bidding down attacks,
   SHOULD be among these discussions.
-> Check, see Security Considerations.

4.6: Applicability of Automated Key Management Requirements

As a result, support for Automated Key Management is RECOMMENDED within a=

   RADIUS crypto-agility solution.
-> Check; TLS supports PFS and thus supports AKM.

automated key management is REQUIRED for RADIUS crypto-agility
   solutions that use cryptographic modes of operation that require
   frequent key changes.
-> Check.



Am 29.04.2011 18:48, schrieb radext issue tracker:
> #93: Compliance with Crypto-Agility Requirements
>
>  The Crypto-Agility Requirements document now in WG last call (see
>  http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requiremen=
ts )
>  includes the following in Section 1.4:
>
>     In the initial phase, crypto-agility solutions adopted by the worki=
ng
>     group will be published on the Experimental Track.  Experimental
>     Track documents should contain a description of experimental
>     deployments and implementations in progress, as well as an evaluati=
on
>     of the proposal against the requirements described in this document=
=2E
>
>
>  The RADSEC document currently does not include this information.
>


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education=
 Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enigF05D2C03D61F3FB2081A5336
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3NN1UACgkQ+jm90f8eFWbEKQCfWiVJ3EvLU8XX0rrpoWmcUBO9
+j8AmwSvpyDJgN4swCfFep/uNT6Psl18
=KtSJ
-----END PGP SIGNATURE-----

--------------enigF05D2C03D61F3FB2081A5336--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 13 May 2011 12:42:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 13 May 2011 14:41:09 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jacni Qin <[e-mail]>
CC: [e-mail]
Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5179FEB34EBA2BE276A1569"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB5179FEB34EBA2BE276A1569
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

> Jacni>: While we opened the door in this way for additional IANA
> activities. I have a fear that everytime we will need to request a
> value for -id,
> then give the recommended definition of -name accordingly, and vise
> versa? ;-)

I understand your concerns. Another option to do this properly would be
to use RFC5777 - it allows traffic filter, QoS, or even time-of-day
definitions. That should cover a lot of use cases.

The obvious drawback (is it a serious one?) is that it pulls in Diameter
attribute format, which might mean it's not very easy to implement in a
RADIUS server.

I wonder what people think of this...

>     I don't see an issue with that unless one would want to have differ=
ent
>     session Id's for different traffic groups in the same accounting
>     ticket
>     - but I have a hard time thinking of a reason for that; after all a=
ll
>     the counted Octets and Packets belong to the same user session,
>     and can
>     thus share the same session id.
>
>
> Jacni>: For example, two clasess v4 and v6, over single access service,=

> there may be cases that the dynamic QoS or bandwidth policy changes
> (class-specific)
> are requested by users,say, through portal, then initiate/executed by
> the server side, the
> -id is needed.

I'm not sure I understand what you mean. Let me construct an example.
Did you mean

- User logs in over single PPPoE session, gets dual stack connectivity
- NAS has Accounting ID 0xf00ba, and two accounting classes, one for v4
and one for v6
- mid-session, IPv6 gets new QoS parameters (DSCP -> higher) and needs
to be billed separately from that moment on

If that's the use case, I still don't see why the accounting ID would
need to be different from the initially allocated one. It's still the
same session, and thus the same session ID.

An accounting packet could start with two accounting blocks:

IPv4 - DSCP 0
IPv6 - DSCP 0

and when the change happened, adds the third block for traffic class

IPv6 - DSCP x

The block "IPv6 - DSCP 0" will stop incrementing at that point, because
all subsequent traffic will be DSCP x. But it can still be there, and
accurate billing can be produced from it - so no reason why a
Acct-packet-global accounting ID would be insufficient.

Or maybe I got your use case wrong :-)

Stefan

>
>
> Cheers,
> Jacni
>
>
>     Greetings,
>
>     Stefan Winter
>
>     --
>     Stefan WINTER
>     Ingenieur de Recherche
>     Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education
>     Nationale et de la Recherche
>     6, rue Richard Coudenhove-Kalergi
>     L-1359 Luxembourg
>
>     Tel: [phone]
>     Fax: [phone]
>
>
>


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enigB5179FEB34EBA2BE276A1569
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3NJukACgkQ+jm90f8eFWY0EQCfVyrT2osnmuVH/8VVOMCPnOOe
EvwAmgNhqRkqMobfBlt4QcR7ZMXqe7nu
=echz
-----END PGP SIGNATURE-----

--------------enigB5179FEB34EBA2BE276A1569--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 11 May 2011 20:53:13 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_31550d55-4766-4d62-814b-0ba6132bf3ff_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Wrapping up draft-ietf-radext-ipv6-access
Date: Wed, 11 May 2011 13:52:11 -0700
MIME-Version: 1.0

--_31550d55-4766-4d62-814b-0ba6132bf3ff_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


TRAC shows that there are three open issues on this document (#61=2C 69 and=
 71):
http://trac.tools.ietf.org/wg/radext/trac/report/1

>From previous discussion=2C it would appear some of these issues may either=
 be closed or have open proposals on the table.=20

Can the authors update the issue list in TRAC and provide us with an update=
 on the status of this document?=20

As soon as the WG last call issues are closed=2C this document can be sent =
to the IESG for publication.=20
 		 	   		  =

--_31550d55-4766-4d62-814b-0ba6132bf3ff_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
TRAC shows that there are three open issues on this document (#61=2C 69 and=
 71):<br>http://trac.tools.ietf.org/wg/radext/trac/report/1<br><br>From pre=
vious discussion=2C it would appear some of these issues may either be clos=
ed or have open proposals on the table. <br><br>Can the authors update the =
issue list in TRAC and provide us with an update on the status of this docu=
ment? <br><br>As soon as the WG last call issues are closed=2C this documen=
t can be sent to the IESG for publication. <br> 		 	   		  </body>
</html>=

--_31550d55-4766-4d62-814b-0ba6132bf3ff_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 05 May 2011 17:20:36 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_4aa060ff-223f-4e64-9437-411e29fd51f5_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Conclusion of RADEXT WG last call on "TLS Encryption for RADIUS"
Date: Thu, 5 May 2011 10:20:15 -0700
MIME-Version: 1.0

--_4aa060ff-223f-4e64-9437-411e29fd51f5_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG last call has concluded on "TLS Encryption for RADIUS". =20

1 issue was filed (#93)=2C which remains open.=20
 		 	   		  =

--_4aa060ff-223f-4e64-9437-411e29fd51f5_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call has concluded on "TLS Encryption for RADIUS".&nbsp=3B <=
br><br>1 issue was filed (#93)=2C which remains open. <br> 		 	   		  </bod=
y>
</html>=

--_4aa060ff-223f-4e64-9437-411e29fd51f5_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 05 May 2011 17:19:46 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_78dcf820-8c87-43e3-a169-a2317c7335da_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Conclusion of RADEXT WG last call on "Crypto-Agility Requirements for RADIUS"
Date: Thu, 5 May 2011 10:17:52 -0700
MIME-Version: 1.0

--_78dcf820-8c87-43e3-a169-a2317c7335da_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG last call has concluded on "Crypto-Agility Requirements for RADIU=
S".=20

4 issues were submitted (#95-98)=2C all of which were resolved in -06. =20
 		 	   		  =

--_78dcf820-8c87-43e3-a169-a2317c7335da_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call has concluded on "Crypto-Agility Requirements for RADIU=
S". <br><br>4 issues were submitted (#95-98)=2C all of which were resolved =
in -06.&nbsp=3B <br> 		 	   		  </body>
</html>=

--_78dcf820-8c87-43e3-a169-a2317c7335da_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 02 May 2011 05:51:09 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 02 May 2011 05:50:57 -0000
Reply-To: [e-mail]
Subject: Re: [radext] #98: Section 4.2
Message-ID: <[e-mail]>

#98: Section 4.2

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  In WG Last Call            |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/98#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 02 May 2011 05:50:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 02 May 2011 05:50:07 -0000
Reply-To: [e-mail]
Subject: Re: [radext] #95: Section 4.2
Message-ID: <[e-mail]>

#95: Section 4.2

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  In WG Last Call            |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/95#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 02 May 2011 05:49:37 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 02 May 2011 05:49:26 -0000
Reply-To: [e-mail]
Subject: Re: [radext] #96: Informative and Normative references
Message-ID: <[e-mail]>

#96: Informative and Normative references

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  In WG Last Call            |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/96#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 02 May 2011 05:49:32 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 02 May 2011 05:48:49 -0000
Reply-To: [e-mail]
Subject: Re: [radext] #97: Section 1.4
Message-ID: <[e-mail]>

#97: Section 1.4

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  In WG Last Call            |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://rsync.tools.ietf.org/wg/radext/trac/ticket/97#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 02 May 2011 04:16:28 +0000
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-06.txt
Message-ID: <[e-mail]>
Date: Sun, 01 May 2011 21:15:01 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.


	Title           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-06.txt
	Pages           : 12
	Date            : 2011-05-01

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-crypto-agility-requirements-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 20:07:16 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Sun, 01 May 2011 20:07:05 -0000
Reply-To: [e-mail]
Subject: [radext] #98: Section 4.2
Message-ID: <[e-mail]>

#98: Section 4.2

 Section 4.2 includes the following:

 Prevent the Domino effect
      In order to prevent the domino effect, RADIUS crypto-agility
      solutions MUST enable each RADIUS client and server pair to
      authenticate utilizing unique credentials.

 [BA] This seems like a meaningless requirement.  Recommend it be deleted.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/98>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 20:05:31 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Sun, 01 May 2011 20:05:08 -0000
Reply-To: [e-mail]
Subject: [radext] #97: Section 1.4
Message-ID: <[e-mail]>

#97: Section 1.4

 Section 1.4 is unclear as to the process for publication of experimental
 vs. standards track documents.

 Proposed change is as follows:

 1.4.  Publication Process

    RADIUS [RFC2865] is a widely deployed protocol that has attained
    Draft Standard status based on multiple independent interoperable
    implementations.  Therefore it is desirable that a high level of
    interoperability be maintained for crypto-agility solutions.

    To ensure that crypto-agility solutions published on the standards
    track are well specified and interoperable, the RADEXT WG has adopted
    a two phase process for standards-track publication of crypto-agility
    solutions.

    In the initial phase, crypto-agility solutions adopted by the working
    group will be published as Experimental.  These documents should
    contain a description of the implementations and experimental
    deployments in progress, as well as an evaluation of the proposal
    against the requirements described in this document.

    The working group will then select proposals to advance on the
    standards track.  Criteria to be used include evaluation of the
    proposal against the requirements, summary of the experimental
    deployment experience and evidence of multiple interoperable
    implementations.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/97>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 19:54:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Sun, 01 May 2011 19:54:16 -0000
Reply-To: [e-mail]
Subject: [radext] #96: Informative and Normative references
Message-ID: <[e-mail]>

#96: Informative and Normative references

 Currently all references in the document are Informative. Recommended
 change is to separate normative and informative references within Section
 8 as follows:

 8.  References

 8.1.  Normative References

 [NIST-SP800-131A]
           Barker, E. and A. Roginsky, "Transitions: Recommendation for
           Transitioning the Use of Cryptographic Algorithms and Key
           Lengths", NIST SP-800-131A, January 2011.

 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
           Authentication Dial In User Service (RADIUS)", RFC 2865, June
           2000.

 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
           Management", BCP 107, RFC 4107, June 2005.

 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
           Authorization, and Accounting (AAA) Key Management", BCP 132,
           RFC 4962, July 2007.

 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for
           the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151,
           March 2011.

 [RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158,
           March 2011.

 8.2.  Informative References

 [RADYN]   Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery
           for RADIUS over TLS and DTLS", Internet draft (work in
           progress), draft-ietf-radext-dynamic-discovery-02, March 2010.

 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
           2548, March 1999.

 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
           and I. Goyret, "RADIUS Attributes for Tunnel Protocol
           Support", RFC 2868, June 2000.

 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
           3162, August 2001.

 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
           In User Service) Support For Extensible Authentication
           Protocol (EAP)", RFC 3579, September 2003.

 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
           Authentication Dialin User Service (RADIUS) Protocol", RFC
           5997, August 2010.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://rsync.tools.ietf.org/wg/radext/trac/ticket/96>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 19:48:01 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Sun, 01 May 2011 19:47:06 -0000
Reply-To: [e-mail]
Subject: [radext] #95: Section 4.2
Message-ID: <[e-mail]>

#95: Section 4.2

 Section 4.2 is not clear what kind of public key credentials are to be
 supported (e.g. X.509 certificates, public keys without certs, etc.).
 Also, it is not clear whether dynamic discovery is a normative requirement
 or whether another discovery mechanism could be used (such as manual
 configuration).

 Proposed change:

 Limit key scope
      In order to enable a NAS and RADIUS server to exchange confidential
      information such as keying material without disclosure to third
      parties, it is RECOMMENDED that a RADIUS crypto-agility solution
      support X.509 certificates for authentication between the NAS and
      RADIUS server.  Manual configuration as well as automated discovery
      mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be
      used to enable direct NAS-RADIUS server communications.  Support
      for end-to-end confidentiality of RADIUS attributes is not
      required.

      For compatibility with existing operations, RADIUS crypto-agility
      solutions SHOULD also support pre-shared key credentials.  However,
      support for direct communications between the NAS and RADIUS server
      is not required when pre-shared key credentials are used.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/95>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 00:36:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RvxJGUmD97Y6UzAhKjzloqi3NRegvGligqEG3xVLeXQ=; b=kkMhg+CBHlDHeN1SmT57piPkVCFt2EzAzwOUt1F/P0TY8mHNbxxJNPVfHtIBpzNRMF N/Q93rkwmB/KTHnw/zum33SOhf91s+voTvISppQsABAFcW5FbmoIjDWVtzTCR9gnId9v PFMxWqc0IBHa+qPlcTVqOFG/Sga+vo+edZ1aM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n6S0NcN4a8DIV0jAdcjEmCjIWIn2bfPOs1a8WlRu663mKBE0P0MUDFvKj1LQUuR23z 3WtKsFV5/qme8mZnDM5Y1jSFdQc+fw3roeLE2KczhQptBpi2w3ZpLK0bNNADRRlkQv7m 1Y1UVOD9+yCREOVmRVOhtLMns//GWjmAOyyKs=
MIME-Version: 1.0
Date: Sun, 1 May 2011 08:36:19 +0800
Message-ID: <[e-mail]>
Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00
From: Jacni Qin <[e-mail]>
To: Stefan Winter <[e-mail]>
Cc: [e-mail]
Content-Type: multipart/alternative; boundary=20cf3071c6fe757aba04a22c187c

--20cf3071c6fe757aba04a22c187c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi,

Sorry for my late reply,

On Wed, Apr 27, 2011 at 5:52 PM, Stefan Winter <[e-mail]>wr=
ote:

> Hi,
>
> > I skimed the draft and got some comments, see below please.
> >
> > * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be
> > redundant, I perfer to only keep the Name attribute which is STRING
> > formatted and defined by BNG (configurable). The traffic classes are
> > specified based on the capability of the BNG. No further IANA
> > activities are needed in the future.
>
> It's true that any value expressed in -Id could also be formulated in a
> string in -Name. However, naming conventions for the string are likely
> to differ, so I would prefer to have controlled vocabulary at least for
> more common use cases - like DSCP classes or IP versions, as in the draft=
.
>

Jacni>: While we opened the door in this way for additional IANA
activities. I have a fear that everytime we will need to request a value fo=
r
-id,
then give the recommended definition of -name accordingly, and vise versa?
;-)


> Another option would be to follow Alan's comment regarding
> NAS-Filter-Rule naming. I'm not much of fan of this, because the first
> examples which came to my mind: IP versions, DSCP values, don't sit
> together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only
> IP versions could be expressed as a filter with NAS-Filter-Rule, but
> DSCP is a Diameter QoSFilterRule - which can't be expressed in
> NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here).
>
> > * An attribute similar to Type#44 Acct-Session-Id is necessary, since
> > this is widely implemented in practice, for example, as an
> > identification of user for policy changes initiated by AAA server.
> > Name it "Acct-Traffic-Class-Id"? But the value should be a random
> > number assigned by BNG. Some other attributes may also need to be
> > considered.
>
> The example in the draft only shows a fragment of the entire Accounting
> packet. The Accounting packet will be able to contain the
> Acct-Session-Id, and then additionally one or more groups of
> Accounting-Traffic-Group.
>
> I don't see an issue with that unless one would want to have different
> session Id's for different traffic groups in the same accounting ticket
> - but I have a hard time thinking of a reason for that; after all all
> the counted Octets and Packets belong to the same user session, and can
> thus share the same session id.
>

Jacni>: For example, two clasess v4 and v6, over single access service,
there may be cases that the dynamic QoS or bandwidth policy changes
(class-specific)
are requested by users,say, through portal, then initiate/executed by the
server side, the
-id is needed.


Cheers,
Jacni


> Greetings,
>
> Stefan Winter
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de
> la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>
> Tel: [phone]
> Fax: [phone]
>
>
>

--20cf3071c6fe757aba04a22c187c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font face=3D"verdana,sans-serif">hi,<br><br>Sorry for my late reply,<br></=
font><br><div class=3D"gmail_quote">On Wed, Apr 27, 2011 at 5:52 PM, Stefan=
 Winter <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]" t=
arget=3D"_blank">[e-mail]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<div><br>
&gt; I skimed the draft and got some comments, see below please.<br>
&gt;<br>
&gt; * &quot;Section 2.2.1.Acct-Traffic-Class-Id attribute&quot; seems to b=
e<br>
&gt; redundant, I perfer to only keep the Name attribute which is STRING<br=
>
&gt; formatted and defined by BNG (configurable). The traffic classes are<b=
r>
&gt; specified based on the capability of the BNG. No further IANA<br>
&gt; activities are needed in the future.<br>
<br>
</div>It&#39;s true that any value expressed in -Id could also be formulate=
d in a<br>
string in -Name. However, naming conventions for the string are likely<br>
to differ, so I would prefer to have controlled vocabulary at least for<br>
more common use cases - like DSCP classes or IP versions, as in the draft.<=
br></blockquote><div><br><font face=3D"verdana,sans-serif">Jacni&gt;: While=
 we opened the door in this way for additional IANA<br>activities. I have a=
 fear that everytime we will need to request a value for -id,<br>

then give the recommended definition of -name accordingly, and vise versa? =
;-)<br><br></font></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"=
>


<br>
Another option would be to follow Alan&#39;s comment regarding<br>
NAS-Filter-Rule naming. I&#39;m not much of fan of this, because the first<=
br>
examples which came to my mind: IP versions, DSCP values, don&#39;t sit<br>
together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only<br>
IP versions could be expressed as a filter with NAS-Filter-Rule, but<br>
DSCP is a Diameter QoSFilterRule - which can&#39;t be expressed in<br>
NAS-Filter-Rule (I&#39;ll be happy to be corrected if I&#39;m wrong here).<=
br>
<div><br>
&gt; * An attribute similar to Type#44 Acct-Session-Id is necessary, since<=
br>
&gt; this is widely implemented in practice, for example, as an<br>
&gt; identification of user for policy changes initiated by AAA server.<br>
&gt; Name it &quot;Acct-Traffic-Class-Id&quot;? But the value should be a r=
andom<br>
&gt; number assigned by BNG. Some other attributes may also need to be<br>
&gt; considered.<br>
<br>
</div>The example in the draft only shows a fragment of the entire Accounti=
ng<br>
packet. The Accounting packet will be able to contain the<br>
Acct-Session-Id, and then additionally one or more groups of<br>
Accounting-Traffic-Group.<br>
<br>
I don&#39;t see an issue with that unless one would want to have different<=
br>
session Id&#39;s for different traffic groups in the same accounting ticket=
<br>
- but I have a hard time thinking of a reason for that; after all all<br>
the counted Octets and Packets belong to the same user session, and can<br>
thus share the same session id.<br></blockquote><div><br><font face=3D"verd=
ana,sans-serif">Jacni&gt;: For example, two clasess v4 and v6, over single =
access service,<br>there may be cases that the dynamic QoS or bandwidth pol=
icy changes (class-specific)<br>
are requested by users,say, through portal, then initiate/executed by the s=
erver side, the<br>-id is needed.<br><br><br>Cheers,<br>Jacni<br>
<br></font></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt =
0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><div></div><div><br>
Greetings,<br>
<br>
Stefan Winter<br>
<br>
--<br>
Stefan WINTER<br>
Ingenieur de Recherche<br>
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l&#39;Education Nation=
ale et de la Recherche<br>
6, rue Richard Coudenhove-Kalergi<br>
L-1359 Luxembourg<br>
<br>
Tel: [phone]<br>
Fax: [phone]<br>
<br>
<br>
</div></div></blockquote></div><br>

--20cf3071c6fe757aba04a22c187c--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 01 May 2011 00:33:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=85bXQ255NIcUlN3bFdACk7pckMHVhV5aSnEEHeGLUx4=; b=lIfgdPJ+PPZH8PNvpwI9UX065QrIuYGhCnX79ZxodYsCi+WGRij8kJO6SPnBNAx/uO zntC4VFw9asDqZ7wfvedJd4S17j9ON6h/HmflxrpcPMoCWeLd5ZuVwwQGSED/jcyhpDP yNvrFfSnu+VHZy5SVSu+OXnojHS832gO3hLiY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v8JqbAm795B4BECPoR/79RYOy3ieNlDSN7F5kd9ohPTMRqKq5FW9vM/mCkqrtapK3B 9fHycxlKvyYzQFG7vN2LZgo2rSnkmmdE6w/sx8kR0sjls9JavaMxA9fWaTuVSglNKT2D M/Hi3M1PhtTpCeHYtp+rGa2hpT5HGZ8w+Cf80=
MIME-Version: 1.0
Date: Sun, 1 May 2011 08:32:42 +0800
Message-ID: <BANLkTi=[e-mail]>
Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00
From: Jacni Qin <[e-mail]>
To: Alan DeKok <[e-mail]>
Cc: Stefan Winter <[e-mail]>, [e-mail]
Content-Type: multipart/alternative; boundary=bcaec501638981b2a504a22c0bdc

--bcaec501638981b2a504a22c0bdc
Content-Type: text/plain; charset=ISO-8859-1

Re-,

Ok, I got your point.


Cheers,
Jacni

On Wed, Apr 27, 2011 at 3:01 PM, Alan DeKok <[e-mail]>wrote:

> Jacni Qin wrote:
> > * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall
> > we "re-use" the type specified in RFC2866, like 245.1.47, etc.
>
>   I would strongly recommend not doing that.  Re-using the type would
> lead people to conclude that the type space for TLVs is the same as the
> type space for "normal" RADIUS attributes.  This is not the case.
>
>  Alan DeKok.
>

--bcaec501638981b2a504a22c0bdc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font face=3D"verdana,sans-serif">Re-,<br><br>Ok, I got your point.<br><br>=
<br>Cheers,<br>Jacni<br></font><br><div class=3D"gmail_quote">On Wed, Apr 2=
7, 2011 at 3:01 PM, Alan DeKok <span dir=3D"ltr">&lt;<a href=3D"mailto:alan=
[e-mail]" target=3D"_blank">[e-mail]</a>&gt;<=
/span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Jacni Qin wrote:<br>
&gt; * For the Input-* &amp; Output-* attributes (Section 2.2.3 ~ 2.2.6), S=
hall<br>
&gt; we &quot;re-use&quot; the type specified in RFC2866, like 245.1.47, et=
c.<br>
<br>
</div> =A0I would strongly recommend not doing that. =A0Re-using the type w=
ould<br>
lead people to conclude that the type space for TLVs is the same as the<br>
type space for &quot;normal&quot; RADIUS attributes. =A0This is not the cas=
e.<br>
<font color=3D"#888888"><br>
 =A0Alan DeKok.<br>
</font></blockquote></div><br>

--bcaec501638981b2a504a22c0bdc--

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