CARD review - Minor issues

hi all,

version 04 is a much improved draft. thanks. here are some minor issues 
that
I could spot.

>   If a MN can listen to L2 IDs of new APs prior to making decision
>   about IP-level handover to CARs, a mechanism is needed for reverse
>   address translation. This function of the CARD protocol enables the
>   MN to map the received L2 ID of an AP to the IP address of the
>   associated CAR that connects to the AP. To get the CAR's IP address,
>   the MN sends the L2 ID of the AP to the current AR and the current
>   AR provides the associated CAR's IP address to the MN.
>
>   In cases where the MN can acquire IP connectivity with CARs prior to
>   making handover decisions, this functionality is trivially realized,
>   since the MN can request CARs individually for discovery of
>   capabilities.
>  
>
doesnt the second paragraph belong to section 3.2?


in section 4.2.1, delete

>For example,
>   using the Preferences message parameter, a MN may indicate that it
>   is only interested in these CAR(s) supporting a specific air
>   interface technology. Similarly, using the Requirements message
>   parameter, a MN can indicate the list of capability attributes and
>   associated capabilities' values to its current AR. The Requirements
>   message parameter may be used to indicate the cut off values of the
>   capabilities for the desired CAR(s).
>
the above is a repeat. it is previously described in detail in
section 4.


section 4.3.1

>the MN's current AR
>   SHALL extract the capability information from the payload of the
>   received message and buffer the received capabilities in its local
>   CAR table.
>
s/buffer/store/


section 4.3.2

>AR-AR CARD Request. The CAR SHALL buffer the received capabilities
>
same as above


section 4.4.1

>A MN SHALL detect the loss of a
>   MN-AR CARD Request or MN-AR CARD Reply Message using a timeout
>   mechanism (MN_AR_CARD_TIMEOUT). The MN SHALL start a timer
>   (MN_AR_CARD_TIMER) after sending a MN-AR CARD Request message with
>   the given sequence number. The MN SHALL stop the timer as soon as
>   the reply to the MN-AR CARD Request is received by it. Upon
>   expiration of the MN_AR_CARD_TIMER, the MN SHALL declare the
>   outstanding message as lost, resends the same message and restart
>
>   the MN_AR_CARD_TIMER.
>

replace the above by

A MN SHOULD retransmit the CARD Request, if it does not receive a
CARD Reply within MR_AR_CARD_TIMEOUT seconds.


section 4.4.2

>The MN's current AR MAY detect the loss of an AR-AR CARD
>   Request or an AR-AR CARD Reply message using a timeout mechanism
>   (AR_AR_CARD_TIMEOUT). The current AR MAY start a timer
>   (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the
>   given sequence number. The current AR should then stop the timer as
>   soon as the reply to the AR-AR CARD Request is received by it. Upon
>   expiration of the AR_AR_CARD_TIMER, the MN's current AR declares the
>   outstanding AR-AR CARD Request as lost and then resends the same
>   message to the CAR.
>

replace the above by

The MN's current AR SHOULD retransmit the CARD Request, if it does
not receive a CARD Reply within AR_AR_CARD_TIMEOUT seconds.

section 4.5

> To allow MNs and ARs appending the ICMP-option type CARD Request and
>   CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6
>   signaling messages
>
I think this is the first time Fast MIPv6 appears. a reference to
the FMIPv6 draft will be useful.


section 4.6

>  The MN-AR and AR-AR messages' authenticity MUST be ensured using
>   IPsec ESP [10]. It is safe to assume that there will be an
>

s/it is safe to assume/The CARD protocol assumes/

>   appropriate SA between a MN and its connected AR, which MAY be used
>

s/appropriate SA/IPsec Security Association/

>   The proposed mechanism for authenticating unsolicited and multicast
>   MN-AR CARD Reply messages at MNs is the use of digital signatures.
>   This assumes that the MN has discovered the respective AR's public
>   key before the received unsolicited CARD Reply messages can be
>   validated.
>

this is too vague. why not just say

  This document does not specify a mechanism for securing
  unsolicted multicast MN-AR CARD Reply messages.


section 5.1.1, delete the following. it is already said in a
couple of places in the draft.

>         Encapsulating Security Payload (ESP) Header:
>                        IPSec ESP MUST be used with a non-null
>                        integrity protection and origin authentication
>                        algorithm and SHOULD be used with a non-null
>                        encryption algorithm for protecting the
>                        confidentiality of the CARD information.
>

section 5.1.3.1

>   L2 type:       Indicates the interface type (optional).
>
>                  If the L2 type indicator is not used, this field MUST
>                  be set to 0x00.
>
>                  The following types are initially defined:
>
>                  Technology    |  L2 type
>                  --------------+---------
>                  IEEE802.11    |   T.B.A.
>                  CDMA2000      |   T.B.A.
>                  WCDMA         |   T.B.A.
>

I think IANA does not have assign the L2 type. it can be done in
this draft itself. I know I was the one who raised this issue
earlier. but now I realise IANA's role is not needed for the L2
type. my mistake.


Vijay