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

["David B. Nelson" <d.b.nelson@comcast.net>]

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

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

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

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

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

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