[Ccpdp-rm] On RFC1591 and "binding"

[Patricio Poblete]

Eberhard,

The FoI did not speak of a review in the context of Delegations, which is
where the RFC1591 mentions the IDNB. It does mention the right of appeal in
the context of revocation.

Why does it matter to me? Because I think that the binding or not binding
nature of a review should be discussed on its own merits, not because some
old piece of scripture that was never implemented said so. I think that we
will make a stronger case that way.

Patricio

On Wed, Apr 21, 2021 at 4:53 PM Dr Eberhard W Lisse via Ccpdp-rm <
ccpdp-rm at icann.org> wrote:

> Patricio,
>
> where is this coming from?  And, now?
>
> The FoI clearly stated that it is appropriate to have a review.  And
> this means binding.  Whether the IDNB has ever existed, how it was
> composed, if at all, and whether it actually decided a case or two is
> hardly relevant.
>
> Never mind that there are very old statutes on book in many places. And
> remain in force unless specifically revoked. Whether the concept of
> "letra muerta" exists in some jurisdictions or not, I don't agree that
> statutes expire by themselves.
>
> el
>
> On 2021-04-21 22:38 , Patricio Poblete wrote:
>  > Perhaps we can't mix and match, but when writing the FoI Report we did
>  > pick and choose.  Which was OK, because we were aware that not
>  > everything in RFC1591 was still relevant, and much of what was
>  > relevant needed interpretation.  That is why I believe the correct way
>  > to cite RFC1591 now is as "RFC1591, /as interpreted by the FoI/".
>  >
>  > Of course, the most obvious part that clearly is not relevant anymore
>  > is where it says
>  >
>  > It is extremely unlikely that any other TLDs will be created
>  >
>  >
>  > but if we restrict ourselves to what has to do with ccTLDs, I believe
>  > the IDNB is one such part.  In fact, when we addressed the matter of
>  > Delegations in the FoI, we copied from RFC1591 the requirement that
>  > that Significantly Interested Parties should agree that the designated
>  > manager is the appropriate party and that other Stakeholders should
>  > have some voice in selecting the manager, but we ignored completely
>  > the IDNB and the possibility that it could be brought back to life
>  > (brought to life, actually) to review cases where contending parties
>  > could not agree among themselves.
>  >
>  > I think that for the review mechanism that we are tasked to design
>  > this point does not make much difference.  But it does make us look
>  > detached from reality when we speak of the IDNB as something somehow
>  > real, when it has been "letra muerta" for decades.
>  >
>  > Patricio
>  >
>  >
>  > On Wed, Apr 21, 2021 at 12:01 PM el--- via Ccpdp-rm <ccpdp-rm at icann.org
>  > <mailto:ccpdp-rm at icann.org>> wrote:
>  >
>  >     Patricio,
>  >
>  >     we can’t mix and match, either we stand by RFC1591/FoI or we
>  >     don’t.  And This is on the level of dying in the ditch for me.
>  >
>  >     Never mind that while it may have been quite at hoc the IDNB seems
>  >     to have been called a few times.  But then a lot of what St.  Jon
>  >     did was ad hoc.
>  >
>  >     greetings, el
> [...]
>
> --
> Dr. Eberhard W. Lisse   \         /       Obstetrician & Gynaecologist
> el at lisse.NA             / *      |  Telephone: +264 81 124 6733 (cell)
> PO Box 8421 Bachbrecht  \      /  If this email is signed with GPG/PGP
> 10007, Namibia           ;____/ Sect 20 of Act No. 4 of 2019 may apply
> _______________________________________________
> Ccpdp-rm mailing list
> Ccpdp-rm at icann.org
> https://mm.icann.org/mailman/listinfo/ccpdp-rm
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccpdp-rm/attachments/20210421/c12073ef/attachment-0001.html>