Subject: RE: comments on draft-ietf-nasreq-criteria-03.txt

From: [email-masked] (Patrice Calhoun)
Date: Wed, 13 Oct 1999 13:16:05 -0700

Not as I see it.

Let's take the hypothetical case where a base protocol exists with several
"extensions". Peers will only attempt to communicate together if they
know that the peers support an extension in question. 

However, vendor A may wish to send additional information in vendor specific
AVPs. Of course, he *should* only do this if the peer is of the same
manufacturer (one would think), but the RADIUS protocol has proved this to
be untrue. Server vendors are in the business of trying to figure out who
has done what with the protocol and implement it. Therefore, simply sending
a "vendor string" is not sufficient.

One other approach would be to send the vendor IDs that an implementation
supports, in addition to the extensions. But there may be hundreds of vendor
specific attributes for the vendor, and not all may be supported. Conversely,
one could send the whole dictionary as part of the capabilities exchange....
let's not even go there :)

This, I believe, is a tough question to answer (now that I've typed it in).
I strongly believe in capabilities negotiation. I also believe that a back-up
plan to support mandatory bits is also another way to ensure extensibility.
One alternative, of course, is to state that if you receive *any* attribute
that is unknown, the request must be rejected. The problem here is that the
attribute in question may contain purely informational data.

PatC
>If you knew that the other side could handle a capability (via
>capabilities negotiation) why would you *also* need to mark
>an attribute as Mandatory? Does this have something to do
>with proxy editing?
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, October 13, 1999 12:34 PM
>To: Bernard Aboba (Exchange); [email-masked];
>[email-masked]'
>Subject: RE: comments on draft-ietf-nasreq-criteria-03.txt
>
>
>Actually, I do not see the two solutions provided as being mutually
>exclusive. I think that both can be used simultaneously. The former
>allows for one to identify standards-track extensions, and the later
>to identify vendor-specific attributes.
>
>PatC
>>I agree with Pat.
>>
>>One of the major reasons for insertion of RADIUS proxies
>>is capabilities adjustment. Given the different dialects
>>that are spoken nowadays, getting the editing right is
>>already quite tedious and might be likely to become
>>unbearable in the future if we don't do something about
>>it. 
>>
>>There are several possible solutions:
>>
>>a. Capabilities negotiation. This is the approach taken
>>in BGP. This approach seems to work well when there are
>>lots of extensions sets, thus making it likely that each side
>>might not be able to communicate well unless they reach
>>an agreement beforehand. 
>>
>>b. Use a Mandatory bit as in L2TP. In this approach, typically 
>>only standardized attributes should be marked Mandatory, so as to
>>avoid potential "bullying." However, if there are sets of
>>standardized attributes that might not be implemented by a
>>client or server (as might be the case when there is a base
>>protocol and extension sets), then this might not work so well.  
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 1999 14:23:14 -0700

> know that the peers support an extension in question. 

s/communicate together/use the extension/

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 14 Oct 1999 14:28:55 +0200

Patrice Calhoun wrote:
Hi Pat et al.,

> attribute in question may contain purely informational data.

just to add a bit to the confusion.

Something that exists and is in use in e.g., ATM signalling protocols,
is the notion of pass along.
What happens if one has a proxy situation (e.g. over two aaa proxies,
the middle RADIUS server belonging to a broker), where some specific
attribute needs to be send end to end, but the next hop doesn't know it.

would it be a valid requirement to the protocol to be able to indicate
in the Attribute the behaviour expected from the 'proxy in the middle'.
Such behaviour could be e.g., if you do not understand it, please
however pass it trough to the other side.

this is an extension to the mandatory field, however specific to the
proxying behaviour and the distinction between end to end and hop by
hop.
if assumed a valid requirement, i can make up some text for it, just
shout.

cheers,
Yves