[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On issue 6: Avi review of I-D Action:draft-ietf-radext-design-13.txt
My thinking on the applicability of design guidelines has always been
pretty simple. It starts with the premise that any Standards
Development Organization (SDO) is in the business of defining
interoperable standards. If we can't all agree that this is a truism,
we have deeper problems. Within that framework, the notion that what
one SDO does will never impact any other SDO or the Internet Community
at large is questionable. It may be true sometimes, but I don't
believe it's universally true.
Within the scope of RADIUS Attribute design and compatibility, I think
there are three levels:
(1) Attributes that are of interest to a single vendor, e.g., for a
single product line. No cross-vendor interoperability is needed.
We use Vendor-Specific Attributes for these cases. The rules are
pretty lax. Code-point allocation is managed by the vendor with the
number space defined by their Private Enterprise Number (PEN).
(2) Attributes that are of interest to an industry segment and a
single SDO that serves that industry. WiMAX is one example. Multi-
vendor interoperability within an industry segment is expected.
We use SDO-Specific Attributes (SSA) for these cases, which are VSAs
in terms of format and code-point allocation, using a PEN assigned to
the SDO rather than one assigned to an individual vendor. The rules
are more stringent. Compliance with the design guidelines is strongly
encouraged, but review by outside agencies (the IETF, AAA Doctors,
etc.) is purely optional.
(3) Attributes that are of broad interest to the Internet Community.
Global Internet multi-vendor interoperability is expected.
We use Standard Attributes for these cases, with code-point allocation
via IANA, subject to the appropriate IETF review and consensus.
Strict conformance with the design guidelines is expected, unless a
good case can be made for an exception, and those tasked with
reviewing the proposals will almost certainly use the design
guidelines as a review checklist.
--
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/>