RE: [radext] #27: Section 1.3

["Dave Nelson" <d.b.nelson@comcast.net>]

>     However, there are situations in which vendors or SDOs can choose
>     not to follow these guidelines without major consequences.  As
>     noted in [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs)
>     are "available to allow vendors to support their own extended 
>     Attributes not suitable for general usage."  Where vendors or 
>     SDOs develop specifications "not suitable for general usage",
>     limited interoperability and inability to use existing 
>     implementations may be acceptable and in these situations, 
>     vendors and SDOs MAY NOT choose to conform to these
>     guidelines.

I have always felt that the notion of placing other SDOs on the same plane
as vendors is a silly one.  I believe I know what motivates this treatment.
It seems to me to be a compromise to assuage those RADIUS practitioners who
are active in other SDOs and who have continually been critical of this WG's
attempts to define a reasonably rigorous set of attribute design criteria.
The point of *any* SDO is to define interoperable standards for multiple
vendors to use, to promote multi-vendor interoperability in implementations
and deployments.  To suggest that SDOs, other than the IETF, do not require
multi-vendor interoperability in their standards seems to devalue their
work.

I think that there should be a three tier scheme for recommended compliance
with these guidelines, not two tier.  I believe that non-IETF SDOs should be
held to a higher level of expectations than single vendors, but lower that
the IETF itself.



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