Re: [Geopriv] draft-ietf-geopriv-dhcp-lbyr-uri-option-03 comments

From: Thomson, Martin ^lt;>
Date: Fri Nov 21 2008 - 15:38:51 EST

Hi James,

Select responses inline; the rest cut in the interest of size.

> >The URI itself is a "Location URI" by that terminology. The draft
> >later refers to Location-URI, which is better (without the hyphen
> >would be better again).
> I prefer to include the hyphen

I prefer consistency between documents. My understanding of grammar suggests that a hyphen in this case is incorrect.

> >I don't know what an "LbyR record" is by the following sentence:
> > "The LbyR record stores the Geolocation of a Location Target."
> I think this is pretty obvious what this is, it's the location data
> at the URI, stored as a record on a server. This isn't a reach. As
> much as folks tell me "things are obvious", I believe this is at
> least as obvious.

Location by reference (lbyr) is a term for the method, a location URI is the record used within that. The term "LbyR record" has a very imprecise meaning that _could_ mean location URI, but could equally mean a log of messages related to location by reference.

> > " The act of dereferencing location is explained in [ID-SIP-CON],"
> >...assuming that the URI is a sip: or sips: URI.
> but it is, per this spec -- see the IANA section

Actually, per the spec, the method for dereference depends on the URI scheme. You've just limited the scope by only providing registrations for the one protocol. On the other hand, allowing registration also means that you have to be more careful in how you approach the discussion. Suggestion:

  This document allows for the inclusion of a pres:, sip: or sips: URI in this option. A method for dereferencing these URIs is described in [ID-SIP-CON].

> > (Actually, I suspect that part of the problems with delay on SIP
> > location conveyance stem from this
> conveyance is delayed because of the retransmision ID *only*, not
> this topic at all.

Keep in mind that this is my opinion only, and not intended as a personal attack, but I still find that conveyance suffers from a readability problem.

> > It would have been easy to label dereference as out of scope
> huh? both this ID and conveyance deal with location-uris... how is
> dereferencing out of scope of both docs?

We've left the actual dereference mechanism out of scope in HELD to keep the focus tighter. Neither this ID, nor conveyance, actually need to say anything. When you make the choice to include these, you also increase the complexity.

> > Better to say that the means for dereference is URI scheme
> > specific; that each scheme needs the following considerations
> documented;
> > and that sip:, sips: and pres: are included in this document...
> this lbyr-option ID does state - and IANA register - sip:, sips: and
> pres: ...

The text in the document is not consistent with that decision, as I pointed out above.

> > "If the dereferencer has permission, defined in [ID-GEO-POL],"
> >I don't think that it is necessary to reference a particular
> >authorization policy document extension.
> Hannes (very definitely) disagrees with you on this point. This is
> also addressing a James W. concern about this ID not discussing how
> policies get to/from the client & LIS.

Simply adding a reference to geopriv-policy does not solve the problem. The document defines a subset of a format for expressing policy, but none of the mechanisms. You need to either specify the entire mechanism, or avoid it. I suggest avoiding it explicitly:

   The LS MUST authorize requesters based on rules provided by the Rule Maker. How the Rule Maker provides rules to the LS is not defined by this document.

(I don't like MUSTs in introductory text, and Rule Maker needs to be defined, but I'll leave that up to the editor to manage.)

> >I don't even think that geopriv-policy is likely to apply to many
> >cases. common-policy contains the most important and useful
> >component for authorization policies: identity.
> Are you suggesting 4745 is more applicable than geopriv-policy? Or
> are you suggesting both are needed?

4745 would be more applicable than geopriv-policy, but see above for why neither works.

> > I think that all that is necessary here is to state that an
> > authorization policy MUST be established and applied for the URI.
> >
> >"Location Seeker" is a new (undefined) term.
> no. Martin, this is one of the first terms Geopriv defined, way before
> 3693.

The point remains. The term is undefined in the draft. There is no RFC that uses this term that you can refer to for a definition.

> >What is wrong with Location Recipient?
> because the Recipient might not be the one that asked for the
> location. This is especially true if you believe that all entities
> that receive location within a packet are to be considered a Location
> Recipient. If you believe this philosophy, the Location Seeker is
> the one that asked for the location to be sent to them. All entities
> between the Location Target and Location Seeker are potential
> Location Recipients.
> I happen to believe there is a difference between Location packet
> receivers and consumers of location.

I happen to disagree with this point. We are finessing the point in retransmission by saying that each proxy is implicitly a Location Recipient.

Rather than invent new terms, I'd suggest that you stick to the documented model.

> > "The Location Server will grant permission to location inquires
> > based on the rules established by a Rule Holder [RFC3693]."
> >Rules are established by Rule _Makers_, Rule Holders don't factor
> >into this unless you are defining mechanisms for moving and storing
> >rules, but I'm getting the impression that this is out of
> >scope. Please state that this is the case.
> Are you saying Rule Makers & Rule Holders are separate entities?

Yes. Read 3693.

> If you are, please reread RFC3693 to see there are no Rule Makers,
> there are only Rule Holders.

Is there a special James M. Polk edition of RFC 3693 that I'm not aware of?

> > "Option."
> this "option" word and the paragraph below seem to be different
> points you are making, but I cannot parse the single word you have
> above to know what issue you have with "Option". Please retry.

Search for this phrase (less quotes). It appears as extra document noise on the bottom of the first page.

> >The terms "additive security properties" and "location revelation"
> >would be more useful if they were adequately defined.
> location revelation isn't a term, it's 2 words put together that have
> meaning. Together they mean 'revealing location'.

When you do this, you invent a term. It works in poetry and non-formal prose, but it is not appropriate for a specification.

> >As it is, the statement is a little vague. A simple reference to
> >the authorization model defined in the lbyr-requirements draft should
> suffice.
> >
> >Use of the term "UA" to refer to the target/host/device/thing needs
> >to be considered. As a draft that is primarily DHCP focused, the
> >use of "host" would seem--to me--to be most appropriate.
> In DHCP, client is best. And I state that clients can be UAs. I
> don't believe this is a stretch

This is an instance of an syllogistic fallacy. Because a UA is (or can be) a client it doesn't mean that a client is a UA.

> >Page 4, paragraph 1. There is a bit of a non-sequitur in this
> >paragraph that threw me. Talking about wiremaps and 3825/4776 is
> >all OK, but it seems to be trying to justify this document on those
> >terms - and that doesn't really work.
> this was put in because of James W.'s demand that "something" needed
> to be said about how in the world DHCP could every tie a walljack to
> a specific location. I'd rather not have to explain this - since I
> believe it's obvious this is what occurs in an enterprise.

My alternative proposal is that you purposefully place the method for location determination out of scope.

> >I think that this just needs to worded differently and have the focus
> changed:
> > "RFC 3825 and RFC 4776 provide location by value through
> > DHCP. This document defines how location information can be
> > provided by reference in DHCP."
> >There's a lot missing there, but I don't think that you need to
> >discuss RAIO and the actual serving of the location URI probably
> >needs more thorough treatment than an off-hand remark about the
> >backend of the network.
> Again, all the backend stuff is from James W.

Stop shifting blame. You are the editor.

> >s/Option/option/g
> >
> I capitalize Option when I talk about a DHCP Option (because the DHCP
> WG does this too).

Yuck. Oh well.

> >" This Option can be useful in WiMAX connected endpoints or IP
> > cellular endpoints."
> >
> >I have to question the usefulness of this statement. I know why
> >it's there. I know that it is true because it is, in theory,
> >possible. But it's also ultimately misleading because whether or
> >not this option is used in those networks (and I'm not aware of
> >plans to do so) depends entirely on the specific architectures
> >adopted in those forums.
> this is chicken and egg. They won't specify it before there is an RFC
> defining it. Once we RFC this, a lot of other SDO's specs will
> define it. If the IETF is chartered to define the protocols, we need
> to lead the timing.
> PacketCable is another example I could use.

Two reasons for my objection to the statement:
 1. I personally thing it's a "Bad Idea". That's a personal view based on my experience of the domain. I wont explain further because I think that the second is enough...
 2. You should make a statement based on the attributes of networks, not name specific networks. The following statement is also true:
   "This Option [sic] can be useful in networks that deploy DHCP."
   Of course, that's also a pretty pointless statement.

> >" The Location-URI Option can be configured as a
> > client if it is a router, such as a residential home gateway, with
> > the ability to communicate to downstream endpoints as a server."
> >The second statement doesn't make sense.
> that's the design of nearly every home broadband router.

It was a grammatical comment, not a technical one. This is a really hard sentence to parse correctly.
> >I think that you want to say that a router that is a DHCP client on
> >one side and DHCP server on the other can relay this information if
> >it doesn't cover a large enough area.
> I am saying this.

You make no mention of the limitations - it is not appropriate to forward the information onward if the NAT/router serves a large geographic area (obviously, there's a need to apply common-sense, there are no guarantees).

> >That might have been true for location by value, but there are some
> >problems with location by reference. For instance, two siblings
> >live in the same house, use the same Internet access (paid for by
> >their parents), but have completely different privacy
> >preferences. So, each provides an authorization policy. The net
> >effect is that either set of friends can get their location. No
> >problem? Right? Wrong. If one sibling doesn't want a particular
> >friend of their other sibling to know where they are, they cannot
> >prevent this.
> I think you are making a fundamentally incorrect assumption that it
> is impossible to have two different location-uris for each
> sibling. If you can have this, and this version of the ID allows
> that - then each sibling can have different rules for different
> location-uris.

How would it be possible to get two different location URIs through a router that relays the URI it gets to all its clients?

> But, it might be the case that the parents are the Rule Holder for
> each child.... this blows up the idea of independent rules
> ;-)

"Siblings", not children ;)

> An analogy exists in which any child gets a separate phone number
> within the same house. Either phone number can be unlisted, and are
> independent to each other, based on who's paying for the service.

Exactly. I get the impression that you understand the use case. However, I don't think that you have the mechanism that supports it.

I'll raise this in another email.
> >Section 2.1: what, if any provisions are made for the propagation
> >delay between the server and the host?
> >
> >" It is RECOMMENDED when the counter associated with this <valid-for>
> > value has passed, the client perform a refresh of this Option."
> >I think that the key word "half" is missing from this statement,
> somewhere.
> I don't understand how "half" can be added to this sentence and make
> any sense. I also don't understand why this sentence needs to say
> "half" anything.
> ultimately, no, I don't make any provision for a delay. What's the
> worst case scenario? a second? 3 seconds? is that something that
> needs to be accounted for - or is this chasing a insignificant corner-
> case?

If you don't request another URI _before_ it expires, you have a gap where you don't have a valid URI. I was obliquely suggesting that the re-request time be at half of the valid-for time. It really only needs to be re-requested some time before it expires, but you have to account for the request delay, plus any delay that occurred when you got it.

> >Do you realise that the absolute maximum time that this URI can be
> >"valid-for" is just a little over 18 hours. That almost guarantees
> >that clients will be updating this option faster than the standard
> >DHCP lease. Why not use minutes, or some other multiple that will
> >allow for a slightly longer interval?
> ok, I didn't realize that. Are minutes not granular enough? I'm ok
> with moving this field to minutes.

Minutes are probably granular enough (opinion). That gives you 45 days.

> >Why does the client care about which server answers the request?
> because that is something the DHCP WG and the IESG cared about with
> anything DHCP based coming out of Geopriv, so I believe this will be
> necessary.

What security assurance does that give you? The key assurance you want is that the DHCP server isn't lying to you. As long as it isn't lying, it doesn't matter what server is in the URI.

> >I don't see that the size of the location URI in this case to be a
> problem.
> I've been told by the DHCP WG to account for this. That's good enough
> for me.

That's fine, but you should realise that there is no inherent need for large addresses. They only need to conform to the requirements in the lbyr-requirements. That's a mitigating factor that should be documented.

> >Discussion of the LIS function, how the DHCP server acquires or
> >generates the URI, and so forth isn't really necessary.
> Again, this is something James W. wanted even more of than is in this
> doc - so which of your comments/concerns (from the same company) do I
> satisfy? I'm caught between the two of you.

I happen to share James' concerns that this draft will suffer in deployment. I just happen to disagree with the way in which you have chosen to address those concerns.

When you, as document editor, address comments, try to work out why someone is making these comments before you try to patch the document. Your task is the hard one of ensuring that the document retains its integrity.

> >Section 3.2: Harmful URIs and URLs: This section isn't helpful.
> This is exactly what Lisa D (APPs AD) wanted put in.

Because you like Wikipedia, here's a link for you:

> >Rather than making sweeping statements about "security concerns",
> >it's more constructive to state the conditions for entry. My
> >suggestion: each URI needs documentation that explains how it is
> >used, along with any potential caveats. For instance, rather than
> >state: " this Option SHOULD NOT be sent to a general-browser",
> >state: "any URI scheme that does not have documentation describing
> >how it can be used as a dereference protocol MUST be ignored by the
> >host". Then go on to reference each of the dereference protocols
> >that are acceptable on the first pass and the matching URI schemes.
> this seems like a maneuver to both increase the size of this doc
> (i.e., double it) and delay it. I really don't accept either.

If you think that I spent as much time as I did in reviewing this document because I don't want it to succeed, I'm sorry that you think that way. It must be tough.

This section should not state "xxx: is bad". It should describe what attributes are necessary. This isn't hard - specification required already covers most of it - just ask for security considerations for the dereference protocol.

We already have a document that covers what properties are desirable in location URIs. Maybe there is something that you could learn from that.

> >I've read this before somewhere, but it still doesn't seem to add
> value:
> >" When implementing a DHC server that will serve clients across an
> > uncontrolled network, one should consider the potential security
> > risks therein."
> this is in 3825 because Jon Peterson wants this in all DHCP docs that
> come out of Geopriv - therefore it stays until he tells me to remove
> it.


This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
Geopriv mailing list
Received on Fri, 21 Nov 2008 14:38:51 -0600

This archive was generated by hypermail 2.1.8 : Fri Nov 21 2008 - 15:39:06 EST