Subject: [Seamoby] (virtual) hum on CARD open issues

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 17 Jul 2003 23:19:34 -0700

Following today's meeeting in Vienna, we've been able to get consensus on most issues. However, we need to get consensus on the mailing list. Please send your opinion to both myself and James on each of the issues below (in a single e-mail, please), and I will tabulate the responses and send a resume to the list.

1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)

2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.

3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.

4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit.

5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links can generate heavy traffic. James Kempf proposes that we drop this for now as we enter experimental. Alternative proposal is to mimic router advertisements, send when changes occur and send when new mobile shows up. Meeting consensus is to add a statement in the document that we considered multicast and leave it for future. 

6. Issue #12: Link Layer triggers for unsolicited CARD reply. Proposal is to remove the text that deals with layer 2 triggers. Meeting consensus is to remove text.

7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the Proxy message does this too. Meeting consensus is to specify a R-flag in the CARD request message.

9. Issue #25: Addressing of unicast CARD protocol messages. Should we use global or link local addresses? Meeting consensus is that since MN-AR is always on a single hop, use keep link local addresses.

10. Issue #36: Removal of per-session state from ARs. Meeting consensus is to keep signalling failure recovery on AR-AR interface, but make it optional (MAY). 

11. Issue #39: Further detail of signalling failure recovery required. Meeting consensus is that if the MN is not able to resolve an L2 ID, put an error code or some flag.

12. Issue #17: Separate appendix from the CARD protocol specification. The appendix is very large which describes many options. James Kempf believes that the appendix really needs to be shortened down to 2 pages, describing the two solutions - these are items that need to be resolved during the experimental phase. Meeting consensus is to take the appendix to 2 pages.

Thanks,

Pat & James

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 18 Jul 2003 11:11:40 -0700

> 1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4…

this is wrong, IMHO. rate limiting is a well known mechanism.
introducing a new flag is not a bright idea. the MN has to
send one request per second upto a maximum of 3 requests. or
it can exponentially backoff. if the MN sends requests more
frequent than this, they are dropped by the AR. I even sent
some text for this, when I reviewed the CARD protocol.

> 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential secur…

2 and 3 dont go togetheer. defining CARD messages as ICMP 
options lets you piggyback these options on FMIPv6 messages.
I am not sure how you can achieve piggybacking if the MN-AR
signaling becomes UDP. ICMP was the right choice between
the MN and the AR.

from a recent discussion on the IPsec mailing list, it
looks like we might get the ICMP type as an IPsec selector.
then you would be able to distinguish between different
ICMP messages. ofcourse I dont when it might be 
standardized.

> 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwi…

unbelievable. the CARD protocol is already complicated (IMO).
the emphasis should be on reducing the complexity. just use 
a value of infinity for the lifetime field to indicate a 
static capability. any other value for the lifetime indicates 
dynamic capability. I think for the CARD protocol, emphasis
should be on making it a simpler protocol than saving 4 bytes
over the air. :)

if you are concerned about an overhead of 4 bytes, make the 
lifetime field 2 bytes. a 2 byte lifetime field gives you
65536 seconds which should be enough. do you need a 4 byte
lifetime field?

> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wire…

I am not sure I understood. is the unsolicited CARD Reply
message being dropped from the spec, because it cant be
protected?

> 7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

I believe combining these two will go a long way in 
simplifying the CARD protocol. I looked up the meeting
minutes, which said there were no comments on this at
all. I strongly suggest combining the two.

> 8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the P…

great. I like this.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 18 Jul 2003 15:42:16 -0700

Vijay Devarapalli wrote:

> ICMP messages. ofcourse I dont when it might be

Pat, Jim,

I misunderstood (3) to mean use UDP both for MN-AR and 
AR-AR CARD signaling.

but I still disagree with concensus for (3) though. I 
mentioned a couple of reasons in my reply to Ajoy.

Vijay

---

From: Robert Chalmers <[email-masked]>
Date: Mon, 21 Jul 2003 14:20:18 -0700

Pat R. Calhoun wrote:

> 1. Issue #2: R-flag for CARD Request rate limiting. What to do about
> potential Dos issues? WG consensus is to Keep the R-flag approach.
> Meeting consensus is to add clarifying text to section 4.2 (4.3?)
> 
Disagree. R-flag seems like an odd design for rate-limiting. Are we 
expecting MN's to be constantly querying their AR's for the latest news, 
or will they make one or two requests prior to handover. Resending will 
be due to losses, and normal rate-limiting techniques work well in this 
environment (especially if AR isn't even receiving the messages due to 
congestion on the wireless link - no reply - no R-bit).

> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6?
> Meeting consensus is to keep the current text for CARD protocol
> operation with FMIPv6.
> 
Agree. Since this is an experimental draft, leaving the capability to 
piggy-back is fine. However, the draft shouldn't waste too much text on 
the issue.

> 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
> editor recommends the use of ICMP to make it consistent with the
> mobile interface. Potential downsides: ICMP has potential security
> implications. ICMP message types on binding is also very
> implementation specific. Also, securing ICMP would require that all
> ICMP packets be secured. Meeting consensus is to keep UDP.
> 
Agree. I've never felt that inter-AR protocols should use ICMP.

> 4. Issue #5: Static vs. dynamic capability attributes. The editor
> recommends that we keep the S-bit and use the 32-bit lifetime only
> when really required for dynamic capabilities. This saves bandwidth,
> but does complicate processing. Meeting consensus is to keep S-bit.
> 
Disagree. This is a bit nit-picky for an experimental draft. I'd like to 
see the protocol simplified as much as possible. People can experiment 
with it and determine whether saving a few bytes here or there would 
make a real difference.

> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast.
> Proposal by the editor is to use broadcast for IPv4 and multicast for
> IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless
> links can generate heavy traffic. James Kempf proposes that we drop
> this for now as we enter experimental. Alternative proposal is to
> mimic router advertisements, send when changes occur and send when
> new mobile shows up. Meeting consensus is to add a statement in the
> document that we considered multicast and leave it for future.
> 
Agree. Although, I'm not sure what the statement accomplishes.

> 6. Issue #12: Link Layer triggers for unsolicited CARD reply.
> Proposal is to remove the text that deals with layer 2 triggers.
> Meeting consensus is to remove text.
> 
Agree.

> 7. Issue #7. Preferences/Requirements sub-option. We should only use
> one of the two methods. Meeting consensus is to keep both the
> sub-option and the preference.
> 
Disagree. It seems like these options could be combined. Simpllify the 
protocol going into experimental so that people are willing to implement 
it and experiment. If the separation is truly necessary, it should 
become clear then.

> 8. Issue #18. Requesting ARs to perform ONLY reverse address
> translation. This is an essential feature for the MN to indicate
> reverse translation. Ultimately, this could become obsolete since the
> Proxy message does this too. Meeting consensus is to specify a R-flag
> in the CARD request message.
> 
Agree with a slight twist. The basic thing here is the reverse-address 
translation (whether or not FMIPv6 may overlap). So, the flag should 
indicate whether the MN would like the extra cabalities returned in the 
message in addition to the address info (a C-flag). Just a side note: 
beware of using R-flag hear for one purpose and using another R-flag in 
the reply for rate-limiting. It could be confusing.

> 9. Issue #25: Addressing of unicast CARD protocol messages. Should we
> use global or link local addresses? Meeting consensus is that since
> MN-AR is always on a single hop, use keep link local addresses.
>
Agree.

> 10. Issue #36: Removal of per-session state from ARs. Meeting
> consensus is to keep signalling failure recovery on AR-AR interface,
> but make it optional (MAY).
> 
Agree.

> 11. Issue #39: Further detail of signalling failure recovery
> required. Meeting consensus is that if the MN is not able to resolve
> an L2 ID, put an error code or some flag.
> 
Not sure what this means. If MN is unable to do something, who is it 
telling? Is this supposed to say if the AR can't resolve then tell the 
MN. If so, I definitely agree.

> 12. Issue #17: Separate appendix from the CARD protocol
> specification. The appendix is very large which describes many
> options. James Kempf believes that the appendix really needs to be
> shortened down to 2 pages, describing the two solutions - these are
> items that need to be resolved during the experimental phase. Meeting
> consensus is to take the appendix to 2 pages.
> 
Agree. Although I would probably prefer to see them as separate drafts. 
Two pages won't tell you much. What exactly is the purpose of the 
appendix then? Just to hint at the solutions?

bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 21 Jul 2003 19:32:08 -0400

Hi, Bob,

Please see my inline comments below.

> congestion on the wireless link - no reply - no R-bit).

[eunsoo] First of all, the R flag or the rate limiting was not introduced
for congestion control. It was introduced to defend the AR against the DOS
attack. The R flag is to notifiy the non-malicious MN about future message
dropping.

We don't like the fixed rate limit because the admin might want to set
different rate limits for different ARs. Then the question is how to inform
the MNs about it. A solution is to inform every MN. Another solution is the
R bit, which is to inform only the MNs that exceed the rate limit. By adding
the rate limit information with the R flag, the MN is informed that the
current AR has a different rate limit from the value the MN uses by default.

BTW, what is the normal rate-limiting technique you propose?

> with it and determine whether saving a few bytes here or there would

[Eunsoo] Saving air interface bandwidth is very important. I don't think
people argue about it. Please notice that people work on header compression
to save a few bytes here and there. The S-bit is much simpler than the
header compression but can save a lot more bandwidth.

> it and experiment. If the separation is truly necessary, it should

[Eunsoo] Please notice that you are proposing introduction of a flag to
combing the two sub-options, which you claim introduces complexity.

I am neutral about this issue. But I don't think having two separate
sub-options make the protocol a bit more complex.

> MN. If so, I definitely agree.

[Eunsoo] Your understanding is right.

> appendix then? Just to hint at the solutions?

Eunsoo

---

From: Robert Chalmers <[email-masked]>
Date: Mon, 21 Jul 2003 17:46:27 -0700

Eunsoo,

>>> 1. Issue #2: R-flag for CARD Request rate limiting. What to do 
>>> about potential Dos issues? WG consensus is to Keep the R-flag 
>>> approach. Meeting consensus is to add clarifying text to section 
>>> 4.2 (4.3?)
>>> 
>> 
>>  expecting MN's to be constantly querying their AR's for the latest
>>  news, or will they make one or two requests prior to handover. 
>> Resending will be due to losses, and normal rate-limiting 
>> techniques work well in this environment (especially if AR isn't 
>> even receiving the messages due to congestion on the wireless link 
>> - no reply - no R-bit).
>> 
> 
> 
> [eunsoo] First of all, the R flag or the rate limiting was not 
> introduced for congestion control. It was introduced to defend the AR
>  against the DOS attack. The R flag is to notifiy the non-malicious
> MN about future message dropping.
> 
This makes no sense to me. The R-flag protects the AR from Dos attacks
by telling non-attacking mobiles to slow down? It's pretty clear that an
attacking mobile is going to ignore the R-bit anyways. So, all you end
up doing is degrading service to those mobiles not causing the problem,
and opening up bandwidth for the attacker.

According to the draft:

    Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
    during link layer scanning, sometimes a MN might send frequent MN-AR
    CARD Requests, thereby overwhelming its current AR with CARD Request
    signaling messages. To counteract this problem, the AR SHOULD set
    the R-flag (rate limiting) of a subsequent CARD Reply message for
    flow-control purposes (section 5.1.2.2), thereby requesting the MN
    to reduce the generation rate of MN-AR CARD Requests. Upon receipt
    of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
    reduce the rate of generation of MN-AR CARD Requests. The exact
    implementation of a rate-limiting algorithm should be decided by the
    implementers.

This sounds more like a "congestion control" feature to me.

> We don't like the fixed rate limit because the admin might want to 
> set different rate limits for different ARs. Then the question is how
>  to inform the MNs about it. A solution is to inform every MN.
> Another solution is the R bit, which is to inform only the MNs that
> exceed the rate limit. By adding the rate limit information with the
> R flag, the MN is informed that the current AR has a different rate
> limit from the value the MN uses by default.
> 
It just seems better to develop guidelines by which MN's behave
"properly". For instance, they should hold off on immediately resolving
each new AP in an effort to batch the requests and limit the rate of
signalling. I understand your desire for the AR to have some control
over what a "good" rate is, but the R-bit seems to me to be too reactive
for this; "Wow partner, you'd better throw on the breaks there!" Can the
MN later try to push this limit (a la TCP)? Rather, have the AR include
a sub-option on the first reply to a MN with the preferred maximum rate,
and let the MN maintain that rate. My 2 cents.

> BTW, what is the normal rate-limiting technique you propose?
Vijay has already answered this a number of times.

>>>  recommends that we keep the S-bit and use the 32-bit lifetime 
>>> only when really required for dynamic capabilities. This saves 
>>> bandwidth, but does complicate processing. Meeting consensus is 
>>> to keep S-bit.
>>> 
>> 
>> Disagree. This is a bit nit-picky for an experimental draft. I'd 
>> like to see the protocol simplified as much as possible. People can
>>  experiment with it and determine whether saving a few bytes here
>> or there would make a real difference.
>> 
> [Eunsoo] Saving air interface bandwidth is very important. I don't 
> think people argue about it. Please notice that people work on header
>  compression to save a few bytes here and there. The S-bit is much 
> simpler than the header compression but can save a lot more 
> bandwidth.
> 
Another option is to separate the sub-options so that the type
explicitly determines whether a lifetime is present or not. This is
probably not much better. In general, I don't care too much about this
one, but as an implementor I always question the need for variable
structures to represent packets. If so, then the variable values are
usually left to the end of the packet, not smack dab in the middle of it.

As side note, it seems odd to use the same capabilities structure (with
the variable lifetime) for preferences and requirements since these 
shouldn't contain lifetimes. Should they? That's what originally 
prompted the previous suggestion.

>>> 7. Issue #7. Preferences/Requirements sub-option. We should only 
>>> use one of the two methods. Meeting consensus is to keep both the
>> Disagree. It seems like these options could be combined. Simpllify 
>> the protocol going into experimental so that people are willing to 
>> implement it and experiment. If the separation is truly necessary, 
>> it should become clear then.
>> 
> 
> 
> [Eunsoo] Please notice that you are proposing introduction of a flag 
> to combing the two sub-options, which you claim introduces 
> complexity.
> 
Not at all. If you look at the structure of the sub-option, Preferences
do not have a value in the AVP format while requirements do. So, any
(Requirement|Preference) without a specific value can be considered as a
wildcard for pre-filtering. No need for a flag.

But Eunsoo, please don't be purposefully combative. Flags do not
introduce undo complexity by themselves. In the previous instance, I was
primarily concerned that the flag indicates the existence of an extra
field in the middle of the message structure which then changes the
offsets of subsequent fields.

>  sub-options make the protocol a bit more complex.
As a side note, why does it specify in Section 5.1.1 that the
Preferences sub-option is "used only in case of performing
         optional capability pre-filtering". It really has no impact on
pre-filtering, does it? My understanding is that it simply states which
capabilities should be returned in the reply message.

ttyl,
bob

  Robert Chalmers

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 22 Jul 2003 11:14:04 -0400

Hi, Bob,

> and opening up bandwidth for the attacker.

[Eunsoo] Please let me explain a little bit further. The AR will drop
messages above the rate limit. It protects the AR from the DOS attack. It is
fine as long as all the MNs know the rate limit set by the AR. So the
question is how the MN gets to know the rate limit which can be different
for different ARs. The R flag is an idea that the AR will inform the non
malicious MN of the fact that the MN reached the rate limit. If the AR
attaches the rate limit value with the R bit, the MN will know that the rate
limit of the AR is different from what the MN uses. Certainly the malicious
attacker will ignore the R flag or whatever information from the AR. As said
earlier, the AR will protect itself by dropping messages. So the R bit was
introduced to protect innocent MNs in a dynamic fashion in the case of rate
limiting.

> This sounds more like a "congestion control" feature to me.

[Eunsoo] I think dealing with the DOS attack has some common aspects with
congestion control. But it seems the draft should be clearer about the
purpose of the rate limiting and its mechanism.

> and let the MN maintain that rate. My 2 cents.

[Eunsoo] The rate limit is set by the AR. The MN can do nothing about it. We
don't envision that the AR will change the rate limit dynamically in
response to any request from the MN. It will be configured by the admin.

The last part is the idea that was proposed as one of the mechanisms by the
design team in the meeting. Certainly it works. We just need to make sure
the MN receive the reply containing the information. Actually this is the
same for the reply containing the R bit. Well, unless the MN does not
retransmit the request with the same sequence number, the AR does not know
whether the MN lost the reply. If the MN gave up retransmitting the request,
the AR never knows that the reply was lost. We need to resolve this problem.

Anyway if the reply containing the R bit includes the rate limit
information, the two mechanisms are almost the same. The R bit can be
replaced by the rate limit information. Then the difference becomes just
whether all the MNs will be informed of the rate limit or only the MN
reaching the rate limit will be informed. The latter can save air interface
bandwidth because probably most MNs won't reach the rate limit. I'd like to
hear WG opinion about these two choices.

> usually left to the end of the packet, not smack dab in the middle of it.

[Eunsoo] Well, having two types of AVP is currently done by the S bit.
Categorizing the attribute IDs for static attributes and dynamic attributes
is the same thing as having a flag. Unfortunately the value field of the AVP
is generally variable size. So pushing the lifetime field to the end does
not help the situation very much in terms of data structure. I understand
having a variable structure is not the best thing. But if we don't do this,
some people may come up with CARD Compression protocol.^^

> prompted the previous suggestion.

 [eunsoo] The preferences sub-option contains only the list of attribute IDs
and the requirements sub-option contains the list of AVPs. So they are quite
different. Is this not clear in the draft?

> wildcard for pre-filtering. No need for a flag.

[Eunsoo] Hmm, when we thought about it, we thought we would add a flag in
the sub-option header. Are you proposing putting just attribute ID values in
the combined Requirement/Preference sub-option? So if the whole sub-option
is used as Preferences, it contains a list of attribute IDs and if the whole
sub-option is used as Requirements, it contains a list of AVPs. Is my
understanding right? If you are suggesting it, then the sub-option should
have a flag indicating the usage. Otherwise the receiver cannot decode the
sub-option.

> offsets of subsequent fields.

[Eunsoo] Bob, I am not purposefully combative. I am just delivering my
technical thought in response to your comments.

> capabilities should be returned in the reply message.

[Eunsoo] Pre-filtering means what you said, that is, the AR returns only the
capabilities requested in the Preferences sub-option rather than all the
capability information. Do you think "pre-filtering" in the draft is not
clear enough? If then, how can we make it clearer?

Eunsoo

---

From: Robert Chalmers <[email-masked]>
Date: Tue, 22 Jul 2003 10:20:01 -0700

Eunsoo,

> purpose of the rate limiting and its mechanism.
Yes, I think this would be good.

> hear WG opinion about these two choices.
Even if it's reactive rather than proactive, I think adding the actual 
expected rate is much more useful for both the AR and the MN than simply 
indicating that the MN is "overclocked". Otherwise, the MN may not 
backoff fast enough, or possibly too fast. For example, the MN may be 
exceeding the AR's rate by just one packet per period. What should his 
response be to the R-bit, halve his rate? That would be too extreme. But 
if he's pushing twice as much as the AR expects, just dropping his rate 
linearly will not converge very quickly. This also complicates the 
design of the MN quite a bit, having to constantly adjust his rate.

> some people may come up with CARD Compression protocol.^^
This is an experimental protocol for G*d sakes. There's time to optimize 
in later drafts if this moves forward towards a standard. Again, I think 
that this is a bit nit-picky at this stage, but oh well.

> different. Is this not clear in the draft?
Section 5.1.3.2 says:

    AVPs MUST be encoded according to the AVP encoding rule described in
    section 5.1.4. Only ATTRIBUTES (AVP Code) need to be set. The VALUE
    indicator (Data) will not be processed and can be omitted. The 'AVP
    Length' field is to be set appropriately.

Section 5.1.4 is the same AVP section describing Requirements. So they 
have the same structure. The above indicates that Preferences simply 
have an empty Data field. This is what I'm referring to in the next issue.

Anyway, this wasn't the point of the original comment. Rather, the AVP 
encoding in Section 5.1.4 includes the lifetime field and a flag 
indicating whether that field is present. However, a missing lifetime 
field is supposed to indicate a static lifetime. Do Preferences and 
Requirements have a "static" lifetime. I'd say they have no lifetime at 
all. So, it seems odd that I have to set some bit, and skip a field to 
express that! I know this is a bit nit-picky, but I can see it being 
confusing for implementors.

I'd recommend either having a separate structure without the S-bit and 
lifetime fields for Preferences/Requirements, or change the S-bit to a 
more generic L-bit that is set when the lifetime field is present (for 
whatever reason). It's also more consistent to have something set when 
something is included, not the other way around.

> have a flag indicating the usage. Otherwise the receiver cannot decode the
No, I don't think it has to be that complicated. As a MN, I include a 
single "Requirement" sub-option with a list of the capabilities that I'm 
interested in. Each capability is encoded as an AVP. If I have a 
particular constraint on a given requirement, then there will be a Data 
field present in the AVP. Otherwise, the AVP will simply be the 
attribute that I'm interested in.

 From the AR's perspective, parsing the single "Requirement" sub-option 
is also straightforward. Everything listed should be returned to the MN 
if a matching capability exists. Anything listed that has a Data value 
should be considered when selecting appropriate CARs. This is almost 
exactly the way it is explained in Section 4:

    Optionally, the MN can provide its current AR with a list of
    capability attribute-value pairs, indicating not only the capability
    parameters (attributes) as required for capability pre-filtering,
    but also a specific value for a particular capability. This allows
    the MN's current AR performing CAR pre-filtering and to send only
    address and capability information of CARs, whose capability values
    meet the requirements of the MN, back to the requesting MN. The
    format of this optional Requirements message parameter is described
    in section 5.1.3.3.

> clear enough? If then, how can we make it clearer?
This was a mis-understanding on my part. In the past, we had use 
pre-filtering to refer to the precess of choosing a set of CARS at the 
AR. I see now that you are using it to indicate filtering of the 
returned capabilities.

ttyl,
bob

  Robert Chalmers