Minutes - GEOPRIV - IETF73 Summary (prepared by Richard Barnes): 1. Retransmission issues in SIP location conveyance draft-ietf-geopriv-sip-lo-retransmission-01 Jon Peterson led a discussion of open issues with this draft. The group reached consensus on the two remaining issues in this draft: Syntax and B2BUAs. First, there was agreement that the document is clear enough that the provided syntax is an example and not binding on the SIP WG. Second, there was consensus that (1) the WG should provide guidance for B2BUAs and (2) the spirit of the current guidance is correct. Brian Rosen will submit revised text for the B2BUA section. 2. HTTP-Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-10 Mary Barnes gave an update on recent changes. There was discussion of decoupling LIS discovery and HELD. Mary will produce a new draft addressing AD comments before the end of the year. Eric Rescorla will review the document again for security concerns. 3. LIS Discovery draft-ietf-geopriv-lis-discovery-04 Martin Thomson presented an update on this document, highlighting two open issues: URI schemes and discovery mechanisms. The group reaffirmed its consensus on using HTTP/HTTPS URIs. Several participants who expressed a preference for a new scheme noted that they are ok moving forward with this decision. Martin proposed removing everything but the DHCP-based discovery mechanism from the draft, based on comments from Peter Koch on the applicability of DNS for this problem. Richard Barnes suggested that the DNS-based solution might be salvageable. Discussion will continue on the list. 4. Civic Address Recommendations draft-ietf-geopriv-civic-address-recommendations-00 Alex Mayrhofer gave an update on this new WG document. Several participants spoke in favor of this document. Hannes Tschofenig noted that he is working with EENA to produce similar standards for European nations. Brian Rosen and Richard Barnes proposed creating an IANA registry for jurisdiction-specific usages of the civic address XML structure. 5. Location Update Filtering draft-ietf-geopriv-loc-filters-03 Brian Rosen gave an update on this document. Martin Thomson noted that the "location delta" format needs work. Brian noted that a generic "element changed" filter would be useful, but he can't commit to creating it. Brian will produce a new version, addressing Martin's comments and aligning with RFC 4661 updates. 6. 3693 Update draft-barnes-geopriv-lo-sec-03.txt This agenda item was dropped in the interest of leaving time for later presentations. 7. Cross-area feedback on identifiers http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html draft-winterbottom-geopriv-held-identity-extensions-07 This agenda item was moved to the end of the meeting during the agenda bash, and was dropped due to insufficient time, and because the relevant people from other areas were unavailable. 8. Third party access to location information draft-winterbottom-geopriv-held-identity-extensions-07 draft-linsner-geopriv-obo-00 Jon Peterson led a discussion on the question of whether GEOPRIV should develop mechanisms to support requests for location in which neither the Location Recipient nor the Location Server is the Target. There was strong consensus in the room that it is important to support request for location by third parties, keeping in mind that such transactions included a role for a Rule Maker. Several participants presented motivating use cases, and no objections were raised. Raw notes from Richard Barnes, Ben Campbell, John Elwell, and Roger Marshall follow: ------------------------------------------------------------ GEOPRIV at IETF73, Tuesday, 19 Nov 2008 ===== Administrivia ===== -- Agenda bash: -- cross-area feedback moved to the end to minimize conflict with idnabis -- periodic-location if we have time at the end -- Status update -- WGLC on lbyr after thanksgiving -- lbyr needs discussion between polk/martin -- W3C update -- Martin: SIMPLE continuous presence doc ===== Retransmission ===== -- Syntax issues ** Use of header field allows prefs without location -- Polk: Maybe provide alternative examples and contrast (?) -- Hardie: We should make semantics clearer so that SIP can use to compare alternatives -- Rosen: We shouldn't hold this document up on this; we can't do syntax anyway -- HUM: Is the document clear that the syntax is an example? -- Several in favor -- None against -- B2BUA issues -- Peterson: Tried to clarify implications of decisions by B2BUAs -- Rosen: Don't think the current draft does this; I'll send text -- Hardie: Trying to help people understand how to apply GEOPRIV principles -- Kaplan: Agrees that you should tell B2BUAs what to do; put in a MUST -- Sparks: Also need to handle the case where SIP calls transit the PSTN -- MBarnes: This text is important, but this discussion should be in SIP -- Hardie: This is still just advice from one WG to another -- Jennings(AD hat): Need to get these docs done -- Drage: SIP can't really deal with B2BUAs either -- Polk: S3.6 does have text for -conveyance. -- HUM: Does the WG believe that this document should contain a consensus opinion from this group on how B2BUAs should behave? -- Strong in favor -- Weak against -- HUM: Do you think the current document captures WG consensus on how B2BUAs should behave with respect to location retransmission? -- (postponed) -- HUM: Do you think that the spirit of the recommendation captures what we believe is right and that we're down to wordsmithing? -- Weak/med in favor -- None against -- ACTION: Brian Rosen to provide updated text -- ACTION: Hardie will produce a new version this week if Brian produces text this week ===== HELD ===== -- URIs -- Sparks: Proposal to use HTTP URIs with a "be careful" in the security considerations -- Thomson: What problem are you trying to solve by proposing this change? -- Trying to decouple discovery and HELD -- Hannes: Thought for a long time that we should decouple discovery and HELD -- Changing validity interval recommendation "several minutes"=>30min -- Removing reference to RFC 3704 -- ACTION: Re-review from Ekr -- ACTION: New draft before the end of the year ===== LIS-discovery ===== -- URIs -- Pretty strong consensus to use HTTP/HTTPS, not a new scheme -- Discovery mechanisms -- Rosen: DHCP OK. Question: What is the use case for not DHCP, but yes DNS? -- MT: Part of the reason we're doing an L7LCP is that DHCP loc didn't work for a lot of people -- DSL networks (PPPoE config, etc) -- Rosen: But those guys don't have DHCP anyway! -- Nope, there are non-DHCP options -- Question: Is there push-back on the DHCP part of this draft? -- Sparks: No push-back; need to check with DHC; maybe add cert fingerprint? -- DNS-based discovery: -- Koch: arguments against from the DNS perspective -- Barnes: Should look at assumptions -- Martin: Inclined to remove this / separate document -- ACTION: Work this out on the list ===== Civic Addresses ===== -- Discussion -- Rosen: Really like this doc. Really need to recruit other countries to do the same thing. I'll do the US. -- Hannes: Working with EENA to do this for European countries. -- Rosen / RBarnes: Let's create a registry, allow multiple per country, tag civic addresses with which format -- Cullen(AD hat): Don't foresee any IESG problems with making a registry ===== loc-filters ===== -- Thomson: Another aspect that might need work is the "location-delta" format. ===== lo-sec ===== -- Bashed off the agenda ===== Third-party requests ===== -- Norreys: We would have trouble without authorization from the endpoint -- Peterson: User is still causing/enabling the LBS to make the request -- Norreys: With that caveat, this could be useful -- Peterson: Do you think this could be a plausible use case? -- Norreys: There are probably 3rd-party services that would want it, need authorization -- Polk: Concerned that endpoint might not know when/how his location is being revealed -- Peterson: Absolutely want to have a rule maker, but it's easy to miss how that role fits in -- Thomson: The mapping to 3693 seems pretty clear here; we need to tackle this problem -- Peterson: This is the concern that Morris raised, that we'll become irrelevant -- Erik Burger: The chip in my dog is a Target with no UI. Need to support positioning this too. -- Matt: This will happen, we can only help add privacy stuff -- Hardie: Is there some difference from 3693 that I'm not getting? -- Peterson: What's different is that it's LIS instead of LG -- Hardie: So there's an RM-PS interaction? Need to create a rule referenced by the seeker -- Hardie: Need to include the identifier in security/privacy boundary -- Linsner: identity-extensions removes requirements/motivation in recent draft -- Peterson: Do you object to what's being said here? -- Linsner: Object to getting rid of the Rule Maker -- Hannes: We've been talking past each other; this diagram captures it nicely; doc should be clearer -- RM relationship might be done contractually as well. -- Thomson: I'll add motivation to the document to respond to Marc's suggestion -- The way rules get to the LIS can be out-of-band -- Gellens: This is kind of different, since there are different rules at the LIS and the LS -- Peterson: Sure, the reason we need weird ID considerations is that the LIS doesn't really get policy -- Polk: Strongly believe that the LIS is the LG in the 3693 sense -- Alissa: Seems like the motivation almost accomodates requests against the Target's wishes -- Peterson: There are cases like that (non-Target RMs) -- Linsner: Problem with the current document is that when RM is brought into the doc it's not sincere -- Peterson: Undoubtedly, the document is imperfect, but if we can agree this is a good case, we can fix the doc -- Thomson: Alissa's concerns can be alleviated if the Target acts as RM; remember that LIS is an LG and an LS -- Peterson: Sure, just different policies and provisioning mechanisms. -- Hardie: In many cases, the target will not be the RM ** Conclusion: Strong agreement that this is an important use case to consider ------------------------------------------------------------ GEOPRIV - IETF73 - Tuesday 0900-1130 Welcome Richard as a co-chair 10m Administrivia/Status Agenda bash - Ted requests that we swap last two items due to schedule constraints. Mary asks for feedback on a wimax related draft. During update - missed dhcp-lbr status. James believes its basically done, but there are some comments that may have impact on draft. Martin - draft in simple about how to put location in presence. Please participate. Martin will send pointer to document. 40m Finalize any outstanding conversations on sip-lo-retransmission (Jon Peterson) http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.txt 2 major changes. Separate semantics from syntax. Offer possible syntax, but let SIP work out details. Soften b2bua language--can't compel b2bua's, but we can show consequences of behavior. Discussion: First point: Keith: is the parameter a header-field or URI parameter. Answer: We're not defining that, but example uses a parameter of geolocation header. Using a header allows some additional expression beyond a header parameter James Polk: Geolocation header is not named in draft. Suggests adding "for instance" example showing it in a header vs a parameter. Response: We're still working out how concrete to be for this. There is a slight semantic difference between the two--open issue as to whether we want to couple geolocation routing to the geolocation header. Ted: We can have the same semantics if we modify geolocation header to allow null location values. Ted: SIP has sent this back to geopriv due to lack of geopriv agreement on semantics. If we can express the semantics, we are good to go. We should give example syntax that expresses the semantics. SIP can change that if they want. We need to get them something soon. Brian: Don't hold up the document for this. James: Draft is not clear that the syntax is exemplary, not prescriptive--do others agree? *** Hum: Is the draft clear on this point? Results: Several hums for, zero against. Keith: Is there a requirement to be able to send location routing policy without location information? No, the requirement is that the rule maker must be able to associate policy with location. Separating the two is one way to accomplish that. Discussion about SIP wanting this draft complete before moving forward. JFP is concerned about the layer of indirection. James states he is satisfied with hum on syntax examples. 2nd point: B2BUA language was too prescriptive. We can't force rules on B2BUAs, but we can show design tradeoffs. This was the intent of new text--did we succeed? Brian: Doesn't think we succeeded. Given language does not tell when you should or shouldn't worry about it. But people who count won't pay attention to it--prefers to delete it. If we can't delete it, Brian will send text. JFP would love to delete it. James: Confused by a discussion from Robert that the b2bua discussion is about gateways. JFP: It's about b2bua's, not specifically gateways. Ted: You have to understand geopriv principles as a whole applies to this other system. We write this down to help us understand how actors in SIP networks can apply these principles. If b2bua implementers won't listen, it doesn't do harm, but there may be value keeping it to help us with this understanding. If we rip it out, we remove part of the explanation of the geopriv system. Hadriel: Even if they won't listen, you should still tell them what to do. Wants stronger (normative?) language. JFP: Does existing language persuade? Hadriel wants some MUSTs. JFP: Important distinction--this is to instruct SIP, not final implementers. SIP can handle the normative stuff. Real Robert Sparks: (refer back to gateway conversation). The idea of crossing a pair of PSTN gateways is helpful for illustrating b2bua issues. It may be possible for the gateways to carry location. If this is true, then any b2bua discussions must be able to handle that scenario, and it makes a good model for discussion. Mary: This debate belongs in SIP. The b2bua guidance does not belong in this document. Ted: Unless SIP decides to take on b2bua's, we should not expect SIP to offer more guidance for this than for any other header. If geopriv has opinions here, it should express them. Cullen: (as AD) balance this with getting the document done quickly, and allowing SIP to get a document out quickly. James: Believes 3.6 has text implications on location conveyance. He's Not sure if he understands how to account for the double-gateway model for b2bua's in location conveyance. JFP: Does that draft discuss b2buas? (no) Keith: The only b2bua that SIP can talk about is a concrete pair of UAs in a single box--not the protocol between the UAs. (Room does not seem to agree) JFP: Lets focus the discussion on whether geopriv support on whether the language in the document is a reasonable recommendation in general. *** Hum: Does the wg believe that this document should contain a consensus opinion from this group on b2bua behavior. results: Strong hum for yes, only a couple for no. *** Hum: Do you think the spirit of the existing text is on the right track and we are down to wordsmithing? results: yes JFP: So now it's all down to Brian :-) Robert -- what's the time pressure on this? Is someone desperately waiting on this? Ted: Ted's bowels are desperately waiting on this! Conclusion: Brian will offer text on list, Ted to incorporate. 05m Update/discussion on http-location-delivery (Mary Barnes) http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10.txt version 09 Several changes from LC review. version 10 - addressed concerns about lack of URI schema registration and SOCKS recommendations. Primary open issue: URI schema for URI from LIS discovery. section 4 references the LIS discovery doc, but does not scope the applicability of URI schema types. Need to add text to qualify the requirements for a URI that is returned from LIS discovery. Robert: Possible way forward to avoid blocking on LIS discovery.--base doc just says use an HTTP URI. Security consideration says only use an HTTP URI from a trusted source--maybe with an attached lawyer. Point _informationally_ to LIS discovery as a way that might help you do this. EKR: Current version not insane. Still confused about the relation between this URI and the HTTPS binding. Martin Thompson: Doesn't know what problem RjS wants to solve. (To remove LIS discovery as a normative dependency.) Martin thinks we can get LIS discovery done. Suggest leave the dependency until we decide there is a problem with LIS discovery. Conclusion: Defer issue discussion to list Brief presentation of several issues, no discussion. Issue: Specific range for frequency of location requests. Currently "several minutes" Propose change to >2 and <10 minutes Martin: Several minutes is okay for now, we can specify later. Can make recommendations for by-ref but not for by-val. If by-ref, we can make a concrete recommendation. In US we keep state for 30 minutes for emergency calls. Recommend "at least 30 min". *** Conclusion: Change to "at least 30 minutes." Be more explicit that this is the time after which a by-ref URI expires. Take details to list. Issue: both get and post. Get rid of get. *** conclusion: remove Get Issue: Use of 3704 to avoid IP addr spoofing. Do we need this? Propose to remove bullet 2 in section 9.3. *** Conclusion: remove bullet 2. Next steps: Update doc, version 11 expected to be ready for publication. Need's a re-review from EKR. Cullen: Tim said he was okay with the direction. 40m lis-discovery (Martin Thomson) http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt Open Issue not on slides: DNS issues, defer to end. ISSUE: URI Scheme. Option to have a "held" scheme. Proposal to use HTTP/HTTPS URIs only. LCP URI must be a product of discovery. Discovery provides necessary context to determine the URI purpose. Text to this effect in the draft. Hannes: We've gotten contradictory advice from apps area on this. Wants to express to apps area to please offer consistent advice. Cullen (individual) - supports proposal. Either approach could work--moving forward is the important thing. Ted: +1 Richard: His resistance to this approach is less strong than before. Given robert's suggested text about being careful about the URIs you use, this is okay. Randall Gellens: Slide does not list any advantages for the HTTP/HTTPS approach. Advantage is that you don't have to mint a new URI scheme. (Randall: But URI minting is on special for rest of year :-) ) Issue: General DNS use. If DHCP does not give you the information you need, there's some tricks to get to a domain name. If that doesn't work, there's a DNS NAPTR procedure to try to get to a domain name. Brian: Why is there a need for more than one mechanism? Isn't DHCP enough? Martin: A lot of people cannot pass this info through to end devices via DHCP. Example, DLS networks where box is configured via PPP or statically. Martin: Before discussing DNS, are their concerns with DHCP parts? Robert - DHCP is okay in general. Got some security advice to also include a finger print for LIS server in the DHCP data. Martin is not sure how that would be useful. Needs more discussion. Martin: Comments on DNS have indicated what is in the draft won't work. Hannes proposed removing DNS parts. Unfortunately there would be networks where discovery would not be possible. Option: REmove DNS from this draft--document that there would be situations where no discovery would be possible. Hannes: Suggests re-looking at a mechanism that we discarded previously. (e.g. IP anycast.) Chair question: Is there a requirement in this doc for devices with static IP configuration to be able to discover the LIS. Brian: Yes, but that would be via static configuration of the LIS. Martin: Is anyone not comfortable progressing without the DNS parts. Mary: Agrees. We need to avoid wiggle-words here. This is close enough for basic functionality. Question: Were there comments that the DNS approach technically wouldn't work, or was it just impractical? Peter (Koch?): DNSSEC would not due what the draft assumed. Also, idea of "being in a domain" is flawed. DNS publishes info about a domain, but not to a particular target audience. Reverse mapping is risky. *** suggested Conclusion: Probably will remove DNS, but need to take to list and confirm with absent stakeholders. Richard: Thinks there might be something salvageable in the DNS mechanisms. Will take to list. Robert: We could always work on DNS mechanisms in the future. EKR: Jabber room comment is concerned about partial solution. *** Conlusion: Need to take to list. 05m civic-address-recommendations (Alex Mayrhofer) http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-00.txt This is now a WG item. Just one recent review (Martin Thomson ) Intended as a "cook book" for mapping civic addresses into pidf-lo. Options for elements that can be mapped unambiguously. Guidelines for elements that don't directly map. Define which elements must be used, can be ommitted, or must not be used in a country. Example mapping for Austria. Questions: Is this useful? Can we recruit people to do mappings for other countries? Brian: Great doc--need to incent people to provide other example mappings. ***Brian will create one for US, based on NENA specs.*** Issue: What do we do with country examples? Hannes: Work with [missed] to do this for all European countries. Hannes: Document lacks motivation on why this is important for emergency services case. That is the case with the most precise requirements. Document could be shorter. Hannes will post a couple of questions on the Austria example to list. Martin: Doc is useful, how can we get it published? Author: It's hard to get anyone in an official capacity to "acknowledge" this and give feedback. Open question about whether the country examples are "normative" or "informative". Robert: We anticipated WGLC on this shortly after publication. WGLC expected in December time frame. Brian: Do we want 300 RFCs, one for each country? Maybe a registry? Suggests a registry that allows multiple entries per country to get around question about who is authoritative for a given country. (probably expert review required.) Suggestion to create template for country considerations. Maybe use the austria example as a template. Cullen (AD) - Cullen does not expect problems with creating a registry. 05m status check on loc-filters (Brian Rosen) http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt Presented status. Review comments (from Martin) listed in slides. Issue: Generalized "change in value" filter mechanism. Brian thinks this is a good idea, but cannot commit to doing it. If someone else wants to do it, Brian will be happy to use it. Martin: Location delta format needs generalization (marking _why_ you got a notification), and should be removed from this draft. Generalize to be generally useful for SIP/SIMPLE. Brian: Willing to use a generalized mechanism if it exists, but doesn't want to take it out of this doc until there is something to reference. Martin: Will discuss this in issue. Next steps: Rev with 4661 changes, comment changes. 05m status check on lo-sec/3963 update (Richard Barnes) http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt (Note: this draft has not been updated since before Dublin) *** bashed out of agenda due to schedule constraints. *** 20m discuss cross-area feedback on identifiers (Ted Hardie) http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt *** not discussed, out of time, principle not in room. *** 20m 3rd party access to location information (Jon Peterson) This will be the next steps in making progress on discussing if/how we facilitate 3rd party access to location information. No draft. Slides presented. Trying to determine if geopriv should take this on. Use cases: -- Endpoint lacks capability to acquire or publish location to the service. -- Access network policy prohibits giving location to endpoint, but will give it to third party services. Example architecture shows a network service that queries LIS on behalf of endpoint. [Steve, from a phone company] - could not do this unless the endpoint can explicitly express consent to allow this. James: This is fine for location of non-IP devices. Concern with ability of target not to know their location was revealed. What if location service is not a trusted agent? (JFP assumes it must be a trusted agent. Must be clear that there is a rule maker.) Martin: We must deal with these cases or become irrelevant. Eric Brunner-Williams: USE case: tracking chip in service animal, no UI. Matt Levinsky: People will do this--we need to describe how to do this safely. Ted: Is there a change here from 3693? Questions of how rule maker interacts with presence service. How does it create an identifier that can be referenced by seeker? What are the security/privacy implications? Mark [Lisner?]: Held-07 removes all requirements and motivation for 3rd party. Hannes: Some emergency services cases involve people planning to use 3rd party access, at least for transition periods. These are not just academic use cases. Discussion generally in favor of working on this. Randy: The presence server and the LIS may have different rule sets. Alissa Cooper - There may be cases where the target does not want to manage their location privacy, through lack of knowledge, et. Mark Lisner - If we really care about the rule maker, we need more guidance on how to push policy to xcap service, etc. [out of time...] Ted: Many cases, the target will _not_ be the rulemaker. ------------------------------------------------------------ GEOPRIV - IETF73 - Tuesday 0900-1130 10m Administrivia/Status Richard Barnes welcomed as new co-chair. Mary Barnes asked people to read her draft ????, so that she can provide feedback to WiMAX people. Preference expressed for doing lbyr-requirements WGLC after Thanksgiving rather than before. Dhcp-lbyr was posted to list, basically done, some comments (impact to be worked out, but more philosophical). Near end of life cycle, so pay attention to it. Richard reported on liaison with W3C, and liaison statement is being prepared along with other chairs. Get in touch if you want more information or wish to help. Announcement of discussion in SIMPLE later in week on location in presence. 40m Finalize any outstanding conversations on sip-lo-retransmission (Jon Peterson) http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.t xt Keith: asked for clarification on parameter - Jon thinks it is header parameter, but we are only giving guidance to SIP as to possible meanings - up to SIP. With header appearing without Geolocation header, you can express something you can't express with parameter to Geolocation header. Ted: So can express policy even though don't have a location (a downstream entity could add it). James: Difference in writing style between James and Jon, and James would have expressed it differently. Jon: don't want to give examples, just principles. James: I can express every piece of semantic needed as header parameters. Ted: I agree with statement as currently expressed, although an alternative would be to allow an empty Geolocation header. So it is important to have a syntax in here that we agree would work, and this can be passed to SIP for them to see whether it is acceptable or whether they need to find an alternative but equivalent syntax. Need to give a clear message to SIP so that SIP can do its work, but not in terms of syntax, just in terms of what we need to happen. Brian: We have got all we need to get out of this, and should not hold things up by prolonging this discussion. James: Don't want to hold it up, but wants to leave meeting with clear interpretation. Hum to say if draft is clear enough as is. Quite a few for - didn't hear any against. Keith: Wants clarification that there is a requirement to be able to send from user indication about policy. Jon: Not necessarily the user, but could be the rule-maker. Mary: Support Keith, needs to be well-cooked. Chair: Point of draft is to capture semantics, and hum indicated we have captured the semantics. James: At this point I am satisfied. Jon: Concerning point about B2BUAs, we can't compel B2BUAs to do anything, but we can explain the design trade-offs. Brian: Not satisfied that the text gives advice. In fact I think we could get rid of it. Prepared to send text if we decide to keep it. Jon, yes, please send text. James: Confused about a suggestion that this is about gateways. Jon: This is purely about B2BUAs. Ted: Reason text is there is that you need to understand the GEOPRIV principles as a whole. Rip it out if it isn't helpful, but I think it is helpful and doesn't harm to keep it in. So before ripping it out we should understand the consequences, i.e., that we think B2BUAs don't need to understand GEOPRIV. Hadriel: Agree with statement that you should tell them what to do, even mandate it. Of course, they won't always do it, but then we can't be responsible for operation of the service. Jon: Does what we have in there persuade? Hadriel: Yes. Jon: In any case, this is not the document that designers will design to - that is for SIP to produce. Robert: Explained where gateway came from, i.e., from point of view of endpoint and e2e operation, which might cross a PSTN hop. So if there is merit in having a recommendation on B2BUAs, it should also address that case (B2B gateways). Mary: Real text has to be done in SIP. Ted: Need to stay in this document, even though SIP may or may not do work on B2BUAs in future. Cullen (as AD): Wants to balance Mary's concern against getting the document done quickly. So do whatever we need to do to get this document out quickly and across to SIP. Jon: Agree that primary purpose of document is more the first rather than the second bullet (B2BUAs). James: Can work with Brian on existing 3.6, but not sure how can apply it to the PSTN hop case. Ted: You are ahead of where we are. Need a hum on the second point. Chair: Wait for line. Keith: You basically want a B2BUA to behave as a proxy. As soon as you get to an intervening PSTN hop you are outside the scope of SIP. James: Confused, because I am the person has to put text into conveyance draft, particularly in case of a gateway. Comment on B2BUAs has been taken out. Jon: Can we determine whether room supports making this kind of recommendation. James: Want to know whether this group wants to recommend to SIP that in conveyance it should address this scenario. Chair. I will call the hum. Does WG believe that this document should contain a consensus opinion from this WG on how B2BUAs should behave. Conclusive in favour. Second hum: Does current document capture WG consensus on how B2BUAS should behave w.r.t. location retransmission. No response either way. Ted: Should instead ask whether advice we are giving is the right advice. Keith: Wants to get rid of "note" from B2BUA text. Also pointed out that SIP WG can implement in its protocol only about 30% of the recommendation, and rest would need to be done elsewhere. Chair: Is the spirit of the recommendation right, i.e., text basically on right track Hum if you believe we are on right track and just need to wordsmith. Nobody hummed against. Ted: If I receive the text this week you will get an updated draft this week. Chair: What is urgency for WGLC on this. Ted: Very urgent. Rosen: Conveyance is waiting on this, lets get both documents out and then phonebcp. 05m Update/discussion on http-location-delivery (Mary Barnes) http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10. txt Primary open issue on URI schema for URI from LIS discovery. Will add text to qualify requirements. Chair: Want a feeling from group whether essence of document (i.e. use an HTTP URI) is correct. Explained boundary between this document and LIS-discovery, so that this document can proceed withouth waiting for LIS-discovery. Mary: LIS-discovery has been a requirement all along, and thought we could cover this. EKR: Didn't catch question: Mary: Will get to that. Martin: Don't know what problem you will solve by proposing this change. Don't think this is a contentious part of draft and shouldn't hold it up. Hannes: Originally proposed to split discovery, so just ????? Mary: Let's defer to list. Additional comments on slides. Martin: On point 3, nothing much we can do to specify a concrete number. Given that it is for lbyr, can make a concrete recommendation. 30 minutes. Agreed 30 minutes would be added. Randy: But slide says frequency, discussion was on lifetime. Martin: The two are related. Randy: Too frequent can involve overloading of resources. Mary: Need more specific text. Will be taken to list. Bullet 2 in 9.3 will be removed. Mary will update the document once mailing list discussion concludes. Should be ready for progressing. 40m lis-discovery (Martin Thomson) http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt Open issue not on slides is with DNS methods. Cover this last. Issue of whether to have HELD URI scheme or just have HTTP/HTTPS URIs. If you get one of these HELD URIs, it would be through the discovery process. Proposal is to stick to what is in draft (HTTP/HTTPS). Hannes: Made one decision in ECRIT (having involved Apps Area), so concerned about making a different decision in GEOPRIV. Cullen (as individual). Support Martin's proposal. Any could work, and had slight preference for a new scheme, in interest of progress let's stick to what we have. Ted: Let's just get on with it. Richard: Arguments are captured accurately, but given the text the present proposal is OK. Randy: Concerned that we don't say why the chosen option is better. Ted: It is simply that you don't have to invent a new URI scheme. Martin: The DNS part will be contentious. Chair: Who read it, and who studied it in detail - sufficient. Biran: Good idea to have a DNS option, but what is the nature of the domain that has a LIS and doesn't provide the DHCP option, so why do we need other options. Martin: No DHCP. Brian: Will read it again. Martin: Not hearing any concerns with DHCP aspects, so before we move on, are there any? Robert: No, although suggestion of containing fingerprint of server for security purposes. Martin: Don't see what this buys you. Discuss later. Martin: Moving on to DNS, Hannes has proposed this be removed, but this would leave networks where you can't discover the LIS. If remove from this draft (and do elsewhere), would people be comfortable? Hannes: I had proposed that we look at some other mechanism, so advance this just with DHCP option, and then look at other options. Chair: Meta question: Do we have a requirement for this document to cover devices with static IP configured to discover LIS. Brian: Yes, but can statically configure LIS. Martin: Are we comfortable with taking this document without the DNS component? Mary: This would be a good thing. Mark: IMO the DNS solution is more theoretical than practical. Peter: Didn't understand what it wanted from DNSSEC - feared it wanted something that DNSSEC won't give you. Also the concept of "being in a domain" is somewhat flawed. DNS is not a service discovery mechanism, but there are other things that do this. Reverse mapping risky. Too much heuristic that you can't really rely on. Martin: That is a pretty good summary of problems we have. Fine with feedback. Suggestion of Hannes to cut the DNS stuff seems to be the way to go. Chair: This needs to be confirmed on list. Richard: There may be something that can be salvaged, but will discuss on list. Chair: If we drop it, does this preclude picking up another option in future? Answer seems to be no. 05m civic-address-recommendations (Alex Mayrhofer) http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendati ons-00.txt Brian: Really likes the document, and need to recruit people from other countries to add their input. Will help a lot of implementers. I will create one from US from NENA's specs. Alex: So what do we do if we end up with 100s of these? Hannes: Will work with ENA for European countries. I have many detailed comments, but lacks a clear articulation of why precise information is needed for emergency services reasons. Perhaps document could be shorter. Will post to list. Martin: What do we need to do to get this document published? It is very useful. Hannes suggestion good. What else of substance to do before WGLC. Alex: Would appreciate feedback on recommendations. Chair: We anticipated that once we got charter item we would WGLC it, so December/January timeframe. Brian: To ADs: Do we want 300 RFCs for 300 countries? Perhaps a registry is the way to go, with Expert Review required. Document would keep Austria, but only as an example. Also ought to allow multiple entries for countries where we don't get an authoritative input. Richard: Registry is a good idea. Roger Marshal. Document excellent. Not clear where "consideration" was already in this document, or needs to be in the 300 country-specific documents or registry entries. Cullen as AD: Don't see a problem with registry. 05m status check on loc-filters (Brian Rosen) http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt Martin: May need work on location delta format. Should reference another draft. Brian: Won't take it out until there is something to reference. 05m status check on lo-sec/3963 update (Richard Barnes) http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt (Note: this draft has not been updated since before Dublin) Removed from agenda. 20m discuss cross-area feedback on identifiers (Ted Hardie) http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte nsions-07.txt 20m 3rd party access to location information (Jon Peterson) This will be the next steps in making progress on discussing if/how we facilitate 3rd party access to location information. Please be familiar with at least the following inputs: http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte nsions-07.txt http://tools.ietf.org/html/draft-linsner-geopriv-obo-00.txt Wants a discussion whether these third party considerations are within scope of the WG. Steve Norreys: We as operator would have a problem doing this unless the phone user has given his permission. Jon: There has to be a way for the user to say go ahead and get that. Steve: If this caveat is put in, this would be useful. Could even be third party services, not part of operator's network, but permission is all important. James: Location seeker can ask PS where a device is, but ???? Didn't follow the argument here???? Martin: Concerns with previous iterations of document distract from things, but from the picture on the slide it is very clear, we do have the discussion there (and people should say if we don't). Dealing with this problem is relevant, and if we don't people will do this anyway. ????: Interested in UI-limited devices. ????: People are going to deploy things like in the picture, if we don't tell them how to respect privacy they will do it wrong. Ted: We have 2 aspects: how rule-maker interacts with PS, and that it needs to be aware of identifier. Need an update of 3693 to include the privacy indicator. Richard: This is some discussion in draft update of the document. Mark: held-identity-o7 removes all mention of 3rd party. Need to identify motivation and requirement. Jon: Do you object to what we have here? Mark: I object to removing the rule-maker. Hannes: This is something real and picture captures it well. Document needs to be stronger on capturing notion of target and rule-maker. Martin: Will take Mark's suggestion as feedback. Jon: Anyone objects to addressing this use case? Nobody objected. Martin: Rule mechanism can come from a number of places, e.g., contract, subpoena, web page. Randy: Other configurations possible, e.g., presence service need not be LS. James: ???? Alice: Expressed as if this is against the target's wishes, but could be cases where the target wants this. Jon: Agreed. Mark: ???? Jon: We can fix what is in the document. Martin: Alice's concern can be fixed by saying target is the rule-maker. ------------------------------------------------------------ GEOPRIV - IETF73 – Tuesday, 11/18/2008, 0900-1130 (Central) 10m Administrivia/Status Robert: Announced Richard Barnes as co-chair to Geopriv Ted: Request to switch order of last two items on agenda (no chair decision) Mary: wrote a draft on periodic location updates based on requirements from WiMAX Forum (Robert: status on agenda items) James: No mention of DHCP-LbyR Robert: by mistake left off the agenda… James: Still need to work out some details with Martin Richard: Status update on [see Richard] Martin Thomson: request to get people to read a SIMPLE draft, which will send link to geopriv link. ---next 40m Finalize any outstanding conversations on sip-lo-retransmission (Jon Peterson) http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.txt Jon Peterson: (see slides) Differentiated (tried) syntax from semantics Comments? Brian: like to discuss B2BUA language Keith Drage: is this recommending header or parameter? Jon: changed to recommending neither – just explaining merits of each. Ted: (paints an example) James Polk: …believes that the geolocation header is named… maybe a difference in writing… I like to include examples… Jon: We pulled back on how concrete we want this to be. James: I believe that language that includes, “for instance…” is better. Do you agree with that approach? Jon: I don’t agree with that… the difference in the semantics is… [missed] Ted: I agree that you could modify the semantics of the geolocation header to be a , then insert later – and get where you are. Ted: I believer it is important to have some example syntax here, because at that point it is testable. Ted: Reality is that we need to do this for SIP to do its work – believe that we SIP can’t unless we include the syntax here. Brian: I think we’ve got all we need to get out of this. Don’t want to hold the document up. James: agree that I don’t want to hold it up, but want to leave this mtg. with a crystal clear understanding that this is what SIP needs. Robert: Would you like to take a hum now? Robert: (takes a hum) do you think that the present draft is clear enough – that the syntax is exemplary, not prescriptive. Some (low audible) Hums in favor, 0 hums against. Keith: to clarify, this draft says that it is possible to send a message without location… Jon: Mary: I agree with Keith that this topic has to be well-baked before it moves over to SIP. Jon: Robert: Point of the draft is capture the semantic *** Second bullet: Jon: B2BUA language softened Brian: will send text bcz I don’t think you’ve provided enough here Brian: am ok with getting rid of it Jon: would agree with getting rid of it James: I thought I’d come up with a decent way to address
… recounting conversation with Robert – “… it is about gateways…” James: Is this about gateways? Jon: This is about B2BUA’s Ted: (recounting …talking to Brian – you’re writing to someone who is not listening… ) trying to help others and ourselves to understand if geopriv principles to a B2BUA, then what would we see… …since they’re not listening, if we rip it out, then be aware… Hadriel Kaplan: Think you should have much stronger language directed to the B2BUAs – regardless of whether they listen. Thou SHALL, you MUST… unless you know better. Jon: what we try to do is “persuade”. Do you think what we have persuades? Hadriel: Jon: Again, what we’re trying to do is to tell a story… Hadriel: Robert: Want to explain where the gateway remark came from. Original language in the draft came from acting as an endpoint in SIP … scenario where from SIP into the PSTN – where it may be possible to carry location, but not policy – in cases like that, we need to specify Mary: If want to pull this out and place into another draft, then ok, but don’t want to see it in this document. Ted: Shouldn’t leave it out in expectation of something else to come. Leaving it out seem (to me) doesn’t seem to get to where we need to go. Jon: Cullen: (speaking w/AD hat on) another draft, not a quick work, so makes this critical for SIP, SIPPING, bcz of this, would rather see this done quickly – published soon. Not saying what the answer should be but that we need to get this document done soon. Jon: agree, and say that the B2BUA language may help – may not, but would say that… taking to areas more perilous… Jon: So where are we here? James: good with the Hum at the top James: don’t know what text Brian will send it… don’t know what I’ll have to do in SIP conveyance Ted: I think you’re further than where we currently are… Ted: I think we need a hum Ted: Suggest a Hum around text in section 3.6… Are we satisfied as a wg with this language Yes | No? Robert: wait…. Jon: would like to take a hum whether this doc is the right place to discuss Kieth: Basically, you’re stating that you want a B2BUA to follow the rules for a Proxy… Jon: no, not… Kieth: black box - Jon: white box… James: I’m confused… I think 3.6 has text implications, if B2BUA is an endpoint, or is a Jon: are the five letters B2BUA in there now? James: I think it is… Jon: ill-advised… Jon: I think we’ve gotten off-track… Jon: does geopriv support making this kind of recommendation…? James: Does this wg want to recommend to SIP, in conveyance Jon: Let’s not think about telling SIP what to do… Robert: I’m going to propose that we stop… Robert: does the wg believe should contain consensus opinion from this group on how B2BUAs should behave Hum loud in favor Hum lesser against Robert: Hum2) do you think current document correctly addresses how location conveyance should be done. (hum not taken) James: Ted: like to go ahead with your hum, but ask if this is the right advice? Kieth: like to get rid of the “note”… you can agree here, but SIP can only implement only about 30% of that reqmnt. Robert: what we’d like to get a read on… Do you believe the spirit of this document, that the text is on the right tract, or that we haven’t captured it yet. Hum – “are we on the right track, just need to wordsmith?” Hums (medium level, yes) Hum – “do you think we’re on the wrong track and need a separate doc?” Hum – no hum heard. Ted: if text can be received this week – I can turn this out this week. Robert: how fast do we need to move? Ted: (mentioned headache… need to get it done) Brian: conveyance is first to me, so then we can get phonebcp, etc. Jon: the power is yours, Mr. Rosen. ---next Mary Barnes – HELD 09 changes status Primary open issue – URI schema for URI from LIS Discovery Robert: suggestion to fix - just say "use an HTTP URI" here. Security would say you only take a HTTP URI that you get (along with a lawyer)... and that this document says nothing about LIS Discovery. Mary: LIS Discovery has been there as a requirement from day one. EKR: HTTPS binding may have two different uses, GET and POST Martin Thomson: listening to Robert’s suggestion, don’t know what problem your trying to solve… Mary: essentially LIS Discovery… Martin: only part that is controversial is DNS Hannes: Suggested splitting out from early on… Mary: let’s go on – HELD: Additional comments (slide) 1 - locationURI schema 2 - are both HTTPS and HTTP allowed? 3 – “several minutes” is not very specific Martin: don’t think there is anything else we can say… Mary: General, not specific to by-value Martin: if a URI, then we can make this Martin: in the States, (mobile), we keep state for at least 30 minutes. Randall Gellens: not sure what is being discussed, since the slide says period, but we’re talking about how long a location request is good for. Mary: or… the expiration of the locationURI Martin: are related…, not orthogonal Randy: Mary: taking this to the list. 4. Get rid of the GET? Leave only the POST? Good with you EKR? 5. Use of 3704 for preventing IP Address Spoofing. Cullen: not sure what this is… Richard Barnes: we get this through return-routability, so would be ok with removing this (bullet 2 from section 9.3) Hannes: agree with removal of this… Way Forward – HELD (slide) Request EKR to re-review Mary: …Ted left the room – would like to ask… Cullen: Ted mentioned as he was leaving room that he was ok with this. ---next Martin Thomas Martin: more has come up – so will add-lib Martin: DNS not included on slides – will have to discuss with Hannes… URI scheme (slide) Option: a held:uri (slide) You only have one of these URIs if you get it through a < > server (perhaps with a lawyer attached, as Ted said…) Martin: will suggest keeping only HTTP, HTTPS uris only Hannes: we agreed in Ecrit and it was fine, now in Geopriv and its not fine. Martin: it’s been a confusing issue, suggest a reset based on proposed. Cullen: I think I support your proposal, vague recounting some history Ted: I agree with Cullen, that inventing a new URI was ok, but is fine to drop it here. Richard: I’m going to disagree some with Ted and Cullen, but if you are careful with URIs used, think it may be ok. Martin: in dropping the GET, this will make it better, Randall: you list an advantage for doing one… but don’t say why the other is not good. Just curious. Ted: image the slide said (at bottom)… and you don’t have to go to the trouble of creating a new URI scheme. Martin: brief talk of way forward for this draft. Unfortunately, some stakeholders, not in the room – Robert: Who read this draft in study mode? (editor’s count, ~8-10) Robert: DHCP option – will require conversations with those DHCP folks… Robert: Who in the room is ready to comment on these 3 options. Brian: Why is there a need for more than one mechanism? Martin: down the road is RFC 3875 – DHCP won’t work for some people. Namely, the DSL folks, gets configuration through PPP, or manual configuration. Brian: If I’m not mistaken… all mechanisms imply that you started with something you get from DHCP… (Brian: will read it again) Martin: doesn’t seem to be a lot of push-back on the DHCP mechanism for this draft. Robert: EKR: why don’t you think this will be useful? Martin: not sure what it’s going to buy you. Robert: Martin: let’s move on to the DNS mechanism Martin: some believe this won’t work, Hannes believes that this mechanism be removed. Robert: …may have to try again… Martin: may need to remove from this draft – stating that this draft will not address all cases. Hannes: not only suggested removing, but also discussed IPAnycast Robert: Does Brian: document says static config is ok Martin: Is anyone against this moving forward Mary: close enough for Marc Linsner: a question, though agree that DNS approach is more theoretic, was there list traffic Peter _________: talked about DNSsec, talked about the gaps… DNS is used to publish information about a domain, not for a < >. Nervous about seeing DNS used as a generic discovery mechanism. Other this was seeing Reverse DNS mapping – can have multiple returned – risky. Too much heuristic that you can’t rely on – might not go to a reliable result. Martin: I think that’s a pretty good summary of the problems we have with DNS discovery. Richard: what’s the result of that Martin… Martin: I think Hannes suggestion is to cut is good. Need to check with the list (others) to see what the impacts might be. Richard: There may be some salvageable pieces. Useful to tease out what the assumption are. Robert: just to be sure that we don’t get into a place where we don’t want to be – does this removal preclude some future method exclusion? no. EKR: Uncomfortable with… Martin: Yes, he’s one that I wanted to check in with… Robert: Martin: We’ll knock this out on the list. ---next Alex Mayrhofer (presenter) Status (slide) Motivation (slide) Comments: Brian: really like this document – need to recruit from other counties. Going to help a lot of implementers – I will contribute one from the US Alex: If, in an ideal case we get hundreds, where/how should we store them? Hannes: will try to get EENA to create for each county in the EU. Need one for each. Document doesn’t say why – especially for emergency case. Martin: want to know how we can get this doc published? Brian: do we want 300 rfc’s? need a registry Richard: Roger: suggestion to extricate the Austrian example into a “consideration” document, which could serve as the basis of a document template – one that each of 300 could be built on. Cullen: agree – don’t see a problem with creating a registry (don’t want 300 milestones…) ---next Brian Rosen (presenter) Loc-filters draft Comments based on review of Martin Thomson (slide) Change filter – will wait for text from somebody Martin: another area which could need work – location delta concept. Martin: would like to see some things removed, such as the “notification” of which area you’ve moved into – would be useful as a general mechanism (in SIMPLE). Brian: perfectly acceptable once there is some external document that contains the mechanism that this document can point to. Martin: will continue to discuss – and will advertise to SIMPLE that this is a topic. ---next Robert: do we have <…>? Jon can we start on the 3rd party issues? Jon Peterson (presenter) – Third-party Access to Location Jon: want to get a sense of whether this is one of the things this wg wants to take on? Jon: goes back to the origination of this wg – the scenario where an access network knows your location and you want a service to acquire it directly. (slide) Jon: slide – how it might work (w/an identifier) Steve Norrys: As a large, monolithic service company, we would be one that would *not* want this *unless* the user agreed to have it. Jon: yes, qualify – relationship btwn black phone ane the presence server. So, based on that… Steve, would this be something a company like yours would be interested in? Steve: yes, only if expressed permission by the user. James Polk: If you go way back (many moons) – if you remember, I used the example of a “lamp” who couldn’t communicate over IP but could be located. Jon: don’t recall the analogy… James: Concern in the old “on-behalf-of”, the rule-maker… Jon: in the old document, it was less clear, this document here make it clear. Martin: going back to old documents, where not clear, doesn’t help. This document does make it clear. Dealing with problem is necessary, and by ignoring it – risk becoming irrelevant ourselves. Martin: …I’m happy with that. _________: chip in my dog’s ear doesn’t have a UI in it. Therefore I think there is a use case where doing this for devices where UI in not present is worthwhile. Matt Lepinsky: Ted: Feelin a bit dim, but looked at 3693 – seems to be the same diagram in ascii. Is there a difference? Jon: main difference is that we have a LIS – rather than an LG. Ted: Richard: Marc: wanted to note that HELD iedentity extensions -07 removes all text as to why we’re doing 3rd party – need to identify motivation and requirements. Jon: do you object to this picture Marc? Marc: I object to remove the Rule Maker out of the picture Jon: okay, we all object to that. Hannes: Maybe this needs to be updated to take into account rule maker – and also acknowledge contracts in place today that equate manual rule maker agreements. Martin: …you can already see this rule maker concept in “I accept” web signup pages. Randall: Have some fundamental disagreements with how entities are nameas in the diagram = reaching back to presence architecture may be more than one LS Jon: James: Elizabeth ______: It seems almost like the discussion is “against the target’s wishes”, but for me, might this also be in reverse, “do it for the target – based on it’s wishes”. Jon: Marc: When the rule maker has been brought into the document, doesn’t believe that it’s been sincere – for example… Jon: , but I am thrilled that we all seem to agree that… Martin: I think we can resolve this by saying the target = rule-maker. Robert: We’re out of time. Ted: qualified… taking discussion to the list Robert: this has been a good conversation, believe that we have a document that Martin and Richard can take to the list to continue the discussion… ---End of meeting ---agenda (as posted) 10m Administrivia/Status 05m Update/discussion on http-location-delivery (Mary Barnes) http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10.txt 40m lis-discovery (Martin Thomson) http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt 05m civic-address-recommendations (Alex Mayrhofer) http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-00.txt 05m status check on loc-filters (Brian Rosen) http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt 05m status check on lo-sec/3963 update (Richard Barnes) http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt (Note: this draft has not been updated since before Dublin) 20m discuss cross-area feedback on identifiers (Ted Hardie) http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt 20m 3rd party access to location information (Jon Peterson) This will be the next steps in making progress on discussing if/how we facilitate 3rd party access to location information. Please be familiar with at least the following inputs: http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt http://tools.ietf.org/html/draft-linsner-geopriv-obo-00.txt Also, please be familiar with the following recently updated drafts to facilitate short conversations during the Administrivia/Status section (and hallway discussions): http://tools.ietf.org/html/draft-ietf-geopriv-lbyr-requirements-04.txt http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt