<div dir="auto">Hi Nishal,<div dir="auto"><br></div><div dir="auto">It all sounds good :)</div><div dir="auto">Automation is the way to go for these thing.</div><div dir="auto"><br></div><div dir="auto">But sometimes people choose the hard road for whatever reason, usually because it is easier at first.</div><div dir="auto">I just want to make sure we don't later hear that SLC is breached due to too much time spent on this policy once implemented.</div><div dir="auto"><br></div><div dir="auto">Just out of curiosity:</div><div dir="auto"><br></div><div dir="auto">A:</div><div dir="auto">How many domain objects are fully broken?</div><div dir="auto"><br></div><div dir="auto">B:</div><div dir="auto">How many have only one working Nserver?</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">David</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Apr 14, 2017 2:41 PM, "Nishal Goburdhan" <<a href="mailto:nishal@controlfreak.co.za">nishal@controlfreak.co.za</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 14 Apr 2017, at 12:51, David Hilario wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel,<br>
Thanks for the reply.<br>
<br>
I do support the end goal of this policy proposal, I just want more<br>
information.<br>
</blockquote>
<br></div>
hi david,<br>
<br>
of course; as we said initially, we expect there to be an interesting thoughts on how to implement, and that’s why we produced a *sample* guideline [1]. but discussing implementation is not the same as discussing policy, and this list if for policy. so that’s why we’d prefer to not take up airspace here, discussing implementation. (well, we’re guided by the PDPWG co-chairs in this, so if you’d prefer us to .. ??)<br>
<br>
i don’t think it’s possible for afrinic to give you concrete implementation steps and 100% guarantees, without a ratified policy, so, while i think it’s reasonable to have you concerns about this taking up staff resources, might i suggest we let afrinic respond to that as part of the “staff assessment” part of the process, which, i guess, would come up closer to the meeting date. i’m trusting that the afrinic team working on policy has taken your concerns to heart, and will respond accordingly.<br>
<br>
on a personal level, i’d state support for what you wrote about automation; i don’t believe this should be done manually, and i trust the afrinic team that implements this, are intelligent enough to do that, since the addition process is already automated ;-)<div class="quoted-text"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let's say we have a policy proposal that demands that AFRINIC ltd verifies<br>
all postal address provided in the AFRINIC Database, with no clear<br>
implementation guidelines and the policy gets approved.<br>
</blockquote>
<br></div>
in the interests of keeping this discussion on-topic, might i ask that we *not* introduce theoretical discussion around items that this policy does not try to introduce. it’s very tempting to add analogies, and stories, but the risk is that they are often hyperbolic, or incorrect (there’s another thread running, that should help make my point :-)) i think that we are all capable enough of discussing *what the text says*.<br>
your example is interesting, and might be text for a future policy :-) but spending cycles talking about that, and not the *one single goal* (see the problem statement) that we have tried to focus on here, is not our intent.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How would the historical information be provided?<br>
</blockquote></div>
A bit more guidelines would be good here as well.<div class="quoted-text"><br>
This leaves AFRINIC staff open to criticism in case people do not like the<br>
final implementation.<br>
<br>
I anyway do not even really see a need for that info to be provided.<br>
If name servers are removed but the domain object is still present,<br>
historical info is available via whois queries as long as the object is not<br>
deleted from the Database.<br>
</div></blockquote>
<br>
nishal@jnb:~$ whois -t domain <a href="http://whois.afrinic.net" rel="noreferrer" target="_blank">whois.afrinic.net</a><br>
[snip]<br>
domain: [mandatory] [single] [primary/lookup key]<br>
descr: [optional] [multiple] [ ]<br>
org: [optional] [multiple] [inverse key]<br>
admin-c: [mandatory] [multiple] [inverse key]<br>
tech-c: [mandatory] [multiple] [inverse key]<br>
zone-c: [mandatory] [multiple] [inverse key]<br>
nserver: [mandatory] [multiple] [inverse key]<br>
[snip]<br>
<br>
domain objects can’t exist without nserver field, as the nserver field is mandatory, so the domain object would have to be deleted.<div class="quoted-text"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the full object is removed, the maintainer etc, should had received a<br>
notification from the automated system with a copy of the object from the<br>
hopefully automated notification system prior to the deletion.<br>
And should again receive some form of notification from the database with a<br>
copy of the object once it is deleted.<br>
</blockquote>
<br></div>
my understanding is that writes in/out of a database can be tracked, so there’s already means to track this information.<br>
i think your suggestion is a good one; this is what the suggested implementation plan reads :<br>
<br>
+----------+------------+----<wbr>------------------------------<wbr>---------+<br>
| Timeline | Event | Actions |<br>
+----------+------------+----<wbr>------------------------------<wbr>---------+<br>
| Day 0 | Lame | Lame delegation is recorded. Nameserver |<br>
| | delegation | is re-tested for lame delegation every 3 |<br>
| | is first | days. |<br>
| | detected. | |<br>
| Day 15 | Delegation | A remark is added in the domain object |<br>
| | is still | for the lame nameservers. Email |<br>
| | detected | notification is sent every 5 days for |<br>
| | as lame | another 15 days (3 notifications) to |<br>
| | (after 5 | "Admin-C", "Tech-C" and "Zone-C" |<br>
| | additional | contacts. Lameness checks are still run |<br>
| | checks). | every 3 days. If a nameserver is not lame |<br>
| | | anymore, the corresponding remark is |<br>
| | | removed. |<br>
| Day 30 | Delegation | The "nserver" record is removed from all |<br>
| | is still | "domain" objects containing it. Any |<br>
| | lame. | "domain" object that thus has zero |<br>
| | | "nserver" records, is removed from the |<br>
| | | WHOIS database. "Admin-C" and "Tech-C" |<br>
| | | contacts are notified of all changes. In |<br>
| | | all instances the original "domain" |<br>
| | | object is archived. |<br>
+----------+------------+----<wbr>------------------------------<wbr>---------+<br>
<br>
2.3.3. Object Archival<br>
<br>
All nameserver records and domain objects removed from the visible<br>
WHOIS database should be viewable on the MyAFRINIC portal for a<br>
period of 90 days. After 90 days, the archived version will be<br>
discarded permanently.<br>
<br>
<br>
is this something that you think should be in the actual policy text?<br>
if not, we’d happily accept a pull request to the implementation plan text.<br>
<br>
as a reminder, the sample implementation plan is how we *think* this could be done, and this is a *hint* to the afrinic team in how/what to implement.<br>
<br>
—n.<br>
<br>
[1] <a href="https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-draft-00.txt" rel="noreferrer" target="_blank">https://raw.githubusercontent.<wbr>com/techdad/afpub-2017-lame-dn<wbr>s/master/sample-implementation<wbr>/afpub-2017-lame-dns-sample-<wbr>ops-manual-draft-00.txt</a><br>
</blockquote></div><br></div>