Re: [Geopriv] geopriv-arch AUTH48

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 08 July 2011 19:15 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC421F8CBC for <geopriv@ietfa.amsl.com>; Fri, 8 Jul 2011 12:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level:
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSKRJ51yXl4J for <geopriv@ietfa.amsl.com>; Fri, 8 Jul 2011 12:15:01 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0EBD221F8903 for <geopriv@ietf.org>; Fri, 8 Jul 2011 12:15:00 -0700 (PDT)
Received: (qmail invoked by alias); 08 Jul 2011 19:14:59 -0000
Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp025) with SMTP; 08 Jul 2011 21:14:59 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX191pTgP7kJ1Fcaj4JrUqThifpI7x05frKiaIHG15b OMtXCME6ESvlSc
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <7CB2113F-184E-4B14-84DF-B6633906A8E2@cdt.org>
Date: Fri, 08 Jul 2011 22:14:58 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D9B41F-2728-4F93-B27F-B2FC319571C4@gmx.net>
References: <7CB2113F-184E-4B14-84DF-B6633906A8E2@cdt.org>
To: Alissa Cooper <acooper@cdt.org>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] geopriv-arch AUTH48
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2011 19:15:02 -0000

Fine for me. 

On Jul 8, 2011, at 8:31 PM, Alissa Cooper wrote:

> draft-ietf-geopriv-arch-03 is in AUTH48 and the authors have suggested a slight change to some normative language in section 4.2.4. Here is the section:
> 
> An LS that receives Rules exclusively through LOs MUST examine the
>   Rules that accompany a given LO in order to determine how the LS may
>   use the LO (if any Rules are included by reference, the LS SHOULD
>   attempt to download them).  If the LO includes no Rules that allow
>   the LS to transmit the LO to another entity, then the LS MUST NOT
>   transmit the LO.  If the LO contains no Rules at all (if it is in a
>   format with no Rules syntax, for example), then the LS MUST delete it
>   (emergency services provide an exception in that Rules can be
>   implicit; see [15]).  If the LO included Rules by reference, but
>   these Rules were not obtained for any reason, the LS MUST NOT
>   transmit the LO and MUST delete it.
> 
> Here is the suggested change:
> 
> OLD:
> If the LO included Rules by reference, but
> these Rules were not obtained for any reason, the LS MUST NOT
> transmit the LO and MUST delete it.
> 
> NEW:
> If the LO included Rules by reference, but
> these Rules were not obtained for any reason, the LS MUST NOT
> transmit the LO and MUST adere to the provided value in the retention-expires field.
> 
> The change has been proposed to clarify that 
> a) if the LS does not want to re-transmit location information then it does not immediately have to delete 
> the received location object but instead looks at the retention-expires field only.
> b) if the LS wants to transmit location information it is not allowed to do so. The retention-expires field would also give guidance on how long it is permitted to keep the location.
> 
> Since this is a change to normative language, if folks have objections to it we're requesting that they send them to the list by next Wednesday, July 13.
> 
> Thanks,
> Alissa 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv