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

The two sub-options have different formats as well as different semantics.
Two separately defined sub-options are simpler in usage and
encoding/decoding, I think.

Eunsoo

----- Original Message ----- 
From: "James Kempf" <[email protected]>
To: "Eunsoo Shim" <[email protected]>; "Vijay Devarapalli"
<[email protected]>
Cc: "Marco Liebsch" <[email protected]>; "Seamoby"
<[email protected]>
Sent: Monday, October 13, 2003 3:42 PM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
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
> > > >
> > >
> > >
> >
> >
>
>