Re: Guidelines Document Discussion

[Alan DeKok <aland@nitros9.org>]

Avi Lior wrote:
> [Avi] Sorry i must be missing something.  Can you explain what you mean
> by non-qualified attribute names or qualified attribute name.

  Qualified attribute name: SDO-Attribute-Foo
  Unqualified attribute name: Attribute-Foo

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

  The qualified attribute names are an attempt to enforce naming
relative to a dictionary.

  Let's take RFC 4679 as an example.  It defines Agent-Circuit-Id, among
other attributes.  As a vendor, Redback also defines Agent-Circuit-Id.

  If we simply refer to Agent-Circuit-Id, that name is ambiguous.  We
could say "RFC 4679 Agent-Circuit-Id", and "Redback VSA
Agent-Circuit-Id".  Or, we could say "ADSL-Agent-Circuit-Id", and
"Redback-Agent-Circuit-Id".

  I prefer the second method.

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

  The 3GPP && 3GPP2 forums have already done this.  We can request that
SDOs do this for future work.

> [Avi] The conflict is in the human brain but not in the protocol. Right?

  And in the implementation that has to parse "Agent-Circuit-Id", and
try to guess which SDO or vendor it applies to.  Ambiguity does not
result in interoperable implementations.

> [Avi] I am not opposed to it but I dont think its as big a problem as
> you make it out to be.

  It's been a problem for me, and for the people I have to support.

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

  Why do that when you can just refer to the fully qualified name?

>  By the way that is a
> human readable policy not an actual policy.  That policy would translate
> X to something like (26,2234,45). 

  The administrator may be typing in the name, rather than selecting it
from a drop-down menu.  With a drop down menu, that qualification can
happen automatically, because the context for the name is available.  If
the name is entered as a test string, additional qualification is needed
to resolve ambiguity.

  And humans need to be able to discuss policy, too.  We're not going to
talk about (26,2234,45) on this list.  (Or at least, I can't be bothered
to remember those numbers).  We can talk about Agent-Circuit-Id, though.

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

  The semantics of an attribute can be clarified without changing its
meaning.  If the meaning changes, then I don't understand how the "same"
attribute can be used simultaneously with two different meanings.  Maybe
I'm the one that's stupid, but I just don't see how it can work.

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