Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I can see where the document is going and I feel that the security considerations section appropriately matches it. In my scan of the document, I did find a number of editorial issues. Perhaps another scrub of the document would be in order. Below are some of the items that I had issues with. In the sentence, The DHCP implementation of the client can then make this location information available to upper layer protocols for their usage. Would it be more appropriate to replace "upper layer protocols" with "other applications"? Then just remove "using upper layer protocols" from the following paragraph for consistency. PIDF-LO is not defined or referenced until its third use. It may just be best to swap paragraphs 4 and 3 in that section as the text flow seems to be a bit more logical that way. That would also then have an appropriate reference to the first use of PIDF-LO. current: The LS will grant permission to location inquires based on the rules suggested: The LS will grant permission to location inquiries based on the rules ^^^^^^^^^ The following two paragraphs should be combined. Server operators should consider the relation between the Valid-For time and the lease time. Clients typically request a lease refresh when half the lease time is up. If the Valid-For time is less than the typical refresh rate (i.e., half the lease time), then for the remaining interval, clients will run the risk of not having a usable location URI for applications. If the Valid-For time is less than half the typical refresh rate, it is a near certainty clients will not have a usable location URI for the interval between the Valid-For time and the typical refresh time for applications. For example, if a lease is set to 24 hours, the typical refresh request is set to initiate at the 12 hour mark. If the Valid-For timer is set to less than 24 hours, but more than 12 hours (in this example), the client might not be refreshed at the 12 hour mark and runs the risk of not have a location URI for applications that request it. If, on the other hand, the Valid-For timer is less than 12 hours (in this example, which is before a typical client would ask for a refresh, applications will be without a usable location URI until the full refresh has been received. In the following sentence, maybe s/identities/identifies ? In the element of a PIDF-LO document, there is an 'entity' attribute that identities what entity *this* document (including the associated location) refers to. Beyond that, it is unclear how the term "document" is being used in this context. Perhaps use "this specification" when appropriate? The first part of the following sentence indicates that there is one model. The second half of that sentence indicates that there are multiple models but doesn't indicate the context (models of what?). Can you clear that up? o The authorization vs. possession security model can be found in [RFC5808], describing what is expected in each model of operation. First, the following sentence needs to be straightened out. Second, just because IANA registers them doesn't mean that URI schemes or types cannot be misused or will not be harmful. Instead of listing all the types of URIs and URLs that can be misused or potentially have harmful effects, Section 3.3 IANA registers acceptable location URI schemes (or types). In most places you quote the uri type but in the following you don't quote "pres:" in the following: See RFC 3922 [RFC3922] for using the pres: URI with XMPP. Maybe that should be: See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP. I have an issue with the following: When implementing a DHCP server that will serve clients across an uncontrolled network, one should consider the potential security risks therein. Actually, this is the section to describe all these risks. You may consider referencing RFC 3552 and restate as: In some cases a DHCp server may be implemented across an uncontrolled network. In those cases, it would be appropriate for a network administrator to perform a threat analysis (see RFC 3552) and take precautions as needed. Is "revelation" common nomenclature for this? "security properties before location revelation" Perhaps revise as: "security properties before location assertion" The acronym "LCI" is not defined in the text. current: In enterprise networks, if a known location is assigned to each individual Ethernet port in the network, a device that attaches to the network a wall-jack suggested: In enterprise networks, if a known location is assigned to each individual Ethernet port in the network, a device that attaches to the network, such as a wall-jack, ^^^^^^^^ The acronym "RIAO" not defined in the text. current (Yoda speak?) ;-) : A real concern with RFC 3118 it is that not widely deployed because suggested: A real concern with RFC 3118 is that it is not widely deployed because ^^^^^^^^^^^^^^ You use LocationURI once but never reference that to luri. It might be nice to reference it once to people unfamiliar with this work (such as I :) In the following, is that supposed to be aTlanta? sips:aliceisat123mainstalantageorgiaus at example.com Thanks, Chris