David - It's almost always the *contents* of attributes that is interpreted by the NAS... I agree. I thought AAA server just need to indicate single or multiple pool names, whose meaning & purpose should definitely be known in advanced by AAA server. 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 will 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-Address-Pool. Right? -----Original Message----- From: David B. Nelson [mailto:d.b.nelson@comcast.net] Sent: Monday, August 15, 2011 11:22 PM To: Wojciech Dec Cc: 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 > ... 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 |