I object to taking on the End-to-End Capabilities document as a
RADEXT WG
work item. The document doesn’t properly
define the problem and the proposed solution
is
excessively complex and is not compatible with existing mechanisms in Diameter.
When adding new features,
the RADEXT WG needs to try and maintain the simplicity of
RADIUS as I believe that this has accounted for much of its
success. Questions
like “is this feature necessary
at all?" And “can this feature be done in a simple way?”
should be answered first.
RADIUS is a simple protocol, and has existed without capability
negotiation since its
inception. A very good case has to
be made for adding this capability at this time,
especially in the complex manner that’s being proposed. The
document does not
make the case for the major changes it
is proposing. In fact, many of the problems
it
defines do not exist and many of the features it attempts to add duplicate
existing
RADIUS functionality.
As a result, I believe that the WG should discard the End-to-End
Capabilities document,
since its approach is so
inherently complex and flawed that it cannot be fixed by
accepting the document as a WG work item.
A couple of specific problems, in addition to the unconvincing motivation are:
* The alternative mechanisms for detecting RFC 3576 support,
something that
is already handled in RFC 3576.
* The use of capabilities negotiation for optional
attributes. RADIUS implementations
have handled
optional attributes for years, so this is unnecessary.
* Retroactive changes to the behaviour of existing RADIUS implementations.
* Creation of a registry for Capability IDs, including
capabilities that don't
exist in RADIUS RFCs. This
will cause interoperability problems -
RADIUS requires
that VSAs be treated as optional so as to allow interoperability
between vendor implementations.
* Incompatibility with the Diameter optional/mandatory attribute
marking.
The document doesn't even have a Diameter
compatibility section.
I can go on to list all the objections to this document, all the
unnecessarily
functionality, the confused problem
statement, etc. But that is hardly necessary;
other participants in the WG have already stated those objections during
previous
discussions, more eloquently than I can.
In fact, looking back at previous
RADEXT WG discussion
which started in January 2005, it appears that many of
these issues were brought up before. Looking back at the discussion, it
appears
that WG consensus previously existed to adopt an
alternative (simpler) approach.
So why is it being
brought back again?
I have to wonder "How can this document even be considered as a
WG work item
given the volume and seriousness of the
criticisms that have been leveled
against it?" And
how can the RADEXT WG be bringing to WG last call
documents that have so many problems, such as the VLAN and Filters
draft?
In its consideration of new WG items, the RADEXT WG seems to be
asking the
wrong questions. The right question
isn't "Are there any objections?"
but rather "Is there
WG consensus that this document is an appropriate solution
to a real problem, and are there a significant base of vendors who
consider this
functionality necessary and who will
implement it?"