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

[Wojciech Dec <wdec@cisco.com>]

On 16/08/2011 16:33, "Dave Nelson" <dnelson@elbrys.com> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>