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

Russ Housley <housley@vigilsec.com> Thu, 21 April 2011 19:30 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: yaco-liaison-tool@ietfc.amsl.com
Delivered-To: yaco-liaison-tool@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FB47E07D6 for <yaco-liaison-tool@ietfc.amsl.com>; Thu, 21 Apr 2011 12:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level:
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqrrFS79+908 for <yaco-liaison-tool@ietfc.amsl.com>; Thu, 21 Apr 2011 12:30:18 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfc.amsl.com (Postfix) with ESMTP id 54BEBE07D1 for <yaco-liaison-tool@ietf.org>; Thu, 21 Apr 2011 12:30:17 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id DB312F24165; Thu, 21 Apr 2011 15:30:24 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 3kjV-xVa+QVy; Thu, 21 Apr 2011 15:30:14 -0400 (EDT)
Received: from [192.168.2.100] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 15633F24162; Thu, 21 Apr 2011 15:30:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-18-836983779
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <32D56C0A-9FF1-4F9F-A536-2B7D2055BCEF@amsl.com>
Date: Thu, 21 Apr 2011 15:30:14 -0400
Message-Id: <8E5CD944-6CD4-410F-A72F-0A820156B6E2@vigilsec.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> <4D9D7BBC.4030708@yaco.es> <4D9D80D5.50302@levkowetz.com> <4D9D85CF.1030100@yaco.es> <4D9DA1B6.6010103@levkowetz.com> <54B04D20-1849-400D-9690-0926EBD944F1@amsl.com> <4DA2CAF1.8080608@yaco.es> <2EEB40DE-A7E8-45E0-9194-6FE0DEFC8CF0@amsl.com> <4DA46F99.6010802@yaco.es> <619C8DA6-16B4-461E-B901-71AFC890035! 4@amsl.com> <036801cbfbb1$118c1f50$34a45df0$@olddog.co.uk> <32D56C0A-9FF1-4F9F-A536-2B7D2055BCEF@amsl.com>
To: Alexa Morris <amorris@amsl.com>
X-Mailer: Apple Mail (2.1084)
Cc: yaco-liaison-tool@ietf.org, 'Eliot Lear' <lear@cisco.com>, =?iso-8859-1?Q?=22=27Patrik_F=E4ltstr=F6m=27=22?= <pfaltstr@cisco.com>, 'Ray Pelletier' <rpelletier@isoc.org>, adrian@olddog.co.uk
Subject: Re: [yaco-liaison-tool] The liaison tool: Status Update
X-BeenThere: yaco-liaison-tool@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 21 Apr 2011 19:30:20 -0000

Yes there should be an option -- for two reasons.

(1) Incoming Liaison Statements - sometimes other SDOs send them to Chairs or ADs, which then get forwarded at some later point for posting.  They should reflect the date that they were originally received.

(2) Outgoing Liaison Statements - again, mistakes happen.  If the tool is not used to send it in the first place, when it is posted it should reflect the date it was actually sent to the recipient SDO.

Russ


On Apr 21, 2011, at 3:15 PM, Alexa Morris wrote:

> Adrian:
> 
> When you post a liaison, it will show the date it was posted -- there is no option (at least for us) to change the date to make it show the original submission date. 
> 
> Henrik, Emilio: 
> is there an option -- or should there be -- to update the date so that it reflects the actual submission date and not the (now very delayed) date that it will be posted? There is another liaison in the queue that Stephanie could not post, but now can, that will be similarly impacted. 
> 
> And to Adrian's other question, when the Secretariat posts a liaison, we have the option to "post only" or "post and send". Does a regular liaison manager have the ability to make such a distinction as well? It sounds as if Adrian might want to avoid a duplicate announcement since he already copied a bunch of folks on his initial attempt at posting the liaison.
> 
> Thanks,
> Alexa
> 
> 
> On Apr 15, 2011, at 2:07 PM, Adrian Farrel wrote:
> 
>> Thanks Stephanie,
>>  
>> Do you know whether if *I* post it, it will show all the dates right and not send another copy?
>>  
>> There is no really great urgency to getting a copy of the LS into the tracker, but I would like to avoid any snafus with what is ultimately recorded and what might get sent.
>>  
>> Cheers,
>> Adrian
>>  
>> PS - Tanks to all for working on the tool!
>>  
>> From: Stephanie McCammon [mailto:smccammon@amsl.com] 
>> Sent: 15 April 2011 21:24
>> To: Emilio A. Sánchez
>> Cc: Henrik Levkowetz; Patrik Fältström; Alexa Morris; Russ Housley; Eliot Lear; Ray Pelletier; Barney Glen; yaco-liaison-tool@ietf.org; adrian@olddog.co.uk
>> Subject: Re: The liaison tool: Status Update
>>  
>>  
>>  
>> Hello everyone
>>  
>> Henrik was able to do the merge, however the tool is still not functioning properly.  It still tells me that I am not allowed to send a liaison to the ITU-T SG 15.  Please look into this as soon as you have a chance.
>>  
>> Adrian,
>>  
>> The new liaison tool will not let me post the response liaison to the ITU-T SG 15 regarding COM15-LS293-E, and while we are working this out you may want to try posting it for yourself.  The CC field should now be editable for you.  Please let me know if you have any questions.
>>  
>> Sincerely,
>>  
>> Stephanie
>>  
>>  
>> On Apr 12, 2011, at 8:28 AM, Emilio A. Sánchez wrote:
>> 
>> 
>>   Hi Stephanie.
>> 
>>   The last fix is applied in a repository branch, it needs to be merged into trunk and then update the code of the production server.
>> 
>>   Henrik, could you do the merge?
>> 
>>   Best,
>> 
>> El 12/04/11 17:24, Stephanie McCammon escribió:
>> 
>>  
>>  
>> Hi Emilio,
>>  
>> I have just tried to post the liaison on behalf of Adrian Farrel and it
>> still says that I am not allowed to send it and reverts the form back to
>> saying that it is from me. Could you please look into this again?
>>  
>> Thank you,
>>  
>> Stephanie
>>  
>>  
>> On Apr 11, 2011, at 2:33 AM, Emilio A. Sánchez wrote:
>>  
>> Hi,
>>  
>> I have fixed this issue in
>> http://trac.tools.ietf.org/tools/ietfdb/ticket/648
>>  
>> Now the tool takes into account which user are you imporsonating in
>> order to check if he/she is allowed to send a liaison to an specific SDO.
>>  
>> Regards,
>>  
>> El 08/04/11 19:58, Stephanie McCammon escribió:
>>  
>>  
>> Hello Everyone,
>>  
>> I just tried to post an outgoing liaison and received an error that said
>> I was not allowed to send an outgoing liaison to ITU-T SG15. I was
>> attempting to post it on behalf of Adrian Farrel who is listed as the
>> liaison manager for ITU-T SG 15. Can this be fixed?
>>  
>> Thank you,
>>  
>> Stephanie
>>  
>>  
>> On Apr 7, 2011, at 4:36 AM, Henrik Levkowetz wrote:
>>  
>> Hi,
>>  
>> On 2011-04-07 11:37 "Emilio A. Sánchez" said:
>> Hi,
>>  
>> Right now the field person of the LiaisonDetail model stores the
>> PersonOrOrgInfo of the user that creates the liaison. The real one
>> so if
>> the secretariat is sending a liaisons the person field has the
>> secretariat user person.
>>  
>> But this info is not used to grant any privilege over the liaisons.
>>  
>> Ah. So that field could more properly have been called 'creator'. Ok.
>>  
>> Best,
>>  
>> Henrik
>>  
>> Best,
>>  
>> El 07/04/11 11:16, Henrik Levkowetz escribió:
>> Hi Emilio,
>>  
>> I'm not sure you, Patrik and myself are talking about the same thing
>> here. See more below.
>>  
>> On 2011-04-07 10:54 "Emilio A. Sánchez" said:
>> Hi.
>>  
>> El 07/04/11 10:25, Henrik Levkowetz escribió:
>> Hi Emilio,
>>  
>> On 2011-04-06 16:03 "Emilio A. Sánchez" said:
>> ...
>>  
>> I don't understand what data want's to edit Patrik when he say 'who
>> holds the action item'. If he refers to the person who can 'take
>> care'
>> of a liaison, this person is selected automatically.
>>  
>> But if the SDO Liaison Manager is changing, then liaisons which
>> still
>> need to be taken care of will need to be updated, no?
>>  
>> I'm revising the code. The persons who are allowed to 'take care' of
>> a liaison are:
>>  
>> * The secretariat (always)
>> * Any person whose email is listed under 'cc', 'reply_to', 'poc',
>> 'response_contact', 'technical_contact' and the submitter. Of course
>> only if this person has an user in the datatracker.
>>  
>> One option is edit one of this field (but this is so ugly).
>>  
>> I think that the best option is allow to the 'take care' a if the
>> current user is allowed to edit the liaison (This check is done
>> on the
>> fly and checks if the user is currently an sdo manager of the
>> liaison).
>>  
>>  
>> There's an entry in the LiaisonDetails class which is 'person'.
>> This would be the person who holds the token to handle a liaison,
>> maybe? If so, I think that's the entry Patrik would like to update.
>>  
>> But if this entry isn't used anywhere, then we need to figure out
>> the distinction between the set of people who 'can take care of' a
>> liaison, and the person who has the token.
>>  
>>  
>> Best,
>>  
>> Henrik
>>  
>>  
>>  
>>  
>>  
>> Stephanie McCammon
>> IETF Registrar
>> 48377 Fremont Blvd, Ste. 117
>> Fremont, CA 94538
>> T: +1.510.492.4081
>> F: +1.510.492.4001
>>  
>> Association Management Solutions (AMS)
>> Forum Management, Meeting, and Event Planning
>> www.amsl.com <http://www.amsl.com> <http://www.amsl.com/>
>>  
>>  
>>  
>>  
>>  
>> Stephanie McCammon
>> IETF Registrar
>> 48377 Fremont Blvd, Ste. 117
>> Fremont, CA 94538
>> T: +1.510.492.4081
>> F: +1.510.492.4001
>>  
>> Association Management Solutions (AMS)
>> Forum Management, Meeting, and Event Planning
>> www.amsl.com <http://www.amsl.com/>
>>  
>>  
>>  
>>  
>>  
>> Stephanie McCammon
>> IETF Registrar
>> 48377 Fremont Blvd, Ste. 117
>> Fremont, CA 94538
>> T: +1.510.492.4081
>> F: +1.510.492.4001
>> 
>> Association Management Solutions (AMS)
>> Forum Management, Meeting, and Event Planning
>> www.amsl.com
>> 
>> 
>>  
> 
> -----------
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: amorris@amsl.com
> 
> Managed by Association Management Solutions (AMS)
> Forum Management, Meeting and Event Planning
> www.amsl.com <http://www.amsl.com/>
>