[CRISP-TEAM] Fwd: Re: [Ianaplan] Question from the ICG

Tue Feb 10 05:57:09 CET 2015

+1

On 10/02/2015 10:21 am, "Andres Piazza" <andres at lacnic.net> wrote:

>Agree fully with John and Andrei.
>
>Hope IETF agrees with us so there is no need for modifications to the
>proposal.
>
>Andres
>
>El 10/2/15 a las 4:39, Sweeting, John escribió:
>>
>> On 2/9/15, 2:58 PM, "Andrei Robachevsky" <robachevsky at isoc.org> wrote:
>>
>>> Hi Izumi,
>>>
>>> Izumi Okutani wrote on 09/02/15 18:48:
>>> [...]
>>>
>>>> "If these aspects of the proposals are perceived as incompatible would
>>>> the numbers and protocol parameters communities be willing to modify
>>>> their proposals to reconcile them?"
>>>>
>>>> Are we willing to modify the proposal and reconcile?
>>>>
>>> If this appear to be the case, I think we should try to reconcile them.
>>> But looking at the discussion in the IETF we may not need to do that at
>>> all, since it looks like there is no incompatibility between the two
>>> proposals.
>> I agree. From reading the threads this does not look to be an issue.
>>
>>>> The rationale of the IETF is that it is not a high priority to address
>>>> the IPR issues on IANA trademark and iana.org and may need to consider
>>>> serveral factors which may not be completed before the transition.
>>>>
>>>> The bottom line for us, my personal opinion is that we simply want to
>>>> make sure that the existing IANA operator does not hold on and
>>>>disallow
>>>> the transfer those IPRs.
>>>>
>>>> As long as it is stated as the condition in the contract, it is not a
>>>> must to transfer IPR to a particular organization before the NTIA
>>>> stewardship transition on the IANA.
>>>>
>>>> What are your thoughts?
>>> I think the community was pretty clear regarding the transfer of thee
>>> assets. If we want to modify this section we will have to confirm this
>>> with the community, IMO.
>> Fully agree with Andrei on this point.
>>
>>
>>> Cheers,
>>>
>>> Andrei
>>>
>>>
>>>>
>>>> Izumi
>>>>
>>>>
>>>> On 2015/02/09 22:31, Nurani Nimpuno wrote:
>>>>> Thanks Andrei.
>>>>>
>>>>> This is my interpretation as well. Good to hear Jari express it this
>>>>> way.
>>>>>
>>>>> Nurani
>>>>>
>>>>>
>>>>> On 9 feb 2015, at 20:59, Andrei Robachevsky <robachevsky at isoc.org>
>>>>> wrote:
>>>>>
>>>>>> FYI. There is some discussion going on in the IETF (IANAPLAN WG) on
>>>>>> how
>>>>>> to answer Alissa's question.
>>>>>>
>>>>>> IMO, the proposals are indeed incompatible only if the IETF opposes
>>>>>> the
>>>>>> change. And only in this case an action would be required from our
>>>>>> side.
>>>>>>
>>>>>> Andrei
>>>>>>
>>>>>>
>>>>>> -------- Forwarded Message --------
>>>>>> Subject: Re: [Ianaplan] Question from the ICG
>>>>>> Date: Mon, 9 Feb 2015 18:48:23 +0800
>>>>>> From: Jari Arkko <jari.arkko at piuha.net>
>>>>>> To: Alissa Cooper <alissa at cooperw.in>
>>>>>> CC: ianaplan at ietf.org
>>>>>>
>>>>>> The IETF proposal did not set it as a requirement that ownership of
>>>>>> IANA.ORG be transferred as a part of the transition. The RIR
>>>>>>community
>>>>>> needs to think if they believe it really is a requirement. But I
>>>>>> guess that
>>>>>> the question for us is from the IETF perspective, if other
>>>>>>communities
>>>>>> believe they need that, is the IETF community OK with that? If we
>>>>>>are,
>>>>>> there are some implications to the IETF Trust, some rules to think
>>>>>> about
>>>>>> for various future same/different/partially different IANA operator
>>>>>> scenarios,
>>>>>> and some negotiations about these. I think we can set most of that
>>>>>> aside
>>>>>> for the moment, as details to worry about later. But what is the
>>>>>> high-level
>>>>>> guidance from the IETF community on this?
>>>>>>
>>>>>>   From my perspective the question that we should try to answer at
>>>>>>the
>>>>>> IETF is as follows. While we are (in my opinion) not changing our
>>>>>> proposal - it stays at the �not required� state, is the IETF
>>>>>>community
>>>>>> OK with a change of ownership? The IETF and RIR proposals are
>>>>>> only incompatible if they require the change _and_ we oppose it.
>>>>>>
>>>>>> FWIW, my read of the earlier discussion in IANAPLAN was that
>>>>>> our opinion was �not required� rather than that we�d oppose it. If
>>>>>> that is right, then the answer is perhaps that we�d be fine with
>>>>>> that. Do I read that right, and what do others think?
>>>>>>
>>>>>> Jari
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CRISP mailing list
>>>>>> CRISP at nro.net
>>>>>> https://www.nro.net/mailman/listinfo/crisp
>>>>>
>>>>> _______________________________________________
>>>>> CRISP mailing list
>>>>> CRISP at nro.net
>>>>> https://www.nro.net/mailman/listinfo/crisp
>>>>>
>>> _______________________________________________
>>> 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
>
>
>_______________________________________________
>CRISP mailing list
>CRISP at nro.net
>https://www.nro.net/mailman/listinfo/crisp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3565 bytes
Desc: not available
URL: <https://www.nro.net/pipermail/crisp/attachments/20150210/bf003729/smime.p7s>