headers
Internet-Drafts | 29 Jun 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-geopriv-radius-lo-07.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		: Carrying Location Objects in RADIUS
	Author(s)	: H. Tschofenig, et al.
	Filename	: draft-ietf-geopriv-radius-lo-07.txt
	Pages		: 56
	Date		: 2006-6-28
	
This document describes RADIUS attributes for conveying access
network ownership and location information based on a civic and
geospatial location format.

The distribution of location information is a privacy sensitive task.
Dealing with mechanisms to preserve the user's privacy is important
and addressed in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-geopriv-radius-lo-07.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Tschofenig | 29 Jun 2006 23:03
Picon

draft-ietf-sip-location-conveyance-03.txt Comments

Hi Brian,
Hi James

I have a few questions concerning the latest SIP location conveyance 
document.

* Usage Cases

I think we need to consider the following scenarios:

(a) Location transport per-value (a1) and per-reference (a2)

(b) Location transport in the header (b1) and in the body (b2)

(a) and (b) has to be combined to produce a reasonable combination.

Let me go through the individual cases:

- If SIP UA Alice wants to convey location information to SIP UA Bob 
then it should put the PIDF-LO into the body (and apply S/MIME to it). 
(Case a1+b2)

- If a proxy wants to add location information to a SIP message then it 
creates the PIDF-LO and a reference to it. The reference is placed into 
the SIP header. (Case a2+b1)
Would the proxy use M2M/M2E security?

- If SIP UA Alice has to perform location-based routing (e.g., as used 
in emergency scenarios) then it has to place something into the SIP 
header since the proxy is not supposed to inspect the body (particularly
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ted Hardie | 30 Jun 2006 21:42

Proposed Resolution to the draft-ietf-geopriv-common-policy issue.

Howdy,

During the IESG review of this draft, Sam Hartman raised an issue relate to the internationalization aspects
of this draft and asked that it be given further review on that topic.  Paul Hoffman was kind enough to review
it, and after he and I discussed the issues Sam raised, we agreed that there was problem in the description
in 7.1.3.  Below there is a proposed RFC Editor note to resolve it.

Paul also felt that it would be good to include an informative reference to RFC 3987
(the IRI spec) on the first mention of xs:anyURI, since it contains useful applicability language.  He
also suggested that the document highlight the statement made in section 5 that conditions are matched
on equality by repeating and expanding on it in the beginning of Section 7.  I propose adding a reference
to xs:anyURI in Section 7, and combining those notes.
			regards,
				Ted Hardie

In 7.

OLD

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) that are used for
   authorization.  A rule in a rule set might have a number of
   conditions that need to be met before executing the remaining parts
   of a rule (i.e., actions and transformations).  Details about rule
   matching are described in Section 10.  This document specifies only a
   few conditions (i.e., identity, sphere, and validity).  Further
   condition elements can be added via extensions to this document.

NEW
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Newton | 30 Jun 2006 22:04
Picon

Re: [Geopriv] Proposed Resolution to the draft-ietf-geopriv-common-policy issue.


On Jun 30, 2006, at 3:42 PM, Ted Hardie wrote:
> In 7.
>
>
> NEW
>
>    The access to data items needs to be matched with the rule set  
> stored
>    at the PS.  Each instance of a request has different attributes
>    (e.g., the identity of the requestor) that are used for
>    authorization.  A rule in a rule set might have a number of
>    conditions that need to be met before executing the remaining parts
>    of a rule (i.e., actions and transformations).  Details about rule
>    matching are described in Section 10.  This document specifies  
> only a
>    few conditions (i.e., identity, sphere, and validity).  Further
>    condition elements can be added via extensions to this document.
>
>    As noted above in section five, conditions are matched on equality
>    or "great than" style comparisons, rather than regular expressions.
>

    s/great than/greater than/

>    Equality is determined according to the rules for the data type  
> associated
>    with the element in the schema given in section 13 below, unless  
> explicit
>     comparison steps are included in this document.  For xs:anyURI
(Continue reading)

Permalink | Reply | 0 comments |

Gmane