Subject: Fwd: Nomcom 2011-2012: Call for Nominations

From: jouni korhonen <[email-masked]>
Date: Wed, 24 Aug 2011 13:29:24 +0300

We encourage you to participate.

The chairs.

Begin forwarded message:

> From: NomCom Chair <[email-masked]>
> Date: August 23, 2011 1:32:18 AM GMT+03:00
> To: IETF Announcement list <[email-masked]>
> Cc: [email-masked]
> Subject: Nomcom 2011-2012: Call for Nominations 
> 
> Hi All,
> 
> The 2011-2012 Nominating committee is seeking nominations from now 
> until October 2, 2011. The list of open positions can be found at:
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may be made directly on the NomCom 2011-2012 pages by 
> selecting the Nominate link at the top of the page.  The URL for
> NomCom 2011-2012 pages is: 
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may also be made by email to [email-masked].
> If you do so, please include the word "Nominate" in the Subject and 
> indicate in the email who is being nominated, their email address (to
> confirm acceptance of the nomination), and the position for which you 
> are making the nomination. If you wish to nominate someone via email 
> for more than one position, please use separate emails to do so.
> 
> Self nomination is welcome. 
> 
> NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing 
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of 
> nominees willing to be considered for positions under review in the 
> current NomCom cycle is not confidential". Willing Nominees for each 
> position will be publicly listed.  The public nominee list will be 
> updated at least once a week and possibly more often as nominations are 
> received.
> 
> With the exception of publicly listing willing nominees, the 
> confidentiality requirements of RFC 3777 remain in effect.  All 
> feedback and NomCom deliberations will remain confidential and not 
> disclosed. 
> 
> Because the list of nominees this year is public, we will accept 
> feedback on the nominees starting August 23, 2011. Per RFC 5680, we 
> will accept feedback from the entire IETF community on all the nominees. 
> 
> If you wish to provide anonymous feedback, the chair or any of the 
> members will be happy to handle this for you.  The Nominating Committee 
> chair can be reached at [email-masked] and the entire nominating 
> committee can be reached at [email-masked]. The email addresses of 
> individual NomCom members is also on the NomCom 2011-2012 pages.
> 
> In addition to nominations, the Nominating Committee is actively
> seeking community input on the jobs that need to be filled.  We have
> received the job descriptions from the IAB, IESG, and IAOC and they can
> be found at:
> 
> https://www.ietf.org/group/nomcom/2011/iab-requirements
> https://www.ietf.org/group/nomcom/2011/iesg-requirements
> https://www.ietf.org/group/nomcom/2011/iaoc-requirements
> 
> However, we also need the community's views and input on the jobs 
> within each organization. If you have ideas on job responsibilities 
> (more, less, different), please let us know.  Please send suggestions 
> and feedback to [email-masked]. 
> 
> Thank you,
> 
> Suresh Krishnan
> Chair, NomCom 2011-2012
> [email-masked]
> [email-masked]
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Delivery-date: Wed, 24 Aug 2011 10:30:36 +0000
From: jouni korhonen <[email-masked]>
Subject: Fwd: Nomcom 2011-2012: Call for Nominations 
Date: Wed, 24 Aug 2011 13:29:24 +0300
To: [email-masked], [email-masked]

We encourage you to participate.

The chairs.

Begin forwarded message:

> From: NomCom Chair <[email-masked]>
> Date: August 23, 2011 1:32:18 AM GMT+03:00
> To: IETF Announcement list <[email-masked]>
> Cc: [email-masked]
> Subject: Nomcom 2011-2012: Call for Nominations 
> 
> Hi All,
> 
> The 2011-2012 Nominating committee is seeking nominations from now 
> until October 2, 2011. The list of open positions can be found at:
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may be made directly on the NomCom 2011-2012 pages by 
> selecting the Nominate link at the top of the page.  The URL for
> NomCom 2011-2012 pages is: 
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may also be made by email to [email-masked].
> If you do so, please include the word "Nominate" in the Subject and 
> indicate in the email who is being nominated, their email address (to
> confirm acceptance of the nomination), and the position for which you 
> are making the nomination. If you wish to nominate someone via email 
> for more than one position, please use separate emails to do so.
> 
> Self nomination is welcome. 
> 
> NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing 
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of 
> nominees willing to be considered for positions under review in the 
> current NomCom cycle is not confidential". Willing Nominees for each 
> position will be publicly listed.  The public nominee list will be 
> updated at least once a week and possibly more often as nominations are 
> received.
> 
> With the exception of publicly listing willing nominees, the 
> confidentiality requirements of RFC 3777 remain in effect.  All 
> feedback and NomCom deliberations will remain confidential and not 
> disclosed. 
> 
> Because the list of nominees this year is public, we will accept 
> feedback on the nominees starting August 23, 2011. Per RFC 5680, we 
> will accept feedback from the entire IETF community on all the nominees. 
> 
> If you wish to provide anonymous feedback, the chair or any of the 
> members will be happy to handle this for you.  The Nominating Committee 
> chair can be reached at [email-masked] and the entire nominating 
> committee can be reached at [email-masked]. The email addresses of 
> individual NomCom members is also on the NomCom 2011-2012 pages.
> 
> In addition to nominations, the Nominating Committee is actively
> seeking community input on the jobs that need to be filled.  We have
> received the job descriptions from the IAB, IESG, and IAOC and they can
> be found at:
> 
> https://www.ietf.org/group/nomcom/2011/iab-requirements
> https://www.ietf.org/group/nomcom/2011/iesg-requirements
> https://www.ietf.org/group/nomcom/2011/iaoc-requirements
> 
> However, we also need the community's views and input on the jobs 
> within each organization. If you have ideas on job responsibilities 
> (more, less, different), please let us know.  Please send suggestions 
> and feedback to [email-masked]. 
> 
> Thank you,
> 
> Suresh Krishnan
> Chair, NomCom 2011-2012
> [email-masked]
> [email-masked]
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Delivery-date: Thu, 18 Aug 2011 02:43:10 +0000
Date: Thu, 18 Aug 2011 02:42:42 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[email-masked]" <[email-masked]>
Cc: Dave Nelson <[email-masked]>, "David B. Nelson" <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Thu, 18 Aug 2011 02:41:52 +0000
Date: Thu, 18 Aug 2011 02:39:39 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?Rlc6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[email-masked]" <[email-masked]>
Cc: Dave Nelson <[email-masked]>, "David B. Nelson" <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Wed, 17 Aug 2011 08:06:26 +0000
Date: Wed, 17 Aug 2011 10:05:42 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[email-masked]>
To: Leaf yeh <[email-masked]>, Dave Nelson <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>, roberta maglione <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>

On 17/08/2011 09:10, "Leaf yeh" <[email-masked]> wrote:

>  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.

This is interesting, given that the root of this thread is your email
proposal for just that:
https://ops.ietf.org/lists/radiusext/2010/msg00959.html

Quote from the above:
" I think Framed-IPv6-Pool can be re-used for the design purpose of
Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could
even think=A0Framed-Pool can replace Framed-IPv6-Pool to indicate the name of
a IPv6 prefix/address pool per the same logic"

draft-ietf-radext-ipv6-access-05 has no such issues does not mix pool namin=
g
with addressing method. It defines separate string attributes for each
addressing method, and allows arbitrary pool name(s) for each.

Thanks,
Woj.

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

Delivery-date: Wed, 17 Aug 2011 07:12:27 +0000
Date: Wed, 17 Aug 2011 07:12:06 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Wojciech Dec <[email-masked]>, Dave Nelson <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>, roberta maglione <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Wed, 17 Aug 2011 07:11:16 +0000
Date: Wed, 17 Aug 2011 07:10:10 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Dave Nelson <[email-masked]>, Wojciech Dec <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>, roberta maglione <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Wed, 17 Aug 2011 07:10:57 +0000
Date: Wed, 17 Aug 2011 07:09:36 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Dave Nelson <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Tue, 16 Aug 2011 15:43:04 +0000
Date: Tue, 16 Aug 2011 15:42:08 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Wojciech Dec <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Accept-Language: zh-CN, en-US

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)
Content-id: <[email-masked]>
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)--

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

Delivery-date: Tue, 16 Aug 2011 15:34:05 +0000
Date: Tue, 16 Aug 2011 15:33:02 +0000
From: Leaf yeh <[email-masked]>
Subject: =?gb2312?B?UkU6ILTwuLQ6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1p?= =?gb2312?Q?pv6-access_after_IETF81_radext_session?=
To: "David B. Nelson" <[email-masked]>, Wojciech Dec <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>, roberta maglione <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Accept-Language: zh-CN, en-US

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)
Content-id: <[email-masked]>
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"0" fPStyle=3D"1">
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ=
E: 10pt">
<pre style=3D"WORD-WRAP: break-word">David - It's almost always the *conten=
ts* of attributes that is interpreted by the NAS...

I agree.=20

I thought AAA server just need to indicate single or multiple pool names, w=
hose meaning &amp; purpose should definitely be known in advanced by AAA se=
rver.=20

I doubted the attributes of 'Delegated-IPv6-Prefix-Pool' and 'Stateful-IPv6=
-Address-Pool' will make NAS's life easier than before. :-) I believe NAS w=
ill double check the type of pool against the name string in the different =
type container of the attributes (or proposed attributes) including Framed-=
Pool, Framed-IPv6-Pool, Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Addres=
s-Pool. Right?

-----Original Message-----
From: David B. Nelson [mailto:[email-masked]]=20
Sent: Monday, August 15, 2011 11:22 PM
To: Wojciech Dec
Cc: [email-masked]; [email-masked]; f=
ine sz; Qiujin; Wangshuxiang; [email-masked]; Lea=
f yeh; roberta maglione; [email-masked]; Bernard Aboba
Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access af=
ter IETF81 radext session

&gt; ... it looks very much as relying on the special NAS feature
&gt; to interpret *the contents* of the attribute as to the pools...

Special NAS feature?  Why is the interpretation of this proposed RADIUS att=
ribute any more special than NAS behavior that interprets any other attribu=
te?  It's almost always the *contents* of attributes that is interpreted by=
 the NAS,

&gt; ...to be used, only this time with the contents being laid down as
&gt; the enumerated type code points in a draft.=20

I think an enumerated type is preferable to parsing strings when the semant=
ics of the attribues is to apply one of a limited number of discreet choice=
s.

&gt; This does not help given a) past precedent in terms of Radius
&gt; pool definitions (there are already 2 pools, and they are being
&gt; used), nor b) give the operator an explicit indication regarding
&gt; the use of a pool, rather than implicit.

I don't undertand either of these points.  What *RADIUS* precedent exists, =
and by that I mean a precedent in normative text?  If you're referring to a=
d-hoc implementation practice, in the absence of any normative guidance, I =
suggest that in standardizing a solution to that sort of gap in the protoco=
l, one would not be unduly influenced by the fact that various ad-hoc solut=
ions had been implemented.  That would defeat the purpose of standardizing =
behavior.

&gt; Besides the above, as with any enumerated type, issues will start
&gt; should there be another combination that someone comes up with or
&gt; wants...

The IANA code point allocation procedures should be sufficiently open to pe=
rmit adding additional &quot;flavors&quot; without invoking IETF consensus =
or WG approvals.

&gt; Frankly, other than it being another way of doing things, I personally
&gt; don=A1=AFt see much of a benefit.

If you are invested in an existing implementation using another approach I =
can understand that, but a clearly defined, enumerated value attribute seem=
s more attractive to me.

-- Dave
</pre>
</div>
</body>
</html>

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)--

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

Delivery-date: Tue, 16 Aug 2011 14:59:33 +0000
Date: Tue, 16 Aug 2011 16:58:02 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, <[email-masked]>, <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, <[email-masked]>, Leaf yeh <[email-masked]>, roberta maglione <[email-masked]>, <[email-masked]>, Bernard Aboba <[email-masked]>

On 16/08/2011 16:33, "Dave Nelson" <[email-masked]> wrote:

> 
> I have no problem with string encodings of pool names.   Since pools
> can be named arbitrarily by the NAS system administrator, anything
> other than a string encoding would be unnatural.  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.

Well, I think we're in agreement and when you come to read the WG proposal
in draft-ietf-radext-ipv6 you will find it NOT to have the above issue.
The origin of this email thread, it seems appropriate to recall it, is that
some folks claimed that the proposal in the draft is not needed and that
solving the case by overloading pool naming is better, followed on by a
second proposal for the enumerated type.

> 
>> Sure. We appear to be talking about code-points for values within a single
>> attribute, fine examples, ( for which no IANA code points were assigned)
>> include the existing Service-Type and Error-Cause attributes.
>> In enumerating this, by definition there is a restriction which is not
>> called for in this situation.
> 
> Why not?

Example given below, and it is one that is perfectly legitimate.

> 
>> Should an operator choose to say assign 2 prefixes to a subscriber
>> for DHCP-PD, but one for SLAAC, they would need to
>> get an IANA code point...
> 
> I don't think that specific values for *combinations* of options is a
> good way to go.

It's rather clear that an enumerated attribute cannot handle this case.

> 
>> Before going further, perhaps you could consider/comment on the current
>> proposal in: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-05
> 
> I'll find some time to do that, soon.

Please do. I think we're in agreement here and there is no need of changes.

Regards,
Woj.
> Regards,
> Dave
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636

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

Delivery-date: Tue, 16 Aug 2011 07:29:48 +0000
Date: Tue, 16 Aug 2011 07:27:22 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "David B. Nelson" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Accept-Language: zh-CN, en-US

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

Delivery-date: Mon, 15 Aug 2011 15:53:19 +0000
Date: Mon, 15 Aug 2011 17:52:40 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, fine sz <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, <[email-masked]>, Leaf yeh <[email-masked]>, roberta maglione <[email-masked]>, <[email-masked]>, Bernard Aboba <[email-masked]>

On 15/08/2011 17:21, "David B. Nelson" <[email-masked]> wrote:

>> ... it looks very much as relying on the special NAS feature
>> to interpret *the contents* of the attribute as to the pools...
>=20
> Special NAS feature?  Why is the interpretation of this proposed RADIUS
> attribute any more special than NAS behavior that interprets any other
> attribute?  It's almost always the *contents* of attributes that is
> interpreted by the NAS,

Ok. So help me out here: An operator has two pools, A for business
customers, B for residential. In both cases the operator expects Foo-bar
addressing method to be used and customers in A or B. How does the NAS pick
the right pool based on receiving a single attribute containing an
enumerated code-point for Foo-bar?

>=20
>> ...to be used, only this time with the contents being laid down as
>> the enumerated type code points in a draft.
>=20
> I think an enumerated type is preferable to parsing strings when the sema=
ntics
> of the attribues is to apply one of a limited number of discreet choices.

The alternative, which is what I and others are proposing is to follow
precedent and use separate string attributes for their role - *as proposed*
in the current ipv6-access draft.
>=20
>> This does not help given a) past precedent in terms of Radius
>> pool definitions (there are already 2 pools, and they are being
>> used), nor b) give the operator an explicit indication regarding
>> the use of a pool, rather than implicit.
>=20
> I don't undertand either of these points.  What *RADIUS* precedent exists=
, and
> by that I mean a precedent in normative text?  If you're referring to ad-=
hoc
> implementation practice, in the absence of any normative guidance, I sugg=
est
> that in standardizing a solution to that sort of gap in the protocol, one
> would not be unduly influenced by the fact that various ad-hoc solutions =
had
> been implemented.  That would defeat the purpose of standardizing behavio=
r.

Precedent =3D rfc3162, rfc4818, and earlier non IPv6 ones, each define named
pools for a specific purpose.

>=20
>> Besides the above, as with any enumerated type, issues will start
>> should there be another combination that someone comes up with or
>> wants...
>=20
> The IANA code point allocation procedures should be sufficiently open to
> permit adding additional "flavors" without invoking IETF consensus or WG
> approvals.

Sure. We appear to be talking about code-points for values within a single
attribute, fine examples, ( for which no IANA code points were assigned)
include the existing Service-Type and Error-Cause attributes.
In enumerating this, by definition there is a restriction which is not
called for in this situation. Should an operator choose to say assign 2
prefixes to a subscriber for DHCP-PD, but one for SLAAC, they would need to
get an IANA code point... And then have the vendor(s) support that, etc.
Never mind open IANA code point allocation procedures - this looks to be
practically unwise.

>=20
>> Frankly, other than it being another way of doing things, I personally
>> don=B9t see much of a benefit.
>=20
> If you are invested in an existing implementation using another approach =
I can
> understand that, but a clearly defined, enumerated value attribute seems =
more
> attractive to me.

Before going further, perhaps you could consider/comment on the current
proposal in: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-05

Thanks,
Wojciech.
>=20
> -- Dave

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

Delivery-date: Mon, 15 Aug 2011 15:22:44 +0000
Date: Mon, 15 Aug 2011 15:21:51 +0000 (UTC)
From: "David B. Nelson" <[email-masked]>
To: Wojciech Dec <[email-masked]>
Cc: [email-masked], [email-masked],  fine sz <[email-masked]>, Qiujin <[email-masked]>,  Wangshuxiang <[email-masked]>,  [email-masked],  Leaf yeh <[email-masked]>,  roberta maglione <[email-masked]>,  [email-masked], Bernard Aboba <[email-masked]>
Subject: =?utf-8?Q?Re:_=E7=AD=94=E5=A4=8D:_Q_on_Ver.-05_of_draft-ietf-radex?= =?utf-8?Q?t-ipv6-access_after_IETF81_radext_session?=

> ... it looks very much as relying on the special NAS feature
> to interpret *the contents* of the attribute as to the pools...

Special NAS feature?  Why is the interpretation of this proposed RADIUS att=
ribute any more special than NAS behavior that interprets any other attribu=
te?  It's almost always the *contents* of attributes that is interpreted by=
 the NAS,

> ...to be used, only this time with the contents being laid down as
> the enumerated type code points in a draft.=20

I think an enumerated type is preferable to parsing strings when the semant=
ics of the attribues is to apply one of a limited number of discreet choice=
s.

> This does not help given a) past precedent in terms of Radius
> pool definitions (there are already 2 pools, and they are being
> used), nor b) give the operator an explicit indication regarding
> the use of a pool, rather than implicit.

I don't undertand either of these points.  What *RADIUS* precedent exists, =
and by that I mean a precedent in normative text?  If you're referring to a=
d-hoc implementation practice, in the absence of any normative guidance, I =
suggest that in standardizing a solution to that sort of gap in the protoco=
l, one would not be unduly influenced by the fact that various ad-hoc solut=
ions had been implemented.  That would defeat the purpose of standardizing =
behavior.

> Besides the above, as with any enumerated type, issues will start
> should there be another combination that someone comes up with or
> wants...

The IANA code point allocation procedures should be sufficiently open to pe=
rmit adding additional "flavors" without invoking IETF consensus or WG appr=
ovals.

> Frankly, other than it being another way of doing things, I personally
> don=E2=80=99t see much of a benefit.

If you are invested in an existing implementation using another approach I =
can understand that, but a clearly defined, enumerated value attribute seem=
s more attractive to me.

-- Dave

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

Delivery-date: Mon, 15 Aug 2011 12:10:29 +0000
Date: Mon, 15 Aug 2011 14:09:12 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[email-masked]>
To: Leaf yeh <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
CC:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3396262154_11243562
Content-type: text/plain;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

Hello Leaf,

If I understand it correctly, you=A1=AFre proposing that the end user/host type=
s
be enumerated as part of a new attribute, which would then drive the
addressing behavior, eg selection of pools. If so, it looks very much as
relying on the special NAS feature to interpret *the contents* of the
attribute as to the pools to be used, only this time with the contents bein=
g
laid down as the enumerated type code points in a draft. This does not help
given a) past precedent in terms of Radius pool definitions (there are
already 2 pools, and they are being used), nor b) give  the operator an
explicit indication regarding the use of a pool, rather than implicit.
Besides the above, as with any enumerated type, issues will start should
there be another combination that someone comes up with or wants...

Frankly, other than it being another way of doing things, I personally don=A1=
=AFt
see much of a benefit.

Regards,
Woj.

On 15/08/2011 13:19, "Leaf yeh" <[email-masked]> wrote:

> Wojciech - There is little that disallows a vendor from implementing just=
 one
> named pool for all protocols and all methods of assignment ( the Framed-P=
ool
> appears to have been envisaged for that ) and then using some implementat=
ion
> specific logic (eg parsing for a name) to figure out/how it=A1=AFs to be used=
.
> =20
> I agree.
> =20
> Wojciech - Since the Radius specification is NOT about specifying
> implementation the only reliable/unambiguous manner in which different
> pools/methods can be utilized would appear to be using different attribut=
es as
> proposed in the current draft. Are there any other options/solutions avai=
lable
> that do not call on implicit features being there?
>=20
>=20
> A new attribute designed to indicate the =A1=AEUser-Type=A1=AF sounds a more stra=
ight
> manner and will have the potential extensibility to prevent this kind of
> ambiguity, which has been proposed in  section 4.1 of
> draft-yeh-radext-dual-stack-access-02.
> =20
> The =A1=AEUser-Type=A1=AF can cover the following cases for both PPPoE and IPoE a=
ccess
> model by now.
> =20
> IPv4-only Host
> IPv6-only Host(Numbered by SLAAC)
> IPv6-only Host(Numbered by DHCPv6)
> IPv6-only Customer Router(Unnumbered)
> IPv6-only Customer Router(Numbered by SLAAC)
> IPv6-only Customer Router(Numbered by DHCPv6)
> Dual stack - IPv4 Host + IPv6 Host(Numbered by SLAAC)
> Dual stack - IPv4 Host + IPv6 Host(Numbered by DHCPv6)
> Dual stack - IPv4 Host + IPv6 Customer Router(Unnumbered)
> Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by SLAAC)
> Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by DHCPv6)
> =20
> Another usage (or design purpose) of =A1=AEUser-Type=A1=AF is for the default beh=
avior
> of the NAS. When the NAS has not received the pool-name attributes
> (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly ass=
ign
> the address/prefix from the default pools.
> =20
> Section 4.1 of draft-tan-v6ops-fast6-aaa-01 might give us a new reference=
.
> "User-Type" attribute can simplify the way how BRAS determines the user t=
ype.
> In addition, BRAS can allocate appropriate IP addresses for the user even
> without the address pool attribute sent by RADIUS serve, if default addre=
ss
> pool is defined by BRAS.
> =20
> =20
> Best Regards,
> Leaf
> =20
> =20
> =20
>=20
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2011 6:48 AM
> To: [email-masked]; Leaf yeh; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> Subject: RE: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IE=
TF81
> radext session
> =20
>=20
> In general, the concern that has lead to defining these distinct pools is=
 the
> possibility that multiple pool types might be enabled for a single sessio=
n.
> For example, it's possible that an IPv6 address might be assigned from a =
pool,
> and at the same time that a Prefix might be delegated from a pool, for th=
e
> same user and session.  In such a situation,  using the same pool name fo=
r
> multiple purposes could be ambiguous and/or under-specified.
>=20
> A note about Woj's concern about errors.  With respect to a server sendin=
g an
> attribute that a client does not understand, RFC 5080 Section 2.5 provide=
s
> guidance:
>    In general, it is best for a RADIUS client to err on the side of
>    caution.  On receiving an Access-Accept including an attribute of
>    known Type for an unimplemented service, a RADIUS client MUST treat
>    it as an Access-Reject, as directed in [RFC2865] Section 1.1
> <http://tools.ietf.org/html/rfc2865#section-1.1> .  On
>    receiving an Access-Accept including an attribute of unknown Type, a
>    RADIUS client SHOULD assume that it is a potential service
>    definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
>    ignored by RADIUS clients.
> As a result, it is possible that a client not implementing the IPv6 Acces=
s RFC
> will ignore the attributes (e.g. not implement the SHOULD) rather than
> refusing to provide service.
>=20
>=20
> Date: Mon, 1 Aug 2011 12:47:38 -0400
> Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IE=
TF81
> radext session
> From: [email-masked]
> To: [email-masked]; [email-masked]; jacniq@gmai=
l.com
> CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
>=20
> Hi All,
>=20
> Allow me to share some comments:
> * There is precedent of multiple =A1=B0specific=A1=B1 named pools; Framed-Pool,
> Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There i=
s
> also a special code in the Framed-IPX-Network attribute that conveys it p=
ool
> like characteristics.
> * There is little that disallows a vendor from implementing just one name=
d
> pool for all protocols and all methods of assignment ( the Framed-Pool ap=
pears
> to have been envisaged for that ) and then using some implementation spec=
ific
> logic (eg parsing for a name) to figure out/how it=A1=AFs to be used.
> * The problem with relying on implementation specific features riding on
> standard Attributes, as opposed to say VSAs, is that nothing indicates to=
 the
> server/client if the recipient actually supports such special features an=
d
> assures correct interpretation. Eg if we used the Framed-Pool as the ONE =
named
> pool attribute, with a carried string =A1=B0IPv4=A1=B1, =A1=B0IPv6=A1=B1 or =A1=B0DHCPv6-PD=A1=B1=
, etc,
> parsed/whatever to indicate the role, it would be all doable, but a likel=
y
> mess should anything go wrong (eg a device not supporting some mode), wit=
hout
> clear indication of error.
>=20
> Since the Radius specification is NOT about specifying implementation the=
 only
> reliable/unambiguous manner in which different pools/methods can be utili=
zed
> would appear to be using different attributes as proposed in the current
> draft. Time (precedent) also appears to have proved this as a desirable
> protocol characteristic.
> Are there any other options/solutions available that do not call on impli=
cit
> features being there?
>=20
> Regards,
> Wojciech.
>=20
>=20
> On 26/07/2011 22:51, "Leaf yeh" <[email-masked]
> <http://[email-masked]> > wrote:
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> I supposed the local configuration on the NAS will answer this question.
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
>=20
> =20
>=20
>=20
> From: Leaf yeh [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 21.50
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
>=20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> The pools configured on the NAS are not necessary to be the same. AAA ser=
ver
> doesn't really need to instruct the NAS the specified type of pools, whic=
h is
> already configured on the NAS. Right?
>=20
> =20
>=20
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> Roberta
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Please see inline.
>=20
> Best regards,
> Roberta
>=20
>=20
> From: Leaf yeh [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 20.22
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
>=20
>=20
> Roberta - If you use the same attribute for both scenarios how does the N=
AS
> know if that pool is for SLAAC or for Stateful DHCPv6?
>=20
> NAS already has those pool names in its configuration, right?
>=20
> [RM] yes pools are already configured in the NAS
>=20
> =20
>=20
> NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6
> address pool.=20
>=20
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> That=A1=AFs why in my opinion the Stateful-IPv6-Address-Pool is required.
>=20
> =20
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
> =B5=BD: 'Jacni Qin'
> Cc: Leaf yeh; [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Hi Jacni,
>    If you use the same attribute for both scenarios how does the NAS know=
 if
> that pool is for SLAAC or for Stateful DHCPv6?
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: Jacni Qin [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 20.03
> To: Maglione Roberta
> Cc: Leaf yeh; [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext
> session
>=20
> Hi Roberta,
>=20
> I agree with you about the semantical logic, while
> "Stateful-IPv6-Address-Pool" is not necessary, IMHO.
>=20
>=20
> Cheers,
> Jacni
> On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta
> <[email-masked] <http://roberta.maglione@telecomitalia=
.it>
> > wrote:
> Hello Leaf,
>     The different attributes proposed in this draft for the pools name ha=
ve
> all the same format (a string), but semantically they are different, as t=
hey
> coved different scenarios.
> As you also summarized in your email below,
>=20
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
>=20
> So each attribute covers a different use-case/scenario and they can appea=
r in
> the same RADIUS packet at the same time.
> If you want to use a single pool name use to cover all the 4 use cases li=
sted
> above, you would also need to define a standard format/syntax for the poo=
l
> name that allows the NAS to be able to disambiguate among the different
> scenarios and in order to do that the NAS would need to have an extra log=
ic to
> infer the semantic of that specific attribute from the assigned name.
> Instead if you have a specific attribute for each specific scenario, the
> semantic is mapped to the attribute name, thus the NAS does not need an e=
xtra
> logic to discovery the purpose of that pool and the pool name can be any
> string, no limitation or special syntax is forced for the pool name.
>=20
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: [email-masked] <http://[email-masked]>
> [mailto:[email-masked]] On Behalf Of Leaf yeh
> Sent: luned=A8=AC 25 luglio 2011 18.23
> To: [email-masked]
> <http://[email-masked]> ; [email-masked]=
f.org
> <http://[email-masked]>
> Cc: [email-masked] <http://[email-masked]> ; Qiujin; Wangshuxiang
> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex=
t
> session
>=20
> Question for clarification:
>=20
> We already have the following Radius Attributes for the address/prefix po=
ols:
>=20
> Framed-Pool (88, section 5.18 of RFC2869),
> Framed-IPv6-Pool (100, section 2.6 of RFC3162).
>=20
> http://www.iana.org/assignments/radius-types/radius-types.xml
>=20
> The foramt are the same as follows:
>=20
> 0                   1                   2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     Type      |    Length     |     String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for
> address/prefix pools:
>=20
> Delegated-IPv6-Prefix-Pool,
> Stateful-IPv6-Address-Pool,
>=20
> the fomat of these 2 attributes are the same as the above one.
>=20
>=20
> Supposed the above attributes could be explained as follows:
>=20
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
>=20
> All above attributes are only used to provide the name of the address/pre=
fix
> pools in a 'string'. I doubt the necessity to make so many 'name' or 'str=
ing'
> attributes for the different address/prefix pools to prevent the ambiguit=
y. I
> guess 1 attribute for the name of the address/prefix pools might be enoug=
h. In
> fact, the NAS take the role to interpret the meaning of the pook name, ri=
ght?
>=20
> I think Framed-Pool can be re-used for the design purpose of
> Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of
> Framed-Pool for IPv6?
> I think Framed-IPv6-Pool can be re-used for the design purpose of
> Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul=
d
> even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name =
of a
> IPv6 prefix/address pool per the same logic. Am I right?
>=20
>=20
> Best Regards,
> Leaf
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
> Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.
>=20
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>=20
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa=
 mail
> se non =A8=A8 necessario.
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa=
 mail
> se non =A8=A8 necessario.
>=20
>=20

--B_3396262154_11243562
Content-type: text/html;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hello Leaf,<BR>
<BR>
If I understand it correctly, you&#8217;re proposing that the end user/host=
 types be enumerated as part of a new attribute, which would then drive the =
addressing behavior, eg selection of pools. If so, it looks very much as rel=
ying on the special NAS feature to interpret *the contents* of the attribute=
 as to the pools to be used, only this time with the contents being laid dow=
n as the enumerated type code points in a draft. This does not help given a)=
 past precedent in terms of Radius pool definitions (there are already 2 poo=
ls, and they are being used), nor b) give &nbsp;the operator an explicit ind=
ication regarding the use of a pool, rather than implicit. <BR>
Besides the above, as with any enumerated type, issues will start should th=
ere be another combination that someone comes up with or wants...<BR>
<BR>
Frankly, other than it being another way of doing things, I personally don&=
#8217;t see much of a benefit.<BR>
<BR>
Regards,<BR>
Woj.<BR>
<BR>
<BR>
On 15/08/2011 13:19, &quot;Leaf yeh&quot; &lt;<a href=3D"[email-masked]=
m">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>Wojciech - There is little that d=
isallows a vendor from implementing just one named pool for all protocols an=
d all methods of assignment ( the Framed-Pool appears to have been envisaged=
 for that ) and then using some implementation specific logic (eg parsing fo=
r a name) to figure out/how it&#8217;s to be used. <BR>
&nbsp;<BR>
I agree.<BR>
&nbsp;<BR>
Wojciech - Since the Radius specification is NOT about specifying implement=
ation the only reliable/unambiguous manner in which different pools/methods =
can be utilized would appear to be using different attributes as proposed in=
 the current draft. Are there any other options/solutions available that do =
not call on implicit features being there?<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>A new attribute designed=
 to indicate the &#8216;User-Type&#8217; sounds a more straight manner and w=
ill have the potential extensibility to prevent this kind of ambiguity, whic=
h has been proposed in &nbsp;section 4.1 of draft-yeh-radext-dual-stack-acce=
ss-02.<BR>
&nbsp;<BR>
The &#8216;User-Type&#8217; can cover the following cases for both PPPoE an=
d IPoE access model by now.<BR>
&nbsp;<BR>
IPv4-only Host<BR>
IPv6-only Host(Numbered by SLAAC)<BR>
IPv6-only Host(Numbered by DHCPv6)<BR>
IPv6-only Customer Router(Unnumbered)<BR>
IPv6-only Customer Router(Numbered by SLAAC)<BR>
IPv6-only Customer Router(Numbered by DHCPv6)<BR>
Dual stack - IPv4 Host + IPv6 Host(Numbered by SLAAC)<BR>
Dual stack - IPv4 Host + IPv6 Host(Numbered by DHCPv6)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Unnumbered)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by SLAAC)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by DHCPv6)<BR>
&nbsp;<BR>
Another usage (or design purpose) of &#8216;User-Type&#8217; is for the def=
ault behavior of the NAS. When the NAS has not received the pool-name attrib=
utes (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly a=
ssign the address/prefix from the default pools. <BR>
&nbsp;<BR>
Section 4.1 of draft-tan-v6ops-fast6-aaa-01 might give us a new reference.<=
BR>
&quot;User-Type&quot; attribute can simplify the way how BRAS determines th=
e user type. &nbsp;In addition, BRAS can allocate appropriate IP addresses f=
or the user even without the address pool attribute sent by RADIUS serve, if=
 default address pool is defined by BRAS.<BR>
&nbsp;<BR>
&nbsp;<BR>
Best Regards,<BR>
Leaf<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Bernard Abo=
ba [<a href=3D"mailto:[email-masked]">mailto:bernard_aboba@hotmail.=
com</a>] <BR>
<B>Sent:</B> Wednesday, August 03, 2011 6:48 AM<BR>
<B>To:</B> <a href=3D"[email-masked]">[email-masked]</a>; Leaf yeh; <a href=3D"=
[email-masked]">[email-masked]</a>; <a=
 href=3D"[email-masked]">[email-masked]</a><BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a>; <a href=3D"[email-masked]">ra=
[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> RE: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access aft=
er IETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>In general, the concern =
that has lead to defining these distinct pools is the possibility that multi=
ple pool types might be enabled for a single session. &nbsp;For example, it'=
s possible that an IPv6 address might be assigned from a pool, and at the sa=
me time that a Prefix might be delegated from a pool, for the same user and =
session. &nbsp;In such a situation, &nbsp;using the same pool name for multi=
ple purposes could be ambiguous and/or under-specified. &nbsp;<BR>
<BR>
A note about Woj's concern about errors. &nbsp;With respect to a server sen=
ding an attribute that a client does not understand, RFC 5080 Section 2.5 pr=
ovides guidance:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'> &nbsp;&nbsp;In general, it is b=
est for a RADIUS client to err on the side of<BR>
&nbsp;&nbsp;&nbsp;caution. &nbsp;On receiving an Access-Accept including an=
 attribute of<BR>
&nbsp;&nbsp;&nbsp;known Type for an unimplemented service, a RADIUS client =
MUST treat<BR>
&nbsp;&nbsp;&nbsp;it as an Access-Reject, as directed in [RFC2865] Section =
1.1 &lt;<a href=3D"http://tools.ietf.org/html/rfc2865#section-1.1">http://tool=
s.ietf.org/html/rfc2865#section-1.1</a>&gt; . &nbsp;On<BR>
&nbsp;&nbsp;&nbsp;receiving an Access-Accept including an attribute of unkn=
own Type, a<BR>
&nbsp;&nbsp;&nbsp;RADIUS client SHOULD assume that it is a potential servic=
e<BR>
&nbsp;&nbsp;&nbsp;definition, and treat it as an Access-Reject. &nbsp;Unkno=
wn VSAs SHOULD be<BR>
&nbsp;&nbsp;&nbsp;ignored by RADIUS clients.<BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>As a result, it is possi=
ble that a client not implementing the IPv6 Access RFC will ignore the attri=
butes (e.g. not implement the SHOULD) rather than refusing to provide servic=
e. <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'>Date: Mon, 1 Aug 2011 12:47:38 -0400<BR>
Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF=
81 radext session<BR>
From: <a href=3D"[email-masked]">[email-masked]</a><BR>
To: <a href=3D"[email-masked]">[email-masked]</a>; <a href=3D"rob=
[email-masked]">[email-masked]</a>; <a hr=
ef=3D"[email-masked]">[email-masked]</a><BR>
CC: <a href=3D"[email-masked]">draft-ietf-radex=
[email-masked]</a>; <a href=3D"[email-masked]">radiusext=
@ops.ietf.org</a>; <a href=3D"[email-masked]">[email-masked]</a>; <a h=
ref=3D"[email-masked]">[email-masked]</a>; <a href=3D"wangshuxiang@huawei.=
com">[email-masked]</a><BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>Hi All,<BR>
<BR>
Allow me to share some comments:<BR>
</SPAN></FONT><UL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is precedent of multiple &#8220;specific&#8221=
; named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-=
IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network att=
ribute that conveys it pool like characteristics.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is little that disallows a vendor from implementin=
g just one named pool for all protocols and all methods of assignment ( the =
Framed-Pool appears to have been envisaged for that ) and then using some im=
plementation specific logic (eg parsing for a name) to figure out/how it&#82=
17;s to be used.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>The problem with relying on implementation specific feat=
ures riding on standard Attributes, as opposed to say VSAs, is that nothing =
indicates to the server/client if the recipient actually supports such speci=
al features and assures correct interpretation. Eg if we used the Framed-Poo=
l as the ONE named pool attribute, with a carried string &#8220;IPv4&#8221;,=
 &#8220;IPv6&#8221; or &#8220;DHCPv6-PD&#8221;, etc, parsed/whatever to indi=
cate the role, it would be all doable, but a likely mess should anything go =
wrong (eg a device not supporting some mode), without clear indication of er=
ror.<BR>
</SPAN></FONT></UL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
Since the Radius specification is NOT about specifying implementation the o=
nly reliable/unambiguous manner in which different pools/methods can be util=
ized would appear to be using different attributes as proposed in the curren=
t draft. Time (precedent) also appears to have proved this as a desirable pr=
otocol characteristic. <BR>
Are there any other options/solutions available that do not call on implici=
t features being there?<BR>
<BR>
Regards,<BR>
Wojciech.<BR>
<BR>
<BR>
On 26/07/2011 22:51, &quot;Leaf yeh&quot; &lt;<a href=3D"[email-masked]=
m">[email-masked]</a> &lt;<a href=3D"http://[email-masked]">http=
://[email-masked]</a>&gt; &gt; wrote:<BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>[RM] NAS can have many p=
ools configured locally: how does the NAS know which pool is for SLAAC and w=
hich pool is for DHCPv6?<BR>
<BR>
&nbsp;<BR>
<BR>
I supposed the local configuration on the NAS will answer this question.<BR=
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
<B>=B7=A2=BC=FE=C8=CB:</B></SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> Maglione =
Roberta [<a href=3D"[email-masked]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[email-masked]">http:/=
/[email-masked]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 3:54<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-radex=
[email-masked]">http://[email-masked]=
f.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> =
&lt;<a href=3D"http://[email-masked]">http://[email-masked]</a=
>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"htt=
p://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
&nbsp;
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Leaf yeh [<=
a href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 21.50<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-radex=
[email-masked]">http://[email-masked]=
f.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> =
&lt;<a href=3D"http://[email-masked]">http://[email-masked]</a=
>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"htt=
p://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>Subject:</B> =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after I=
ETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><BR>
[RM] All the configured pools are the same for the NAS, in this case an ext=
ra logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd which one is for DHCPv6<BR>
<BR>
&nbsp;<BR>
<BR>
The pools configured on the NAS are not necessary to be the same. AAA serve=
r doesn't really need to instruct the NAS the specified type of pools, which=
 is already configured on the NAS. Right?<BR>
<BR>
&nbsp;<BR>
<BR>
[RM] NAS can have many pools configured locally: how does the NAS know whic=
h pool is for SLAAC and which pool is for DHCPv6?<BR>
<BR>
&nbsp;<BR>
<BR>
Roberta<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>=B7=A2=BC=FE=C8=CB:</B> Maglione =
Roberta [<a href=3D"[email-masked]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[email-masked]">http:/=
/[email-masked]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 2:27<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-radex=
[email-masked]">http://[email-masked]=
f.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> =
&lt;<a href=3D"http://[email-masked]">http://[email-masked]</a=
>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"htt=
p://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
Please see inline.<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>Best regards,<BR>
Roberta<BR>

</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[email-masked]=
m">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 20.22<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-radex=
[email-masked]">http://[email-masked]=
f.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> =
&lt;<a href=3D"http://[email-masked]">http://[email-masked]</a=
>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"htt=
p://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>Subject:</B> =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after I=
ETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><BR>
Roberta - If you use the same attribute for both scenarios how does the NAS=
 know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
NAS already has those pool names in its configuration, right?<BR>
<BR>
[RM] yes pools are already configured in the NAS<BR>
<BR>
&nbsp;<BR>
<BR>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 a=
ddress pool. <BR>
<BR>
&nbsp;<BR>
<BR>
[RM] All the configured pools are the same for the NAS, in this case an ext=
ra logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd which one is for DHCPv6<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
That&#8217;s why in my opinion the Stateful-IPv6-Address-Pool is required.<=
BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>=B7=A2=BC=FE=C8=CB:</B> Maglione =
Roberta [<a href=3D"[email-masked]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[email-masked]">http:/=
/[email-masked]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 2:13<BR>
<B>=B5=BD:</B> 'Jacni Qin'<BR>
<B>Cc:</B> Leaf yeh; <a href=3D"[email-masked]"=
>[email-masked]</a> &lt;<a href=3D"http://draft-=
[email-masked]">http://draft-ietf-radext-ipv6-access=
@tools.ietf.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]=
f.org</a> &lt;<a href=3D"http://[email-masked]">http://[email-masked]=
etf.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a=
 href=3D"http://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin=
; Wangshuxiang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
Hi Jacni,<BR>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does=
 the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: Jacni Qin [<a href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/a>]<BR>
Sent: marted&igrave; 26 luglio 2011 20.03<BR>
To: Maglione Roberta<BR>
Cc: Leaf yeh; <a href=3D"[email-masked]">draft-=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-ra=
[email-masked]">http://draft-ietf-radext-ipv6-access@tools.=
ietf.org</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</=
a> &lt;<a href=3D"http://[email-masked]">http://[email-masked]=
</a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"=
http://[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangs=
huxiang<BR>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad=
ext session<BR>
<BR>
Hi Roberta,<BR>
<BR>
I agree with you about the semantical logic, while &quot;Stateful-IPv6-Addr=
ess-Pool&quot; is not necessary, IMHO.<BR>
<BR>
<BR>
Cheers,<BR>
Jacni<BR>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href=3D"roberta.magl=
[email-masked]">[email-masked]</a> &lt;<a href=3D"ht=
tp://[email-masked]">http://roberta.maglione@telecomitali=
a.it</a>&gt; &gt; wrote:<BR>
Hello Leaf,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for=
 the pools name have all the same format (a string), but semantically they a=
re different, as they coved different scenarios.<BR>
As you also summarized in your email below,<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
So each attribute covers a different use-case/scenario and they can appear =
in the same RADIUS packet at the same time.<BR>
If you want to use a single pool name use to cover all the 4 use cases list=
ed above, you would also need to define a standard format/syntax for the poo=
l name that allows the NAS to be able to disambiguate among the different sc=
enarios and in order to do that the NAS would need to have an extra logic to=
 infer the semantic of that specific attribute from the assigned name.<BR>
Instead if you have a specific attribute for each specific scenario, the se=
mantic is mapped to the attribute name, thus the NAS does not need an extra =
logic to discovery the purpose of that pool and the pool name can be any str=
ing, no limitation or special syntax is forced for the pool name.<BR>
<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: <a href=3D"[email-masked]">[email-masked]</=
a> &lt;<a href=3D"http://[email-masked]">http://owner-radiusext@=
ops.ietf.org</a>&gt; &nbsp;[<a href=3D"mailto:[email-masked]">ma=
ilto:[email-masked]</a>] On Behalf Of Leaf yeh<BR>
Sent: luned&igrave; 25 luglio 2011 18.23<BR>
To: <a href=3D"[email-masked]">draft-ietf-radex=
[email-masked]</a> &lt;<a href=3D"http://draft-ietf-radext-ipv6-=
[email-masked]">http://[email-masked]</=
a>&gt; ; <a href=3D"[email-masked]">[email-masked]</a> &lt;<a =
href=3D"http://[email-masked]">http://[email-masked]</a>&gt; <=
BR>
Cc: <a href=3D"[email-masked]">[email-masked]</a> &lt;<a href=3D"http:/=
/[email-masked]">http://[email-masked]</a>&gt; ; Qiujin; Wangshuxian=
g<BR>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext =
session<BR>
<BR>
Question for clarification:<BR>
<BR>
We already have the following Radius Attributes for the address/prefix pool=
s:<BR>
<BR>
Framed-Pool (88, section 5.18 of RFC2869),<BR>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<BR>
<BR>
<a href=3D"http://www.iana.org/assignments/radius-types/radius-types.xml">htt=
p://www.iana.org/assignments/radius-types/radius-types.xml</a><BR>
<BR>
The foramt are the same as follows:<BR>
<BR>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<BR>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;=
&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
<BR>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/=
prefix pools:<BR>
<BR>
Delegated-IPv6-Prefix-Pool,<BR>
Stateful-IPv6-Address-Pool,<BR>
<BR>
the fomat of these 2 attributes are the same as the above one.<BR>
<BR>
<BR>
Supposed the above attributes could be explained as follows:<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
All above attributes are only used to provide the name of the address/prefi=
x pools in a 'string'. I doubt the necessity to make so many 'name' or 'stri=
ng' attributes for the different address/prefix pools to prevent the ambigui=
ty. I guess 1 attribute for the name of the address/prefix pools might be en=
ough. In fact, the NAS take the role to interpret the meaning of the pook na=
me, right?<BR>
<BR>
I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-=
Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6=
?<BR>
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated=
-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think=
 Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 pre=
fix/address pool per the same logic. Am I right?<BR>
<BR>
<BR>
Best Regards,<BR>
Leaf<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla=
 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
Rispetta l'ambiente. Non stampare questa mail se non &egrave; necessario.<B=
R>
<BR>
<BR>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla=
 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
<BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:7pt'>Questo messaggio e=
 i suoi allegati sono indirizzati esclusivamente alle persone indicate. La d=
iffusione, copia o qualsiasi altra azione derivante dalla conoscenza di ques=
te informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo =
documento per errore siete cortesemente pregati di darne immediata comunicaz=
ione al mittente e di provvedere alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:7pt'>Questo messaggio e i suoi=
 allegati sono indirizzati esclusivamente alle persone indicate. La diffusio=
ne, copia o qualsiasi altra azione derivante dalla conoscenza di queste info=
rmazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documen=
to per errore siete cortesemente pregati di darne immediata comunicazione al=
 mittente e di provvedere alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3396262154_11243562--

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

Delivery-date: Mon, 15 Aug 2011 11:44:52 +0000
Date: Mon, 15 Aug 2011 11:43:31 +0000 (UTC)
From: "David B. Nelson" <[email-masked]>
To: Leaf yeh <[email-masked]>
Cc: [email-masked], [email-masked],  fine sz <[email-masked]>, Qiujin <[email-masked]>,  Wangshuxiang <[email-masked]>,  [email-masked], [email-masked],  roberta maglione <[email-masked]>,  [email-masked], Bernard Aboba <[email-masked]>
Subject: =?utf-8?Q?Re:_=E7=AD=94=E5=A4=8D:_Q_on_Ver.-05_of_draft-ietf-radex?= =?utf-8?Q?t-ipv6-access_after_IETF81_radext_session?=

> The =E2=80=98User-Type=E2=80=99 can cover the following cases for both
> PPPoE and IPoE access model by now.

The proposed values for this attribute seem to describe properties of the a=
ttached host.  In RADIUS, the term "user" refers to a human, for whom accou=
nt and service provisioning has been established.  I would suggest calling =
this proposed attribute something else, more accurately descriptive.=20

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

Delivery-date: Mon, 15 Aug 2011 11:20:49 +0000
Date: Mon, 15 Aug 2011 11:19:20 +0000
From: Leaf yeh <[email-masked]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: zh-CN, en-US

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)--

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

Delivery-date: Fri, 05 Aug 2011 21:54:56 +0000
Date: Fri, 05 Aug 2011 17:53:48 -0400
From: Alan DeKok <[email-masked]>
To: Peter Deacon <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

Peter Deacon wrote:
> This was never my intention.  My intention was a couple of paragraphs to
> explain a new data type attribute designers may want to take advantage
> of for their *future* work while implementing new attributes in the new
> attribute space.

  If it's in the doc, people will use it.  We need to agree that it's a
good idea before it's standardized.

  Alan DeKok.

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

Delivery-date: Fri, 05 Aug 2011 16:21:44 +0000
Date: Fri, 5 Aug 2011 09:20:49 -0700 (Pacific Daylight Time)
From: Peter Deacon <[email-masked]>
To: Avi Lior <[email-masked]>
cc: Alan DeKok <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

On Fri, 5 Aug 2011, Avi Lior wrote:

> I also support the notion of having a "family-specific" attribute set.

I'm sorry for any confusion.  The intent was never to "take away" any 
options that already exist.  I certainly am not suggesting any current 
attributes be changed in any way.

All I suggested is that a new "data type" be specified allowing single IP 
Addresses to be conveyed in either IPv4 or IPv6 address family.

It would be up to the designer of a new attribute to weigh the pros and 
cons and select the appropriate data type.  This would simply be another 
tool in the extensions toolbox at their disposal.

> My reasons are somewhat different.
> In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
> the argument for having a single attribute to carry both makes sense.

My recommendation is limited to anything that would currently fit in the 
IPv4 or IPv6 address data types.

regards,
Peter

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

Delivery-date: Fri, 05 Aug 2011 15:52:17 +0000
Date: Fri, 5 Aug 2011 08:51:19 -0700 (Pacific Daylight Time)
From: Peter Deacon <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

On Fri, 5 Aug 2011, Alan DeKok wrote:

>> Use of naming services to abstract network addresses is universal.  Kind
>> of the whole point of using these systems in the first place.

>  What I meant was that *unexpected* changes are a problem.  DNS is
> nice, and useful for many things.  RADIUS policies are usually
> relatively fixed.  Having them depend on DNS means that a non-RADIUS
> admin can effectively update the RADIUS policies.

>  I've seen this cause problems in practice, which makes me wary of it.

By specifying a name you delegate responsibility for resolution to the 
naming service.  This is always the case no matter where that name is 
stored.

>> Without combo IP the system needs *extra* intelligence to know the IPv4
>> and IPv6 analogue for each attribute.  With combo IP this is unnecessary
>> as the same attribute can be used and the system just works.

>  The main way I can see combo IP being useful is if family-specific
> attributes were to be deprecated.

>  Unless there's a groundswell of support for it on this list, I don't
> see combo-IP making it into the document.

This was never my intention.  My intention was a couple of paragraphs to 
explain a new data type attribute designers may want to take advantage of 
for their *future* work while implementing new attributes in the new 
attribute space.

regards,
Peter

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

Delivery-date: Fri, 05 Aug 2011 15:25:39 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>, Peter Deacon <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Date: Fri, 5 Aug 2011 11:24:46 -0400
Subject: Re: Last call on extensions document?
Accept-Language: en-US
acceptlanguage: en-US

I also support the notion of having a "family-specific" attribute set.

My reasons are somewhat different.

In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
the argument for having a single attribute to carry both makes sense.

However, IPv6 addresses have different flavours.  Sometime I want to carry
a "pure" IPv6 address, sometimes I want to convey just the prefix and
sometimes I want to convey the prefix and the interface and thus I need to
include the prefix length in the address.  There are examples of these
encodings already in the IETF.

A family-specific approach is good.  Thus if we want to create such a
beast for IPv6 addresses we should create an attribute that can meet all
the use cases or have an attribute type for each use case.

Avi

On 11-08-04 20:52 , "Alan DeKok" <[email-masked]> wrote:

>Peter Deacon wrote:
>> In most cases where an attribute of type IP Address needs to be defined
>> there will be a need for an IPv6 analogue of that same attribute.
>
>  OK.
>
>> There are implementation costs and operational costs associated with the
>> approach of segregating address families.  Costs can be reduced somewhat
>> with a ComboIP (Payload Len 4 =3D IPv4, 16 =3D IPv6) data type.
>>=20
>> Currently:
>>=20
>> 1. Multiple attributes need to be defined.
>
>  With 1000+ new attributes and TLVs, I'm not sure this is an issue.
>
>> 2. Operators entering an IP Address into fields need to make sure they
>> select the correct attribute based on the address family they are
>> targeting.
>
>  That's a UI problem.  The system in which they enter the IP should
>know (a) the address family, and (b) the relevant attribute.  There's no
>reason to force the admin to make those choices.
>
>> Operators may enter a hostname and have the system enter the resolved
>> address.  In this case the operator may have no knowledge of the address
>> family or it may change tomorrow!
>
>  Which is a disaster for maintainable systems.  Having the RADIUS
>response change because of modifications to DNS is terrible.  I strongly
>oppose that kind of setup.
>
>> The system will need to provide additional intelligence during the name
>> lookup process to select the proper attribute based on address family
>> for each instance.
>
>  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.
>
>  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
>send that in RADIUS?
>
>> We can live without however much like gigawords I believe with the new
>> attribute space comes some opportunity to improve the standard framework
>> for future attributes.
>
>  Of course.
>
>  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
>above use-cases *require* it.  The same result can be achieved with
>family-specific attributes.
>
>  Alan DeKok.
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Fri, 05 Aug 2011 11:48:32 +0000
Date: Fri, 05 Aug 2011 07:47:32 -0400
From: Alan DeKok <[email-masked]>
To: Peter Deacon <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

Peter Deacon wrote:
>>  Which is a disaster for maintainable systems.  Having the RADIUS
>> response change because of modifications to DNS is terrible.  I strongly
>> oppose that kind of setup.
> 
> Use of naming services to abstract network addresses is universal.  Kind
> of the whole point of using these systems in the first place.

  What I meant was that *unexpected* changes are a problem.  DNS is
nice, and useful for many things.  RADIUS policies are usually
relatively fixed.  Having them depend on DNS means that a non-RADIUS
admin can effectively update the RADIUS policies.

  I've seen this cause problems in practice, which makes me wary of it.

> Without combo IP the system needs *extra* intelligence to know the IPv4
> and IPv6 analogue for each attribute.  With combo IP this is unnecessary
> as the same attribute can be used and the system just works.

  The main way I can see combo IP being useful is if family-specific
attributes were to be deprecated.

  Unless there's a groundswell of support for it on this list, I don't
see combo-IP making it into the document.

  Alan DeKok.

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

Delivery-date: Fri, 05 Aug 2011 04:57:48 +0000
Date: Thu, 4 Aug 2011 21:45:25 -0700 (Pacific Daylight Time)
From: Peter Deacon <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

On Thu, 4 Aug 2011, Alan DeKok wrote:

> Peter Deacon wrote:
>> In most cases where an attribute of type IP Address needs to be defined
>> there will be a need for an IPv6 analogue of that same attribute.

>> There are implementation costs and operational costs associated with the
>> approach of segregating address families.  Costs can be reduced somewhat
>> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.

>> Currently:
>> 1. Multiple attributes need to be defined.

>  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

It is unecessary, redundant and wasteful.

>> 2. Operators entering an IP Address into fields need to make sure they
>> select the correct attribute based on the address family they are
>> targeting.

>  That's a UI problem.  The system in which they enter the IP should
> know (a) the address family, and (b) the relevant attribute.  There's no
> reason to force the admin to make those choices.

Its a problem that does not need to exist.  Regardless of where you punt 
for those attributes taking advantage of combo IP the issue goes away.

>> Operators may enter a hostname and have the system enter the resolved
>> address.  In this case the operator may have no knowledge of the address
>> family or it may change tomorrow!

>  Which is a disaster for maintainable systems.  Having the RADIUS
> response change because of modifications to DNS is terrible.  I strongly
> oppose that kind of setup.

Use of naming services to abstract network addresses is universal.  Kind 
of the whole point of using these systems in the first place.

>> The system will need to provide additional intelligence during the name
>> lookup process to select the proper attribute based on address family
>> for each instance.

>  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

>  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
> send that in RADIUS?

Of course you can enumerate the result of name lookups and send multiple 
attributes if there are multiple results.  I never suggested otherwise.

Without combo IP the system needs *extra* intelligence to know the IPv4 
and IPv6 analogue for each attribute.  With combo IP this is unnecessary as 
the same attribute can be used and the system just works.

>> We can live without however much like gigawords I believe with the new
>> attribute space comes some opportunity to improve the standard framework
>> for future attributes.
>
>  Of course.
>
>  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
> above use-cases *require* it.  The same result can be achieved with
> family-specific attributes.

64-bit integers are not required to convey 64-bit data types.  There are 
thousands of attributes available.  The same result can be achieved with 
gigawords.

*require* is not the point.  I think this was made pretty clear in the "we 
can live without" language used above.

regards,
Peter

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

Delivery-date: Fri, 05 Aug 2011 00:52:54 +0000
Date: Thu, 04 Aug 2011 20:52:00 -0400
From: Alan DeKok <[email-masked]>
To: Peter Deacon <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

Peter Deacon wrote:
> In most cases where an attribute of type IP Address needs to be defined
> there will be a need for an IPv6 analogue of that same attribute.

  OK.

> There are implementation costs and operational costs associated with the
> approach of segregating address families.  Costs can be reduced somewhat
> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.
> 
> Currently:
> 
> 1. Multiple attributes need to be defined.

  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

> 2. Operators entering an IP Address into fields need to make sure they
> select the correct attribute based on the address family they are
> targeting.

  That's a UI problem.  The system in which they enter the IP should
know (a) the address family, and (b) the relevant attribute.  There's no
reason to force the admin to make those choices.

> Operators may enter a hostname and have the system enter the resolved
> address.  In this case the operator may have no knowledge of the address
> family or it may change tomorrow!

  Which is a disaster for maintainable systems.  Having the RADIUS
response change because of modifications to DNS is terrible.  I strongly
oppose that kind of setup.

> The system will need to provide additional intelligence during the name
> lookup process to select the proper attribute based on address family
> for each instance.

  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
send that in RADIUS?

> We can live without however much like gigawords I believe with the new
> attribute space comes some opportunity to improve the standard framework
> for future attributes.

  Of course.

  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
above use-cases *require* it.  The same result can be achieved with
family-specific attributes.

  Alan DeKok.

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

Delivery-date: Thu, 04 Aug 2011 17:54:52 +0000
Date: Thu, 4 Aug 2011 10:53:24 -0700 (Pacific Daylight Time)
From: Peter Deacon <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

On Tue, 2 Aug 2011, Alan DeKok wrote:

>> As IPv6 is deployed following the current scheme of keeping address
>> families separated into separate attributes wherever addresses are used
>> will become problematic as cases where the address family is not known
>> in advance creep up.

>  My $0.02 is that it would be better to use TLVs.  But I welcome an
> inspired discussion on the topic. :)

In most cases where an attribute of type IP Address needs to be defined 
there will be a need for an IPv6 analogue of that same attribute.

Some examples:

Naming services
Access control and filtering
Flow export and logging servers
Application proxies (smtp, web content filter..etc)
App specific services

There are implementation costs and operational costs associated with the 
approach of segregating address families.  Costs can be reduced somewhat 
with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.

Currently:

1. Multiple attributes need to be defined.

2. Operators entering an IP Address into fields need to make sure they 
select the correct attribute based on the address family they are 
targeting.

Operators may enter a hostname and have the system enter the resolved 
address.  In this case the operator may have no knowledge of the address 
family or it may change tomorrow!

The system will need to provide additional intelligence during the name 
lookup process to select the proper attribute based on address family for 
each instance.

We can live without however much like gigawords I believe with the new 
attribute space comes some opportunity to improve the standard framework 
for future attributes.

regards,
Peter

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

Delivery-date: Wed, 03 Aug 2011 02:36:37 +0000
Date: Tue, 02 Aug 2011 22:35:42 -0400
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: i18n and RADIUS

  As discussed at the last IETF, RFC 4282 has some problems.  My draft
(expired) describes the issues, and proposes a way to address them.

  The Precis working group is looking at i18n issues across a wide
variety of protocols.  The framework document applies to RADIUS and to
EAP, though neither is explicitly mentioned:

http://tools.ietf.org/id/draft-blanchet-precis-framework-02.txt

  I'd recommend reading Section 3, which defines stringprep "classes"
for names and secrets.  Section 10 deals with "confusable" strings, and
says that applications need to find a way to deal with them.

  It looks like the work in Precis will allow RADIUS and EAP to continue
with their current way of dealing with names and passwords.  Since
neither RADIUS nor EAP show strings to users, "confusable" strings can
be avoided in the protocol transport.

  Alan DeKok.

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

Delivery-date: Tue, 02 Aug 2011 22:49:24 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: =?gb2312?B?UkU6ILTwuLQ6IFEg?= =?gb2312?Q?on_Ver.-05?= =?gb2312?Q?_of_draft-?= =?gb2312?Q?ietf-radex?= =?gb2312?Q?t-ipv6-acc?= =?gb2312?Q?ess_after_?= =?gb2312?Q?IETF81_rad?= =?gb2312?Q?ext_sessio?= =?gb2312?Q?n?=
Date: Tue, 2 Aug 2011 15:48:13 -0700

--_9dea068e-fc81-4966-b73d-20faca6c3bed_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

In general, the concern that has lead to defining these distinct pools is the possibility that multiple pool types might be enabled for a single session.  For example, it's possible that an IPv6 address might be assigned from a pool, and at the same time that a Prefix might be delegated from a pool, for the same user and session.  In such a situation,  using the same pool name for multiple purposes could be ambiguous and/or under-specified.  

A note about Woj's concern about errors.  With respect to a server sending an attribute that a client does not understand, RFC 5080 Section 2.5 provides guidance:

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service. 

Date: Mon, 1 Aug 2011 12:47:38 -0400
Subject: Re: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Re: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Hi All,

Allow me to share some comments:

There is precedent of multiple ��specific�� named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics. 
There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it��s to be used. 
The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string ��IPv4��, ��IPv6�� or ��DHCPv6-PD��, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.

Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Time (precedent) also appears to have proved this as a desirable protocol characteristic. 

Are there any other options/solutions available that do not call on implicit features being there?

Regards,

Wojciech.

On 26/07/2011 22:51, "Leaf yeh" <[email-masked]> wrote:

[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?

I supposed the local configuration on the NAS will answer this question.

Best Regards,

Leaf

 

������: Maglione Roberta [[email-masked]]

����ʱ��: 2011��7��27�� 3:54

��: Leaf yeh; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

����: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

From: Leaf yeh [mailto:[email-masked]] 

Sent: marted�� 26 luglio 2011 21.50

To: Maglione Roberta; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

Subject: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6

The pools configured on the NAS are not necessary to be the same. AAA server doesn't really need to instruct the NAS the specified type of pools, which is already configured on the NAS. Right?

[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?

Roberta

Best Regards,

Leaf

 

������: Maglione Roberta [[email-masked]]

����ʱ��: 2011��7��27�� 2:27

��: Leaf yeh; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

����: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Please see inline.

Best regards,

Roberta

From: Leaf yeh [mailto:[email-masked]] 

Sent: marted�� 26 luglio 2011 20.22

To: Maglione Roberta; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

Subject: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Roberta - If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?

[RM] yes pools are already configured in the NAS

NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 address pool. 

[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6

 

That��s why in my opinion the Stateful-IPv6-Address-Pool is required.

 

Best Regards,

Leaf

 

������: Maglione Roberta [[email-masked]]

����ʱ��: 2011��7��27�� 2:13

��: 'Jacni Qin'

Cc: Leaf yeh; [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

����: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Hi Jacni,

   If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,

Regards,

Roberta

________________________________________

From: Jacni Qin [mailto:[email-masked]]

Sent: marted�� 26 luglio 2011 20.03

To: Maglione Roberta

Cc: Leaf yeh; [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO.

Cheers,

Jacni

On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <[email-masked]> wrote:

Hello Leaf,

    The different attributes proposed in this draft for the pools name have all the same format (a string), but semantically they are different, as they coved different scenarios.

As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;

Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear in the same RADIUS packet at the same time.

If you want to use a single pool name use to cover all the 4 use cases listed above, you would also need to define a standard format/syntax for the pool name that allows the NAS to be able to disambiguate among the different scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each specific scenario, the semantic is mapped to the attribute name, thus the NAS does not need an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitation or special syntax is forced for the pool name.

Thanks,

Regards,

Roberta

________________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf yeh

Sent: luned�� 25 luglio 2011 18.23

To: [email-masked]; [email-masked]

Cc: [email-masked]; Qiujin; Wangshuxiang

Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pools:

Framed-Pool (88, section 5.18 of RFC2869),

Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.xml

The foramt are the same as follows:

0                   1                   2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type      |    Length     |     String...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:

Delegated-IPv6-Prefix-Pool,

Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.

Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;

Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right?

Best Regards,

Leaf

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non �� necessario.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non �� necessario. 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non �� necessario. 

--_9dea068e-fc81-4966-b73d-20faca6c3bed_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
In general, the concern that has lead to defining these distinct pools is the possibility that multiple pool types might be enabled for a single session.&nbsp; For example, it's possible that an IPv6 address might be assigned from a pool, and at the same time that a Prefix might be delegated from a pool, for the same user and session.&nbsp; In such a situation,&nbsp; using the same pool name for multiple purposes could be ambiguous and/or under-specified.&nbsp; <br><br>A note about Woj's concern about errors.&nbsp; With respect to a server sending an attribute that a client does not understand, RFC 5080 Section 2.5 provides guidance:<br><br><pre class="newpage">   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in <a href="http://tools.ietf.org/html/rfc2865#section-1.1">[RFC2865] Section&nbsp;1.1</a>.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.</pre>As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service. <br><br><div><hr id="stopSpelling">Date: Mon, 1 Aug 2011 12:47:38 -0400<br>Subject: Re: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>From: [email-masked]<br>To: [email-masked]; [email-masked]; [email-masked]<br>CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]<br><br>

<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<title>Re: ��: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session</title>

<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hi All,<br>
<br>
Allow me to share some comments:<br>
<br>
</span></font><ul><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There is precedent of multiple ��specific�� named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics. 
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it��s to be used. 
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string ��IPv4��, ��IPv6�� or ��DHCPv6-PD��, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.<br>
</span></font></li></ul><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Time (precedent) also appears to have proved this as a desirable protocol characteristic. <br>
Are there any other options/solutions available that do not call on implicit features being there?<br>
<br>
Regards,<br>
Wojciech.<br>
<br>
<br>
On 26/07/2011 22:51, "Leaf yeh" &lt;<a href="http://[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
</span></font><blockquote><font color="#000080"><font size="2"><font face="Arial"><span style="font-size:10pt">[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?<br>
</span></font></font></font><font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
I supposed the local configuration on the NAS will answer this question.<br>
<br>
&nbsp;<br>
<br>
Best Regards,<br>
<br>
Leaf<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
<hr align="CENTER" size="3" width="100%"></font></span></font><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:11pt"><b>������:</b></span><font size="2"><span style="font-size:10pt"> Maglione Roberta [<a href="http://[email-masked]" target="_blank">[email-masked]</a>]<br>
<b>����ʱ��:</b> 2011��7��27�� 3:54<br>
<b>��:</b> Leaf yeh; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
<b>����:</b> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
&nbsp;<br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">
</span></font></font>
<p align="CENTER">
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><b>From:</b> Leaf yeh [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
<b>Sent:</b> marted�� 26 luglio 2011 21.50<br>
<b>To:</b> Maglione Roberta; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
<b>Subject:</b> </span></font><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
</font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
</span></font><span style="font-size:10pt"><font color="#000080"><font face="Arial">[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">The pools configured on the NAS are not necessary to be the same. AAA server doesn't really need to instruct the NAS the specified type of pools, which is already configured on the NAS. Right?<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">Roberta<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">Best Regards,<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
</font><font color="#000080"><font face="Arial">Leaf<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>

</font></span></font>
<BR><p align="CENTER">
<font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"></font></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial"><b>������</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Maglione Roberta [<a href="http://[email-masked]" target="_blank">[email-masked]</a>]<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>����ʱ��</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 2011</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">7</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">27</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial"> 2:27<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>��</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Leaf yeh; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>����</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
</font><font color="#000080"><font face="Arial">Please see inline.<br>
</font></font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font color="#000080"><font size="2"><font face="Arial"><span style="font-size:10pt">Best regards,<br>
Roberta<br>
</span></font></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">
</span></font></font>
<BR><p align="CENTER">
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><b>From:</b> Leaf yeh [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
<b>Sent:</b> marted�� 26 luglio 2011 20.22<br>
<b>To:</b> Maglione Roberta; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
<b>Subject:</b> </span></font><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
</font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
Roberta - If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<br>
<br>
NAS already has those pool names in its configuration, right?<br>
<br>
</span></font><span style="font-size:10pt"><font color="#000080"><font face="Arial">[RM] yes pools are already configured in the NAS<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 address pool. <br>
<br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">That��s why in my opinion the Stateful-IPv6-Address-Pool is required.<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
Best Regards,<br>
<br>
Leaf<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>

</font></span></font>
<BR><p align="CENTER">
<font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"></font></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial"><b>������</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Maglione Roberta [<a href="http://[email-masked]" target="_blank">[email-masked]</a>]<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>����ʱ��</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 2011</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">7</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial">27</font><font face="Calibri, Verdana, Helvetica, Arial">��</font><font face="Tahoma, Verdana, Helvetica, Arial"> 2:13<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>��</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 'Jacni Qin'<br>
<b>Cc:</b> Leaf yeh; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>����</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Hi Jacni,<br>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<br>
<br>
Thanks,<br>
Regards,<br>
Roberta<br>
<br>
<br>
<br>
<br>
<br>
________________________________________<br>
From: Jacni Qin [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>
Sent: marted�� 26 luglio 2011 20.03<br>
To: Maglione Roberta<br>
Cc: Leaf yeh; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Hi Roberta,<br>
<br>
I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO.<br>
<br>
<br>
Cheers,<br>
Jacni<br>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href="http://[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
Hello Leaf,<br>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for the pools name have all the same format (a string), but semantically they are different, as they coved different scenarios.<br>
As you also summarized in your email below,<br>
<br>
Framed-Pool was designed for the IPv4 address pool;<br>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<br>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<br>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<br>
<br>
So each attribute covers a different use-case/scenario and they can appear in the same RADIUS packet at the same time.<br>
If you want to use a single pool name use to cover all the 4 use cases listed above, you would also need to define a standard format/syntax for the pool name that allows the NAS to be able to disambiguate among the different scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that specific attribute from the assigned name.<br>
Instead if you have a specific attribute for each specific scenario, the semantic is mapped to the attribute name, thus the NAS does not need an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitation or special syntax is forced for the pool name.<br>
<br>
<br>
Thanks,<br>
Regards,<br>
Roberta<br>
<br>
<br>
<br>
<br>
<br>
________________________________________<br>
From: <a href="http://[email-masked]" target="_blank">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Leaf yeh<br>
Sent: luned�� 25 luglio 2011 18.23<br>
To: <a href="http://[email-masked]" target="_blank">[email-masked]</a>; <a href="http://[email-masked]" target="_blank">[email-masked]</a><br>
Cc: <a href="http://[email-masked]" target="_blank">[email-masked]</a>; Qiujin; Wangshuxiang<br>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Question for clarification:<br>
<br>
We already have the following Radius Attributes for the address/prefix pools:<br>
<br>
Framed-Pool (88, section 5.18 of RFC2869),<br>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<br>
<br>
<a href="http://www.iana.org/assignments/radius-types/radius-types.xml" target="_blank">http://www.iana.org/assignments/radius-types/radius-types.xml</a><br>
<br>
The foramt are the same as follows:<br>
<br>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<br>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:<br>
<br>
Delegated-IPv6-Prefix-Pool,<br>
Stateful-IPv6-Address-Pool,<br>
<br>
the fomat of these 2 attributes are the same as the above one.<br>
<br>
<br>
Supposed the above attributes could be explained as follows:<br>
<br>
Framed-Pool was designed for the IPv4 address pool;<br>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<br>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<br>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<br>
<br>
All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right?<br>
<br>
I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6?<br>
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right?<br>
<br>
<br>
Best Regards,<br>
Leaf<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.<br>
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.<br>
Rispetta l'ambiente. Non stampare questa mail se non �� necessario.<br>
<br>
<br>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.<br>
<br>
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.<br>
<br>
</font></span></font><font size="1"><font face="Verdana, Helvetica, Arial"><span style="font-size:7pt">Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. <br>
<i>This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.</i></span><span style="font-size:9pt"> </span><span style="font-size:7pt"><b>Rispetta l'ambiente. Non stampare questa mail se non �� necessario.</b></span><span style="font-size:9pt"> <br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="1"><font face="Verdana, Helvetica, Arial"><span style="font-size:7pt">Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. <br>
<i>This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.</i></span><span style="font-size:9pt"> </span><span style="font-size:7pt"><b>Rispetta l'ambiente. Non stampare questa mail se non �� necessario.</b></span><span style="font-size:9pt"> <br>
</span></font></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
</span></font></font><BR></blockquote></div> 		 	   		  </div></body>
</html>
--_9dea068e-fc81-4966-b73d-20faca6c3bed_--

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

Delivery-date: Tue, 02 Aug 2011 21:37:26 +0000
Date: Tue, 02 Aug 2011 17:36:58 -0400
From: Alan DeKok <[email-masked]>
To: Peter Deacon <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

Peter Deacon wrote:
> Aside from picking up the 64-bit int type my crystal ball is saying
> there will be increasing need for Combo-IP like data type to convey
> either IPv4 or IPv6 address information in one attribute.

  Oh, that scares me.

> As IPv6 is deployed following the current scheme of keeping address
> families separated into separate attributes wherever addresses are used
> will become problematic as cases where the address family is not known
> in advance creep up.

  My $0.02 is that it would be better to use TLVs.  But I welcome an
inspired discussion on the topic. :)

> Vendors are using it in their VSA spaces so why not just add a few
> paragraphs.  I'll volunteer.  This way future attributes with an IP data
> type have the option if makes sense for them.

  So far as I know, it's only WiMAX that does this.

> Thought about suggesting it in the IPv6 draft but perhaps better for
> everyone to get that one done ASAP.

  If everyone else here thinks it's a good idea, fine.  But I'm not sure
that's going to happen.

  Alan DeKok.

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

Delivery-date: Tue, 02 Aug 2011 21:12:29 +0000
Date: Tue, 2 Aug 2011 14:11:18 -0700 (Pacific Daylight Time)
From: Peter Deacon <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: 'radext mailing list' <[email-masked]>
Subject: Re: Last call on extensions document?

On Tue, 26 Jul 2011, Alan DeKok wrote:

>  Can we do a last call on the extensions document?  The list has had
> little discussion on it.

>  I think the name will need to change, as RFC 2868 is already RADIUS
> extensions.

Aside from picking up the 64-bit int type my crystal ball is saying there 
will be increasing need for Combo-IP like data type to convey either IPv4 
or IPv6 address information in one attribute.

As IPv6 is deployed following the current scheme of keeping address 
families separated into separate attributes wherever addresses are used 
will become problematic as cases where the address family is not known in 
advance creep up.

Vendors are using it in their VSA spaces so why not just add a few 
paragraphs.  I'll volunteer.  This way future attributes with an IP data 
type have the option if makes sense for them.

Thought about suggesting it in the IPv6 draft but perhaps better for 
everyone to get that one done ASAP.

regards,
Peter

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

Delivery-date: Mon, 01 Aug 2011 10:54:09 +0000
Date: Mon, 01 Aug 2011 12:47:38 -0400
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[email-masked]>
To: Leaf yeh <[email-masked]>, Maglione Roberta <[email-masked]>, "'Jacni Qin'" <[email-masked]>
CC:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Qiujin <[email-masked]>, Wangshuxiang <[email-masked]>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3395047664_3043101
Content-type: text/plain;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

Hi All,

Allow me to share some comments:

* There is precedent of multiple =A1=B0specific=A1=B1 named pools; Framed-Pool,
Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is
also a special code in the Framed-IPX-Network attribute that conveys it poo=
l
like characteristics.
* There is little that disallows a vendor from implementing just one named
pool for all protocols and all methods of assignment ( the Framed-Pool
appears to have been envisaged for that ) and then using some implementatio=
n
specific logic (eg parsing for a name) to figure out/how it=A1=AFs to be used.
* The problem with relying on implementation specific features riding on
standard Attributes, as opposed to say VSAs, is that nothing indicates to
the server/client if the recipient actually supports such special features
and assures correct interpretation. Eg if we used the Framed-Pool as the ON=
E
named pool attribute, with a carried string =A1=B0IPv4=A1=B1, =A1=B0IPv6=A1=B1 or =A1=B0DHCPv6-=
PD=A1=B1,
etc, parsed/whatever to indicate the role, it would be all doable, but a
likely mess should anything go wrong (eg a device not supporting some mode)=
,
without clear indication of error.

Since the Radius specification is NOT about specifying implementation the
only reliable/unambiguous manner in which different pools/methods can be
utilized would appear to be using different attributes as proposed in the
current draft. Time (precedent) also appears to have proved this as a
desirable protocol characteristic.
Are there any other options/solutions available that do not call on implici=
t
features being there?

Regards,
Wojciech.

On 26/07/2011 22:51, "Leaf yeh" <[email-masked]> wrote:

> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> I supposed the local configuration on the NAS will answer this question.
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> =20
> =20
>=20
>=20
> From: Leaf yeh [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 21.50
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> The pools configured on the NAS are not necessary to be the same. AAA ser=
ver
> doesn't really need to instruct the NAS the specified type of pools, whic=
h is
> already configured on the NAS. Right?
>=20
> =20
>=20
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> Roberta
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Please see inline.
> =20
> Best regards,
> Roberta
> =20
>=20
>=20
> From: Leaf yeh [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 20.22
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
> =20
>=20
> Roberta - If you use the same attribute for both scenarios how does the N=
AS
> know if that pool is for SLAAC or for Stateful DHCPv6?
>=20
> NAS already has those pool names in its configuration, right?
>=20
> [RM] yes pools are already configured in the NAS
>=20
> =20
>=20
> NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6
> address pool.=20
>=20
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> That=A1=AFs why in my opinion the Stateful-IPv6-Address-Pool is required.
>=20
> =20
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[email-masked]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
> =B5=BD: 'Jacni Qin'
> Cc: Leaf yeh; [email-masked];
> [email-masked]; [email-masked]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Hi Jacni,
>    If you use the same attribute for both scenarios how does the NAS know=
 if
> that pool is for SLAAC or for Stateful DHCPv6?
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: Jacni Qin [mailto:[email-masked]]
> Sent: marted=A8=AC 26 luglio 2011 20.03
> To: Maglione Roberta
> Cc: Leaf yeh; [email-masked];
> [email-masked]; [email-masked]; Qiujin; Wangshuxiang
> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext
> session
>=20
> Hi Roberta,
>=20
> I agree with you about the semantical logic, while
> "Stateful-IPv6-Address-Pool" is not necessary, IMHO.
>=20
>=20
> Cheers,
> Jacni
> On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta
> <[email-masked]> wrote:
> Hello Leaf,
>     The different attributes proposed in this draft for the pools name ha=
ve
> all the same format (a string), but semantically they are different, as t=
hey
> coved different scenarios.
> As you also summarized in your email below,
>=20
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
>=20
> So each attribute covers a different use-case/scenario and they can appea=
r in
> the same RADIUS packet at the same time.
> If you want to use a single pool name use to cover all the 4 use cases li=
sted
> above, you would also need to define a standard format/syntax for the poo=
l
> name that allows the NAS to be able to disambiguate among the different
> scenarios and in order to do that the NAS would need to have an extra log=
ic to
> infer the semantic of that specific attribute from the assigned name.
> Instead if you have a specific attribute for each specific scenario, the
> semantic is mapped to the attribute name, thus the NAS does not need an e=
xtra
> logic to discovery the purpose of that pool and the pool name can be any
> string, no limitation or special syntax is forced for the pool name.
>=20
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Leaf yeh
> Sent: luned=A8=AC 25 luglio 2011 18.23
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Qiujin; Wangshuxiang
> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex=
t
> session
>=20
> Question for clarification:
>=20
> We already have the following Radius Attributes for the address/prefix po=
ols:
>=20
> Framed-Pool (88, section 5.18 of RFC2869),
> Framed-IPv6-Pool (100, section 2.6 of RFC3162).
>=20
> http://www.iana.org/assignments/radius-types/radius-types.xml
>=20
> The foramt are the same as follows:
>=20
> 0                   1                   2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     Type      |    Length     |     String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for
> address/prefix pools:
>=20
> Delegated-IPv6-Prefix-Pool,
> Stateful-IPv6-Address-Pool,
>=20
> the fomat of these 2 attributes are the same as the above one.
>=20
>=20
> Supposed the above attributes could be explained as follows:
>=20
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
>=20
> All above attributes are only used to provide the name of the address/pre=
fix
> pools in a 'string'. I doubt the necessity to make so many 'name' or 'str=
ing'
> attributes for the different address/prefix pools to prevent the ambiguit=
y. I
> guess 1 attribute for the name of the address/prefix pools might be enoug=
h. In
> fact, the NAS take the role to interpret the meaning of the pook name, ri=
ght?
>=20
> I think Framed-Pool can be re-used for the design purpose of
> Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of
> Framed-Pool for IPv6?
> I think Framed-IPv6-Pool can be re-used for the design purpose of
> Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul=
d
> even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name =
of a
> IPv6 prefix/address pool per the same logic. Am I right?
>=20
>=20
> Best Regards,
> Leaf
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
> Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.
>=20
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>=20
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa=
 mail
> se non =A8=A8 necessario.
> =20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privilege=
d
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the inten=
ded
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa=
 mail
> se non =A8=A8 necessario.
>=20

--B_3395047664_3043101
Content-type: text/html;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hi All,<BR>
<BR>
Allow me to share some comments:<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is precedent of multiple &#8220;specific&#8221=
; named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-=
IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network att=
ribute that conveys it pool like characteristics.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is little that disallows a vendor from implementin=
g just one named pool for all protocols and all methods of assignment ( the =
Framed-Pool appears to have been envisaged for that ) and then using some im=
plementation specific logic (eg parsing for a name) to figure out/how it&#82=
17;s to be used.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>The problem with relying on implementation specific feat=
ures riding on standard Attributes, as opposed to say VSAs, is that nothing =
indicates to the server/client if the recipient actually supports such speci=
al features and assures correct interpretation. Eg if we used the Framed-Poo=
l as the ONE named pool attribute, with a carried string &#8220;IPv4&#8221;,=
 &#8220;IPv6&#8221; or &#8220;DHCPv6-PD&#8221;, etc, parsed/whatever to indi=
cate the role, it would be all doable, but a likely mess should anything go =
wrong (eg a device not supporting some mode), without clear indication of er=
ror.<BR>
</SPAN></FONT></UL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
Since the Radius specification is NOT about specifying implementation the o=
nly reliable/unambiguous manner in which different pools/methods can be util=
ized would appear to be using different attributes as proposed in the curren=
t draft. Time (precedent) also appears to have proved this as a desirable pr=
otocol characteristic. <BR>
Are there any other options/solutions available that do not call on implici=
t features being there?<BR>
<BR>
Regards,<BR>
Wojciech.<BR>
<BR>
<BR>
On 26/07/2011 22:51, &quot;Leaf yeh&quot; &lt;<a href=3D"[email-masked]=
m">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"=
Arial"><SPAN STYLE=3D'font-size:10pt'>[RM] NAS can have many pools configured =
locally: how does the NAS know which pool is for SLAAC and which pool is for=
 DHCPv6?<BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
I supposed the local configuration on the NAS will answer this question.<BR=
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></FONT></SPAN></FONT><FONT FACE=3D"Tah=
oma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'><B>=B7=A2=BC=FE=C8=CB:</B><=
/SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> Maglione Roberta [<a href=
=3D"[email-masked]">[email-masked]</a>]<=
BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 3:54<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a>; <a href=3D"[email-masked]">ra=
[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]</a=
>; Qiujin; Wangshuxiang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
&nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12pt=
'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[email-masked]=
">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 21.50<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a>; <a href=3D"[email-masked]">ra=
[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> </SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Cali=
bri, Verdana, Helvetica, Arial">=B4=F0=B8=B4</FONT><FONT FACE=3D"Tahoma, Verdana, Helv=
etica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext session<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT COLOR=3D"#000080"><FONT FACE=
=3D"Arial">[RM] All the configured pools are the same for the NAS, in this cas=
e an extra logic would be needed to instruct the NAS about which pool is for=
 SLAAC and which one is for DHCPv6<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">The pools configured on the=
 NAS are not necessary to be the same. AAA server doesn't really need to ins=
truct the NAS the specified type of pools, which is already configured on th=
e NAS. Right?<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">[RM] NAS can have many pool=
s configured locally: how does the NAS know which pool is for SLAAC and whic=
h pool is for DHCPv6?<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Roberta<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Best Regards,<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Leaf<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>

</FONT></SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Tahoma, Verdana, He=
lvetica, Arial"><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Calibri, Verdana, H=
elvetica, Arial"><B>=B7=A2=BC=FE=C8=CB</B></FONT><B><FONT FACE=3D"Tahoma, Verdana, Helveti=
ca, Arial">:</FONT></B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> Magli=
one Roberta [<a href=3D"[email-masked]">roberta.maglione@te=
lecomitalia.it</a>]<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B7=A2=CB=CD=CA=B1=BC=E4</B></FON=
T><B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial"> 2011</FONT><FONT FACE=3D"Calibri, Verdana,=
 Helvetica, Arial">=C4=EA</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">7=
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=D4=C2</FONT><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial">27</FONT><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">=C8=D5</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> 2:2=
7<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B5=BD</B></FONT><B><=
FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Tahoma=
, Verdana, Helvetica, Arial"> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a>; <a href=3D"[email-masked]">ra=
[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]</a=
>; Qiujin; Wangshuxiang<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=D6=F7=CC=E2</B></FONT><B=
><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Taho=
ma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-a=
ccess after IETF81 radext session<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Please see inline.<BR>
</FONT></FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Best regards,<BR>
Roberta<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12pt=
'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[email-masked]=
">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 20.22<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[email-masked]">draft-iet=
[email-masked]</a>; <a href=3D"[email-masked]">ra=
[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> </SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Cali=
bri, Verdana, Helvetica, Arial">=B4=F0=B8=B4</FONT><FONT FACE=3D"Tahoma, Verdana, Helv=
etica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext session<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><BR>
Roberta - If you use the same attribute for both scenarios how does the NAS=
 know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
NAS already has those pool names in its configuration, right?<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT COLOR=3D"#000080"><FONT FACE=
=3D"Arial">[RM] yes pools are already configured in the NAS<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 a=
ddress pool. <BR>
<BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">[RM] All the configured poo=
ls are the same for the NAS, in this case an extra logic would be needed to =
instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<B=
R>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">That&#8217;s why in my opin=
ion the Stateful-IPv6-Address-Pool is required.<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>

</FONT></SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Tahoma, Verdana, He=
lvetica, Arial"><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Calibri, Verdana, H=
elvetica, Arial"><B>=B7=A2=BC=FE=C8=CB</B></FONT><B><FONT FACE=3D"Tahoma, Verdana, Helveti=
ca, Arial">:</FONT></B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> Magli=
one Roberta [<a href=3D"[email-masked]">roberta.maglione@te=
lecomitalia.it</a>]<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B7=A2=CB=CD=CA=B1=BC=E4</B></FON=
T><B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial"> 2011</FONT><FONT FACE=3D"Calibri, Verdana,=
 Helvetica, Arial">=C4=EA</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">7=
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=D4=C2</FONT><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial">27</FONT><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">=C8=D5</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> 2:1=
3<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B5=BD</B></FONT><B><=
FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Tahoma=
, Verdana, Helvetica, Arial"> 'Jacni Qin'<BR>
<B>Cc:</B> Leaf yeh; <a href=3D"[email-masked]"=
>[email-masked]</a>; <a href=3D"[email-masked]=
tf.org">[email-masked]</a>; <a href=3D"[email-masked]">fine_sz@hua=
wei.com</a>; Qiujin; Wangshuxiang<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=D6=F7=CC=E2</B></FONT><B=
><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Taho=
ma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-a=
ccess after IETF81 radext session<BR>
<BR>
Hi Jacni,<BR>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does=
 the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: Jacni Qin [<a href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/a>]<BR>
Sent: marted&igrave; 26 luglio 2011 20.03<BR>
To: Maglione Roberta<BR>
Cc: Leaf yeh; <a href=3D"[email-masked]">draft-=
[email-masked]</a>; <a href=3D"[email-masked]"=
>[email-masked]</a>; <a href=3D"[email-masked]">[email-masked]=
</a>; Qiujin; Wangshuxiang<BR>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad=
ext session<BR>
<BR>
Hi Roberta,<BR>
<BR>
I agree with you about the semantical logic, while &quot;Stateful-IPv6-Addr=
ess-Pool&quot; is not necessary, IMHO.<BR>
<BR>
<BR>
Cheers,<BR>
Jacni<BR>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href=3D"roberta.magl=
[email-masked]">[email-masked]</a>&gt; wrote:<BR>
Hello Leaf,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for=
 the pools name have all the same format (a string), but semantically they a=
re different, as they coved different scenarios.<BR>
As you also summarized in your email below,<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
So each attribute covers a different use-case/scenario and they can appear =
in the same RADIUS packet at the same time.<BR>
If you want to use a single pool name use to cover all the 4 use cases list=
ed above, you would also need to define a standard format/syntax for the poo=
l name that allows the NAS to be able to disambiguate among the different sc=
enarios and in order to do that the NAS would need to have an extra logic to=
 infer the semantic of that specific attribute from the assigned name.<BR>
Instead if you have a specific attribute for each specific scenario, the se=
mantic is mapped to the attribute name, thus the NAS does not need an extra =
logic to discovery the purpose of that pool and the pool name can be any str=
ing, no limitation or special syntax is forced for the pool name.<BR>
<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: <a href=3D"[email-masked]">[email-masked]</=
a> [<a href=3D"mailto:[email-masked]">mailto:owner-radiusext@ops=
.ietf.org</a>] On Behalf Of Leaf yeh<BR>
Sent: luned&igrave; 25 luglio 2011 18.23<BR>
To: <a href=3D"[email-masked]">draft-ietf-radex=
[email-masked]</a>; <a href=3D"[email-masked]">radiusext=
@ops.ietf.org</a><BR>
Cc: <a href=3D"[email-masked]">[email-masked]</a>; Qiujin; Wangshuxia=
ng<BR>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext =
session<BR>
<BR>
Question for clarification:<BR>
<BR>
We already have the following Radius Attributes for the address/prefix pool=
s:<BR>
<BR>
Framed-Pool (88, section 5.18 of RFC2869),<BR>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<BR>
<BR>
<a href=3D"http://www.iana.org/assignments/radius-types/radius-types.xml">htt=
p://www.iana.org/assignments/radius-types/radius-types.xml</a><BR>
<BR>
The foramt are the same as follows:<BR>
<BR>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<BR>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;=
&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
<BR>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/=
prefix pools:<BR>
<BR>
Delegated-IPv6-Prefix-Pool,<BR>
Stateful-IPv6-Address-Pool,<BR>
<BR>
the fomat of these 2 attributes are the same as the above one.<BR>
<BR>
<BR>
Supposed the above attributes could be explained as follows:<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
All above attributes are only used to provide the name of the address/prefi=
x pools in a 'string'. I doubt the necessity to make so many 'name' or 'stri=
ng' attributes for the different address/prefix pools to prevent the ambigui=
ty. I guess 1 attribute for the name of the address/prefix pools might be en=
ough. In fact, the NAS take the role to interpret the meaning of the pook na=
me, right?<BR>
<BR>
I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-=
Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6=
?<BR>
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated=
-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think=
 Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 pre=
fix/address pool per the same logic. Am I right?<BR>
<BR>
<BR>
Best Regards,<BR>
Leaf<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla=
 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
Rispetta l'ambiente. Non stampare questa mail se non &egrave; necessario.<B=
R>
<BR>
<BR>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla=
 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
<BR>
</FONT></SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:7pt'>Questo messaggio e i suoi allegati sono indirizz=
ati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi a=
ltra azione derivante dalla conoscenza di queste informazioni sono rigorosam=
ente vietate. Qualora abbiate ricevuto questo documento per errore siete cor=
tesemente pregati di darne immediata comunicazione al mittente e di provvede=
re alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN S=
TYLE=3D'font-size:7pt'>Questo messaggio e i suoi allegati sono indirizzati esc=
lusivamente alle persone indicate. La diffusione, copia o qualsiasi altra az=
ione derivante dalla conoscenza di queste informazioni sono rigorosamente vi=
etate. Qualora abbiate ricevuto questo documento per errore siete cortesemen=
te pregati di darne immediata comunicazione al mittente e di provvedere alla=
 sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica,=
 Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3395047664_3043101--

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