IETF Logo Mail Archive

Re: [Geopriv] geopriv-arch AUTH48

"Thomson, Martin" <Martin.Thomson@commscope.com> Mon, 11 July 2011 01:36 UTC

Return-Path: <Martin.Thomson@commscope.com>
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 4CBF321F8669 for <geopriv@ietfa.amsl.com>; Sun, 10 Jul 2011 18:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
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 Zj6WjPcx3CUR for <geopriv@ietfa.amsl.com>; Sun, 10 Jul 2011 18:36:00 -0700 (PDT)
Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id AE55321F877A for <geopriv@ietf.org>; Sun, 10 Jul 2011 18:36:00 -0700 (PDT)
X-AuditID: 0a0404e9-b7c5fae000000985-98-4e1a53899b6d
Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 99.9D.02437.9835A1E4; Sun, 10 Jul 2011 20:36:09 -0500 (CDT)
Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 10 Jul 2011 20:36:57 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 10 Jul 2011 18:36:57 -0700
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 11 Jul 2011 09:31:03 +0800
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Date: Mon, 11 Jul 2011 09:31:25 +0800
Thread-Topic: [Geopriv] geopriv-arch AUTH48
Thread-Index: Acw9qrUuTpGsA5dgTP22+g4ziC4dZgBv4MOw
Message-ID: <8B0A9FCBB9832F43971E38010638454F040B419CC0@SISPE7MB1.commscope.com>
References: <7CB2113F-184E-4B14-84DF-B6633906A8E2@cdt.org> <24D9B41F-2728-4F93-B27F-B2FC319571C4@gmx.net> <865F5092-E382-4E58-B50E-8A002A22100E@bbn.com>
In-Reply-To: <865F5092-E382-4E58-B50E-8A002A22100E@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "geopriv@ietf.org" <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: Mon, 11 Jul 2011 01:36:01 -0000

Yeah.  Much better in fact.

On 2011-07-09 at 05:32:17, Richard L. Barnes wrote:
> +1
> 
> On Jul 8, 2011, at 3:14 PM, Hannes Tschofenig wrote:
> 
> > 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
> >
> > _______________________________________________
> > 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

v2.23.0 | Report a Bug | By Email