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

So why not merge them into a "filter" suboption? And have the filter
language reflect the two different uses?

            jak

----- Original Message ----- 
From: "Eunsoo Shim" <[email protected]>
To: "James Kempf" <[email protected]>; "Vijay Devarapalli"
<[email protected]>
Cc: "Marco Liebsch" <[email protected]>; "Seamoby"
<[email protected]>
Sent: Monday, October 13, 2003 11:10 AM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
Proposal to resolve remaining CARD issues)


> The Requirements sub-option is used to filter out the CARs to be included
in
> the Reply.
> For example, it can say " CARs supporting 802.11b interface". Then the
> current AR puts CAR information satisfying the conditions (requirements).
It
> is useful since any CAR that does not support the link types available for
> the MN should not be included in the Reply. Since the current AR does not
> know what link types are available for each MN, it is the MN that should
> tell the current AR about them.
>
> The Preferences sub-option is used to filter out the attributes to be
> included in the Reply.
> For example, it can say "link types, supported IP versions, authentication
> protocols". Then the current AR puts those attributes among all the
> capability (attributes) of the CARs. That is, the Reply does not contain
> "cost = free" of the CARs but it can contain information such as "link
type
> = 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated
> protocols = RADIUS" for each CAR entry.
>
> So the two sub-options are for independent filtering of the CAR
information.
> One cannot replace the other.
>
> Also, merging the two sub-options does NOT make anything simpler. Rather,
it
> makes the sub-option more complex to decode.
>
> Eunsoo
>
> ----- Original Message ----- 
> From: "James Kempf" <[email protected]>
> To: "Vijay Devarapalli" <[email protected]>; "Eunsoo Shim"
> <[email protected]>
> Cc: "Marco Liebsch" <[email protected]>; "Seamoby"
> <[email protected]>
> Sent: Monday, October 13, 2003 1:50 PM
> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
> Proposal to resolve remaining CARD issues)
>
>
> > Marco/Eunsoo,
> >
> > Can you explain what the exact semantic difference is between these two
> > options? If it isn't large, then I'd suggest merging them, based on the
> > premise that "simpler is better"?
> >
> >             jak
> >
> > ----- Original Message ----- 
> > From: "Vijay Devarapalli" <[email protected]>
> > To: "Eunsoo Shim" <[email protected]>
> > Cc: "Marco Liebsch" <[email protected]>; "Seamoby"
> > <[email protected]>
> > Sent: Friday, October 10, 2003 11:20 AM
> > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
> > Proposal to resolve remaining CARD issues)
> >
> >
> > >
> > >
> > > Eunsoo Shim wrote:
> > >
> > > > The MN does not lose connectivity necessarily in the case you
> described.
> > >
> > > what I meant, if there are no candidate ARs, the MN loses connectivity
> > > eventually.
> > >
> > > > However, if the requirements are something in which there is no
> > flexibility
> > > > with the MN such as link type, the empty reply means there is no
> access
> > > > network supporting the link type. In the case, losing connectivity
may
> > not
> > > > be unavoidable if the MN keeps moving far from the old access
> point/base
> > > > station.
> > >
> > > let the MN make the decision, if no CARs can satisfy its requirements.
> > > and you have the preferences options for the MN to tell the current AR
> > > what it wants.
> > >
> > > Vijay
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
>
>