Subject: RE: [Mipshop] RE: Concerning mobility services transport PS

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 15 Sep 2006 15:48:54 -0400

Hi James,

I agree with you and others who have commented that the PS in its
current form is too long and complicated.  I like your suggestion and
also the suggestion from Behcet on possible ways to re-write the PS.  

I just hope that this does not cause us to slip our milestones for MIH.
I really just don't understand why we are making everything related to
MIH so complicated in MIPSHOP.

Akbar

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 2:11 PM
To: Hancock, Robert; [email-masked]
Subject: Re: [Mipshop] RE: Concerning mobility services transport PS

Robert,

The problem is there is too much material in this document that has
nothing 
to do with a simple problem statement. Problem statement documents are 
typically short, rarely over 10 pages. This one runs to 40 pages. That's
as 
much as a detailed protocol spec.

If you want to publish this document, then make it an architectural and 
requirements/goals document. If you want to do a problem statement, then

come up with a 4-8 page document that focusses specifically on the
problem 
of running 802.21 signaling over IP transport.

            jak

----- Original Message ----- 
From: "Hancock, Robert" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 14, 2006 4:01 AM
Subject: RE: [Mipshop] RE: Concerning mobility services transport PS

james,

I'm not sure exactly what aspect of the draft your are
concerned about.

In terms of the main body of the document (the first 10
pages of content, say), it's true that it includes a description
of the framework within which a particular problem sits.
So it's not a problem statement for the overall medium
independent handover problem space; it's a problem statement
for how to transport signalling messages for such handovers.

To be specific, as I understand it, the WG is chartered
(in the near term) to work on precisely that subset of the
overall problem. As soon as one writes something that describes
a subset of a larger problem, it gets pretty hard to avoid
architectural aspects in the description. (As a point of
comparison, working out where to put the description of the
architecture within which netlmm sits has been similarly
problematic.)

Is this just a question of being clearer about the scope/goals
of the document?

In terms of the appendices, it's true that there is a fair
amount of .21-related material in there. But other appendices
are not .21-related. AFAIK the intention of the appendices
is to provide a stable reference point for the context within
which the solution is intended to be used; that's partly to
get some kind of organisational buy-in from .21, and partly
also to provide the same information to outsiders, since the
.21 documents are not publicly available (and the .21 requirements
document probably never will be). I don't see the appendices
as actually harmful.

cheers,

Robert H.

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: 13 September 2006 21:03
> To: Faccin, Stefano M; Telemaco Melia; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Mipshop] RE: Concerning mobility services transport PS
>
>
> I just started looking at this document, but it really
> doesn't seem to me to
> be a problem statement. It is more like an architecture
> document, combined
> with a description of 802.21's approach to a solution. I
> don't really get a
> sense of "what's the problem and why can't existing protocols
> handle it"?
> It's more like "mobile services provide this, here's an
> architecture for
> them, and here's what 802.21 is doing to implement that
> architecture". A
> real problem statement might be useful, but I question
> whether it is needed
> since 802.21 already seems to have decided there's a problem
> and they are
> working on the solution that conforms to a particular
> architecture, which
> this document describes. Perhaps confining the problem
> statement to "what
> problem exactly does 802.21 need solved by IETF" without all
> the additional
> material about 802.21 architecture, with reference to their
> documents where
> appropriate, would simplify the document. I don't think IETF
> really needs to
> duplicate 802.21 architecture and solution documents.
>
>             jak
>
>
> ----- Original Message ----- 
> From: "Faccin, Stefano M" <[email-masked]>
> To: "Telemaco Melia" <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, September 12, 2006 10:38 AM
> Subject: [Mipshop] RE: Concerning mobility services transport PS
>
>
> Dear MIPSHOPers,
> As discussed at the meeting in Montreal, we would like to get this
> document discussed, adopted and into a WG last call ASAP.
> Therefore, I'd
> like to solicit your input in the next two weeks. Based on
> the level and
> type of input, we will decide how to proceed.
> Thanks to the authors for getting together as requested to write a PS
> draft, and thanks in advance to all of you for helping in progressing
> this work.
>
> Stefano
>
> -----Original Message-----
> From: Telemaco Melia [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2006 10:26 AM
> To: [email-masked]
> Cc: Faccin, Stefano M; [email-masked]
> Subject: Concerning mobility services transport PS
>
> Hello,
>
> A new ID on mobility services and MIH related issues is available.
> As long as it is not announced on the mailing list you can find it at
> the following link:
> ftp://195.37.70.21/pub/internet-drafts/draft-melia-mipshop-mob
ility-serv
ices-ps-00.txt

regards,
telemaco

-- 

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

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

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

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

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

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Tue, 19 Sep 2006 16:27:29 +1000

Same concern here. While relooking at the MIPSHOP charter, it is
targeting to 802.21 space only. So, I don't think the approach in this
document as "not limited to IEEE 802.21" is acceptable...Please focuse
on 21 relevant problems. Analyzing pros and cons in each transport
layer suggested by Betcet seems also too much wide in the PS document,
rather describing those in a separated document as analysis or
something like that if necessary later. Now, let's focus on the
problem space to accelarate on this stuff in IETF.

My 0.2 cents.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 19 Sep 2006 18:25:43 +1000

Dear all,

I'm slightly confused by the direction of this discussion. We seem
to have
- some in favour of stripping out the .21 material and only keeping
the aspects specifically relevant to the IETF work
- some in favour of stripping out anything which isn't directly needed
for .21
- some in favour of sticking strictly to a high level problem statement
- some in favour of going into more detailed requirements and 
design space analysis

We already have individual documents that do these things; for example,
a high-level PS-only draft was presented in Vancouver. 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.

Although I'm not one of the authors, I'll happily take some of the
blame for the current document scope and structure. Actually, I still
think it is a reasonable way to satisfy the set of conflicting 
requirements. If you only want to see the minimal problem statement, 
ignore the appendices; if you only want to see the .21 stuff, ignore 
the appendices which are not about .21. It certainly reflects my 
understanding of what the authors were asked to do after the 
Montreal meeting ("Need a single PS at WG level; Chairs strongly 
suggest interested parties to work offline and produce common 
PS ..."). I guess we need some guidance on whether a common PS 
is expected to be the union or intersection of the various
strands of work.

cheers,

robert h.

> From: Soohong Daniel Park [mailto:[email-masked]] 
> Sent: 19 September 2006 16:27
> To: Rahman, Akbar
> Cc: [email-masked]; James Kempf

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Tue, 19 Sep 2006 18:56:10 +1000

Robert,

Here is a relevant sentence in the MIPSHOP charter:

===================
Additionally, the IEEE 802.21 Media Independent Handoff (MIH) working
group aims at providing services to assist with handoffs between
heterogeneous link-layer technologies, and across IP subnet
boundaries. The information exchanges defined by IEEE 802.21 are
classified as MI (Media Independent) Event Service (MIES), MI Command
Service (MICS), and MI Information Service (MIIS). The MIIS provides
topological and location-related information of service networks. The
MIES provides timely communications of wireless environment
information via the delivery of events originating across the
link-layer or farther away. The MICS is an analogous service for
commands which can change the state of the wireless link or of a
host's point of attachment, potentially triggering further event
generation. MIH services can be delivered through link-layer specific
solutions and/or through a "layer 3 or above" protocol. MIPSHOP will
define the delivery of information for MIH services for this latter
case. Notice that this allows the network information to reside
anywhere (not necessarily across the link-layer hop), and enables MIH
services even in the absence of the corresponding link-layer
support. An L2 or L3 based mechanism to identify a valid information
server is also required; in particular for L3, we expect that any of
the several current L3 discovery mechanisms will be used. A liaison
with IEEE 802.21 has been established, and access to the IEEE 802.21
drafts is granted to mipshop members. Interested members need to send
a request to the WG chairs in order to obtain a copy of the current
IEEE 802.21 draft.
===================

"MIPSHOP will define the delivery of information for MIH services for
this latter case. Obviously, MIH means IEEE 802.21 not *mobility
service*. No doubt. Anything else ?

-- 

<snip>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Sep 2006 09:14:50 -0700

I agree with Daniel. I think the problem statement must focus specifically 
on the problem defined in the paragaph he cited below from the charter, 
namely transport of 802.21 MIS between the MIS server and host. The current 
document could potentially be changed into an architectural document that 
describes the MIS architecture and how 802.21 protocol implements it, and 
where an IETF transport solution fits in.

            jak

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "Robert Hancock" <[email-masked]>
Cc: "Rahman, Akbar" <[email-masked]>; <[email-masked]>; 
"James Kempf" <[email-masked]>
Sent: Tuesday, September 19, 2006 1:56 AM
Subject: Re: [Mipshop] RE: Concerning mobility services transport PS

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Sep 2006 10:34:32 -0700 (PDT)

James, I guess you meant MIH not MIS?
Daniel: quote
Analyzing pros and cons in each transport
layer suggested by Betcet seems also too much wide in the PS document,
rather describing those in a separated document as analysis or
something like that if necessary later.
 
Well, there are many PS documents, the one I based my comment on was RFC 4093, it is structured as follows
-deployment scenarios for IP transport of MIH (could include the figures 1-5)
-problem statement could discuss IP transport problem and shortly cover proposals made so far including DHCP transport.
 
change the title and then remove all annexes.
 
My 2 cents.
 
--behcet

----- Original Message ----
From: James Kempf <[email-masked]>
To: Soohong Daniel Park <[email-masked]>; Robert Hancock <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, September 19, 2006 11:14:50 AM
Subject: Re: [Mipshop] RE: Concerning mobility services transport PS

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Sep 2006 13:43:53 -0700

"Mobile Independent Services" which covers command, information, and event. 
But I guess MIH would work as well.

            jak

----- Original Message ----- 
From: "Behcet Sarikaya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Soohong Daniel Park" 
<[email-masked]>; "Robert Hancock" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 10:34 AM
Subject: Re: [Mipshop] RE: Concerning mobility services transport PS

> -problem statement could discuss IP transport problem and shortly cover 
> proposals made so far including DHCP transport.
>