Page History

"...described in section 3.6" appears to be an error. Section 3.5 describes Dispute Resolution

The eSC ToR has an additional item under eSC responsibilities that is missing from the eduGAIN Constitution: "Approving, supporting and chairing eduGAIN Working Groups". Is that omission intentional?

It is unclear from this text who the eduGAIN Service Team reports to, i.e., who oversees the work and performance of this function?

Both mentions of "... as per section 2.2." seem questionable. Section 2.2 describes the eduGAIN Steering Committee.

The 2 URLs at these lines begin with "http://". Both redirect to their secure equivalent. It'd be best to point directly to their "https://" equivalents. 

The amended constitution still reads like eduGAIN is only a point of metadata exchange among federations. Is that the intent? Is there any work underway to address other matters essential to trusted and scalable interoperation among entities registered in eduGAIN: broad adoption of interoperability profiles; mappable operating (security, privacy, support, etc) policies? Does eduGAIN intend to take an active role in helping newer/smaller federations grow/mature in their capabilities so that there is parity across federations?

'Technical Profiles': is there a difference compared to the 'Technology Profiles'?

'voting list': Does this refer to eduGAIN Membership Votes? If yes, there should be 1-2 explanatory sentences in section  2.3, e.g. "A Member Federation which is absent from two consecutive votes will be removed from the active list for the purpose of subsequent votes. Participating in a vote returns the federation to the active list." (copy+paste)

Did we ever need the distinction between delegate and deputy? (I can't think of desirable processes that would act solely on the difference of someone being deputy vs. delegate.) Can we simplify this and just make it (up to) two delegates?

We're still all voting on new memberships? I find that a bit tedious because I cannot imagine there being a different outcome other than a simple majority for "yes" for some fed joining. If the outcome is always the same the process itself seems superfluous.
Maybe rethink this approach and simply accept candidate federations if – within a given period, say a week or two – no strong objections have been raised and properly argued for. If strong objects indeed were raised, discuss those until the objector can live with the decision. If consent cannot be reached (within another given period, say, a week or two) we could still let the eSC decide or  call for a vote then (but only then, which would/should likely never happen).
N.B.: Non-primary functions of voting such as "liveness detection" should be implemented using different methods (better CRM processes, essentially). I.e., we shouldn't ask people to vote only to find out whether they still care or still work for the federation.

For broader discussion - invite Peter to push this to the list?

Due to the lack of input from members, we do feel that we have to push for an active vote at the moment to ensure that there is consensus and not just apathy.

Need to roll out reporting tool asap.

should we add a MUST for having completed the membership/joining process to make this more explicit/clear?