Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

Sorry, I should take that back. That only applies to http URIs, with which I am more familiar. URIs are defined as a sequence of characters and not using UTF-8 would unduly restrict the set of URIs that we can represent. I hit send before reading my 3986/3987.

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Wednesday, 30 September 2009 11:48 AM
> To: Richard Barnes
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-
> option-06
>
> My understanding of the situation is that IRIs are intended for
> consumption and production by human beings. There's a process for
> conversion to URI, which is the protocol element. This is a protocol.
>
> I can imagine that a DHCP server might provide a user interface that
> accepts an IRI, but it converts that to a URI for use in the protocol.
>
> > -----Original Message-----
> > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > Sent: Wednesday, 30 September 2009 10:41 AM
> > To: Thomson, Martin
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-
> > option-06
> >
> > What's the argument against IRIs here? That these URIs aren't
> > user-facing? Not having done much with i8n, I'm not sure what the
> > relevant norms are here.
> >
> > --Richard
> >
> >
> > Thomson, Martin wrote:
> > >> and LocationUri a UTF-8 string.
> > >
> > > URIs are ASCII, no need for UTF-8 in this case. We don't need or
> > want IRIs here.
> > > -------------------------------------------------------------------
> --
> > ---------------------------
> > > 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]
>
> -----------------------------------------------------------------------
> -------------------------
> 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]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

My understanding of the situation is that IRIs are intended for consumption and production by human beings. There's a process for conversion to URI, which is the protocol element. This is a protocol.

I can imagine that a DHCP server might provide a user interface that accepts an IRI, but it converts that to a URI for use in the protocol.

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Wednesday, 30 September 2009 10:41 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-
> option-06
>
> What's the argument against IRIs here? That these URIs aren't
> user-facing? Not having done much with i8n, I'm not sure what the
> relevant norms are here.
>
> --Richard
>
>
> Thomson, Martin wrote:
> >> and LocationUri a UTF-8 string.
> >
> > URIs are ASCII, no need for UTF-8 in this case. We don't need or
> want IRIs here.
> > ---------------------------------------------------------------------
> ---------------------------
> > 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]

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

What's the argument against IRIs here? That these URIs aren't
user-facing? Not having done much with i8n, I'm not sure what the
relevant norms are here.

--Richard

Thomson, Martin wrote:
>> and LocationUri a UTF-8 string.
>
> URIs are ASCII, no need for UTF-8 in this case. We don't need or want IRIs here.
> ------------------------------------------------------------------------------------------------
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

> and LocationUri a UTF-8 string.

URIs are ASCII, no need for UTF-8 in this case. We don't need or want IRIs here.
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

-----
Draft: draft-ietf-geopriv-dhcp-lbyr-uri-option-06
Reviewer: Richard Barnes
Review Date: 29 Sep 09

General Comments:

1. This draft is in pretty good shape overall, although there are a few
critical sections that need to be added.

2. There needs to be tighter wording around allowed URI schemes and how
the client processes the URIs it receives. I would suggest using a
different LUriType for each type of URI (sip/sips/pres vs. http vs. geo
...) -- this will allow you to (1) save a registry, and (2) have
multiple dereference schemes available for a URI scheme. That latter
feature could be very useful for HTTP URIs, for example. This also
avoids the issue of whether HTTP/HELD is included, since the HELD deref
document can register a new LUriType for itself.

3. This document cannot mandate a policy for the URIs it carries, either
access-controlled or possession-model. The approach here should be the
same as in HELD (they both provide URIs unilaterally, with no way to set
policy): "Servers SHOULD apply access control policy to URIs; clients
MUST assume that URI is not access controlled, since it has no way to
know what the policy is."

4. The document needs to better define the format for LUriValues. It's
not clear that it makes sense here to just have UTF-8 strings (as RFC
4776 does). Suggest making Valid-For an integer of some fixed
precision, and LocationUri a UTF-8 string.

5. Can multiple URIs be provided? If so, how do the Valid-For
attributes map to them? Do all the URIs get the same Valid-For, or can
I define different ones per URI?

Specific Comments:

Section 1, paragraph 2
s/Dereferencing a location URI/Dereferencing a SIP location URI/

Section 1, paragraph 3
s/having a PIDF-LO/having a location object/

Section 1, paragraph 8
Full stop after "given out". Change latter half to: "In cases where
multiple client have the same location, the unique URIs assigned to
these clients can all reference the same location object, relieving the
LS from maintaining each location individually."

Section 1, paragraph 9
s/vary, and/vary, according to/

Section 2.1 / 2.2
Make the formatting of the IPv4 and IPv6 sections the same. Choose
either the "XXX" or "option-" format. Add an RFC editor note to fill in
the assigned value for the option code in each case.

Section 2.3
As I mentioned above, this section needs to have a little more
structure. Suggest
1. Move Valid-For to LUriType=0
2. Change LUriType=1 to "SIP Presence URI" (sip/sips/pres scheme)
3. Add two sub-sections here, one for each LUriType
4. Move appropriate content under subsections

Section 3, paragraph 1
s/there is zero knowledge by the client/the client doesn't know/

Section 3, example URIs
A more realistic (tempting) example might be something like
sip:[mac-address]@example.com
s/*this*/the/
Change "The entity= discussion is orthogonal to" to " The identity
contained in the 'entity' attribute of a PDIF-LO is independent of the
identification information in a location URI."

Section 3, paragraph starting "The deference..."
This paragraph is false -- the DHCP client needs to know how to handle a
URI it gets, so this document needs to define (by reference) how such
URIs are handled. All that really means is that when you register an
LUriType, you MUST point to a standards-track document (such as the SIP
location-conveyance spec) that defines how URIs of that type are handled.

Section 3.1, Bullet 2
This discussion is exactly backwards. It MUST be assumed that a
location URI attained using DHCP will NOT operate under an authorization
model, since the client has no way to know what policy is being applied.

Section 3.3
Delete this section, or move it up to section 2.3.2 (for LUriType=1=Sip
Presence URI)

Section 4.4
Delete this section; this registry is unnecessary if we use
LUriType=1=Sip Presence URI

Section 5, paragraph 1
Delete the first part of this sentence: "Where critical decisions might
be based on the value of this location URI option..." There's no need
to qualify a SHOULD. Remove the following paragraph break.

Section 5, paragraph 2
Change "It is not secure in a practical sense" to "It is secured only at
layers 1 and 2." Change "DHCP will be primarily..." to "DHCP is
often...". Change "to within a wire" to "to a wire".

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FW: New IETF Journal available now (Volume 5, Issue 2)

Folks in the WG might be interested to read the article on GEOPRIV from Alissa and Ted in the latest journal:

<http://www.isoc.org/tools/blogs/ietfjournal/?p=1290>

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Mirjam Kuehne
Sent: Tuesday, 29 September 2009 2:51 AM
To: ietf-announce@ietf.org; ietf@ietf.org
Subject: New IETF Journal available now (Volume 5, Issue 2)

[Apologies for duplicate emails]

Hello,

The new issue of the IETF Journal - Volume 5, Issue 2 - is now
available at http://ietfjournal.isoc.org

You can read this publication online or choose to download the full
issue in PDF format. You can also keep up to date with the latest
issue of the IETF Journal by subscribing to one of our RSS or Atom
feeds.

For comments or suggestions, please do not hesiate to contact us at
ietfjournal@isoc.org.

Kind Regards,
Mirjam Kuehne

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hannes;

At BLISS we are trying to define set of URIs along with
rules on how these URIs are to be used to enable/disable
common features on the proxy (call-forward ON/OFF,
voicemail ON/OFF for particular AoR etc.). Each configuration
is viewed as a resource, represented as a URI following the
REST principle.

We are not defining a protocol per se, but trying to
provide a simple solution to an interoperability problems
observed in a wild, while maintaining forward compatibility
to XCAP.

So we are neither updating XCAP nor replacing XCAP.

Regards
Shida

On Sep 22, 2009, at 3:59 PM, Hannes Tschofenig wrote:

> Hi Richard,
>
> Regarding (1): The usage of XCAP for the transport instead of the
> mechanism
> currently described in Context is certain something we could
> investigate. I
> have not followed the recent work in BLISS but aren't some folks
> trying to
> invent a new protocol mechanism to update XCAP?
>
> Regarding (2): I have tried to create such an extension to Common
> Policy &
> the Gelocation Policy (since I thought it was a good idea after the
> discussion we had at the interim meeting) but then the outcome
> convinced me
> that it isn't.
>
> Here is the result I came up with about a year ago:
> http://www.ietf.org/mail-archive/web/geopriv/current/msg05907.html
>
> We might want to revisit that very brief discussion and try to the
> complexity for implementers.
>
> Ciao
> Hannes
>
>
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>> Sent: 22 September, 2009 00:08
>> To: Winterbottom, James
>> Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); Hannes
>> Tschofenig; GEOPRIV
>> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>>
>> Hm, no, that's not the answer I was looking for. Here's what I'm
>> thinking: Context has basically two parts, 1. Protocol
>> mechanics for creating/updating/deleting contexts 2.
>> Attributes of contexts that can be set with those mechanics
>>
>> I was thinking that (1) could move toward being XCAP, and (2)
>> could move toward extensions of the policy language.
>>
>> In particular, w.r.t. (2), there are only three things that can be
>> set:
>> -- "Authorization policy" is already common-policy
>> -- "Context lifetime" may require some extension, but is
>> largely the same as the <validity> element of common-policy
>> -- "Snapshot context" is the most novel, but you could
>> probably still implement it with an extension to the
>> <provide-location> element from geopriv-policy.
>>
>> The protocol mechanics (1) don't do anything really magical; I
>> think you could map semantics pretty cleanly to a combination
>> of HELD and XCAP.
>>
>> --Richard
>>
>>
>>
>> Winterbottom, James wrote:
>>> Hi Richard,
>>>
>>> I see Context as a being a container, one of the things of
>> which it can contain is a common policy document.
>>>
>>> Does that help?
>>>
>>> Cheers
>>> James
>>>
>>>
>>> -----Original Message-----
>>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>>> Sent: Mon 9/21/2009 3:42 PM
>>> To: James M. Polk
>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes
>>> Tschofenig; GEOPRIV
>>> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>>>
>>> James: Don't worry. Nothing in held-context is getting rid of or
>>> duplicating Common Policy. The difference is that held-context does
>>> some things that are not possible today with common-policy or
>>> geopriv-policy framework.
>>>
>>> Hannes/James: Thinking back to the discussions at the Dallas interim
>>> some time ago, I thought that there was a motion to move the
>>> held-context toward being more of an extension to common-policy,
>>> rather than an alternative policy transport. Am I recalling
>> correctly?
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>> James M. Polk wrote:
>>>> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>>>> I could imagine that adding the ability to upload Common
>>>>> Policy/Geolocation Policy as an add-on to
>>>>> draft-winterbottom-geopriv-held-context-04.txt is a lot
>> easier than
>>>>> using XCAP, particularly since I believe that 95% of the
>> cases will
>>>>> only make usage of a fraction of Common Policy (and
>> nothing from the
>>>>> geolocation policy document).
>>>> I'm trying to figure out what is being said here in Hannes'
>> paragraph
>>>> above.
>>>>
>>>> Is HELD really not needing Common Policy/Geolocation Policy because
>>>> it has another ID specifying some other mechanism?
>>>>
>>>> If so, why would this WG allow this?
>>>>
>>>> Common Policy is supposed to be "common" to everything, right?
>>>>
>>>> Geolocation Policy is supposed to be used by everything Geopriv
>>>> specific, right?
>>>>
>>>> It appears the net result of this - if true - is that DHCP has to
>>>> jump through hoops that HELD doesn't, even though HELD can.
>>>>
>>>> James
>>>>
>>>>
>>>>> Ciao
>>>>> Hannes
>>>>
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> -------------------------- 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]
>>>
>>>
>>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] IPv6 Address Option

Bernard Aboba [mailto:bernard_aboba@hotmail.com]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 

 

[BA] Are there specific uses of normative language in the document that you believe are inappropriate?  

With the caveat that it’s been some time since I read the draft, based upon my last review I’d have to say virtually all the uses of RFC 2119 requirements language in the document are problematic.  I plan to go through the note in depth again this week.  There is a lot of nonsense in it which I had mistakenly considered innocuous blather, easily ignored (they are “guidelines”, after all).  However,  at some point during the final discussions before the publication of RFC 5580 I realized that the document, far from being a set of harmless suggestions on style, was in fact a club to be used by pompous asses to keep people from getting real work done.  If you recall, my major arguments against the attributes defined in 5580 were based upon non-compliance w/the Design Guidelines document (yes, that would make me one of those pompous asses & I would like to take this opportunity to apologize to the authors of RFC 5580, the geopriv WG and the IESG for my misguided behavior).  In fact, though, there was nothing technically wrong with the geopriv attributes: they would have worked just fine, thank you.  Their only sin was deviation from a set of rules based upon a highly suspect historical characterization of RADIUS development and a simplistic (if not downright primitive processing model).  At any rate, removing the RFC 2119 language from the draft would go a long way toward making the document truly harmless.

Re: [Geopriv] OT: twitter geolocation details

Also, I believe they are planning using the W3C Geolocation API as a
source of geolocation information, and that API uses WGS84 as a default.
--Richard

Alexander Mayrhofer wrote:
> [OT, but i think of interest to this list]
>
> Twitter will soon allow posts to contain geolocation information. Some
> information about functionality and privacy protection is here:
>
> http://smarterware.org/3419/details-on-twitters-imminent-geolocation-sup
> port-launch
>
> The official API documentation is here:
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0upda
> te
>
> Sadly, they are not specifying which CRS the coordinates have to be in
> ... (but since they are re-using geoRSS, my personal assumption would be
> WGS84 - which is the default there)
>
> Alex
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] OT: twitter geolocation details

[OT, but i think of interest to this list]

Twitter will soon allow posts to contain geolocation information. Some
information about functionality and privacy protection is here:

http://smarterware.org/3419/details-on-twitters-imminent-geolocation-sup
port-launch

The official API documentation is here:

http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0upda
te

Sadly, they are not specifying which CRS the coordinates have to be in
... (but since they are re-using geoRSS, my personal assumption would be
WGS84 - which is the default there)

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Test

This is a test, please ignore
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] LCP & Arch....

Marc,

> You may get other comments around end-user knowledge of location
> dissemination/rules, etc.

There is already text in the document regarding the need for the establishment of prior authorization by Rule Makers.

Now, if your meta-policy dictates that an end-user is a Rule Maker, you get what you want. But end-user knowledge is not mandated, even if it is arguably a desirable goal in many cases.

If the user is only one of many Rule Makers, then it might be the wish of a non-end-user Rule Maker that the end-user is not aware of the rules it creates. Yes, that's not pretty, but I'd argue that a) GEOPRIV permits this, and b) that it's an ugly fact of life and not our problem. If you have a problem with that, I'd suggest a career in public policy.

> Just to be clear, the draft is asking for the functional equivalent of
> pres:identifier-du_jour@lis.example.com, correct? Knowing this allows
> me to compare the security/privacy attributes.

Not functionally equivalent in all aspects, but I think that they are equivalent from the perspective of applying GEOPRIV principles (i.e. RFC 3693 and geopriv-arch). The security story might be different. For instance, SIP generally has intermediaries, which adds complexity that doesn't apply here.

--Martin

>
> -Marc-
>
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] LCP & Arch....

Martin,

>
> Yes, I would like to solve the problem that was previously known as OBO. That
> is, third party requests that use the mechaisms provided by held-identity.
>
> I'll note that OBO is a term that isn't necessary because we already had
> adequate labels in the GEOPRIV model.

OK, I can accept calling this is a limited use case third party model.

>
> That's right. I'm saying that we don't need to justify our use case in
> privacy terms. Not any further than we have already.

You may get other comments around end-user knowledge of location
dissemination/rules, etc.

>
>> Before we can agree to the above, we have to agree that HELD identity
>> extensions is strictly for the use-case described (further) above,
>> third-party/OBO (we need to pick one term), and can not be used by a
>> target discovering it's own location from a Rulemaker pov.
>
> We did agree. It's not LCP. It's someone requesting the location of someone
> else.

Then state this is not addressing a target discovering it's location
use-case in the draft.

I believe the draft takes too many liberties with "LCP Policy". That policy
still falls under the Rulemaker and is not a given.

Just to be clear, the draft is asking for the functional equivalent of
pres:identifier-du_jour@lis.example.com, correct? Knowing this allows me to
compare the security/privacy attributes.

-Marc-

>
> --Martin
>
>
> ------------------------------------------------------------------------------
> ------------------
> 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv]

At 03:45 PM 9/21/2009, Richard Barnes wrote:
>RFC 5606?
><http://tools.ietf.org/html/rfc5606>

Hannes

This was the context I asked about if I was missing from your
"intended recipient" comment in a recent thread. I don't know if you
meant the <retransmission-allowed> topic -- which isn't really an
"intended recipient" but more like a "preventing unintended
recipient(s)" thread -- or another topic. The idea of intended
recipient is sufficiently different from <retransmission-allowed> in
my mind that I had to ask if you were considering the two the same topic.

The <retransmission-allowed> topic (and the subject of RFC 5606, as
Richard pointed out) is about strongly suggesting an intermediary
server not look at information it can (i.e., the PIDF-LO or
dereference the location URI - either of which is contained in a SIP
request message that server is processing. There really is not
anything "intended" about it. We don't ever say "this is for servers"
or "this is for endpoints" -- although I had that text in earlier
versions of Conveyance. Based on the <retransmission-allowed>
effort, I was forced to remove this "intended recipient" header
parameter from that doc.

Now, Martin went down a path of saying any location in a SIP request
is obviously the originator of the request. But this limitation is
not allowed in PIDF-LO. At this point, this list (and SIP and
SIPCORE) got into the differences between the 'entity' attribute in
the <presence> element vs. the <device ID> element vs. the SIP From:
header value.

(Does this give you understanding of the confusion I have with your question? )

Ultimately the 'entity' attribute can match the From header value if
the SIP request contains the PIDF-LO. Martin agrees with this, as
does Brian. I was after getting the 'entity'/From: linkage for all
situations. The problem is with the location URI, and being able to
still maintain this linkage. I'm willing to concede that there can
be only 1 location in a SIP request if a location URI is given out,
if we can agree that if locations values are in the SIP request -
that more than one target's location (in separate PIDF-LOs) can be
given out. I'll add text stating that the way to match the SIP
request originator to a PIDF-LO is if the From: value is the same as
the 'entity' attribute. Also, that PIDF-LOs that don't match this
From/entity linkage can be ignored if the LR doesn't understand what
to do with that location.

It could easily be the case in which Alice has Carol's location
(Carol's <retransmission-allowed> set to yes), and Alice sends
Carol's location to Bob. If Bob knows Carol, he consumes her
location. If Bob doesn't know Carol, he ignores that PIDF-LO. All
this is separate from Alice including her PIDF-LO in the SIP request
towards Bob - which he identifies by matching the From/entity linkage.

That said, if Alice were to send Bob her location with a location
URI, I'll add text that says this must be the only location in that
SIP request.

Does this make sense to you? What about anyone else?

Is there something still unsettled in your mind wrt this overall topic?

James

>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Hi Brian, Hi James
>>if I am the only one still seeing problems with <retransmission-allowed>
>>in context of SIP location conveyance then I keep my mouth shut.
>>Ciao
>>Hannes
>>
>>
>>------------------------------------------------------------------------
>>_______________________________________________
>>Geopriv mailing list
>>Geopriv@ietf.org
>>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hi James,

~snip~
>
>What you stated above is good, but it really makes me question
>why we have done all the work in Common or Geolocation Policy
>because if it weren't for DHCP, neither appears to have been
>useful at all.
>
>Am I wrong in that conclusion?

Common Policy and Geolocation policy is a good mechanism for usage with a
Location Server but not for a LIS (in my opinion).

I have the following model in mind (copied from
http://tools.ietf.org/html/draft-garcia-geopriv-indirect-publish-00 and
modified):

+------------+
| Location |
| Recipient |
| |
| |
+------------+
^
|Location
|Request/
|Response
|(3)
|
v
+-----------+ +------------+
| | | Location |
| LIS | | Server |
| | | (+Policies)|
| | | |
+-----------+ +------------+
^ ^
| Geopriv //
| Location //
| Configuration //
| Protocol //
| (1) //
| // Geopriv Location
v // Conveyance Protocol
+-----------+ // (e.g., SIP)
| Device | // (2)
| |v
| |
+-----------+

Figure: Location by Value

+------------+
| Location |
| Recipient |
| |
| |
+------------+
^
|Location
|Request/
|Response
|(4)
|
v
+-----------+ Geopriv +------------+
| | Location | Location |
| LIS |<------------->| Server |
| | Dereference | (+Policies)|
| | Protocol (3) | |
+-----------+ +------------+
^ ^
| Geopriv //
| Location //
| Configuration //
| Protocol //
| (1) //
| // Geopriv Location
v // Conveyance Protocol
+-----------+ // (e.g., SIP)
| Device | // (2)
| |v
| |
+-----------+

Figure: Location by Reference

>
>
>>Finally, as you know: The geolocation policy document provides only
>>location-based authorization and transformations for location
>>information. The most important features one needs are for
>the purpose
>>discussed here is, however, authorization based on the
>**identity** of
>>the location recipient.
>
>So, while not disagreeing with you at all, I'm still
>struggling to understand why referencing RFC 4745 isn't enough
>for the DHCP location URI doc? Why does this ID need to go
>into all the additional details since it is merely a delivery
>system piece of the soltion?

A reference to RFC 4745 is a first step, certainly. But it leaves the
question open of how the XML documents get to the LIS.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hi Richard,

Regarding (1): The usage of XCAP for the transport instead of the mechanism
currently described in Context is certain something we could investigate. I
have not followed the recent work in BLISS but aren't some folks trying to
invent a new protocol mechanism to update XCAP?

Regarding (2): I have tried to create such an extension to Common Policy &
the Gelocation Policy (since I thought it was a good idea after the
discussion we had at the interim meeting) but then the outcome convinced me
that it isn't.

Here is the result I came up with about a year ago:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05907.html

We might want to revisit that very brief discussion and try to the
complexity for implementers.

Ciao
Hannes

>-----Original Message-----
>From: Richard Barnes [mailto:rbarnes@bbn.com]
>Sent: 22 September, 2009 00:08
>To: Winterbottom, James
>Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); Hannes
>Tschofenig; GEOPRIV
>Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>
>Hm, no, that's not the answer I was looking for. Here's what I'm
>thinking: Context has basically two parts, 1. Protocol
>mechanics for creating/updating/deleting contexts 2.
>Attributes of contexts that can be set with those mechanics
>
>I was thinking that (1) could move toward being XCAP, and (2)
>could move toward extensions of the policy language.
>
>In particular, w.r.t. (2), there are only three things that can be set:
>-- "Authorization policy" is already common-policy
>-- "Context lifetime" may require some extension, but is
>largely the same as the <validity> element of common-policy
>-- "Snapshot context" is the most novel, but you could
>probably still implement it with an extension to the
><provide-location> element from geopriv-policy.
>
>The protocol mechanics (1) don't do anything really magical; I
>think you could map semantics pretty cleanly to a combination
>of HELD and XCAP.
>
>--Richard
>
>
>
>Winterbottom, James wrote:
>> Hi Richard,
>>
>> I see Context as a being a container, one of the things of
>which it can contain is a common policy document.
>>
>> Does that help?
>>
>> Cheers
>> James
>>
>>
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>> Sent: Mon 9/21/2009 3:42 PM
>> To: James M. Polk
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes
>> Tschofenig; GEOPRIV
>> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>>
>> James: Don't worry. Nothing in held-context is getting rid of or
>> duplicating Common Policy. The difference is that held-context does
>> some things that are not possible today with common-policy or
>> geopriv-policy framework.
>>
>> Hannes/James: Thinking back to the discussions at the Dallas interim
>> some time ago, I thought that there was a motion to move the
>> held-context toward being more of an extension to common-policy,
>> rather than an alternative policy transport. Am I recalling
>correctly?
>>
>> --Richard
>>
>>
>>
>>
>> James M. Polk wrote:
>>> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>>> I could imagine that adding the ability to upload Common
>>>> Policy/Geolocation Policy as an add-on to
>>>> draft-winterbottom-geopriv-held-context-04.txt is a lot
>easier than
>>>> using XCAP, particularly since I believe that 95% of the
>cases will
>>>> only make usage of a fraction of Common Policy (and
>nothing from the
>>>> geolocation policy document).
>>> I'm trying to figure out what is being said here in Hannes'
>paragraph
>>> above.
>>>
>>> Is HELD really not needing Common Policy/Geolocation Policy because
>>> it has another ID specifying some other mechanism?
>>>
>>> If so, why would this WG allow this?
>>>
>>> Common Policy is supposed to be "common" to everything, right?
>>>
>>> Geolocation Policy is supposed to be used by everything Geopriv
>>> specific, right?
>>>
>>> It appears the net result of this - if true - is that DHCP has to
>>> jump through hoops that HELD doesn't, even though HELD can.
>>>
>>> James
>>>
>>>
>>>> Ciao
>>>> Hannes
>>>
>>
>>
>>
>----------------------------------------------------------------------
>> -------------------------- 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]
>>
>>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [Editorial Errata Reported] RFC5491 (1888)

The following errata report has been submitted for RFC5491,
"GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5491&eid=1888

--------------------------------------
Type: Editorial
Reported by: Martin Thomson <martin.thomson@andrew.com>

Section: 3

Original Text
-------------
The PIDF format provides for an unbounded number of <tuple>,
<device>, and <person> elements. Each of these elements contains a
single <status> element that may contain more than one <geopriv>
element as a child.

Corrected Text
--------------
The PIDF format provides for an unbounded number of <tuple>,
<device>, and <person> elements. Each of these elements may
contain more than one <geopriv> element.

Notes
-----
<status> only exists in <tuple> [RFC3863], not <device> or <person> [RFC4479]. The proposed text removes the problem.

I believe that it was only late that someone pointed out that <status> only applied to <tuple>; this sentence obviously got missed in the edit.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5491 (draft-ietf-geopriv-pdif-lo-profile-14)
--------------------------------------
Title : GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations
Publication Date : March 2009
Author(s) : J. Winterbottom, M. Thomson, H. Tschofenig
Category : PROPOSED STANDARD
Source : Geographic Location/Privacy
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] LCP & Arch....

Marc,

We're not agreeing yet...

Yes, I would like to solve the problem that was previously known as OBO. That is, third party requests that use the mechaisms provided by held-identity.

I'll note that OBO is a term that isn't necessary because we already had adequate labels in the GEOPRIV model.

That's right. I'm saying that we don't need to justify our use case in privacy terms. Not any further than we have already.

> Before we can agree to the above, we have to agree that HELD identity
> extensions is strictly for the use-case described (further) above,
> third-party/OBO (we need to pick one term), and can not be used by a
> target discovering it's own location from a Rulemaker pov.

We did agree. It's not LCP. It's someone requesting the location of someone else.

--Martin

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

At 03:42 PM 9/21/2009, Richard Barnes wrote:
>James: Don't worry. Nothing in held-context is getting rid of or
>duplicating Common Policy. The difference is that held-context does
>some things that are not possible today with common-policy or
>geopriv-policy framework.
>
>Hannes/James: Thinking back to the discussions at the Dallas interim
>some time ago, I thought that there was a motion to move the
>held-context toward being more of an extension to common-policy,
>rather than an alternative policy transport. Am I recalling correctly?

there was something along those lines, but it's been a while now so
my memory isn't the greatest (I've killed a lot of brain cells since then ;-)

If your memory is right, then I would have pushed the held-context
effort to be way more general - making it an update (i.e., an
extension to) common policy; something that I don't get the
impression it ever did. That said - why hasn't it moved to being
more general in scope?

>--Richard
>
>
>
>
>James M. Polk wrote:
>>At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>>I could imagine that adding the ability to upload Common
>>>Policy/Geolocation Policy as an add-on to
>>>draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>>>using XCAP, particularly since I believe that 95% of the cases will only
>>>make usage of a fraction of Common Policy (and nothing from the
>>>geolocation policy document).
>>I'm trying to figure out what is being said here in Hannes' paragraph above.
>>Is HELD really not needing Common Policy/Geolocation Policy because
>>it has another ID specifying some other mechanism?
>>If so, why would this WG allow this?
>>Common Policy is supposed to be "common" to everything, right?
>>Geolocation Policy is supposed to be used by everything Geopriv
>>specific, right?
>>It appears the net result of this - if true - is that DHCP has to
>>jump through hoops that HELD doesn't, even though HELD can.
>>James
>>
>>>Ciao
>>>Hannes

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

At 02:17 PM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi James,
>
>Let me provide a longer description of the story.

thanks for taking the time

>With the work on the DHCP LbyR you wanted to go for the access control
>authorization model. I told you about the disadvantages before (but, as
>usual, you did not seem to like my input).
>
>The downside of that decision is that you need to provide a story for
>the access control authorization model. The only possible story in DHCP
>is to use a separate protocol mechanism. At the moment there is only one
>mechanism available for usage with DHCP, namely XCAP & Common Policy
>(and potentially Geolocation Policy).
>
>In HELD the group decided in favor of the possession authorization
>model. HELD runs on top of HTTP and hence you can put a lot of other
>stuff in there, if you want. However, with the possession model you
>don't need to upload authorization policies. If you (later) still want
>to additionally provide support for the access control model then you
>could, as an option, piggyback a Common Policy document (which was in
>one of the earliest HELD drafts -- a feature that got removed because
>it was seen as too complex by the group back then) -- something you
>cannot do with DHCP (obviously because of the size).
>
>So, the default model in HELD is the possession model and the access
>control authorization model is just an add-on. In DHCP you decided that
>the access control authorization model is the only suitable model (for
>whatever reason).
>
>About the HELD context work: Doing the work on HELD we noticed that
>additional functionality would be very useful, i.e. functionality that
>goes beyond Common Policy and the Geolocation Policy (or is even not
>directly related to the two, I would say). This work is documented in
>the HELD context document.
>
>Hope my description helped and was able to clarify the topic. This is
>not a HELD vs. DHCP issue, just as a remark.

ok - I didn't necessarily mean for this thread to be a HELD vs. DHCP
focus, I was more asking why HELD is being allowed to not do Common
and Geolocation Policy defined procedures.

What you stated above is good, but it really makes me question why we
have done all the work in Common or Geolocation Policy because if it
weren't for DHCP, neither appears to have been useful at all.

Am I wrong in that conclusion?

>Finally, as you know: The geolocation policy document provides only
>location-based authorization and transformations for location
>information. The most important features one needs are for the purpose
>discussed here is, however, authorization based on the **identity** of
>the location recipient.

So, while not disagreeing with you at all, I'm still struggling to
understand why referencing RFC 4745 isn't enough for the DHCP
location URI doc? Why does this ID need to go into all the additional
details since it is merely a delivery system piece of the soltion?

>This functionality is in Common Policy. So, I
>believe that (if this stuff gets used at all) then it will be Common
>Policy rather than Geolocation Policy.
>
>Ciao
>Hannes
>
>PS: Please note that I only review and help with the DHCP LbyR document
>review because I want to be a good GEOPRIV WG citizen and not because my
>employer has any interest in it.

I, on the other hand (& FWIW), believe in being a good <pick your WG>
citizen regardless of whether my employer has any interested in it.
Cisco is big enough to be involved in most everything, but that
doesn't mean I work with those internal groups.

> >At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>I could imagine that adding the ability to upload Common
> >>Policy/Geolocation Policy as an add-on to
> >>draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
> >>using XCAP, particularly since I believe that 95% of the cases will
> >>only make usage of a fraction of Common Policy (and nothing from the
> >>geolocation policy document).
> >
> >I'm trying to figure out what is being said here in Hannes'
> >paragraph above.
> >
> >Is HELD really not needing Common Policy/Geolocation Policy
> >because it has another ID specifying some other mechanism?
> >
> >If so, why would this WG allow this?
> >
> >Common Policy is supposed to be "common" to everything, right?
> >
> >Geolocation Policy is supposed to be used by everything
> >Geopriv specific, right?
> >
> >It appears the net result of this - if true - is that DHCP has
> >to jump through hoops that HELD doesn't, even though HELD can.
> >
> >James
> >
> >
> >>Ciao
> >>Hannes
> >
> >

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

I think that the answer that you were looking for is this:

Held-context had a few items that I still believe pertain to the minting of the URI, more so than the authorization policy. Of those three functions you list below:

-- authorization policy: common-policy is already used by held-context directly
-- lifetime: managing the lifetime of the created resource is an important problem, and one that goes beyond what is available through policy (even if some of the effects can be mimicked by using policy)
-- snapshot: I'm yet to see a workable proposal that extends common- or geopriv-policy; I'd love to see one.

Regarding the fundamentals:

The problem I have is the continuing mutation of the HELD locationRequest. I was perhaps in the minority when it came to deciding that "locationURI" was a location type. I would have preferred that locationURI was the subject of an entirely separate request (i.e. context creation). Sure, there are some good reasons for it being as it is, but those are reasons of convenience for the most part.

Thus, on consideration, the largest problem I have with your proposal is that it continues to build on something that is only marginally useful in the first place. The net result is an increase in complexity, with less to show for it.

However, I see this as constructive input on held-context. I've been toying with ideas regarding better modularity and use of REST-like principles in its design. Perhaps there's an opportunity to make some improvements.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Richard Barnes
> Sent: Tuesday, 22 September 2009 7:08 AM
> To: Winterbottom, James
> Cc: GEOPRIV; James M. Polk; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation
> Policy
>
> Hm, no, that's not the answer I was looking for. Here's what I'm
> thinking: Context has basically two parts,
> 1. Protocol mechanics for creating/updating/deleting contexts
> 2. Attributes of contexts that can be set with those mechanics
>
> I was thinking that (1) could move toward being XCAP, and (2) could
> move
> toward extensions of the policy language.
>
> In particular, w.r.t. (2), there are only three things that can be set:
> -- "Authorization policy" is already common-policy
> -- "Context lifetime" may require some extension, but is largely the
> same as the <validity> element of common-policy
> -- "Snapshot context" is the most novel, but you could probably still
> implement it with an extension to the <provide-location> element from
> geopriv-policy.
>
> The protocol mechanics (1) don't do anything really magical; I think
> you
> could map semantics pretty cleanly to a combination of HELD and XCAP.
>
> --Richard
>
>
>
> Winterbottom, James wrote:
> > Hi Richard,
> >
> > I see Context as a being a container, one of the things of which it
> can contain is a common policy document.
> >
> > Does that help?
> >
> > Cheers
> > James
> >
> >
> > -----Original Message-----
> > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > Sent: Mon 9/21/2009 3:42 PM
> > To: James M. Polk
> > Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes
> Tschofenig; GEOPRIV
> > Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
> >
> > James: Don't worry. Nothing in held-context is getting rid of or
> > duplicating Common Policy. The difference is that held-context does
> > some things that are not possible today with common-policy or
> > geopriv-policy framework.
> >
> > Hannes/James: Thinking back to the discussions at the Dallas interim
> > some time ago, I thought that there was a motion to move the
> > held-context toward being more of an extension to common-policy,
> rather
> > than an alternative policy transport. Am I recalling correctly?
> >
> > --Richard
> >
> >
> >
> >
> > James M. Polk wrote:
> >> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>> I could imagine that adding the ability to upload Common
> >>> Policy/Geolocation Policy as an add-on to
> >>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
> >>> using XCAP, particularly since I believe that 95% of the cases will
> only
> >>> make usage of a fraction of Common Policy (and nothing from the
> >>> geolocation policy document).
> >> I'm trying to figure out what is being said here in Hannes'
> paragraph
> >> above.
> >>
> >> Is HELD really not needing Common Policy/Geolocation Policy because
> it
> >> has another ID specifying some other mechanism?
> >>
> >> If so, why would this WG allow this?
> >>
> >> Common Policy is supposed to be "common" to everything, right?
> >>
> >> Geolocation Policy is supposed to be used by everything Geopriv
> >> specific, right?
> >>
> >> It appears the net result of this - if true - is that DHCP has to
> jump
> >> through hoops that HELD doesn't, even though HELD can.
> >>
> >> James
> >>
> >>
> >>> Ciao
> >>> Hannes
> >>
> >
> >
> > ---------------------------------------------------------------------
> ---------------------------
> > 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]
> >
> >
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] LCP & Arch....

Martin,

In-line....

On 9/20/09 9:11 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:

>> What am I missing?
>
> Nothing.
>
> We might have a different view of what is necessary for this group to produce
> though.

agree

>
> I think that you are obliquely suggesting that we need to establish a baseline
> for what identity can be used, how it is used, references to the mechanisms to
> employ, etc... All that would be necessary for a Rule Maker to identify and
> authorize arbitrary Location Recipients.

Agree, I believe that is our task at hand.

>
> That's really great if you think that third party requesting is part of the
> end-game architecture. Third parties from all over request location
> information I don't think that. In fact, we'd be wasting our time if we
> pursued that. It's a big problem that isn't worth solving. Not because it
> wouldn't be useful, but because it isn't necessary.
>
> Location by reference solves much of this problem by allowing us to move from
> location configuration (local) to presence (global) where all those sorts of
> problems are in the process of being solved. That's the end-game I'm thinking
> about.
>
> Third party requests don't really figure in this end-game. Third party
> requests exist because we have an immediate need that cannot be addressed by
> the end-game solution. That need has very specific requirements that
> held-identity-extensions addresses.

First, I consider 'third party' to include other contexts than what you are
inferring here. My spouse asking my presence server for my location is a
'third party' request from a RuleMaker pov.

Hence, I have to assume that your use of 'third party' in this context is
probably closer to the previous term used, OBO. So, I assume we are talking
about the need to discover a location on behalf of a location unaware
device, which seems to coincide with what others are asking to solve.

>
> Let me suggest an alternative then. We state the following: the means by
> which authentication of requesters is established is a matter for local
> policy. Tools that are provided include TLS (authentication by shared private
> key, PKI, etc...) and HTTP authentication. If you like, you can authenticate
> based on the source IP of the request if that suits you.
>
> It's all up to the discretion of the Rule Maker.

Before we can agree to the above, we have to agree that HELD identity
extensions is strictly for the use-case described (further) above,
third-party/OBO (we need to pick one term), and can not be used by a target
discovering it's own location from a Rulemaker pov. Hence, HELD identity
extensions is not an LCP. Obviously a target could request a location
associated with an identity that happens to be it's own identity from a
different obscure layer, but since there is no way for the Rulemaker to
ascertain the request is from a target, the only possible policy that can be
applied in this use case, is a third-party/OBO policy.

Let's establish this before continuing.

-Marc-

>
> --Martin
>
> ------------------------------------------------------------------------------
> ------------------
> 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]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hm, no, that's not the answer I was looking for. Here's what I'm
thinking: Context has basically two parts,
1. Protocol mechanics for creating/updating/deleting contexts
2. Attributes of contexts that can be set with those mechanics

I was thinking that (1) could move toward being XCAP, and (2) could move
toward extensions of the policy language.

In particular, w.r.t. (2), there are only three things that can be set:
-- "Authorization policy" is already common-policy
-- "Context lifetime" may require some extension, but is largely the
same as the <validity> element of common-policy
-- "Snapshot context" is the most novel, but you could probably still
implement it with an extension to the <provide-location> element from
geopriv-policy.

The protocol mechanics (1) don't do anything really magical; I think you
could map semantics pretty cleanly to a combination of HELD and XCAP.

--Richard

Winterbottom, James wrote:
> Hi Richard,
>
> I see Context as a being a container, one of the things of which it can contain is a common policy document.
>
> Does that help?
>
> Cheers
> James
>
>
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Mon 9/21/2009 3:42 PM
> To: James M. Polk
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes Tschofenig; GEOPRIV
> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>
> James: Don't worry. Nothing in held-context is getting rid of or
> duplicating Common Policy. The difference is that held-context does
> some things that are not possible today with common-policy or
> geopriv-policy framework.
>
> Hannes/James: Thinking back to the discussions at the Dallas interim
> some time ago, I thought that there was a motion to move the
> held-context toward being more of an extension to common-policy, rather
> than an alternative policy transport. Am I recalling correctly?
>
> --Richard
>
>
>
>
> James M. Polk wrote:
>> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>> I could imagine that adding the ability to upload Common
>>> Policy/Geolocation Policy as an add-on to
>>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>>> using XCAP, particularly since I believe that 95% of the cases will only
>>> make usage of a fraction of Common Policy (and nothing from the
>>> geolocation policy document).
>> I'm trying to figure out what is being said here in Hannes' paragraph
>> above.
>>
>> Is HELD really not needing Common Policy/Geolocation Policy because it
>> has another ID specifying some other mechanism?
>>
>> If so, why would this WG allow this?
>>
>> Common Policy is supposed to be "common" to everything, right?
>>
>> Geolocation Policy is supposed to be used by everything Geopriv
>> specific, right?
>>
>> It appears the net result of this - if true - is that DHCP has to jump
>> through hoops that HELD doesn't, even though HELD can.
>>
>> James
>>
>>
>>> Ciao
>>> Hannes
>>
>
>
> ------------------------------------------------------------------------------------------------
> 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]
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

>Hannes/James: Thinking back to the discussions at the Dallas
>interim some time ago, I thought that there was a motion to
>move the held-context toward being more of an extension to
>common-policy, rather than an alternative policy transport.
>Am I recalling correctly?

You recall it correctly. I tried it and it was super complex without any
additional benefit. I posted something to the list, if I recall it
correctly.
I could even try to find it
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hi Richard,

I see Context as a being a container, one of the things of which it can contain is a common policy document.

Does that help?

Cheers
James

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Mon 9/21/2009 3:42 PM
To: James M. Polk
Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes Tschofenig; GEOPRIV
Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy

James: Don't worry. Nothing in held-context is getting rid of or
duplicating Common Policy. The difference is that held-context does
some things that are not possible today with common-policy or
geopriv-policy framework.

Hannes/James: Thinking back to the discussions at the Dallas interim
some time ago, I thought that there was a motion to move the
held-context toward being more of an extension to common-policy, rather
than an alternative policy transport. Am I recalling correctly?

--Richard

James M. Polk wrote:
> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> I could imagine that adding the ability to upload Common
>> Policy/Geolocation Policy as an add-on to
>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>> using XCAP, particularly since I believe that 95% of the cases will only
>> make usage of a fraction of Common Policy (and nothing from the
>> geolocation policy document).
>
> I'm trying to figure out what is being said here in Hannes' paragraph
> above.
>
> Is HELD really not needing Common Policy/Geolocation Policy because it
> has another ID specifying some other mechanism?
>
> If so, why would this WG allow this?
>
> Common Policy is supposed to be "common" to everything, right?
>
> Geolocation Policy is supposed to be used by everything Geopriv
> specific, right?
>
> It appears the net result of this - if true - is that DHCP has to jump
> through hoops that HELD doesn't, even though HELD can.
>
> James
>
>
>> Ciao
>> Hannes
>
>

------------------------------------------------------------------------------------------------
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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv]

RFC 5606?
<http://tools.ietf.org/html/rfc5606>

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi Brian,
> Hi James
>
> if I am the only one still seeing problems with <retransmission-allowed>
> in context of SIP location conveyance then I keep my mouth shut.
>
> Ciao
> Hannes
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

James: Don't worry. Nothing in held-context is getting rid of or
duplicating Common Policy. The difference is that held-context does
some things that are not possible today with common-policy or
geopriv-policy framework.

Hannes/James: Thinking back to the discussions at the Dallas interim
some time ago, I thought that there was a motion to move the
held-context toward being more of an extension to common-policy, rather
than an alternative policy transport. Am I recalling correctly?

--Richard

James M. Polk wrote:
> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> I could imagine that adding the ability to upload Common
>> Policy/Geolocation Policy as an add-on to
>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>> using XCAP, particularly since I believe that 95% of the cases will only
>> make usage of a fraction of Common Policy (and nothing from the
>> geolocation policy document).
>
> I'm trying to figure out what is being said here in Hannes' paragraph
> above.
>
> Is HELD really not needing Common Policy/Geolocation Policy because it
> has another ID specifying some other mechanism?
>
> If so, why would this WG allow this?
>
> Common Policy is supposed to be "common" to everything, right?
>
> Geolocation Policy is supposed to be used by everything Geopriv
> specific, right?
>
> It appears the net result of this - if true - is that DHCP has to jump
> through hoops that HELD doesn't, even though HELD can.
>
> James
>
>
>> Ciao
>> Hannes
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv]

Hi Brian,
Hi James

if I am the only one still seeing problems with <retransmission-allowed> in context of SIP location conveyance then I keep my mouth shut.

Ciao
Hannes

Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

Hi James,

Let me provide a longer description of the story.

With the work on the DHCP LbyR you wanted to go for the access control
authorization model. I told you about the disadvantages before (but, as
usual, you did not seem to like my input).

The downside of that decision is that you need to provide a story for
the access control authorization model. The only possible story in DHCP
is to use a separate protocol mechanism. At the moment there is only one
mechanism available for usage with DHCP, namely XCAP & Common Policy
(and potentially Geolocation Policy).

In HELD the group decided in favor of the possession authorization
model. HELD runs on top of HTTP and hence you can put a lot of other
stuff in there, if you want. However, with the possession model you
don't need to upload authorization policies. If you (later) still want
to additionally provide support for the access control model then you
could, as an option, piggyback a Common Policy document (which was in
one of the earliest HELD drafts -- a feature that got removed because
it was seen as too complex by the group back then) -- something you
cannot do with DHCP (obviously because of the size).

So, the default model in HELD is the possession model and the access
control authorization model is just an add-on. In DHCP you decided that
the access control authorization model is the only suitable model (for
whatever reason).

About the HELD context work: Doing the work on HELD we noticed that
additional functionality would be very useful, i.e. functionality that
goes beyond Common Policy and the Geolocation Policy (or is even not
directly related to the two, I would say). This work is documented in
the HELD context document.

Hope my description helped and was able to clarify the topic. This is
not a HELD vs. DHCP issue, just as a remark.

Finally, as you know: The geolocation policy document provides only
location-based authorization and transformations for location
information. The most important features one needs are for the purpose
discussed here is, however, authorization based on the **identity** of
the location recipient. This functionality is in Common Policy. So, I
believe that (if this stuff gets used at all) then it will be Common
Policy rather than Geolocation Policy.

Ciao
Hannes

PS: Please note that I only review and help with the DHCP LbyR document
review because I want to be a good GEOPRIV WG citizen and not because my
employer has any interest in it.

>At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>I could imagine that adding the ability to upload Common
>>Policy/Geolocation Policy as an add-on to
>>draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>>using XCAP, particularly since I believe that 95% of the cases will
>>only make usage of a fraction of Common Policy (and nothing from the
>>geolocation policy document).
>
>I'm trying to figure out what is being said here in Hannes'
>paragraph above.
>
>Is HELD really not needing Common Policy/Geolocation Policy
>because it has another ID specifying some other mechanism?
>
>If so, why would this WG allow this?
>
>Common Policy is supposed to be "common" to everything, right?
>
>Geolocation Policy is supposed to be used by everything
>Geopriv specific, right?
>
>It appears the net result of this - if true - is that DHCP has
>to jump through hoops that HELD doesn't, even though HELD can.
>
>James
>
>
>>Ciao
>>Hannes
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>I could imagine that adding the ability to upload Common
>Policy/Geolocation Policy as an add-on to
>draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>using XCAP, particularly since I believe that 95% of the cases will only
>make usage of a fraction of Common Policy (and nothing from the
>geolocation policy document).

I'm trying to figure out what is being said here in Hannes' paragraph above.

Is HELD really not needing Common Policy/Geolocation Policy because
it has another ID specifying some other mechanism?

If so, why would this WG allow this?

Common Policy is supposed to be "common" to everything, right?

Geolocation Policy is supposed to be used by everything Geopriv
specific, right?

It appears the net result of this - if true - is that DHCP has to
jump through hoops that HELD doesn't, even though HELD can.

James

>Ciao
>Hannes

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-geo-uri-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : A Uniform Resource Identifier for Geographic Locations ('geo' URI)
Author(s) : A. Mayrhofer, C. Spanring
Filename : draft-ietf-geopriv-geo-uri-03.txt
Pages : 21
Date : 2009-09-21

This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and
protocol independent way. The default coordinate reference system
used is WGS-84.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-geo-uri-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[Geopriv] draft-ietf-geopriv-geo-uri-03 posted (adressing WGLC comments)

I have just posted an update of the "geo" URI draft:

http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-03.txt

This version addresses comments from the Working Group Last Call, so the
document should be ready for requesting publication..

Thanks,

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #17: Text nits by Ivan Shmakov

#17: Text nits by Ivan Shmakov
----------------------------------------+-----------------------------------
Reporter: alexander.mayrhofer@nic.at | Owner: alexander.mayrhofer@nic.at
Type: enhancement | Status: closed
Priority: trivial | Milestone:
Component: geo-uri | Version:
Severity: - | Resolution: fixed
Keywords: |
----------------------------------------+-----------------------------------
Changes (by alexander.mayrhofer@nic.at):

* status: new => closed
* resolution: => fixed

Comment:

added changes to -03 version.

--
Ticket URL: <http://tools.ietf.org/wg/geopriv/trac/ticket/17#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #16: "time dependent" text

#16: "time dependent" text
----------------------------------------+-----------------------------------
Reporter: alexander.mayrhofer@nic.at | Owner: alexander.mayrhofer@nic.at
Type: defect | Status: closed
Priority: trivial | Milestone:
Component: geo-uri | Version:
Severity: In WG Last Call | Resolution: fixed
Keywords: |
----------------------------------------+-----------------------------------
Changes (by alexander.mayrhofer@nic.at):

* status: new => closed
* resolution: => fixed

Comment:

Fixed using the text from Alissa's comments. To be included in -03

--
Ticket URL: <http://tools.ietf.org/wg/geopriv/trac/ticket/16#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #18: Last call issues and nits from Alissa

#18: Last call issues and nits from Alissa
----------------------------------------+-----------------------------------
Reporter: alexander.mayrhofer@nic.at | Owner: alexander.mayrhofer@nic.at
Type: defect | Status: closed
Priority: minor | Milestone:
Component: geo-uri | Version:
Severity: - | Resolution: fixed
Keywords: |
----------------------------------------+-----------------------------------
Changes (by alexander.mayrhofer@nic.at):

* status: new => closed
* resolution: => fixed

Comment:

I have applied all changes to the upcoming version -03.

--
Ticket URL: <http://tools.ietf.org/wg/geopriv/trac/ticket/18#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv