IASA operating instructions

IASA operating instructions
I suggest this as a place to gather the instructions for how IASA operates that aren't appropriate BCP material, but still need to be written down somewhere. - HTA -

IAOC operating instructions




IAOC openness guidelines


See IAOC Openness Guidelines

IAOC decision-making procedures


IAOC expense reimbursement policy


The IAOC members are expected to bear their own cost of teleconference calls and attending physical meetings of the IAOC; these will most commonly be colocated with IETF meetings.

If the economic circumstances of an IAOC member is greatly changed after the member joins the IAOC, so that it would be an undue hardship to attend the physical meetings, while still being otherwise able to function as an IAOC member, the IAOC chair may authorize exceptional reimbursement of reasonable cost of attending an IAOC meeting.

IAOC conflict-of-interest policy


Starting proposal: Adopt the ISOC BoT policy for this.

IAD operating instructions


Budget process timeline


A proposed outline is given in the BCP section....

The procedure for the 2005 budget will be:

The procedure for the 2006 budget will be:

Reporting procedures


Meeting site planning/selection


Contracting for services


The main function of IASA is to make sure services that the IETF needs to support its function get done. So the contracting for services is a critical function.
The BCP does not put stringent limits on these procedures, but does mention important terms like transparency, accountability and responsiveness to the community.

A normal procedure for contracting services is a "request for proposals" - in which the IASA creates a description of a function or a set of functions, and asks for interested parties to identify themselves to the IASA. This description will be public, and the process of developing it will allow for community review and comments.
The IASA will then decide which of the interested parties seem qualified to deliver the service, and enter into negotiations with some of the qualified parties. This may lead to changes in the function description.
Once negotiations are finished, IASA will sign a contract with the party or parties that IASA thinks can perform this function in the way that is best for the IETF (cost, quality and performance all considered).
At least the parts of the contract that describe the final agreement about function will be made public; the whole contract may be made public if the contractor agrees to do so - if not, the reason for not publishing all of it is made public.

In some cases (small contracts, contracts with special requirements), IASA may choose to negotiate with only one potential contractor for a function. This choice should be justified to the community, and the step of creating a function description with public input is especially important in this case.

Monitoring services


(this text picked up from BCP -05, and expanded)
The IASA should ensure that wherever feasible there are reported objective performance metrics for all IETF process supporting activities.
While objective metrics are no guarantee that things are OK, metrics (processing time, response time, queue lengths) can often indicate that something is definitely wrong.





Link to this Page