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

[Wojciech Dec <wdec@cisco.com>]

On 15/08/2011 17:21, "David B. Nelson" <d.b.nelson@comcast.net> wrote:

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


> 
>> ...to be used, only this time with the contents being laid down as
>> the enumerated type code points in a draft.
> 
> I think an enumerated type is preferable to parsing strings when the semantics
> 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.
> 
>> 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 ad-hoc
> implementation practice, in the absence of any normative guidance, I suggest
> 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 behavior.

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


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

> 
>> Frankly, other than it being another way of doing things, I personally
>> don¹t 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 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.
> 
> -- Dave


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