Re: [Ianaplan] A draft for your review

["Richard Hill" <[e-mail]>]

Re "we have managed without one for the past decade and a half, let’s not
start now", this implies that the absence of the IANA contract between NTIA
and ICANN will have no significant effect.

That is, it assumes that the change engendered by the absence of the
contract with NTIA is of no significance.

I think that it is safer to be agnostic and to protect against possible
negative consequences of that change.

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[e-mail]]On Behalf Of Eric
> Burger
> Sent: dimanche, 31. août 2014 20:28
> To: [e-mail]
> Subject: Re: [Ianaplan] A draft for your review
>
>
> Anyone can take anyone to court anywhere. Both the Internet
> Society and ICANN are setting up offices that could be potential
> venues all over the world. Any one we chose today will be a bad
> one tomorrow. If we do not need to specify a venue today, and we
> have managed without one for the past decade and a half, let’s
> not start now.
>
> On Aug 31, 2014, at 6:07 AM, Richard Hill <[e-mail]> wrote:
>
> > Dear Brian,
> >
> > Thank you for these thoughtful comments.
> >
> > Please see additional comments embedded below.
> >
> > Best,
> > Richard
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: samedi, 30. août 2014 22:30
> >> To: [e-mail]
> >> Cc: Eliot Lear; [e-mail]; Russ Housley
> >> Subject: Re: [Ianaplan] A draft for your review
> >>
> >>
> >> Hi,
> >>
> >> I will review the draft carefully in due course, but I want to react
> >> briefly to a couple of Richard's comments:
> >>
> >> On 31/08/2014 01:29, Richard Hill wrote:
> >> ...
> >>
> >>> 4) Related to the above, should consideration be given to
> >> adding a proper dispute resolution clause, that is, including
> >> choice of law and venue, to the agreement?
> >>
> >> I believe that we should explicitly not mention a legal venue.
> >
> > Whether you mention it or not, the legal venue exists.  Either
> party to the agreement (ICANN or ISOC) could take the other to
> court, arguing that the agreement is a contract.
> >
> >> We
> >> should simply
> >> stick to the IAB being in charge and the IESG being the
> technical decision
> >> taker in case of doubt. We never, ever want to suggest that a court has
> >> authority.
> >
> > As noted above, there is no way to prevent one party from
> taking the other to court.  What the outcome might be is anybody's guess.
> >
> >> (And if we did, we would definitely not want it to be
> >> a national
> >> court anyway.)
> >
> > I definitely agree with that.  But the only way to ensure that
> a national court cannot get involved is to specify an arbitration
> clause, something like:
> >
> > "Any disputes arising out of or in connection with this
> agreement shall be finally settled by binding arbitration under
> the [commercial | international] arbitration rules of the
> [American Arbitration Association | Swiss Chambers' Arbitration
> Institution] by three arbitrators.  The language of arbitration
> shall be English.  The seat of arbitration shall be [New York,
> New York | Geneva, Switzerland].  The agreement shall be governed
> by the law of [California | New York | Switzerland]."
> >
> > Obviously other possibilites exist for the bits in square
> brackets (I'm using the symbol | to indicate the option to choose
> one of the possibilities).
> >
> >>
> >> ...
> >>
> >>> "And item 4 of RFC 2860 should be modified to read as follows:
> >>>
> >>> "4. Agreed technical work items.  ICANN agrees, notwithstanding
> >> any provisions in its Bylaws or other corporate documents that
> >> might be construed differently, that during the term of this MOU
> >> it shall cause IANA to comply ..."
> >>>
> >>> For reference, item 4 of RFC 2860 currently reads "4. Agreed
> >> technical work items. ICANN agrees that during the term of this
> >> MOU it shall cause IANA to comply ..."
> >>
> >> IANAL, but that "notwithstanding" clause seems logically
> >> redundant.
> >
> > I wouldn't be so sure about that.  The agreement is indeed
> clear, but what may not be clear is whether ICANN explicitly
> agreed that the agreement takes priority over its Bylaws.
> >
> > The ICANN Board has a fiduciary duty faithfully to abide by the
> ICANN Bylaws.  Since the Bylaws imply that the Board is the
> ultimate decision-making authority, the Board might feel that the
> Bylaws have prededence over the agreement.
> >
> > Of course if that ever happened ISOC could cancel the
> agreement, but, in accordance with the cancellation clause, that
> would leave ICANN in charge for six months, until ISOC
> establishes some other mechanism.
> >
> > The possibility that the ICANN Board might override an IETF
> decision clearly does not arise at present, because the IANA
> Functions contract between ICANN and NITA specifies (in 1.2.9)
> that ICANN will implement the IETF policies/instructions.
> >
> > But the issue here is how to replace that contract.  Once that
> contract is gone, there should be, in my opinion, some formal
> recognition by ICANN that it is not the ultimate authority, the
> ultimate authority is still the IETF.
> >
> > That is, I think that something like the language in question
> is needed to replace the current contract between NTIA and ICANN.
> >
> >> The existing
> >> text (which was ratified by the ICANN Board in 2000) leaves no
> >> loophole. Personally
> >> I think the risks in changing even one word in the existing MoU
> >> are too great.
> >
> > What risks do you have in mind?
> >
> >>
> >>> 7) There was extensive discussion (but no agreement) on the
> >> IANA Transition mailing list regarding whether or not the fact
> >> that a US court could, in theory, order ICANN/IANA to do
> >> something contrary to agreed community policies is an issue and,
> >> if so, whether anything should be proposed to deal with that
> >> issue, such as proposing that the entity that performs the IANA
> >> function should have immunity of jurisdiction, or that the entity
> >> should have redundant sites in more than one jurisdiction.
> >>>
> >>> If there is support for dealing with that issue, then some text
> >> could be added.
> >>
> >> While I'd love to see it happen, I think it's a separable issue so
> >> should be left out of scope for now.
> >>
> >>   Brian
> >>
> >
> > _______________________________________________
> > Ianaplan mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ianaplan
>
>