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

Mon Oct 19 10:23:56 CEST 2015

+ 1 Andrei. 

As John has mentioned it may be worth having him to talk to Michael first and see if Jason still has further questions.

Izumi

On 2015/10/19 16:15, Andrei Robachevsky wrote:
> 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
>>