Re: [yaco-liaison-tool] The liaison tool: Status Update

"Emilio A. Sánchez" <esanchez@yaco.es> Thu, 07 April 2011 09:24 UTC

Return-Path: <esanchez@yaco.es>
X-Original-To: yaco-liaison-tool@core3.amsl.com
Delivered-To: yaco-liaison-tool@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2ECC3A69F7 for <yaco-liaison-tool@core3.amsl.com>; Thu, 7 Apr 2011 02:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.96
X-Spam-Level:
X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPWd-GLUJk+p for <yaco-liaison-tool@core3.amsl.com>; Thu, 7 Apr 2011 02:24:56 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C9CC53A69EE for <yaco-liaison-tool@ietf.org>; Thu, 7 Apr 2011 02:24:55 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1752148fxm.31 for <yaco-liaison-tool@ietf.org>; Thu, 07 Apr 2011 02:26:39 -0700 (PDT)
Received: by 10.223.95.138 with SMTP id d10mr639370fan.21.1302168399548; Thu, 07 Apr 2011 02:26:39 -0700 (PDT)
Received: from [192.168.0.197] ([77.227.215.107]) by mx.google.com with ESMTPS id 21sm418113fav.41.2011.04.07.02.26.37 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 02:26:38 -0700 (PDT)
Message-ID: <4D9D8359.6080205@yaco.es>
Date: Thu, 07 Apr 2011 11:26:49 +0200
From: =?ISO-8859-1?Q?=22Emilio_A=2E_S=E1nchez=22?= <esanchez@yaco.es>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <pfaltstr@cisco.com>
References: <4D483171.7090508@levkowetz.com> <A9723AE7-F5B8-4722-BBB6-80F71C6AED31@amsl.com> <4D485061.3090204@levkowetz.com> <1FD00AF1-C1C6-4D33-9E70-E2B3D3ED11A6@cisco.com> <4D494292.1000809@levkowetz.com> <D4C88766-1C27-4212-B833-EF9F3B06452C@cisco.com> <4D49D50A.9000408@levkowetz.com> <18D7B1E6-2A70-4C5A-8C0E-9D43AD489599@cisco.com> <4D4B0946.7070302@levkowetz.com> <AF68B07C-FB34-4B7D-B710-848C710E20E1@cisco.com> <4D4BB18F.8020808@yaco.es> <09D40B0B-3058-4416-AC88-49C072EE93E0@cisco.com> <1EA3B690-E6A3-4988-8D2A-8A73147117EA@amsl.com> <C09F0708-AD85-4B96-BB63-537DE1936373@cisco.com> <4D9C5C79.40904@levkowetz.com> <4D9C72BB.8020605@yaco.es> <4D9D74E6.3080808@levkowetz.com> <37685D0B-E5C4-4AAF-AF3F-CA61663D789B@cisco.com> <4D9D7EFC.8040503@yaco.es> <4A5DE368-1D2B-4419-A8C3-0E31749285C7@cisco.com>
In-Reply-To: <4A5DE368-1D2B-4419-A8C3-0E31749285C7@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: yaco-liaison-tool@ietf.org, Eliot Lear <lear@cisco.com>, Ray Pelletier <rpelletier@isoc.org>
Subject: Re: [yaco-liaison-tool] The liaison tool: Status Update
X-BeenThere: yaco-liaison-tool@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of the Yaco / Liaison Statement Management Tool Project details <yaco-liaison-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yaco-liaison-tool>, <mailto:yaco-liaison-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yaco-liaison-tool>
List-Post: <mailto:yaco-liaison-tool@ietf.org>
List-Help: <mailto:yaco-liaison-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yaco-liaison-tool>, <mailto:yaco-liaison-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 09:24:56 -0000

El 07/04/11 11:19, Patrik Fältström escribió:
> On 7 apr 2011, at 11.08, Emilio A. Sánchez wrote:
>
>>> The important thing is to be able to update the liaisons. And we can trust our (IETF) liaisons, so to get fine-grained access rights is not so important. The ability to get things right in the database is. Having bad data in the database -- as now -- is not working in the long(er) run.
>>
>>    I suppose, as I said in my previous mail, that the problem is who can 'take care' (mark as done) a liaison. Right now this action can be done by anyone whose email is listed in the liaison. But probably I should add the people that can edit the liaison to the ones that can 'take care' of it.
>
> That imply that someone from ITU-T that is the receiver of a liaison can log in an edit an outgoing liaison that they receive... "interesting feature"...
>
> You have an access right already today when one add a liaison, right? That access algorithm say whether you as a user can add certain data in the to/from fields.

    No, no, no. He can use the button "Take care of" (the one that 
appears in the detail of a liaison next to 'No actions taken') cause he 
(as a receiver) can now if the liaison has been taken care.

    People who can edit a liaison are:

    * The secretariat (always)
    * A Liaison Manager with these conditions:
       * For outgoing liaisons: If the liaison was sent to its SDO
       * For incoming liaisons: If the liaison was sent from its SDO

> 1. An external party, for example someone from ITU SG2, should only be able to add a liaison that is incoming to IETF from SG2, but with various receivers on the IETF side.
>
> 2. An internal party, for example liaison to ITU-T SG2, should only be able to add liaisons to or from IETF and that external party.
>
> 3. An internal party that has power gloves, like the liaison to ITU-T should be like (2) but for more SG's than one
>
> 4. Secretariat should be able to access everything
>
> Easiest way of course for 1, 2 and 3 is to have the ability for each user to map that to one relationship, and whether the access is incoming or outgoing. For example:
>
> A. A user have access to some external groups (zero or more).
>
> B. If the user is _incoming_ then the user can only add incoming liaisons.
>
> C. If the user is _outgoing_ then the user can add incoming, outgoing liaisons AND edit the liaisons.
>
> But once again, I am not so worried about giving people "too much access" to start with, because we have had problems for years with having not enough access in the tool.
>
> So lets start with what you now have created! Sounds fine!
>
>     Patrik
>