Subject: [Geopriv] "conveyance protocols" in lo-sec-05

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Mar 2009 00:35:13 -0500

Richard

"Conveyance protocols" are protocols such as SIP, and LCP protocols 
are like DHCP, HELD and LLDP-MED.

Clearly SIP vs. DHCP/LLDP-MED are different types of protocols doing 
different functions. For example, the former protocol controls 
identity, and each of the latter protocols cannot.

Since when did DHCP become a conveyance protocol, and what's the 
justification for the reclassification?

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 16 Mar 2009 00:48:29 -0500

I don't see why you would have a problem with this.  It's a label, which is only relevant if there are associated changes in expectations.  Don't worry that the goalposts have moved.

By the model described in lo-sec, an "LCP" is a conveyance protocol.  For DHCP, that changes nothing, because the model describes a different set of constraints on conveyance protocols.  Lo-sec allows an LS to distribute LI to a Target - which is what DHCP does.

Saying the DHCP doesn't "control identity" (whatever that means) was never a good basis for distinction - lo-sec gives what LCPs do greater credibility.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Monday, 16 March 2009 4:35 PM
> To: [email-masked]
> Subject: [Geopriv] "conveyance protocols" in lo-sec-05
> 
> Richard
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Mar 2009 11:12:03 -0400

Piling on:

I thought we had agreement on this part of the terminology:
Location Configuration was "give me my location"
Conveyance was "Let me send you my location"
When we add third parties, we need analogs of these ("give me his location"
and "let me send you his location").  I'm not sure we need two new terms,
because the protocols are, generally, the same (HELD for "give me his
location" and SIP Geolocation header ("let me send you his location").  

Since I agree we don't need LG to LS protocols, we don't need a term.

We use the term "determination" for the mechanism the LIS uses to figure out
where a device is.

We use the term "target" and I don't think there is any discussion about
changing that.

I think we use "LIS" for LG+LS.

I think that's it, except for the existing privacy rule stuff, which I have
no desire to change.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Monday, March 16, 2009 1:35 AM
To: [email-masked]
Subject: [Geopriv] "conveyance protocols" in lo-sec-05

Richard

James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Mar 2009 12:09:25 -0500

Martin

Brian just wrote this

>Conveyance was "Let me send you my location"

and I believe there are sufficient differences between how the two 
act that one protocol *could* do both, but one protocol *shouldn't* 
be expected to do both.

My angle is mostly from a WG perspective because of the a "which docs 
apply to which protocol behaviors?" In other words, you know I'm not 
a fan of HELD, but I've not said anything (or even hummed one way or 
the other) against HELD for more than a year - but docs like LbyR 
Reqs came from the HELD break-up and I've had to stay on top of that 
doc because it was HELD doc, and it's now a general Location URI doc 
that assumes a lot about what HELD can do that DHCP and LLDP-MED 
cannot.  These types of situations are what get this WG all lathered 
up and screaming at each other because of the inconsistencies between 
the protocols and the "changing of the rules" midstream (which is 
generally years after another effort has started).

There's just no easy way for someone reading loc-sec-05 as his/her 
first doc from this WG and have a good feeling about all the previous 
docs that now do not align with what's in loc-sec-05 (in these 
architectural changes).

Where do we say "*then* (i.e., the older docs) were phase 1 of 
Geopriv, loc-sec-05 starts phase 2 (with a changed architecture)"?

At 12:48 AM 3/16/2009, Thomson, Martin wrote:
>I don't see why you would have a problem with this.  It's a label, 
>which is only relevant if there are associated changes in 
>expectations.  Don't worry that the goalposts have moved.
>
>By the model described in lo-sec, an "LCP" is a conveyance 
>protocol.  For DHCP, that changes nothing, because the model 
>describes a different set of constraints on conveyance 
>protocols.  Lo-sec allows an LS to distribute LI to a Target - which 
>is what DHCP does.
>
>Saying the DHCP doesn't "control identity" (whatever that means) was 
>never a good basis for distinction - lo-sec gives what LCPs do 
>greater credibility.
>
>Cheers,
>Martin
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 16 Mar 2009 21:40:55 +0200

Hi Brian, 

>and "let me send you his location").  I'm not sure we need two 
>new terms, because the protocols are, generally, the same 
>(HELD for "give me his location" and SIP Geolocation header 
>("let me send you his location").  

Well. Let's take SIP Location Conveyance, for example: 

* It allows the UA to add location about the Target.  This is the "Let
me send you my location"
* It allows the SIP proxy to add location about the Target. This is "I,
proxy, have added the location of the Target."

Both usages, so far, are called SIP Location Conveyance. 

Now, if you add the LbyR case to SIP Location Conveyance then this "Let
me send you my location" approach isn't quite correct either since the
LR has to ask someone since otherwise it has absolutely nothing. This
would then be the "give me his location" scenario since the only thing
you learned is the identifier where to retrieve location from.  

Still, this may be different from the "give me his location" in
comparison with the LR issuing a SUBSCRIBE to [email-masked] for his
location. 

The differences in the "me" and "his" part are only in the identifiers.
The cases are: sip:[email-masked],
sip:[email-masked], 192.168.1.2, etc.  

In summary, the cases are difficult to classify meaningfully
particularly when you consider the protocols being involved (as you can
use one protocol in multiple contexts).

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Mar 2009 15:00:12 -0500

>you learned is the identifier where to retrieve location from.

Hannes - nothing you've said so far allows a direct comparison 
between how SIP conveys location and how DHCP or LLDP-MED configure 
location on an endpoint.

>The differences in the "me" and "his" part are only in the identifiers.

no, they are in who initiates the action.

In SIP, for example, I have location (directly or indirectly) already 
and I'm going to give it to you.

in both DHCP and LLDP-MED, the client asks for it's own location, and 
never for anyone else's (as in never ever).

These are complementary protocols that should not be grouped together 
with the same identifier.

The main reason this is not correct to do is that this WG loves to 
hang identifier labels on what a particular doc needs to include when 
writing about a particular protocol ("you can't propose *that* 
without including all these accountings for what we consider right 
for this label of a protocol").

>use one protocol in multiple contexts).

so then why force these dissimilar protocols into the same category 
(of label) in the first place?

You argument begs that they be kept separate.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 16 Mar 2009 22:18:51 +0200

Hi James, 

>between how SIP conveys location and how DHCP or LLDP-MED 
>configure location on an endpoint.

Well. That was not my intention anyway. 

If you look at my mail where I suggest terminology I make the following
differentiation: 

A) Please send me location (or a reference to it) corresponding to the
following identifier. 

Example protocols: LLDP-MED, DHCP, HELD, SIP Subscribe

B) Here is location (or a reference to it) (This is the case where no
prior request was made.)

Example protocols: SIP Location Conveyance 

Just an idea; maybe there is a simpler way for classification. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Mar 2009 17:26:30 -0400

I'm not sure this is helpful, given that the nature of the identifier  
makes all the difference in terms of privacy and other issues:

For example:

- "give me the location of 192.168.1.1" (local host)

vs.

- "give me the location pointed to by http://www.whitehouse.gov/address"

vs.

- "give me the current location of [email-masked]"

All these may look pretty similar from a protocol perspective.

The difference you make seems to be mostly one of data being carried  
in some non-location-focused protocol (such as SIP INVITE or email),  
as a secondary piece of information, vs. protocols that provide/ 
deliver/request location explicitly, as their main line of work.  
Modestly useful, but I'm not sure where that helps.

Thus, I don't think classifying protocols is a worthwhile effort  
unless the distinction yields some insight or requirements. So far, it  
mainly yields confusion and angels-on-a-pin discussions.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 16 Mar 2009 17:36:26 -0500

I think that's the most sensible approach.  We need to identify concerns with protocols, but those concerns don't need to be based on (arbitrary) labels.  As much as having a label aids communication, I sometimes think that overreliance on labels is a crutch.

Strangely enough, lo-sec follows a sensible model.  In the lifecycle, there is only one protocol step: conveyance/distribution.  That is, location moves from one place (LS) to another (LR).  Repeat as necessary.

> Behalf Of Henning Schulzrinne
> Sent: Tuesday, 17 March 2009 8:27 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [email-masked]; ext James M. Polk
> Subject: Re: [Geopriv] "conveyance protocols" in lo-sec-05
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Mar 2009 19:32:07 -0500

>Modestly useful, but I'm not sure where that helps.

my only concern along this whole topic is how other documents have 
been used to force a proposal to comply with the labels given out by this WG.

Most know I've written about as many proposals into this WG as 
Henning, Hannes or Martin - and I've experienced the "oh, well, 
*that* idea doesn't comply with what we decided in a non-public 
meeting (i.e., concall or hallway conversation) over there some time 
ago" just a little too often.

To give a concrete example, I've heard several times that my DHCP 
Location URI ID needs to meet all that HELD needed to meet based on 
the LbyR References ID.  Funny thing is the LbyR References ID 
started as a HELD ID, and has been retrofitted fairly successfully - 
yet not completely - to be a more general purpose document.  This 
retrofitting is still being done by Roger as I write this email, yet 
I started hearing in 2007 about all the capabilities I had to comply 
with that were in the LbyR Reqs ID, some of which weren't possible 
with DHCP, unless DHCP as a protocol was changed.

This is a classic example of writing a document to a moving set of 
requirements, which is nearly impossible.

The funny thing is that this DHCP Option will get the Location URI 
into the client, instead of LI into the client, which has been voiced 
as a far superior means of location conveyance over the years by DHCP 
detractors, buuuut it's still a stalled effort.

The nut of this is labels are great when everyone agrees to them to 
begin with. loc-sec-05 changes some of the labels very late in the 
game, and in a way that may make sense to a few of us, but not all of 
us - therefore there is confusion that will not go away.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 Mar 2009 21:49:18 -0400

The intent was not to change labels late in the game. In fact, it was  
the opposite: to use existing terminology to the greatest extent  
possible and only introduce new terms where previous WG documents were  
unclear. Of course if previous documents are in conflict with each  
other, that makes this task impossible, but it's not clear that that's  
the case.

Lo-sec-05 introduces three protocol labels: Positioning Protocol,  
Conveyance Protocol, and Rules Protocol. There seem to be two  
threshold questions:

(1) Is the protocol label necessary to describe some interaction? If so,

(2) Does the protocol have any meaningful requirements that differ  
from the other protocols?

My instinct is to say that the answer to (1) for both Positioning  
Protocol and Rules Protocol is "no." The requirements that lo-sec  
outlines for these two protocols could just as easily be described as  
requirements on the entities involved, which would reduce us back to  
the entity terminology that we already have substantial agreement on  
(other than LG/LS perhaps, which still requires clarification).

That leaves conveyance, which at its most generic could describe:

request for location of X, and
offering of location of X

For the Geopriv newbie, this probably provides the simplest basis to  
establish what the conveyance protocol requirements are. If something  
so generic can be made to be consistent with the way that much more  
narrow proposals (SIP location conveyance, DHCP/LLDP-MED, etc.) have  
been written, that would be ideal.

Alissa

On Mar 16, 2009, at 8:32 PM, James M. Polk wrote:

> into the client, instead of LI into the client, which has been  
> voiced as a far superior means of location conveyance over the years  
> by DHCP detractors, buuuut it's still a stalled effort.
>
> game, and in a way that may make sense to a few of us, but not all  
> of us - therefore there is confusion that will not go away.
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Mar 2009 21:56:54 -0500

>offering of location of X

At the Paris IETF (64?), it was made extremely clear to me when I 
presented SIP Location Conveyance that "Conveyance" meant to tell or 
inform someone else, and that did not include the ability to request 
location information (with the exception being indirect location).

This argument was made by several in the room at me on stage, 
principally by our AD, Jon Peterson.

 From this inflection point, I have always separated the two phrases 
you have above.

At the time, I included both the conveyance and retrieval of location 
information in the conveyance document. I subsequently had to remove 
text from said document to just convey location. Rohan Mahy, the SIP 
WG chair at the time, was also making this point (painful for me) at the time.

I believe Geopriv as a WG has struggled with the idea that to 
subscribe (in SIP terms) means "retrieve" in all cases, and that 
simply isn't true.

DHCP and LLDP-MED can only ever be configuration protocols, meaning 
they only ever deal in the "my" world. DHCP can ask for my location, 
but it cannot ever ask for your location. It also cannot ever tell 
you my location.  LLDP-MED is at L2, between an Ethernet switch and 
what's at the other end of that CAT-5 cable, so it equally cannot 
tell you my location. It can only tell me my location.

SIP cannot tell me my location unless it subscribes to a LIS with a 
Location URI, received by one of the configuration protocols.  If the 
location URI is not where I am, then the LbyR is pointing at someone 
else, and that is not delievered over DHCP or LLDP-MED.

SIP location conveyance, once a configuration protocol has delivered 
the endpoint's location directly in LCI, or indirectly as an LbyR, 
can ask where am I, but this is dependent on the first step having 
occurred already - the configuration download of the LbyR.

Using a Location filter, SIP can ask another entity where they are, 
which is not conveyance, it is retrieval and is an unsolicited act to 
find out where you are, or where someone else is.

>establish what the conveyance protocol requirements are.

I think this is lacking the perspective of who is getting what information.

#1 - If I am getting the information about me, it is a configuration 
protocol that does something first.

#2 - If I am sending you my location information, this is conveyance 
(i.e., to inform).

#3 - if I am asking for my or your location information, this is 
retrieval (i.e., I'm asking someone for their location information). 
If I'm asking for my own information, I'll have to have had a 
configuration protocol tell me the LbyR first - in order to subscribe 
to it (i.e., it's a second step in the process).

To me, actions 1 & 2 are independent, therefore separate.  #3 is 
independent when asking for your location, but is dependent when I'm 
asking for my location.

This separates #3 from both #1 & #2 -- meaning all 3 cannot be 
classified the same.

>If something

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Mar 2009 11:47:08 +0200

What terminology would you suggest, Martin? 
 
I had a hard time coming up with a terminology... 

>From: ext Thomson, Martin [mailto:[email-masked]] 
>Sent: 17 March, 2009 00:36
>To: Henning Schulzrinne; Tschofenig, Hannes (NSN - FI/Espoo)
>Subject: RE: [Geopriv] "conveyance protocols" in lo-sec-05
>
>I think that's the most sensible approach.  We need to 
>identify concerns with protocols, but those concerns don't 
>need to be based on (arbitrary) labels.  As much as having a 
>label aids communication, I sometimes think that overreliance 
>on labels is a crutch.
>
>Strangely enough, lo-sec follows a sensible model.  In the 
>lifecycle, there is only one protocol step: 
>conveyance/distribution.  That is, location moves from one 
>place (LS) to another (LR).  Repeat as necessary.
>
>> > B) Here is location (or a reference to it) (This is the case where 
>> > no prior request was made.)
>> >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Mar 2009 08:02:37 -0400

Leave it as it is:
Configuration is LIS to endpoint or proxy, value or reference
Conveyance is from endpoint or proxy to some other endpoint (or proxy),
value or reference.

And, Dereference is the reference to value exchange.

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, March 17, 2009 5:47 AM
To: ext Thomson, Martin; Henning Schulzrinne
Cc: [email-masked]; ext James M. Polk
Subject: Re: [Geopriv] "conveyance protocols" in lo-sec-05

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Mar 2009 08:45:24 -0400

More thoughts.

When you configure an endpoint, the endpoint IS NOT a location recipient.
Consider, for example, our favorite retransmission-allowed.  That does not
apply to the endpoint; it's getting location for the purpose of conveying it
to some other entity, where retransmission-allowed WOULD apply.

With conveyance, the "other" endpoint/proxy IS a location recipient.

This means that we don't label protocols, but use of protocols.  For
example, if an endpoint uses HELD to get its own location, and then gives it
to some application, the LCP endpoint is not the LR, but the application is.
On the other hand, if a carrier uses HELD to get location for one of its
customers, and uses the location in some application itself, then HELD is
being used for conveyance.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Tuesday, March 17, 2009 8:03 AM
To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ext Thomson, Martin'; 'Henning
Schulzrinne'
Cc: [email-masked]; 'ext James M. Polk'
Subject: Re: [Geopriv] "conveyance protocols" in lo-sec-05

Leave it as it is:

Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Mar 2009 09:08:28 -0400

Brian,

That taxonomy makes sense.  What I think we were trying to express in 
the document is that all three of those cases have in common that
(1) Location is being transmitted, and
(2) The entity sending location needs to apply policy

So all three of those cases (Configuration, Conveyance, Dereference) are 
cases of a general class of protocols that transmit location according 
to policy.  "Conveyance Protocol" was just the name I chose (I'll take 
the blame) to label that general class.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Mar 2009 11:16:31 -0500

At 08:08 AM 3/17/2009, Richard Barnes wrote:
>Brian,
>
>That taxonomy makes sense.  What I think we were trying to express 
>in the document is that all three of those cases have in common that

Richard

what's "the policy" for DHCP or LLDP-MED?

>So all three of those cases (Configuration, Conveyance, Dereference) 
>are cases of a general class of protocols that transmit location 
>according to policy.

This is sufficiently different than the hoops any "using protocol" 
had to overcome that I'd like to hear why this is changing?

>"Conveyance Protocol" was just the name I chose (I'll take the 
>blame) to label that general class.

again - I believe the DHCP/LLDP-MED and SIP protocol actions are 
sufficiently different than they should not be in the same class.

>>What terminology would you suggest, Martin?  I had a hard time 
>>coming up with a terminology...
>>>From: ext Thomson, Martin [mailto:[email-masked]] Sent: 
>>>17 March, 2009 00:36
>>>I think that's the most sensible approach.  We need to identify 
>>>concerns with protocols, but those concerns don't need to be based 
>>>on (arbitrary) labels.  As much as having a label aids 
>>>communication, I sometimes think that overreliance on labels is a crutch.
>>>
>>>conveyance/distribution.  That is, location moves from one place 
>>>(LS) to another (LR).  Repeat as necessary.
>>>
>>>>From: [email-masked] [mailto:[email-masked]] 
>>>>On Behalf Of Henning Schulzrinne
>>>>The difference you make seems to be mostly one of data being 
>>>>carried in some non-location-focused protocol (such as SIP INVITE 
>>>>or email), as a secondary piece of information, vs. protocols 
>>>>that provide/ deliver/request location explicitly, as their main line of work.
>>>>>B) Here is location (or a reference to it) (This is the case 
>>>>>where no prior request was made.)
>>>>>
>>>This message is for the designated recipient only and may contain 
>>>privileged, proprietary, or otherwise private information.
>>>immediately and delete the original.  Any unauthorized use of this 
>>>email is prohibited.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Mar 2009 13:15:06 -0400

> what's "the policy" for DHCP or LLDP-MED?

The policy for those protocols, as for HELD, is the "LCP Policy" -- 
namely that an entity is authorized to receive location if it is the 
same as the Target.

> This is sufficiently different than the hoops any "using protocol" had 
> to overcome that I'd like to hear why this is changing?

My understanding was that the term "using protocol" was sufficiently 
vague that we didn't want to continue using it.  This draft was trying 
to come up with a clearer set of terms (but maybe we're failing...).

>> "Conveyance Protocol" was just the name I chose (I'll take the blame) 
>> to label that general class.
> 

Could you explain more clearly what the critical differences are?  In 
both cases, one entity (a DHCP server or SIP UA) makes a policy-based 
decision to transmit location to another entity.  The policies are 
different (the LCP policy vs. some user-provided policy), but they're 
very similar for privacy purposes.

Now, that's not to say that there aren't sub-classes of the general class:
-- Configuration: Recipient=Target, policy=LCP policy
-- Conveyance/BR: Recipient=any (by policy), policy from Rules or LO
-- Dereference: Conveyance, but initiated by a request for an identifier
But all of these types of protocols share a set of privacy concerns 
related to transmitting location, so they also belong under a general 
umbrella of "ways to send location to somebody else", call it what you may.

--Richard

---

From: John Morris <[email-masked]>
Date: Tue, 17 Mar 2009 11:16:02 -0400

And FWIW, my primary goal is to end up with a document that cleanly 
and clearly explains the Geopriv basics, and clarifies some of the 
uncertainties that have arisen over the years.  I don't feel strongly 
one way or another on whether we should "name" the protocols classes, 
or what the names should be -- so long as the name enhances clarity 
rather than the opposite.

John

At 9:08 AM -0400 3/17/09, Richard Barnes wrote:
>according to policy.  "Conveyance Protocol" was just the name I 
>chose (I'll take the blame) to label that general class.
>
>--Richard
>
>
>Brian Rosen wrote:
>>Leave it as it is:
>>>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.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Mar 2009 14:30:38 -0500

At 12:15 PM 3/17/2009, Richard Barnes wrote:
>>>So all three of those cases (Configuration, Conveyance, 
>>>Dereference) are cases of a general class of protocols that 
>>>transmit location according to policy.
>vague that we didn't want to continue using it.  This draft was 
>trying to come up with a clearer set of terms (but maybe we're failing...).

I understand what you are trying to accomplish, and perhaps Brian and 
me more sensitive to "conveyance" because we are deep into SIP 
Conveyance - given that we authored that doc, and therefore 
understand the differences because we had to make them or had to deal 
with them.

I didn't see any issue with the LCPs, given that SIP is clearly not 
one of them. HELD can be an LCP, but James W wants to make it more 
than just an LCP, and that's fine. That  means it's in more than one 
category (or has more than one label).

>Could you explain more clearly what the critical differences are?

LLDP-MED is generated by the Ethernet switch, and is transmitted at 
the endpoint at the end of the cable that connects to that Ethernet 
port, once the port attaches to a device.  There's no server involved 
here, therefore there really isn't any policy other than to have 
location provided or not.  There is sufficient intelligence in the 
switch port to figure out what specific device is at the end of the 
wire, but I don't believe that's used very much now, or in 5 years. 
There is no identity to the client, so this is a configuration 
protocol. There are no privacy rules with LLDP-MED.

The DHCP policy is to either answer a DHCPDISCOVER or DHCPINFORM when 
asking for a location Option *or* to send the location Option 
unsolicited (i.e., whether the client wanted it or not).  There is no 
identity to the client, so this is a configuration protocol. I don't 
believe there are any privacy rules with DHCP.

SIP is never a configuration protocol. It is either a conveyance 
protocol, a dereference protocol, or a retrieval protocol. This has 
identity associated with it because it is carrying the full PIDF-LO, 
and not just the naked LI (as LLDP-MED an DHCP are). There are always 
privacy rules with SIP.

SIP (unlike DHCP or LLEP-MED) can convey (unsolicited) location, plus 
ask for the location of a remote entity entity (unsolicited).

To me, this separates SIP from DHCP and LLDP-MED.

If you are looking at this from any endpoint's point of view, DHCP 
and LLDP-MED do things similarly, and SIP does things 
differently.  HELD can do things in both camps, but not completely - 
given that I don't believe HELD can ask for another's location 
unsolicited, but I may be wrong.

[RB] In both cases, one entity (a DHCP server or SIP UA) makes a 
policy-based decision to transmit location to another entity

to me, saying "a DHCP server makes a policy-based decision to 
transmit location" is an thumbs-up/thumbs-down decision, because 
there is no other policy or privacy that can be attained with 
DHCP.  RFC3118 is certainly not deployed to protect it, even though 
every sec cons section of a DHCP doc has "must do 3118" as its 
protection mechanism.

  [RB] policies are different (the LCP policy vs. some user-provided 
policy), but they're very similar for privacy purposes.

>related to transmitting location, so they also belong under a 
>general umbrella of "ways to send location to somebody else", call 
>it what you may.
>
>--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 18 Mar 2009 00:47:30 -0500

Hi James,

I find the commentary on LLDP-MED and DHCP interesting. When we queried
the inclusion of location reference as a DHCP option, the response was
that it wasn't the protocol's problem as to how a DHCP server managed
the generation and servicing of references. Obviously quite complex
things could be going on behind the DHCP service in support of that
functionality.

Can the same not be said for the correlation and assessment of policy
for any particular requesting host?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James M. Polk
Sent: Wednesday, 18 March 2009 6:31 AM
To: Richard Barnes
Cc: [email-masked]; 'Tschofenig,Hannes (NSN - FI/Espoo)'; Thomson,
Martin; 'Henning Schulzrinne'
Subject: Re: [Geopriv] "conveyance protocols" in lo-sec-05

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Mar 2009 13:17:33 -0500

At 12:47 AM 3/18/2009, Dawson, Martin wrote:
>the generation and servicing of references.

true - that isn't a DHC protocol issue. The protocol only carries the 
Location URI, and can do so acting as if the URI were the payload 
being sent from server to client, meaning there was no other 
processing by the DHCP server other than ensuring the right payload 
goes to the right client. The RAIO (RFC 3046) identifies this to the server.

The payload could be coming from the same server, but not over the 
DHC protocol (i.e., an API).

This ID, which is meeting more resistance than I would have expected, 
is merely the protocol specification, not the architecture solution 
of how this API works, or what other servers there are behind the 
DHCP server (probably a LIS), nor what protocol is used in that 
communication with the LIS (because it cannot be DHCP, so it doesn't 
belong in a DHCP specification).

>Obviously quite complex things could be going on behind the DHCP 
>service in support of that functionality.

*could*, certainly - but I don't believe it will be that complex, 
given if such concerns were really needed, like you imply, I would 
have thought DHCP would be a more robust protocol than it is (perhaps 
using TLS or DTLS or some other security mechanisms or protocols). 
Sure location cannot be the first such usage into DHCP that our usage 
would be the first to require such measures be taken.

I think the DHCP transaction may be a little simpler than you are eluding to.

>for any particular requesting host?

I can understand where you are going. But the DHCP server only gets 
an circuit-ID as an identifier from the client, and nothing else, so 
how complex should we make the decision and with what critical 
criteria can we use to differentiate between a white hat and a black hat?

I believe a wise man (or woman) said "you're only as strong as your 
weakest link"... and given the simplistic protocol being used, 
lacking TLS or DTLS as a transport, I'm not sure the decision should 
be that complex behind the scenes, given that most likely the only 
identifier is a Ethernet switch port ID...