Subject: [Geopriv] Submitted draft-ietf-geopriv-dhcp-lbyr-uri-option-07

From: "James M. Polk" <[email-masked]>
Date: Sun, 07 Mar 2010 16:38:34 -0600

I've updated the draft-ietf-geopriv-dhcp-lbyr-uri-option-07 ID.

I addressed what I believe is the final open issue (wrt allowing and 
IANA registering HTTP: and HTTPS: URIs), with incorporated text 
covering the conditions these are allowed -- which was offered by 
Richard. I didn't change his offered text (in Section 3.3). I also 
didn't delete any text in this version - only changed the dates, 
therefore, the diff should be easy to figure out  ;-) i.e., it should 
only be showing the paragraph Richard offered - which I thought 
addressed the open issue well.

Comments are welcome and appreciated

ABSTRACT
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends
this URI to.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-07.txt

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 9 Mar 2010 13:48:55 +0800

Hi James,

> I addressed what I believe is the final open issue [...]

Open issues that I'm aware of or have just noticed:

1. The means by which authorization rules are provisioned is not specified.

...nor is it declared out of scope.  Hannes and I have argued the point that this cannot be deployed without this missing piece.  Thus, this cannot be made out of scope just by declaring it so.  It's not an impossible problem, even though it might be difficult.

This remains my biggest issue with the document.  It's been an open issue for a while.  It might be nice to get WG consensus on this so we can stop wasting cycles on it (I think that it's been an open issue since the earliest versions of the doc).

2. Has this document been reviewed by the DHC WG?  

I've been subscribed there for a while now and I've not seen any emails on this draft.  I anticipate a problem relating to the way that this option does not use sub-options consistent with existing options.  Two reasons: the existence of the ver and resv parts (which I argue are not necessary [1]), and the length of the sub-option code is usually different in DHCPv4 and DHCPv6.

3. Valid-For is independent of the DHCP lease.  

I can see why this is necessary, but it introduces an interesting deployment problem.  One major DHCP implementation I'm aware of (and use daily :*( ) does not update individual options  independent of the lease.  The only effective way to update options with this implementation is to release the IP address and renew it.

Thus, it's going to be hard to get an updated URI if it is valid for less time than the lease duration.

4. RAIO (RFC 3046) is mandated with MUST-strength language.

This is not necessary.  While this might make sense where relays are employed, this is not necessary for successful deployment.  In our (relatively small) office, we use a flat network that does not employ relay agents.  This would not be an impediment to us deploying this option.

Furthermore, the draft talks about movement.  RAIO only provides information about the point of attachment when the DHCP request is made; later requests to the location URI might happen after the Target moves from this point.  Thus, the LS and LG need to be able to handle movement.

5. URI length.

Quoting the draft:

   Per [RFC2131], subsequent LuriElement Options, which are
   non-concatenated, overwrite the previous value.

This is OK, though I don't think that 2131 says anything about this at all.  Even 3396 says nothing about this.  Rules for handling sub-options are not defined for the general case, so it's good that you define them.  

Note that the draft talks about long URIs, which cannot be created based on these rules.  It might be worth pointing out the 255 octet limitation (which could be fewer characters).

6. URI character encoding.

The draft is silent on the way that URI characters are encoded into a sequence of octets.

7. (Easy one) the draft uses "Rule Holder" when it means "Rule Maker".

--Martin

[1] http://trac.tools.ietf.org/wg/geopriv/trac/ticket/26

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 8 Mar 2010 17:33:04 -0700

James -

Just finished a review. Attached is a Word version with comments. Mostly
small nits - some spelling, perhaps some missing prepositions. Also some
questions. I tries to read this as someone who is slightly familiar with the
technology area but no expert (easy for me!). For the most part, I was able
to follow and understand the content and application of the document. There
were a few instances where I became lost. There were also a few instances
where an additional definition or clarification of a term not used before in
the document would really help.

Overall, no conceptual or approach issues. Well written.

And of course I have probably incorrectly provided comments and suggested
edits, but when dealing with about a dozen standards orgs  . . .

Regards

Carl Reed
CTO
OGC

PS to OGC tstaff - just a FYI

----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 07, 2010 3:38 PM
Subject: [Geopriv] Submitted draft-ietf-geopriv-dhcp-lbyr-uri-option-07

> I addressed what I believe is the final open issue (wrt allowing and IANA
> registering HTTP: and HTTPS: URIs), with incorporated text covering the
> conditions these are allowed -- which was offered by Richard. I didn't
> change his offered text (in Section 3.3). I also didn't delete any text in
> this version - only changed the dates, therefore, the diff should be easy
> to figure out  ;-) i.e., it should only be showing the paragraph Richard
> offered - which I thought addressed the open issue well.
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Mar 2010 10:00:06 -0600

Martin

Thanks for the review

>1. The means by which authorization rules are provisioned is not specified.

please provide some suggested text

>...nor is it declared out of scope.  Hannes and I have argued the 
>point that this cannot be deployed without this missing 
>piece.  Thus, this cannot be made out of scope just by declaring it 
>so.  It's not an impossible problem, even though it might be difficult.
>
>This remains my biggest issue with the document.  It's been an open 
>issue for a while.  It might be nice to get WG consensus on this so 
>we can stop wasting cycles on it (I think that it's been an open 
>issue since the earliest versions of the doc).
>

it will be cross-WGLCd just like the past IDs that involve DHCP, 
unless things have changed that I didn't notice.

>I've been subscribed there for a while now and I've not seen any 
>emails on this draft.  I anticipate a problem relating to the way 
>that this option does not use sub-options consistent with existing 
>options.  Two reasons: the existence of the ver and resv parts 
>(which I argue are not necessary [1]), and the length of the 
>sub-option code is usually different in DHCPv4 and DHCPv6.
>
>I can see why this is necessary, but it introduces an interesting 
>deployment problem.  One major DHCP implementation I'm aware of (and 
>use daily :*( ) does not update individual options  independent of 
>the lease.  The only effective way to update options with this 
>implementation is to release the IP address and renew it.

that isn't necessarily true, and I'm not going to propose limiting 
this doc to how 1 implementation does things.

If the valid-for is the same as the lease time, then the valid-for 
isn't necessary. That's why it's optional. Roger Marshall really 
wants this, so I incorporated it, and there might be times where the 
lease of an IP address (or other DHCP Options) is different than the 
time a location URI is to be considered *not stale*. The two do not 
have to be bound to the same timeframes, though sometimes they will 
be.  I believe it flexibility here.

>This is not necessary.  While this might make sense where relays are 
>employed, this is not necessary for successful deployment.  In our 
>(relatively small) office, we use a flat network that does not 
>employ relay agents.  This would not be an impediment to us 
>deploying this option.

This is a fair observation. I'll change the text to say something like this

         "RFC 3046 SHOULD be utilized, however, where relays are not
         deployed, the RAIO Option is not necessary."

>Furthermore, the draft talks about movement.  RAIO only provides 
>information about the point of attachment when the DHCP request is 
>made; later requests to the location URI might happen after the 
>Target moves from this point.  Thus, the LS and LG need to be able 
>to handle movement.

a lot of the time, RAIO will be tied to the wiremap database, which 
is necessary.

When a device is mobile, the RAIO will indicate which AP the Target 
is attached to, so I also think this is necessary.

>This is OK, though I don't think that 2131 says anything about this at all.

In past drafts, the DHCP WG did in fact correct me about the 255 length.

Their opinion is that if a URI is longer than 255 bytes, "you need to 
pick a new URI".

Therefore something like what 3396 proposes should cover us pretty 
well for the small number of cases that URIs go a little bit over.

>Even 3396 says nothing about this.  Rules for handling sub-options 
>are not defined for the general case, so it's good that you define them.
>
>Note that the draft talks about long URIs, which cannot be created 
>based on these rules.  It might be worth pointing out the 255 octet 
>limitation (which could be fewer characters).
>

what do you suggest?

>7. (Easy one) the draft uses "Rule Holder" when it means "Rule Maker".

Even simpler -- RFC 3693 says "Rule Holder", so I'm not changing 
anything.  The idea of a "Rule Maker" might have been made up by me 
for all I know, but it has permeated list and meeting discussions -- 
but it is not what the Geopriv Requirements RFC calls the entity.

Thanks

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Mar 2010 07:22:54 +0800

Responses inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Wednesday, 10 March 2010 3:00 AM
> To: Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Submitted draft-ietf-geopriv-dhcp-lbyr-uri-
> option-07
> 
> Martin
> 
> Thanks for the review
> 

I think that we've had discussions about this a number of times, but we don't have consensus on a particular solution.  Until the WG has consensus, it's hard to propose text.  As the draft editor, I'd suggest that it is your responsibility to start and guide discussion on this.  I'm not interested in deploying this option, so don't try to push the problem on me.

Richard proposed one such solution, which might be appropriate.

> unless things have changed that I didn't notice.

Why wait until WGLC?  I have concerns now, but I've not had them addressed to my satisfaction.
 
> be.  I believe it flexibility here.

I think that the concern here is that the expiration of the information is different to the lease time, which introduces real problems in updating this data.

> >4. RAIO (RFC 3046) is mandated with MUST-strength language.
...
> is attached to, so I also think this is necessary.

RAIO can't provide a DHCP server with information about the current point of attachment of a Device when a URI is dereferenced.  It only provides information when the Device makes a DHCP request.  Thus, making it mandatory is largely pointless for this scenario.  It might be helpful, but since we're making location determination out of scope, it's not really necessary to describe these sorts of details.

> well for the small number of cases that URIs go a little bit over.

You can't go "a little bit over".  Based on my reading, URIs cannot exceed 255 bytes.  It would be nice if the draft said this directly.

> >The draft is silent on the way that URI characters are encoded into

UTF-8
 
> but it is not what the Geopriv Requirements RFC calls the entity.

<http://tools.ietf.org/html/rfc3693#page-5>:

      Rule Holder: The entity that provides the rules associated with a
         particular target for the distribution of location information.
         It may either 'push' rules to a location server, or a location
         server may 'pull' rules from the Rule Holder.

      Rule Maker: The authority that creates rules governing access to
         location information for a target (typically, this it the
         target themselves).

draft-ietf-geopriv-arch doesn't mention rule holder at all.  It's a role that has no great influence on scenarios.

--Martin

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Mar 2010 14:05:33 -0600

in-line

At 05:22 PM 3/9/2010, Thomson, Martin wrote:
>I think that we've had discussions about this a number of times, but 
>we don't have consensus on a particular solution.  Until the WG has 
>consensus, it's hard to propose text.  As the draft editor, I'd 
>suggest that it is your responsibility to start and guide discussion 
>on this.  I'm not interested in deploying this option, so don't try 
>to push the problem on me.

Martin - you have stated you have a problem with an ID, it's on you 
to offer an alternative -- preferably in the form of text that can be 
pasted into the ID.  It's been this way in the IETF for more than a 
decade. Please... ask Brian, as I know you don't/won't believe me.

As author, I have offered a solution. Stating that "that ain't gonna 
work" isn't enough most of time, if you expect to make progress. 
Stating you have no intention of deploying what's specified in a 
particular ID is great -- but don't poke wholes in it without 
sufficiently supplying what you consider to be a sound alternative. 
You are admitting you will not (by stating above "As the draft 
editor, I'd suggest that it is your responsibility to start and guide 
discussion on this").

>Richard proposed one such solution, which might be appropriate.

if you have knowledge of such a solution -- please cute and paste his here

>addressed to my satisfaction.

then you bring them to the other WG, if you feel so strongly. No one 
is holding you back.

>I think that the concern here is that the expiration of the 
>information is different to the lease time, which introduces real 
>problems in updating this data.

no it doesn't. if a client's <valid-for> timer goes off before the 
lease timer, the client asks for an updated location URI. That 
doesn't mean it has to ask for every other DHCP Option at the same time.

>RAIO can't provide a DHCP server with information about the current 
>point of attachment of a Device when a URI is dereferenced.

nor can it ever, that's why it becomes the burden of the client to 
request for a fresh location URI whenever its attachment changes, or 
the device power cycles.

>It only provides information when the Device makes a DHCP 
>request.  Thus, making it mandatory is largely pointless for this scenario.

in the above sentence, what is "it" referring to (the device, the 
server, the location URI or the RAIO)?

>It might be helpful, but since we're making location determination 
>out of scope, it's not really necessary to describe these sorts of details.

same question as above -- in fact, it seems you have "it" in the 
above sentence describing two different things, which I can't make out.

>You can't go "a little bit over".  Based on my reading, URIs cannot 
>exceed 255 bytes.

Directly quoted from Section 3.:

"It is RECOMMENDED to avoid building URIs, with any parameters,
    larger than what a single DHCP response can be.  However, if a
    message is larger than 255 bytes, concatenation is allowed, per RFC
    3396 [RFC3396]."

>It would be nice if the draft said this directly.

hmmm .... guess it does after all...  ;-)

> > >The draft is silent on the way that URI characters are encoded into

I can add that as the encoding, np

(see, I'm not totally unreasonable)

>          location information for a target (typically, this it the

oops - I'm wrong here.

So, in Section 1, there's this text about the LS and the Rule Holder:

"A Location Server (LS) stores the Target's location as a presence
    document, called a Presence Information Date Format - Location
    Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
    is the entity contacted during the act of dereferencing a Target's
    location.  If the dereferencing entity has permission, defined in
    [ID-GEO-POL], the location of the target will be received.  The LS
    will grant permission to location inquires based on the rules
    established by a Rule Holder [RFC3693].  The LS has the ability to
    challenge any request for a target's location, thereby providing
    additive security properties before location revelation. "

You're saying that the Rule Holder doesn't "establish" the rules, but 
contains the rules, right?

If I did a s/establish/contained

would you be satisfied with that?

As Jon Peterson has stated many times, the Target isn't the only one 
setting rules for acquisition of location - often it is the ASP 
(which could be acting according to a Judge's ruling - is his 
frequent example).

>draft-ietf-geopriv-arch doesn't mention rule holder at all.  It's a 
>role that has no great influence on scenarios.

Rule Makers make the rules. There can be, and likely are more than 
one Rule Maker affecting the location of each Target -- effectively 
making the Rule Maker the Location Policy Server.

What entity is contains all those rules?

RFC 3693 says the rules are stored in the Rule Holder, which the 
Location Server explicitly contacts.

What takes the place of the Location Policy Server in draft-ietf-geopriv-arch?

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Mar 2010 06:07:15 +0800

> decade. Please... ask Brian, as I know you don't/won't believe me.

I'm not interested in getting into arguments of that nature.

If you want suggested text, here's some:

  This location URI operates under the "authorization by possession" model, described in [lbyr-requirements].

That's my preference, and I've not seen good arguments that support your selected model.

> then you bring them to the other WG, if you feel so strongly. No one

There's nothing stopping you from addressing my concerns, either.

> server, the location URI or the RAIO)?

It == RAIO

> hmmm .... guess it does after all...  ;-)

That's not what I'm talking about.  I'm talking about a statement like:

  'A URI included in this option is constrained to 255 octets in length.'

> contains the rules, right?

Right.

> If I did a s/establish/contained

I think that it would be more helpful to use Rule Maker than Rule Holder.  I personally don't find Rule Holding to be especially relevant to the discussion.  It's a necessary function, with real security and privacy considerations, but it's a passive rather than active role.

...

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Mar 2010 18:31:16 -0600

At 04:07 PM 3/10/2010, Thomson, Martin wrote:
>   This location URI operates under the "authorization by 
> possession" model, described in [lbyr-requirements].

lbyr-reqjuirements is rooted from a HELD ID, I believe. HELD has the 
concept of identity and of TLS to protect that HTTP based protocol in 
transit.  DHCP has no such protection, therefore possession of a 
location URI shouldn't grant access to a DHCP client's location 
without a challenge from the requested resource/entity. I don't 
believe a possession model works when there is no change of secure 
communication to a Target.

>There's nothing stopping you from addressing my concerns, either.

I am addressing them, at least for the valid ones.

But you're right, this isn't just about you and me. The trick is, I'm 
not hearing from the rest of that WG that supports your points. I 
might hear from 1 other person, but the two of you do not represent 
the WG either (I've heard from a few that support the way it is).  It 
takes more than 2 to reach consensus of a WG. Surely that's obvious 
to all concerned. Right now, there is no consensus this WG document 
needs to change, and it shouldn't until such consensus is reached.

> > server, the location URI or the RAIO)?

thanks for clarifying

Here's an issue with HELD too, it's only valid if the Target doesn't 
move since it last requested location; else, the location is 
invalid/stale.  There is no difference with DHCP (by value or with a 
locaition URI).

>   'A URI included in this option is constrained to 255 octets in length.'

without the exception - which I quoted - it is constrained to 
255.  Perhaps I can either say something like:

         Location URIs are normally or RECOMMENDED to be less than 
255, to comply with existing DHCP practices. Exceptions can be met by 
following RFC 3396."

> > contains the rules, right?

ok

>I think that it would be more helpful to use Rule Maker than Rule 
>Holder.  I personally don't find Rule Holding to be especially 
>relevant to the discussion.  It's a necessary function, with real 
>security and privacy considerations, but it's a passive rather than 
>active role.

The Rule Holder is who is asked for the location, or for the 
policy(ies) for location distribution by Location Servers (per RFC 
3693 - which the -arch- isn't obsoleting BTW. Therefore I'm going to 
have to think a little more about how to use the terms in a consistent way.

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Mar 2010 14:10:01 +0800

Hi James,

More below.

> communication to a Target.

Possession model works well enough.  If DHCP is secure enough for location by value, it is good enough for possession model.  ...by virtue of possession model sharing security properties with location by value.

> Right now, there is no consensus this WG document

I don't want to get entangled in minutiae, but I could equally argue that there is no consensus for the current form of the document.

> invalid/stale.  There is no difference with DHCP (by value or with a

That's true for provision of location by value, but not for location by reference.  The location URI can be dereferenced at any time after the initial HELD or DHCP request, at which time the location server can (and should) acquire fresh location information.  RAIO doesn't help the LS in this task.  Thus, I conclude that while it might provide marginal assistance where the URI is dereferenced shortly after the URI is minted, it doesn't provide any tangible aid in the time after that.

> 255, to comply with existing DHCP practices. Exceptions can be met by

As it stands, a location URI cannot be 256 octets long.  The length field for the sub-option is one octet and sub-options aren't concatenated.  Get a bigger sub-option code, or allow concatenation and this might apply; otherwise, you're stuck with a hard limit.  

I'd also point out that 2119 language wont change this, so I'd argue that capitalization is pointless.

Also, to get to 255 octets, you need RFC 3396 because of the overhead in the option (ver, resv, sub-option code and length), so 3396 is worth a mention, but not for this.
 
> have to think a little more about how to use the terms in a consistent

Actually, the Location Server is the one that is asked for location.

In other architectures, the Location Server and Rule Holder are distinct entities.  There is a protocol interface between the LS and the Rule Holder for the Rule Holder to communicate authorization decisions about specific requests.  (e.g., LS asks can person X get person Y's location?  Rule Holder says yes/no/maybe...)

--Martin