CARD issue#29: more text on use of "Context-ID" and "M-flag"required

Hi all,

going through the remaining open issues, there are some
important ones, which have not been discussed during the
meeting in Vienna. Here is one: 

There was a comment that more text w.r.t use of Context-ID
and the M-flag is required. The proposal is to briefly describe
the mechanism again and to solicit comments. After having agreed 
on a mechanism, more text will be added to the document.
Please find a desciption/example of the proposed mechanism below:

Since the L2 ID, a CAR's IP address and associated capabilities come
with separate sub-options in a CARD Request/Reply message,
association is indicated using a Context-ID.
Example:

MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR
in a CARD Request for resolution:

CARD Request (MN->AR)
L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1
L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2

Now, first assume both L2_IDs (APs) connect to 2 different
CARs, hence, associated IP address and capability container
is identified with the respective Context-ID :

CARD Reply (AR->MN)
IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
IP address of CAR(2) comes with capability container(2), both carry Context-ID=2.

Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR:
IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
L2_ID(2) comes back with "Context-ID=1", "M-flag=1".

M-flag avoids to send IP address and capability container of the same CAR
back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed
to Context-ID=1, M-flag indicates that Context-ID has been modified by the
AR and that associated CAR IP address and associated capability container
is the same as for a previously received IP-address/capability
container pair, here indicated with Context-ID=1.

Comments?

marco