Towards a “Model” Peering Contract

GMCH 4th August 2002

Background

A Template Peering Contract has been available to LINX members for some time. It does not appear to be in common use, except as a basis for individual member’s own contracts.

A Peering Contract formalises the relationship between two peers. As a matter of practice, many peering relationships are established and operate informally, often on a simple email-shake. Increasingly, however, a formal arrangement is preferred at a “corporate” level. The reasons for this include, but are not limited to:

• the real operational and commercial value of peering relationships. If peering did not have value, no one would do it. If a peering relationship can come and (perhaps more importantly) go at a moment’s notice, it is hard to count on that value and it could pose an operational risk.
• the risk of an open-ended “hand-shake” arrangement implicitly committing the company to more than was intended. For example: what is the liability of one party to the other should one network knock down the other ? Or: if the term of the peering arrangement is unbounded, what happens if one party decides to terminate – suppose, for example, a one party is suddenly “cut off” by a larger party, where the smaller party depends on the connection for a significant part of its business.
• the wish to ensure that both parties literally sign up to minimum technical and operational standards, in the interests maintaining effective handling of mutual customers’ traffic.
• the advantages of documenting peering connections and operational procedures.
• This is a heady mix of Technical, Operational, Legal and Commercial considerations. Commercial considerations may be particularly complicated where the parties are markedly different in size (by whatever measure), or perceive themselves as being so.

With formal peering agreements still unusual, it is hard to find experienced advice. Coupled with the tendency, amongst both the technical and the legal fraternity, to wish to “improve” any given text, it is perhaps not surprising that there is little uniformity.

Rationale for a “Model Contract”

If every ISP has their own Peering Contract, then we have an order n-squared problem !

What was a straightforward matter of establishing a BGP session can become bogged down in initial skirmishes over whose Standard Peering Contract should apply, followed by paragraph-to-paragraph scrimmages over the contents as crack teams of enthusiastic lawyers and technical experts hone the text to a mutually acceptable state. The value of this process can be hard to appreciate.

If only there was a Standard Contract !

Unfortunately, a single Standard Contract is doomed, as different organisations take different views of the interlocking Technical, Operational, Legal and Commercial requirements.

The effect is that one may be presented with a Peering Contract nominally based on the Template available from LINX, but it is still necessary to pick through it, to establish the differences, then to establish whether those differences are acceptable, and finally to negotiate an acceptable contract.

This leads to the proposal to build a “Model Contract”, which would:

• separate the Technical, Operational, Legal and Commercial elements. In particular, separate the enumeration of peering connections, and their individual properties, from a framework agreement about peering in general.
• within each part offer a (hopefully small) number of options, variations and parameters – more on that, below.
• require any other changes to the text to be clearly marked.
• include a “version number” so that the Model can improve over time.

With the objective that organisations can pre-digest the Model Contract, so that formal peering arrangements can be established with the minimum of commercial and legal review.

Model Contract Protocol

Considering the above it becomes clear that what is required actually has two parts:

• construct a modular contract form.
• construct a protocol for the use of that modular contract.

The protocol would be along the lines of:

1. agree to use the LINX Model Contract, version ‘x’.
2. agree which options and parameters suit the situation.
3. append any specific variations to the Model terms.
4. complete the tables of peering points, configurations, contact details, etc.
5. sign and file.

This should be realisable as a form on one side of paper, to which the Model Contract could be stapled, unchanged and unread. This could be called the Model Form.

To make this protocol work, each user of the model contract will need to review the LINX Model Contract, version ‘x’, and decide on:

• which options and parameters it will generally apply under what circumstances.
• which options and parameters it will accept or reject in those circumstances.
• what extra terms or variations it has to make.

There is a balance to be found between the number of variations and parameters required for the Model Contract to be adoptable by many organisations, and the complexity introduced.

The other challenge is avoiding inessential extra terms and variations. The protocol for the adoption of the Model Contract must stress the value of standard terms over the perfection of each one !

For each organisation using the Model Contract, the complete set of documents is, therefore:

• the Model Contract itself.
• a statement describing the options, parameters etc. the organisation will apply.

  This could be several statements, one for each distinct peering circumstance. There might be one statement for open peering with all comers at a given exchange – hopefully a simple and public statement ! There might be another statement for private interconnections with strategically significant peering partners.

  Where an organisation has to implement extra terms or variations, this should be made clear, along with the reasons for and the significance of each one. [There is commonly a reluctance to explain a given piece of legal prose, so there may be resistance to this. Perhaps that will serve to reduce the number of such exceptions ?]

• the Model Form.

Constructing the Model Contract, Protocol and Form

Some time ago, Thus took the LINX Peering Template, and promptly did what Lawyers and Engineers do, they improved it.

These improvements did not materially change the form of the agreement, they did improve wording, definition and other clarifications.

The result we happily put into the public domain.

The next step is as wide a review of the text as possible. The acid test here is for as many organisations as possible to challenge themselves to adopt this model contract, and assess:

• what changes would they make to make the contract work for them ? This can be split into:
  • wording, definition and technical improvements.
  • material commercial concerns: e.g. term, continuation, termination, conditions etc.
  • material legal/corporate concerns: e.g. content and AUP, liability etc.
• what range of peering circumstances do they identify, and what variations on the contract would apply to those circumstances. ?
• how they would deal with the business of completing formal agreements with peers, new and existing.
• any gaps ?
• any applicable experience and pointers to how best to implement formal peering arrangements ?

This process would further improve the document, and provide the raw material to guide the next step, which is adding the parameters and the variants to create the Model Contract.

The Model Protocol will reflect the application of the Model Contract. The size and shape of that will depend to a large extent on the degree of flexibility built in to the Model Contract.

The Model Form is clearly dependent on the Model Contract and Protocol.