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

Eunsoo,

I do not have a lot of time to discuss this, so this will be my last email
on the topic.

> 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.
>

Can you explain how having two sets of parsing code is simpler than having
one?


        jak

> 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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>