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
