[NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal:First Draft

Seun Ojedeji seun.ojedeji at gmail.com
Sun Dec 21 06:04:35 CET 2014


sent from Google nexus 4
kindly excuse brevity and typos.
On 20 Dec 2014 21:51, "Richard Hill" <rhill at hill-a.ch> wrote:
>
>
> >-----Original Message-----
> >From: Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
> >Sent: samedi, 20. décembre 2014 17:12
> >To: Richard Hill
> >Cc: Mwendwa Kivuva; ianaxfer at nro.net
> >Subject: Re: [NRO-IANAXFER] Internet Number Community IANA Stewardship
Proposal:First >Draft
> >

>
> > and the operator would not lay claims on them.
>
> As already mentioned, ICANN owns the trademark and the domain name, so it
doesn't need to "lay claims on them".
>
Domain name yes based on the simple fact that one needs to provide contact
information when registering a domain and it made absolute sense for that
contact to be ICANN's as the IANA operator. I don't think ICANN will refuse
to allow change of contact information once it is determined no longer to
be worthy of operating IANA. As to the trademark on the name IANA, perhaps
it will be good if you refer me to any writeup that days something in the
line of the following "....IANA is a trademark registered to ICANN"
otherwise I would expect most writeup to be in the form of "....As the
operator of IANA functions, IANA is the registered trademark to ICANN"

If the former is the case then maybe there may be something to worry about,
however if the later is the case (which I think it is) then I think what
would apply with the domain name will also apply here is a move is
required. Everything related to IANA function simply moves, I don't think
listing the items one by one is necessary for a layman reason of not
forgetting an item :-)

> >On the other hand in a worse/unlikely scenario when ICANN does, then it
would
> >be that ICANN will have those items but will not be able to perform any
functions
> > with it...
>
> Perhaps not. But it could charge money for their transfer to (or use by)
a new IANA functions operator.
>
Well I doubt this makes a strong case as I have explained above.

>
>
> SNIP
>.
>
> > I think i will put this in context that ICANN is currently empowered at
the moment
> > to do that as the IANA operator and that is what the current draft
> > is also reflecting.
>
> It is not only empowered to do that as the moment.
> It will also be empowered to do that in the future,
>
I think you read that incorrectly, what I meant is that it's empowerment is
presently from the NTIA contract (which is simply the ability to operate
the functions). By your statement above, it seem you are implying that even
the current NTIA contract does not allow the transfer?

>
unless the new contract between the RIRs and ICANN says otherwise.
>
I guess your response to the above question will really help answer this.

> >> Another option is that the new contract between the RIRs and ICANN
specifies
> >> that the RIRs could continue to use the mark IANA and the domain name
IANA.ORG
> >> if their part of the IANA function is transferred to some entity other
than ICANN.
> >
> >Actually in a scenario where its a community that pulls out, i think it
may be
> > neater to not even use the name IANA and iana.org any longer.
>
> Again, that's a different discussion.
>
Well maybe, but its to emphasis the fact that this does not have to be cast
and stone. It should be flexible. The crisp proposal in it's current form
has indicated it empowers ICANN to operate numbers related functions and
ICANN will no longer operate those functions if there is a bridge in
agreement IMO that's all that matters. At the bridge of crossing to another
operator, it's the ultimate decision of this community to determine what it
wants to carry along to another operator... Maybe adding a line that makes
sure that the current operator works with this community to ensure smooth
transition to another operator may be helpful.
This is not the same thing as specifically mentioning that the name IANA or
domain iana.org would be transferred because that on it's own is an attempt
to separate those items. When infact it's all part of the function.

>
SNIP
>
> So if the RIRs want something about intellectual property rights, then
the RIRs have to propose actual language.
>
> >> but  they should be mindful of how this is worded so as not to
indirectly
> >> restrict a community from using another name/url when its become
> >> absolutely necessary.
>
> Correct, that is a matter of drafting.
>
I think simply writing about IANA function (it's description) will be fine.
A point to the about iana on the iana.org may be helpful

Thanks

> SNIP
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.nro.net/pipermail/ianaxfer/attachments/20141221/9979bc30/attachment-0001.html>


More information about the ianaxfer mailing list