Subject: [Geopriv] LIS discovery direction

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 17:30:17 -0500

We are making excellent progress on this document considering that we only get to work on it for 2.5 hours every four months.

Before I crank out an -09 this afternoon, these are the changes that I will make:

 - Fingerprints are out entirely.

 - The U-NAPTR section 3.1 will now say, changes marked**:

   "If the device knows one or more domain names **that could be used as input to this process**, it MAY...

 - The overall section will no longer mandate (2119 MUST) use of DHCP over U-NAPTR.  Instead I propose the following addition to the first paragraph.

   "Methods of discovery that explicitly provide a LIS URI, such as the DHCP method described in section 2, are preferred over method that are based on any degree of inference."

After the update Richard and I will look to getting an updated security review.  I strongly suspect that our SECDIR reviewer will be OK with the change.

Cheers,
Martin

------------------------------------------------------------------------------------------------
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]

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 01:40:47 +0100

In today's GEOPRIV WG meeting there was a tentative agreement to provide a fix to RFC3825. 

Since non-broken parts do not usually need a fix, I believe the 'fix' has to be limited to the broken parts of the RFC. Since altitude type 2 (floors) does not have anything to do with the broken part of the RFC, that should not be deprecated.

Therefore, if rfc3825bis is going to be accepted as a way forward to fix RFC 3825, I'd like the wg version of it to be limited to only contain the necessary fixes for the RFC. 

- gabor

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 19:57:13 -0500

My response to this same question in the meeting was thus:

Floor is only locally significant within the constructed environment, therefore it is a civic address component.  CAtype 27 exists, therefore it should be used instead; if you want floors, use RFC 4776.  

There are no good, universal rules for floor numbers; determining a floor number from an altitude value is a geocoding operation.

Finally, the document does not _prevent_ the use of altitude type of 2, it only deprecates it.  Deprecation means: there is a better way to do this, please don't use this any more.

I think that the document does this the right way.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Thursday, 26 March 2009 5:41 PM
> To: [email-masked]
> Subject: [Geopriv] rfc3825 fix
> 
> Since non-broken parts do not usually need a fix, I believe the 'fix'
> has to be limited to the broken parts of the RFC. Since altitude type 2
> (floors) does not have anything to do with the broken part of the RFC,
> that should not be deprecated.
> 
> Therefore, if rfc3825bis is going to be accepted as a way forward to
> fix RFC 3825, I'd like the wg version of it to be limited to only
> contain the necessary fixes for the RFC.
> 
> - gabor
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Mar 2009 11:48:58 -0500

Martin

CAtype 27 is after any DHCP transaction.  Moving geo-floors from 
Option 123 into a PIDF-LO in CAtype 27 is easily done. Asking that 
"if you want floors, you need to ask for Option 99" is way overkill - 
because CAtype 27 isn't going to be the only thing returned if Option 
99 is sent (plus you're wasting bytes on the wire).

A client might not support Option 99 (for whatever reason).

Your argument that Floors is only locally significant - therefore 
somehow bad - doesn't solve how RFC 4776 has the same problem with floors.

Geocoding is something that isn't that hard to do, and will get 
easier to do, yet you are making a policy decision at the protocol 
level, instead of allowing the existing field to be decided in operation.

Do you have operational experience that RFC 3825 breaks when floors 
is used, or is this just a perceived preference for how you'd do it?

The latter isn't a good want to change an existing spec.

James

At 07:57 PM 3/26/2009, Thomson, Martin wrote:
>Floor is only locally significant within the constructed 
>environment, therefore it is a civic address component.  CAtype 27 
>exists, therefore it should be used instead; if you want floors, use 
>RFC 4776.
>
>There are no good, universal rules for floor numbers; determining a 
>floor number from an altitude value is a geocoding operation.
>
>Finally, the document does not _prevent_ the use of altitude type of 
>2, it only deprecates it.  Deprecation means: there is a better way 
>to do this, please don't use this any more.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 13:05:07 -0400

I've always been uncomfortable with floors in a geo.  Altitude in a geo is
height above mean sea level (or a local datum).  Everyone agrees that to get
floors, you are geocoding.  If you are geocoding you are turning a geo into
a civic.  You are free to return any or all parts of that geo.  If you have
a floor, I'd like the room number please.

Floors is also problematic, because you have the problem of how floors are
numbered.  Although there is a local convention, it's only good if you
either know it intimately, or the signage is functional.  In a really useful
case for this: the emergency case, that signage may not be useful.
Emergency responders don't use signage; effectively, they renumber floors
from a defined (at the scene) entrance.

If you have real altitude, I'd like that please, and not floors.  If you
want to geocode, and you tell me you did that, by all means, give me what
you think it is in civic.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Friday, March 27, 2009 12:49 PM
To: Thomson, Martin; [email-masked]; [email-masked]
Subject: Re: [Geopriv] rfc3825 fix

Martin

James

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Mar 2009 12:19:25 -0500

At 12:05 PM 3/27/2009, Brian Rosen wrote:
>floors, you are geocoding.

not necessarily. Option 123 is 17 bytes short. DHCP Option size may 
have importance. It certainly was something we were told to consider 
when we created Option 123.  Now you are advocating keeping Option 
123, but ignore Option size from being an issue - I believe - without 
getting someone from DHC saying this is no longer a concern.

SPs that provide location can easily choose to have no altitude in 
Option 123, or provide both Option 123 and 99.

Enterprises will have significantly more knowledge about local 
building layouts than SPs will, yet, I believe, enterprise solutions 
are taking at least a backburner here.

Why deprecate something that you haven't shown is broken for all 
potential customers of this spec?

>If you are geocoding you are turning a geo into
>numbered.

err., enterprises don't have this problem

>Although there is a local convention, it's only good if you
>either know it intimately, or the signage is functional.

like an enterprise would

>  In a really useful

it is to enterprises

>If you have real altitude, I'd like that please, and not floors.

meters in any building is useless

>  If you want to geocode, and you tell me you did that, by all 
> means, give me what

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 13:36:57 -0400

Just don't send it.

I claim there is no use case for lat/lon + floors that you can't do with
lat/lon+altitude.  In order to use a geo within a building (your enterprise
case), you need a floor plan.  If you have a floor plan, you can convert
altitude to the right place in the floor plans as well as you can convert
lat/lon into the right place.

Without a floor plan, you can't use the data. You can't
navigate/display/direct or do anything without the plan.  It's very useful
data, with the plan.  Without the plan, it's pretty useless.  If you have
the plan, altitude is as good as floors, and works in all cases.

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 1:19 PM
To: Brian Rosen; 'Thomson, Martin'; [email-masked]; [email-masked]
Subject: Re: [Geopriv] rfc3825 fix

like an enterprise would

it is to enterprises

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 18:53:57 +0100

My understanding was that in the meeting we discussed how to fix RFC 3825, and nothing else. Therefore, the update to RFC 3825 should be limited to fix the broken parts.

I do not believe there is any controversy in having floor numbers together with long/lat, as the altitude type value tells you what exactly the number in the altitude field means.

Taking away the possibility to convey floor numbers would not remove the need for an altitude type in the option. Therefore, I do not see any harm in having a type value allocated for floor numbers.

- Gabor

  >From: ext Brian Rosen [mailto:[email-masked]]
  >Sent: Friday, March 27, 2009 10:05 AM
  >To: 'James M. Polk'; 'Thomson, Martin'; Bajko Gabor (Nokia-CIC/MtView);
  >[email-masked]
  >Subject: RE: [Geopriv] rfc3825 fix
  >
  >Behalf
  >>------------------------------------------------------------------------
  >---
  >---------------------
  >>------------------------------------------------------------------------
  >---
  >---------------------
  >>[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Mar 2009 12:58:47 -0500

>lat/lon into the right place.

I've bought that argument for <gml> vs. <cl>, but not for the cases 
where you use Option 123 (geo) and have any issues Option sizes.

Again, I don't see what breaks.

You say you don't see any usage, and I'm asking for operational 
experience of this existing RFC in which altitude in floors is turns 
something bad, especially given that DHCP is never to be used in the 
conveyance protocol (which the first responders do see).

this seems to be to be a simple "where this goes in the PIDF-LO" 
problem, and not a "which Option delivers the LI" problem.

Yoy are arguing the latter because the first responders will be 
affected, and I'm claiming they will never see the LCP format, 
therefore this is not a problem.

What you want is is the former problem to be addressed, and I don't 
believe anyone disagrees that <cl:FLR> be used whenever floors are in 
the PIDF-LO.

>the plan, altitude is as good as floors, and works in all cases.

really?

Which hotel are you staying in here?

how many meters up is your floor?

Where is that on the map?

How do you account for differing heights of difference floors within 
the same building?

Where's that legend?

This is a PIDF-LO issue, not an LCP issue. Solve this where it needs 
to be solved.

James

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 2009 14:18:03 -0400

It's generally a bad idea to have two ways to do roughly the same  
thing, thus, I'm in favor of deprecating floors. All you get is the  
possibility that 3825 says "floor 5" and 4776 says "floor 6". It might  
have made sense when 3825 was standardized, given that we didn't have  
4776, but no longer fits. Given the ability to request items  
separately, the byte argument seems to be a stretch.

Henning

On Mar 27, 2009, at 1:36 PM, Brian Rosen wrote:

>> height above mean sea level (or a local datum).  Everyone agrees  
>> that to
> get
>>>> has to be limited to the broken parts of the RFC. Since altitude  
>>>> type
> 2

---

From: [email-masked]
Date: Fri, 27 Mar 2009 10:40:36 -0800

> separately, the byte argument seems to be a stretch.

I'm in favour of deprecating floors too.

Also, I'd privately made a proposal to add a version bit (or two) to 
3825bis that indicates whether the resolution fields should be read in 
RFC3825 mode or 3825bis mode.

Specifically, that bit could be taken from the datum field which is 
currently unnecessarily wide (8 bits).  So current datum #1 in 3825bis 
mode could become datum #129.

The downside is that is breaks full backwards compatibility, insomuch as a 
RFC3825 client receiving a 3825bis response would be unable to parse it 
because it wouldn't be a recognised datum.  However it would allow 
RFC3825bis clients to receive either format interchangeably and 
unambiguously.

Ray

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 27 Mar 2009 13:30:59 -0500

It still fits within the local area, floor 5 for building A is at a
different elevation than floor 5 in building B across the street, floors
are almost building specific, there certainly is no standardized method
other than what Brian suggest, using the floor plan for each building.
Long / Lat + altitude, even using the WGS 84 datum, will never give an
accurate floor, geocoding will not work in all cases either, it gets
back to each building is different. You really need a floor plan
specific to that building. Besides altitude is very inaccurate, even
when a receiver is stationary and can collect many readings over a
period of time.

By two cents,
 Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henning Schulzrinne
Sent: Friday, March 27, 2009 1:18 PM
To: Brian Rosen
Cc: [email-masked]; 'James M. Polk'; 'Thomson,Martin'
Subject: Re: [Geopriv] rfc3825 fix

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Mar 2009 13:53:01 -0500

Henning

This assumes RFC 4776 is mandatory to implement on both the client 
and the server (where DHCP is an LCP).

Will it be available in all cases?

If so, what says that?

James

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Mar 2009 16:17:30 -0400

Brian, Martin,

The issue is the LCI in 3825 is delivered from the network admin inside the
building.  The aren't geocoding, they know their floors.  The issue Gabor is
bringing up is the fact that others have taken the object from 3825 and are
using it with their transport (stripped DHCP).  They are expecting the IETF
to maintain the object.  They use and want to maintain the mu='floors'.
Those folks are not sending the LCI from 4776, hence, they won't be able to
send a floor value from that object.

Yeah, it's acknowledged it has limitations.  That's been accepted by those
using it.

Can you provide any technical (as in protocol problems) reason to not
maintain the mu=floors other than your personal dislike for it?

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 16:29:51 -0400

In order to get the lat/lon, that admin has to either have a measuring
device, or a floor plan with a datum.   Either gets him a real altitude
(albeit GPS is less accurate for altitude with lower signal levels typical
of in-building measurement).

There are no protocol problems.

There are a LOT of misunderstandings about location.  Everyone thinks it's
easy.  Lot's of people make mistakes.  Floors in 3825 was a mistake.  We
should fix it.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 4:18 PM
To: Brian Rosen; James Polk; 'Thomson, Martin'; [email-masked];
[email-masked]

Brian, Martin,

-Marc-

>>> contain the necessary fixes for the RFC.
---------------------------------------------------------------------------
---------------------------------------------------------------------------

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Mar 2009 22:11:05 +0100

My understanding of the hum in the GEOPPRIV group was that people were OK to open up 3825 to do fixes, but specifically rejected things that were essentially changing the document otherwise.

So in essence it is my view that if you wish to remove floors you need to prove something is broken. Just saying we took the wrong technical direction, but otherwise is not broken does not need a fix. Just saying we should not have have two technical solutions to the same problem is not necessarily broken and does not need a fix.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Friday, March 27, 2009 8:30 PM
> To: 'Marc Linsner'; 'James Polk'; 'Thomson, Martin'; 
> [email-masked]; [email-masked]
> (albeit GPS is less accurate for altitude with lower signal 
> levels typical of in-building measurement).
> 
> There are a LOT of misunderstandings about location.  
> Everyone thinks it's easy.  Lot's of people make mistakes.  
> Floors in 3825 was a mistake.  We should fix it.
> 
> Brian
> 
> To: Brian Rosen; James Polk; 'Thomson, Martin'; 
> [email-masked]; [email-masked]
> The issue is the LCI in 3825 is delivered from the network 
> admin inside the building.  The aren't geocoding, they know 
> their floors.  The issue Gabor is bringing up is the fact 
> that others have taken the object from 3825 and are using it 
> with their transport (stripped DHCP).  They are expecting the 
> IETF to maintain the object.  They use and want to maintain 
> the mu='floors'.
> Those folks are not sending the LCI from 4776, hence, they 
> won't be able to send a floor value from that object.
> 
> Yeah, it's acknowledged it has limitations.  That's been 
> accepted by those using it.
> 
> Can you provide any technical (as in protocol problems) 
> reason to not maintain the mu=floors other than your personal 
> dislike for it?
> 
> -Marc-
> 
> 
> 
> > I've always been uncomfortable with floors in a geo.  Altitude in a 
> > geo is height above mean sea level (or a local datum).  Everyone 
> > agrees that to
> get
> > floors, you are geocoding.  If you are geocoding you are 
> turning a geo
> into
> > a civic.  You are free to return any or all parts of that 
> geo.  If you
> have
> > Floors is also problematic, because you have the problem of 
> how floors 
> > are numbered.  Although there is a local convention, it's 
> only good if 
> > you either know it intimately, or the signage is functional.  In a 
> > really
> useful
> > Emergency responders don't use signage; effectively, they renumber 
> > floors from a defined (at the scene) entrance.
> > 
> > If you have real altitude, I'd like that please, and not 
> floors.  If 
> > you want to geocode, and you tell me you did that, by all 
> means, give 
> > me what you think it is in civic.
> > 
> > Brian
> > 
> > Behalf Of James M. Polk
> > Option 123 into a PIDF-LO in CAtype 27 is easily done. 
> Asking that "if 
> > you want floors, you need to ask for Option 99" is way overkill - 
> > Geocoding is something that isn't that hard to do, and will 
> get easier 
> > to do, yet you are making a policy decision at the protocol level, 
> > instead of allowing the existing field to be decided in operation.
> > 
> > Do you have operational experience that RFC 3825 breaks 
> when floors is 
> > used, or is this just a perceived preference for how you'd do it?
> > 
> environment, 
> >> therefore it is a civic address component.  CAtype 27 exists, 
> >> therefore it should be used instead; if you want floors, use RFC 
> >> 4776.
> >> 
> >>> type 2
> >>> (floors) does not have anything to do with the broken part of the 
> >>> RFC, that should not be deprecated.
> >>> 
> >> This message is for the designated recipient only and may contain 
> >> privileged, proprietary, or otherwise private information.
> >> immediately and delete the original.  Any unauthorized use of this 
> >> email is prohibited.
> >>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Mar 2009 17:17:09 -0400

Brian,

> device, or a floor plan with a datum.   Either gets him a real altitude

I would suggest that most floor plans designate 'floor' (in addition to your
claimed 'altitude').

> of in-building measurement).

I thought the IETF wasn't in the business of location determination.

> easy.  Lot's of people make mistakes.  Floors in 3825 was a mistake.  We

Those using it disagree with you.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 2009 17:17:19 -0400

On Mar 27, 2009, at 5:11 PM, DRAGE, Keith (Keith) wrote:

> My understanding of the hum in the GEOPPRIV group was that people  
> were OK to open up 3825 to do fixes, but specifically rejected  
> things that were essentially changing the document otherwise.

My recollection of the hum was that this was about backward- 
compatibility, not specific to the fields discussed.

I would suggest we gather a list consensus on this issue, rather than  
just appeal to process. After all, the IETF74 hum needs to be  
confirmed by the list discussion in any event.

>
>
> So in essence it is my view that if you wish to remove floors you  
> need to prove something is broken. Just saying we took the wrong  
> technical direction, but otherwise is not broken does not need a  
> fix. Just saying we should not have have two technical solutions to  
> the same problem is not necessarily broken and does not need a fix.

It's not just two ships-in-the-night solutions (like CDP and RSVP-TE),  
it's two solutions that are likely to appear in the same packet for  
indoor locations and thus cause a new error condition.

Henning

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Mar 2009 22:31:08 +0100

Gathering list consensus is an appeal to process!

The existing document is an RFC. That raises the consensus bar to change it.

You need to gather consensus for a change. Failure to gain consensus means there is no change.

Keith 

> [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
> Sent: Friday, March 27, 2009 9:17 PM
> To: DRAGE, Keith (Keith)
> Cc: GEOPRIV WG
> > My understanding of the hum in the GEOPPRIV group was that 
> people were 
> > OK to open up 3825 to do fixes, but specifically rejected 
> things that 
> > were essentially changing the document otherwise.
> 
> I would suggest we gather a list consensus on this issue, 
> rather than just appeal to process. After all, the IETF74 hum 
> needs to be confirmed by the list discussion in any event.
> 
> >
> >
> > So in essence it is my view that if you wish to remove 
> floors you need 
> > to prove something is broken. Just saying we took the wrong 
> technical 
> > direction, but otherwise is not broken does not need a fix. Just 
> > saying we should not have have two technical solutions to the same 
> > problem is not necessarily broken and does not need a fix.
> 
> It's not just two ships-in-the-night solutions (like CDP and 
> RSVP-TE), it's two solutions that are likely to appear in the 
> same packet for indoor locations and thus cause a new error condition.
> 
> Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 27 Mar 2009 20:21:16 -0500

I've stated my opinion, which hasn't changed, but...

Let's be pragmatic.  Deprecation of altitude in floors is one of those "protocol police" things, since the registry entry remains and people can continue to use it if they choose.  And I've heard that some people have use cases for it.  Even these are just optimisations and logically it's the wrong place for the data, we need to face the fact that there's nothing we can do to prevent someone from using altitude datum = 2.

So what I propose is to remove the ineffectual datum text and we can get on with more important work.

Regards,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Apr 2009 00:03:24 -0500

All,

I have made the changes to the document, as described below.

The updated document is here:

<http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-09>

Richard has requested that I add the following to the security considerations (with my edits) as a clarification on LIS authentication:

"
This document does not provide a mechanism for the client to discover information on certificate that a LIS might present in order to authenticate the LIS.  Alternative mechanisms might be specified in future work.  Thus, in order for a LIS to successfully authenticate itself to a client, the client MUST be provisioned out of band with information that allows it to authenticate the LIS.  For example, a client might be statically provisioned with a default list of trust anchors.
"

My only concern is that this might be mistaken for a new mechanism.  The intent is only to describe the usual domain name based authentication used in browsers.  I am of the opinion that RFC 2818 already provides enough text on authentication, but I am ok with the above text.

I also don't like "future work" type statements, but again, I'm ok with them.

--Martin

> Behalf Of Thomson, Martin
> Sent: Friday, 27 March 2009 9:30 AM
> To: GEOPRIV
> Subject: [Geopriv] LIS discovery direction
> 
> We are making excellent progress on this document considering that we
> only get to work on it for 2.5 hours every four months.
> 
>  - The overall section will no longer mandate (2119 MUST) use of DHCP
> over U-NAPTR.  Instead I propose the following addition to the first
> paragraph.
> 
>    "Methods of discovery that explicitly provide a LIS URI, such as the
> DHCP method described in section 2, are preferred over method that are
> based on any degree of inference."
> 
> After the update Richard and I will look to getting an updated security
> review.  I strongly suspect that our SECDIR reviewer will be OK with
> the change.
> 
> Cheers,
> Martin
>