Subject: [seamoby] I-D ACTION:draft-koodli-seamoby-ctv6-00.txt

From: [email-masked]
Date: Mon, 26 Feb 2001 07:05:40 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Context Transfer Framework for Seamless Mobility
	Author(s)	: R. Koodli, C. Perkins
	Filename	: draft-koodli-seamoby-ctv6-00.txt
	Pages		: 19
	Date		: 23-Feb-01
	
Mobile nodes enhance their connections across wireless media
by establishing various kinds of state (context), in order to
make practicable, secure, and economical use of the available
bandwidth.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-koodli-seamoby-ctv6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-koodli-seamoby-ctv6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Feb 2001 13:29:05 -0800 (PST)

A couple of comments:

1) This draft is completely v6-centric. Does that mean
   that we'd have yet another protocol which has gratuitous
   differences between v4 and v6? If so, why is that advantageous?

2) It presumes that ICMP will be the proper transport for
   a context transfer protocol. How was it arrived at that, say,
   some other ip version neutral protocol over, say, SCTP
   was not preferable. It would be nice to see some rationalization
   for the design criteria which lead to this choice. As far as
   I can tell, it was only driven by the MIP's fast handoff 
   draft group's desire to overstep their bounds
   and solve their narrow slice of the whole CT
   problem.

		Mike

[email-masked] writes:
 > Content-Type: text/plain
 > Content-ID:	<[email-masked]>
 > 
 > ENCODING mime
 > FILE /internet-drafts/draft-koodli-seamoby-ctv6-00.txt
 > Content-Type: text/plain
 > Content-ID:	<[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Feb 2001 16:20:43 -0800

Hello Michael,

In order to help understand our draft, I will try to explain
our reasons for publishing it.

- The protocols are expected to work based on our experience
  of implementing a prototype.

- We think that practical experience and a systematic approach
   to the problem is of some considerable value.

Of course, beauty is in the eye of the beholder, and your message
indicates that not much of value has registered with you.  Even so,
we still think that there are some design ideas that bear serious
consideration.  For starters, we really like the idea of a general profile
type which can be specialized to describe a profile type for any of
a wide class of context features.  It took us a long time to figure that
out, and it's worthy of discussion.  It's especially worthy, because we
know there is a road map from general to specific that is not hard to
travel.  That makes us think our design is at the right level of
abstraction.

Having said all that, perhaps I can respond more appropriately
to your points.

>    differences between v4 and v6? If so, why is that advantageous?

We believe that the form of our solution can be quickly adapted
to whatever requirements emerge for the IPv4 solution.  Our draft
is v6-centric, but that is only the form, not the major content.

>    and solve their narrow slice of the whole CT

Our draft is a draft.  We think it's good.  We know it can be
improved.  The rationalization for choosing ICMP is simple:
the signals fit into the definition of what an ICMP message should
be as best we understand that.  They are control messages,
controlling the orderly delivery of context messages.  Maybe
a transport protocol would be better.  That would not change
very much of the design.  The design is much more widely
applicable than your "narrow slice" characterization would lead
one to believe.

Drafts come and go.  Maybe our draft will be viewed as having
some value by other people.  Maybe someone will read it and
have an idea about how we can improve it.  Maybe some or all
(or none!) of it can be adapted as a working group draft.  We
look forward to the discussion.

Somehow I think that this is a very long note that is saying nothing
surprising.  On the other hand, the content of your note seems to
invite defense.  I can assure you that none of the design in our
draft was driven by any desire to overstep bounds.  In fact, just
the opposite: our design was driven by a desire to work within
the bounds established by [seamoby] problem statements, and
by our best guess about how [seamoby] might interact with the
routing solution proposed by the design team in the [mobileip]
working group.  That is a good way to work.

If the problem statements change, or if the outputs of the design
teams are revised, we would naturally look at changing the
relevant parts of our design document.

Why do you think this is not a good approach?

Regards,
Charlie P.