Avi Lior
Office: +1 613 591-9104 x 6417
Cell : +1 613 796-4183
-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org]
Sent: Thu 4/12/2007 4:01 AM
To: Avi Lior
Cc: Bernard Aboba; radiusext@ops.ietf.org
Subject: 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
> sufficient.
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.
[Avi] Sorry i must be missing something. Can you explain what you mean by non-qualified attribute names or qualified attribute name.
> The actual naming of the attribute is for human
> readability.
And for policies. If the policy says "Do X if DNS-Server is set to
1.2.3.4", 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] Sorry Alan but i don't get it. We never work with attribute names themselves we work with Vendor Specific Dictionaries so all attributes are always relative to a dictionary. So there is no confusion.
[Avi] If you are thinking of suggesting that SDO prefix their attributes with the SDOs name. That could be a good idea. Its a little too late. And would require that we create a registry for SDO prefixes. But I am not sure that this really helps. It may make it easier for humans to read.
> [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
of conflict.
[Avi] The conflict is in the human brain but not in the protocol. Right?
[Avi] This is not a RADIUS only problem by the way. It is an IETF problem since VSA are defined by many protocols.
[Avi] I am not opposed to it but I dont think its as big a problem as you make it out to be.
> 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?
[Avi] X_DNS_NAME and Y_DNS_NAME is equally confusing. And we already of namespaces. If someone gave me a policy if IF X == 1.2.3.4 I would ask which Vendor Dictionary are you using for X. By the way that is a human readable policy not an actual policy. That policy would translate X to something like (26,2234,45).
Even if we had a prefix, I still would not rely on that prefix when writting the policy down. I still would use X plus dictionary name. Or I would say X as defined by some reference so I know the context of the attribute.
> 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
pointed out?
Curious. Or maybe I misunderstood exactly how the SDO's change the
meaning of attributes, while maintaining backwards compatibility and
interoperability.
[Avi] Why do you think SDOs are stupid? They change the meaning/definition of an attribute like smart people at the IETF do. For example, adding a new enumeration to an enumerated type. Or when a bug is found. Or the semantics of an attribute can change as well while still maintianing backwards compatibility.
Alan DeKok.