Re: (virtual) hum on CARD open issues

My consensus vote inline - Hemant

>From: "Pat R. Calhoun" <[email protected]>
>To: <[email protected]>
>Subject: [Seamoby] (virtual) hum on CARD open issues
>Date: Thu, 17 Jul 2003 23:19:34 -0700
>
>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?)

Agree.

>
>2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting 
>consensus is to keep the current text for CARD protocol operation with 
>FMIPv6.

Agree.

>
>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.

Agree.

>
>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.

Agree.

>
>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.

Neutral.

>
>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.

Agree.

>
>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.

Agree.

>
>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.

Neutral.

>
>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.

Neutral.

>
>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).

Agree.

>
>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.

Agree.

>
>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.

Agree.

>
>
>Thanks,
>
>Pat & James
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963