Re: Guidelines Document Discussion

[Alan DeKok <aland@nitros9.org>]

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.

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

> 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
pointed out?

  Curious.  Or maybe I misunderstood exactly how the SDO's change the
meaning of attributes, while maintaining backwards compatibility and
interoperability.

  Alan DeKok.

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