1. Namespace Allocation Discussion link: http://goo.gl/J6RbbD (pasted emails at the bottom of that page)
   1. Questions remaining about namespace allocation
      1. What is the length of the period for appeals against namespace decisions? 1 Month?
      2. Should there be a quorum on the vote on a disputed namespace allocation? I'd say no.
2. Handbook link: http://goo.gl/0Tht3J

1. Namespace allocation To react to a top-level namespace proposal, One month or six weeks seems reasonable for period for appeals against namespace decisions. Start with a month and see if members are dissatisfied for some reason. We are talking about top level namespaces only. There should not be too many of those.
2. Top level namespaces
   1. Top level namespaces, such as IE for IEDA, may have two character namespaces as the root, but that is not necessary. In Perth, ARC namespace, Australian Resource Center. The idea was for the geochemical lab to use ARC. There will not be many “sub-users”. e.g. Core repositories should have relatively few namespaces to begin with - 3 or 4 for example for Bremen.
   2. KL: We took the step of beginning namespaces with IE in order to reduce the number of top level namespaces taken.
   3. The last section of the handbook should give some guidance of how allocating agents assign IGSNs
   4. CC: all namespaces should be associated with someone who is a member of IGSN (and that is the way it is). In other words, groups or Allocating Agens=ts have a supernamespace, like IE, IE takes care of all clients with subnamespaces (up to IEDA). But there could be cases where people have a supernamespace and only use it once.
   5. Namespaces for allocating agents will require an approval process.
   6. Note: It is a bit confusing with the 10273 in the handbook. Define the toplevel namespaces - IGSN assigned to 10273 is sort of confusing - especially to include into this document, this is for a completely different use.
   7. There is a cultural difference of how people understand the terms, (informed by cultural practices), this text has been around for a long time, tries to explain the pattern of hierarchical thing and how to get from an IGSN name to a resolvable URL. KL: some things are more generic than they need to be in the document. There could be confusion if 10273 never changes.
   8. When talking about 10273, put that in where to resolve. In the next section, it could be about the IGSN itself, and remove the handle section information. That would be more clear to focus just on IGSN. CC: could use a specific example, like the IE case.
   9. KL: can we define a “top level namespace”
   10. We May need to set up a namespace subcommittee (mentioned in the text)
   11. One of the flowcharts is out of date for the Namespace Approval Procedure, if not rejected right away, there is an appeals period. (vs. an approval period). If the IGSN e.V. membership does not react, is an approval. If we seek an approval, we need a vote for all cases, but if it is an appeals period then it goes through unless there is a rejection. The persons who would appeal would be the persons that objected.
   12. A supernamespace can only be given to a new allocating agent. Requesting that they become allocation agents. Or, an existing allocation agent serves a new community and wants another supernamespace. Example: IEDA is building sample registration system for the critical zone observatories. The will ask for CZ. It's agreed, that the top level namespaces are under the responsibility of the AA to adhere to the rules of the handbook. AA: that may be something that does not happen in a month. Check: are they a member? Does it conflict with anything else? That can be done in a month. But we need to make sure that the allocation agent is functioning in the way that we envision they are.
3. Rules and Responsibilities of members
   1. CC: in the invoicing letter, we wanted to tell members what the rules and responsibilities are. Must adhere to the namespace policies. What happens if people don't use their namespace, then what? Membership rules refer to the statutes. But something else about the rules of the procedures should be included. If people don't come to the meetings (are not active), then after a warning, they may not be members anymore. If There is a member that pays their dues and attends the meetings, and they propose a namespace, at that point there is not much else besides saying that the namespace is unique and conforms to the understood rules. But after that, what happens if the group doesn't act on the namespace for 1-2-3 years, OR if they start breaking the syntax. Then what? Also, how do we even monitor that? The registry would have to control the syntax of IGSNs being registered at the registry. It will increase the burden of the organization running the registry and would require some resources.
   2. AA: every year at the General Assembly, then we will get some summary of what has happens. There is a summary once per year. Total, new IGSNs assigned per year. (1) Looking at the activity is something that DataCite does as well, to give a people an overview of what is happening. (2) If a namespace is not being used, for one year, then it should be revoked. There could also be a warning period.
4. IGSN Syntax beyond the suggested syntax
   1. KL: Does there need to be an approval process for changing the syntax of IGSN, and to what level should this be controlled? It's easy to control 9 digits. If someone wants 11 digits, then something would need to be implemented at the registry that allows 11 digits. Maybe you need to provide the resources to do the checks. JK: at the moment the system checks if you are allowed to register in that namespace and the webspace, it doesn't check anything else. We could check the format, but do we really want to do that? the hierarchical delegation pattern is good because then you can leave those business processes to the agents and trust that they do things right. (KL: but we would also like to make sure as opposed to just trust). If there are all sorts of syntax modifications, then it will ultimately increase the risk of failure to the system. If someone wants to make changes to the syntax, they can do that, but they should present the changes to the IGSN e.V. to be approved then we reduce the risk of crazy extensions. JK: there are certain characters allowed and that there are 9 characters allowed. There seems to be agreement that if it is 9 characters and uses approved characters, then that is fine. But otherwise you must present a case. 9 characters okay, but anything else needs approval.
   2. Original use case - 9. There are other use cases that cannot use 9, so if you say you can do anything, then people can do anything. The standard length is 9, and if you as an allocation agent wants to use more, then make a case. AA: why would the system break? We are uniquely identifying samples so they can be linked in databases and etc. But investigators will not want to use very long, cumbersome IGSNs in their tables and etc. The first paper with IGSNs in it, already had an example where there was an IGSN with a missing characters, so that IGSN did not resolve. Jens: Elsevier should check to see if the URL resolves.
   3. The capacity to have longer names needs some logic behind it and it needs to be discussed by the group.
5. Does there need to be a Quorum - Decided there does not need to be a quorum, but result should be announced. (We basically have this now, but it still requires a manual dimension, it is not fully automated. But it should not happen too often.)
   1. The only cases to object to namespaces is (1) someone is thinking of that namespace already (2) the namespace is inappropriate in some language.
6. CC: wants to look at the handbook and can make concrete suggestions about wording.

Closed the meeting by saying everyone will look at the Handbook before the Sept. 18th meeting. LH numbered the sections in the Handbook.