Subject: RE: [Seamoby] CAR Discovery Requirements

From: Phillip Neumiller <[email-masked]>
Date: Thu, 10 Jan 2002 16:49:07 -0500

I would like to see the following requirement added:

1).  It MUST support IPv4 and IPv6, but may take advantage of features
     in IPv6 that are not in IPv4.  For example anycast addressing may
     be useful as well address autoconfiguration.

2).  It MUST provide a query (client server) and/or a post (publish and
     subscribe) method to allow other mobility protocols like those being
     worked on in the MIP and MANET WGs to cooperate with this protocol.

Thanks,

Phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 10 Jan 2002 18:49:07 -0500

Hello Phil,
Just adding to Dirk's comments, we do take care of this support for
IPv4 and IPv6 that you mention in the first point which says L2id to L3id 
(ARid) mapping is a MUST. The AR is an IP(v4 or v6) router.

Thanks,
Govind.
>Hi Phil,
>comments inline
>I can see the first part 'It MUST support IPv4 and IPv6' as a
>requirement.
>I don't see the necessity for the rest of your comment. Either you
>provide a
>solution that handles IPv4 and V6 in separate modules to fulfill said
>first
>part of your requirement. Then I don't care that for the V6 part you're
>using
>V6 features. Or you provide a combined solution which prohibits V6-only
>features since it would violate said first part.
>In conclusion, only 'It MUST support IPv4 and IPv6' is a requirement we
>have to agree on.
>
> >
>Requirement 9 of the current list already states the independence of any
>mobility management protocol. Why do you want to enforce specific
>methods that have to be provided to ensure (from your point of view)
>said independence?
>In conclusion, I think said requirement 9 is sufficient since it leave
>more freedom for the actual solution.
>
>Regards,
>
>
>
>
>Dirk
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 13:33:39 +0100

> more freedom for the actual solution.

=> I think it's important to be realistic, there is a 
difference between designing it _for_ MIP and MANET, 
and designing it to allow usage _with_ MIP and MANET. 
The latter is a minimum requirement IMO. Ignoring that
there are mobility protocols that should be used 
with the final solution, when the entire problem 
is mostly relevant to mobile devices, doesn't seem
realistic to me.

So I agree with Phil's comment.

Hesham

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 10:35:12 -0500

Hi Hesham,

It's not quite clear to me what you propose. Do you want requirement 9,
i.e., the independence from the mobility mgt., to be removed or to be
changed
to a SHOULD requirement?
The said requirement 9 exactly states that the final solution should
be able to be used with ANY mobility mgt. protocol. It does not ignore
that CAR is used in the context of mobility.

My concern regarding Phil's comment was that he mentioned specific
methods to be mandatory in the final solution. I don't think it's a 
good idea to define specific methods as requirements since they
restrict the solution space. That was simply my comment. 

Regards,

Dirk
> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Friday, January 11, 2002 7:34 AM
> To: Trossen Dirk (NRC/Boston); ext Phillip Neumiller; Govind
> Krishnamurthi; [email-masked]
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
>   > >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 16:48:29 +0100

Dirk,

  > i.e., the independence from the mobility mgt., to be 

=> No, I was suggesting that the solution must 
   accomodate the existing mobility solutions. 
   This maybe as simple as having hooks in it, 
   but might also require more work. So simply stating
   that it MUST accomodate the existing mobility 
   solutions, to me, means that when used with MIP/MANET,
   everything should work without losing any of the
   existing features in MIP or MANET protocols. 

   I hope this is clearer, you might want to change
   'accomodate' to a better word, I don't mean 
   this to be taken literally.

  > restrict the solution space. That was simply my comment. 

=> I agree that the requirements should not mandate a 
certain way of solving the problem. So when I said 
I agree with Phil, I meant the first part of his comment, 
without actually specifying 'how to do it'.
Sorry for not making this clear.

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 11 Jan 2002 10:59:12 -0500

Hi Hesham and Trossen,

We seem to dance around in abstract space a lot in this WG.  Isn't it time
to get down to brass tacks?  MIP has an implied architecture and it is not
going away.  Neither are many of the MANET protocols.  What ever happened
to the "running code" idea anyway?  I don't see why we have to be so
very vague (which is occuring strictly to be pedantic about requirement-
speak).  There is an old adage that states if its not "testable" its not
a requirement.  This WG seems to have adopted the opposite approach, i.e.
if its "testable" it can't be a requirement because it isn't vague enough.

Best regards,

Phil

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 17:18:18 +0100

Phil,

  > We seem to dance around in abstract space a lot in this WG. 

=> Really ! :)

  >  Isn't it time
  > a requirement.  

=> I agree, we should have clear and 'easy to test'
requirements. I was only explaining in generic terms
that requirements should not mandate solutions. In  this
particular case, all I care about is that no optimisations
or features of existing MIP/MANET stuff is lost.
I don't care how it's done.

Hesham

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 11:45:21 -0500

Hi Phil and Hesham,

some comments:
- requirements shouldn't mandate certain solutions. What Phil proposed
was to make certain solutions mandatory. This is not about being vague
or not. This is retricting the solutions (maybe for a certain reason).

- making the 'usage' or 'accomodation' of mobility management features
a MUST restricts the solution space, too. Is a solution prohibited, only

because it does not rely on certain mobility management features, even
if
the solution might be easier?

Regards,

Dirk

> Sent: Friday, January 11, 2002 11:18 AM
> To: Phillip Neumiller; Hesham Soliman (ERA); Trossen Dirk 
> (NRC/Boston);
> Govind Krishnamurthi; [email-masked]

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Fri, 11 Jan 2002 11:49:42 -0500

Hello Hesham,
Just for clarification. Is there an inherent assumption in your
statement that CAR discovery will need assistance from mobility management 
protocols. My understanding is that in Seamoby we don't
restrict only to MIP. Also by making it independent of mobility management 
protocols  we clearly don't affect any of the features of the underlying 
mobility management protocol is that not? Or am I missing something here.
-Govind.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 18:29:13 +0100

> the solution might be easier?

=> If we're designing things to be used, then yes
you have to be compatible with existing (very related)
protocols. What's the point of this work if it breaks
mobility management as we know it today ? 
This should not be seen as a pure research exercise
IMO, we need to design useable products. 

I'm not ruling out any new features or trying to make
it work with MIP only, I'm saying don't break the 
existing solutions. 

I think this is a pretty straight forward request
and we shouldn't dwell on it too much

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 18:45:27 +0100

Hi Govind, 

Sure you could use CAR without any mobility 
management, but I think that it is reasonable
to assume that CAR will also be very useful for 
MNs. If you agree with that, then it would sense
to make sure that it certainly works smoothly
with existing solutions, that will most likely
be around for a long time. 

Again, I' not suggesting we integrate CAR into
MIP, just make sure they work well together.

Hesham

  > From: Govind Krishnamurthi [mailto:[email-masked]]
  > Sent: Friday, January 11, 2002 5:49 PM
  > To: [email-masked]

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 12:47:19 -0500

Hi Hesham,

> mobility management as we know it today ? 

I don't quite understand your problem. Not accomodating 
existing features does not necessarily means to break mobility 
management features. It certainly has to be compatible to existing
protocols, noone ever questioned that. However, making the
accomodation of existing features mandatory restricts the solution
space.

> and we shouldn't dwell on it too much

I agree with both.

Regards,

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 19:03:38 +0100

> I don't quite understand your problem. 

=> I don't have a problem. the requirement does.

Not accomodating 
  > accomodation of existing features mandatory restricts the solution

=> This is getting confusing, you've just said 

'It certainly has to be compatible to existing ..'

then

'However, making the
  > space.'

=> What are you saying ?

  > > and we shouldn't dwell on it too much

=> Great !

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Fri, 11 Jan 2002 13:14:14 -0500

Hello Hesham,
>MNs.
----> I believe CAR discovery is for mobility and
therefore for MNs. So we have no disagreement here :).
What I said was that it may be possible for CAR discovery
to happen without any help from underlying mobility management protocols.

If you agree with that, then it would sense
>be around for a long time.
----> Agreed again and I think we are saying the same thing,
except that there seems to be confusion about how we put
it into words. IMO, working independently implies that
it does not depend on or impede any mobility management protocols.

Regards,
Govind.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 13:18:20 -0500

Hi Hesham,

maybe you should outline what you mean by 'accomodating features'.

Being compatible to existing mobility management solution means to
me not to break mobility management when introducing a specific
solution.

Accomodating features means to me to use specific features whereever
possible. 

These are two different things. The first one should be clear, I simply
don't like the second one since it restricts the solution space. That's 
where the discussion started by Phil's proposal to make specific methods

mandatory in any solution.

Regards,

Dirk

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 11 Jan 2002 13:23:12 -0500

Hi Dirk,

Perhaps we can compromise here and say that some particular set of 
specific methods MUST be supported as a minimum and not restrict at
all what goes on beyond this.  Lets be honest with ourselves here,
this protocol will be used by MIP and MANET protocols as their 
primary customers.  If not, then what customer does this requirement
serve?  Maybe I am dense on this, but I just don't get why we can't
specify the existance of an interface here?

Thanks,

Phil