Re: Preferences and Requirements Options (was Re: Proposal to resolve remaining CARD issues)

Vijay Devarapalli wrote:

>>
>> Issue#17: Preferences/Requirements sub-option - One
>> of them is sufficient?
>> ---------------------------------------------------
>> Proposal is to keep both, since this implies just the definition of a 
>> further sub-option type, which indicates
>> that only Attributes without any Data field will follow
>> in case of receiving a Preferences sub-option.
>> The Requirements parameter sub-option will carry then a
>> list of Attribute-Value pairs, the Preferences parameter
>> carries a list of Attributes (just the AVP Code and
>> Length, no Lifetime, no Data).
>
>
>
> one has to still implement both, right?
>
> I still think one of them is enough. I suggest removing the 
> Requirements Sub-Option.
> it causes more harm than benefit. here is one example.
>
> lets assume none of the CARs were able to meet the MN's requirements. 
> the CARD
> Reply returns empty. because of the MN's strict requirements, it loses 
> connectivity.
> isnt that worse than picking a CAR with less capabilities? a local 
> decision at the
> MN is better than the MN not getting any CARs.
>
> Vijay
>
>
I don't want to provide input for a huge discussion here, but I don't see
any reason why not to have 2 separate sub-options for 2 separate
functions. If these should be merged, ARs need to check always whether
or not AVPs carry a Data field, if not then this is interpreted as a 
"preference",
otherwise as a "requirement" parameters.....

However, from implementation point of view, the current one is the simplest
case, since the format for both are the same, just use a separate type 
number
for these sub-options, that's it. This makes the meaning of the parameters
already clear when processing the header of the sub-option, right?

marco