RE: Guidelines Document Discussion

["Avi Lior" <avi@bridgewatersystems.com>]

Alan see inline, 

Avi Lior wrote:
> [Avi] The name space for a VSA is defined -- it the SDOs (or vendors 
> namespace).  I don't know what else you would do.
...
> [Avi] The reality is that one SDO may define DNS-Server because it 
> does not know that another attribute by that name is already defined.

> There is no global repository for looking up what other SDO have done.

  Which appears to contract your previous statement.

  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.  The actual naming of the attribute is for human
readability.  Having said that, it would be nice if a vendor did want
their attribute to be widely used that they did somehow decorated the
name with the vendor designation as Microsoft did (I assume that the MSS
of the MSS-MPPE... Attribute is for Microsoft). 

  Both SDO's defining "DNS-Server" without qualification is not OK.

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

[Avi] As to the qualification part, I am sure when an SDO defines
DNS-Server they do provide both the definition for the attribute and the
semantics for its use.


> [Avi] There is apprehension and that relates to change control.  If I 
> use an attribute x from VendorA, then I need assurances that if that 
> attribute is going to change or that I would be consulted or be 
> notified when such a change occurs.

  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.

> [Avi] Given the IETF is a common denominator across SDOs, a way 
> forward perhaps is to encourage SDOs to publish their dictionaries as 
> INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in
IANA.

  I agree.

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