Re: [sig-policy] prop-134-v001: Secretariat impact assessment

  • To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
  • Subject: Re: [sig-policy] prop-134-v001: Secretariat impact assessment
  • From: Adam Gosling <email@adamgosling.com>
  • Date: Tue, 18 Feb 2020 12:17:29 +1000
  • Cc: mailman_SIG-policy <sig-policy@apnic.net>
  • Delivered-to: sig-policy@clove.apnic.net
  • In-reply-to: <8DE93564-AFC2-45FA-9A59-F9B36A29717B@consulintel.es>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <3856441B-29EA-4CE5-92FE-DC475FE4FAA4@consulintel.es> <CAF18598-2AF3-442C-AE36-B495E1502134@adamgosling.com> <8DE93564-AFC2-45FA-9A59-F9B36A29717B@consulintel.es>

    • Hi Jordi

      Sorry, but I have a very close knowledge of these documents. They are not perfect (or even good). Everybody may not always understand them, or apply them. That is why I want to make sure people understand what it is they are changing from and what they are changing to.


      On 17 Feb 2020, at 1:30 pm, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

      Hi Adam,
       
      -> The first problem we have here is that those guidelines were developed long time ago (2 decades or so), when we had many SIGs, and they were developed by the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t mention anything about the guidelines.

      Then propose that we add a reference to the Guidelines into the PDP. We can easily reach consensus and move on.

      This is not a mere editorial comment, it requires the community to accept those guidelines in a modification (thru a policy proposal) of the PDP. The third problem is that the PDP talks about “general agreement”, while the guidelines talks about “consensus”. It is a matter of English wording? I don’t know, but making it clear is good for everyone. Otherwise a newcomer will not see in the meeting that we are following our own process (because we aren’t!).
      -> If I recall correctly, when asked at least one of the co-chairs about what they recognize as consensus, and I believe is the way they explain at the beginning of each Policy SIG, they use the rough consensus definition and I’m almost sure they even mention the IETF RFC.

      The only reference Google finds to RFC7282 on the www.apnic.net or conference.apnic.net site is your presentation 

      I checked the slides presented at the beginning of APNIC 46 and 47. These explain Consensus = ‘general agreement’ and the concept of Minor and Major Objections. They also provide the URL for the PDP and SIG Guidelines.

      Anybody that says APNIC Policy runs on ‘rough consensus’ has made an assumption or is using the phrase to make it easier for you to understand to idea of 'general agreement'.


       
      The RFC is similar, but fundamentally different. Changing this in the PDP is not just a word tweak. It would result in a different approach from the Chairs and participants. There is no concept of “Minor” and “Major” objections in RFC 7282, for example.
      -> The RFC doesn’t provide the “operational” details, it is an informational document, so nothing precludes the co-chairs for their assessment to still make some “classification”, but again,  the guidelines aren’t part of the PDP, unless we change it. I think they key here, and again, I believe is the understanding of the chairs, if I got it correctly, we aren’t counting hands or votes, but instead we declare consensus “when all the issues are addressed, but not necessarily accommodated”, which is the “short” description of the RFC.

      My reading of the Guidelines and the practice I have noticed from past Chairs is that Minor Objections can be 'addressed but not necessarily accommodated'. For Major Objections the guidelines say "When this happens, the Chair should encourage the proponent and the community to continue discussion and develop a more widely accepted proposal to be presented at the following meeting.” 

      I’m not saying that it is bad to change. I am just saying that we should be aware of what change we are making.


      If there is no consensus on a proposal, the authors can decide to
      withdraw it.

       
      This removes discretion from the Chair (and the SIG), to abandon a proposal if an Author repeatedly persists with the same unpopular idea. I think that’s interesting and worth discussing if that’s what we want.
       
       
      -> Which I think is wrong. It is inappropriate (in my opinion) that (and it may be again an English understanding) chairs can “abandon” on behalf of the authors (I will understand “force withdrawal”). If there is an unpopular idea, the community will not reach consensus. That’s it. Instead, chairs can decide NOT allocate time in the agenda (if other newer proposals require more time) for a proposal that is not getting consensus after several attempts, but I think it has been demonstrated many times, that ideas that doesn’t work on the first round, may work after 3-4 consecutive rounds (because the lack of inputs in the list take much much much longer), and even sometimes, authors may decide not to continue, and after some years come back and then in works. This is normal, because all this is evolving all the time.

      I see your point. I still disagree and would prefer the Chair’s to have some right to put a stop to unpopular ideas that are presented over and over. An earlier Chair started the three strikes rule, which seems to have become the norm. (He also used to reference the Tao of IETF in his slides)

      This needs to be done carefully to stick to the policy. The Policy says; "The SIG will then discuss (either on the mailing list or in the SIG) whether to pursue the proposal or withdraw it.” So the SIG as a group can abandon work on a proposal. I interpret this to mean the Chair can propose that the SIG abandon work on a proposal (and not accept it idea back until circumstances change).

      You are within your rights to question such a decision. The Chair(s) should be willing to hear counter arguments or there is no consensus for their decision. I would say if the Chair abandons your proposal, you should respectfully seek public support on the mailing list to demonstrate that there is no consensus for their decision. They might reconsider.

      All this is very difficult if people do not participate. 


       
      -> Again, let’s see if there are further inputs and then makes sense to send a new version tomorrow maximum? However, even if I like it, the timing is not correct, as the proposal deadline is for new proposals, not for new versions, so it needs some tuning. Maybe:
      Otherwise, the proposal will be considered expired unless a new version incorporating feedback is provided before the next OPM relevant deadline, to restart the discussions

      As I said, I like the idea. I don’t feel strongly about the wording. The proposal deadline is the time the Chair sets the agenda. A new version can be submitted much later and they would not know whether or not to include the proposal that had ‘expired'.



       
      -> I still thing the guidelines aren’t useful neither have been ever approved by the community, and instead either we make a Task Force to update the PDP and incorporate the guidelines, or to update the PDP to refer to the guidelines *and* the guidelines get also approved following the PDP.

      Of course they are developed by the community. I wasn’t there for the formulation of the original SIG Guidelines, but I am pretty sure that any changes made to them in the last 12 years were made by the SIG community. These are not Chair or Secretariat guidelines. They are not a numbered document, but to the best of my knowledge, the practice has been that changes are owned by the community, reach consensus in all existing SIGs, and are run through the process outlined in the Document Editorial Policy.

       
      Jordi I think the issues you are raising are really important because it demonstrates that people are not all that familiar with the documents and what they mean. There is definitely room for improvement in the documents and the processes, but getting agreement is often difficult.

      Adam