[CRISP-TEAM] Response to the ICG Re: Actions

Wed Aug 26 16:43:07 CEST 2015

Thanks Nurani for the formatting and the clean version.

On the introduction where you commented, I think we can delete the part about the new charter "with a remit to serve [***SEE NEW CHARTER***]" and just refer to the link to our charter, as the revised charter probably isn't available yet. I can reflect this if no further comments/feedback.

REVISED:
This proposal was submitted to the ICG in
January 2015. The CRISP Team will remain in place until the completion of the transition process. For more details, see: 
https://www.nro.net/nro-and-internet-governance/iana-
oversight/consolidated-rir-iana-stewardship-proposal-team-crisp-team

> I also made the main part of our question in bold so it stands out a little more if people want to copy and paste it. (But I don’t feel strongly about formatting, so if others want to step in - feel free! :)

Yes, that's helpful thanks.

> We might still need to rewrite the answer to question 6 about the DNS stability, based on today’s discussion. 

I had already incorporated Andrei's comment about  “IN-ADDR.ARPA” and “IP6.ARPA” DNS zones", in the version I circulated before the call (which is ofcourse reflected in ver.5 sent by Nurani).
Further edits are welcome.

---
Yes we believe the proposal maintains the security, stability, and resiliency of the DNS. It is our assessment that no other elements in the ICG proposal, compromise the security, stability, and resiliency of the DNS as pertained to the administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS zones". . The current security, stability, and resiliency of the DNS today will remain, as there are no fundamental changes proposed to the operation of the DNS .

While not directly relevant to the DNS,  in the wider context of the number resources component of  the IANA functions, the Number Community believes the current operation of the IANA Numbering Services is secure, stable, and resilient. To maintain this current state, we have ensured that our proposal does not suggest any changes that would affect the security, stability, or resiliency of the IANA Numbering Services. There are no changes proposed for the operation of the IANA Numbering Services. We are further ensuring the service level to be maintained through the SLA. 
---

> Looking at the clean version, I can see that it still needs some tidying.
> 
> Also, we said that we were going to publish our response on the NRO website, so let’s make sure to do so! 

NRO CRISP website I assume ? Yes, we can ask German/NRO Secretariat Team to post this for us, once we fix and circulate to the global list.

Thanks,
Izumi

On 2015/08/26 23:10, Nurani Nimpuno wrote:
> Hi all,
> 
> I have just done a very quick tidy-up of formatting and accepted all formatting changes so it’s a little easier to read the latest changes.
> 
> I also made the main part of our question in bold so it stands out a little more if people want to copy and paste it. (But I don’t feel strongly about formatting, so if others want to step in - feel free! :)
> 
> We might still need to rewrite the answer to question 6 about the DNS stability, based on today’s discussion. 
> 
> Looking at the clean version, I can see that it still needs some tidying.
> 
> Also, we said that we were going to publish our response on the NRO website, so let’s make sure to do so! 
> 
> Cheers,
> Nurani
> 
> 
> 
> 
> 
>> On 26 aug 2015, at 13:06, Izumi Okutani <izumi at nic.ad.jp> wrote:
>>
>> Hi Andrei, all,
>>
>>
>>>> 1. Q2. 
>>>
>>> I suggest a slight modification to the text "each of the three IANA
>>> function is basically independent with minimum overlap. In areas where
>>> potential overlaps were anticipated, such as on Intellectual Property
>>> Rights (IPR)  and establishment of the Post Transition IANA(PTI),'
>>>
>>> specifically to use "potential incompatibility" instead of "potential
>>> overlap" since we used the term overlap in a different context (i.e.
>>> overlapping registries).
>>>
>>
>> I agree. Reflected: "potential overlap" --> "potential incompatibility"
>>
>> I kept the first "overlap" as this is the word used in the question and "minimum incompatilility" could imply there are some incompatililit(ies).
>>
>> ----
>> While the three communities did not produce identical proposals on how to handle the IANA functions, each of the three IANA function is basically independent with minimum overlap. In areas where potential incompatibility were anticipated, such as on Intellectual Property Rights (IPR)  and establishment of the Post Transition IANA(PTI),we believe all three communities have worked to ensure that the structures and mechanisms proposed in their submissions do not conflict. 
>> ----
>>
>>
>>>>    Observation about compability on PTI.
>>>>    We say we observe no compability with establishment of PTI, which is correct. 
>>>>    Do we want to give condition such as “given all existing resources to perform the IANA functions under ICANN will be made available to PTI “.?
>>>>
>>>
>>> IMO, as long as the service levels are met, the IANA resources are
>>> outside our concern. If we still  want to stress this point, I'd suggest
>>> "The Number Community proposal for the RIRs to sign an SLA with ICANN is
>>> still possible to implement, and therefore still workable, provided that
>>> ICANN ensures that conditions in the SLA are met by the PTI".
>>
>>
>> That's true. I suppose I was wondering if we need to be clear about the condition on observing no incompatibility.
>> I don't feel strongly about it so, given the SLA is arealdy mentioned, so have made no addition at this stage.
>>
>>>
>>>> 2. Q.6 
>>>>    We are describig the number community as the customer of the IANA Numbering Services.
>>>>    I can see this perspective in the wider sense, as the same time I assume RIRs would consider themselves as the direct customers of the IANA Numbering Services.
>>>>    Do we keep this description as it is, or mention anything about RIRs being the direct customers?
>>>
>>> I have a bit of a problem with the answer to Q6 as it is written. I
>>> think we should limit the scope of the review to "as pertained to the
>>> administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS
>>> zones".
>>
>> Refeclted to add this after the first sentence.
>>
>>> I am not sure we need to include the second paragraph of the answer to Q6.
>>
>> I think this was included in the wider interpretation of DNS, as NTIA uses the word DNS when it refers to the IANA functions, as you can see from their announcement.
>>
>> I have made addition to to say "While not directly relevant to the DNS,  in the wider context of the number resources component of  the IANA functions,..." 
>> Does this make it look more acceptable?
>>
>> I see your point as well that it is strange that we talk about the IANA Numbering Services when being asked about DNS.
>> I'm OK to also delete the paragraph in [] if others also believe it is not necessary.
>>
>> ----
>> Yes we believe the proposal maintains the security, stability, and resiliency of the DNS. It is our assessment that no other elements in the ICG proposal, compromise the security, stability, and resiliency of the DNS as pertained to the administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS zones".The current security, stability, and resiliency of the DNS today will remain, as there are no fundamental changes proposed to the operation of the DNS .
>>
>> [While not directly relevant to the DNS,  in the wider context of the number resources component of  the IANA functions, the Number Community believes the current operation of the IANA Numbering Services is secure, stable, and resilient. To maintain this current state, we have ensured that our proposal does not suggest any changes that would affect the security, stability, or resiliency of the IANA Numbering Services. There are no changes proposed for the operation of the IANA Numbering Services. We are further ensuring the service level to be maintained through the SLA. ]
>> ----
>>
>> Izumi
>>
>> On 2015/08/26 19:34, Andrei Robachevsky wrote:
>>> Hi Izumi,
>>>
>>> This version looks good to me.
>>>
>>> Izumi Okutani wrote on 26/08/15 11:59:
>>> [...]
>>>
>>>> There are two points where I didn't make changes and would like to see for your comments:
>>>>
>>>> 1. Q2. 
>>>
>>> I suggest a slight modification to the text "each of the three IANA
>>> function is basically independent with minimum overlap. In areas where
>>> potential overlaps were anticipated, such as on Intellectual Property
>>> Rights (IPR)  and establishment of the Post Transition IANA(PTI),'
>>>
>>> specifically to use "potential incompatibility" instead of "potential
>>> overlap" since we used the term overlap in a different context (i.e.
>>> overlapping registries).
>>>
>>>
>>>>    Observation about compability on PTI.
>>>>    We say we observe no compability with establishment of PTI, which is correct. 
>>>>    Do we want to give condition such as “given all existing resources to perform the IANA functions under ICANN will be made available to PTI “.?
>>>>
>>>
>>> IMO, as long as the service levels are met, the IANA resources are
>>> outside our concern. If we still  want to stress this point, I'd suggest
>>> "The Number Community proposal for the RIRs to sign an SLA with ICANN is
>>> still possible to implement, and therefore still workable, provided that
>>> ICANN ensures that conditions in the SLA are met by the PTI".
>>>
>>>
>>>> 2. Q.6 
>>>>    We are describig the number community as the customer of the IANA Numbering Services.
>>>>    I can see this perspective in the wider sense, as the same time I assume RIRs would consider themselves as the direct customers of the IANA Numbering Services.
>>>>    Do we keep this description as it is, or mention anything about RIRs being the direct customers?
>>>
>>> I have a bit of a problem with the answer to Q6 as it is written. I
>>> think we should limit the scope of the review to "as pertained to the
>>> administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS
>>> zones".
>>>
>>> I am not sure we need to include the second paragraph of the answer to Q6.
>>>
>>> Thanks,
>>>
>>> Andrei
>>>
>>
>> <CRISP team response to the call for public comment on the combined proposal-20150826_4.docx>_______________________________________________
>> CRISP mailing list
>> CRISP at nro.net
>> https://www.nro.net/mailman/listinfo/crisp
> 