Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision

From: George Tsirtsis <[email-masked]>
Date: Tue, 22 Jan 2002 06:46:58 -0500

Well, the chairs asked who is planning to implement a possible
standard in the area in a product any time soon...I did not see many
hands going up...in fact I did not see any.

My main point, however, was that I do not see how any process will
allow you to go forward given the current climate. Anyway, I have no
intention or power to stop you so good luck.

Regards
George

- -----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 11:38 AM
To: George Tsirtsis; [email-masked]
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision

George,

If there is no need, there would not have been 5 proposals and that
kind of 
discussion, because nobody would care about the outcome.

Marcus

- --On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis 
<[email-masked]> wrote:

>
> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Monday, January 21, 2002 11:04 PM
> To: Pat R. Calhoun
> Cc: [email-masked]
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision 
>
> ...
> - Completely dropping this work item, is this an option?
>
> GT> I will risk the following opinion since I have been following
> this discussion for some time: I like the option above. Given the
> level of resentment between people in this sub-group I can not see
> how this work will be successful no matter what the process is. Any
> processes is flawed unless people want to work with it.
>
> Do not despair, the work item will reincarnate it self when there
> is actual need for it.
>
> George
>
>
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

- --------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 22 Jan 2002 13:56:47 -0800

All,

> hands going up...in fact I did not see any.

At this stage, what would be the risks in products? Would there
not be some research prototypes first when the protocol starts
to show signs of consolidation?

> intention or power to stop you so good luck.

I am more optimistic. If grievances for process and participation
are aired openly now, and everybody's concerns are addressed while
all understanding that their proposal (mostly) alone will not make it,
this could also bring together a coauthoring design team willing to
defend a common text, a compromise, yes, but adopted by all.

As a side note, I appreciate Marco's comments on being open
and have no objections seeing him edit the text. If all have
the urge to go forward, it is a matter of definition, whether we
"officially" go from draft-renker, or from an empty proposal. With
the knowledge that it will anyway take big chuncks from draft-
renker as well as from other drafts, some signs of willingness to
compromise from certain parties (wink, wink) might move things
ahead.. With Marco's comment and wg chairs' recommendations in
mind, it will anyway be a puzzle with discussions how to put the
pieces together.

> George

BR,

-Jari

> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> 
> iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9faHRE5dkkkAoONF
> diXAng3tmaaDh/t5qiv1tO7W
> =MXnq
> -----END PGP SIGNATURE-----
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 Jan 2002 17:46:16 -0600

Dear All,
  This is a mail on TECHNICAL issues. It may refer to the procedural 
issues when relevant
I looked at the drafts first time seriously!
First of all from size perspective: draft-renker 59 pages
draft-ohba 52 pages
draft-koodli 31 pages
draft-sarikaya 22 pages
draft-guri 16 pages.
  Combining all these would give a document of 180 pages of extreme 
complexity and confusion. So I agree with Jari, attaching text from 
different proposals written with different background is simply NOT 
going to work.
  Now, draft-renker starts with a very simple architecture: of
PA -- AR -- MN
using only PA entity of the requirements document. The rest of 
draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya is 
also based on Mobile IPv6 and so these two drafts should have been 
treated in a similar way. What do you say Srinivas? i.e most possibly 
refuse both.
  Next draft-ohba,  it has DMA, PA and TA of the requirements draft. The 
basic architecture has the DMA on the link which is I think an 
architectural problem and uses only TA. Remember this draft is called 
Last Hop DMHA Protocol. Next, draft-ohba tries to handle host mobility 
and there draft-ohba introduces PA. There is a long list of the states 
maintained in each entity which takes several pages. There is also a 
description of an 802.11 implementation in the annex.
  Next draft-koodli, it has PF entity which probably stands for DMA, TA 
and PA which is in charge of paging and the ARs on subnets with MNs. The 
mobility is handled by the L2 and L3 paging areas but only textual 
description. From p.10 onwards it covers security and from p.15 onwards 
it covers mapping to MIPv6, regional registration and TO HMIPv6.
  However, draft-sarikaya completely integrates paging to MIPv6 and 
HMIPv6 (as such it is not the only draft that covers HMIPv6).
  Draft-guri is completely on the architectural entities of the 
requirements draft. It uses DMA, PA and TA. It defines a model for L2 
and L3 paging areas. It is a complete IP paging protocol independent of MIP.

  Can someone tell me how can we integrate these drafts by giving some 
text to Marco? Do you think that I am rigid and non conciliatory Jari?

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: [email-masked]
Phone: (972) 477 2794 Fax: (972) 519 2460

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 22 Jan 2002 18:49:44 -0800

Behcet,

If we are in a hurry, the complexity will be mind-boggling.
A construction may be a possibility, maybe I'm optimistic,
using the material as a set of design elements (build a framework
based on components in the proposals)..

> also based on Mobile IPv6 and so these two drafts should have been treated
> in a similar way. What do you say Srinivas? i.e most possibly refuse both.

A first observation is that there is an architecture each
proposal presents. Some try to follow that outlined in the RFC, some
go with a simpler model. The first question is: do we go with the
good preliminary work of James et al in choosing the architecture or
can we agree on a simpler model which was a hint given by wg chairs'
recommendation etc. Maybe that's a first decision to do. Also,
having some sense of understanding of requirement priority could
help. Chairs have stated their preference, maybe these should be
checked in the discussion..

Whenever a choice is made, that material in most drafts can be skipped.
By construction maybe a simpler / shorter text could be possible.
Even though not bad, genericity in draft-renker was problematic
to me, a design should rather economically communicate an unambiguous
design without going to surveys etc. By construction that might be
more likely than patching a large framework, perhaps.

Sure it is not going to be easy, probably impossible. That is not
sure yet, though. Maybe Marco could try to build towards a more
short/readable a framework this way, reflecting issues discussed,
I don't know?

> architectural problem and uses only TA. Remember this draft is called Last
> Hop DMHA Protocol. Next, draft-ohba tries to handle host mobility and
> there draft-ohba introduces PA. There is a long list of the states 
> description. From p.10 onwards it covers security and from p.15 onwards it > covers mapping to MIPv6, regional registration and TO HMIPv6.
>   However, draft-sarikaya completely integrates paging to MIPv6 and HMIPv6
> (as such it is not the only draft that covers HMIPv6).
> requirements draft. It uses DMA, PA and TA. It defines a model for L2 and
> L3 paging areas. It is a complete IP paging protocol independent of MIP.

To some degree, appendix implementation description and integration with
other protocols may be something to omit first..

> text to Marco? Do you think that I am rigid and non conciliatory Jari?

Almost quoting my M-X doctor: Does it bother you that you think
I think you are rigid and non conciliatory? :) No I do not, really..

BR,

-Jari

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 23 Jan 2002 17:48:01 +0100

Jari,

thanks for your constructive comments. The way you propose on
how to proceed leads into a right direction, which is first to clarify
how to map the functional elements to the architecture.
That's why I sent an e-mail to the list, referring to the architecture
as it is described in draft-renker and taking it over to the very first
cut of the WG draft. As already said, optimization parts as well
as specifics on paging policies are a candidate to not be part of the
generic architecture and protocol description. Coming up with a
framework and a first cut of a WG draft would require to extract specific
information and to form the generic parts into a clear order for the framework.
That's what I can do. For the architecture, the WG should express an opinion,
but maybe we should address this better in a separate thread again.

Regards,

Marco

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Jan 2002 09:39:18 -0800

Jari,

> based on components in the proposals)..

Actually, I don't think we are in a hurry. As the response to
the survey I sent out indicated, nobody is doing product
in this area in the near future, so we have some time to
get this right. 

Counting pages and figuring out how to do a merge on
the existing specs isn't the right way to go, IMHO. 
We want a design that will last, like Internet routing
has, and fit properly into the Internet architecture,
since paging will be a key component of the future
all-IP wireless networks.  This is naturally going to require 
some time. 

I still believe that draft-renker is a good starting
point for the design. It is easier to find the faults
in something that exists and fix them than try
to start from scratch. But if the working group isn't 
happy with using draft-renker as the base, then Allison, 
Pat and I need to figure out a way to go forward that 
will result in a good technical solution. We have some ideas, 
but the question in my mind right now is: is the WG
interested in getting the right technical solution?

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 23 Jan 2002 11:56:53 -0600

Dear All,
  Let me say that, probably to everybody's surprise, I completely concur 
with James's view. There is no rush and IP paging will be an important 
component in future wireless networks.
So let's not go for a cheap solution.

  Regards,

-- 
Behcet

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 23 Jan 2002 16:41:17 -0800

All,

Also agreed, except that a construction is a better way than
starting from draft-renker.

BR,

-Jari

Behcet Sarikaya wrote:
> 
> Dear All,
>   Let me say that, probably to everybody's surprise, I completely concur with James's view. There is no rush and IP paging will be an important component in future wireless networks.