[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Seamoby] 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


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby