[NRO-IANAXFER] Contract details

Filiz Yilmaz koalafil at gmail.com
Tue Jan 6 13:33:03 CET 2015


Here is my thought process and reasons why I support a renewable contract
in the context of the current proposal:

The proposed contract is defined to be signed between the IANA operator and
the RIRs. IANA function is mainly providing certain and very specific
services to the RIRs. These services are critical for RIRs so they can
serve their own communities and members. RIRs have legal contracts with
their members too. I believe a contract as defined in the proposal is more
appropriate than an MoU in this context, where services are defined and
expected to be received.

In the the context of policy coordination matters, such as in ASO/NRO/ICANN
Board setting, a MoU serves well, I agree, but that is a separate case and
I do not think an MoU will suffice in a specific-service-providing setting
as in this case.

A contract is legally more binding then an MoU and a renewable contract
ensures there is a check mechanism for the parties involved in any
contract, both for IANA operator and the RIRs in this context. Otherwise a
timeless contract will be legally too binding for all involved. It is not
only about the service levels or for the check of quality measures either.
We are talking about Internet operations here, which happen relating to an
ever changing technology. It is also an eco system where several players
and their actions have consequences on others'. Requirements may be very
different in 5 years (and this is only for purposes of an example) from
today. There should be some buffer time and opportunity for the parties to
review if amendments should be made to the contract, so operations on both
end can be continued properly and according to the signed contract too.

Overall, if the IANA operator and the RIRs are to engage in any contract, I
support an auto-renewable contract where there is a notice period before
the end date noted, say XX days before the Contract End date. During this
period if any of the parties has any issues then they can give a notice of
these and invite the other party to work on amendments. If there are no
issues raised by any party, they can automatically step into a new contract
period. In fact the role of the proposed Review Committee will be most
prominent prior to this period I would expect, to see if there will be any
notice necessary to be given to the IANA operator or if everything is all
right, so should the RIRs smoothly move into a new auto-renewable contract

The important thing here is making sure that there will be some (enough)
time for this notice/review period before the Contract end date. Once the
proposal receives consensus on this, the detail of how long of a notice
period would be best can be figured out by the Legal teams of RIRs in my

Kind regards

Filiz Yilmaz

On Tue, Jan 6, 2015 at 11:56 AM, Seun Ojedeji <seun.ojedeji at gmail.com>

> Hello Alan,
> Coming back to you on this now that i have some time. Kindly find inset
> On Mon, Jan 5, 2015 at 2:23 PM, Alan Barrett <apb at cequrux.com> wrote:
>> On Fri, 02 Jan 2015, Seun Ojedeji wrote:
>>> In my personal opinion, it doesn't matter whether it's a fixed term with
>>>> periodic renewal, or an indefinite term, provided there's provision for
>>>> immediate termination upon breach of contract or failure to meet SLAs.
>>> I think there may be a difference in the 2 scenario as periodic renewal
>>> will mean initiating a process at the end of each fixed term(which could
>>> require some level of resources). As you have rightly mentioned above,
>>> providing termination conditions on the basis of SLA is what is most
>>> important, so an indefinite term similar to the MOU that established ASO
>>> would not reduce the strength of the agreement but could save us some
>>> resources.
>> We discussed this in the CRISP Team teleconference today.  We think that
>> a fixed term (with provision for periodic renewal) makes more sense for a
>> few reasons:
> Well it depends on how we view "making sense" in this context because the
> NRO/ICANN MOU is not term based neither is RFC2860 and it does not in
> anyway diminish the possibility of achieving what you have listed below.
>> - renewal should not consume much additional resources over and above
>>   the periodic review which will be done in any case;
> I wonder what other periodic review is refereed to here other than
> reviewing the SLA; could you kindly clarify the review you refer and what
> that will entail?
>> - it makes it easier to revise the SLA from time to time;
> Well i don't agree that you need to have a term based contract to revise
> SLA at least(unless i missed something) the IETF SLA is revised annually to
> supplement the MOU
> - it makes it possible to terminate the contract for reasons other
>>   than breach.
>> Maybe you should state the other reasons (different from the ones stated
> in the agreement) that will justify that having a termed based contract is
> ideal, otherwise i think the content of the agreement is what in important.
> In anycase, its okay if that is what achieves consensus. However, i think
> i should note that this community is quite matured and may not need this
> level of un-necessary bureaucracy; we should continue to be an example for
> other communities.
> Regards
>> --apb (Alan Barrett)
>> _______________________________________________
>> ianaxfer mailing list
>> ianaxfer at nro.net
>> https://www.nro.net/mailman/listinfo/ianaxfer
> --
> ------------------------------------------------------------------------
> *Seun Ojedeji,Federal University Oye-Ekitiweb:
> http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt
> email: <http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
> <seun.ojedeji at fuoye.edu.ng>*
> The key to understanding is humility - my view !
> _______________________________________________
> ianaxfer mailing list
> ianaxfer at nro.net
> https://www.nro.net/mailman/listinfo/ianaxfer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.nro.net/pipermail/ianaxfer/attachments/20150106/f4e807dc/attachment-0001.html>

More information about the ianaxfer mailing list