Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging

From: "Hesham Soliman \(ERA\)" <[email-masked]>
Date: Mon, 9 Apr 2001 00:08:46 +0200

Pat, 

Sorry for the short disobedience to your recommendtion to kill
the thread. But for the record, I think Alessio is making a lot 
of sense. Others also raised similar issues in Minneapolis. 

Regards,
Hesham

> -----Original Message-----
> From:	Patrice Calhoun [SMTP:[email-masked]]
> Sent:	Saturday, 7 April 2001 12:41
> To:	Casati, Alessio (Alessio)
> Cc:	Seamoby (E-mail)
> Subject:	Re: [seamoby] Response of Mobile Operator to Request for Info on  Re alistic Paging
> 
> I have been trying to sit by the sidelines, and allow everyone to express
> their opinion, but it is apparent to me that there is no possible compromise
> here. Alessio is insistent that this is useless, and others do not think so.
> They find this work useful, and have stated their opinions as well.
> 
> So, in the spirit of cooperation, perhaps we can put this thread aside, and
> start working on the requirements.
> 
> Please kill this thread. If the market does in fact not find this work useful,
> then like many other things from the IETF, it will not have much deployment.
> 
> As for HLR/VLR, I know that there is significant work going on to eliminate
> them in *some* of the SDOs. Again, whether or not carriers will use the new
> standards is nothing more than a guess any one of us could do.
> 
> So, let's get to work!
> 
> PatC
> 
> > 
> > 
> > 	Your opinion is not shared by either the working group chair 
> > 	nor by the AD.
> > 	When the AD reports back to us, we will see whether it is shared by
> > the
> > 	IESG. We are not talking about GPRS nor 3GPP2, we are talking
> > 	about a future network where there is no HLR or VLR.
> > 
> > So, this should be written in the problem statement.
> > However this does not change the validity of
> > what I wrote. By the way there are
> > a few operators out there that are happy to use HLR
> > and VLR. Those concepts I wrote will remain valid, although technology
> > and naming of for the same functionality will evolve. So, something 
> > meaningless today (such as a wireless net without HLR and VLR 
> > functionality,
> > will be meaningless in the future). Need of L3 paging is 
> > meaningless today
> > as it will be tomorrow (unless what you are doing is what the GTP
> > PDU notification does today, in which case you are doing really nothing
> > new, since this was done years ago in ETSI - if you are doing that
> > then I can point you to where you could look this up not to 
> > reinvent the wheel
> > too much)
> > 
> > 	My observation is that you keep bringing up the same points, 
> > 	which I keep
> > 	answering. To that extent, Mike's comment that you seem to be
> > disruptive
> > 	is appropriate.
> > 
> > The same points are brought insofar as no response is given to
> > them. I wonder why I get no answer other than " we work by 
> > rough consensus".
> > It is depressing :).
> > 
> > 
> > alessio
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Sun, 8 Apr 2001 23:29:41 -0400

> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Sunday, April 08, 2001 6:09 PM
> To: 'Patrice Calhoun'; Casati, Alessio (Alessio)
> Cc: Seamoby (E-mail)
> Subject: RE: [seamoby] Response of Mobile Operator to Request for Info
> on Re alistic Paging
> 
> 
> Pat, 
> 

I agree.  Some of the points that have been raised are valid ones.

- why can't this annonyous operator speak?  Why can't the operator be more
specific in requirements?
- A paging protocol is more about enabling paging optimized vs routing
optimized networks.
- Low power design is better handled in hardware, than a new protocol for
routing optimized networks.
- 3GPP2,3GPP do not need an IP paging protocol.
- If 3GPP2 does not need a paging protocol then it is inappropriate for
anyone to state: "MIP needs IP paging"

Is the IP Paging protocol really about "some network in the future", or
about paging in a city wide network infrastructure composed of
AMPS,GSM,PCS,3GPP, and 3GPP2?

If so, then the only real requirements that I can see are: 

- timeliness of the incoming phone call 
(i.e. send call out on all network types at the same time: IP Multi-cast).
- Legacy compabitility.

- Kulwinder.

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 11 Apr 2001 09:22:28 -0700

Sorry, I think I was a little harsh with my use of "bashing thread". I understand
that he wasn't "bashing" the work, but trying to make his position known, and
what I was really trying to state was that we understood his position, so it was
time to move on.

(it'll teach me better to write e-mails when in a different time zone while my
internal clock still thinks it's middle of the night)

PatC
>Then it is up to these people to either state:
>
>1. proposed changes to the problem statement
>2. Claim that this is not a problem to be solved, or
>3. point to specific text that needs to be clarified
>
>What I don't want is simple e-mails that bash the work without any
>justification.
>Alessio tried to kill it and failed, because he was alone, and concensus rules.
>I don't have issues if other people want to do one of the above, but I wanted
>to kill Alessio's bashing thread because his position was well known.
>
>PatC
> 
>>Pat, 
>>
>>> Subject:	Re: [seamoby] Response of Mobile Operator to Request for Info on 
>Re
>>alistic Paging
>>>

---

From: "Casati, Alessio \(Alessio\)" <[email-masked]>
Date: Wed, 11 Apr 2001 14:57:52 +0100

*
*
*Sorry, I think I was a little harsh with my use of "bashing 
*thread". I understand
*that he wasn't "bashing" the work, but trying to make his 
*position known, and
*what I was really trying to state was that we understood his 
*position, so it was
*time to move on.
*
*(it'll teach me better to write e-mails when in a different 
*time zone while my
*internal clock still thinks it's middle of the night)
*

You should not send IP packets while you are dormant ;).

alessio

---

From: "Casati, Alessio \(Alessio\)" <[email-masked]>
Date: Wed, 11 Apr 2001 14:54:24 +0100

*Then it is up to these people to either state:
*
*1. proposed changes to the problem statement
*2. Claim that this is not a problem to be solved, or
*3. point to specific text that needs to be clarified
*
*What I don't want is simple e-mails that bash the work without 
*any justification.
*Alessio tried to kill it and failed, because he was alone, and 
*concensus rules. 

My attempt was not to kill it (I'm not in the draft murder business as yet).
I also don't think I was alone (at least 3 people on the list show
some agreement on my position). I think I'm the only one that persisted
in pointing out some weak technical foundations upon which the work is
based.
I also believed I indicated parts of the probelem statement that need
fixing, and parts that are (sorry for crude statement) bogus.

I understand the only answers were escaping via the 
well Known IETF rule of rough consensus. But the only endorsement we have so
far
is the author's and the anonymous' (Based on his presumed (?)
and not justified operational aspects - rather than answers to my technical
comments).

I also don't want to interfere with the rest of the paging work, since, who
knows,
it may be that something useful could come out from the brain trust working
at it. If not, we'll just add this work to the pile of the failures in
research history, as Pat stated.

*I don't have issues if other people want to do one of the 
*above, but I wanted
*to kill Alessio's bashing thread because his position was well known.

Yet unanswered...

But, Till some not correct messages like the one you sent now
will show up (or till the discussion on the problem statement
can continue on a technical basis) I'll go dormant. 
Perhaps I'm experimenting L8 paging...

PS.
By the way, a reminder for the AD: you promised you would have reported on
the
IESG telechat. How did it go? Can you summarize what the discussion on this
was
(if at all it was discussed). It is interesting to have a statement from the
IESG 
on this.

peace
alessio

---

From: "Casati, Alessio \(Alessio\)" <[email-masked]>
Date: Wed, 11 Apr 2001 16:26:16 +0100

*
*
**Then it is up to these people to either state:
**
**1. proposed changes to the problem statement
**2. Claim that this is not a problem to be solved, or
**3. point to specific text that needs to be clarified
**

by the way, I think the attached e-mail contradicts 
your previous message.

alessio

Subject: Re: [seamoby-paging] Paging Requirements Draft and Teleconference
From: Patrice Calhoun <[email-masked]>
To: James Kempf <[email-masked]>, [email-masked]
Date: Wed, 11 Apr 2001 17:27:12 +0100

>1) If you don't believe there is a problem to be solved for paging,
>please go to the IESG and talk to them. 
Or me, and I will concatenate the comments and bring them to the IESG.

> If you don't believe paging
>applies to your favorite radio protocol, please don't bother to
>show up at the teleconference. 

But do write me e-mail so I can understand your position.

So far I have been collecting comments from people that do not believe this
works is needed.

PatC

---

From: [email-masked]
Date: Thu, 12 Apr 2001 14:21:50 +0300

Hi Phil,

> Ok then, allow me to play devil's advocate.  Its done.  Why not use
> TCP, UDP, or SCTP depending on your application and transport
> lumps of Type, Length, Value (TLV) fields (and just for giggles give
> the user a choice of parseable ASCII (Unicode) or binary.  Q.E.D.
> End of CT work, we can all go home?  Is this all there is it to it?

If we are having a protocol running on top of a transport protocol,
we need to define the blobs.  I think that we may want to define 
different modes (proactive transfer, reactive trasfer); error 
messages & error situations, ability to 'broadcast' the blobs (to 
more than one AR); security requirements.

Some questions:
	o Will we ever have to do a hop-by-hop operation?
	o Do we want to build some inteligence into the system, 
	some sort of discovery protocol?
	o Should we define some sort of extensibility mechanism?
	o How to handle situations when one node only understands
	one type of QoS (for example) but the destination node
	only understands another type?

Lots more as well.
John