Subject: [Mip6] Draft - draft-patel-vendor-options-00.txt

From: Alpesh <[email-masked]>
Date: Thu, 18 Dec 2003 18:31:35 -0800

Hi -

A new draft is available for your reference at:

ftp://ftp-eng.cisco.com/mipdrafts/draft-patel-vendor-options-00.txt

 Introduction
 
        The base specification of Mobile IPv6 [1] does not allow for
        organizations  and  vendors  to  include  organization/vendor-
        specific information in the Mobile IP messages.  It is useful
        to have vendor or organization Specific Mobility Options in
        Mobility messages to carry more information than is permitted
        by standard messaging.  This document defines a mobility option
        that  can  be  used  for  including  organization  specific
        information by vendors/organizations for their own specific
        purposes.

Thx
-a

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Dec 2003 16:01:34 +0200

Alpesh,

Is the purpose to define permanent local enhancements, or to
allow for experimentation e.g. trials and tests before we know
whether the new scheme makes sense?

I'm asking because there is definately a need for the latter,
but the former might raise some questions about interoperability.
And the solutions for the two goals not be the same. A space specially
set aside for experimental moboptions and MH header values would
suffice for the experiments, whereas more permanent vendor extensions
would require something like you have proposed.

--Jari

---

From: Alpesh <[email-masked]>
Date: Fri, 19 Dec 2003 08:32:43 -0800

Jari -

The intention of this draft is for the vendors to add their information 
in the
control  messages. I was looking more on lines of skippable and 
non-skippable
options in MIPv6, but my search found that they were not considered.

I am working on a draft to reserve experimental number space (similar effort
in mip4 WG) to permit experimentation (which will not be in shipped 
products).

Good that you see a need for experimental extensions - more reason to 
publish it
sooner than later :)

-a

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Dec 2003 20:47:27 +0200

> options in MIPv6, but my search found that they were not considered.

Yes. On the other *everything* beyond the base specification is
skippable.

So on the surface it looks like there could never be any interoperability
or "vendor lock-ins" due to vendor specific options. However, I'm not
sure this would prevent someone from sending a 129 if, say, a vendor
specific authorization mobption was missing. If you have good ideas
how to avoid us getting into that kind of a situation, let us know...

 > Good that you see a need for experimental extensions - more reason to publish it
 > sooner than later

Please do. That could be a very short RFC that simply updates the IANA
tables.

--Jari