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

[Arsène Tungali]

Hi all,

At this stage, i think i love this proposal. 

But i am not sure what's next once the policy has been approved by community members (with the provision to have staff clarify some implementation aspects). 

Will staff have an opportunity to comment and bring it back to the community to decide whether we agree with that way of doing? If this is the process, then i support the proposal.

Thanks,
Arsene

-----------------
Arsène Tungali,
@arsenebaguma
+243 993810967
GPG: 523644A0
Goma, Democratic Republic of Congo

Sent from my iPhone (excuse typos)

> On Apr 14, 2017, at 1:52 PM, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
> 
> 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
> _______________________________________________
> 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/3d227bca/attachment-0001.html>