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

From: [email-masked] (Patrice Calhoun)
Date: Wed, 13 Oct 1999 12:33:45 -0700

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 13:15:05 -0700

>> protocol and extension sets), then this might not work so well.  

as we have learned that we can not make vendor-specific non-standard
extensions truely mandatory, it devolves into a form of negotiation.

randy