>+1
>
>(Please note that there is also an updated draft that addresses various
>issues raised in the review that I quickly addressed.)
please note that I did say I was pleased that some of the comments
were taken well by the authors, and even resulted in some clarifying
or improved text be added to the ID.
I didn't bash what you said, I just wanted to make sure each of the
comments were addressed in this final WGLC (before it gets thrown
over the wall to the IESG).
James
BTW -- Keith's holding me accountable for each of the comments you
(or anyone else that's) made on Location Conveyance using a
spreadsheet, not just my confirmation that they are addressed.
> >-----Original Message-----
> >From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On Behalf Of Richard Barnes
> >Sent: 12 November, 2009 18:24
> >To: James M. Polk
> >Cc: geopriv@ietf.org
> >Subject: Re: [Geopriv] Draft GEOPRIV notes for IETF 76
> >
> >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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
