(virtual) hum on CARD open issues

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