Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff)

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 15:59:18 -0600

Hello Pat,
Thanks for expressing your thoughts.
Please find my few 
inline comments. 
Regards,
Ajoy 

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 2:24 PM
To: [email-masked]
Subject: [Seamoby] My thoughts on server approaches (and other fun
stuff)

Just caught up on the rather long e-mail thread, and wanted to
communicate my feelings about the discussions going on.

My initial reaction is that mandating a server is the wrong approach. I
am not claiming that discovery over the air, or some other approach, is
better, but *requiring* a server is problematic.

AJOY-> I agree that requiring a new server introduces a single point 
of failure. But if we piggyback CARD function over the existing 
server such as AAA, it will not have this problem though. BTW, 
if WG decides not to that then I am fine with that too. But so 
far I have only heard from dycard co-authors.  BTW, the DT
proposed server based approach to get the feedback from WG. 
The DT will be happy change the approach if WG decides that. 

 I agree that service
providers will most likely not have much of an issue with requiring a
server for their network, but I doubt that enterprises that require
mobility, really want more infrastructure to manage.

AJOY-> Servers are easier to manage. BTW, if the CARD function 
can be integrated with existing server function e.g., AAA, then I do 
not see why enterprise will need to manage extra infrastructure. 

One issue that I've heard in favor of a server approach is security.
I'll admit that I don't understand all of the issues, but there are
plenty of proof points where security can be provided without a backend
server. Whether it be peer-2-peer authentication via shared secrets,
certs, or what-have-you. In fact, maybe we should look at how OSPF
domains are created, and how routers communicate in a secure fashion? I
understand there are significant differences, but is there anything we
can learn from?

AJOY-> I am not sure if comparing security requirements of intra-domain 
routing protocol with that of CARD is fair. I will definitely like to 
hear from the security experts because I do not consider myself 
as a security expert.   

The next issue I have is what appears to be a requirement to build an
iron-clad protocol. I get very nervous when I hear that folks want to
create a protocol that cannot drop a single call (or packet!). 

AJOY-> I think here simplicity is the key. If we can get simpler 
protocol that can guarantee less or zero call drop, then what is
wrong in using that. I would request you to read dycard as 
well as DT draft to conclude which is more complicated protocol. 

Let's be
fair here folks, my cell phone drops calls all the time, regardless of
whether I'm doing a 911 call or not. That's just the nature of 1) really
complex systems, 2) unreliable code and 3) wireless is simply NOT
reliable. So in my opinion, we need to design a protocol that works
well, and can tolerate failures and recover from any problems.

AJOY-> I agree that cell phone can drop the call due to poor 
radio conditions. The radio conditions change due to many 
factors which we cannot control sometime. But, cellular networks are 
not designed to drop the call though. 

I'm perfectly happy with a protocol that learns about it's neighbors.
It's all about trade-offs. Ethernet also has a cache, and has designed a
mechanism to re-validate the cache before it expires. Again, another
area that we should look into, and determine whether it can be applied
to this particular scenario.

AJOY-> I will be happy with such protocol if the protocol in questions
is a simple protocol and  provides significant benefit over 
other protocol in consideration. 

The last one is rumblings about inter-domain. This subject has come u
before, and at that time the result was that it was out of scope (and it
still is).

AJOY-> Ok, but I suppose we are not discussing the inter-domain issues. 
Even in big access network, the security associations are not manually
configured though.  

Next is just a nit. When I hear "DT hat off", it provides the appearance
that DT members have more power than the rest of the WG, and I just
wanted to lay that one to rest... a DT serves the WG and does not have
more power (or say). We are all individual contributors working towards
a common goal.

Hope this help,

PatC

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

---

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 14:18:05 -0800

> The DT will be happy change the approach if WG decides that. 
Right, and I'm providing my feedback... but I'm just one of many.

> not see why enterprise will need to manage extra infrastructure. 
embedded devices need to be configured, regardless of whether a server
is present or not. At a minimum, you'll want to create some form of
security relationship between the embedded device and the server... so
there's no way around it :(

> hear from the security experts because I do not consider myself 

Well, maybe it's not a fair comparison, but I'd like to know why. If we
are focused on intra-domain, then I see no difference.

> well as DT draft to conclude which is more complicated protocol. 

There's nothing wrong with high availability, but there's a price to pay
for that. If you're telling me that it's free... then I get really
confused and am willing to be convinced :)

> not designed to drop the call though. 

Ah, but that's my point exactly. They are designed to NOT drop calls,
but they do. There's physics involved here, and there's nothing in the
IETF we can do about it. So let's just keep that in mind while we decide
how complex this needs to be.

> other protocol in consideration. 
Simplicity, in itself, is a significant benefit.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 14:18:05 -0800

PatC