Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture)

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Sep 2005 01:24:31 -0500

You use the word "seems", which is appropriate because DHCP isn't universally applicable.  We need more widely applicable solutions.

Efficiency isn't the only consideration here - the mobile case still provides a problem.  Anyhow, talking of efficiency gets very close to similar arguments already exhausted in GEOPRIV about application layer location acquisition; GEOPRIV decided that application layer has it's place.

Of course, I agree that SIP routing can take care of a large amount of those cases.

Just to prevent any misconceptions, call transfer is not absolutely necessary for VPNs if the endpoint retrieves location information before committing to a VPN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Wednesday, 21 September 2005 3:25 PM
To: Brian Rosen
Cc: ECRIT
Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture)

DNS, IRIS and LUMP are useless without location of the UA. Location seems 
to be coming from DHCP. In that *very*same* DHCP response IP packet can be 
the PSAP URI. that seems pretty efficient to me.  The lease mechanism can 
be used to provide a fairly fresh URI in the phones. SIP Routing can take 
care of reroutes due to:
         1- time of day routing changes
         2- overloads (by pushing the overload state to the Proxies)
         3- jurisdictional changes
         4- etc...
and
Call transfer:
         - whether before the operator answers the call
                 - because the local PSAP Proxy recognized the
                 INVITE from intended for another PSAP, or
         - when the operator asks the user where they are

will handle the rest of the cases.

We already need the call transfer procedure in place for VPNs.

For i3, the PSAP will have an ESRP for message inspection. This can do the 
message rerouting if necessary, and the PSAP administrators can control 
when that occus for the above 3 listed reasons (plus a few others)

At 06:09 PM 9/20/2005 -0400, Brian Rosen wrote:
>If we select my dns proposal, or lump or iris, every routing element can 
>implement it, without exception.  If we use dhcp, only environments that 
>support dhcp can use it.
>
>The other location protocol is lldp-med, and the proposed third is HELD.
>
>We certainly can have exactly one mapping protocol, and I think we 
>should.  It does not bother me that phones don't do iris or lump, and even 
>if they have ds support, they don't ecrit mapping.  Its new code.
>The difference is that dhcp requires local support, and that's not 
>available everywhere. Dns and lump and iris don't need local support.

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Sep 2005 16:45:34 -0500

At 01:24 AM 9/21/2005 -0500, Thomson, Martin wrote:
>You use the word "seems", which is appropriate because DHCP isn't 
>universally applicable.

I said the latter too!

>We need more widely applicable solutions.

one size fits all is a great dream, but no one here has come up with one in 
the 2+ years we've been at this, so how much longer do we wait?

>Efficiency isn't the only consideration here - the mobile case still 
>provides a problem.

3GPP *WILL*NOT*ALLOW the UA to know its own location, so that concept MUST 
be dropped from all our models and diagrams - then where are we at?

>Anyhow, talking of efficiency gets very close to similar arguments already 
>exhausted in GEOPRIV about application layer location acquisition; GEOPRIV 
>decided that application layer has it's place.
>
>Just to prevent any misconceptions, call transfer is not absolutely 
>necessary for VPNs if the endpoint retrieves location information before 
>committing to a VPN.

Just as I said "seems", you say "if" - and I think that is a big IF to rely on.

cheers,
James

                                 *******************

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Sep 2005 17:03:45 -0500

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 22 September 2005 7:46 AM
> To: Thomson, Martin; Brian Rosen
> Cc: ECRIT
> Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture)
> 

Those 2+ years weren't wasted (I hope) - we now have requirements almost finished, which can provide input to the design of an appropriate LCMS protocol.

> be dropped from all our models and diagrams - then where are we at?

I wonder about your statement about 3GPP - I don't want to sound contrary, but I have here a copy of TS 23.271, which includes a sizable section entitled "9.2 Mobile Originating Location Request", which seems to contradict your statement.  Where did you get this information?

The other thing is, I am not talking about 3GPP wireless specifically, I was referring to the general wireless case, which includes a large number of technologies (WiFi and WiMax for instance).

> Just as I said "seems", you say "if" - and I think that is a big IF to
 
My opinion differs, I don't think that this "if" is unreasonable - that is not to say that call transfer is pointless, misrouting is still going to occur, but that this is the model that we want to work towards.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Sep 2005 11:07:45 -0500

At 05:03 PM 9/21/2005 -0500, Thomson, Martin wrote:
>Those 2+ years weren't wasted (I hope) -

I didn't say it was a waste. I think people often get so focused on a 
particular aspect that they lose sight of other angles and pieces of the 
puzzle.

Take the statement: ' if one protocol cannot cover 100% of the cases, it 
shouldn't be considered for any of them'.

This DHCP idea is in essence for when the Location is provided by the same 
server.  This DHCP idea is NOT all about PSAP URIs, as there are several 
URIs defined that have little to do with PSAPs, yet folks on this list (who 
are not taking this same argument to the DHC list themselves) are focusing 
on purpose=1 (PSAP URI). One other person discussed purpose=4 (ESRP URI) & 
=5 (ESGW URI). But that's the end of the comments, other than this whole 
DHCP idea is bad.

This idea is the only one proposing getting the organization who provided 
location to the client/UA in order to include it in the PIDF-LO. No one 
else has done anything to resolve that one - yet that was a BIG deal last 
year as to why the DHCP provided location was a BAD idea.

This discussion makes me think folks only want to talk about what's bad 
about someone else's idea, or it's just me they like to pick on  ;-)

>we now have requirements almost finished, which can provide input to the 
>design of an appropriate LCMS protocol.
>
> >
>I wonder about your statement about 3GPP - I don't want to sound contrary, 
>but I have here a copy of TS 23.271, which includes a sizable section 
>entitled "9.2 Mobile Originating Location Request", which seems to 
>contradict your statement.  Where did you get this information?

I'm the author of SIP Location Conveyance doc, and I was appraoched about 
modifying that IETF doc to suit 3GPP's requirements.

>The other thing is, I am not talking about 3GPP wireless specifically, I 
>was referring to the general wireless case, which includes a large number 
>of technologies (WiFi and WiMax for instance).

I do not believe the 802.11 case is that much of a problem from a routing 
to the right PSAP pov. WiMax is another issue.

> > >Of course, I agree that SIP routing can take care of a large amount of

you seem to be the first to acknowledge this - I give you kudos

>My opinion differs, I don't think that this "if" is unreasonable - that is 
>not to say that call transfer is pointless, misrouting is still going to 
>occur, but that this is the model that we want to work towards.

cheers,
James

                                 *******************

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 22 Sep 2005 17:22:19 -0500

Hi James,

Inline...

> Sent: Friday, 23 September 2005 2:08 AM
> To: Thomson, Martin
> Cc: ECRIT

Too true; perhaps the problem is exacerbated by differing perspectives as well.  I don't think that anything but healthy discussion will solve that particular problem.

> shouldn't be considered for any of them'.

I'm inclined to agree with you, but I think that the arguments are usually less black & white than that particular one.  How about 'if one protocol can cover 100% of the cases, why bother with any others?'

> year as to why the DHCP provided location was a BAD idea.

I'm not sure what you are talking about - your first sentence doesn't parse.  But, if you refer to DHCP providing location information, then I'd suggest you are wrong.  HELD goes one step further and provides a PIDF-LO.

> about someone else's idea, or it's just me they like to pick on  ;-)

But talking down other people's ideas is fun ;)  It's so much harder to be constructive, that takes time and effort.

Seriously though, I generally like the idea of having a means to provide configuration URIs through DHCP.  I have already raised my other concerns - which did not include saying that purpose=1 was bad, only that I would do it another way.

> modifying that IETF doc to suit 3GPP's requirements.

You seem to have completely contradictory information to what is in published 3GPP standards.  Which requirements do you refer to specifically?

> to the right PSAP pov. WiMax is another issue