[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guidelines Document Discussion
Avi Lior wrote:
> i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK.
> [Avi] When I said name space I mean an implicit name-space. I don't
> think that vendors and operators be required to call their attribute
> SDO-A-Foobar. The vendor id creates a name-space and that is
I strongly disagree. Vendors or SDOs who use non-qualified attribute
names have caused interoperability problems in the past, and will
continue to do so in the future.
> The actual naming of the attribute is for human
And for policies. If the policy says "Do X if DNS-Server is set to
188.8.131.52", what does that mean when two SDO's define the same name?
SDO namespaces allow clear policies to be created. Non-SDO namespaces
allow policies to be created that cannot be meaningfully interpreted.
> [Avi] it's a fact of life that two SDOs can and probably will define
> attribute that have the same name. They are operating autonomously.
Then the RADIUS guidelines document needs to say that the attribute
names should be prefixed with the SDO name, to obtain an SDO-specific
namespace. They can then operate autonomously without the possibility
> When working in one SDO I am not checking the attributes of another SDOs
> or other vendors. Its not practical. I don't know about all the SDOs
> or all the vendors. Lets get real here.
Yes. Which is why prefixes create independent name spaces, and do not
require coordination. Allowing SDO's to create names *without* prefixes
has all of the problems you highlight, and all of the problems I
highlight. Why not avoid both problems by using namespaces?
> Attributes change their meaning? That's bad practice.
> [Avi] Meaning or semantics. Well that is just the way the cookie
> crumbles sometimes. It is precisely dogma like that that make some SDOs
> nervous about sharing.
That's an interesting approach. SDO's change the meaning of
attributes so that existing implementations and deployments are
non-compliant with the new meanings. Existing implementations and
deployments are also non-interoperable with new deployments that
understand the new meaning. And it makes the SDO's nervous to have this
Curious. Or maybe I misunderstood exactly how the SDO's change the
meaning of attributes, while maintaining backwards compatibility and
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.