Subject: [Seamoby] CARD Issues List

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 14:43:02 -0800

Folks,

I've made up a list of issues on CARD. It is available at:

     http://www.geocities.com/kempf42/CARD_Issues_List.htm

The issues are divided into Requirements, Architecture, Protocol Design, and
Editorial (about the Protocol document). Each issue has a number, a short
description, and a hyperlink to a longer description and any proposals or
resolutions (very few issues are resolved). Issues can be in the state of:

    Open: the issue is identified and there are either no or multiple proposed
solutions.

    Proposal: there is a single proposal, discussion is underway, but there
seems to be concensus around the proposal

    Resolved: the WG has agreed to a resolution (or, in the case of editorial
issues, the resolution is trivial).

I've tried to represent the various proposals fairly, if I've missed anything or
got it wrong, please send me email and let me know. Also, if there are any
additional issues that people have, please send email to the list clearly
identifying the issue and any proposed resolution.

Also, please continue discussion on the existing issues, we are far from
resolving them. However, I'd also like to hear from people on the list who don't
have an intellectual investment in one of the existing proposals (dycard or DT).
The conversation last few days has been too much like a rugby match, and playing
referee has been too time consuming.

                        jak

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

---

From: [email-masked]
Date: Fri, 14 Mar 2003 11:36:32 -0500

James,
Thanks for taking the time to putup a website. 
It will help us follow the discussion better.

Here are my comments.

Issue 1: You haven't mentioned the general WG opinion (including people from the DT)
that this issue is out of scope. We may be dealing with non-IP addressable devices here of
different technologies, and as pointed out by a slew of email,
and that there are existing methods to take care of this. 

So would this be a good statement for an alternative proposal for Issue 1?
Proposal 2: Problem is important, but is out-of-scope of CARD.  We
can use the following statement in the final spec. The operator/ISP MUST
provide an authorized list of AP beacons that can be attached to each AR. 

Issue 2:
Proposal 2: If you remove the server from the base draft, how is this base draft
going to address the AP-AR mapping. This is not clear to me. 
Maybe I'm missing something.

Issue 3: Though I'm not against putting explicit text in,
 I don't think explicit text is necessary. If the "cache protection"  scheme 
is designed well this kind of rate limiting will automatically happen. Rate limiting
may be difficult when used in the DT scheme, as MNs may report APs from other domains.

Issue 4:
Proposal 2: Apart from what is written, this should be added to the 
proposal. The scheme also uses a third party verified unique MN id and 
tags it with each cache entry. The number of cache entries created 
per MN is this limited. 

Proposal 3: I have illustrated the problems associated with Proposal 3. This is not
very secure against attacks by multiple malicious MNs, particularly when used
in conjunction with the DT approach. I haven't looked at the proposal's efficiency
when used with the cache population scheme described in dycard. I think
Proposal 2 works fine with dycard and we don't need proposal 3.

Issue 5:
Again, I think the points raised in the mailing list are missing here.
I think we shouldn't really do what is being proposed here. I think CARD is not
just for FMIPv6. 

Issues  6 - 9:
These issues may not exist when you have finished tackling prior issues.

Apart from these issues, here is an issue that was brought up in the mailing list:

Issue 12: Non-conformance with Requirement that deals with ARs with private
 and site-local addresses:
DT draft currently does not address this. 

Proposal: One possible approach is presented in dycard. 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Fri, 14 Mar 2003 14:17:06 -0500

> OK, I will add it.
[Govind] Thanks.

> Spell it out, please. It is not obvious to me that the DT 
> draft doesn't deal
> with site-locals, nor that the Dycard draft does.
[Govind] Would it suffice to say that one approach is described in section 4.8.5 of the dycard draft? Or do you want me to go into detail?
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby