Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
draft-ietf-geopriv-policy-27
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-09-14
|
27 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-09-13
|
27 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-09-07
|
27 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-09-05
|
27 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-09-04
|
27 | (System) | IANA Action state changed to In Progress |
2012-09-04
|
27 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-09-04
|
27 | Amy Vezza | IESG has approved the document |
2012-09-04
|
27 | Amy Vezza | Closed "Approve" ballot |
2012-09-04
|
27 | Amy Vezza | Ballot approval text was generated |
2012-09-04
|
27 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-08-22
|
27 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
27 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
27 | (System) | post-migration administrative database adjustment to the Abstain position for Lisa Dusseault |
2012-08-21
|
27 | Martin Thomson | New version available: draft-ietf-geopriv-policy-27.txt |
2012-07-30
|
26 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2012-06-20
|
26 | Barry Leiba | [Ballot discuss] [Updated on 20 June] -- IANA Considerations -- [*** This part is resolved by version -26; thanks. ***] To ensure that IANA understands … [Ballot discuss] [Updated on 20 June] -- IANA Considerations -- [*** This part is resolved by version -26; thanks. ***] To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name. It would be nice to include the URL as well, to be absolutely sure. I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5. The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct? I note that IANA has questions about the registrations for this document, which need to be resolved. [*** This part is still pending, after Martin's note of 5 June; see below. ***] For the new registry in 11.3, I would like to see a rationale for the choice of registration policy. (See draft-leiba-iana-policy-update, if you want to see where I'm coming from here.) Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option. [5 June] > [MT] I don't have any information on the rationale behind Standards > Action. I'm asking the working group on this one. Specification > Required is better (in my onion) and I've changed the draft to that. > I'll revert it (probably with a RFC Editors note) if this doesn't work > out with the working group. [6 June] Thanks. I'll watch for that, and clear the DISCUSS when it's resolved. [20 June] I haven't heard anything further yet. |
2012-06-20
|
26 | Barry Leiba | [Ballot comment] [6 June] I'm happy with Martin's responses to these; thanks! +++++++++++++++++++++++++++++++++++++++++++++ -- Introduction -- This document does not describe the protocol used to … [Ballot comment] [6 June] I'm happy with Martin's responses to these; thanks! +++++++++++++++++++++++++++++++++++++++++++++ -- Introduction -- This document does not describe the protocol used to convey location information from the Location Server to the Location Recipient. What document does? Should it be noted here, with a citation? ---- OLD (unclear what part is "for example") Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor, for example, by reducing the granularity of returned location information. NEW (I think you mean...) Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor by, for example, reducing the granularity of returned location information. ---- Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. It's not clear exactly what this means. Is the only limitation the one related to the obfuscation? If there are other limitations, then it should be "e.g.", not "i.e." If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:". Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions? So maybe this is what you mean?: NEW Both algorithms come with limitations: they provide location obfuscation only under certain conditions, and may therefore not be appropriate for all application domains. -- Section 3.1 -- The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4. -- Section 3.2 -- URL, not URI ? -- Section 6.2 -- The value provided with the element indicates seconds and these seconds are added to the current date. If the element is absent then the value of the element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the value MUST be set to the current date. It looks like "current date" means "current date and time"; should you not say that? Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK. -- Section 6.4 -- If the element is absent, then the value of the element in the PIDF-LO is kept unchanged when available or, if the PIDF-LO is created for the first time then the element MUST NOT be included. This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present. That's odd, and possible troublesome, so I want to be sure you've thought about that. -- Internationaliztion Considerations -- The content of the element is meant to be provided by a human (the Rule Maker) and also displayed to a human. Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters? -- Section 13.3 -- The first paragraph is confusing, and doesn't seem to reach a reasonable conclusion. It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful. Please try to re-work that paragraph. -- Section 13.4 -- Location obscuring attempts to remove information about the location of a Target. The effectiveness of location obscuring is determined by how much uncertainty a Location Recipient has about the location of the Target. As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will. Obscured locations can still serve a purpose where a Location Recipient is willing to respect privacy. It's not clear what value that paragraph has. It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine." It's true, but not very useful as a security consideration. You might just want to remove this paragraph, and take the word "more" out of the subsequent one. This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified. The reference to RFC 2434 is obsolete, replaced by 5226, for example. ======== Editorial suggestions. No need to respond to these; take them, leave them, or modify them as you please. There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them. -- Introduction -- (clarity) Not all terminology is in one place, and Target isn't specifically defined. I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2): ----- 1. Introduction First sentence as written. Second sentence. 1.1 Terminology for the model, as in RFC 3693 Location Generator (LG), [explain]. Location Server (LS), ... Location Recipient (LR), ... Rule Maker (RM), ... Authorization Policy, ... Location Object (LO), ... Target, ... 1.2 Overview The basic rule set defined [...] ----- OLD (sounds awkward) The basic rule set, however, does not allow to control access to location information based on specific Location Recipients. NEW The basic rule set, however, does not allow access control for location information based on specific Location Recipients. OLD (clarity) The rule set allows the entity that uses the rules defined in this document to restrict the retention NEW The enhanced rule set allows the entity that uses the rules defined in this document to restrict the retention OLD (sounds awkward) or that the resolution of parts of the Location Object is reduced. NEW or that the resolution is reduced for parts of the Location Object. OLD (to read more smoothly) The typical sequence of operations is as follows. A Location Server receives a query NEW In the typical sequence of operations, a Location Server receives a query OLD (awkward usage) determine under which circumstances the entity executing the rules, for example a Location Server, NEW determine under which circumstances the entity executing the rules, such as a Location Server, -- Section 2 -- OLD (setting off defined terms) The term permission refers to the action and transformation components of a rule. NEW The term "permission" refers to the action and transformation components of a rule. OR The term Permission refers to the action and transformation components of a rule. In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence. OLD (bad usage) as motivated in RFC 4079 This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand. NEW as explained in RFC 4079 [or "described in", or something like that] -- Section 4.1 -- OLD (repetition) reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the European Petroleum Survey Group NEW Can you re-word this to avoid the "based on... based on" repetition? -- Section 7.5 -- OLD We will set up a grid not only for the continental US, but for the whole earth between latitudes 25 and 50 degrees You're not including Alaska. This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US". -- Section 13.1 -- First paragraph has a spurious ")" at the end. OLD (unclear antecedent) This algorithm for geodetic location information obfuscation makes use of these techniques. NEW The algorithm defined in this document for geodetic location information obfuscation makes use of these techniques. -- Section 13.2 -- OLD For example, when a transformation indicates that civic location is provided at a 'building' level of granularity. Consequently, floor levels, room numbers, etc. would be hidden. The first sentence is not a complete sentence, and the second is not a very good one. Merge these, and make a proper sentence. Maybe (assuming I understand what you mean to say) something like this?: NEW For example, when a transformation indicates that civic location is provided at a 'building' level of granularity, floor levels, room numbers, and other detailed information would be hidden. The paragraph that begins thus: The algorithm presented in Section 6.5.2 has some measures against leaking information when moving, switching from one privacy region to another one ...is very long, and has quite a number of grammatical errors. I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs. -- IANA Considerations -- I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address. Should you perhaps be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual? (I notice that Hannes's other document on this telechat has his old Siemens address, and discussion mail is bouncing as a result... that's the sort of thing I mean.) |
2012-06-20
|
26 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2012-06-06
|
26 | Stephen Farrell | [Ballot comment] abstract: "restrict access" in the abstract is ambiguous - it could mean "restrict access to a target's actual location" or it could mean … [Ballot comment] abstract: "restrict access" in the abstract is ambiguous - it could mean "restrict access to a target's actual location" or it could mean "restrict access to something based on a target's location information." Not sure if that needs fixing or not but this is only addressing the former I think. 4.1: what does "within" mean here - does overlapping count or not? Seems like that could be made more precise, but maybe its defined elsewhere in which case a reference to the relevant section of the relevant RFC would be good. I think that's clarified later, but be good to be clear here too. 6.2: It'd maybe be good to explicitly state the meaning of setting this to the current date. I assume it means "don't retain." 6.4: CID URIs are mentioned here but not explained nor is the acronym expanded. Be nice to do that. - 13.2: says that "The quotient of the sizes A1/A should be, even in the worst case, larger than a fixed known number, in order that the user knows what is the maximal information leakage he has." Should that should be a 2119 SHOULD? In other words, is the "maximum leakage" referred to here really a parameter of the 6.5.2 algorithm? If so, then ought that not be called out with 2119 terms? - 13.2: I don't follow how the A1/A quotient is >0.13, can you explain that some more? (That may or may not need to be reflected in the document, not sure.) - 13.3: 1st para - What is an implementer supposed to do with or based on this paragraph? - 13.4: This seems to imply "uncertainty" is a parameter of the algorithm, but that's not explained. This is a similar point to that made for 13.2 13: the term "privacy region" is used but not defined 10.4: typo s/to defined/to define/ 13.2: a few typos at the end of 1st para, and more elsewhere, could do with an editorial pass really 13.3: "further checks are performed" seems wrong if you don't say what those are, maybe s/are/can be/? |
2012-06-06
|
26 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-06-05
|
26 | Martin Thomson | New version available: draft-ietf-geopriv-policy-26.txt |
2012-05-07
|
25 | Suresh Krishnan | Request for Last Call review by GENART Completed. Reviewer: Suresh Krishnan. |
2012-04-26
|
25 | Cindy Morgan | State Change Notice email list changed to jmpolk@cisco.com, Hannes.Tschofenig@siemens.com, schulzrinne@cs.columbia.edu, rjsparks@nostrum.com, martin.thomson@gmail.com from jmpolk@cisco.com, Hannes.Tschofenig@siemens.com, schulzrinne@cs.columbia.edu, rjsparks@nostrum.com |
2012-04-26
|
25 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2012-04-26
|
25 | Barry Leiba | [Ballot discuss] [Updated after telechat] -- IANA Considerations -- To ensure that IANA understands which registries you're putting things in, please specify very clearly which … [Ballot discuss] [Updated after telechat] -- IANA Considerations -- To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name. It would be nice to include the URL as well, to be absolutely sure. I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5. The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct? I note that IANA has questions about the registrations for this document, which need to be resolved. For the new registry in 11.3, I would like to see a rationale for the choice of registration policy. (See draft-leiba-iana-policy-update, if you want to see where I'm coming from here.) Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option. |
2012-04-26
|
25 | Barry Leiba | [Ballot comment] Substantive suggestions; please adopt or respond to these: -- Introduction -- This document does not describe the protocol used to convey location information … [Ballot comment] Substantive suggestions; please adopt or respond to these: -- Introduction -- This document does not describe the protocol used to convey location information from the Location Server to the Location Recipient. What document does? Should it be noted here, with a citation? ---- OLD (unclear what part is "for example") Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor, for example, by reducing the granularity of returned location information. NEW (I think you mean...) Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor by, for example, reducing the granularity of returned location information. ---- Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. It's not clear exactly what this means. Is the only limitation the one related to the obfuscation? If there are other limitations, then it should be "e.g.", not "i.e." If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:". Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions? So maybe this is what you mean?: NEW Both algorithms come with limitations: they provide location obfuscation only under certain conditions, and may therefore not be appropriate for all application domains. -- Section 3.1 -- The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4. -- Section 3.2 -- URL, not URI ? -- Section 6.2 -- The value provided with the element indicates seconds and these seconds are added to the current date. If the element is absent then the value of the element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the value MUST be set to the current date. It looks like "current date" means "current date and time"; should you not say that? Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK. -- Section 6.4 -- If the element is absent, then the value of the element in the PIDF-LO is kept unchanged when available or, if the PIDF-LO is created for the first time then the element MUST NOT be included. This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present. That's odd, and possible troublesome, so I want to be sure you've thought about that. -- Internationaliztion Considerations -- The content of the element is meant to be provided by a human (the Rule Maker) and also displayed to a human. Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters? -- Section 13.3 -- The first paragraph is confusing, and doesn't seem to reach a reasonable conclusion. It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful. Please try to re-work that paragraph. -- Section 13.4 -- Location obscuring attempts to remove information about the location of a Target. The effectiveness of location obscuring is determined by how much uncertainty a Location Recipient has about the location of the Target. As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will. Obscured locations can still serve a purpose where a Location Recipient is willing to respect privacy. It's not clear what value that paragraph has. It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine." It's true, but not very useful as a security consideration. You might just want to remove this paragraph, and take the word "more" out of the subsequent one. This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified. The reference to RFC 2434 is obsolete, replaced by 5226, for example. ======== Editorial suggestions. No need to respond to these; take them, leave them, or modify them as you please. There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them. -- Introduction -- (clarity) Not all terminology is in one place, and Target isn't specifically defined. I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2): ----- 1. Introduction First sentence as written. Second sentence. 1.1 Terminology for the model, as in RFC 3693 Location Generator (LG), [explain]. Location Server (LS), ... Location Recipient (LR), ... Rule Maker (RM), ... Authorization Policy, ... Location Object (LO), ... Target, ... 1.2 Overview The basic rule set defined [...] ----- OLD (sounds awkward) The basic rule set, however, does not allow to control access to location information based on specific Location Recipients. NEW The basic rule set, however, does not allow access control for location information based on specific Location Recipients. OLD (clarity) The rule set allows the entity that uses the rules defined in this document to restrict the retention NEW The enhanced rule set allows the entity that uses the rules defined in this document to restrict the retention OLD (sounds awkward) or that the resolution of parts of the Location Object is reduced. NEW or that the resolution is reduced for parts of the Location Object. OLD (to read more smoothly) The typical sequence of operations is as follows. A Location Server receives a query NEW In the typical sequence of operations, a Location Server receives a query OLD (awkward usage) determine under which circumstances the entity executing the rules, for example a Location Server, NEW determine under which circumstances the entity executing the rules, such as a Location Server, -- Section 2 -- OLD (setting off defined terms) The term permission refers to the action and transformation components of a rule. NEW The term "permission" refers to the action and transformation components of a rule. OR The term Permission refers to the action and transformation components of a rule. In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence. OLD (bad usage) as motivated in RFC 4079 This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand. NEW as explained in RFC 4079 [or "described in", or something like that] -- Section 4.1 -- OLD (repetition) reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the European Petroleum Survey Group NEW Can you re-word this to avoid the "based on... based on" repetition? -- Section 7.5 -- OLD We will set up a grid not only for the continental US, but for the whole earth between latitudes 25 and 50 degrees You're not including Alaska. This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US". -- Section 13.1 -- First paragraph has a spurious ")" at the end. OLD (unclear antecedent) This algorithm for geodetic location information obfuscation makes use of these techniques. NEW The algorithm defined in this document for geodetic location information obfuscation makes use of these techniques. -- Section 13.2 -- OLD For example, when a transformation indicates that civic location is provided at a 'building' level of granularity. Consequently, floor levels, room numbers, etc. would be hidden. The first sentence is not a complete sentence, and the second is not a very good one. Merge these, and make a proper sentence. Maybe (assuming I understand what you mean to say) something like this?: NEW For example, when a transformation indicates that civic location is provided at a 'building' level of granularity, floor levels, room numbers, and other detailed information would be hidden. The paragraph that begins thus: The algorithm presented in Section 6.5.2 has some measures against leaking information when moving, switching from one privacy region to another one ...is very long, and has quite a number of grammatical errors. I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs. -- IANA Considerations -- I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address. Should you perhaps be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual? (I notice that Hannes's other document on this telechat has his old Siemens address, and discussion mail is bouncing as a result... that's the sort of thing I mean.) |
2012-04-26
|
25 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2012-04-26
|
25 | Sean Turner | [Ballot comment] I cleared my discuss based on some exchagnes with Robert. s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's … [Ballot comment] I cleared my discuss based on some exchagnes with Robert. s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's not really safe it's enabling. s3.2: r/There are two ways how the/There are two ways the s4: r/allows to indicate/indicates s6.5.2: r/steps.The/steps. The s6.5.2: I found this a little hard to parse: The maximal distortion of the map may not be too much (see notes below). r/much/large? s6.5.2, step 5: r/P/p s6.5.2: Okay I'll bite what's the basis for picking those values for p and q? s8/s9: I'm going with the thought that somebody verified the XML schema. I agreed with many of the initial IESG reviews of early versions of this draft, but I think the security considerations is great big step in the right direction. But, I had a bunch of edits on the security considerations to make it more understandable. Not sure that all my suggestions are correct though. s13.1, 1st para: r/This is accomplished through the usage of authorization policies./This is accomplished using authorization policies. r/treated in [RFC4745])./addressed in [RFC4745]. s13.1, 2nd para: r/In addition to the authorization policies mechanisms/ In addition to the authorization policies, mechanisms r/makes use of these/uses these s13.1, 3rd para: what does this mean: The requirements of location information with respect to privacy protection vary. requirements on the information or requirements on giving out the information? r/While the two obfuscation algorithm/While the two obfuscation algorithms I think you mean to protection against unauthorized disclosure of location information: r/protection/protecting against unauthorized disclosure of location information This sounds odd: There are certainly applications that require a different level of protection and for this purpose the ability to define and use additional algorithms has been envisioned. New algorithms can be specified via the available extension mechanism. Maybe: Applications requirements vary widely; therefore, an extension mechanism is supported to allow for the definition of new algorithms. s13.2, 1st para: r/then it contains/it contains r/is danger to reveal information over time/is a danger than information will be revealed over time. r/real/reveal ? 13.2, 3rd para: ? OLD: For this purpose the algorithm described in Section 6.5.2 uses a grid that ensures to report the same location information whenever the target remains in the same geographical area. NEW: For this purpose the algorithm described in Section 6.5.2 uses a grid that ensures the same location information is reported whenever the target remains in the same geographical area. s13.2, 5th para: r/measures/protections ? r/is visiting regularly/is regularly visiting r/The first issue is the following:/The first concern is the ability to be followed: The second issue is also the following? Isn't the 3rd concern listed in the 1st sentence visiting places regularly? r/If the reported obfuscated locations are all randomly different, an analysis will probably soon reveal the home location with high precision/ If the reported obfuscated locations are all randomly chosen, an analysis can reveal the home location with high precision. all randomly different/all randomly chosen (it'd be funny if they were all randomly the same) and will probably is wishy-washy - the point is you can do an analysis. r/may render a much precise location information than desired./ may render a much more precise location information than is desired. once or in a regular repetitive way can non-regular samples help leak samples? maybe r/once or in a regular repetitive way/once or multiple times also is it or or and at the end of that sentence? r/An opponent,/A stalker, ;) but probably better to say attacker Oh and I support Stephen's discuss position. |
2012-04-26
|
25 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-04-26
|
25 | Adrian Farrel | [Ballot comment] I find the philosophical aspects of this work very hard to grapple with. Had the work been presented in a more abstract way … [Ballot comment] I find the philosophical aspects of this work very hard to grapple with. Had the work been presented in a more abstract way (for example, as a policy language that could be used in a number of ways) I would have found it easier. But the text on motivation disturbs me and, while I can completely accept that many people are motivated in this way, the approach and ideas seem to me to be broken. I do not believe that I should enter a Discuss or stand in the way of this work because of my views, but I cannot offer a "No Objection" ballot position. === Additionally, the authors might like to consider the following: It is not clear to me why algorithms need to be standardised in this case. While they do affect what is sent on the wire, and while they provide useful examples to show that the results can be reliably achieved, it seems to me that the results of the algorithms (i.e. the outputs based on the inputs) are all that need to be contained in a Technical Specification. In short, I do not believe that the specification of the algorithms is necessary for interoperability. |
2012-04-26
|
25 | Adrian Farrel | [Ballot Position Update] New position, Abstain, has been recorded for Adrian Farrel |
2012-04-25
|
25 | Pete Resnick | [Ballot comment] This document needs a great deal of editing for simplification and clarity. That said, none of these (or the other changes I suggest … [Ballot comment] This document needs a great deal of editing for simplification and clarity. That said, none of these (or the other changes I suggest below) are enough for me to hold up the document. But I do wish you would address these issues before publication. First, the strictly editorial. There's a great deal of use of the passive voice that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing, with some suggested replacements: This section describes the location-specific conditions of a rule. The element contains zero, one or an unbounded number of child element(s). Providing more than one element may not be useful since all child elements of the element must evaluate to TRUE in order for the element to be TRUE. The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. "The element contains zero or more child element(s). The element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple elements are not normally useful). The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements evaluates to TRUE." The element has three attributes, namely 'profile', 'xml: lang' and 'label'. The 'profile' attribute allows to indicate the location profile that is included as child elements in the element and each profile needs to describe under what conditions each element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile, see Section 4.1 and Section 4.2. The 'label' attribute allows a human readable description to be added to each element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute. "The three attributes of element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute." I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. These are just two examples. The entire document could use a good rewrite. From here on, I will point only out places where I think the language obfuscates meaning. 4: The and the elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. Are you saying that if an unknown extension is used in a child of , that should evaluate FALSE if if another known child of evaluates TRUE? That violates the logical OR of the element. 4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must. "If the civic location of the Target is unknown": Do you mean "If the element is missing"? This reads as if the should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean. 6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else. 6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite. 6.2 " element is an integer." I assume unsigned, yes? Probably best to say. 6.5.1 I can't get any more granular than the 6 choices? Why not? |
2012-04-25
|
25 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-04-25
|
25 | Pete Resnick | [Ballot comment] This document needs a great deal of editing for simplification and clarity. That said, none of these or the other changes I suggest … [Ballot comment] This document needs a great deal of editing for simplification and clarity. That said, none of these or the other changes I suggest below, are enough for me to hold up the document. But I do wish you would address these issues before publication. First, the strictly editorial. There's a great deal of use of the passive voice that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing, with some suggested replacements: This section describes the location-specific conditions of a rule. The element contains zero, one or an unbounded number of child element(s). Providing more than one element may not be useful since all child elements of the element must evaluate to TRUE in order for the element to be TRUE. The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. "The element contains zero or more child element(s). The element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple elements are not normally useful). The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements evaluates to TRUE." The element has three attributes, namely 'profile', 'xml: lang' and 'label'. The 'profile' attribute allows to indicate the location profile that is included as child elements in the element and each profile needs to describe under what conditions each element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile, see Section 4.1 and Section 4.2. The 'label' attribute allows a human readable description to be added to each element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute. "The three attributes of element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute." I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. These are just two examples. The entire document could use a good rewrite. From here on, I will point only out places where I think the language obfuscates meaning. 4: The and the elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. Are you saying that if an unknown extension is used in a child of , that should evaluate FALSE if if another known child of evaluates TRUE? That violates the logical OR of the element. 4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must. "If the civic location of the Target is unknown": Do you mean "If the element is missing"? This reads as if the should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean. 6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else. 6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite. 6.2 " element is an integer." I assume unsigned, yes? Probably best to say. 6.5.1 I can't get any more granular than the 6 choices? Why not? |
2012-04-25
|
25 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from No Record |
2012-04-25
|
25 | Pete Resnick | [Ballot comment] [Not done with my comments yet. Not recording my position yet.] This document needs a great deal of editing for simplification and clarity. … [Ballot comment] [Not done with my comments yet. Not recording my position yet.] This document needs a great deal of editing for simplification and clarity. There's a great deal of use of the passive voice with verbs that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing: This section describes the location-specific conditions of a rule. The element contains zero, one or an unbounded number of child element(s). Providing more than one element may not be useful since all child elements of the element must evaluate to TRUE in order for the element to be TRUE. The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. "The element contains zero or more child element(s). The element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple elements are not normally useful). The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements evaluates to TRUE." The element has three attributes, namely 'profile', 'xml: lang' and 'label'. The 'profile' attribute allows to indicate the location profile that is included as child elements in the element and each profile needs to describe under what conditions each element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile, see Section 4.1 and Section 4.2. The 'label' attribute allows a human readable description to be added to each element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute. "The three attributes of element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute." I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. From here on, I will point only out places where the language obfuscates meaning. 4: The and the elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. Are you saying that if an unknown extension is used in a child of , that should evaluate FALSE if if another known child of evaluates TRUE? That violates the logical OR of the element. 4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must. "If the civic location of the Target is unknown": Do you mean "If the element is missing"? This reads as if the should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean. 6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else. 6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite. 6.2 " element is an integer." I assume unsigned, yes? Probably best to say. 6.5.1 I can't get any more granular than the 6 choices? Why not? |
2012-04-25
|
25 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-04-25
|
25 | Pete Resnick | [Ballot comment] [Not done with my comments yet. Not recording my position yet.] This document needs a great deal of editing for simplification and clarity. … [Ballot comment] [Not done with my comments yet. Not recording my position yet.] This document needs a great deal of editing for simplification and clarity. There's a great deal of use of the passive voice with verbs that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing: This section describes the location-specific conditions of a rule. The element contains zero, one or an unbounded number of child element(s). Providing more than one element may not be useful since all child elements of the element must evaluate to TRUE in order for the element to be TRUE. The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. "The element contains zero or more child element(s). The element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple elements are not normally useful). The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements evaluates to TRUE." The element has three attributes, namely 'profile', 'xml: lang' and 'label'. The 'profile' attribute allows to indicate the location profile that is included as child elements in the element and each profile needs to describe under what conditions each element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile, see Section 4.1 and Section 4.2. The 'label' attribute allows a human readable description to be added to each element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute. "The three attributes of element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute." I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. From here on, I will point only out places where the language obfuscates meaning. 4: The and the elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. Are you saying that if an unknown extension is used in a child of , that should evaluate FALSE if if another known child of evaluates TRUE? That violates the logical OR of the element. 4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must. "If the civic location of the Target is unknown": Do you mean "If the element is missing"? This reads as if the should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean. 6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else. 6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite. 6.2 " element is an integer." I assume unsigned, yes? Probably best to say. |
2012-04-25
|
25 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-04-25
|
25 | Ralph Droms | [Ballot comment] Minor editorial nits: section 4: The 'profile' attribute allows to indicate the location profile that is included as child elements in … [Ballot comment] Minor editorial nits: section 4: The 'profile' attribute allows to indicate the location profile that is included as child elements in the element and each profile needs to describe under what conditions each element evaluates to TRUE. missing word in "allows to"? (also section 6.4) section 6.5.2 5. Let P = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p), lower case or upper case P? section 7.5 Suppose you want a to obscure s/a// ? section 7.5 In his way "In this way"? THe document lists 6 authors; you may get pushback as the guideline is 5. |
2012-04-25
|
25 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-04-25
|
25 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-04-25
|
25 | Sean Turner | [Ballot discuss] Just trying to make this actionable (I understand this parenthetical bit isn't so much: the rest of the section needs a good editorial … [Ballot discuss] Just trying to make this actionable (I understand this parenthetical bit isn't so much: the rest of the section needs a good editorial pass to make sure it makes sense -see my comments): The last paragraph in s13.2 seems like it might be missing a discussion about one of the three things listed in the 1st sentence. There's a discussion about the 1st and 2nd issue but not the 3rd and the 1st and 2nd issue both "the following", which I assume has something to do with Jack Torrance/Nicholson. Maybe it's just editorial, but I'd like to make sure nothing got dropped. |
2012-04-25
|
25 | Sean Turner | [Ballot comment] s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's not really safe it's enabling. s3.2: r/There are two ways … [Ballot comment] s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's not really safe it's enabling. s3.2: r/There are two ways how the/There are two ways the s4: r/allows to indicate/indicates s6.5.2: r/steps.The/steps. The s6.5.2: I found this a little hard to parse: The maximal distortion of the map may not be too much (see notes below). r/much/large? s6.5.2, step 5: r/P/p s6.5.2: Okay I'll bite what's the basis for picking those values for p and q? s8/s9: I'm going with the thought that somebody verified the XML schema. I agreed with many of the initial IESG reviews of early versions of this draft, but I think the security considerations is great big step in the right direction. But, I had a bunch of edits on the security considerations to make it more understandable. Not sure that all my suggestions are correct though. s13.1, 1st para: r/This is accomplished through the usage of authorization policies./This is accomplished using authorization policies. r/treated in [RFC4745])./addressed in [RFC4745]. s13.1, 2nd para: r/In addition to the authorization policies mechanisms/ In addition to the authorization policies, mechanisms r/makes use of these/uses these s13.1, 3rd para: what does this mean: The requirements of location information with respect to privacy protection vary. requirements on the information or requirements on giving out the information? r/While the two obfuscation algorithm/While the two obfuscation algorithms I think you mean to protection against unauthorized disclosure of location information: r/protection/protecting against unauthorized disclosure of location information This sounds odd: There are certainly applications that require a different level of protection and for this purpose the ability to define and use additional algorithms has been envisioned. New algorithms can be specified via the available extension mechanism. Maybe: Applications requirements vary widely; therefore, an extension mechanism is supported to allow for the definition of new algorithms. s13.2, 1st para: r/then it contains/it contains r/is danger to reveal information over time/is a danger than information will be revealed over time. r/real/reveal ? 13.2, 3rd para: ? OLD: For this purpose the algorithm described in Section 6.5.2 uses a grid that ensures to report the same location information whenever the target remains in the same geographical area. NEW: For this purpose the algorithm described in Section 6.5.2 uses a grid that ensures the same location information is reported whenever the target remains in the same geographical area. s13.2, 5th para: r/measures/protections ? r/is visiting regularly/is regularly visiting r/The first issue is the following:/The first concern is the ability to be followed: The second issue is also the following? Isn't the 3rd concern listed in the 1st sentence visiting places regularly? r/If the reported obfuscated locations are all randomly different, an analysis will probably soon reveal the home location with high precision/ If the reported obfuscated locations are all randomly chosen, an analysis can reveal the home location with high precision. all randomly different/all randomly chosen (it'd be funny if they were all randomly the same) and will probably is wishy-washy - the point is you can do an analysis. r/may render a much precise location information than desired./ may render a much more precise location information than is desired. once or in a regular repetitive way can non-regular samples help leak samples? maybe r/once or in a regular repetitive way/once or multiple times also is it or or and at the end of that sentence? r/An opponent,/A stalker, ;) but probably better to say attacker Oh and I support Stephen's discuss position. |
2012-04-25
|
25 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-04-24
|
25 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-04-23
|
25 | Barry Leiba | [Ballot discuss] -- IANA Considerations -- To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the … [Ballot discuss] -- IANA Considerations -- To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name. It would be nice to include the URL as well, to be absolutely sure. I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5. The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct? For the new registry in 11.3, I would like to see a rationale for the choice of registration policy. See draft-leiba-iana-policy-update, if you want to see where I'm coming from here. Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option. I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address. Discussion: should you be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual? |
2012-04-23
|
25 | Barry Leiba | [Ballot comment] Substantive suggestions; please adopt or respond to these: -- Introduction -- This document does not describe the protocol used to convey location information … [Ballot comment] Substantive suggestions; please adopt or respond to these: -- Introduction -- This document does not describe the protocol used to convey location information from the Location Server to the Location Recipient. What document does? Should it be noted here, with a citation? ---- OLD (unclear what part is "for example") Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor, for example, by reducing the granularity of returned location information. NEW (I think you mean...) Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor by, for example, reducing the granularity of returned location information. ---- Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. It's not clear exactly what this means. Is the only limitation the one related to the obfuscation? If there are other limitations, then it should be "e.g.", not "i.e." If that's the only limitation, I suggest replacing "limitations, i.e." with "limitations:". Also, it doesn't make sense that providing location obfuscation would be a limitation; perhaps you mean *only* under certain conditions? So maybe this is what you mean?: NEW Both algorithms come with limitations: they provide location obfuscation only under certain conditions, and may therefore not be appropriate for all application domains. -- Section 3.1 -- The preferred term now is "media type", not "MIME type"; please change it. Also in Section 10.4. -- Section 3.2 -- URL, not URI ? -- Section 6.2 -- The value provided with the element indicates seconds and these seconds are added to the current date. If the element is absent then the value of the element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the value MUST be set to the current date. It looks like "current date" means "current date and time"; should you not say that? Also, I guess absence then means that the retention expiry is immediate... and I presume that's OK. -- Section 6.4 -- If the element is absent, then the value of the element in the PIDF-LO is kept unchanged when available or, if the PIDF-LO is created for the first time then the element MUST NOT be included. This creates an interesting situation, in which the absence of a value has a meaning that cannot be conveyed by any value that might be present. That's odd, and possible troublesome, so I want to be sure you've thought about that. -- Internationaliztion Considerations -- The content of the element is meant to be provided by a human (the Rule Maker) and also displayed to a human. Does this also mean that the information might need to be language-tagged and/or translated (in addition to perhaps being in non-ASCII characters? -- Section 13.3 -- The first paragraph is confusing, and doesn't seem to reach a reasonable conclusion. It purports to talk about usability, but then seems to get into information leakage, and never makes a point that seems to me to be clear and useful. Please try to re-work that paragraph. -- Section 13.4 -- Location obscuring attempts to remove information about the location of a Target. The effectiveness of location obscuring is determined by how much uncertainty a Location Recipient has about the location of the Target. As you note earlier (and later, two paragraphs down), this is oversimplified: the effectiveness is not determined just by that, but is also strongly influenced by what can be revealed by repeated queries over time -- how aggregating responses can reveal more than a single response will. Obscured locations can still serve a purpose where a Location Recipient is willing to respect privacy. It's not clear what value that paragraph has. It seems to say, basically, "If the LR doesn't want to attack you, then whatever you've done will be fine." It's true, but not very useful as a security consideration. You might just want to remove this paragraph, and take the word "more" out of the subsequent one. This is an old document; please double-check the references to make sure they're accurate, current, and correctly classified. The reference to RFC 2434 is obsolete, replaced by 5226, for example. ======== Editorial suggestions. No need to respond to these; take them, leave them, or modify them as you please. There are also numerous errors in punctuation, number agreement, and the like; it would be good for one of the native English speaking editors to go through the document source code and fix those... or I guess we can let the RFC Editor deal with them. -- Introduction -- (clarity) Not all terminology is in one place, and Target isn't specifically defined. I suggest the following structure for the introduction (and if you do this, you can remove the second paragraph from section 2): ----- 1. Introduction First sentence as written. Second sentence. 1.1 Terminology for the model, as in RFC 3693 Location Generator (LG), [explain]. Location Server (LS), ... Location Recipient (LR), ... Rule Maker (RM), ... Authorization Policy, ... Location Object (LO), ... Target, ... 1.2 Overview The basic rule set defined [...] ----- OLD (sounds awkward) The basic rule set, however, does not allow to control access to location information based on specific Location Recipients. NEW The basic rule set, however, does not allow access control for location information based on specific Location Recipients. OLD (clarity) The rule set allows the entity that uses the rules defined in this document to restrict the retention NEW The enhanced rule set allows the entity that uses the rules defined in this document to restrict the retention OLD (sounds awkward) or that the resolution of parts of the Location Object is reduced. NEW or that the resolution is reduced for parts of the Location Object. OLD (to read more smoothly) The typical sequence of operations is as follows. A Location Server receives a query NEW In the typical sequence of operations, a Location Server receives a query OLD (awkward usage) determine under which circumstances the entity executing the rules, for example a Location Server, NEW determine under which circumstances the entity executing the rules, such as a Location Server, -- Section 2 -- OLD (setting off defined terms) The term permission refers to the action and transformation components of a rule. NEW The term "permission" refers to the action and transformation components of a rule. OR The term Permission refers to the action and transformation components of a rule. In general, please be consistent with how you set off defined terms, and avoid using a term in a definition while making it look like it's just part of the sentence. OLD (bad usage) as motivated in RFC 4079 This usage of "motivated" is made-up business jargon and will be difficult for many non-native speakers (and quite some native speakers) to understand. NEW as explained in RFC 4079 [or "described in", or something like that] -- Section 4.1 -- OLD (repetition) reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the European Petroleum Survey Group NEW Can you re-word this to avoid the "based on... based on" repetition? -- Section 7.5 -- OLD We will set up a grid not only for the continental US, but for the whole earth between latitudes 25 and 50 degrees You're not including Alaska. This is a total nit, but in order to avoid arguments about whether "continental" U.S. includes Alaska, you might switch to "contiguous US". -- Section 13.1 -- First paragraph has a spurious ")" at the end. OLD (unclear antecedent) This algorithm for geodetic location information obfuscation makes use of these techniques. NEW The algorithm defined in this document for geodetic location information obfuscation makes use of these techniques. -- Section 13.2 -- OLD For example, when a transformation indicates that civic location is provided at a 'building' level of granularity. Consequently, floor levels, room numbers, etc. would be hidden. The first sentence is not a complete sentence, and the second is not a very good one. Merge these, and make a proper sentence. Maybe (assuming I understand what you mean to say) something like this?: NEW For example, when a transformation indicates that civic location is provided at a 'building' level of granularity, floor levels, room numbers, and other detailed information would be hidden. The paragraph that begins thus: The algorithm presented in Section 6.5.2 has some measures against leaking information when moving, switching from one privacy region to another one ...is very long, and has quite a number of grammatical errors. I suggest getting one of the native-English-speaking editors to fix this and to split it into at least three paragraphs. |
2012-04-23
|
25 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2012-04-23
|
25 | Ron Bonica | Ballot comment text updated for Ronald Bonica |
2012-04-23
|
25 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-04-23
|
25 | Stewart Bryant | [Ballot comment] Maybe "Internationalization" is an IETF keyword for character set, but I was surprised that the section did not include a discussion on the … [Ballot comment] Maybe "Internationalization" is an IETF keyword for character set, but I was surprised that the section did not include a discussion on the datums use in different countries. The text only supports WGS84, but I understand that there are other datums and that WGS84 is tied to GPS but that there are other Sat Nav systems. |
2012-04-23
|
25 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-04-22
|
25 | Russ Housley | Ballot comment and discuss text updated for Russ Housley |
2012-04-20
|
25 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-04-19
|
25 | Stephen Farrell | [Ballot discuss] Since the previous iesg discussions on this document pre-date me as an AD I might be commenting here on things that have already … [Ballot discuss] Since the previous iesg discussions on this document pre-date me as an AD I might be commenting here on things that have already been discussed. If so, just send me a pointer if you can to the earlier discussion. - general: repeated queries are a threat here and are recognised as such in a number of places. I would like to have seen some guidanace to implementers as to when such repeated queries might be considered to be an attack, and when not, and if there's something you can do about that. Can such guidance be offered? If so, why not include it in the document? If not, perhaps saying why that's the case would be worthwhile? - 13.4: The last sentence is too vague IMO. I think you mean that if location is only obscured e.g. around the home, then the lack of location implies that I'm at home. You should say that more clearly. |
2012-04-19
|
25 | Stephen Farrell | [Ballot comment] abstract: "restrict access" in the abstract is ambiguous - it could mean "restrict access to a target's actual location" or it could mean … [Ballot comment] abstract: "restrict access" in the abstract is ambiguous - it could mean "restrict access to a target's actual location" or it could mean "restrict access to something based on a target's location information." Not sure if that needs fixing or not but this is only addressing the former I think. 4.1: what does "within" mean here - does overlapping count or not? Seems like that could be made more precise, but maybe its defined elsewhere in which case a reference to the relevant section of the relevant RFC would be good. I think that's clarified later, but be good to be clear here too. 6.2: It'd maybe be good to explicitly state the meaning of setting this to the current date. I assume it means "don't retain." 6.4: CID URIs are mentioned here but not explained nor is the acronym expanded. Be nice to do that. - 13.2: says that "The quotient of the sizes A1/A should be, even in the worst case, larger than a fixed known number, in order that the user knows what is the maximal information leakage he has." Should that should be a 2119 SHOULD? In other words, is the "maximum leakage" referred to here really a parameter of the 6.5.2 algorithm? If so, then ought that not be called out with 2119 terms? - 13.2: I don't follow how the A1/A quotient is >0.13, can you explain that some more? (That may or may not need to be reflected in the document, not sure.) - 13.3: 1st para - What is an implementer supposed to do with or based on this paragraph? - 13.4: This seems to imply "uncertainty" is a parameter of the algorithm, but that's not explained. This is a similar point to that made for 13.2 13: the term "privacy region" is used but not defined 10.4: typo s/to defined/to define/ 13.2: a few typos at the end of 1st para, and more elsewhere, could do with an editorial pass really 13.3: "further checks are performed" seems wrong if you don't say what those are, maybe s/are/can be/? |
2012-04-19
|
25 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-04-05
|
25 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Discuss |
2012-04-05
|
25 | Robert Sparks | Placed on agenda for telechat - 2012-04-26 |
2012-04-05
|
25 | Robert Sparks | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-03
|
25 | Amanda Baber | IANA has a question about one of the actions requested in this document. IANA understands that, upon approval of this document, there are six IANA … IANA has a question about one of the actions requested in this document. IANA understands that, upon approval of this document, there are six IANA actions which must be completed. First, in the XML Schemas subregistry of the IETF XML registry located at: http://www.iana.org/assignments/xml-registry/schema.html a new schema will be registered as follows: ID: geolocation-policy URI: urn:ietf:params:xml:schema:geolocation-policy Filename: As provided in Section 9 of the approved document Reference: [ RFC-to-be ] Second, in the XML Namesspaces subregistry of the IETF XML registry located at: http://www.iana.org/assignments/xml-registry/ns.html a new namespace will be registered as follows: ID: geolocation-policy URI: urn:ietf:params:xml:ns:geolocation-policy Registry template: As provided in section 11.2 of the approved document Reference: [ RFC-to-be ] Third, IANA will create a new registry called the "Geolocation Policy Location Profiles" registry. Each profile name will be an XML token. Maintenance of the registry will be through Standards Action. There are initial values for the registry: IANA QUESTION -> Is this the only information that the new registry should contain? Policy Location Profile Reference -------------------------------|--------------| geodetic-condition [ RFC-to-be ] civic-condition [ RFC-to-be ] geodetic-transformation [ RFC-to-be ] civic-transformation [ RFC-to-be ] Fourth, in the XML Schemas subregistry of the IETF XML registry located at: http://www.iana.org/assignments/xml-registry/schema.html a new schema will be registered as follows: ID: basic-location-profiles URI: urn:ietf:params:xml:schema:basic-location-profiles Filename: As provided in Section 8 of the approved document Reference: [ RFC-to-be ] Fifth, in the XML Namesspaces subregistry of the IETF XML registry located at: http://www.iana.org/assignments/xml-registry/ns.html a new namespace will be registered as follows: ID: basic-location-profiles URI: urn:ietf:params:xml:ns:basic-location-profiles Registry template: As provided in section 11.5 of the approved document Reference: [ RFC-to-be ] Sixth, in the XCAP Application Unique IDs subregistry in the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Parameters registry located at: http://www.iana.org/assignments/xcap-parameters/xcap-parameters.xml a new XCAP Application Usage ID will be registered as follows: Application Unique ID: geolocation-policy Description: Geolocation privacy rules are documents that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location. Reference: [ RFC-to-be ] IANA understands that these six actions are the only actions required to be completed upon approval of the document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2012-04-03
|
25 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-22
|
25 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-03-22
|
25 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-03-20
|
25 | Amy Vezza | Last call sent |
2012-03-20
|
25 | Amy Vezza | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information) to Proposed Standard The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information' as a Proposed Standard This last call focuses on the changes related to location obfuscation (fuzzing) resulting from additional working group attention resulting from a prior IESG review. Please focus the review on the difference between versions -21 and -25 of this draft. Version -21 of this document was IETF LCed in Jun 2010. Subsequent IESG review identified an issue with location obfuscation that required additional working group attention. Version -11 of this document was IETF LCed in Feb 2007 - subsequent IESG review identified several issues. The resulting working group discussion resulted in significant changes to the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information while the other one applies to geodetic location information. Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-20
|
25 | Robert Sparks | Last call was requested |
2012-03-20
|
25 | Robert Sparks | State changed to Last Call Requested from Publication Requested |
2012-03-20
|
25 | Robert Sparks | Last call announcement was changed |
2012-03-20
|
25 | Robert Sparks | Last call announcement was generated |
2012-03-20
|
25 | Robert Sparks | Ballot writeup was changed |
2012-03-19
|
25 | Cindy Morgan | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested. This is appropriate because the document defines a uniform protocol for expressing privacy rules. This is the type of RFC indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location-specific transformation elements to reduce the granularity of the returned location information. Working Group Summary There is strong, long-standing consensus in the working group that the policies described this document are a useful way to transmit geolocation-based privacy policies. The main point of discussion in the working group was over which "fuzzing" algorithm(s) should be mandatory to implement, given that all known algorithms have failings. In the end, there was strong consensus that the current approach, with an extensive discussion of risks associated with fuzzing, is the most appropriate. Document Quality The document has been reviewed by key participants from the GEOPRIV working group. In the process of analyzing fuzzing algorithms, there were several experimental implementations. Personnel The document shepherd is Richard Barnes. The responsible AD is Robert Sparks. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed this document, and think it is r easy for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have any concerns about the depth or breadth of review. Over the several years it has been in discussion, this document has received very thorough review from several perspectives. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I do not believe that this document requires any special review. It does contain XML schemas, but the structures it defines are simple and have been reviewed by members of the working group with XML expertise. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I do not have any special concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG consensus behind this document is very strong. There was robust debate over the issue of location fuzzing, with contributions from many participants. All parties agreed to the current approach. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) I am not aware of any threats of appeal or other extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document may require some minor changes to copyright boilerplate: The idnits tool warns of pre-RFC5378 work, but to my knowledge, there are no RFC5378 concerns for this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not contain MIBs or other data types that require formal review. (13) Have all references within this document been identified as either normative or informative? The references are split into normative and informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are either Standards Track RFCs or external documents in a similar state of maturity. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations are consistent with the body of the document, and provide clear instructions to IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document creates one registry, which requires Standards Action for modification. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains two XML schemas and several example XML documents. I have validated that these XML structures are well-formed using the W3C automated validator (). |
2012-03-19
|
25 | Cindy Morgan | State changed to Publication Requested from AD is watching |
2011-10-14
|
25 | (System) | New version available: draft-ietf-geopriv-policy-25.txt |
2011-09-14
|
24 | (System) | New version available: draft-ietf-geopriv-policy-24.txt |
2011-03-28
|
25 | Robert Sparks | State changed to AD is watching from Waiting for AD Go-Ahead. The GEOPRIV working group is going to rework the location obscuring algorithm section and … State changed to AD is watching from Waiting for AD Go-Ahead. The GEOPRIV working group is going to rework the location obscuring algorithm section and re-request publication when they achieve consensus on the revision. |
2011-03-27
|
25 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss |
2011-03-14
|
23 | (System) | New version available: draft-ietf-geopriv-policy-23.txt |
2011-03-04
|
25 | Robert Sparks | [Ballot discuss] Holding a discuss until the conversation on location hiding reaches a conclusion. |
2011-03-04
|
25 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded |
2010-10-25
|
22 | (System) | New version available: draft-ietf-geopriv-policy-22.txt |
2010-07-01
|
25 | Amanda Baber | IANA questions/comments: - In Section 11.3 you ask for the creation of the Geolocation Policy Location Profile Registry, but you don't define the information you … IANA questions/comments: - In Section 11.3 you ask for the creation of the Geolocation Policy Location Profile Registry, but you don't define the information you want in the registry. Is the only information required the Profile Name (and document reference)? Or do you need additional information as well, such as the profile definition? Action 1 (Sections 11.1, 11.4): Upon approval of this document, IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html ID URI Filename Reference -- ---------------- -------- --------- geolocation-policy urn:ietf:params:xml:schema:geolocation-policy geolocation-policy [RFC-geopriv-policy-21] basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles basic-location-profiles [RFC-geopriv-policy-21] Action 2 (Section 11.2, 11.5): Upon approval of this document, IANA will make the following assignments in the "ns" registry located at http://www.iana.org/assignments/xml-registry/ns.html ID URI Registration Template Reference -- ---------------- --------------------- --------- geolocation-policy urn:ietf:params:xml:ns:geolocation-policy geolocation-policy [RFC-geopriv-policy-21] basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles basic-location-profiles [RFC-geopriv-policy-21] Action 3 (Section 11.3): Upon approval of this document, IANA will create the following registry at http://www.iana.org/assignments/TBD Registry Name: Geolocation Policy Location Profiles Registration Procedures: Standards Action Initial contents of this registry will be: Profile Name Reference ------------ --------- geodetic-condition [RFC-geopriv-policy-21] civic-condition [RFC-geopriv-policy-21] geodetic-transformation [RFC-geopriv-policy-21] civic-transformation [RFC-geopriv-policy-21] Action 4 (Section 11.6): Upon approval of this document, IANA will make the following assignments in the "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Parameters" registry located at http://www.iana.org/assignments/xcap-parameters/xcap-parameters.xhtml "XCAP Application Unique IDs" Application Unique ID (AUID): geolocation-policy Description: Geolocation privacy rules are documents that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location. Reference: [RFC-geopriv-policy-21] |
2010-06-30
|
25 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-06-16
|
25 | Amy Vezza | Last call sent |
2010-06-16
|
25 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-06-16
|
25 | Robert Sparks | State Changes to Last Call Requested from Publication Requested by Robert Sparks |
2010-06-16
|
25 | Robert Sparks | Last Call was requested by Robert Sparks |
2010-04-13
|
25 | Robert Sparks | Responsible AD has been changed to Robert Sparks from Cullen Jennings |
2010-04-13
|
25 | Robert Sparks | [Note]: 'The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).' added by Robert Sparks |
2010-01-15
|
25 | Amy Vezza | State Changes to Publication Requested from AD is watching by Amy Vezza |
2010-01-15
|
25 | Amy Vezza | The GEOPRIV working group requests publication of draft-ietf-geopriv- policy-21 as Proposed Standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd … The GEOPRIV working group requests publication of draft-ietf-geopriv- policy-21 as Proposed Standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Richard Barnes. The Shepherd has personally reviewed this version of the document, and believes it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been the subject of thorough discussion within the GEOPRIV working group. I have no concerns about the level of review this document has received. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe that this document requires any special review. It does contain XML schemas, but the structures it defines are simple and have been reviewed by members of the working group with XML expertise. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no special concerns about this document. There have been no IPR disclosures related to the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong, broad-based, and long-standing consensus in the working group that this document is a useful and usable way to encode geolocation-based privacy rules. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) I am not aware of any extreme discontent or potential appeals related to this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have verified that the the document satisfies all ID nits, though it contains a few out-of-date references (which can be fixed as last-call and IESG comments are addressed). The document does not contain MIBs or other content that requires special review. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative. There is one normative reference to a non-IETF document, the Open Geospatial Consortium standard for the Geospatial Markup Language (GML). This reference is stable, and GML is generally considered to have an equivalent level of maturity to a standards-track RFC. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, and provides instructions for IANA to (1) register two new XML schemas and namespaces, and a new XCAP Application Unique ID; and (2) create a registry of "location profiles" (operating under the Standards Action policy). (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains two XML schemas and several example XML documents. I have validated that these XML structures are well-formed using the W3C automated validator (). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. Working Group Summary There is strong, long-standing consensus in the working group that the policies described this document are a useful way to transmit geolocation-based privacy policies. Document Quality The document has been reviewed by key participants from the GEOPRIV working group. |
2010-01-15
|
25 | Amy Vezza | [Note]: 'The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).' added by Amy Vezza |
2010-01-15
|
25 | Cindy Morgan | State Changes to AD is watching from Dead by Cindy Morgan |
2010-01-15
|
25 | (System) | This document has been resurrected. |
2010-01-14
|
25 | (System) | Document has expired |
2010-01-14
|
25 | (System) | State Changes to Dead from AD is watching by system |
2009-07-13
|
21 | (System) | New version available: draft-ietf-geopriv-policy-21.txt |
2009-06-08
|
25 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-06-08
|
25 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-02-09
|
20 | (System) | New version available: draft-ietf-geopriv-policy-20.txt |
2009-01-28
|
25 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Yes by Cullen Jennings |
2009-01-25
|
19 | (System) | New version available: draft-ietf-geopriv-policy-19.txt |
2009-01-20
|
25 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Abstain from Discuss by Lisa Dusseault |
2009-01-12
|
25 | Cindy Morgan | State Changes to AD is watching from Dead by Cindy Morgan |
2009-01-10
|
18 | (System) | New version available: draft-ietf-geopriv-policy-18.txt |
2009-01-08
|
25 | Cullen Jennings | I-D Resurrection was requested by Cullen Jennings |
2008-12-28
|
25 | (System) | State Changes to Dead from AD is watching::AD Followup by system |
2008-12-28
|
25 | (System) | Document has expired |
2008-06-26
|
17 | (System) | New version available: draft-ietf-geopriv-policy-17.txt |
2008-06-15
|
16 | (System) | New version available: draft-ietf-geopriv-policy-16.txt |
2008-03-30
|
25 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-03-29
|
15 | (System) | New version available: draft-ietf-geopriv-policy-15.txt |
2008-02-25
|
25 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-02-25
|
14 | (System) | New version available: draft-ietf-geopriv-policy-14.txt |
2007-11-15
|
25 | Cullen Jennings | State Changes to AD is watching::Revised ID Needed from AD is watching by Cullen Jennings |
2007-11-08
|
25 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2007-10-06
|
25 | Cullen Jennings | State Changes to AD is watching from AD is watching::AD Followup by Cullen Jennings |
2007-10-02
|
25 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-10-02
|
13 | (System) | New version available: draft-ietf-geopriv-policy-13.txt |
2007-09-21
|
25 | (System) | Removed from agenda for telechat - 2007-09-20 |
2007-09-20
|
25 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Tim Polk. |
2007-09-20
|
25 | Cullen Jennings | State Changes to AD is watching::Revised ID Needed from IESG Evaluation::Revised ID Needed by Cullen Jennings |
2007-09-20
|
25 | Cullen Jennings | I believe that some of the issues raised in discuss will need to go back to the working group for discussion. I am glad to … I believe that some of the issues raised in discuss will need to go back to the working group for discussion. I am glad to work with people to help figure out resolution to all of these. |
2007-09-20
|
25 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2007-09-20
|
25 | Chris Newman | [Ballot comment] I share many of Lisa's concerns. It is my suspicion that if the polygon feature remains in the initial publication that it will … [Ballot comment] I share many of Lisa's concerns. It is my suspicion that if the polygon feature remains in the initial publication that it will have to be dropped to advance to draft. Might be better to drop it now to save time. Is there a use case where rectangles or civic information is not sufficient? We already have consumer map services that omit information related to military installations and similar high-security locations. Perhaps that sort of omission will simply be built-into geopriv system and not need a standardized policy language of this complexity? |
2007-09-20
|
25 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-09-19
|
25 | Russ Housley | [Ballot comment] Consider a the four corners of Colorado. (Colorado is a rectangle.) Call the northeast corner A. Call the northwest corner B. Call … [Ballot comment] Consider a the four corners of Colorado. (Colorado is a rectangle.) Call the northeast corner A. Call the northwest corner B. Call the southwest corner C. Call the southeast corner D. It is pretty clear that ABCDA is a valid polygon. Is ACBDA a valid polygon? I do not see text that would tell me that such a polygon is not allowed, but such text could be in EPSG 4326 or EPSG 4979. I did not go look. I have writen algorithms to find a polygon that includes all of the provided coordinates, but that does not seem like the right thing to do here. The formula: n'=FLOOR(n*r + 0.5) * 1/r Can be simplified to: n'=FLOOR(n*r + 0.5)/r |
2007-09-19
|
25 | Russ Housley | [Ballot discuss] In section 6.5.2, the values in the table for n=38.89868 do not seem right. Working through the most simple case, where r=1.0, … [Ballot discuss] In section 6.5.2, the values in the table for n=38.89868 do not seem right. Working through the most simple case, where r=1.0, I get: 39.39868 = n*r + 0.5 39.00000 = FLOOR(n*r + 0.5) 39.00000 = FLOOR(n*r + 0.5) * 1/r |
2007-09-19
|
25 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2007-09-19
|
25 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-09-19
|
25 | Ron Bonica | [Ballot comment] Also agree with Lisa's DISCUSS |
2007-09-19
|
25 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2007-09-19
|
25 | Sam Hartman | [Ballot discuss] > > > Hi. > > I'm trying to think about the mechanisms in section 6 of the geopriv > document for reducing … [Ballot discuss] > > > Hi. > > I'm trying to think about the mechanisms in section 6 of the geopriv > document for reducing the granularity of location. I'm wonder though > how effective these mechanisms are in cases where in addition to > getting one-time location information I'm also seeing transitions in > location information. > > As an example if I see a transition from one building to a near by > building, I may well know much more about the civic location than > granularity. > > Similarly, I'm wondering how much information monitoring transitions > in geodetic location would help me in discovering where someone is in > the best case. I.E. where they are near a discontinuity in the > rounding. > > > If these concerns are real, I expect to see a discussion in the > security considerations at the very least. Depending on how serious > they are, we may need to work on mechanisms that do better. > |
2007-09-19
|
25 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-09-19
|
25 | Tim Polk | [Ballot discuss] Interdependencies between the civic and geodetic location information adds complexity that should be addressed in the Security Considerations section. I am specifically worried … [Ballot discuss] Interdependencies between the civic and geodetic location information adds complexity that should be addressed in the Security Considerations section. I am specifically worried about situations where differences in precision between the two location forms results in information leakage. I also see opportunities for error in the specification of rulesets in the two location formats, but it is unclear whether choosing a single form for rulesets is a practical alternative. |
2007-09-19
|
25 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2007-09-19
|
25 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-09-19
|
25 | Lars Eggert | [Ballot comment] Strongly agree with Lisa's DISCUSS. |
2007-09-19
|
25 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-09-19
|
25 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu |
2007-09-19
|
25 | Jari Arkko | [Ballot discuss] > However, > implementations SHOULD be prepared to accept small variations that > might occur depending on whether the the polygon is specified … [Ballot discuss] > However, > implementations SHOULD be prepared to accept small variations that > might occur depending on whether the the polygon is specified on a > plane in space, or only relative to the ellipsoid. I do not understand how to implement this. Please clarify. |
2007-09-19
|
25 | Jon Peterson | [Ballot comment] In section 6.5.2, does it make sense to have a practical maximum value for 'r', that is, before 'INF'? Nit Section 1, "does … [Ballot comment] In section 6.5.2, does it make sense to have a practical maximum value for 'r', that is, before 'INF'? Nit Section 1, "does not allow to control access" does not allow what to control access? Nit Section 6.4, "allows to reference" allows what to reference? |
2007-09-19
|
25 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded by Jon Peterson |
2007-09-19
|
25 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2007-09-18
|
25 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-09-17
|
25 | Lisa Dusseault | [Ballot discuss] These mechanisms are too complicated and don't give enough thought to how different user-agents are going to interact. In particular, one should imagine … [Ballot discuss] These mechanisms are too complicated and don't give enough thought to how different user-agents are going to interact. In particular, one should imagine setting a privacy policy with one user agent and then trying to edit it with another. It seems that geo-spatial policy creation requires some kind of user interface that includes a map. Is that correct? Are devices without maps then unable to modify or even read policies? I am not sure that the polygons are as cut-and-dried as they appear. I'd like to understand better: - how one knows what is the inside of the polygon, and what is the outside - ... how that interacts with poles and other problems mapping 2D to a sphere - how the altitude stuff works at all with client GUIs - when is altitude known and unknown, independent of knowing a rough long/lat position - whether you can define a polygon for "Alberta" and one for "Saskatchewan" and have any point be in one or the other or completely outside both -- but not *inside* both, and not stuck in-between When it comes to users viewing policies created in the past, the lack of human-readable labels and comments is going to be a real usability problem. What happens when a user or user-agent creates a non-sensical geo-political or geo-spatial location? Are all geo-political elements *really* allowed in conditions? One possible non-sensical policy would be "Show my location unless I'm in seat 32A". Aren't there any restrictions here? How are user agents supposed to handle mixed geo-spatial and civic location conditions? How would that be displayed or represented in a list of policy elements? With the dependency on geopriv-revised-civic-lo, this can't complete yet anyway. |
2007-09-17
|
25 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Discuss from Abstain by Lisa Dusseault |
2007-09-17
|
25 | Lisa Dusseault | [Ballot comment] This is very complicated (too flexible) for a privacy extension. I do not expect clients from different vendors to be able to interoperate … [Ballot comment] This is very complicated (too flexible) for a privacy extension. I do not expect clients from different vendors to be able to interoperate very well over the same policy information. I expect the end result of this to be cases where users believe they have privacy, or intend to have privacy, but do not achieve their goals due to difficulty of getting clients to interoperate with each other and with servers. |
2007-09-17
|
25 | Lisa Dusseault | [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault |
2007-09-04
|
25 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
2007-09-04
|
25 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
2007-09-04
|
25 | Cullen Jennings | Created "Approve" ballot |
2007-09-04
|
25 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings |
2007-09-04
|
25 | Cullen Jennings | State Change Notice email list have been change to jmpolk@cisco.com, Hannes.Tschofenig@siemens.com, schulzrinne@cs.columbia.edu, rjsparks@nostrum.com from mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, … State Change Notice email list have been change to jmpolk@cisco.com, Hannes.Tschofenig@siemens.com, schulzrinne@cs.columbia.edu, rjsparks@nostrum.com from mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, andy@hxr.us, schulzrinne@cs.columbia.edu |
2007-09-04
|
25 | Cullen Jennings | Placed on agenda for telechat - 2007-09-20 by Cullen Jennings |
2007-09-04
|
25 | Cullen Jennings | [Note]: 'Robert Sparks is PROTO Shepherd' added by Cullen Jennings |
2007-05-22
|
12 | (System) | New version available: draft-ietf-geopriv-policy-12.txt |
2007-03-13
|
25 | Cullen Jennings | Status date has been changed to 2007-03-26 from |
2007-03-12
|
25 | Yoshiko Fong | IANA Additional comments: > Extract section 9 for action #1. Section 8 for action #4. > > NOTE: document in section 11.4 (action #4) says … IANA Additional comments: > Extract section 9 for action #1. Section 8 for action #4. > > NOTE: document in section 11.4 (action #4) says Section 9 but the > corresponding XML schema looks like it is in Section 9. It should read: document in section 11.4 (action #4) says Section 9 but the corresponding XML schema looks like it is in Section 8. |
2007-03-12
|
25 | Yoshiko Fong | IANA Additional Comments: > Action #2: (see section 11.2) > Upon approval of this document, the IANA will make the following > assignments in the … IANA Additional Comments: > Action #2: (see section 11.2) > Upon approval of this document, the IANA will make the following > assignments in the "NS" registry located at > > http://www.iana.org/assignments/xml-registry/ns.html > ID URI Template Reference > geolocation-policy urn:ietf:params:xml:ns:geolocation-policy > [RFC-geopriv-policy-11] > > The XML schema to be linked to this entry is in section 11.2 of this > document. The XML schema corresponding to the namespace is in Section 9 and is registered by the IANA consideration section in Section 11.2. ----- > Action #4: (see section 11.4) > Upon approval of this document, the IANA will make the following > assignments in the "schema" registry located at > > http://www.iana.org/assignments/xml-registry/schema.html > > basic-location-profiles > urn:ietf:params:xml:schema:basic-location-profiles > [RFC-geopriv-policy-11] > > The XML schema to be linked to this entry is in section 9 of this > document, > > HERE IS A BUG: The reference should go to Section 8. The schema in Section 9 is already registered with Action #1. ---- > Action #5: (see section 11.5) > Upon approval of this document, the IANA will make the following > assignments in the "NS" registry located at > > http://www.iana.org/assignments/xml-registry/ns.html > ID URI Template Reference > basic-location-profiles > urn:ietf:params:xml:ns:basic-location-profiles > [RFC-geopriv-policy-11] > > The XML schema to be linked to this entry is in section 11.4 of this > document. > The XML schema corresponding to the namespace is in Section 8 and is registered by the IANA consideration section in Section 11.4. --- |
2007-03-07
|
25 | Yoshiko Fong | IANA Additional Comments: IANA has a QUESTION. ------------------- Extract section 9 for action #1. Section 8 for action #4. NOTE: document in section 11.4 (action … IANA Additional Comments: IANA has a QUESTION. ------------------- Extract section 9 for action #1. Section 8 for action #4. NOTE: document in section 11.4 (action #4) says Section 9 but the corresponding XML schema looks like it is in Section 9. IANA would like to ask editors if this is correct. |
2007-03-07
|
25 | Yoshiko Fong | IANA Last Call Comments: Action #1: (see section 11.1) Upon approval of this document, the IANA will make the following assignments in the "schema" registry … IANA Last Call Comments: Action #1: (see section 11.1) Upon approval of this document, the IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html geolocation-policy urn:ietf:params:xml:schema:geolocation-policy [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 9 of this document. Action #2: (see section 11.2) Upon approval of this document, the IANA will make the following assignments in the "NS" registry located at http://www.iana.org/assignments/xml-registry/ns.html ID URI Template Reference geolocation-policy urn:ietf:params:xml:ns:geolocation-policy [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 11.2 of this document. Action #3: (see section 11.3) Upon approval of this document, the IANA will create the following registry "Geolocation Policy Location Profile" located at http://www.iana.org/assignments/TDB Initial contents of this registry will be: Token description Reference geodetic-condition: Section 4.1. [RFC-geopriv-policy-11] civic-condition: Section 4.2. [RFC-geopriv-policy-11] geodetic-transformation: Section 6.5.2. [RFC-geopriv-policy-11] civic-transformation: Section 6.5.1. [RFC-geopriv-policy-11] Action #4: (see section 11.4) Upon approval of this document, the IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 9 of this document, Action #5: (see section 11.5) Upon approval of this document, the IANA will make the following assignments in the "NS" registry located at http://www.iana.org/assignments/xml-registry/ns.html ID URI Template Reference basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 11.4 of this document. Action #6: (see section 11.6) Upon approval of this document, the IANA will make the following assignments in the "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Parameters" registry located at http://www.iana.org/assignments/xcap-parameters ID Description Reference geolocation-policy Geolocation privacy rules are documents [RFC-geopriv-policy-11] that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location. We understand the above to be the only IANA Action for this document. |
2007-03-07
|
25 | Yoshiko Fong | IANA Last Call Comments: Action #1: (see section 11.1) Upon approval of this document, the IANA will make the following assignments in the "schema" registry … IANA Last Call Comments: Action #1: (see section 11.1) Upon approval of this document, the IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html geolocation-policy urn:ietf:params:xml:schema:geolocation-policy [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 9 of this document. Action #2: (see section 11.2) Upon approval of this document, the IANA will make the following assignments in the "NS" registry located at http://www.iana.org/assignments/xml-registry/ns.html ID URI Template Reference geolocation-policy urn:ietf:params:xml:ns:geolocation-policy [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 11.2 of this document. Action #3: (see section 11.3) Upon approval of this document, the IANA will create the following registry "Geolocation Policy Location Profile" located at http://www.iana.org/assignments/TDB Initial contents of this registry will be: Token description Reference geodetic-condition: Section 4.1. [RFC-geopriv-policy-11] civic-condition: Section 4.2. [RFC-geopriv-policy-11] geodetic-transformation: Section 6.5.2. [RFC-geopriv-policy-11] civic-transformation: Section 6.5.1. [RFC-geopriv-policy-11] Action #4: (see section 11.4) Upon approval of this document, the IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html basic-location-profiles urn:ietf:params:xml:schema:basic-location-profiles [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 9 of this document, Action #5: (see section 11.5) Upon approval of this document, the IANA will make the following assignments in the "NS" registry located at http://www.iana.org/assignments/xml-registry/ns.html ID URI Template Reference basic-location-profiles urn:ietf:params:xml:ns:basic-location-profiles [RFC-geopriv-policy-11] The XML schema to be linked to this entry is in section 11.4 of this document. Action #6: (see section 11.6) Upon approval of this document, the IANA will make the following assignments in the "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Parameters" registry located at http://www.iana.org/assignments/xcap-parameters ID Description Reference geolocation-policy Geolocation privacy rules are documents [RFC-geopriv-policy-11] that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location. We understand the above to be the only IANA Action for this document. |
2007-03-01
|
25 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-02-16
|
25 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2007-02-16
|
25 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2007-02-15
|
25 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-02-15
|
25 | Cullen Jennings | Last Call was requested by Cullen Jennings |
2007-02-15
|
25 | Cullen Jennings | State Changes to Last Call Requested from AD Evaluation::AD Followup by Cullen Jennings |
2007-02-15
|
25 | (System) | Ballot writeup text was added |
2007-02-15
|
25 | (System) | Last call text was added |
2007-02-15
|
25 | (System) | Ballot approval text was added |
2007-02-03
|
25 | Cullen Jennings | Status date has been changed to 2007-01-14 from |
2007-02-02
|
25 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-02-02
|
11 | (System) | New version available: draft-ietf-geopriv-policy-11.txt |
2007-01-24
|
25 | Cullen Jennings | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Cullen Jennings |
2007-01-24
|
25 | Cullen Jennings | Hannes is updating it. |
2007-01-24
|
25 | Cullen Jennings | State Changes to AD Evaluation from AD Evaluation::AD Followup by Cullen Jennings |
2007-01-08
|
10 | (System) | New version available: draft-ietf-geopriv-policy-10.txt |
2006-12-11
|
25 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-12-11
|
09 | (System) | New version available: draft-ietf-geopriv-policy-09.txt |
2006-09-22
|
25 | Cullen Jennings | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Cullen Jennings |
2006-09-22
|
25 | Cullen Jennings | Sent last comment in email. |
2006-08-24
|
25 | Cullen Jennings | I'm still working on this but had some initial questions that came up when reading it..... When the draft says The is of the … I'm still working on this but had some initial questions that came up when reading it..... When the draft says The is of the 'civicAddress' complex type defined in [RFC4119]. It includes a number of fields, including the country, expressed as a two-letter ISO 3166 code, and the administrative units A1 through A6 of [I-D.ietf-geopriv-dhcp- civil]. I'm a bit confused about where the A1 to A6 were defined. I thought they were in 4119 and not sure why the dhcp-civil ref is here. Section 8.2 Is the retention time in seconds? Section 8.4 It seems like in the figure, at the city level, the set should include A3 Is this extensible such that we could add in some other level? I'm not implying it needs more - I'm just asking if people have though about the level of extensibility here and are happy with it. Section 6.1 Do we need to specify any sort of particular rules for matching the strings here? I'm wondering about i18n type stuff. This may be find but give it some thought. Section 6.2.1 First of all, I like the general way you have gone about doing the polygon. I think you need to add the the edge of the polygon are the great circle arcs between the vertexes. The term polygon is confusing in that Polygon is a type in GML but is not the same as a polygon here. Might want to point that out. A Ring is an abstract class in GML, and the term LinearRing might be better for what we want. Might want to change this but it is not a huge deal. I suspect the algorithm for point in polygon that is specified here does not work for some polygons in spherical geometries but I'm not sure. Certainly it would need better definition of what "go right" means in the spherical sense. It you just use the planar version of it with lat, lon, it clearly won't work on polygons spanning the date line. I don't see why you need to have the last vertex repeated - i understand GML does that but that was largely historical and this is not GML any more so I think you should consider not doing this. Either way, be keep it explicit about it is repeated or not. The schema for polygon has min occurrence of 3 points but if you stay with the requirement that the first needs vertex to be repeated as the last, this should be 4. When doing a point in polygon test, we need more definition about what happens to points that are on the edge or vertex of the polygon. Altitude assumes WGS84 coordinate system but polygon allow others to be specified. Is this really what you want? References Move geopriv-common-policy to normative references Decide if you need the deopriv-dhcp-civil reference Remove xcap, webdav, and 3825 references Add an IANA section that says there are no IANA considerations. |
2006-08-24
|
25 | Cullen Jennings | [Note]: 'Allison Mankin <mankin@psg.com> is PROTO Shepherd' added by Cullen Jennings |
2006-08-24
|
25 | Cullen Jennings | Technical Summary This document defines the specific usage for controlling access to location information, given the framework for authorization … Technical Summary This document defines the specific usage for controlling access to location information, given the framework for authorization policies controlling access to application data provided in the already approved document draft-ietf-geopriv-common-policy. Access control authorization is specified using XML Schema in which policy rules are expressed. Work Group Summary This document represents the consensus of the GEOPRIV working group. Protocol Quality The document received careful review by geolocation application specialists participating in the working group. is the WG Chair shepherd and Cullen Jennings is the Responsible Area Director. o We have found one nit, the absence of a blank IANA considerations section. o [I-D.ietf-geopriv-common-policy] needs to be a normative reference o [I-D.ietf-geopriv-dhcp-civil] probably needs to be a normative reference Note to RFC Editor: Change the References section to 13, and add a new Section 12: 12. IANA Considerations This document contains no actions for the IANA. |
2006-08-24
|
25 | Cullen Jennings | State Changes to AD Evaluation from Publication Requested by Cullen Jennings |
2006-08-24
|
25 | Cullen Jennings | State Change Notice email list have been change to mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, andy@hxr.us, schulzrinne@cs.columbia.edu from mankin@psg.com, rg+ietf@qualcomm.com, … State Change Notice email list have been change to mankin@psg.com, jmpolk@cisco.com, rg+ietf@qualcomm.com, Hannes.Tschofenig@siemens.com, andy@hxr.us, schulzrinne@cs.columbia.edu from mankin@psg.com, rg+ietf@qualcomm.com, andy@hxr.us |
2006-08-10
|
25 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2006-05-07
|
25 | Cullen Jennings | Intended Status has been changed to Proposed Standard from None |
2006-03-28
|
25 | Cullen Jennings | Shepherding AD has been changed to Cullen Jennings from Ted Hardie |
2006-02-13
|
08 | (System) | New version available: draft-ietf-geopriv-policy-08.txt |
2006-02-06
|
25 | (System) | State Changes to AD is watching from Dead by system |
2005-10-26
|
07 | (System) | New version available: draft-ietf-geopriv-policy-07.txt |
2005-07-20
|
06 | (System) | New version available: draft-ietf-geopriv-policy-06.txt |
2005-06-04
|
25 | (System) | Document has expired |
2005-06-04
|
25 | (System) | State Changes to Dead from AD is watching by system |
2004-11-30
|
05 | (System) | New version available: draft-ietf-geopriv-policy-05.txt |
2004-10-28
|
04 | (System) | New version available: draft-ietf-geopriv-policy-04.txt |
2004-10-06
|
03 | (System) | New version available: draft-ietf-geopriv-policy-03.txt |
2004-09-01
|
25 | Ted Hardie | Draft Added by Ted Hardie in state AD is watching |
2004-07-21
|
02 | (System) | New version available: draft-ietf-geopriv-policy-02.txt |
2004-02-17
|
01 | (System) | New version available: draft-ietf-geopriv-policy-01.txt |
2003-11-03
|
00 | (System) | New version available: draft-ietf-geopriv-policy-00.txt |