Proposal to resolve remaining CARD issues

Hi all,

to resolve the remaining issues of the CARD protocol 
specification, please find below a list of these issues
with a short description of a proposed solution
appended to all of them.

If there are no concerns or negative comments, we'll
incorporate the proposed mechanisms into the next
updated version of the CARD protocol document,
which will be available beginning of next week.

marco


Issue#5: static vs. dynamic capabilities.
-----------------------------------------
Since there were some objections w.r.t the S-flag
in the Capability AVP encoding format, we drop the
S-flag for now and take over the proposal of
indicating a static capability by means of setting
the lifetime to 0. Lifetime field will be reduced
to 16 bit (unit is seconds) and will be always present. 

Issue#6,issue#15 and issue#23: addressing and
protection of unsolicited CARD Reply messages.
-----------------------------------------------
Addressing of unsolicited CARD Reply messages will
be done using a well-known multicast address. This
requires to request a well known multicast address
from IANA for IPv4 and IPv6 (link-local).
For authentication of unsolicited CARD Reply
messages, refer to the use of Digital Signatures
in the Security Consideration section. Since this
is a problem which is common to other protocols
(Router Advertisements), hope there will be more
efficient mechanisms in the future.

Issue#9: Reverse Address Translation function -
CARD vs. FMIPv6 (Piggybacking approach)
-----------------------------------------------
Proposal is to include an additional flag in the
CARD Request message, which allows a mobile terminal,
when performing CARD protocol piggybacking with
FMIPv6, to use CARD only for Capability Discovery
without Reverse Address Translation (will be
performed using the related FMIPv6 function). This
implies, that no L2 ID will be appended to the CARD
Request message and only Capability Container
parameters will come back to the mobile terminal with
the CARD Reply. Correct association of CARs' Capability
Containers (coming with CARD Reply) with CARs' IP address
(coming with PrRtAdv) will be done according to the
order of how resolved IP addresses are listed in the
PrRtAdv, whereas the Context-ID of the Capability
Container indicates the position in that table
(1,2,3...). 

Issue#17: Preferences/Requirements sub-option - One
of them is sufficient?
---------------------------------------------------
Proposal is to keep both, since this implies just the 
definition of a further sub-option type, which indicates
that only Attributes without any Data field will follow
in case of receiving a Preferences sub-option.
The Requirements parameter sub-option will carry then a
list of Attribute-Value pairs, the Preferences parameter
carries a list of Attributes (just the AVP Code and
Length, no Lifetime, no Data).


Issue#40: 8-bit CARD Option length not enough
---------------------------------------------
Length indicator units of CARD messages and parameters
have been adjusted:

CARD Request/Reply: 8-bit length indicator in units of
8 octets including the message header.

Capability Container sub-option: 8-bit length indicator
in units of 8 octets, not including the sub-option header.

Remaining sub-options: 8-bit length indicator in units
of octets including the header.