Subject: [Mipshop] I-D ACTION:draft-ietf-mipshop-mis-ps-01.txt

From: [email-masked]
Date: Wed, 09 May 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

	Title		: Mobility Services Transport: Problem Statement
	Author(s)	: T. Melia, et al.
	Filename	: draft-ietf-mipshop-mis-ps-01.txt
	Pages		: 18
	Date		: 2007-5-9
	
There are on-going activities in the networking community to develop
   solutions that aid in IP handover mechanisms between heterogeneous
   wired and wireless access systems including, but not limited to, IEEE
   802.21.  Intelligent access selection, taking into account link layer
   attributes, requires the delivery of a variety of different
   information types to the terminal from different sources within the
   network and vice-versa.  The protocol requirements for this
   signalling have both transport and security issues that must be
   considered.  The signalling must not be constrained to specific link
   types, so there is at least a common component to the signalling
   problem which is within the scope of the IETF.  This draft presents a
   problem statement for this core problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mis-ps-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ietf-mipshop-mis-ps-01.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-ietf-mipshop-mis-ps-01.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.
_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 May 2007 14:12:29 -0700

Hello,

The revised draft is available. To all those who had comments during
the WG last call, please check if your comments have been addressed.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, May 09, 2007 12:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Mipshop] I-D ACTION:draft-ietf-mipshop-mis-ps-01.txt 
> 
> This draft is a work item of the Mobility for IP: 
> Performance, Signaling and Handoff Optimization Working Group 
> of the IETF.
> 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 10 May 2007 01:37:35 +0300

I couldn't see what changes were made in response to my feedback (except few
items) --
http://www1.ietf.org/mail-archive/web/mipshop/current/msg03243.html.

I'd appreciate if the authors can point out if I missed any relevant
changes, or if they have some other response.

Alper

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, May 10, 2007 12:12 AM
> To: [email-masked]
> Subject: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt
> 
> Hello,
>

---

From: Telemaco Melia <[email-masked]>
Date: Thu, 10 May 2007 11:33:44 +0200

Alper,

Please find below the view of the authors in response to your questions.

+ Concern about having not relevant material in the PS doc (e.g. 
requirements, formats, layering..).
This issue has been extensively discussed even before the adoption of 
this document as WG document. (Eleanor presented this during IETF# 65 if 
I recall exactly...) The conclusion was that having such information in 
the document it helps in understanding the problem and it clearly 
identifies mipshop's playground.
I went back to some emails exchange we had in September and I found the 
following (Robert's email):
"....However, my recollection from the meeting (and also the minutes) 
was that for a number of people, a "pure" PS draft was very difficult to 
absorb without
the architectural context, which includes at least the .21 discussions. 
Also in Montreal the AR-info issues came up as another (not .21) 
protocol user...."
Nobody ever complained about the above statement and the authors assumed 
the WG was fine with this (at least up to now).

+ Relation with 802.21
The document has undergone several review iterations from 802.21 folks. 
(Yoshi triggered several times .21 experts)
We received detailed comments on section 5.2 and nothing conflicting 
with .21 activities was found.
In the document we refer to Mobility Services as supporting functions 
for media independent handovers and IS, ES, CS are  an example.
Such interpretation of the Mobility Services was discussed/agreed back 
to the Montreal meeting. (Cannot find the appropriate email thread)

+ Comment on section 4.2, 4.3 and 4.4
Again, this is part of what we call architectural context necessary to 
explain the content of the document.
And yes, you are right, the scenarios come from IEEE. Is there any 
problem in having them in this document?

+ About naming
ID name has been adapted to address your comment.

A final remark on the statement "Much of the functionality required for 
this problem is available from existing IETF protocols or combination 
thereof."
One of the DT's goals is to reuse/adapt, where possible, existing 
solutions. Do you see the sentence harmful?

Please consider that the PS doc was widely discussed in Prague and 
agreed by all parties.
We hope the above explanation address your concerns.

regards,
telemaco

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155
Network Laboratories			Web: http://www.netlab.nec.de
Kurfuersten-Anlage 36			       
69115 Heidelberg
GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 11 May 2007 01:34:48 +0300

Hi Telemaco,

I appreciate the effort people put into this I-D. But I believe this I-D has
some extra baggage that can cause unintended side effects. I'm trying to
raise such issues.

Please see below.

Alper,

+ Concern about having not relevant material in the PS doc (e.g.
requirements, formats, layering..).
This issue has been extensively discussed even before the adoption of this
document as WG document. (Eleanor presented this during IETF# 65 if I recall
exactly...) The conclusion was that having such information in the document
it helps in understanding the problem and it clearly identifies mipshop's
playground.
I went back to some emails exchange we had in September and I found the
following (Robert's email): 
"....However, my recollection from the meeting (and also the minutes) was
that for a number of people, a "pure" PS draft was very difficult to absorb
without
the architectural context, which includes at least the .21 discussions. Also
in Montreal the AR-info issues came up as another (not .21) protocol
user...."
Nobody ever complained about the above statement and the authors assumed the
WG was fine with this (at least up to now).

Alper> That's the intent of the WG last call, right? I'm raising a concern
about this. If I'm the only one, and no one else cares, I don't intend to be
hung up on these points -- despite my strong belief on some of them.

Alper> For example, how does the Section 5 and 5.1 really help, other than
prematurely setting the tone of the solution? If all we need to say is that
we need to transport some IEEE 802.21 defined payloads, we can just say so.
We shall leave the further details to the solutions.

+ Relation with 802.21
The document has undergone several review iterations from 802.21 folks.
(Yoshi triggered several times .21 experts)
We received detailed comments on section 5.2 and nothing conflicting with
.21 activities was found. 

Alper> I didn't mean we are conflicting with .21. My question is, do we
intend to go beyond transporting what's defined in .21? 

In the document we refer to Mobility Services as supporting functions for
media independent handovers and IS, ES, CS are  an example.
Such interpretation of the Mobility Services was discussed/agreed back to
the Montreal meeting. (Cannot find the appropriate email thread)

+ Comment on section 4.2, 4.3 and 4.4
Again, this is part of what we call architectural context necessary to
explain the content of the document.
And yes, you are right, the scenarios come from IEEE. Is there any problem
in having them in this document?

Alper> I think it is best if we simply refer to .21 documents.

+ About naming

A final remark on the statement "Much of the functionality required for this
problem is available from existing IETF protocols or combination thereof."
One of the DT's goals is to reuse/adapt, where possible, existing solutions.
Do you see the sentence harmful?

Alper> I think I-D should say what you intend: "goal is to reuse/adapt,
where possible, existing solutions." The authors of this I-D might have done
an analysis and achieved the documented conclusion. But unless you share it
with us in detail, it does not serve any purpose. Besides, such assessment
also does not belong to a "problem statement" document.

Alper> And while we are at that, please let us know the details of your
assessment. What protocols are those?

Please consider that the PS doc was widely discussed in Prague and agreed by
all parties. 

Alper> Then we should have skipped the WG LC :-) 

Alper

regards,
telemaco

Alper Yegin wrote: 

Alper

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Thursday, May 10, 2007 12:12 AM
To: [email-masked]
Subject: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt

Hello,

Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 09, 2007 12:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Mipshop] I-D ACTION:draft-ietf-mipshop-mis-ps-01.txt

There are on-going activities in the networking community to develop
   solutions that aid in IP handover mechanisms between heterogeneous
   wired and wireless access systems including, but not
limited to, IEEE
   802.21.  Intelligent access selection, taking into account
link layer
   attributes, requires the delivery of a variety of different
   information types to the terminal from different sources within the
   network and vice-versa.  The protocol requirements for this
   signalling have both transport and security issues that must be
   considered.  The signalling must not be constrained to
specific link
   types, so there is at least a common component to the signalling
   problem which is within the scope of the IETF.  This draft
presents a
   problem statement for this core problem.

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in
the body of
the message.
You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Send a message to:
	[email-masked].
In the body type:

	a MIME-compliant mail reader.  Different MIME-compliant
mail readers

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 16 May 2007 16:00:56 +0200

Alper,

I think we can summarize your concerns as follow:

+ Issue on the extra given context information
Probably there will never be an answer making everyone happy, but there 
is no point in keeping changing the scope again and again.
We believe the extra given context has been revised in way to provide 
the minimum amount of info required to better understand the document.

+ Issue on the scope of the ID beyond what's being defined in .21.
We discussed this several times and the feeling was to have a doc 
general enough while not conflicting with .21 requirements
(this is why .21 folks reviewed the ID). In other words, we are trying 
to solve the .21 problem but without doing it in a way
which hardcodes unnecessary assumptions.

+ Issue on the statement "goal is to reuse/adapt, where possible, 
existing solutions."
We can update the sentence to reflect your comments.
You should expect an analysis of existing solutions as part of the DT 
output.

Comments are welcome.

regards,
telemaco

Alper Yegin wrote:
> agreed by

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 17 May 2007 00:12:35 +0900

As I also mentioned several times before, I did recommend you and
MIPSHOP to take the original approach of MIPSHOP charter in terms of
802.21 stuff into consideration. BUT, still it seems really wide
spreaded. not good at least to me...:-(

http://www1.ietf.org/mail-archive/web/mipshop/current/msg02879.html

-- Daniel Park

On 5/16/07, Telemaco Melia <[email-masked]> wrote:
> Probably there will never be an answer making everyone happy, but there is
> no point in keeping changing the scope again and again.
> We believe the extra given context has been revised in way to provide the
> minimum amount of info required to better understand the document.
>
> We discussed this several times and the feeling was to have a doc general
> enough while not conflicting with .21 requirements
> (this is why .21 folks reviewed the ID). In other words, we are trying to
> solve the .21 problem but without doing it in a way
> + Issue on the statement "goal is to reuse/adapt, where possible, existing
> solutions."

---

From: Telemaco Melia <[email-masked]>
Date: Fri, 25 May 2007 12:17:08 +0200

Daniel,

If we modify the Introduction to include the following text:

"The initial requirement for this protocol comes from the need to 
provide a transport for the MIH protocol being defined by IEEE 802.21
(specifically the IS/ES/CS components) which is not bound to any 
specific link layer and can operate over more that one network-layer
hop. The solution should be flexible to accommodate evolution in the
MIH standard, and should also be applicable for other new mobility 
signalling protocols which have similar message patterns and discovery
and transport requirements."

and explicitly mention IS,CS,ES in the definition of MoS, would that address your doubts?

cheers,
telemaco

Daniel Park wrote:
>> the
>> general
>> existing
>> this
>> was
>> for