Subject: Re: [Seamoby] (virtual) hum on CARD open issues

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 18 Jul 2003 16:05:17 +0000

My consensus vote inline - Hemant

>From: "Pat R. Calhoun" <[email-masked]>
>To: <[email-masked]>
>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-masked]
>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

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 21 Jul 2003 16:22:55 +0000

Hi Vijay,

---------------------------------------------------snip------------------------------------------------------

>unbelievable. the CARD protocol is already complicated (IMO).
>the emphasis should be on reducing the complexity. just use
>a value of infinity for the lifetime field to indicate a
>static capability. any other value for the lifetime indicates
>dynamic capability. I think for the CARD protocol, emphasis
>should be on making it a simpler protocol than saving 4 bytes
>over the air. :)
>
>if you are concerned about an overhead of 4 bytes, make the
>lifetime field 2 bytes. a 2 byte lifetime field gives you
>65536 seconds which should be enough. do you need a 4 byte
>lifetime field?

--------------------------------------------------------------------------------------------------------------------------------

I am netural to this issue. However, IMO reduction of complexity as claimed 
above is mostly unfounded argument. The complexity impact is mostly 
negligible. It wont take much out of the protocol implementation that is 
already so complex as you said.

So let us toss a coin and decide on what to do ;-) and move ahead.

Hemant

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail