I know you responded, but how you responded didn't make sense to me.
To be clear, I'm not suggesting a Geolocation: be in the SUBSCRIBE,
just in the NOTIFY, if it contains a PIDF-LO.
Saying Presence predates Conveyance therefore you're gonna stick to
the old rules and procedures of Presence is explicitly saying you
don't care about any changes that are being made since Presence was
first defined -- which Conveyance does to all of SIP when Location is
carried in any SIP request.
Heck, dude, Conveyance even insists when you subscribe to another
entity, you use the Presence event package *with* a Geolocation:
header value (when location is contained as a value or a reference).
Conveyance updates all of SIP where location is concerned, it's just
not a formal update to 3261 or 3265.
I'm saying - also - that RFPs will be written saying whenever
Location is transported in SIP, that vendor's products must support
whatever RFC Conveyance becomes. Yet, you're arguing that in the case
of Presence - which Conveyance talks about - don't use the rules or
guidelines in Conveyance.
I'm thinking this may be the wrong list to have this discussion,
since Conveyance belongs to the SIPCORE WG, and that's where
subscriptions are primarily also owned.
James
At 01:12 PM 11/13/2009, Brian Rosen wrote:
>James
>
>We've responded to this, and yet you persist.
>
>This is PRESENCE. Nothing more, nothing less.
>
>PRESENCE, predates Geolocation by a lot, but even if it didn't, presence
>returns a PIDF in the body of a NOTIFY. It doesn't need, nor want, a
>Geolocation header even if the PIDF contains a PIDF-LO. That is
>fundamental. It's simple.
>
>Think about what you are saying. If a plain old presence subscription
>happens to have a PIDF-LO in it, you are arguing that there must be a
>Geolocation header in the NOTIFY. That makes no sense.
>
>You subscribe to presence, and if the presence NOTIFY has location,
>loc-filters can be used, like any other filter, to adjust the frequency of
>notification. It is NOT related to Geolocation.
>
>It's not implementation choice. If you are using the presence event
>package, you don't use Geolocation (at least normally). I shudder to
>imagine what would happen if you tried. I think you would need multipart
>and two PIDFs, one for the Notify body and the other for the Geolocation
>header cid.
>
>Brian
>
>
>On 11/13/09 1:31 PM, "James Polk" <jmpolk@cisco.com> wrote:
>
> > Richard
> >
> > If nothing else, I'm firmly reminding whoever is the document
> > shepherd that there are some outstanding issues remaining, and these
> > need to be checked out - as they occurred within WGLC - before the
> > doc gets thrown over the wall to the IESG.
> >
> > Sometimes firmness (or bluntness) is needed to get attention.
> >
> > For instance, the stance of the authors that this doc has no
> > relationship to Location Conveyance will be troublesome for
> > implementers, given that Conveyance has always said - even before
> > Rohan wrote the first -00 of loc-filters - that for SIP to carry
> > location as a value or a location URI, the Geolocation header value
> > (which back then was the Location header value) must be present.
> >
> > Now, according to Location Conveyance, implementers must include a
> > Geolocation header value when carrying location as a PIDF-LO or a
> > Location URI, even in a NOTIFY request. Yet, according to
> > loc-filters-08 and the authors, the Geolocation header value is not
> > necessary at all.
> >
> > So, imagine you are an implementer, if you're implementing
> > loc-filters you are probably implementing Location Conveyance too.
> > Now, are you really going to implement that in some cases there is a
> > Geolocation header value, and this one case there is none - by
> > implementation choice?
> >
> > that will lead to Location Conveyance not being followed, or
> > loc-filters having something added to it when implemented.
> >
> > This is an inconsistency that might be troublesome to LRs, and appear
> > in RFPs, as this is clearly not following the rules of Location
> > Conveyance, which is defining SIP as a using protocol (a defined term
> > that some believe doesn't apply anymore, yet is still in our
> > documents, and is in one that's about to go to the IESG
> > (lbyr-requirements) from this WG -- so this means it's still applicable).
> >
> > James
> >
> > At 03:23 AM 11/12/2009, Richard Barnes wrote:
> >> James,
> >>
> >> Don't shoot the messenger, man! I was just trying to summarize what
> >> Hannes said. The following may be more accurate:
> >>
> >> "Hannes Tschofenig noted that the major outstanding technical issue
> >> with loc-filters is whether to add a "speed greater than" condition."
> >>
> >> Please note that that sentence doesn't imply that he's not going to
> >> address the rest of your comments, just that they're more
> >> straightforward than that issue.
> >>
> >> --Richard
> >>
> >>
> >>
> >>
> >>
> >> On Nov 12, 2009, at 3:04 PM, James M. Polk wrote:
> >>
> >>> At 10:29 PM 11/11/2009, Richard Barnes wrote:
> >>>> Minutes - GEOPRIV - IETF76
> >>>>
> >>>> Summary (prepared by Richard Barnes):
> >>>>
> >>>> 1. Chairs' Introduction
> >>>> The chairs reviewed the status of several WG documents. Hannes
> >>>> Tschofenig noted that there is only one outstanding issue with loc-
> >>>> filters, namely whether to add a "speed greater than" condition.
> >>>
> >>> Richard/Alissa
> >>>
> >>> I sent a note to the list containing 47 numbered comments with what
> >>> I believe need to be addressed wrt to my review of loc-filters.
> >>> http://www.ietf.org/mail-archive/web/geopriv/current/msg08118.html
> >>>
> >>> The authors haven't replied to at least half of the comments I made.
> >>>
> >>> Are these being ignored by the chairs, or possible was this note not
> >>> read?
> >>>
> >>> Or do you want issue tracker entries for all 47 before they will be
> >>> considered?
> >>>
> >>> Or do I need to write individual messages to the list, with numbers,
> >>> so that each can be addressed and closed individually?
> >>>
> >>> I'm kinda at a loss as to how this many comments look like they are
> >>> about to be ignored -- especially since I didn't get into the "speed
> >>> greater than" issue that is mentioned above (but maybe I'm not
> >>> understanding the issue as stated; as I have issues regarding this
> >>> section of the ID -- like acceleration anyone?).
> >>>
> >>> James
> >>>
> >>> BTW -- I agree with some of the author's responses (as some of these
> >>> were just clarifications about what was meant). I am pleased some of
> >>> my comments have resulted in modified text. However, I don't agree
> >>> with all of the responses. I'll be continuing with the list thread
> >>> about these.
> >>>
> >>>> Martin Thomson noted that lis-discovery is ready to go to the IESG
> >>>>
> >>>> 2. RFC 3825 Update
> >>>> draft-ietf-geopriv-rfc3825bis
> >>>> Bernard Aboba presented an update on this document. Several issues
> >>>> have been closed, leaving three remaining after the next, upcoming
> >>>> revision.
> >>>>
> >>>> 3. GEOPRIV Architecture
> >>>> draft-ietf-geopriv-arch
> >>>> Alissa Cooper presented an update on this document. The most recent
> >>>> edition added some clarifications and simplifications. Ms. Cooper
> >>>> proposed that the document be last-called.
> >>>>
> >>>> 4. HELD Identity Extensions
> >>>> draft-ietf-geopriv-held-identity-extensions
> >>>> Martin Thomson presented an update on this document. The primary
> >>>> open
> >>>> issues are around how authentication and authorization are applied.
> >>>> Cullen Jennings expressed concern that current text on authenticating
> >>>> ownership of identifiers is not implementable. The authors agreed to
> >>>> add more explanatory text, and where good authentication techniques
> >>>> cannot be clearly described, to restrict usage to limited cases with
> >>>> pre-configured authorization relationships.
> >>>>
> >>>> 5. Indoor Location
> >>>> draft-stanley-geopriv-int-ext
> >>>> draft-polk-geopriv-int-relative-in-tlv
> >>>> draft-rosen-geopriv-pidf-interior
> >>>> draft-thomson-geopriv-indoor-location
> >>>> Dorothy Stanley presented an overview of the first three documents.
> >>>> Martin Thomson and Brian Rosen expressed reservations about the
> >>>> syntax
> >>>> that these drafts employ, in particular the overloading of the civic
> >>>> address structure. Martin Thomson presented an overview of his
> >>>> document. The two teams agreed to work together to come up with a
> >>>> unified strategy.
> >>>>
> >>>> 6. Geocoding
> >>>> draft-george-geopriv-address-translation
> >>>> Robins George presented an overview of this document. Several
> >>>> participants had read the draft and agreed that the general topic is
> >>>> worth working on, but doubted whether HELD was the appropriate
> >>>> protocol. At least one more revision will be necessary before the
> >>>> draft can be considered for adoption.
> >>>>
> >>>> 7. Policy URIs
> >>>> draft-barnes-geopriv-policy-uri
> >>>> Richard Barnes presented an overview of this document. Hannes
> >>>> Tschofenig and Martin Thomson observed that indirect-publish
> >>>> mechanisms might be more suitable.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Raw notes from John Elwell and Stephen McCann follow:
> >>>> ------------------------------------------------------------
> >>>> Status update:
> >>>> On held-identity-extensions:
> >>>> Remote: Are we going to do a generalised mechanism?
> >>>> Martin: ????
> >>>> Martin: lis-discovery - about ready.
> >>>>
> >>>> draft-ietf-geopriv-rfc3825bis (Bernard Aboba)
> >>>> Chair: Does issues list include discussion on list in last 24 hours
> >>>> Bernard: Indicated which issues were still open.
> >>>> Martin: Document in good shape apart from 3 issues listed on slide.
> >>>>
> >>>> draft-ietf-geopriv-arch (Alissa Cooper)
> >>>> In opinion of Alissa, about ready for last call.
> >>>> About 6 people had read the document.
> >>>>
> >>>> HELD Identity Extensions update and discussion of open issues
> >>>> draft-ietf-geopriv-held-identity-extensions (Martin Thompson)
> >>>> Issue#19: Martin also added that latest discussions lead to
> >>>> restrictions in which something can be considered LCP. No discussion.
> >>>> Issue#27: No discussion.
> >>>>
> >>>> Open issue on solution scope: Martin's proposal is that the questions
> >>>> raised on the list are valid questions but do not need to be
> >>>> addressed
> >>>> in this document, so out of scope.
> >>>> Richard: OK with first, but 2nd and 3rd should have something said to
> >>>> address privacy concerns.
> >>>> Cullen: On 2nd and 3rd, which document DOES address these?
> >>>> Richard: Can't have a general solution for these, but at least can
> >>>> give guidance.
> >>>> Cullen: Need proper normative references to get past IESG.
> >>>> Martin: We have such references, will make document a bit longer if
> >>>> we
> >>>> put them in. But problem is, that for one network they may work fine,
> >>>> but not for the next one.
> >>>> Jon: Sense is correct (not wrong), but unsure that it is complete or
> >>>> helpful (but that was a month ago). Doesn't understand how IMSI would
> >>>> work, for example.
> >>>> Martin: IMSI easier than MAC address from my perspective.
> >>>> Cullen: Others won't understand it - write it down.
> >>>> Jon: Different classes of problem, for IMSI, MAC address etc.
> >>>> Jabber: Gave reference.
> >>>> Martin: Don't see much value in an LCP request with identifier.
> >>>> Cullen: We need to say how privacy will work, although there won't be
> >>>> a single answer. From the present document I fail to see the answers.
> >>>> Same issue will come up from people who haven't previously read the
> >>>> document, as it progresses.
> >>>> Martin: Disallow request if you don't have policy for dealing with
> >>>> that request.
> >>>> Cullen: Not implementable.
> >>>> Richard: One case is MAC address look-up from IP address:
> >>>> Cullen: This doesn't make sense.
> >>>> Martin: That is correct, supplying MAC address as identifier is not
> >>>> required.
> >>>> Richard: So doesn't do any harm.
> >>>> Cullen: So it might be misused for something else.
> >>>> Martin: Explained one case.
> >>>> Jon: If that is the only case, I understand.
> >>>> Martin: Explained another case.
> >>>> Brian: Can give you a use case for LCP - involves a gateway. Could
> >>>> turn it into third party, but really it is first party.
> >>>> Jon: This should be treated as third party.
> >>>> Martin: No problem covering this in the document.
> >>>> Jon: Need text that says that for third party case must be some
> >>>> pre- association, and must express scope of what requests can be
> >>>> made.
> >>>> Cullen: Write down how it should work in practice. We have been
> >>>> complaining about W3C ignoring all privacy, so we should ourselves
> >>>> address the issue.
> >>>> Martin: When hosts can get their own location, this will gradually go
> >>>> away.
> >>>> Jon: This is a MUST use case, not just a MUST implement.
> >>>> Jabber: ????
> >>>> Alissa: Make it clear in document which of these are third party
> >>>> cases.
> >>>> Jon: Fundamental distinction between these cases - different
> >>>> approach,
> >>>> different security.
> >>>> Martin: Want people to attach to network and get location information
> >>>> they need, and often IP address is sufficient.
> >>>> Jon: Don't' all become 3rd party, they are different.
> >>>> Alissa: They need to be explained.
> >>>> Martin: Will deal with non-LCP cases in more detail.
> >>>> Chair: If we can solve by reference, that would be fine.
> >>>>
> >>>> Open issue that we need examples:
> >>>> No agreement on list on what principles, but perhaps moot in view of
> >>>> previous discussion.
> >>>>
> >>>> Open issue on alphabet soup:
> >>>> Martin: Not a lot I can do about it, but we are in a lot better state
> >>>> than some other documents.
> >>>> Cullen: I agree with people complaining about this.
> >>>>
> >>>> No other issues raised from floor.
> >>>>
> >>>>
> >>>> Indoor location proposals
> >>>> draft-stanley-geopriv-int-ext
> >>>> draft-polk-geopriv-int-relative-in-tlv (Dorothy Stanley)
> >>>> Proposal also make use of draft-rosen-geopriv-pidf-interior.
> >>>> Jabber: Why just these shapes?
> >>>> Dorothy: Others can be added - just not in this draft.
> >>>> Roger Marshall: Good to have a discreet reference that is more
> >>>> precise
> >>>> than "front door".
> >>>> Dorothy: Looking to provide civic-only parameters.
> >>>> Brian: Like the draft. Generally the approach is correct, but two
> >>>> problems. "Front door" is a string that does not exist on the
> >>>> drawing.
> >>>> Would like to see something like "Door" with value "Front". Add
> >>>> another level or two of INT. Second issue is syntax for offset. Would
> >>>> prefer a more structured syntax.
> >>>> Dorothy: On first point, this was considered, but went this way to
> >>>> provide additional flexibility for deployment. Otherwise we would
> >>>> need
> >>>> to know all entity types (door, elevator, etc.) that one might want
> >>>> to
> >>>> use, and this is very difficult.
> >>>> Richard: Agree with Brian we should say what it is and what it is
> >>>> called.
> >>>> Dorothy: Yes, but issue of how to specify and what degree of
> >>>> flexibility we want to give.
> >>>> Marc: IEEE has adopted PIDF-LO and is using it in its protocols, so
> >>>> to
> >>>> say stop now and go in a different direction puts us in a bad light.
> >>>> Doesn't see problem with having a tag.
> >>>> Martin: I have already outlined my concerns, and whilst the use cases
> >>>> need to be solved, this is a bad way of doing it. A recipient could
> >>>> be
> >>>> mislead by this. Need to get the data model right first - then fix
> >>>> the
> >>>> other things.
> >>>> Roger: ????
> >>>> Dorothy: In response to Jabber question, not trying to add
> >>>> complexity,
> >>>> just extending what already exists.
> >>>> Martin: The bunch of elements being introduced masks the complexity
> >>>> that is there. An entity not understanding the extension would get
> >>>> the
> >>>> wrong location.
> >>>> Dorothy: But would still have building address.
> >>>> Martin: Each element added to a civic address should make the
> >>>> location
> >>>> more specific. Adding these elements should make the location
> >>>> specific, but they are intentionally making it less specific (e.g., a
> >>>> circle) and shifting the location.
> >>>> Hannes: No way of negotiating what you understand.
> >>>> Dorothy: In the context of using this, would know the protocols being
> >>>> used.
> >>>> Hannes: Could use proprietary.
> >>>>
> >>>> Concerning comparison with draft-thomson-geopriv-indoor-location
> >>>> Martin: I don't think it is a good characterisation of my draft.
> >>>>
> >>>> draft-thomson-geopriv-indoor-location (Martin Thompson)
> >>>> Addresses same problem, but solution takes into account some things
> >>>> Martin considers important.
> >>>> Cullen: How to get from WGS84 is better attached as metadata to the
> >>>> map, but otherwise like the way this is going.
> >>>>
> >>>> Martin: Will need to discuss on list.
> >>>>
> >>>> Dorothy's final slide:
> >>>> Dorothy: Solutions have different characteristics, and different
> >>>> applications have different needs. So recommendation is to progress
> >>>> both.
> >>>> Martin: Would be willing to work on a merged proposal, if we get the
> >>>> data model right. Don't want to see two competing solutions.
> >>>> Dorothy: Happy to discuss this off-line, but there are some important
> >>>> considerations that need to be kept. Requirements don't appear to be
> >>>> quite the same.
> >>>> Martin: Let's discuss requirements and see which ones survive.
> >>>>
> >>>> Jabber (James): Any location must have significance outside the local
> >>>> environment.
> >>>> Martin: Either need a way of specifying both an outside location and
> >>>> an inside location, or need to know which the application needs.
> >>>>
> >>>> Marc: There is running code on some of this IEEE stuff.
> >>>> Richard: Should not have impact on XML - should be able to translate
> >>>> to/from binary.
> >>>>
> >>>> Brian: Would like to see one solution for this, if possible.
> >>>>
> >>>>
> >>>> draft-george-geopriv-address-translation (Robins George)
> >>>> 4 people have read the draft.
> >>>> Martin: Like the idea in general. Location requests in HELD is
> >>>> probably not the right way. Either use a different request in HELD,
> >>>> or
> >>>> better, another protocol. Perhaps need to work with James Polk. Also
> >>>> there are discussions on putting something similar into LoST.
> >>>> Roger: Good idea to have a standard for this. Seconds Martin's
> >>>> comments on use of HELD - perhaps a light LoST usage.
> >>>> Martin: Last discussion said don't geocode in LoST.
> >>>> Brian: Martin has said most I want to say. Would not accept the draft
> >>>> as is.
> >>>> Chair: More discussion on list.
> >>>>
> >>>> draft-barnes-geopriv-policy-uri (Richard Barnes)
> >>>> Open question: Does the general approach make sense
> >>>> Is the extension syntax correct (DHCP and HELD)?
> >>>> Do we need also to provide general policy (outside of LbyR)
> >>>> What is the right protocol for installing policy.
> >>>>
> >>>> Hannes: There was a previous proposal that people found too
> >>>> complicated. That was placed with something simpler in the HELD
> >>>> context document. Advocates a different model. How would server
> >>>> authenticate.
> >>>> Richard: Not all the things the policy server can provide require
> >>>> authentication.
> >>>> Hannes: ????
> >>>> Martin: Not too against it, but don't see it as deployable.
> >>>> Jon: Needs to be some glue for some cases. Want to make sure all
> >>>> those
> >>>> cases are covered.
> >>>> Martin: Third bullet on open issues slide - thinks this is bad - sees
> >>>> no need to do. To Jon's questions, need to work on it.
> >>>>
> >>>> Other business:
> >>>> Martin: People should perhaps get involved with indirect publish,
> >>>> which seems to have relevance to these discussions, although it is
> >>>> only a straw man.
> >>>>
> >>>> Meeting closed.
> >>>>
> >>>>
> >>>> ------------------------------------------------------------
> >>>> alissa and Richard Barnes chairing
> >>>>
> >>>> see slides (geopriv agenda)
> >>>>
> >>>> Draft status
> >>>> ------------
> >>>>
> >>>> Brian Rosen's document is now in last call. There don't appear to be
> >>>> any mailing list comments on this.
> >>>>
> >>>> HELD on the RFC editors queue
> >>>>
> >>>> -loc-filters: Resolving WGLC issues
> >>>>
> >>>> Hannes: regarding the filter document, there was an issue about
> >>>> reachng a certain speed (e.g. 100km/h). You can currently say that
> >>>> the speed is above this limit. A custom filter is possibly required.
> >>>>
> >>>> Richard; Please can we take this discussion to the list
> >>>>
> >>>> Martin: I'm not sure why we want to use this.
> >>>> A: Tempreture changes, why not add greater than, less than.
> >>>>
> >>>> Martin: -lis-discovery, this has now finished last call and I've
> >>>> updated it with comments. I think its ready for IESG evaluation
> >>>> Cullen: Yes, I agree
> >>>>
> >>>> w3C liaison
> >>>> -----------
> >>>>
> >>>> We sent some comments to w3C regarding their liaison.
> >>>>
> >>>> It looks as though no further action is required.
> >>>>
> >>>> RFC 3825bis - Bernard Aboba (remotely)
> >>>> ---------------------------
> >>>>
> >>>> Added some next sections as shown in the slides.
> >>>>
> >>>> Martin: Does these updates include the list discussion during the
> >>>> last
> >>>> 48 hrs?
> >>>> Bernard: Not entirely
> >>>>
> >>>> Martin: If we can close off the 3 issues as shown, then I think the
> >>>> document is good. Issue 4 is a bit of a concern.
> >>>> Bernard: Yes, ok. There are some more possible change to this.
> >>>>
> >>>> -arch-01 - Alissa Cooper
> >>>> ------------------------
> >>>>
> >>>> Changes since 01.
> >>>>
> >>>> Alissa thinks the document is ready for WG last call (WGLC).
> >>>>
> >>>> Richard: How many people have read this document. About 9
> >>>>
> >>>> HELD identity - Martin Thomson
> >>>> ------------------------------
> >>>>
> >>>> Changes since 01
> >>>>
> >>>> two primary issues have been raised: Issue #19 and Issue #27
> >>>>
> >>>> There are some outstanding issues.
> >>>>
> >>>> Richard: OK, that's fine for the 1st point. For the 2nd and 3rd
> >>>> (about
> >>>> the security issues) I'm not sure.
> >>>> Cullen: But which document addresses the 2nd and 3rd points?
> >>>> Richard: Well, they would be use cases and have not been written
> >>>> down.
> >>>> We'll not have any universal solution to these issues. We can produce
> >>>> a set of requirements.
> >>>> Cullen: We need normative text so we can actually implement this.
> >>>> Alissa: There have been some ideas on the list, but are not in the
> >>>> draft.
> >>>> Jon Peterson: The text is ok, but I don't think it's complete. The
> >>>> IMSI cases are difficult.
> >>>> Martin: I don't think IMSI makes sense for LCP.
> >>>> Cullen: So perhaps we should split out IMSI.
> >>>> Martin: But IMSI is easier than using a MAC address. I can put in
> >>>> another paragraph about this.
> >>>> Jon: There are different classes of identifier, and perhaps these
> >>>> need
> >>>> to be dealt with seperately. You have different sets of security
> >>>> challenages for these classes. The IMSI does scare me (regarding the
> >>>> ease of attack), as opposed to MAC address.
> >>>> James Winterbottom (remotely). Something is already defined in a TS
> >>>> 31.xxx document (3GPP).
> >>>> Martin: I don't see any point in having a LCP request which contains
> >>>> an indentifier.
> >>>> Cullen: But this group is supposed to only create functionality where
> >>>> security is included. The document is missing this level of detail.
> >>>> Martin: So, if a 3rd request comes in, without a policy identifer,
> >>>> then we should ignore.
> >>>> Richard: Your trying to authenticate the identifier againsts an IP
> >>>> address, which is the LCP case.
> >>>> Martin: So we don't need any identifer.
> >>>> Cullen: But this draft will not be used for that type of
> >>>> functionality. You must be able to secure this system.
> >>>> Jon: Re: Emergency Service case: This is the only case where I can
> >>>> see
> >>>> this draft working.
> >>>> Brian (remotely): I agree that this is abig problem. You have a class
> >>>> 5 switch and need location for an ES. The identifier is a phone call.
> >>>> The gateway will query it's location using its own telephone number.
> >>>> The network will then assert the location against that number. The
> >>>> LIS
> >>>> should know the range of numbers and therefore allow location to be
> >>>> determined for that gateway. Therefore this is case where no IP
> >>>> address is used.
> >>>> Jon: I think this is still a 3rd party situation. It only works based
> >>>> on a security pre-association.
> >>>> Martin: ok, so I can put this in the document.
> >>>> Jon: So you add some text which describes the 3rd party case and the
> >>>> assumptoipn that there is a pre-SA between the individual and the
> >>>> LIS.
> >>>> Martin: So, that's your policy.
> >>>> Jon: Without a pre-SA, then this mechanism will not work.
> >>>> James (remotely): NAI is used in WiMAX. Typically there is no mapping
> >>>> of IP address to identifiers in a enterprise.
> >>>> Alissa: I think you need to describe the use cases for the 3rd party
> >>>> scenarios.
> >>>> Jon: I think there are almost all 3rd party cases, but there may be a
> >>>> couple of 1st party cases, where the security threat model is
> >>>> different. IMSI is a long term identifier.
> >>>> Alissa: Sure, but they all need to be explained.
> >>>> Martin: Ok, I'll address the cases where LCP make sense.
> >>>> Cullen: perhaps we could pull in the references to other SDOs which
> >>>> have addressed the IMSI case.
> >>>>
> >>>> Alphabet Soup comment
> >>>>
> >>>> Cullen: This draft is quite heavy on the acronyms.
> >>>> Martin: I agree but I'm not sure what I can do about it.
> >>>>
> >>>> -int-ext & -int-relative-in-tlv - Dorothy Stanley
> >>>> -------------------------------
> >>>>
> >>>> There is also a draft rosen-pidf-interior, which has been covered in
> >>>> this pressentation.
> >>>>
> >>>> This work is partially in response to a liaison from IEEE 802.11,
> >>>> asking for support of WLAN relative locations.
> >>>>
> >>>> James Winterbottom: Why is ellipse not in the list?
> >>>> Dorothy: I'm sure that it can be added at a later point. It's not in
> >>>> the first draft.
> >>>>
> >>>> Cullen: The IP manager policy issue is quite unique.
> >>>>
> >>>> Richard: What is the difference between the private and the
> >>>> registered
> >>>> int syntax.
> >>>> Dorothy: It's just the way they are registerred.
> >>>> Roger Marshall: It appears to be a subjective reference. Perhaps you
> >>>> should use a wall.
> >>>> Dorothy: Yes, you could use a WG system, with a lat/long.
> >>>> Brian Rosen: This is very useful. But I have two problems:
> >>>>
> >>>> 1) the reference itself. Front door is a string which does not exist
> >>>> on the buliding drawing itself. I would like the reference point to
> >>>> be
> >>>> the civic address itself, then specify a "door" on the drawing
> >>>> itself.
> >>>> This adds another level of INT.
> >>>> 2) the syntax of the offset, is defined as INTs. Normally we would
> >>>> expect to see a normal piece of XML. This document tries to fit into
> >>>> the PIDF-LO syntax and to fit within a TLV.
> >>>> I think this is a poor way to define a new data strucuture. I think
> >>>> we
> >>>> should define a new element instead and have a new mapping to TLVs.
> >>>>
> >>>> Brian: With that I think it would be a really great draft.
> >>>> Dorothy: Regarding the enumeration of the door, we'd then have to
> >>>> enumerate all entities within the building, e.g. door, elevator,
> >>>> water
> >>>> cooler etc. I think our scheme gives more flexibility.
> >>>> Richard: But there needs to be a split syntax, say whay the entity
> >>>> is,
> >>>> then what it's name is.
> >>>> Dorothy: The problem is that the civic address is not enough to
> >>>> provide the referece point.
> >>>> Marc Lisner (remote): IEEE has adopted some of the PIDF-LO work and
> >>>> so
> >>>> we're trying to re-use that syntax. Regarding the explicit reference,
> >>>> I think this is a minor point. When it's mapped to the binary code.
> >>>> Martin: Civic address can identity a reference point for you. I think
> >>>> this is bad way to add a new item. The use cases are good. The
> >>>> binary
> >>>> format is not well designed. It allows mis-understanding. I think
> >>>> we
> >>>> need to get the data format correct, before we consider the binary
> >>>> format (RFC 4476).
> >>>> Roger: One different point would be to think of a virtual rectangle,
> >>>> and then to define anchor points at the corners. Then suite 400
> >>>> centroid would make sense. The rectangle would then cover any civic
> >>>> location.
> >>>> James Winterbottom (remotely): Why not define a new location type, as
> >>>> opposed to Civic.
> >>>> Dorothy: We're not looking to add a lot of new functionaluty. We just
> >>>> want to extend what's there already.
> >>>> Martin: But you've already added new elements. The extra extensions
> >>>> can move the reference point and cause confusion.
> >>>> Dorothy: But the civic address is still ok.
> >>>> Martin: Every element you add to a civic address, just refines the
> >>>> location. Adding these element should refine the civic address, not
> >>>> move it somewhere else.
> >>>> Hannes: When we added speed and velocity, work in GML helped us. This
> >>>> is a similar problem. We then decided to not use the GML, as they
> >>>> were
> >>>> not backward compatible. Another approach is to go for a propriatery
> >>>> solution.
> >>>>
> >>>> Comparison table (between -stanley and -thomson)
> >>>>
> >>>> Martin: I was asked not to present, but I do have a presentation of
> >>>> my
> >>>> draft ready
> >>>> Alissa: Let's allow Dorothy to go through the comparison table, then
> >>>> you can present.
> >>>>
> >>>> Indoor Location - Martin Thomson
> >>>> --------------------------------
> >>>>
> >>>> Cullen: The transformation from WGS84 to the map is better attached
> >>>> as
> >>>> meta-data to the map itself, as opposed to the location offset
> >>>> itself.
> >>>> Otherwise, I do like the direction that this is going.
> >>>>
> >>>> Recommendations slide - Dorothy Stanley
> >>>> ---------------------------------------
> >>>>
> >>>> The two solutions are different.
> >>>> recommendation is to progress both solutions
> >>>>
> >>>> Martin: I think the two solutions are not too different and I think
> >>>> it's a matter of getting the XML model right first. Then the binary
> >>>> part will come afterwards. I think two RFCs is a bad idea.
> >>>> Dorothy: Sure, but the binary representation is very important. We
> >>>> should be able to sort this out offline.
> >>>> James Winterbottom (remotely): How does a device obtain this location
> >>>> from a LIS, as it should be able to do that.
> >>>> Martin: Basically this is asking whether the location offset is
> >>>> spceific to the location. Well, yes it is. It would not be useful in
> >>>> another context. Perhaps we have to define an inner and an outer
> >>>> offset (perhaps for emergency service use).
> >>>> Alissa: But if you receive more detailed information, which you don't
> >>>> understand; I think you can ignore it.
> >>>> Marc (remotely): You wouldn't send all the offset information to a
> >>>> LIS
> >>>> server. There is product and running code based on the earlier work.
> >>>> Richard: But I don't think that will change the XML to binary
> >>>> conversion
> >>>> Brain (remotely): I think we need 1 solution on this. I don't think
> >>>> the compact biary requirement is not a bit issue. I think we should
> >>>> be
> >>>> able to compromise quite easily.
> >>>>
> >>>> Geodetic Datum to Civic address - Robins George
> >>>> -----------------------------------------------
> >>>>
> >>>> Alissa: how many people have read the draft: about 5
> >>>>
> >>>> Martin: I'm not sure that this is right place to put it. I like the
> >>>> concept. Geo-coding is quite useful, but location requests in HELD is
> >>>> not the best place. Perhaps a new request or even a new protocol
> >>>> should be created. Let's look at what people are using out there.
> >>>> Discovery of geo services would also be usful. It could also go into
> >>>> LoST. LoST needs an extension to provide this reverse look up
> >>>> mechanism. Therefore the draft needs some more thought.
> >>>> Roger: I like this document and its a good idea. In an emeregency
> >>>> context, PSAPs don't have a exchange protocol to communicate with
> >>>> each
> >>>> other. Something based on LoST is perhaps the way to go.
> >>>> Robins: But I thought the WG said, don't geo-code in LoST
> >>>> Martin: Yes, so perhaps another protocol needs to be found.
> >>>> Brian (remotely): Yes, I agree, but this should be a new protocol.
> >>>> it
> >>>> may have some good uses within NENA.
> >>>> Richard: Ok, so please can we have some more discussion on the list.
> >>>>
> >>>> -policy-url - Richard Barnes
> >>>> ----------------------------
> >>>>
> >>>> LbyR (location by reference)
> >>>>
> >>>> Hannes: In the intiial HELD submissions, there was some text about
> >>>> policy. But how do you apply the policy. You need to authenticate and
> >>>> then use the LIS itself. Even today, it is not solved correctly.
> >>>> Within the DHCP document, James Polk wrote another mechanism to do
> >>>> this. The HELD approach is still rather heavyweight.
> >>>>
> >>>> Richard: You might want to upload some geographic information, which
> >>>> does not contain any identity information.
> >>>>
> >>>> Hannes: But many location service servers need some understanding of
> >>>> identity. Not everyone has certificates? In addition, these policies
> >>>> are quite complicated. There are some overlaps with the HELD policy
> >>>> document, but it's still not clear.
> >>>>
> >>>> Martin: I don't think this is deployable. I don't see why is it
> >>>> required. You establish a policy in one place and then you don't
> >>>> worry
> >>>> about the local access provider. Perhaps we just need the ability to
> >>>> invalidate the refernce.
> >>>>
> >>>> Jon Peterson: If I get a location and then give it to someone else,
> >>>> then this may be appropraite.
> >>>>
> >>>> Martin: You say, here's my policy. What happens when the IP address
> >>>> is
> >>>> re-allocated to someone else. This can be a real mess. Regarding
> >>>> JOn's question, can we fallback to location based authentication, but
> >>>> I'm not sure.
> >>>>
> >>>> ===
> >>>>
> >>>> AoB
> >>>> ---
> >>>>
> >>>> Martin: Can I also have comments on the list about -immediate- publish,
> >>>> which may have some relevance here.
> >>>>
> >>>> _______________________________________________
> >>>> Geopriv mailing list
> >>>> Geopriv@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
