Subject: [Ecrit] Minor comment on phonebcp

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Dec 2007 15:29:34 -0500

In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other things)

"
    9.   If a device understands the SIP location conveyance
         [I-D.ietf-sip-location-conveyance] extension and has its
         location available, it MUST include location either by-value or
         by-reference.
"

It seems like this requirement should be stronger.  In particular, if an 
endpoint has an LbyR, it's likely to point to a more timely location 
than an LbyV that it has (ignoring Henning's classification of LbyR for 
the moment).  Should it be MUST include LbyR if you have it?

--Richard

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 17 Dec 2007 15:35:30 -0500

If you have both, send both.  If you have one, send what you have.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, December 17, 2007 3:30 PM
> To: ECRIT; Brian Rosen
> Subject: Minor comment on phonebcp
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Dec 2007 15:41:15 -0500

Right.  That's what we mean, but not what the document says.  How about 
if we change it to "... it MUST include location by-value or 
by-reference, or in both forms if both are available."

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Dec 2007 13:25:00 -0600

At 02:41 PM 12/17/2007, Richard Barnes wrote:
>Right.  That's what we mean, but not what the document says.  How 
>about if we change it to "... it MUST include location by-value or 

well, I disagree here

for one, since including *both* could be pointing to TWO (different) locations

Let's not instantly create a situation of confusion by all Location 
Recipients by making it have to decide which location is better, ok?

Deciding that LbyR is more up-to-date than LbyV is a function of a 
local network, not for an international standard to decide.

The text, as written, makes providing either (LbyR or LbyV) location 
mandatory, and leaves which to those local policies and 
configurations - where they belong.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Dec 2007 15:48:37 -0600

Matt

in-line

At 02:26 PM 12/18/2007, Matt Lepinski wrote:
>James,
>
>I agree that there may be cases where a device ends up with both 
>LbyV and LbyR and the LbyV is more useful/up-to-date than the LbyR.
>
>However, there is certainly a common use-case where a mobile device

how isn't mobile devices "a local network decision" (from my message below)?

BTW - what if LbyR is mandatory and the UA has a GPS with the most 
precise location information? Isn't this defeating the purpose of 
what you want (i.e., the most up-to-date and precise location information)?

>obtains an LbyV for use in call-routing and an LbyR which can be 
>used to obtain more update location information (within some window 
>of time). In this case where the LbyV is used for routing and the 
>LbyR is able to provide more up-to-date location as the target moves,

SIP Conveyance has the UA sending an UPDATE every time it moves, so 
this case isn't ignore.

>I think we agree that the endpoint should include both locations in 
>the SIP INVITE (marking the LbyV with the "used-for-routing" parameter).

no, I said I don't agree with this, and I gave a reason previously - 
which is a valid one (confusing situation for a Location Recipient)

>Currently, it is unclear from the text that when a mobile device has 
>both LbyV and LbyR that it should often include both locations. It 
>would be nice if this were clarified.

I think sending both creates confusion more often than it won't, 
since there will likely be two different Sighters, with different 
measuring techniques

>If there are important cases where a device has both LbyV and LbyR, 
>but should only include one or the other, then instead of "MUST 
>include both when both are available", we can instead use 
>"SHOULD"-strength text with an explanation of when sending both is 
>appropriate and when sending only one is appropriate.

The text currently says "MUST send Location", it doesn't say which, 
and it shouldn't in the protocol spec.  Local policy can always 
specify (or extend) which one to send or both, knowing Recipients 
know what to do if they receive two or more locations - but right 
now, we don't tell a Recipient what to do if receiving both types, 
nor do we state which is more trustworthy.  For example, in an 
IP-cellular environment, 3GPP is more appropriate to specify that the 
LbyR from a server is more trustworthy - than an IETF doc that 
shouldn't make that underlying network type distinction.

James

>- Matt Lepinski
>James M. Polk wrote:
>>The text, as written, makes providing either (LbyR or LbyV) 
>>location mandatory, and leaves which to those local policies and

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Dec 2007 19:07:02 -0500

I disagree.

It's always better to send both the LbyR and an LbyV if you have them and
its possible that you are mobile.  If you are not mobile, it wastes bits and
bandwidth, but does no harm.

It avoids needing to dereference to route, and yet gives you the ability to
get location updates when you can get them.

The LbyV, if it's "fresh" is going to be as good as it gets for all the
routing decisions, because they happen fast.  Avoiding the dereference at
every routing step is a good thing.

If you mark the LbyV as used for routing, it's crystal clear what you are
doing: supplying an "I'm here now as best as anyone can tell" and a "check
this for more information later".  I really want that.

I think the answer to phonebcp is "send what you got, mark one
used-for-routing".  It's always right for emergency calls.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2007 4:49 PM
> To: Matt Lepinski
> Cc: Richard Barnes; Brian Rosen; 'ECRIT'
> Subject: Re: [Ecrit] Re: Minor comment on phonebcp
> 
> Matt
> 
> in-line
>