Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

["Peterson, Jon" <[e-mail]>]

Insisting on the transfer of domains, marks, and identifiers to ourselves
is not likely to prevent the contingencies we're concerned about - it is
more likely to precipitate them, by turning this process into a
confrontation. I think we would need a very different mandate as an
organization to take this step. It is both reckless and unnecessary.


Jon Peterson
Neustar, Inc.

On 11/4/14, 4:21 AM, "Miles Fidelman" <[e-mail]> wrote:

>Agree.  Specificity is as important in contractual language as it is in
>a protocol spec.  Lack of clarity would only prolong conflict (e.g.,
>litigation) if this clause ever has to be executed.  I'd go further, and
>explicitly add "including registration of the iana.org domain" to the
>language.
>
>Miles Fidelman
>
>Richard Hill wrote:
>> Thank you for this, but I still prefer the language that I proposed in
>>my
>> previous message, that is:
>>
>> "2.  results in the transfer of any associated marks and identifiers to
>>the
>> IETF Trust, with the understanding that current and subsequent
>>operators of
>> the IANA function shall be allowed to use them free of charge."
>>
>> Best,
>> Richard
>>
>>> -----Original Message-----
>>> From: Ianaplan [mailto:[e-mail]]On Behalf Of Alissa
>>> Cooper
>>> Sent: mardi, 4. novembre 2014 02:27
>>> To: Eliot Lear
>>> Cc: [e-mail]; Andrew Sullivan
>>> Subject: Re: [Ianaplan] control and negotiation (was Re:
>>> draft-ietf-ianaplan-icg-response-02 working group last call)
>>>
>>>
>>> Hi Eliot,
>>>
>>> On Nov 3, 2014, at 5:15 PM, Eliot Lear <[e-mail]> wrote:
>>>
>>>> On 11/3/14, 5:12 PM, Alissa Cooper wrote:
>>>>> Hi Eliot,
>>>>>
>>>>> On Nov 3, 2014, at 2:03 PM, Eliot Lear <[e-mail]> wrote:
>>>>>
>>>>>> I suggest that if
>>>>>> the IETF/IAB or IETF trust takes control of the name, it do
>>> so with the
>>>>>> understanding that it take responsibility for seeing that backward
>>>>>> compatibility continue for each customer (names, numbers, protocol
>>>>>> parameters, in particular) for so long as it is safe to do so.  If
>>>>>> someone else wants to take control of the name, they should make
>>>>>>that
>>>>>> same promise.
>>>>> This is so close to the language that I suggested that it¹s
>>> hard for me to tell the difference between what you¹re suggesting
>>> and what I suggested. To state the above requirement concisely:
>>>>> "Whoever owns the marks and identifiers has responsibility for
>>> ensuring backwards compatibility in the event that IANA
>>> operations shift to different entit(ies).²
>>>>> The requirement is that the owner of the marks/identifiers has
>>> to enable a smooth transition of the operations ‹ regardless of
>>> whether the marks owner is the same as the operator or different
>>> or if there are multiple operators. Because the current owner is
>>> ICANN, this requirement would fall on ICANN.
>>>>> I would be satisfied if we substitute the above requirement in
>>> place of the one currently in the draft about the transfer of
>>> marks and identifiers. Do I read your email correctly that you
>>> would be satisfied as well?
>>>> Very much so!!
>>> Cool. So I would suggest something like this:
>>>
>>> "To address concerns regarding appropriate contingencies to transition
>>>     to another operator, the IAOC is asked to conclude a supplemental
>>>     agreement that-
>>>
>>> ...
>>>
>>>     2.  requires the owner of any associated marks and identifiers
>>> to ensure backwards compatibility with subsequent operators.²
>>>
>>> Alissa
>>>
>>>
>>>> Eliot
>>>>
>>> _______________________________________________
>>> Ianaplan mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ianaplan
>>>
>>>
>> _______________________________________________
>> Ianaplan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ianaplan
>
>
>-- 
>In theory, there is no difference between theory and practice.
>In practice, there is.   .... Yogi Berra
>
>_______________________________________________
>Ianaplan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan