{i'm starting a new thread. Source :
<https://lists.afrinic.net/pipermail/rpd/2019/009601.html>}
Hi all,
...Please see below (inline).
Le 6/25/2019 à 9:09 AM, JORDI PALET MARTINEZ a écrit :
>
> See below, in-line.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
> El 25/6/19 1:21, "Sylvain BAYA" <abscoco at gmail.com
> <mailto:abscoco at gmail.com>> escribió:
>
>
>
> [...]
>
> ...not sure if we can do it so simple as you want it ; but...we should
> try ;-)
>
> * I think we may use this one, which is a very simple change, and I
> hope everybody in the community will be happy to accept as a
> “trial”. I’m not suggesting at this time to use it for other
> policy proposals. If it works, in the future we can consider a PDP
> change to allow policies to go thru the mailing list without the
> need to wait for the meeting (as we do in IETF and RIPE). It is up
> to the chairs at this time to accept it and the community to
> decide on this small change then.
>
Jordi, thanks for your very kick response :-)
...as it was, i still believe it can not *correctly* fix our problem (i
may be wrong), and of course it's not just about the *simplicity* ; it's
first about having a workable solution which could address most of the
known issues. I have observed that it appears to try to get thing done
by simply officialising the *agreement* the Chairs concluded with the
Staff.
But what do i think that was missing :
- I think, as it was, it does not guarantee us to have a timely Impact
Analysis Report (IAR) for all versions (particulary intermediary ones)
of any policy proposal {not really a big issue for me ; because it would
be acceptable to have at least an IAR, even only, for the first version
and for the last version of a proposal published before the PPM (Public
Policy Meeting) and at least a week before the deadline (TBD | To Be
Defined to better fit) of the publication of all IARs}.
- It also miss to provide the possibility, for the Chairs, to request
for an IAR (as the CPM section 3.4.1 actually allows it), for an
intermediary new version of a given policy proposal ; where the
community agrees there is a need for an IAR.
- That text was giving to the Staff the rights to provide only one IAR,
even if an author publish more than three (very impacting) versions of a
proposal in five month between two PPM. {this could be a good point
depending on which side you stand : Staff or Community.}
> I’m proposing you the following and I’m doing it openly in the
> list, so others can provide inputs as well.
>
>
>
> I agree, let's discuss openly to collect any available input :-)
>
>
>
> According “3.6 Varying the Process”, for that we need a
> **co-chair** to accept it. Any taker?
>
>
>
> This is the variance that I’m proposing:
>
> 1) Publish officially the policy proposal and start a 4-weeks
> for community discussion.
>
> 2) If after that, the chairs believe there is consensus,
> last-call for 4-weeks.
>
> 3) If there is no-consensus, allow to repeat the process,
> maximum up to one month before the next meeting (then there is no
> need for the variance of the process).
>
>
>
> 4. This Variance decision shall take effect one month after its
> publication on the PDP list.
>
> -> not sure what do you mean here. Once the chairs accept it, the
> policy proposal can be submitted and published in a few days. There
> will be 4-weeks (I think is sufficient for this case but I’m happy for
> more) for discussing. So why 4 more weeks are needed? We want to keep
> it simple, if we start discussing about the variance itself, we may
> never have go thru it …
>
> 5. That first month after the publication of the Variance decision
> shall serve to prepare the commuty before the effective start point of
> the cycle of variance.
>
> -> Now I see it, but I don’t think is needed. We are already talking
> about it, community should be reading (those not reading now will not
> read later … according to my experience, and anyway, they have several
> weeks to discuss), and it may take several days for the chairs to
> decide, then to prepare a policy proposal document, then to publish
> it, and finally for a formal announcement of the process. The chairs
> may decide to just use 6 weeks or 8 instead of 4. Whatever they decide
> I’m ok with that.
>
Thanks, for your explanation, i understand now why it's not necessary to
delay the starting point of the variance period.
> *Question* : where to store this Variance decision and its future
> successors ?
>
> ...to what i understand, when published it becomes part of the PDP and
> supersides all existent concurrent texts which might conflict with it.
>
> -> there is no difference between how a policy proposal is handled,
> same process versus a normal one (web page, presentation in the next
> meeting if reached consensus, minutes, etc.).
>
:-/ not sure if you are speaking about the *variance decision* taken by
the Chairs or about the policy proposal (IAR Timely Disponibility) under
the *variance of the process*. I'm ok with the PDP for the latter, but
my question was about the first.
> *A Proposed Answer*
>
> With the CPM section 3.6, can we conclude that it's not possible to
> alter the CPM to insert|store the variance decision ? (perhaps we
> should also prepare a policy proposal to amend the CPM section 3.6 :-/)
>
> I have an idea, i'm not sure it could work fine. But let's give it a
> try please :-)
>
> ...so when the Chairs annonce a new variance of the CPM, we can tag
> the title of all the section affected by the new variance decision by
> something like [SUPERSIDED by Variance in Place ; see Section 3.6.1] :
>
> + We leave the actual texts of any affected sections as it is :
>
> + Just add a special tag with a small text to the title ?
>
> Like this : [SUPERSIDED by the Varying in Place ; see section 3.6.1]
>
> + Title the section 3.6.1 by : Active Variance Process Decisions
>
> + Paste the variance decision at the section 3.6.1. (new sub-section)
>
> + Remove the content of the section when the Variance Decision expires.
>
> I don’t think this is needed and this makes it very complex, as it
> means we must change the PDP before processing this variance …
>
...i also hope it is not needed, Jordi. But please also considere that
the Staff has less than six months (CPM section 3.4.5) to implement a
new policy, then they would be able to insert the new change (to the
CPM, if needed) once the ratification from the BoD (CPM section 3.4.4).
As we have the opportunity to use the *variance* for the first time, i
wanted to share my concerns and i added a possible solution. But i'm ok
to use it (as you proposed it) first ; then come back at the end of the
*variance period* for a thorough appraisal.
> ***
>
> ACTUAL text (at 3.4.1):
>
> The Working Group Chair(s) may request AFRINIC to provide an
> analysis (technical, financial, legal or other), of the impact of
> the draft policy proposal.
>
>
>
> DRAFT proposed text (replace the previous text):
>
> AFRINIC will publish an impact analysis (technical, financial,
> legal or other) at least 10 days before the next Public Policy
> Meeting. If justified, in case of extremely complex new policy
> proposals, AFRINIC will publish at least a draft version of the
> impact analysis.
>
> ***
>
>
>
> As discussed before, the problem to solve is too complex. To handle
> most of the complexity, i propose this text instead :
>
> *** DRAFT proposed text (replace the previous text):
> * The AFRINIC Staff publish (website and RPD mailinglist) an impact
> analysis report during the first week after a new policy proposal is
> published.
>
> * When a new version of a policy proposal is published, on request of
> the Chair(s) or the Author(s), the Staff publish a new impact analysis
> report, during the first week after the publication of that policy
> proposal version.
>
> * No impact analysis report should be published ten (10) days before
> the next Public Policy Meeting.
>
> * If justified, in case of extremely complex new policy proposals,
> AFRINIC Staff publish at least a draft version of the impact analysis
> report.
>
> * An impact analysis report shall be of one or both following types
> : technical, financial, legal or other.
> *** END
>
> -> I think you’re making it extremely complex without a real need for
> that. Keep it simple and “short”. Some impact analysis need much more
> time than a week. Just let’s make sure we have it ahead of the
> meeting. 10 days allows the authors, if they are quick, to publish
> immediately a new version (within the 1-week deadline before the
> meeting), in case minor issues discovered by the impact analysis (I’ve
> done that in a couple of cases!). The impact analysis already includes
> all that, no need to mention it.
>
...again, i have no problem with simplicity (yes it still a difficult
exercise for me to write short texts which would take into account
complex considerations. I admit to need some help here) ; however i
don't see (IMHO) simplicity and shortness as the similar things. Your
explanation is awaiting.
> -> This will only work if we make it extremely simple and acceptable
> for all the community. I’m happy to change the 10-days before the
> meeting to 2-weeks, for example. See a new version below.
>
...now i ask you to explain me how your actual text can deal with all
these points i listed on top of this mail. As soon as you confirm me
that it taking into account these basic requirements it will be seen as
a sustainable draft policy proposal which can correct the problem we
actually faced with the IARs.
> * DRAFT proposed text (replace the previous text):
>
> AFRINIC will publish an impact analysis (including technical,
> financial, legal and other aspects) as soon as possible for each
> policy proposal submitted (as a maximum 2 weeks before the next Public
> Policy Meeting). When duly justified, in case of extremely complex new
> policy proposals, AFRINIC will publish meanwhile a draft version of
> the impact analysis.
>
...i can live with this version, better than the previous. But, please,
can you check it once more against the basics requirements i listed on
the near top of this mail ? ;-)
Thanks & Shalom,
--sb.
> This small change in our PDP will prove ourselves that AFRINIC
> community is able to pro-actively discuss and pass policy
> proposals in the list.
>
>
>
> What do you think?
>
>
> I agree that we are doing a good job (thank GOD), together, and
> hopefully some other will follow this challenging approach.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> [...]
>
--
Regards,
Sylvain B.
<http://www.chretiennement.org>
__
Website : <https://www.cmnog.cm>
Wiki : <https://www.cmnog.cm/dokuwiki>
Surveys : <https://survey.cmnog.cm>
Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Last Event's Feed : <https://twitter.com/hashtag/cmNOGlab3>
<https://twitter.com/cmN0G>
<https://facebook.com/cmNOG>
<https://twitter.com/hashtag/REBOOTcmNOG>
<https://twitter.com/hashtag/cmNOG>
<https://cmnog.wordpress.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190629/65a42140/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x0387408365AC8594.asc
Type: application/pgp-keys
Size: 4826 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190629/65a42140/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190629/65a42140/attachment-0001.sig>