<div dir="auto">Hi Jordi,<div dir="auto"><br></div><div dir="auto">Thank you for the detailed answers. I accept the phasing point — implementing one check at a time is normal — and I am not asking the policy to schedule development or to pre-determine bug fixes. I also accept that the appendix is not intended as policy text.</div><div dir="auto"><br></div><div dir="auto">That last point is why I am following up, because it changes what is left.</div><div dir="auto"><br></div><div dir="auto">If sections 6 and 7 and the appendix are not policy text, the operative proposal is items 1–4. The only enforcement sentence is item 4: on "evidence suggesting that there is lack of compliance", AFRINIC "is able to initiate a more exhaustive investigation and take further actions (such as service withholding, revocation or even member closure)", following the RSA/bylaws prerogatives. You have also confirmed that the thresholds for manual investigation are unchanged and that the proposal deliberately creates no procedure, because that is a staff/board decision.</div><div dir="auto"><br></div><div dir="auto">In the notifications item the operative rule is that notifications go to members and staff "as soon as a possible non-compliance is detected, showing previous history if available". You have added that the exact notification text is left to staff so that they are not "mandated to that text", and that the "continued" qualifier was removed from the normative text.</div><div dir="auto"><br></div><div dir="auto">So the operative effect is: a member is recorded and staff are alerted on an automated possibility, with history included on an availability test, while the procedure that determines what follows is outside the policy. That reverses the structure you describe — the obligations are inside the text and the safeguards are outside it. The earlier version required staff to define and publish a procedure to ensure fair treatment of all members; DRAFT02 does not, and you have confirmed no procedure is created.</div><div dir="auto"><br></div><div dir="auto">Three questions:</div><div dir="auto"><br></div><div dir="auto">1. Which text is normative? If 6 and 7 are examples, they should be moved out of the block labelled "Proposed", or expressly marked non-normative, before Last Call. If they are normative, then the publication step, the NS-record removal, the holder-record deletion, the "more than 3 confirmed violations happen in a 12 months timeframe" trigger and the staff-set "severity graduation" still need the objections raised on 2 October answered. As it stands, the community cannot tell which document it is being asked to adopt.</div><div dir="auto"><br></div><div dir="auto">2. What governs the notification content, including "previous history"? You have said staff decide the text and can change it over time. Then the only test the policy itself contains for including history is "if available" — availability, not relevance. A record kept for audit and re-displayed in an unrelated notification serves a different purpose from the one it was kept for. Will the published procedure required by CPM 3.2.2 state the relevance test, and will it be published before Last Call?</div><div dir="auto"><br></div><div dir="auto">3. Does an unconfirmed automated finding — including one from a feature still in "beta" — enter "previous history", and the count? You mentioned beta features. Nothing in the text excludes unfinished check output from the notification or from the record.</div><div dir="auto"><br></div><div dir="auto">Changes I would support:</div><div dir="auto"><br></div><div dir="auto">- In item 3: notification to the member on a possible finding; the notice states that no determination has been made; historical information included only where necessary and relevant to understand or correct the finding, identified by source, date and current disposition; automated findings not confirmed under item 4 excluded from the history.</div><div dir="auto">- In item 4, or a new item: no adverse decision may rely on dashboard information unless the applicable CPM or RSA provision is identified, the facts established are stated, and the notice, response and appeal provisions of the RSA and Bylaws have been observed; the published implementation procedure exists before any adverse decision relies on dashboard information.</div><div dir="auto">- In item 2: state the position under CPM 3.4.5, and list the initial set of checks in the policy. Any later check, or any change of a criterion or threshold that creates or widens an obligation, should come back through the PDP.</div><div dir="auto"><br></div><div dir="auto">I am not asking the policy to describe your development process, and I am not asking it to fix bugs. I am asking it to state the rules that decide whether a member is compliant, because those rules are what the community is being asked to approve. I oppose the proposal as drafted until that is resolved.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Nonjabulo</div></div>