RE: Review of draft-lior-radext-end-to-end-caps-01.txt

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.

[Avi] The problem statement was discussed over the list and presented at IETF. As well there are some drafts that have indepementatly introduced a capability exchange. This is an attempt to try to get one consistant approach to solve the problem.

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.

[Avi] I agree that RADIUS as a Dialup AAA server is simple. But RADIUS has been evolving. The addition of EAP. Support for dynamic operations 3576. The evolution of RADIUS is necessary as it is being asked to be involved in more complex deployements.

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.
[Avi] Very inefficiently. We have to try to disconnect or perform a change of authorization before we can learn that whether or not a NAS supports 3576. In deployments where you have millions of subscribers the facilities provided by 3576 are not usable. This is why for example 3GPP2 developed a capbility exchange specifically for determining whether a NAS support this capability or not,

* The use of capabilities negotiation for optional attributes. RADIUS implementations
have handled optional attributes for years, so this is unnecessary.
[Avi] I dont think so. A NAS will ignore attirbutes that it does not support. Therefore for example in prepaid, when the server sends prepaid attributes to the NAS that are going to control the session, if the NAS ignores the attributes the prepaid user will be given unlimited access.

* Retroactive changes to the behaviour of existing RADIUS implementations.
[Avi] As long as we maintain backwards compatibility then I belive that we are okay. With a capability exchange the Server can detect that it is potentially dealing with an old NAS and apply its policies accordingly. Without a capability exchange we are blind.

* Creation of a registry for Capability IDs, including capabilities that don't
exist in RADIUS RFCs.
[Avi] We should only have a registry of capabilities that are supported by RFCs.

This will cause interoperability problems -
RADIUS requires that VSAs be treated as optional so as to allow interoperability
between vendor implementations.
[Avi] I think SDOs that define VSAs should use the same scheme as proposed but they should maintian their own registry.

* Incompatibility with the Diameter optional/mandatory attribute marking.
The document doesn't even have a Diameter compatibility section.
[Avi] We can add something to this document and perhaps write a Diameter version. Diameter also suffers from this problem btw. Diameter has serious problems which is to be expected for a new AAA protocol.

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?
[Avi] Because other works have required some of the approaches taken here. Look this document is a starting point. Lets make this a working group document and then we can shape it so that it makes sense. But as you noted first and foremost we need a capability exchange mechanism. What we should debate is what it looks like.

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?"

[Avi] I wish you wouldnt missrepresent the wishes of the group. At the last IETF there were no objections for having a capability excange.

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?"