[OFB-WG] Draft Comment on Bylaw Amendment

Cheryl Langdon-Orr langdonorr at gmail.com
Fri Mar 22 20:27:47 UTC 2024


Well articulated (as usual) Alan...
<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
Cheryl Langdon-Orr
about.me/cheryl.LangdonOrr
<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>


On Sat, 23 Mar 2024 at 05:12, Alan Greenberg via OFB-WG <ofb-wg at icann.org>
wrote:

> See embedded replies
>
> On Fri, Mar 22, 2024 at 9:57 AM Eduardo Diaz <eduardodiazrivera at gmail.com>
> wrote:
>
>> Alan:
>>
>>
>> I must emphasize the critical concern that incorporating URLs into the
>> ICANN bylaws fundamentally undermines their integrity and purpose. In this
>> instance, the reliance on a URL is particularly problematic. The inherent
>> nature of URLs allows for the content they direct to be altered at any
>> moment. Why include them at all if not to signify potential change?
>>
>
> Yes, in theory the content of the web page could be altered on purpose or
> accidentally.  But that would not alter the use of the Bylaw limitation.
> For the limitation to kick in, the actual conditions need to be satisfied,
> not just appear falsely on a web page. Presumably the web page would have
> an appropriate disclaimer.
>
>>
>>
>> I want to draw your attention to the URL precedence mentioned in the
>> ICANN bylaw 4.2(h) URL, which directs users to a page detailing the process
>> for a “Reconsideration Request,” including a form for submission. It guides
>> to a procedural aspect rather than to "…specific cases where the
>> accountability mechanisms shall be limited or unavailable…"
>>
>
> Of course. It is there for a different purpose than the one being
> suggested. But it does set a precedent for having a web pointer in the
> Bylaws.
>
> This is not at all optimal, but the problem I raised is real and needs to
> be addressed. How do you alert someone who is reading the Bylaws to exactly
> what cases the limitation applies. *Do you have a better way to address
> this real problem?*
>
>
>> As I've previously mentioned, the fact that you can change online content
>> means that these "specific cases" could be added, modified, or removed
>> without notice, thereby affecting the stability and reliability of the
>> ICANN bylaws.
>>
>
> No, for the limitation/unavailability to apply, being on a web page is not
> sufficient.  The three stringent conditions listed in the proposed Bylaw
> must have been met.
>
>>
>>
>> I think instances warranting limited or unavailable accountability
>> mechanisms should be explicitly stated within the bylaw rather than
>> referenced through a mutable online source. This approach ensures the
>> permanence and clarity of our bylaws and safeguards against any changes
>> that could compromise their intended mandate.
>>
>
> That is what was originally proposed. We do not know if there will ever be
> mose limitations (I personally believe that there will be - one was
> discussed during the failed discussions on Closed Generics). But if there
> is, that would require a new Fundamental Bylaw amendment and the process to
> do that is an awkward and time-consuming process. See Bylaws Annex D,
> Article 1. It takes several pages just to describe the process.
>
> Avoiding having to do that while NOT making it any easier to enact
> accountability limitation is why I suggested commending the Board for its
> idea.
>
> Alan
>
>>
>> -ed
>>
>> On Thu, Mar 21, 2024 at 6:39 PM Alan Greenberg via OFB-WG <
>> ofb-wg at icann.org> wrote:
>>
>>> I have drafted a comment on Proposed Bylaws Updates to Limit Access to
>>> Accountability Mechanisms.
>>>
>>> The Wiki page is https://community.icann.org/x/PoDyEg
>>> and the Comment Google Doc is
>>> https://docs.google.com/document/d/1CzW_U6nA7GSdwX5z6eu3EFn8FE-uh0Z1ZDGIgez2q7c/
>>> <https://docs.google.com/document/d/1CzW_U6nA7GSdwX5z6eu3EFn8FE-uh0Z1ZDGIgez2q7c/edit?usp=sharing>
>>> .
>>>
>>> Alan
>>> _______________________________________________
>>> OFB-WG mailing list
>>> OFB-WG at icann.org
>>> https://mm.icann.org/mailman/listinfo/ofb-wg
>>>
>>> _______________________________________________
>>> 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.
>>
>>
>>
>> --
>> *Notice*: This email may contain confidential information, is subject to
>> legal privilege, and is intended for the use of the named addressee only.
>> If you are not the intended recipient, you must not use, disclose or copy
>> any part of this email. If you have received this email by mistake, please
>> notify the sender and delete this message immediately.
>>
> _______________________________________________
> OFB-WG mailing list
> OFB-WG at icann.org
> https://mm.icann.org/mailman/listinfo/ofb-wg
>
> _______________________________________________
> 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: <https://mm.icann.org/pipermail/ofb-wg/attachments/20240323/403f34d4/attachment-0001.html>


More information about the OFB-WG mailing list