Subject: [yaco-liaison-tool] Test driving the new Liaison tool

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 03 Sep 2010 11:20:34 +0200

Hello, and welcome.

When I sent out invitations to some of you to subscribe to the list last
week, I asked Mailman to notify me of new subscriptions, and haven't seen
a single one.  I now checked the list and found that people have actually
been joining, and we're now in good shape for beta testing of the rewritten
tool.

The developer (Emilio) is also on this list, so comments and questions will be
directly available to him.

The user manual written as part of the rewrite is enclosed with this mail;
comments on that are welcome.

The beta server URL is

   http://beta.lsmt.yaco.es/

and here are the username/passwords which have been set up for the beta
server:

     * admin/admin
           o This user is an IETF Liaison Manager

     * external/external
           o This user is an SDO Manager of 3GPP and WIPO
           o This user is an SDO Authorized of IEEE 802 and Open Grid Forum

     * internal/internal
           o This user is the Area Director of the Application Area
           o This user is a Working Group Secretary of 
             'Performance Metrics for Other Layers' group.

     * internal2/internal2
           o This user is the IETF/IESG Chair
           o This user is the IAB Executive Chair

    There are different users so different cases can be tested.

Best regards,

	Henrik

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Sep 2010 14:40:47 +0200

Hi Henrik and others,

Thanks a lot for this. This looks good, but, I of course have a few questions on features I would like to have, which I understand might be in future releases:

1. The ability to see the deadline in the list of liaisons, and sort on that date

2. The ability to for a liaison (incoming or outgoing) "link" to some other historical liaison, so that one can create a thread

3. See those "links" so that one can see what outgoing liaison an incoming liaison is a response to

   Patrik

On 3 sep 2010, at 11.20, Henrik Levkowetz wrote:

> <lsmt_user_manual.pdf>_______________________________________________
> yaco-liaison-tool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yaco-liaison-tool

---

From: "Emilio A. Sanchez Lopez" <[email-masked]>
Date: Mon, 06 Sep 2010 20:12:16 +0200

Hi Patrik,

    As I talked with Henrik if we can define a set of new requirements 
we can try to extend de liaison project to develop these new requirements.

    I make little comments to your features inline,

> 1. The ability to see the deadline in the list of liaisons, and sort on that date

    This is really easy but I would extend it as follows:

    The ability to see the deadline in the list of liaisons and the 
ability to sort by any displayed field.

    There are liaisons without deadline (the ones which have 'for 
information' or 'in response' purposes) so it can be a bad idea to sort 
the liaisons just on the deadline date.

> 2. The ability to for a liaison (incoming or outgoing) "link" to some other historical liaison, so that one can create a thread

    I suppose that this only have sense when the purpose of the liaison 
statement is 'In response'. In that case when selecting this type of 
purpose a list of existing liaisons could be show to select one of them.

    The requirement should be defined better. For example:

    * Any liaison statement (of any purpose) can have a pointer to any 
other liaison statement

    Or:

    * Liaison statements with purpose "In response" should have a 
pointer to the liaison statement it responses.

    With these restrictions:

    * Incoming liaisons can only point to outgoing liaisons.
    * Outgoing liaisons can only point to incoming liaisons.

    Or with tighter restrictions:

    * Incoming liaisons to an IETF entity can only point to outgoing 
liaisons from this IETF entity.
    * Outgoing liaisons to an SDO can only point to incoming liaisons 
from this SDO.

    So when presenting the liaison list to the user we can reduce its 
components to the necessary ones and not show the complete liaison list.

> 3. See those "links" so that one can see what outgoing liaison an incoming liaison is a response to

    No problem on this.

    Best regards,

-- 
Emilio A. Sánchez
[email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Sep 2010 14:24:58 +0300

Hi,

I have given the tool a try. The interface was clear and the tool was
easy to use. As far as I can tell, this tool covers everything I have
done as a liaison manager (related to liaison statements) in the last
few years.

One question, though. The deadline field, will it trigger some type of
alarm (e.g., sending an email) when the deadline is reached? If so, will
it be possible to mark a liaison "for action" as "already taken care of"
so that no alarm is triggered on the deadline.

I agree with Patrik that being able to group together a liaison
statement and its response would be useful.

Thanks,

Gonzalo

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 14 Sep 2010 01:11:20 +0300

Sorry for being late with reply...

On 6 sep 2010, at 21.12, Emilio A. Sanchez Lopez wrote:

>   The ability to see the deadline in the list of liaisons and the ability to sort by any displayed field.

Yes.

>   There are liaisons without deadline (the ones which have 'for information' or 'in response' purposes) so it can be a bad idea to sort the liaisons just on the deadline date.

Correct.

>   I suppose that this only have sense when the purpose of the liaison statement is 'In response'. In that case when selecting this type of purpose a list of existing liaisons could be show to select one of them.
> 
>   * Any liaison statement (of any purpose) can have a pointer to any other liaison statement

I think we must start with this. Otherwise we might have to remove rules over time.

>   Or:
> 
>   * Liaison statements with purpose "In response" should have a pointer to the liaison statement it responses.

Maybe too restrictive.

>   * Outgoing liaisons can only point to incoming liaisons.

Maybe. Possibly.

>   * Incoming liaisons to an IETF entity can only point to outgoing liaisons from this IETF entity.
>   * Outgoing liaisons to an SDO can only point to incoming liaisons from this SDO.
> 
>   So when presenting the liaison list to the user we can reduce its components to the necessary ones and not show the complete liaison list.

I have problems making such strict rules. The reason for that is that I do not have enough data for what must be able to link to what.

I would be happy to, at first stage, allow something to link to something else.

>> 3. See those "links" so that one can see what outgoing liaison an incoming liaison is a response to

Thanks!

   paf