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

[Sweeting, John]

Support and like Alan¹s edits.

On 2/19/15, 6:07 AM, "Alan Barrett" <apb at cequrux.com> wrote:

>On Thu, 19 Feb 2015, Izumi Okutani wrote:
>>If you recall my update from ICANN52 Singapore, we discussed with Russ
>>and Jari to make a joint statement with the IETF.
>>
>>I am consulting Russ and Jari whether we should submit joint +
>>indivisual statements from each of the communities, or stick to a single
>>joint statement by the IETF and the numbers.
>>
>>I haven't heard from them at this stage so I suggest:
>>
>> - We work on our reponse to the ICG as the numbers community, so that
>>   we have something to repond to the ICG before the 21 Feb deadline,
>>   as the numbers at least
>> - We can still submit a joint statement with the IETF, in addition to
>>   this, after we hear from the IETF
>
>Yes, I think we should work on statement purely from the numbers
>community, and a joint statement can be added later, or not, as
>the situation warrants.
>
>>Based on the above, this is a draft reply to Alissa.
>>
>> - Once I re-confirm with Russ and Jari that they are happy to make a
>>   joint statement, I will add this sentence at the end:
>>
>>   "The IETF and the numbers community are working on the joint
>>   statement in addition, which we plan to submit the ICG."
>>
>>Please let me know if you have any feedback to the draft before UTC13:00
>>20th Feb. I will submit to the ICG before 23:00 UTC 20th Feb.
>
>That seems like a good way of handling the possibility that a joint
>statemt may come later.
>
>I agree with the essence of your draft reply below.  However, I
>will suggest some minor editing.
>
>> Dear Alissa,
>>
>> Thank you for sharing the question from the ICG.
>>
>>> The numbers proposal sees these changes as a requirement of the
>>> transition and the protocols parameters proposal does not. 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?
>>
>> If the two proposals are incompatible and if needed, the numbers
>> community is open to consider to modify the proposal.
>>
>> On the other hand, we do not observe incompatibilities in our
>> proposal with the proposal for protocol parameters based on our
>> observation below.
>
>My suggestion: Give more emphasis to "we do not observe
>incompatibilities", like this:
>
>   We do not observe incompatibilities between the proposals from
>   the numbers and protocol parameters communities, for reasons
>   given below.  However, if they are indeed incompatible, then
>   the numbers community would be willing to modify our proposal.
>
>> * It is the preference of the Internet Number Community that the mark
>>   and the name be transferred to an entity independent of the
>>   IANA Numbering Services Operator.
>>
>> * The numbers community considers the IETF Trust as an acceptable
>>   option, given this is supported by the IETF community, and the IETF
>>   Trust is willing to accept it. This is not the only option and open
>>   to consider an option which works for the IETF community.
>>
>> * The holder of the mark and domain are expected to keep a condition,
>>   that IANA trademark and IANA.ORG domain are available for the use of
>>   IANA Numbering Services, in case we change the IANA operator in the
>>   future.
>
>Where you say "given", I'd say "provided", because I think it's not yet
>known what the IETF and IETF Trust will decide.
>
>I'd also be inclined to move the hardest requirement to the beginning
>of the list, like this:
>
> * The numbers community has a requirement that the IANA
>   trademark and IANA.ORG domain must be available for the use
>   of IANA Numbering Services in the future, even if the IANA
>   Numbering Services Operator is changed from ICANN to some other
>   operator, or if different communities choose different IANA
>   operators in the future.
>
> * In order to meet that requirement, it is the preference of
>   the Internet Number Community that the mark and the name be
>   transferred to an entity independent of the IANA Numbering
>   Services Operator.
>
> * The numbers community considers the IETF Trust as an acceptable
>   option, provided this is supported by the IETF community, and
>   the IETF Trust is willing to accept it. This is not the only
>   option, and the numbers community is open to consider other
>   solutions which work for other affected parties.
>
>> To summarize, given the numbers proposal does not set a must
>> condition to transfer the mark and domain to the IETF Trust nor
>> any other specific entity, and the IETF proposal does not say it
>> will oppose to consider transfer of the mark and domain to the
>> IETF Trust, we do not observe any incompatibilities.
>
>I'd emphasise the word "must", and reword slightly:
>
>  To summarize: the numbers proposal does not set a "MUST"
>  condition to transfer the mark and domain to the IETF Trust or
>  to any other specific entity, and the IETF proposal does not
>  say it will oppose transfer of the mark and domain to the IETF
>  Trust, so we do not observe any incompatibilities.
>
>>
>> Best Regards,
>> Izumi Okutani
>> Chair, the CRISP Team
>
>Thanks for drafting the reply.
>
>--apb (Alan Barrett)
>
>_______________________________________________
>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.