[CRISP-TEAM] FW: Community accountability WRT IANA performance

[Andrei Robachevsky]

Hi,

It'd be interesting to know if Jason sees any deficiencies in the set-up
of the Review Committee, since this is the body that was designed to
address most of the potential threats he mentioned.

Andrei

Sweeting, John wrote on 18/10/15 13:28:
> Thanks, hoping to get a response from Jason here in Dublin. It may be as
> simple as having him speak with Michael A.
> 
> 
> 
> On 10/14/15, 6:52 PM, "Izumi Okutani" <izumi at nic.ad.jp> wrote:
> 
>> Hi John,
>>
>>
>> Thanks for sharing the questions from Jason. Just to follow up if Jason
>> is still interested in asking those questions. I have no concerns about
>> posting those questions on the ianaxfer and have them answered by the RIR
>> legal team who developed the SLA.
>>
>> I do have a question about his questions :)
>>
>> He listed some exapmples about the capture by some group and I wasn't
>> sure how that could happen, given it it the five RIRs as the direct
>> customers of the IANA Numbering Serives, who would be responsible in the
>> performance review. The community provides the advice to the RIRs and
>> they don't directly do the oversight, so I wonder how a certain group can
>> capture the performance review as he has listed as a possible scenario.
>> Perhaps I am not understanding his questions properly? In anycase, I see
>> no issue to have those questions asked on the global list.
>>
>>
>>
>>
>> Izumi
>>
>> On 2015/10/08 23:00, Sweeting, John wrote:
>>> Hi Team,
>>>
>>> I have received this email from Jason Schiller and wanted to share them
>>> with the team. I think that the best way forward is that I ask Jason to
>>> share these questions on the global list so that all interested parties
>>> will be able to share. I think that the team that drafted and is working
>>> the SLA would be in best position to answer and Michael agrees. Let me
>>> know if there are any concerns, otherwise I will ask Jason to post later
>>> today.
>>>
>>> Thanks,
>>> John
>>>
>>> On 10/7/15, 10:12 AM, "Jason Schiller"
>>> <jschiller at google.com<mailto:jschiller at google.com>> wrote:
>>>
>>> John,
>>>
>>> In our ASO AC meeting, I began thinking about our CRISP stuff as well.
>>>
>>> I think the key thing NTIA gives us is a safety valve.
>>>
>>> If there is a failure to perform the IANA function we could easily get
>>> a few key community members to prod the NTIA to get this resolved, or
>>> move the contract.  What mechanism exists to prod this along under the
>>> new plans?
>>>
>>> Our current plan is to move the SLAs that are in the NTIA contract to a
>>> contract with the RIRs and the IANA function holder.
>>>
>>> The report of (non-)meeting the SLAs will be presented, and if
>>> non-compliance was judged the RIRs would work with the IANA function
>>> holder to address those issues or declare the inability to meet the SLA
>>> grounds to break the contract.
>>>
>>> What mechanism exists to ensure there is proper community oversight
>>> that:
>>>
>>> 1. the SLAs are the right SLAs
>>>     (or changes to the SLAs are the right changes)
>>>
>>> 2. that the measurement of SLA compliance is the right measure
>>>     and that  (non-)compliance is being correctly judged
>>>
>>> 3. that the RIRs are appropriately following up on non-compliance,
>>> appropriately choose to call the contract in breach due to SLA
>>> non-compliance
>>>
>>>
>>>
>>> Say for example the IANA function is not being performed well, but
>>> meeting the SLAs.  How can the community get the SLAs changed to ensure
>>> the poor performance is covered under a new SLA?
>>>
>>>
>>> Say the IANA function is not meeting an SLA, but the SLA is measured
>>> and judged as compliant.  How can the community ensure the SLA is
>>> properly measured and non-compliance properly judged?
>>>
>>>
>>> Say IANA function is not meeting an SLA, and judged out of compliance,
>>> but the RIRs are not doing enough to resolve the issue quickly?  How can
>>> the community ensure the non-compliance is properly addressed?
>>>
>>>
>>> Say IANA function is not meeting an SLA, and judged out of compliance,
>>> but the RIRs are moving too quickly to invalidate the contract?  How can
>>> the community ensure the RIR take the proper steps to resolve the
>>> problem without declaring the contract broken?
>>>
>>>
>>> Say IANA function is meeting the SLAs, but non-compliance is
>>> erroneously judged, because some group wants to invalidate the contract
>>> and award it to another party.  How can the community ensure the
>>> non-compliance is properly judged?
>>>
>>>
>>> Say the SLAs are arbitrarily raised such that the IANA function
>>> operator cannot meet them and non-compliance is judged, because some
>>> group wants to invalidate the contract and award it to another party.
>>> How can the community ensure the SLA are the right SLAs?
>>>
>>>
>>> Say the SLAs are arbitrarily lowered such that in the next round of
>>> bidding, another vendor can under bid and get awarded the function
>>> because some group wants to award it to another party? How can the
>>> community ensure the SLA are the right SLAs?
>>>
>>>
>>> ___Jason
>>> --
>>> _______________________________________________________
>>> Jason
>>> Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266
>>> -0006
>>>
>>>
>>> ________________________________
>>>
>>> This E-mail and any of its attachments may contain Time Warner Cable
>>> proprietary information, which is privileged, confidential, or subject
>>> to copyright belonging to Time Warner Cable. This E-mail is intended
>>> solely for the use of the individual or entity to which it is addressed.
>>> If you are not the intended recipient of this E-mail, you are hereby
>>> notified that any dissemination, distribution, copying, or action taken
>>> in relation to the contents of and attachments to this E-mail is
>>> strictly prohibited and may be unlawful. If you have received this
>>> E-mail in error, please notify the sender immediately and permanently
>>> delete the original and any copy of this E-mail and any printout.
>>>
>>>
>>>
>>> _______________________________________________
>>> CRISP mailing list
>>> CRISP at nro.net
>>> https://www.nro.net/mailman/listinfo/crisp
>>>
>>
> 
> 
> ________________________________
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> 
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp
>