On Sat, Sep 27, 2014 at 09:02:12AM +0200, William Drake ([log in to unmask]) wrote:

> For the techies here (especially Tapani, who seems the most
> familiar): Off the top of my head on my first coffee of the morning,
> a couple question arise: If we have an integrated db for all of
> NCSG, how if at all would it affect the key functionalities for
> NCUC, e.g. having data base additions feed directly into our website
> listing of members (and subscribing new members to mail lists), and
> the conduct of our elections?

It would not need to have any visible impact on those, although
some changes might be useful.

> Could we set this up in a way that Maryam just handles it for
> everyone?

How various tasks would be delegated is more of a political than
technical issue, but I was thinking along the lines of
"click-to-approve" interface for NCSG, NCUC and NPOC,
who could decide within themselves if it's the Chair
or treasurer or whoever who uses it.
Everything else should be more or less automatic.

> How would we handle a hosting transfer?

That would depend on where it'd be transferred.
Picking on Sam's message:

> On Sep 27, 2014, at 5:43 AM, Sam Lanfranco <[log in to unmask]> wrote:

> > 2.      Where should the membership database be hosted? Should it be on an ICANN server or elsewhere?

I can see three obvious alternatives:

* NCUC's member database now lives in NCUC's own (virtual) server, and
  it could just as easily handle entire NCSG. (Websites of NPOC and
  NCSG could still live elsewhere, just accessing the database in
  NCUC's server.) In this case there'd be no need to transfer hosting,
  only updating the database (adding new fields and NPOC and other non-NCUC
  members of NCSG).

* A dedicated virtual server for the purpose could be purchased.
  Moving the database (so that NCUC's server would also access it
  remotely) would be trivial (assuming a similar i.e. Linux server).

* ICANN might want to offer a server (or just database in one) for NCSG.
  In this case we'd need to work with ICANN technical staff; I spoke
  about it with some of them last year, and they were a bit cautious
  about giving NCUC direct access to a database in their machines,
  so transfer would depend on them.

> > 3.      Who should have what levels of access to the membership database?

That is a good question.

First, whoever maintains the machine it lives in will rather
inevitably have full access from a technical point of view
(there are some means of splitting that but they're rather
cumbersome and hard to do well, probably not practical).
The choice here is between ICANN staff if we use their servers
and "our own people", i.e., whoever NCSG gets to do the job.

Second, from administrative point of view access can be restricted
as narrowly as we want. E.g., NPOC Chair (or whoever they nominate
as membership manager or whatever) could be limited to seeing only
NPOC members' and applicants' data and changing their NPOC membership
status, similarly for NCUC, whereas NCSG Chair &c could see all
members, and someone (perhaps just one person for NCSG) should
have "secretarial" access, i.e., ability to edit contact details &c.

> > 4. Should members have password protected access to their own
> > profiles in order to update information (especially important for
> > organizations)?

Yes.

> > 5.      Should profile access by via the ICANN dashboard?

I have no strong opinion on that but I'll have to note it is both
technical and political question and increase our dependency on ICANN.

-- 
Tapani Tarvainen