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

Sweeting, John john.sweeting at twcable.com
Sun Oct 18 13:28:52 CEST 2015


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.



More information about the CRISP mailing list