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

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

On 11/9/14, 11:34 PM, ""Martin J. Dürst"" <[e-mail]> wrote:
><snip>
>But my guess is that agreeing to share iana.org is much easier that to
>agree e.g. about reserved labels (such as .local) in the root zone. The
>later is crucial for the functioning of the Internet, and if that can be
>agreed on, then an agreement on the former should also be possible.
>
>So I very much think that the question of "But what if the registry
>operator function is split up?" cannot be used as an argument for not
>talking about the trademark and domain name transfer.

Well, there's a big difference between "talking about the trademark and
domain name transfer" and directly requesting the reassignment of
corporate property preemptively for our peace of mind. We currently have
some text in our draft ICG response intended to protect us in the
eventuality of a transition, and we will continue to in the future. So I
don't think anyone is arguing against "talking," it's more about the
nature of the discussion. Ideally, we will grant the IAOC the latitude
they need to cover our backs, rather than being overly prescriptive in the
ICG response.


And sure, after the hypothetical division of the IANA function into
multiple operators, I could imagine engineering practices that might, at
least for a transitional period, rely on DNS or web redirects to dispatch
requests from iana.org to the new operators. That would be one of several
directions worth exploring. Fortunately, access to the IANA registries, as
Stephen Farrell recently noted, does not have the same operational
requirements as accessing the root of the DNS - not by a very long shot.

But what does that mean for the purposes of this discussion? If the
registries split up acrimoniously, we have no shortage of options for
engineering a protocol parameter registry transition, including just
forking it. Tricky to do that with a mission-critical resource like the
root of the DNS, definitely, but much less tricky when we're talking about
a registry that is infrequently consulted, and almost always consulted by
developers and protocol designers. This makes the IETF's requirements for
a transition a bit easier to solve for. Our job on this mailing list is to
solve for those requirements.

Jon Peterson
Neustar, Inc.