Subject: [MIPSHOP-MIH-DT] [Fwd: Re: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt]

From: Telemaco Melia <[email-masked]>
Date: Wed, 16 May 2007 11:38:29 +0200

Hi all,

I would like to poll the DT attention on the comments Alper did to the 
PS doc and reach a consensus before replying.
Issue on the extra given context information: I would leave it in the 
document. Opinions?
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). Is this still the view of our work?
Issue on the statement "goal is to reuse/adapt, where possible, existing 
solutions." We can update the doc however it is true that
we need an analysis of existing solutions (we need to list them) against 
the requirements we identified. I could start to work on this
if required.

Please let me know your opinions. I really would like to push the work 
forward.

cheers,
telemaco

-- 

Subject: RE: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt
From: "Alper Yegin" <[email-masked]>
To: "'Telemaco Melia'" <[email-masked]>
Cc: "'Vijay Devarapalli'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Stefano Faccin'" <[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,

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).

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
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?

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

We hope the above explanation address your concerns.

regards,
telemaco

Alper Yegin wrote: 
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

-----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,

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

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

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

-- 
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 

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 16 May 2007 13:52:17 +0100

hi telemaco,

my views in line. i would suggest that you respond fairly
fast and then the rest of us can add our views. there is
no harm in having the discussion on the mipshop list
(especially given some of the comments in prague).

r. 

> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: 16 May 2007 10:38
> To: [email-masked]
> Subject: [MIPSHOP-MIH-DT] [Fwd: Re: 
> [Mipshop]draft-ietf-mipshop-mis-ps-01.txt]
> 
> Hi all,
> 

i would keep it. there is no answer that will satisfy everyone
but no point in keeping changing the scope again and again.

> .21 folks reviewed the ID). Is this still the view of our work?

it is still mine. we are trying to solve the .21 problem but 
without doing it in a way which hardcodes unnecesary assumptions.
(really, this is just good engineering practice). 

> the requirements we identified. I could start to work on this

i don't see this as part of the PS document. this sort of work
can be never ending. (we should certainly be thinking about it 
in the DT "activities" but no need to hold the PS on it).

r.

---

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

Done.
Just a side comment: I meant to do the analysis as part of the DT work.

tele

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