[Internal-cg] Handling process complaints

Sat Jan 31 14:50:41 UTC 2015

Dear Daniel,
Dear All,
let us use the term " concerns" or " comments " instead of complaint
Let also us to take everybody's view into account.
We need to make compromise and not pushiong for a particular thought
Regards
Kavouss

2015-01-31 12:20 GMT+01:00 Daniel Karrenberg <daniel.karrenberg at ripe.net>:

>
> Manal, colleagues,
>
> thank you for your thoughts. What you drafted is much less of a
> 'complaints procedure' than what I expected based on the discussion at our
> call. I am still not convinced that we actually need this. I will comment
> on the draft in a separate message.
>
> <addressing Milton and Kavouss more than Manal>
> For the sake of our discussion I make absolutely clear that I am not
> implying that the OC processes will be flawless. I fully expect comments to
> that effect. In fact we have already observed such comments. I have said
> explicitly that we absolutely need to address those comments if they raise
> issues which, in our judgement, will make our document unacceptable. My
> intention is definitely not to avoid such decisions, to the contrary.
>
> I strongly object to use the word "complaint" because of its meaning as an
> initial step in a formal procedure or in litigation. By talking about
> complaints we are raising expectations about a formal process and an
> obligation to respond and to take specific actions. We are raising these
> expectations whether we intend to or not. This is why we should not use the
> word when communicating about process comments.
> </addressing Milton and Kavouss more than Manal>
>
> I repeat that we should avoid making procedures unless we absolutely need
> to. In my experience, even small and seemingly benign "procedures" create
> the risk of abuse and the potential to grow into bureaucratic monsters
> before we realise it. NB: I am not an anarchist: if we are really convinced
> of the necessity of a procedure, we should decide to implement one. I argue
> against doing it without being 100% clear about the need. I am not
> convinced of the need in this case.
>
> Now for the in-line stuff: ;-)
>
> On 29.01.15 21:40 , Manal Ismail wrote:
>
>> Many thanks Daniel for your thorough email ..
>> To make sure I address all the points you've raised, please find my
>> responses inline below ..
>> Thanks Patrik for your reply, which I've also responded to, inline below
>> ..
>> Kind Regards
>> --Manal
>>
>> -----Original Message-----
>> From: Patrik Fältström [mailto:paf at frobbit.se]
>> Sent: Thursday, January 29, 2015 2:16 PM
>> To: Daniel Karrenberg
>> Cc: Manal Ismail; internal-cg at icann.org
>> Subject: Re: [Internal-cg] Handling process complaints
>>
>> This makes to me a lot of sense.
>>
>> Our job is to produce an acceptable document.
>> [MI]: Agree ..
>>
>> Not fall into the trap of responding to questions that should in reality
>> have been sent to each one of the operational communities.
>> [MI]: I don't think anyone suggested that the ICG respond to comments
>> submitted .. The suggestion was forwarding them to the relevant operational
>> communities which I thought to be non-controversial, and consider their
>> response ..
>>
>> In most cases it is probably the case that the question in reality
>> already have been taken care of, according to whatever process that
>> specific operational community have. Including appeals (or similar
>> arrangements).
>> [MI]: Fair enough .. this would be an equally informative response to
>> receive from the relevant operational community ..
>>
>
> Of course we will observe what the OCs do with comments about the
> substance of their responses or their procedures. If we determine that
> action by an OC is needed we can decide to request it, via our normal
> process.
>
>
>> We should stay by following our process and do our work and answer
>> questions on our process.
>> [MI]: Fair enough .. but our process allowed for receiving comments ..
>> and we should agree to either forward all, or forward none, or if we are to
>> forward some then at least this has to be based on some agreed criteria ..
>> If I recall correctly, we have already forwarded one ..
>>
>
>
> We should point out the forum to the OCs and the world. We should not
> respond to or forward any comments via an automatic procedure. We should
> read all the comments. We should take action on the substance from comments
> that we consider relevant for producing an acceptable document. Each one of
> us can raise substance from a comment. We take action based on our process.
> We do not need a new procedure for that.
>
>
>>     Patrik
>>
>>  On 29 Jan 2015, at 12:15, Daniel Karrenberg <daniel.karrenberg at ripe.net>
>>> wrote:
>>>
>>>
>>> Manal, colleagues,
>>>
>>> let me explain why I believe we should not define detailed procedures
>>> for dealing with comments, and please let us not call them complaints and
>>> let us also not limit our discussion to comments about the processes used
>>> to create input to our process.
>>>
>>>  [MI]: Just to note that I agree .. we should not complicate things, but
>> the suggestions was agreeing on few steps to be followed for EVERY comment
>> received .. Also your valid point regarding complaints have been noted and
>> corrected in the shared draft ..
>>
>>  This is somewhat longer than usual, because I take a substantially
>>> different position from what I sense our general "mood" is. All that I ask
>>> is that each of us hears this argument before we proceed with what may feel
>>> comfortable now but could be quite unpleasant in the long run.
>>>
>>>
>>> Principles:
>>>
>>> Our single task is to produce a proposal document. The one requirement
>>> for this document is that it will be acceptable to the Internet community
>>> and in particular to NTIA and the operational communities. In other words:
>>> we need to come up with a document that has sufficient support to get
>>> implemented. NB: All other properties of the document, such as that it
>>> results in a working arrangement etc. etc. derive from the acceptability.
>>>
>>> Our task is not to respond to all, or even to any, comments made to us.
>>> Our task is not to treat everyone equally. Our task is not to be an appeals
>>> body for community processes, nor is it to arbitrate in conflicts arising
>>> from the process of providing input to us.
>>>
>>> Again: Our task is to compose a document that will be acceptable to
>>> NTIA, the operational communities, others directly involved and the
>>> community at large in that order of priority.
>>>
>>>
>>>  [MI]: Please refer to my reply to Patrik .. In addition, although "Our
>> task is not to treat everyone equally" yet it is important that we ensure a
>> trustworthy and credible process .. Frankly, I wouldn't prioritize
>> acceptance of the document and glad the NTIA indicated that "the transition
>> proposal must have broad community support" ..
>>
>
> We have to produce a document that is acceptable to all relevant parties. I
>
>>
>>  Requirements & Process:
>>>
>>> We have derived a number of requirements from the principles in order to
>>> receive input that will enable us to produce a document that is acceptable.
>>> We are currently executing a process that checks whether these requirements
>>> are met by the input we have received up to now from two operational
>>> communities. During this process we receive comments via a variety of
>>> channels. The only important thing about processing these comments is that
>>> we deal with all those that point out reasons why our final document may
>>> not be acceptable or how it can be made more acceptable. Anything else is a
>>> distraction from our task.
>>>
>>
>> [MI]: I agree that we may need to deal with certain comments and that why
>> I included this " unless the ICG decides that there is need for further
>> communication with the sender and/or the relevant operational community. "
>> but was suggesting that anything else should still be forwarded to the
>> relevant operational community ,,
>>
>>
>>> We have also agreed and stated forcefully that input on both substance
>>> and process for the community proposals should be treated within the
>>> respective community process. We have further agreed and stated that we
>>> will refer comments made to us to the respective community. There are a
>>> couple of good reasons for this and we should change that position.
>>>
>>>  [MI]: Agree .. no change in position ..
>>
>>  Again: we need to address as a group all those comments that in our
>>> judgement raise a point that needs to be addressed in order to make our
>>> document acceptable to NTIA, the operational communities, other directly
>>> involved parties and the Internet community at large. We do not need to
>>> address any other comments, or even respond to any comment.
>>>
>>>  [MI]: Again, the suggestion is not for the ICG to address all comments
>> but for the ICG to forward all comments to the relevant operational
>> communities ..
>>
>>
> We do not need a procedure for that. We do not even need to forward the
> comments. We just need to point out the forum. If any of us gets the
> impression that an OC is ignoring a relevant comment, they can informally
> tell the OC. If there is still no action and the ICG decides that the
> substance is relevant, the ICG can decide to request action from the OC.
>
>  Making detailed procedures bears the significant risk of wasting time and
>>> energy in meta-discussions that are not needed because we do not need the
>>> procedures in the first place. More importantly it bears the risk that
>>> these procedures will be abused against us or that we loose credibility by
>>> running afoul of them unintentionally or even only allegedly.
>>>
>>>  [MI]: no complex procedure .. only a few straightforward steps (not
>> sure I understand the last sentence)
>>
>
> Sorry, that sentence is not really plain English. I sometimes still write
> for my very British English teacher instead of the intended audience. ;-)
> Let me try to say it more clearly:
>
> If we make a procedure we have to stick to it, absolutely. An adversary
> can abuse this because they know what we are going to do. If we make a
> mistake, even an innocent one, our credibility suffers: "They are not even
> following their own procedures." That claim can even be made if we did not
> in fact make any mistakes as long as the adversary can create the
> perception that we did. All these risks come from the existence of the
> procedure. No procedure, no such risks.
>
> I agree with the remainder of your comments *if* we decide that we really
> have to forward comments to the OCs and that we need to have a procedure
> for that.
>
>
>>  Beyond these my personal experience suggests that the mere existence of
>>> a comment procedure encourages comments that would otherwise not be made
>>> because there was no guaranteed attention resulting from them.
>>>
>>>  [MI]: Agree but we've already allowed for providing comments on the ICG
>> forum ..
>>
>>>
>>> What we should do:
>>>
>>> 1) We should point out our forum to the operational communities and
>>> other directly involved parties and ask them to participate with their
>>> particular responsibility in mind. We should point out that comments in
>>> this forum have no special properties and each participant should treat
>>> them according to their own judgement and procedures.
>>>
>>>  [MI]: I tried to cover this by the footnote, which by the way could be
>> moved to the beginning of the document ..
>>
>>  2) We should direct comments that we receive via other means to that
>>> forum as much as possible in order to have them on the public record and
>>> subject to reaction for others.
>>>
>>>  [MI]: Agree
>>
>>  3) If any on us considers that the substance of a comment needs to be
>>> addressed by the ICG in order to ensure that our document will be
>>> acceptable, they should raise that substance in our deliberations and
>>> suggest an action we should take. Possible actions I can imagine are: amend
>>> a draft of our document, ask an operational community to consider the
>>> question and amend their input to us, ask an operational community to
>>> respond to a comment about their process, respond to a comment about the
>>> ICG process.
>>>
>>
>> [MI]: Agree .. and this is the reason for this sentence "unless the ICG
>> decides that there is need for further communication with the sender and/or
>> the relevant operational community. "
>>
>>>
>>> 3a) This means it will take one of us to raise a question from a comment
>>> for us to address it. No comments will be automatically addressed. There
>>> will be no "due process" other than our normal ICG process. It also means
>>> that all comments are treated absolutely equal.
>>>
>>>  [MI]: Nothing automatically addressed but all automatically forwarded ..
>>
>>  3b) If we remain concerned that we might miss comments that may lead to
>>> our document not being acceptable, we can delegate some of us to
>>> specifically watch the forum and bring questions that might affect the
>>> ultimate acceptability of our document to us.
>>>
>>>  [MI]: No problem .. although I'm always in favor of having as many ICG
>> members as possible participating to any task ..
>>
>>
>>> What we should not do:
>>>
>>> We should not define a process for dealing with comments. We should rely
>>> on our existing process and on our individual judgement to raise relevant
>>> questions and our collective judgement to address them.
>>>
>>>  [MI]: Maybe process was not the right word at the first place ..
>> forwarding comments is not mutually exclusive with " rely on our existing
>> process and on our individual judgement to raise relevant questions and our
>> collective judgement to address them "
>>
>> [MI]: Sorry for the long email but I just felt obliged to respond to all
>> points in your message and like you said just to hear each other's
>> arguments before we proceed ..
>>
>>
> No need to apologise. I started the long message thread.
>
>
> Daniel
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20150131/efb8d664/attachment-0001.html>