[rpd] New Proposal: Lame delegations in AFRINIC reverse DNS

[Seun Ojedeji]

Hello,

Normally I expect that staff analysis will follow soon enough which would
normally highlight among other things, the implementation possibilities and
implications (more in summary).

Regards

On Apr 14, 2017 11:55, "David Hilario" <d.hilario at laruscloudservice.net>
wrote:

>
> Hi Daniel,
>
> Thanks for the reply.
>
> I do support the end goal of this policy proposal, I just want more
> information.
>
> On Apr 13, 2017 11:50 PM, "Daniel Shaw" <daniel at afrinic.net> wrote:
>
>
> > On 13 Apr 2017, at 23:18, David Hilario <d.hilario at laruscloudservice.net>
> wrote:
> >
> > As long as it is guaranteed to be 100% automated, so that once
> > implemented it does not take any operational manpower from AFRINIC
> > staff in tracking, notifying and updating, I am in support.
>
> Hi David,
>
> Thanks. As this question speaks to the implementation by staff, it would
> be challenging for the authors to be able to guarantee as part of the
> policy. However, the authors’ expectation when writing this proposal was
> that indeed this would be automated.
>
>
> The benefit for the community must not impact the already strained
> resources of AFRINIC staff, comments from AFRINIC ltd on how they would
> expect to handle such a mandate would indeed be appreciated.
>
> Such a policy could require either extra staff, or add further load on
> current staff, the net benefit of hunting down bad RDNS would be outweigh
> by either prospects.
>
> A simple and extreme example to showcase my reluctance of providing
> support without some implementation grantees.
> Let's say we have a policy proposal that demands that AFRINIC ltd verifies
> all postal address provided in the AFRINIC Database, with no clear
> implementation guidelines and the policy gets approved.
>
> AFRINIC decides that the best way to do this is to physically go to each
> location, therefore needs to hire 100 persons, and triple the membership
> fees of the LIRs.
>
> This is why a somewhat guarantee of automation and limitation in the
> implementation would be needed for me to support the policy without any
> reservations.
>
>
>
> > How would the historical information be provided?
> > Would making deleted domain object visible through the whois query
> > "--show-version " be an option?
>
> The authors also leave this to the implementing staff to decide. However
> we do believe the policy should have *some* way to get the history, be that
> via WHOIS port 43, My.AFRINIC or some other interface entirely. Or some
> combination.
>
>
> A bit more guidelines would be good here as well.
> This leaves AFRINIC staff open to criticism in case people do not like the
> final implementation.
>
> I anyway do not even really see a need for that info to be provided.
> If name servers are removed but the domain object is still present,
> historical info is available via whois queries as long as the object is not
> deleted from the Database.
>
> If the full object is removed, the maintainer etc, should had received a
> notification from the automated system with a copy of the object from the
> hopefully automated notification system prior to the deletion.
> And should again receive some form of notification from the database with
> a copy of the object once it is deleted.
>
> You can skip that part of the policy proposal as the vast majority of the
> affected users would have no need for it anyways and would had received the
> information in one form or another during the process.
>
>
>
>
> Regards,
> Daniel
> co-author
>
>
> Regards,
> David
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170414/cb59bca1/attachment.html>