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

[Leaf yeh <leaf.y.yeh@huawei.com>]

Dave - If there are in fact two independent variables at play (a) address
assignment method and (b) adress pool selection, then it seems to me
that we need one attribute (or set of attributes) to name the pool and
a second one to name the address assignment method.

Dave - I'm proposing that the (ad-hoc) precedent is a bad
design choice and that in standardizing this feature we perhaps should
make another choice.  I always prefer an enumerated type encoding over
a string encoding when the underlying semantics and data model of the
object is a set of discreet choices.

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

I think the above explanations are good enough from the stand points of my view.


Best Regards,
Leaf


-----Original Message-----
From: Dave Nelson [mailto:dnelson@elbrys.com] 
Sent: Tuesday, August 16, 2011 10:34 PM
To: Wojciech Dec
Cc: David B. Nelson; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine sz; Qiujin; Wangshuxiang; draft-tan-v6ops-fast6-aaa@tools.ietf.org; Leaf yeh; roberta maglione; jacniq@gmail.com; Bernard Aboba
Subject: Re: çå: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

> How does the NAS pick  the right pool based on receiving a single
> attribute containing an enumerated code-point for Foo-bar?

If there are in fact two independent variables at play (a) address
assignment method and (b) adress pool selection, then it seems to me
that we need one attribute (or set of attributes) to name the pool and
a second one to name the address assignment method.

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

I understand. I'm proposing that the (ad-hoc) precedent is a bad
design choice and that in standardizing this feature we perhaps should
make another choice.  I always prefer an enumerated type encoding over
a string encoding when the underlying semantics and data model of the
object is a set of discreet choices.

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

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.

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

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

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

Regards,

Dave

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