Subject: RE: [netlmm] RE: PMIP follow-up questions (was RE: Why is PMIP...)

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 2 Nov 2006 02:52:40 -0800

> > Also, for the sake of argument, do
 > > you think that adding 100 lines of code to an existing base is more
 > > expensive in terms of design/testing/support/OAM than 
 > writing a new 1000
 > > line code? I don't think so.
 > 
 > Actually, even adding 10 lines to a large codebase can be 
 > more expensive
 > than 1000 lines in a fresh application.  Especially testing effort is
 > proportionate to the number of combinations of features, rather than
 > number of added lines.  And it is very likely that adding 
 > the 10 lines is
 > going to break something when you are trying to force 
 > together things that
 > don't really fit, such as for instance the very different authority
 > relationships which you have in MIP and PMIP.

=> You're making very different assumptions about the authentication
issues IMO based on a different idea of how this will work than what I
have in mind. So, as a consequence you're coming to a very different
conclusion. If you want to discuss this we can discuss it in the context
of a proposal, I don't think email will be useful. 

As for implementation efforts I find it interesting that you think
adding 10 lines of code will introduce errors (which it might of course)
but you seem less concerned about the errors, interop issues, lines of
support and maturity of a new protocol...anyway, we can agree to
disagree on this.

 > 
 > Are you saying that you believe the authentication and authority
 > model in MIP and in PMIP are the same?

=> No but I think the change is very small; we can change the trust
model with virtually no change in the implementation. 

 > > I don't know where you got that from either. Please feel free to
 > > check with me or others before you assert this information. The
 > > information above is completely false. We don't have an HA and my
 > > arguments here are not motivated by any product on offer 
 > by my employer.
 > > I don't appreciate the mind reading Henrik, please don't do that.
 > 
 > Oh, it wasn't mind reading, you don't have to worry about that.
 > 
 > I apologize for the erroneous assumption.
 > 
 > But if Flarion didn't have a HA implementation, I'm afraid I 
 > have been
 > sorely misled by your indications of knowledge and understanding of
 > what's needed to build, maintain and extend a MIP HA software
 > implementation.

=> So because I worked on MIPv6 implementations you thought I had an HA
product...No I don't have the HA product, but I built and maintained
larger products in a company you might be familiar with (it was only
used by a couple of hundred million people at the time so I don't know
if that's credible enough for you), but I'm not guessing what's involved
in a product cycle. Anyway, I find it better to show merit through a
technical discussion, so let's stick to that.

 > 
 > Of course Flarion could have had one, and Qualcomm could have ditched
 > it.  I didn't think of that.  

=> I guess you didn't think enough. In the meantime I'm more interested
in a technical discussion, but feel free to explore that track more with
someone else.

   But I really thought from comments from
 > you over the last 3 or 4 years that you had had experience 
 > from working
 > with HA software, both v4 and v6.

=> This is funny. I didn't work with v4 HA SW, I don't know what
comments you're talking about. 

Hesham

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 02 Nov 2006 13:31:11 +0100

on 2006-11-02 11:52 Soliman, Hesham said the following:
>> > expensive in terms of design/testing/support/OAM than  writing a new 1000
>> Actually, even adding 10 lines to a large codebase can be more expensive
>> number of added lines.  And it is very likely that adding the 10 lines is
>> going to break something when you are trying to force together things that
> You're making very different assumptions about the authentication

I'm concerned not with the specifics of a proposed solution here, but
with the fundamental difference between what an AR in a visited network
may be permitted to do on behalf of an MN, and what the MN may do using
its own credentials.

> support and maturity of a new protocol...anyway, we can agree to

You assert that I'm not enough concerned about errors, after I point out
the cost of testing effort...  Maybe we should leave these assertions of
what the other guy seems to be thinking and concerned about, and do what
you propose below - deal with technical arguments.

I wished to call you on your assertion of implementation costs, which
is very contrary to my experience; we've gone over that now.

> No but I think the change is very small; we can change the trust

Ok.  So here we have a fundamental disagreement.

>> > arguments here are not motivated by any product on offer  by my employer.
> So because I worked on MIPv6 implementations you thought I had an HA
> product...

Not primarily that, more the way I've understood your comments and
arguments over the last couple of years.  But I apologize for that
mistake.

	Henrik