[CCWG-Accountability] judicial/arbitral function

Sat Jan 10 15:37:26 UTC 2015

Dear Mathieu,
Further to my previous message, I wish to make some comments to your
covering message
For ease of refernce, I have copied your message below and comment on that
pargraph by paragraph as follows:

*General Comments from Kavouss *
*Dear Mathieu , dear all,*
*There is conceptual problem in this other message referring to the two
terms "Review Mechanism "and "Redress Mechanism"..The  legal difficulties
 and 8or problem is that you have tzaken these two Mechanism as alternative
to each other where as they are complementary in the consecutive order i.e.
the  **"Review Mechanism " is a prerequisite mechamism based on its outcome
( suhggestions, recommendatioons,conclusions ) the "Redress Mechanism"
would be unsed to redress those elements which have been identified by the
Review Process.*
*If an enterprise, an organisation, or a company decides to verfy whther
the course of action taken complies with the terms and conditions (
charter ,convention, charter, constitution, covenant ....) based on which
that enterprise, organisation, or  company  is/ was established .It would
first review  the process and based on the outcome of the review the
shortcoming, inconsistencies, defficiencies ,problems are identified ,Then
through the **redress **process those **shortcoming, inconsistencies,
defficiencies ,problems are corrected .*

*Dear Colleagues, I support the relevance and importance of the
distinction. A description of this distinction is included in the "problem
definition" document currently open for your comments and contributions,
sections 3b (review) and 3c (redress). Maybe this discussion could be used
to check whether the current wording is agreeable to everyone ? *

*b.      Review mechanisms*

*The group considers review mechanisms to be mechanisms that assess the
performance and relevance of processes or structures, and provide
recommendations (binding or not binding) for improvement. *
*Examples include: *

Comments from Kavouss

1.The outcome from the review mechanism is never binding due to the legal
connotation of the Term " Review" . Review is review  has always had
optional character and never has been binding

*-          Periodic structural reviews of SOs and ACs (as currently
mandated in the ICANN Bylaws)*

*-          AoC-mandated ICANN organizational reviews for Accountability
and Transparency; Security, Stability, and Resiliency; WHOIS; and
Competition and Consumer Trust.*
Comments from Kavouss
2. You have referred to  *Periodic structural reviews of SOs and ACs (as
currently mandated in the ICANN Bylaws.*But this is valid in regard with
present structure  which is based on terms and conditions of AoC Bylaws,
Article of corporation where as the future structure may be totally
different

*c.      Redress mechanisms*

*The group defines redress mechanisms as mechanisms that focus on assessing
the compliance or relevance of a certain decision, and can conclude to its
confirmation, cancellation or amendment. The output of such mechanism shall
be binding. *

*Examples include: *

*-          Independent Review (if it is considered to be binding)*
*-          State of California or jurisdictions where ICANN has a presence
Court décisions*
*Comments from Kavouss *
*With respect to the first indent ,as I explained Under general comments
redressing process  has always been mandatory and binding since without
that how the **inconsistencies, defficiencies ,problems are identified
Under the review process are redressed if the process was not mandatory /
binding .*
*In view of the above, there is a need to clarify the matter.*
*I guess people are thinking of Review process similar to ATRT process
which is totally optional in the implementation . That does not work .If
you take that path there would be no accountability at all.*
*Moreover, As I have already indicated you need to make a clear distinction
between the Policy, Policy making and Policy implementing entities and
processes.*
*I do not uinderstand why we always by passed that important process .*
*I have made such suggestions several times but the two ch chairs have
ignored that to be included in the agenda*
*The question is are we make evry possible effrort to maintain the existing
process which is not acutally accountable to any one but on certain cases
is accountable to NTIA  or*
*We need to establish the separation of process and responsibilty through
an appropriate mechanism having two steps" Review "and the "Redress " the
former is  essential to be done periodically while the outcome once
considered under the latter process" Redress " is mandatory .*
*Then we need to describe*
*Who is the Policy making entity*
*Who is the Policy implementing entity*
*And what are the terms . conditions, provisions and content of Policy .*
*Thes should be clarified.*
*Regards*
*Kavouss *

2015-01-09 14:17 GMT+01:00 Kavouss Arasteh <kavouss.arasteh at gmail.com>:

> Dear Mathieu
> Dear All,
> I have several comments and one major problem in misconception and
> misunderstanding propagated by the author of these issues which has led and
> would further lead to a total misleading of the two terms " Review" and "
> redress"
> I will revert to you later
> Kavouss
>
> Sent from my iPhone
>
> On 9 Jan 2015, at 10:10, Mathieu Weill <mathieu.weill at afnic.fr> wrote:
>
> Dear Colleagues,
>
> I support the relevance and importance of the distinction. A description
> of this distinction is included in the "problem definition" document
> currently open for your comments and contributions, sections 3b (review)
> and 3c (redress).
>
> Maybe this discussion could be used to check whether the current wording
> is agreeable to everyone ?
>
>  b.      *Review mechanisms*
>
> The group considers review mechanisms to be mechanisms that assess the
> performance and relevance of processes or structures, and provide
> recommendations (binding or not binding) for improvement.
>
> Examples include:
>
> -          Periodic structural reviews of SOs and ACs (as currently
> mandated in the ICANN Bylaws)
>
> -          AoC-mandated ICANN organizational reviews for Accountability
> and Transparency; Security, Stability, and Resiliency; WHOIS; and
> Competition and Consumer Trust.
>
>
>
> c.      *Redress mechanisms*
>
> The group defines redress mechanisms as mechanisms that focus on assessing
> the compliance or relevance of a certain decision, and can conclude to its
> confirmation, cancellation or amendment. The output of such mechanism shall
> be binding.
>
> Examples include:
>
> -          Independent Review (if it is considered to be binding)
>
> -          State of California or jurisdictions where ICANN has a
> presence Court decisions
>
>
> May I also seize the opportunity to remind you all that your edits and
> suggestions are welcome on the rest of the document as well ?
>
> Best
> Mathieu
>
> Le 08/01/2015 22:44, Bruce Tonkin a écrit :
>
> Hello Paul,
>
>
>
>   .  For me, the difference between "review" (i.e. recommendations) and "judicial/arbitral function" (i.e. binding decision that mandates implementation) is key.
>
>  Agreed.    That is an important distinction.
>
> Regards,
> Bruce Tonkin
>
> _______________________________________________
> Accountability-Cross-Community mailing listAccountability-Cross-Community at icann.orghttps://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
> --
> *****************************
> Mathieu WEILL
> AFNIC - directeur général
> Tél: +33 1 39 30 83 06mathieu.weill at afnic.fr
> Twitter : @mathieuweill
> *****************************
>
> <20140105 CCWG Accountability - problem definition - strawman
> -coChairs.pdf>
>
> <20140105 CCWG Accountability - problem definition - strawman
> -prefinal.docx>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150110/5b2e2e24/attachment.html>