Re: [DBWG] why can't i change role object? -- resolved

[Frank Habicht]

Hi all,

My problem was that (as a test whether i can modify the object) i tried 
to change the first line/attribute: "role".


this is a "lookup key" per [1] and can not be changed.
Changing other attributes works.

Thanks Keessun for your help!

We agreed that documentation might need improvements.


Have a good time  - and let's have the cables fixed soon

Frank
(no hat)


[1]
$ whois -h whois.afrinic.net -- -t role
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use. 
See https://afrinic.net/whois/terms


role:   [mandatory]  [single] [lookup key]
address:[mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]
e-mail: [mandatory]  [multiple]   [lookup key]
org:[optional]   [multiple]   [inverse key]
admin-c:[mandatory]  [multiple]   [inverse key]
tech-c: [mandatory]  [multiple]   [inverse key]
nic-hdl:[mandatory]  [single] [primary/lookup key]
remarks:[optional]   [multiple]   [ ]
notify: [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by: [optional]   [multiple]   [inverse key]
changed:[mandatory]  [multiple]   [ ]
source: [mandatory]  [single] [ ]




On 16/05/2024 07:20, Sylvain Baya wrote:

Dear DBWG,
Hope this email finds you in good health!

Please see my comments below, inline.
Thanks.

Le ven. 10 mai 2024 à 12:52 PM, Frank Habicht <mailto:ge...@geier.ne.tz>> a écrit :


Hi all,


Hi Frank,
Thanks for keeping the WG as active as you can, brother :'-(


I hope/trust that's not a question for "Support"...


...sure!
But, someone should explain how Policy
Manual have been used in building the
business rules behind implementation :-)


I tried to update/modify a role object, and got this (sorry for the
line
breaks):


What's the difference with other objects?

PII (Person Identifiable Information) risk?


***Error:   Person/Role name cannot be changed automatically. Please
create


...time to *automate* the process?


              another Person/Role object and modify any references
to the old
              object, then delete the old object



:-/ so the object's history would be lost?



I can't see a reason why 



...i don't also agree that:
'delete' right
is easily grantable than
'update' right

:-/ ...i would have understood a kind of
intent implementation of a "protect *new created* objects in order to 
avoid an  accidental deletion" policy...


Such as:

"A WhoisDB object can only be deleted
after a *reasonable* amount of time; at least :
  $new_delete_prevent_time seconds"

->Protected object! please try again after
  $new_delete_prevent_time seconds;
in case you *really* need to delete it ;-)


updates to role projects should not be allowed.
I even think that's the main purpose

So, am I missing something?


Thanks,
Frank



PS: AfriNIC staff:
I got "Internal software error" when i wanted to delete
SNHT5-AFRINIC
less than 1 minute after creating it


...interesting behaviour :-\

< $new_delete_prevent_time?


wanted to delete it with the line
delete:         remove
added

according to
delete: 
under section "2.2.4 Deleting an object"
in
https://afrinic.net/press/197-database-afrinic-database-reference-manual- 
<https://afrinic.net/press/197-database-afrinic-database-reference-manual->

deleting without the comment worked.


Noted!
...by the way, have you first reproduced
your initial testing steps/constraints[*]?
:-)
__
[*]: (i) create an object; (ii) delete within a minute; (iii) ...


Can that section in that manual be reviewed?


For the *remastering* activity concerning
  the Whois Manual & documentation, it
should be done openly & collaboratively;
imho!

...it would be interesting to contribute on
it under a public/locally [.] accessible git
repository or a self hosted [.] wiki engine.
__
[.]: idea  or dot afrinic?



If google sent me to an outdated document, can we remove it?


...or simply versioned and archived?

Please see here [1] for appropriate facts.
__
[1]: AFRINIC's Factsheets
<https://afrinic.net/our-factsheets/ <https://afrinic.net/our-factsheets/>>




Thanks,
Frank



Shalom,
--sb.

--
Best Regards !

baya.sylvain [AT cmNOG DOT cm]
| "cmNOG's Structure"<https://www.cmnog.cm/dokuwiki/Structure 
<https://www.cmnog.cm/dokuwiki/Structure>> | "Douala-IX's IXP 
Manager"<https://ixpm.douala-ix.net/statistics/ 
<https://ixpm.douala-ix.net/statistics/>> |
"cmNOG's Surveys"<https://survey2.cmnog.cm <https://survey2.cmnog.cm>> | 

Re: [DBWG] why can't i change role object?

[Frank Habicht]

Hi Yogesh,

no, i think my expectation/requirement is different.

role object A is created for a specific purpose, say the "Hostmasters" 
at my employer.


we want to be adding new person contacts to the role object as new real 
people take up this role/join that team, and we want to remove persons 
from admin-c and tech-c as they leave the position or the company. I 
believe this flexibility - without changes in the objects referencing 
the role object - is the main benefit of role objects.


Specifically, i believe i want to use role objects in admin-c and tech-c 
of ORG objects.


however, the error message told me I can not modify the role object.
that left me confused.


Regards,
Frank



On 13/05/2024 10:54, Yogesh Chadee via DBWG wrote:

Good morning Mr. Habicht.

I wish to understand your expectations on this matter. I am thinking you 
want effect this type of change:


"nic-hdl X had role A, now nic-hdl X has role B."

Am I correct in my assumption?


Regards,

Yogesh


On 10/05/2024 15:51, Frank Habicht wrote:

Hi all,

I hope/trust that's not a question for "Support"...

I tried to update/modify a role object, and got this (sorry for the 
line breaks):



***Error:   Person/Role name cannot be changed automatically. Please 
create
    another Person/Role object and modify any references to 
the old

    object, then delete the old object



I can't see a reason why updates to role projects should not be allowed.
I even think that's the main purpose

So, am I missing something?


Thanks,
Frank



PS: AfriNIC staff:
I got "Internal software error" when i wanted to delete
SNHT5-AFRINIC
less than 1 minute after creating it

wanted to delete it with the line
delete: remove
added

according to
delete: 
under section "2.2.4 Deleting an object"
in
https://afrinic.net/press/197-database-afrinic-database-reference-manual-

deleting without the comment worked.

Can that section in that manual be reviewed?
If google sent me to an outdated document, can we remove it?


Thanks,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] why can't i change role object?

[Frank Habicht]

Hi all,

I hope/trust that's not a question for "Support"...

I tried to update/modify a role object, and got this (sorry for the line 
breaks):



***Error:   Person/Role name cannot be changed automatically. Please create
another Person/Role object and modify any references to the old
object, then delete the old object



I can't see a reason why updates to role projects should not be allowed.
I even think that's the main purpose

So, am I missing something?


Thanks,
Frank



PS: AfriNIC staff:
I got "Internal software error" when i wanted to delete
SNHT5-AFRINIC
less than 1 minute after creating it

wanted to delete it with the line
delete: remove
added

according to
delete: 
under section "2.2.4 Deleting an object"
in
https://afrinic.net/press/197-database-afrinic-database-reference-manual-

deleting without the comment worked.

Can that section in that manual be reviewed?
If google sent me to an outdated document, can we remove it?


Thanks,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] 1x whois server not responding

[Frank Habicht]

Hi Yogesh,

Yes, I believe it was restored the same day.


- the https://status.afrinic.net page didn't know
- I don't know if anyone in AfriNIC had noticed
- was it something that can happen again?

Thanks,
Frank


On 29/04/2024 14:02, Yogesh Chadee via DBWG wrote:

Dear Frank, All,

The service has been restored. Thank you.

Regards,

Yogesh

On 24/04/2024 08:54, Frank Habicht wrote:

Hi AfriNIC NOC,

in DNS for whois.afrinic.net IPs 196.192.115.21 and 
2001:42d0:2:601::21 are returned. (amongst others)


This might be the same host.

These IPs are responding to ping, but not to whois.

This might have started between 0:20 and 1:20 UTC

I believe the https://status.afrinic.net page is wrong to state that 
"WHOIS DB Queries" - whois.afrinic.net:43 are working.

I'd say they're working only 3/4

Please check.

Thanks,
Frank


[frank@fisi ~]$ date
Wed Apr 24 07:40:04 EAT 2024
[frank@fisi ~]$ date -u
Wed Apr 24 04:40:07 UTC 2024
[frank@fisi ~]$ ping -c 5 196.192.115.21
PING 196.192.115.21 (196.192.115.21) 56(84) bytes of data.
64 bytes from 196.192.115.21: icmp_seq=1 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=2 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=3 ttl=54 time=49.8 ms
64 bytes from 196.192.115.21: icmp_seq=4 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=5 ttl=54 time=50.0 ms

--- 196.192.115.21 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4055ms
rtt min/avg/max/mdev = 49.879/49.968/50.067/0.062 ms
[frank@fisi ~]$ whois -h 196.192.115.21 AS37084
[Querying 196.192.115.21]
[196.192.115.21]
[frank@fisi ~]$ ping6 -c 5 2001:42d0:2:601::21
PING 2001:42d0:2:601::21(2001:42d0:2:601::21) 56 data bytes
64 bytes from 2001:42d0:2:601::21: icmp_seq=1 ttl=56 time=49.6 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=2 ttl=56 time=49.2 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=3 ttl=56 time=49.0 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=4 ttl=56 time=49.5 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=5 ttl=56 time=49.3 ms

--- 2001:42d0:2:601::21 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4054ms
rtt min/avg/max/mdev = 49.089/49.359/49.613/0.239 ms
[frank@fisi ~]$ whois -h 2001:42d0:2:601::21 AS37084
[Querying 2001:42d0:2:601::21]
[Unable to connect to remote host]
You have new mail in /var/spool/mail/frank
[frank@fisi ~]$ date -u
Wed Apr 24 04:49:13 UTC 2024
[frank@fisi ~]$ dig whois.afrinic.net. +short
whois-public.afrinic.net.
196.192.115.21
196.216.2.21
196.216.2.20
196.192.115.22
[frank@fisi ~]$ whois -h 196.192.115.22 AS37084
[Querying 196.192.115.22]
[196.192.115.22]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of 
Use. See https://afrinic.net/whois/terms


% Note: this output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to 'AS37084'

% No abuse contact registered for AS37084

aut-num:    AS37084
as-name:    simbanet-tz
descr:  Simbanet (T) Ltd

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] 1x whois server not responding

[Frank Habicht]

Hi AfriNIC NOC,

in DNS for whois.afrinic.net IPs 196.192.115.21 and 2001:42d0:2:601::21 
are returned. (amongst others)


This might be the same host.

These IPs are responding to ping, but not to whois.

This might have started between 0:20 and 1:20 UTC

I believe the https://status.afrinic.net page is wrong to state that 
"WHOIS DB Queries" - whois.afrinic.net:43 are working.

I'd say they're working only 3/4

Please check.

Thanks,
Frank


[frank@fisi ~]$ date
Wed Apr 24 07:40:04 EAT 2024
[frank@fisi ~]$ date -u
Wed Apr 24 04:40:07 UTC 2024
[frank@fisi ~]$ ping -c 5 196.192.115.21
PING 196.192.115.21 (196.192.115.21) 56(84) bytes of data.
64 bytes from 196.192.115.21: icmp_seq=1 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=2 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=3 ttl=54 time=49.8 ms
64 bytes from 196.192.115.21: icmp_seq=4 ttl=54 time=49.9 ms
64 bytes from 196.192.115.21: icmp_seq=5 ttl=54 time=50.0 ms

--- 196.192.115.21 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4055ms
rtt min/avg/max/mdev = 49.879/49.968/50.067/0.062 ms
[frank@fisi ~]$ whois -h 196.192.115.21 AS37084
[Querying 196.192.115.21]
[196.192.115.21]
[frank@fisi ~]$ ping6 -c 5 2001:42d0:2:601::21
PING 2001:42d0:2:601::21(2001:42d0:2:601::21) 56 data bytes
64 bytes from 2001:42d0:2:601::21: icmp_seq=1 ttl=56 time=49.6 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=2 ttl=56 time=49.2 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=3 ttl=56 time=49.0 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=4 ttl=56 time=49.5 ms
64 bytes from 2001:42d0:2:601::21: icmp_seq=5 ttl=56 time=49.3 ms

--- 2001:42d0:2:601::21 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4054ms
rtt min/avg/max/mdev = 49.089/49.359/49.613/0.239 ms
[frank@fisi ~]$ whois -h 2001:42d0:2:601::21 AS37084
[Querying 2001:42d0:2:601::21]
[Unable to connect to remote host]
You have new mail in /var/spool/mail/frank
[frank@fisi ~]$ date -u
Wed Apr 24 04:49:13 UTC 2024
[frank@fisi ~]$ dig whois.afrinic.net. +short
whois-public.afrinic.net.
196.192.115.21
196.216.2.21
196.216.2.20
196.192.115.22
[frank@fisi ~]$ whois -h 196.192.115.22 AS37084
[Querying 196.192.115.22]
[196.192.115.22]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use. 
See https://afrinic.net/whois/terms


% Note: this output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to 'AS37084'

% No abuse contact registered for AS37084

aut-num:AS37084
as-name:simbanet-tz
descr:  Simbanet (T) Ltd

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] person without email... and domain object size

[Frank Habicht]

Hi DBWG,

I didn't see any responses to below email.

But I've seen some new objects created recently - [1]

Is there no interest to stop objects like [1] from being created?

I'm conflicted as in both thinking a change is called for and trying to 
be a neutral chair.


So I think if there's no response, then I can not be an impartial chair 
and declare consensus.


There seem to be 11 domain objects for /128's.
There seem to be 108 domain objects for longer than /48.

I.e. not a current problem as much as a potential problem when any 
average LIR can create 2^96 domain objects.

Sorry. That's the number of objects for /128's to create.
Total of 2^97-1 objects can be created when including all the shorter ones.

Thanks,
Frank

[1]
domain: 
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.0.0.0.0.0.0.0.f.f.f.0.c.2.ip6.arpa

descr:  BTCL INTERNAL6
nserver:ns4.btc.bw
nserver:ns1.btc.bw
nserver:vpsm.btc.bw
org:ORG-BTC2-AFRINIC
admin-c:BM16-AFRINIC
admin-c:OSD1-AFRINIC
admin-c:IO10-AFRINIC
tech-c: BM16-AFRINIC
tech-c: OSD1-AFRINIC
tech-c: IO10-AFRINIC
zone-c: BM16-AFRINIC
zone-c: OSD1-AFRINIC
zone-c: IO10-AFRINIC
mnt-by: TF-196-1-130-0-196-1-133-255-MNT
mnt-lower:  TF-196-1-130-0-196-1-133-255-MNT
changed:maliba...@btc.bw 20240319
source: AFRINIC


On 22/02/2024 17:01, Frank Habicht wrote:

On 07/09/2020 17:21, Ben Maddison wrote:

Hi Simon, all,

On 09/07, Simon Seruyinda wrote:

Hi Frank,



Regarding the rdns objects size, thanks for bringing this up for 
discussion. Currently we have a limit for IPv4 set to minimum of /24, 
but there is no limit implemented for IPv6, so it will go up to 128.
I agree this could lead to unnecessary db growth and i think a limit 
should be set. Input from the DBWG members on what would be the 
appropriate minimum would highly be appreciated.



I would align with the minimum allocation size (/48, right?).
It's conceivable that a resource holder might want to delegate down
further, but that, I believe, should be a task for the operator's
nameservers.


So,

I apparently was wrong assuming something was already implemented.

I've just seen that a domain object for a /128 was created yesterday.

I think we can now start a 1-week last call on the suggestion from Ben 
(yes, from long ago) to limit domain objects for IPv6 (i.e. ending in 
.ip6.arpa) to be covering no smaller(longer) prefixes than the minimum 
assignment size (currently /48)



I propose, if consensus:
- domain objects with .ip6.arpa can not have more than 12 hexits when
    created
- staff to contact owners of the domain objects with more than 12 hexits
   to create an object covering their allocation/assignment and
   eventually delete the domain object covering an unnecessarily specific
   prefix
   There are 110 if my grep counted correctly.
   Surely from much fewer organisations.


Regards,
Frank


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] person without email... and domain object size

[Frank Habicht]

On 07/09/2020 17:21, Ben Maddison wrote:

Hi Simon, all,

On 09/07, Simon Seruyinda wrote:

Hi Frank,



Regarding the rdns objects size, thanks for bringing this up for discussion. 
Currently we have a limit for IPv4 set to minimum of /24, but there is no limit 
implemented for IPv6, so it will go up to 128.
I agree this could lead to unnecessary db growth and i think a limit should be 
set. Input from the DBWG members on what would be the appropriate minimum would 
highly be appreciated.


I would align with the minimum allocation size (/48, right?).
It's conceivable that a resource holder might want to delegate down
further, but that, I believe, should be a task for the operator's
nameservers.


So,

I apparently was wrong assuming something was already implemented.

I've just seen that a domain object for a /128 was created yesterday.

I think we can now start a 1-week last call on the suggestion from Ben 
(yes, from long ago) to limit domain objects for IPv6 (i.e. ending in 
.ip6.arpa) to be covering no smaller(longer) prefixes than the minimum 
assignment size (currently /48)



I propose, if consensus:
- domain objects with .ip6.arpa can not have more than 12 hexits when
   created
- staff to contact owners of the domain objects with more than 12 hexits
  to create an object covering their allocation/assignment and
  eventually delete the domain object covering an unnecessarily specific
  prefix
  There are 110 if my grep counted correctly.
  Surely from much fewer organisations.


Regards,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: Single partition fs layout

[Frank Habicht]

On 13/02/2024 16:52, Odhiambo Washington wrote:

Thanks a million for such a nice explanation.
Let me now ask Google about those flags.

 ^^
you misspelled "the man pages"

Frank

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Frank Habicht]

On 01/02/2024 01:45, Tom Beecher wrote:
Seems a bit dramatic. Companies all over the world have been using other 
people's public IPs internally for decades. I worked at a place 20 odd 
years ago that had an odd numbering scheme internally, and it was 
someone else's public space. When I asked why, the guy who built it said 
"Well I just liked the pattern."


If you're not announcing someone else's space into the DFZ, or 
otherwise trying to do anything shady, the three letter agencies aren't 
likely to come knocking. Doesn't mean anyone SHOULD be doing it, but still.


Well...

If you're using 20.20.20.0/24 which is not "yours" (as I've seen 
happen), then certainly your customers can't get to the real 20.20.20.x
And even if that's not announced and used /today/ - this can change 
quickly...


Frank

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Frank Habicht]

Seems it disappeared now and we can go back to regular programming.

Thanks to those who did that.

Frank

[frank@fisi ~]$ whois -h rr.level3.com 0.0.0.0/32
[Querying rr.level3.com]
[rr.level3.com]
%  No entries found for the selected source(s).


[frank@fisi ~]$






On 30/01/2024 19:37, Job Snijders via NANOG wrote:

On Tue, Jan 30, 2024 at 07:28:01PM +0300, Frank Habicht wrote:

I believe that the entry of
route:  0.0.0.0/32

does not serve any good purpose?


I don't think so either, I've created an issue to prevent that in future
releases of IRRd v4: https://github.com/irrdnet/irrd/issues/906

Thanks for noticing that!

It'll be up to Lumen to remove the record at hand.

Kind regards,

Job

route: 0.0.0.0/32 in LEVEL3 IRR

[Frank Habicht]

Hi,

I got 2 bounces for the email addresses seen below for an email similar 
to the below...


Anyone want to remove this IRR entry before anyone notices...???   ;-)

Frank


I believe that the entry of
route:  0.0.0.0/32

does not serve any good purpose?

I was surprised to see it in a list of prefixes from bgpq4 and the very 
good https://irrexplorer.nlnog.net/prefix/0.0.0.0 guided me that it's in 
"Level3".


I'm wondering how many auto-generated filters contain this unnecessary 
prefix


PS: Oh, just seen - it's from TODAY. Maybe remove before anyone sees it...?

Thanks for looking into this,
Frank


[frank@fisi ~]$ whois -h rr.level3.com 0.0.0.0/32
[Querying rr.level3.com]
[rr.level3.com]
route:  0.0.0.0/32
origin: AS10753
mnt-by: TCCGlobalNV-MNT
changed:ankita.gre...@lumen.com
source: LEVEL3
last-modified:  2024-01-30T11:04:49Z


[frank@fisi ~]$ whois -h rr.level3.com TCCGlobalNV-MNT
[Querying rr.level3.com]
[rr.level3.com]
mntner: TCCGlobalNV-MNT
descr:  TCC Global N.V.
auth:   CRYPT-PW DummyValue  # Filtered for security
upd-to: ripehostmas...@eu.centurylink.net
tech-c: LTHM
admin-c:LTHM
mnt-by: TCCGlobalNV-MNT
changed:ankita.gre...@lumen.com
source: LEVEL3
last-modified:  2024-01-30T11:01:52Z

Re: Generally accepted BGP acceptance criteria?

[Frank Habicht]

Also, you don't want to accept Google prefixes from your customer, even 
if they are ROV valid.


i.e. you want to restrict what you accept to customer and customer's 
customer prefixes...


Frank

On 17/11/2023 08:38, Pierfrancesco Caci wrote:
If you need to support RTBH you need to check prefix list (thus IRR) 
first, then the RTBH , then RPKI. Otherwise blackhole route gets dropped 
before executing.

Re: Dodgy AS327933 ...?

[Frank Habicht]

On 10/08/2023 16:02, Mark Tinka wrote:


We are seeing some weird routing from them, and the AS2 they are 
attached to (University of Delaware) seems odd.


Not sure if any of the American folk on this list can verify AS2 is 
really part of the University of Delaware...


Mark.



ouch!
I see in your LG that this AS 2 is originating 197.157.254.0/24 .

which seems to mean that it's not just a plain "we want to prepend 2 
times, put the number 2 into config and the NOS takes this as the ASN to 
insert"


putting someone from  AS37451 into BCC.

ouch again!
looking for "show ip bgp regexp _37451 2_" in Mark's LG, i see there are 
many originated and downstream's prefixes of AS37451 affected.


So i'd now thing it's a AS37451 issue, not AS327933 alone.

Frank

Re: Dodgy AS327933 ...?

[Frank Habicht]

Hi Mark,

On 10/08/2023 11:55, Mark Tinka wrote:

Anyone know anything about this AS:
https://bgp.he.net/AS327933


from a 2019 DB snapshot:

aut-num:AS327933
as-name:GROUPE-TELECOM-SPRL
descr:  GROUPE TELECOM SPRL
status: ASSIGNED
org:ORG-GTS2-AFRINIC
admin-c:YM8-AFRINIC
tech-c: YM9-AFRINIC
notify: ***@gtl-rdcongo.com
mnt-lower:  GTS2-MNT
mnt-routes: GTS2-MNT
mnt-by: AFRINIC-HM-MNT
changed:***@afrinic.net 20150917
source: AFRINIC

I think the most common way to get out of this DB is to not pay something.

I'd guess that

aut-num:AS37451
as-name:CongoTelecom
descr:  CONGO TELECOM

has a relationship with them and AS327933 wanted to prepend 2x [1] to 
their sole provider.  (AS37451)


Frank

[1]
https://bgp.he.net/AS327933#_graph4

Re: [DBWG] WHOIS maintenance

[Frank Habicht]

Thanks for the notification.
Frank

On 23/07/2023 22:25, Michel ODOU wrote:

Dear colleagues,

Please note that there will be an urgent WHOIS maintenance tomorrow 
morning (7.30 MUT) to fix some critical bugs.


The AFRINIC status page has been updated accordingly: 
https://status.afrinic.net/notices/phkxg6vttchgrqx3-urgent-whois-maintenance


Regards,
Michel


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] Status Update: [Scheduled] WHOIS Updates Maintenance

[Frank Habicht]

Thanks Sylvain,

I agree, it would in my opinion be very good if AfriNIC staff could (in 
addition to posting this to status.afrinic.net) also notify this mailing 
list about maintenances (before and after).




1. what do others think?

2. could we get a response from staff about this?


Thanks,
Frank


On 17/07/2023 22:52, Sylvain Baya wrote:

{read only icymi! not on the Status' delivery list?}
Dear AfriNIC's DBWG,

Hope this email finds you in good health!

...i thought it would be of interest to the DBWG
mailinglist; thus i share this [*] notification FYI. Thanks to let me 
know if you think i'm, somewhat,

  wrong :-/
__
[*]: 
>


AFRINIC Status
[Scheduled] WHOIS Updates Maintenance

Dear Members,

Please be informed that we'll be performing a maintenance on the WHOIS 
services on Tuesday 18th July, 2023.


Start Time: Tuesday 18th July 07:00 UTC End Time: Tuesday 18th July 
10:00 UTC


Affected services will be any WHOIS updates done on the MyAFRINIC portal 
or using the WHOIS web interface on afrinic.net .


Normal whois queries will not be affected.

Sincerely, AFRINIC

Schedule
Begins: 18 July 2023 @ 07:00 UTC
Ends: 18 July 2023 @ 10:20 UTC
Duration: 3 hours and 20 minutes

Affected Components
WHOIS Database
WHOIS Updates

View the full notice → 





Shalom,
--sb.




--

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|>
Subscribe to Mailing List: 
>

__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec 
vous tous! ‪#‎Amen‬!»

‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
après TOI, ô DIEU!»(#Psaumes42:2)



___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Frank Habicht]

Hi all,

On 02/06/2023 10:28, Stephane Bortzmeyer wrote:

The .ga TLD will change its mode of operation on 6th june 2023. The majority
of domain names, registered under disputable conditions, will be removed. Do
not be surprised if many domains will yield NXDOMAIN.

https://mon.ga/english.html

See the details in the press release:

https://www.afnic.fr/wp-media/uploads/2023/05/ga-domain-names-soon-to-return-to-Gabonese-management-1.pdf


I'm not involved at all, but wondering:
no webpage for registrants to check whether their domain will 'survive'?

Frank
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [DBWG] AFRINIC RPKI RRDP connectivity issues?

[Frank Habicht]

For the Friday (May 26) morning issue, I know noc@afrinic have some 
info, and I think they can share something. Otherwise I can help 
tomorrow evening.


for earlier issue(s) - i currently believe that was unrelated.

Regards,
Frank
(no hat)


On 27/05/2023 02:45, Massimo Candela wrote:

Hi all,


I'm also experiencing issues with downloading data from afrinic.net.

In attachment you can find two charts of errors with a similar time 
frame of the one reported above: one about rrdp network failures and one 
about rsync timeouts.


Ciao,
Massimo

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: Reverse DNS for eyeballs?

[Frank Habicht]

On 21/04/2023 15:37, Chris Adams wrote:

I don't see any benefit to programmatically-generated reverse DNS.  I
stopped setting it up a long time ago now.  Really, reverse DNS these
days is mostly only useful for:

- mail servers (where it shows a modicum of control and clue)
- infrastructure/router IPs (so mtr/traceroute can show useful info)


I would say the absence of reverse DNS tells useful info to receiving 
MTAs - to preferably not accept.


Frank

Re: PF rules to block out every IP from a given country

[Frank Habicht]

Hi,

On 07/12/2022 18:36, Peter N. M. Hansteen wrote:
...> and can now be found at 
https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --

as it says in the script itself, a trivial hack.

And I might add, it comes with *NO* warranties of any kind.


I think instead of :
grep allocated
in the two important lines, it should be :
egrep '(allocated)|(assigned)'

coz both can go to countries.

Frank

Re: Equinix routeservers (MLPE) behavior c/f no_export

[Frank Habicht]

Hi Elmar,

it seems to be a not completely agreed/standardised question.

https://www.rfc-editor.org/rfc/rfc7947#section-2.2.4

   The BGP Communities [RFC1997] and Extended Communities [RFC4360]
   attributes are intended for labeling information carried in BGP
   UPDATE messages.  Transitive as well as non-transitive Communities
   attributes applied to an NLRI UPDATE sent to a route server SHOULD
   NOT be modified, processed, or removed, except as defined by local
   policy.  If a Communities attribute is intended for processing by the
   route server itself, as determined by local policy, it MAY be
   modified or removed.

and
https://docs.ixpmanager.org/features/route-servers/#rfc1997-passthru
has some more background.

Hi Nick!

Frank


On 28/10/2022 15:21, Elmar K. Bins wrote:

Hi guys (and others),

I couldn't find an official description/explanation of this (EQX docs only
mention that this should behave the same as their "set the no_export" TE
community.

We are using Equinix' IXP platform's routeserver service (MLPE) in a few
locations on the planet, and due to the nature of our anycast structure, we are
sending our prefixes with the well-known NO_EXPORT community attached.

It seems to me that, at least in some places (i.e. Warsaw, ex-PLIX), the
routeservers will not forward the routes further, being intransparent to the
NO_EXPORT setting.

My assumption was transparency, so the prefixes would be forwarded unchanged,
including the NO_EXPORT community attached.

It would be nice to hear directly from Equinix, of course, but if anybody on
this list has hard knowledge of this, please share, so that I can take the
appropriate measures...

Thanks in advance,
 Elmar.

Re: [db-wg] NWI-13 Geofeed Legal Analysis

[Frank Habicht via db-wg]

Hi,


my name is Frank Habicht, not having enable in RIPE region, but Eastern 
Africa and active in AfriNIC etc...


Wanted to stay out of this, but to me this thread is turning sad and 
"funny" at the same time...


On 29/07/2022 18:24, denis walker via db-wg wrote:
...
The legal team will have to answer this question but is facilitating a 
service that leads to the identification of an individual the same (in 
law) as providing the PII directly?


Guess we have to accept that the legal team rules supreme, but I fail to 
understand how this "facilitating a service that leads to..." is the 
problem.


To me this seems similar to the next building having a sign "BANK" on it 
- that facilitates bank robberies (illegal activities) just the same.


Does it do any harm to review the current wording of the purposes and 
how they can be interpreted and perhaps make them more explicitly cover 
how the database is used?


can at the very least the operationally useful status quo be maintained 
until all the committees have finished the review?

please.

PS: i believe some content providers operate routers, and i believe some 
network operators can have an operational interest in geography.


I also believe that a geofeed in a /29 inetnum can point to data of /20 
granularity - covering multiple customers in one city. which should be 
highly legal.


Thanks,
Frank Habicht



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Re: [Community-Discuss] [members-discuss] ATTENDANCE & PARTICIPATION AT THE ANNUAL GENERAL MEMBERS’ MEETING (AGMM)

[Frank Habicht]

Hi,

I think there is a wrong assumption...

On 02/06/2022 00:38, DANIEL NANGHAKA wrote:

Some of you want to create confusion over small logical issues.

A corporation cannot be created by one individual. Corporation are 
represented by one Administrator despite of have many members in the 
team. That is why the registration is for one Administrative contact.


There can be multiple admin-c.


[frank@fisi ~]$ whois -h whois.afrinic.net -- -t organisation
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use. 
See https://afrinic.net/whois/terms


organisation:   [mandatory]  [single] [primary/lookup key]
.
admin-c:[optional]   [multiple]   [inverse key]# "multiple"
tech-c: [optional]   [multiple]   [inverse key]


example:

[frank@fisi ~]$ whois -h whois.afrinic.net -- -T organisation -B -r 
ORG-WCL4-AFRINIC

[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use. 
See https://afrinic.net/whois/terms


% Information related to 'ORG-WCL4-AFRINIC'

organisation:   ORG-WCL4-AFRINIC
.
admin-c:GM51-AFRINIC
admin-c:WL8-AFRINIC
admin-c:WCTT-AFRINIC
tech-c: WL8-AFRINIC
tech-c: WCTT-AFRINIC




Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [dns-operations] DNS request for ./NS with two extra bytes at the end

[Frank Habicht]

On 26/05/2022 22:37, John Levine wrote:

It appears that Brown, William  said:

-=-=-=-=-=-
It made sense 40 years ago when it was written.  In today’s security 
environment,  it does not.


It made sense and still makes sense when you know what Postel meant.

Be liberal in what you accept when the specification is ambiguous, not
accept any random garbage and try to guess what it means.


I also want to interpret it as "be resilient to anything thrown at you".

Frank
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [Community-Discuss] [apnic-talk]Re: [arin-ppml] Update on Litigation Between AFRINIC and Cloud Innovation ltd

[Frank Habicht]

On 31/12/2021 16:45, Cheken Chetty wrote:

Good day all, chairs,
I would like to call out a violation of the Code of Conduct by Ronald. 
His statements are clearly against section B, numbers 2, 3 and 4 within 
the AFRINIC code of conduct. His actions and statements are defamatory 
and quite offensive.

Regards


Hi Cheken Chetty,

Please assist to state any affiliation of concern you have and assist to 
clarify :

- who is defamed
- who is offended

Thanks,
Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: IPv6 and CDN's

[Frank Habicht]

On 26/11/2021 13:52, Mark Tinka wrote:

On 11/3/21 22:13, Max Tulyev wrote:
Implementing IPv6 reduces costs for CGNAT. You will have (twice?) less 
traffic flow through CGNAT, so cheaper hardware and less IPv4 address 
space. Isn't it?


How to express that in numbers CFO can take to the bank?


"want to buy 5 of those shiny new CGNAT boxes or only 2 ?"

Frank

Re: [Community-Discuss] Associated Press article

[Frank Habicht]

Hi Ronald,

just commenting briefly on one part only

On 02/10/2021 00:21, Ronald F. Guilmette wrote:
> I have asked here to see those original Cloud Innovation justification
> documents and that request has been met only with stony silence in reply.

While I would "love to" see Cloud Innovation's justifications that were
part of those IP resource applications, I do understand and accept that
these are not shared. I would also not necessarily be happy if AfriNIC
shared the details of my last application for resources, because there
are details about business setups and business plans included, which are
not necessarily for public or competitors' consumption.

Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [db-wg] running in whios-circles...?

[Frank Habicht via db-wg]

On 16/09/2021 09:06, Gert Doering via db-wg wrote:
> On Thu, Sep 16, 2021 at 02:59:04AM +0200, denis walker wrote:
>> The RIPE NCC effectively already provides
>> this referral service with RIPE GRS. It solves this problem 100% for
>> all RIR administered address space. Why do we need the NRO to start
>> discussions with IANA on how to fix a problem that already has a fully
>> implemented and working solution?
> 
> The NCC is not the root of the address distribution tree.  IANA is.
> 
> So pointing people from all over the world to the RIPE NCC "because IANA
> can't get their part right" is conceptually the wrong approach.
> 
> In practice, it might provide a fast and convenient approach today, but
> why can't IANA just do that?  Mirror the RIR stats files, point people
> asking *at the root of the tree* to the right branch.
> 
> Gert Doering
> -- NetMaster

thanks Gert for putting it much better than I did/could.

Frank
(OP)

Re: [db-wg] Bogon route object cleanup

[Frank Habicht via db-wg]

Hi all,

I'd like to suggest keeping the first listed one :
192.31.196.0/24 - AS112

and removing the 2nd (192.88.99.0/24) and the last (2011:4188::/48).

probably "reserved" is not the right status for 192.31.196.0/24
[rfc7535]
and
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
where the entry for 192.88.99.0/24
is much less favourable.

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

seems to suggest to keep 2001::/32 and 2002::/16

Regards,
Frank

On 03/09/2021 03:58, Ronald F. Guilmette via db-wg wrote:
> It seems that we never really settled the question of route objects that make
> reference to the following reserved IP blocks.
> 
> 192.31.196.0/24
> 192.88.99.0/24
> 
> 2001::/32
> 2002::/16
> 2011:4188::/48
> 
> Note that route objects referring to these IP blocks are *not* present in
> the route registries of any RIR other than RIPE.
> 
> I am in favor of including route objects that reference any of these
> reserved blocks in the ongoing cleanup.  My recollection is that Cynthia
> Revstr�m also expressed support for including any and all such route
> objects in the current ongoing route object cleanup.
> 
> Are there any objections at the present time to including such route objects
> in the ongoing cleanup?
> 
> 
> Regards,
> rfg
> 

Re: [DBWG] Abuse contacts (?)

[Frank Habicht]

Hi Ronald,

There's an "mnt-irt" attribute to the IP block and ASN objects.
It's optional in all of those; should point to an "irt" object.

This is how resource owners can add abuse contact information.
This is currently voluntary.

But I'd say that staff has in previous meeting presentations advised to
make use of this.

There is a policy proposal in the PDWG (since August 2018) to make an
abuse contact (through different DB mechanism) mandatory. This proposal
has faced some serious opposition.
https://afrinic.net/policy/proposals/2018-gen-001-d7

There is also an alternate proposal
https://afrinic.net/policy/proposals/2020-gen-005-d1
since Oct 2020.

Hope this helps.

Frank


[1]
whois -h whois.afrinic.net -- -v aut-num
whois -h whois.afrinic.net -- -v inetnum
whois -h whois.afrinic.net -- -v inet6num

mnt-irt

   May appear in an inetnum, inet6num or aut-num object. It points to an
   irt object representing a Computer Security Incident Response Team
   (CSIRT) that handles security incidents for the address space
   specified by the object.

 An irt name is made up of letters, digits, the character
 underscore "_", and the character hyphen "-"; it must start
 with "irt-", and the last character of a name must be a
 letter or a digit.



On 02/09/2021 02:26, Ronald F. Guilmette wrote:
> Just a question...
> 
> What is the history regarding abuse contact email addresses within the
> AFRINIC region, as related to both IP blocks and ASNs?
> 
> I'm guessing that this topic has been discussed in the past, but perhaps
> some kind person could give me a short summary of those past discussions.
> 
> Other RIRs have gone to some lengths to try to get resource holders to
> register abuse addresses for their IP blocks and ASNs, in some cases
> even mandating that.  Has the AFRINIC region considered such a mandate?
> 
> 
> Regards,
> rfg
> 
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] ASNs assigned to AFRINIC from IANA (missing from daily stats file)

[Frank Habicht]

Thanks for the update James.
Frank

On 25/08/2021 17:51, James wrote:
> Dear DBWG Members,
> 
> The resolution was earlier responded to Ronald directly through the
> support ticket, however, we also find it imperative to inform the
> working group as well.
> 
> This issue was caused by an error while handling the ASN resource pool
> on Tuesday 17th August and was eventually fixed on Friday 20th.
> 
> Thank you and best regards,
> 
> James
> 
> On 20/08/2021 22:53, Ronald F. Guilmette wrote:
>> It may seem inconsequential, given everything else that's going on right
>> now, but I felt obliged to at least note for the record that there exists
>> some AS numbers that have been assigned by IANA to AFRINIC but that are
>> not showing up in the daily AFRINIC "stats" file.
>>
>> IANA has assigned to AFRINIC the following AS number ranges:
>>
>> 327680-328703
>> 328704-329727
>>
>> (See relevant IANA WHOIS records at end.)
>>
>> In theory, at least, this implies that the entirety of these AS ranges
>> should be represented in the daily AFRINIC stats file.  If any of the
>> AS numbers in either range is not currently assigned, by AFRINIC, to any
>> resource member, then that ASN (or a range of ASNs containing it) should
>> still appear within the daily stats file, but it should be marked as either
>> "reserved" or "available".
>>
>> In the case of the first ASN range above, it appears that all ASNs in the
>> range are in fact represented within the daily AFRINIC stats file except
>> for the first three ASNs of the range, i.e. 327680, 327681, and 327682.
>>
>> In the case of the second ASN range above, all of the ASNs in the range
>> are represented in the daily stats file except for the ones in the
>> sub-range 328916-329727, inclusive... a total of some 812 "missing"
>> AS numbers.
>>
>> Hopefully, these small omissions from the daily AFRINIC stats file will
>> be rectified... by someone.
>>
>>
>> Regards,
>> rfg
>>
>> ___
>> DBWG mailing list
>> DBWG@afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [Community-Discuss] Multinational ISPs

[Frank Habicht]

Ronald,

just to confirm,

are you talking about organisation "ORG-HLta1-RIPE" - per RIPE DB ? [1]

The one that has 185.2.48.0/22 and 178.236.224.0/20 from RIPE? [2]

Both of which have the same maintainer for their route objects -
"mnt-routes: hk-larus-1-mnt"

which appears to be located in "Flat B5,11/F,TML Tower, No.3 Hoi Shing
Road,Tsuen Wan, HKSAR"  [3]

You're talking of that same organisation?

Greetings,
Frank


[1]
organisation:   ORG-HLta1-RIPE
org-name:   Wu Han YunWaiHeng information Technology, Co,Ltd.
country:CN
org-type:   LIR
address:Esdoorlaan 656
address:9741MH
address:Groningen
address:NETHERLANDS
phone:  +31507200036
fax-no: +31507200036
e-mail: t...@outsideheaven.com
abuse-c:OHS20-RIPE
mnt-ref:RIPE-NCC-HM-MNT
mnt-ref:OH-MNT
mnt-by: RIPE-NCC-HM-MNT
mnt-by: OH-MNT
created:2010-06-11T10:03:32Z
last-modified:  2020-12-16T13:13:16Z
source: RIPE

[2]
inetnum:185.2.48.0 - 185.2.51.255
netname:CN-YUNWAIHENG-20120917
country:NL
org:ORG-HLta1-RIPE
admin-c:OHS18-RIPE
tech-c: OHS18-RIPE
status: ALLOCATED PA
notify: i...@outsideheaven.com
mnt-by: RIPE-NCC-HM-MNT
mnt-by: OH-MNT
mnt-lower:  hk-larus-1-mnt
mnt-routes: hk-larus-1-mnt
mnt-domains:OH-MNT
created:2012-09-17T12:21:43Z
last-modified:  2017-11-05T22:05:21Z
source: RIPE

inetnum:178.236.224.0 - 178.236.239.255
netname:CN-YUNWAIHENG-20100616
country:FR
org:ORG-HLta1-RIPE
admin-c:OHS18-RIPE
tech-c: OHS18-RIPE
status: ALLOCATED PA
notify: ab...@outsideheaven.com
notify: ab...@outsideheaven.com
mnt-by: RIPE-NCC-HM-MNT
mnt-by: OH-MNT
mnt-lower:  hk-larus-1-mnt
mnt-domains:OH-MNT
mnt-routes: hk-larus-1-mnt
mnt-routes: IPTP
created:2010-06-16T09:27:45Z
last-modified:  2017-11-05T22:04:36Z
source: RIPE

[3]
mntner: hk-larus-1-mnt
descr:  Startup maintainer
auth:   MD5-PW # Filtered
admin-c:LDC282-RIPE
tech-c: LDC282-RIPE
upd-to: d.hila...@laruscloudservice.net
auth:   SSO # Filtered
auth:   SSO # Filtered
mnt-by: hk-larus-1-mnt
created:2017-01-24T09:49:30Z
last-modified:  2017-09-30T09:39:02Z
source: RIPE # Filtered

role:   Larus DB contacts
address:Flat B5,11/F,TML Tower, No.3 Hoi Shing Road,Tsuen Wan, HKSAR
e-mail: i...@laruscloudservice.net
admin-c:DH6786-RIPE
nic-hdl:LDC282-RIPE
mnt-by: hk-larus-1-mnt
created:2017-08-28T04:04:01Z
last-modified:  2017-08-28T04:04:01Z
source: RIPE


On 16/08/2021 04:40, Ronald F. Guilmette wrote:
> Some ISP companies are truly multinational in scope.  Take this one, for
> example, which apparently operates in no fewer that 243 different countries:
> 
> https://www.ripe.net/membership/indices/data/cn.yunwaiheng.html
> 
> (Note that at present, the DNS root zone only contains 248 two-letter
> ccTLDs.  But I guess that the above company has elected to spurn potential
> customers in, for example, Ascension Island - .AC, together with any and
> all residents of and enterprises within the former Soviet Union - .SU.)
> 
> 
> Regards,
> rfg
> 
> ___
> Community-Discuss mailing list
> Community-Discuss@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/community-discuss
> 

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] ICANN ( NRO ) vs LARUS (NRA)

[Frank Habicht]

On 02/08/2021 16:48, Lamiaa Chnayti wrote:
> So yes, Africa
> has always and will always have my support, but not AFRINIC..

Sad to see you go, but well - it is what it is.

Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Call for AFRINIC’s registry service migration to other RIRs

[Frank Habicht]

On 01/08/2021 20:54, Owen DeLong wrote:
>> On Aug 1, 2021, at 08:27 , Frank Habicht  wrote:
>> I think Cloud Innovation dropping all lawsuits would have the same
>> effect, and that is the way I would like to suggest.
> 
> OK, for the sake of argument, what would you have AFRINIC do to ensure the 
> protection of Cloud Innovations rights in that process?
> 
> Unless and until there is some willingness on the other side to address the 
> issues that created the need for the lawsuits, why would
> Cloud Innovation surrender its rights and the damage it has suffered at the 
> hands of AFRINIC’s misdeeds?

I'm still not convinced that CI had the right to lease out the space.
That's where we differ.
And I believe that we agree in the fact that it's not (any more) for us
or this mailing list to determine this.

Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] [ripe-list] Call for AFRINIC’s registry service migration to other RIRs

[Frank Habicht]

On 01/08/2021 14:58, Lamiaa Chnayti wrote:
> ... There’s too much to risk
> if we don’t get any help from another RIR as soon as possible..

I have a question about the "we".
How would any non-functioning of any AfriNIC service affect you or any
employer of yours?
[other than the ability to post to this very mailing list]

Thanks,
Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Call for AFRINIC’s registry service migration to other RIRs

[Frank Habicht]

Hi,

first the part from the end that prompted me to respond...

>   In fact I find the amount of legal posturing on this
> list to be nothing short of bizarre - let the courts do their work -
   - how dare you use the singular
I expected 2 lists, but then saw many more (which I'm not subscribed
to). And I've seen where this was introduced - Thanks Paul!


On 01/08/2021 15:38, Andrew Alston via Community-Discuss wrote:
> It is my (personal) view that AfriNIC board should exercise their powers
> and pass a transfer policy.

One version to achieve that result already exists, though in 2 steps:
- get new IPs elsewhere - [1]
- return your current resources to AfriNIC
  It's possible, I've done that.


> It is entirely within the boards powers to pass emergency policy which
> the community can revoke at the next pdp should they wish to do so - and
> if AfriNIC has the support claimed by members of this list there is
> absolutely zero risk in this approach.

After all the good things certain members have done, the board really
should consider returning a favour or two.


> Furthermore - such an approach would also remove the possibility of
> other legal action which may be taken against them on grounds removed
> from the current legal situation

If memory serves me right, while you were on the board you were talking
about "fiduciary duty" and that's when i first heard the expression.


> I remind everyone that AfriNIC has a duty to act in the interests of its
> members - and AfriNIC has repeatedly stated in the press - and has been
> echoed by various ISP associations that there is risk here - 

.. in my humble opinion the risk is brought by the initiator of the
legal proceedings.
And yes, I also have this minor disagreement with Owen that leasing
space was permitted - or not. And I agree we let someone else conclude this.

Frank

[1]
seems my google-foo is with me today:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers
https://www.arin.net/resources/registry/transfers/stls/registered_facilitators/
https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer-of-unused-ip-and-as-numbers/transfer-facilitators/



___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Call for AFRINIC’s registry service migration to other RIRs

[Frank Habicht]

Hi,

On 01/08/2021 17:54, Thizwilondi Malupa wrote:
> Hi Robert , 
> 
> I think Andrew made a very good point, despite your argument that he is
> pushing for the  transfer  policy for some other reasons. Passing a
> transfer policy would  by all means reduce the risk of having AFRINIC
> badly affected entirely , including this community  .

I think Cloud Innovation dropping all lawsuits would have the same
effect, and that is the way I would like to suggest.


Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: A crazy idea

[Frank Habicht]

Hi,

On 30/07/2021 07:58, Owen DeLong via NANOG wrote:> ...
> Consider this… I discussed this topic at length with JJB (COMCAST at
> the time) and pushed hard on why they don’t give /48s to their
> residential customers. His answer was that if they did so, they would
> need to get a /12 from their RIR (ARIN). My question to him in
> response to that was “so?”.


I recently got this "so?" question asked [1] and I believe I follow you
and see the point.

My response was along the line:
- today (at least here in AfriNIC-land - sorry to get out of "NA")
  the RIR charges membership fee depending on size of IPv4 allocations.
- Will the RIR charge membership fee depending on IPv6 allocation size
  in 5 years from now?

And it's a genuine question.
Does anyone know what the intentions or likelihood of options are?
Really interested.

Thanks,
Frank

[1]
by staff member asking why we don't replace the existing v6 /32 with
something bigger.

Re: [Community-Discuss] [members-discuss] STATEMENT OF TANZANIA ISP ASSOCIATION (TISPA) - Regarding AFRINIC

[Frank Habicht]

You know what I think:

On 29/07/2021 23:49, Paul Wollner wrote:
> ...
> I for one call that at this stage, AFRINIC should be seriously looking
> into ways transition it’s service to other RIRs to mitigate the risk
> that they have mentioned today to the press.

Destroying it rather than fixing it, you want.


Frank
being frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

On 29/07/2021 05:06, Owen DeLong via Community-Discuss wrote:
>> On Jul 28, 2021, at 14:43 , JORDI PALET MARTINEZ via Community-Discuss 
>>  wrote:
>> If I said "I'm going to setup a network connecting 8 million users in a, b 
>> and c African countries, please allocate 9 million addresses to me". If then 
>> I change my business plan or actually *never* setup this network, the 
>> original documentation provided to justify the allocation, is not valid. 
>> Otherwise, every AFRINIC member could do the same, just to circumvent the 
>> rules!
> 
> Sure, but if you said I’m going to provide addresses to number more than 
> 6,000,000 hosts on our own and our customers networks, please give me 
> 6,000,000 addresses in 2013 and 2014 (and we did this in the form of 4 
> sequential requests as utilization increased), and you can show that the 
> networks were actually built out at each phase and you can show that the 
> addresses are still utilized in a manner consistent with that description, 
> then there’s no valid basis for reclamation.

I'd like to point out that both Jordi's question and Owens answer are
hypothetical.

Including the conclusion.

Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

Hi Jordi,

On 27/07/2021 22:30, JORDI PALET MARTINEZ via Community-Discuss wrote:
> This will be very simple to resolve (not taking a position in one side or the 
> other because I don't have all the real facts and documents).
> 
> The original justificacion of the request of the resources I don't think it 
> had so many "secret" and "confidential" details. After several years if any 
> "secrets" were there, probably aren't longer something that can't published 
> now.
> 
> So why not CI, voluntarely publish that information? I don't have any stance 
> on this game, but if I was CI, this will be the best way to probe my points.

it seems 4 minutes earlier I suggested same to Owen.

> Otherwise, I will suggest that AFRINIC asks the court to incorporate that in 
> the proceedings if is not there already, this way, whatever is the result of 
> the case, everybody will know it. At least in the countries I know, the 
> results of the cases are public, as well as the documents that were 
> incorporated during all the process: transparency.

I don't know whether or not (under the Mauritius legal system) the
information/documents will become public.
I certainly would like to have AfriNIC ask the courts to consider them.
I was hoping that was clear from my previous emails.


Frank



> 
> Regards,
> Jordi
> @jordipalet
>  
>  
> 
> El 27/7/21 21:12, "Frank Habicht"  escribió:
> 
> Hi Owen,
> 
> On 27/07/2021 19:09, Owen DeLong wrote:
> >> On Jul 27, 2021, at 00:26 , Frank Habicht  wrote:
> >>> It also serves more end users than the population of all of those
> >>> countries combined. What is your point?
> >>
> >> "serves" ...?
> > Yes.>> with connectivity?
> > 
> > In some cases.
> 
> I'll just mentally insert the word "few" in there, because i haven't
> seen any yet.
> 
> 
> >> Or by "buying" IPv4 addresses one place and "selling"/leasing them
> >> another place.
> > 
> > By providing a variety of services, some of which include IP address 
> management
> > independent of connectivity.
> 
> "variety of services"
> So my first thought was to press  and the key between v and n
> and then  and the key between a and d
> 
> gosh, at the risk of getting my hand slapped, just to make sure i'm
> understood : BS - bullshit!
> 
> 
> "IP address management"
> putting something into AfriNIC's Whois / IRR ?
> reverse DNS delegations?
>  [ probably only at extra cost (wild guess) ]
> Using AfriNIC's auth DNS servers, by just updating domain: objects?
> 
> 
> >> this is to me closer to speculation than the stated intention of
> >>
> >> 1. the resource we take are using in africa.
> >> 2. we are investing in africa.
> > 
> > We are definitely investing in Africa. That statement remains true.
> 
> No doubt.
> Lawyers in Mauritius.
> 
> 
> > Regarding the former statement, things do change over time.
> 
> Agree.
> Also validity of justifications of IPv4 space.
> I maintain this:
> - I have no idea how it was justified.
> - I have no right to see this justification.
> - I consider it likely that commitments have been made.
> - I consider it likely that not all were - and still are - fulfilled.
> 
> > At the time the statement was made, it was true.
> 
> I do currently believe that.
> 
> > Today, the statement “many of the resources we received from AFRINIC 
> are being used in Africa” would be more accurate.
> 
> I'm still not too sure about my English knowledge. Especially about
> "many". I generally encourage people to be as specific as possible.
> Can I interpret this as "more than three IPv4 addresses we received from
> AFRINIC are being used in Africa” ?
> 
> 
> >> which is a quote from
> >> https://lists.afrinic.net/pipermail/rpd/2014/004161.html
> > 
> > Yes… It’s a 7 year old statement which was true at the time.
> 
> And I believe so was the justification for IPv4 addresses - at the time.
> Currently, I believe that. That back then the justification was ok.
> 
> 
> >> and which I understand was good reason to receive IPv4 addresses.
> >> *was*
> >> when it was true.
> > 
> > And today, a good reason to keep the addresses is:
> > We use the addresses to number internet connected hos

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

On 27/07/2021 19:27, Owen DeLong wrote:
>> On Jul 27, 2021, at 00:31 , Frank Habicht > <mailto:ge...@geier.ne.tz>> wrote:
>>
>> Hi,
>>
>> did any of those make any commitment like "we are using these to connect
>> our customers in Africa" ?
> 
> I have no idea what they did or did not commit to with regards to Africa.
> How is that relevant to the question at hand regarding the amount of address
> space in question?

I really hope we can agree that AfriNIC did never outright "sell" the IP
address space. But gave the right to use subject to justification(s).

If not, we seem to live in different universes.

>> Did CI?
> 
> 7 years ago, CI made such a statement. CI subsequently adapted to the
> changing business
> environment and expanded its operations to include both Africa and other
> continents. CI
> submitted appropriate updates to WHOIS as these changes occurred.

I am not sure whether AfriNIC expanded it's acceptance for the use of IP
resources by CI to the same extent.


>> PS: I count connectivity to a VM hosted by CI as ok, but not leasing
>> just the IP to an entity without providing them any connectivity.
> 
> Where is your basis in policy for this?

In the justification from CI for the IP address space. which I haven't
seen. Want to share?


Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

Hi Owen,

On 27/07/2021 19:09, Owen DeLong wrote:
>> On Jul 27, 2021, at 00:26 , Frank Habicht  wrote:
>>> It also serves more end users than the population of all of those
>>> countries combined. What is your point?
>>
>> "serves" ...?
> Yes.>> with connectivity?
> 
> In some cases.

I'll just mentally insert the word "few" in there, because i haven't
seen any yet.


>> Or by "buying" IPv4 addresses one place and "selling"/leasing them
>> another place.
> 
> By providing a variety of services, some of which include IP address 
> management
> independent of connectivity.

"variety of services"
So my first thought was to press  and the key between v and n
and then  and the key between a and d

gosh, at the risk of getting my hand slapped, just to make sure i'm
understood : BS - bullshit!


"IP address management"
putting something into AfriNIC's Whois / IRR ?
reverse DNS delegations?
 [ probably only at extra cost (wild guess) ]
Using AfriNIC's auth DNS servers, by just updating domain: objects?


>> this is to me closer to speculation than the stated intention of
>>
>> 1. the resource we take are using in africa.
>> 2. we are investing in africa.
> 
> We are definitely investing in Africa. That statement remains true.

No doubt.
Lawyers in Mauritius.


> Regarding the former statement, things do change over time.

Agree.
Also validity of justifications of IPv4 space.
I maintain this:
- I have no idea how it was justified.
- I have no right to see this justification.
- I consider it likely that commitments have been made.
- I consider it likely that not all were - and still are - fulfilled.

> At the time the statement was made, it was true.

I do currently believe that.

> Today, the statement “many of the resources we received from AFRINIC are 
> being used in Africa” would be more accurate.

I'm still not too sure about my English knowledge. Especially about
"many". I generally encourage people to be as specific as possible.
Can I interpret this as "more than three IPv4 addresses we received from
AFRINIC are being used in Africa” ?


>> which is a quote from
>> https://lists.afrinic.net/pipermail/rpd/2014/004161.html
> 
> Yes… It’s a 7 year old statement which was true at the time.

And I believe so was the justification for IPv4 addresses - at the time.
Currently, I believe that. That back then the justification was ok.


>> and which I understand was good reason to receive IPv4 addresses.
>> *was*
>> when it was true.
> 
> And today, a good reason to keep the addresses is:
> We use the addresses to number internet connected hosts on our own and our 
> customers networks.

"own network" ?
I believe that in your home area it would be a very valid question to
ask: "which AS is that?" (ie on nanog)

"customers networks."
"customer" certainly not in terms of connectivity.
[ to be specific: for 99% of traffic towards these IPs [1], I hazard the
  guess that it doesn't pass through CI connectivity.]

but "customer" instead only in terms of leasing IP addresses.
which you (CI) got the right to do when getting them from AfriNIC in the
first place??? I beg to doubt!!!

And I think this is what it's all about. CI interpretation vs AfriNIC
interpretation. And I think that latter is shared with a majority of the
community.

> This is a perfectly valid justification for addresses and there is no basis 
> in current policy to deny it and
> it remains a true statement to this day.

If
it was a perfectly valid justification to provide addresses to CI's
"customers" - without the "customers" receiving (for all the duration of
the lease) any services but the lease of IPv4 addresses (not counting
BS-"IP address management"), and with that fact (of leasing) being
stated in said justification - and this accepted as justification at the
time by AfriNIC,
then
I rest my case.


Frank

PS: sorry for the long sentence, it seems my mind turned "legal".

[1]
"these IPs":
2x /11 and 2x /12

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

Hi,

did any of those make any commitment like "we are using these to connect
our customers in Africa" ?

Did CI?

Thanks,
Frank

PS: I count connectivity to a VM hosted by CI as ok, but not leasing
just the IP to an entity without providing them any connectivity.

On 27/07/2021 08:24, Owen DeLong via Community-Discuss wrote:
> If you think this is a shocking amount of address space, please consider
> the amount of space
> held by:
> 
> Non-LIRs (end users):
> Hewlett Packard
> Apple Computer
> 
> Unclear whether to classify as LIR or not:
> Amateur Radio (AMPR)
> 
> LIRs:
> XFINITY/Comcast
> Verizon
> Akamai
> XO Communications
> Amazon
> Microsoft
> Google
> etc.
> 
> The equivalent of 1.5 /10s (75% of a /9) is far less than any of the
> above organizations.
> 
> Owen
> 
> 
>> On Jul 26, 2021, at 01:11 , Leo S > > wrote:
>>
>> Hi Ronald
>> Maybe your number is correct, whether it is 6.3M or 7M,This is a
>> shocking number for everyone especially in 201x such a large block
>> allocated. This is not in 199x year.
>>
>> On Mon, Jul 26, 2021 at 4:25 AM Ronald F. Guilmette
>> mailto:r...@tristatelogic.com>> wrote:
>>
>> In message
>> > >
>> Meriem Dayday > > wrote:
>>
>> >This is a direct violation of the CoC.
>>
>> No, actually, it isn't.
>>
>> The information about how Cloud Innovation is presently making use of
>> it's assigned 6,291,456 AFRINIC-administered IPv4 addresses is
>> effectively
>> public information, and it is not difficult to derive from any
>> number of
>> public sources (e.g. RIPEStat, bgp.he.net , etc.)
>>
>> If you lived in the time of Galileo Galilei, would you consider it an
>> affront to public decency if some people elected to look through the
>> telescope and then just describe what they saw?  And if so, then what
>> is next?  Book burning?
>>
>> >Disclosing such information and data without the company's
>> consent is a
>> >clear attempt of defamation and can have legal consequences on the
>> >concerned person.
>>
>> OK, let's parse that statement, because it conjoins two different
>> obvious
>> logical problems.
>>
>> First, the Internet is *not* a private network.  Fact's about what
>> various
>> companies are doing on the Internet are possible to see, and to learn,
>> without needing the consent of the companies inolved.  That is the
>> nature
>> of the Internet.  If you want to run your own closed private intranet,
>> then go head.  Nobody will stop you and you can then keep every last
>> detail of your corporate operations utterly secret.  But the
>> minute any
>> company obtains Internet number resources and starts using those, it
>> *voluntarily* gives up some of its corporate secrecy in exchange
>> for being
>> a part of, and a participant on this great communications
>> experiment we
>> call the Internet.
>>
>> I personally am not now, and never have been a customer of Cloud
>> Innovation.
>> And yet even well before today I already determined for myself
>> that well
>> more that 90% of Cloud Innovation's assigned AFRINIC-administered IPv4
>> address space was being deployed to other continents.  This is not
>> a state
>> secret by any means, and the information may be derived from 100%
>> public
>> sources.  Anyone clever enough to seek it out will find the same
>> information.
>>
>> Whether the manner in which Cloud Innovation is using/deploying its
>> assigned number resources does or does not comport with its specific
>> RSA and/or with community approved regulations is a separate question,
>> and one which I myself do not have an answer to.  In any case, the
>> courts will sort out those questions in due course, I imagine. 
>> But the
>> mere facts of how Cloud Innovation has deployed its AFRINIC-assigned
>> resources, or how it would appear to make money, based on the
>> available
>> public evidence, are *not* corporate secrets.  Any attempt to portray
>> them as such is just an attempt at heavy-handed censorship.
>>
>> The second logical problem with the statement above is contained
>> in the
>> part that says "... attempt of defamation and can have legal
>> consequences
>> on the concerned person."
>>
>> Exactly so!  If the guy who posted the material you are reacting
>> to was
>> willing to take the legal risk to post that material, IN SPITE OF the
>> possibility that he could, at least in theory, be sued for defamation,
>> then why are YOU worried about it?  Why should AFRINIC be worried
>> about
>> it?  Obviously, this (theoretical) possibility of a defemation lawsuit
>> is only a problem for the guy who posted the 

Re: [Community-Discuss] Share About Cloud Innovation Ltd and their business

[Frank Habicht]

Hi Owen,

On 27/07/2021 08:28, Owen DeLong via Community-Discuss wrote:
> 
> 
>> On Jul 26, 2021, at 04:01 , Noah > > wrote:
>> So while checking some statistics with a good friend over the weekend,
>> we just noted that actually Cloud Innovation has more IPv4 addresses
>> than East African countries of Kenya, Tanzania, Uganda and I won't
>> even bother posting for Rwanda, Burundi and South Sudan because its sad.
> 
> It also serves more end users than the population of all of those
> countries combined. What is your point?

"serves" ...?
with connectivity?
Or by "buying" IPv4 addresses one place and "selling"/leasing them
another place.

this is to me closer to speculation than the stated intention of

1. the resource we take are using in africa.
2. we are investing in africa.

which is a quote from
https://lists.afrinic.net/pipermail/rpd/2014/004161.html

and which I understand was good reason to receive IPv4 addresses.
*was*
when it was true.

Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi,

On 25/07/2021 19:37, Nishal Goburdhan wrote:
> On 25 Jul 2021, at 18:14, Frank Habicht wrote:
> 
> 
>> I trust you mean the DBWG to ask AfriNIC staff to request RADB to do
>> some still-to-be-better-specified cleanup.
>> So this is for action at a party external to AfriNIC.!
>> It looks like we're getting towards consensus.
>> I see Ronald, Noah, yourself and Frank-when-he's-not-co-chair supporting
>> this.
>> Wanted to give other just a little bit more time.
>>
>> Nishal's message I understand as asking AfriNIC staff to publish blocks
>> under their control. nothing more (yet).
> 
> hi frank,
> 
> i think i clarified my expectation, and, hopefully helped to fix other
> broken expectation(s), here:
> https://lists.afrinic.net/pipermail/dbwg/2021-July/000394.html.
> i really don’t think i have anything more i can add, but i’m happy to
> try to restate what i’ve already written, if it wasn’t already clear  :-)

Yes, I have understood.

Frank



___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

On 25/07/2021 18:54, Sylvain Baya wrote:
> Hi Ronald,
> Thanks for your email, brother!
> ...good! that is why i appreciated your effort.
> 
> Maybe i failed to state it clearly...i add my support 
> for a request from the DBWG to the AfriNIC's Staff, 
> so that they could handle a formal cleanup request 
> directed to RADb in order to remove all IRR's 
> objects (including route: and route6:) incorrectly 
> created in their Database; whereas those objects 
> are attached to AfriNIC's delegated INRs pools.

Thanks. Noted.


> ...yes, it's more than what you asked...that's how 
> things work...then the DBWG has to agree or not :-)

I am not sure I understand how it's more than Ronald's request.
Most importantly, what's the definition of "incorrectly created" ?


But thanks for contributing to move this item forward!

I think we need a good definition of what the request is.
Any volunteer?

And...

I believe a resource member's contact-staff for AfriNIC might have
changed/left/... so that we we could/should/? exclude space that was
previously delegated by AfriNIC to a resource member and is now
non-delegated for less than one month (...or two months?)
What do others think?


Thanks,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi Sylvain and all,

On 25/07/2021 18:21, Sylvain Baya wrote:
> Dear DBWG,
> 
> Le dimanche 25 juillet 2021, Noah  > a écrit :
> 
> 
> 
> [...]  
> 
> But I don't think that they could or would
> ignore a reasonable request that came to them direct from the
> staff at
> any RIR.  I will make some effort to see if I can find out about
> that.
> 
> 
> 
> And this is where Afrinic staff would become in handy imho.
> 
> 
> Hi Noah,
> Thanks for your email, brother!
> 
> As there seems to be more than a full consensus 
> on that cleanup request action.

I trust you mean the DBWG to ask AfriNIC staff to request RADB to do
some still-to-be-better-specified cleanup.
So this is for action at a party external to AfriNIC.!

It looks like we're getting towards consensus.
I see Ronald, Noah, yourself and Frank-when-he's-not-co-chair supporting
this.
Wanted to give other just a little bit more time.


Nishal's message I understand as asking AfriNIC staff to publish blocks
under their control. nothing more (yet).

> 
> So the next question would then be, can Afrinic pick this up on
> behalf of the community and ping RADB folks.
> 
> 
> ...i fail to see why they could not follow the DBWG 
> consensus on that action.

Allow me to ask that we be very specific.
The "they" refers to "RADB folk"?
Because "Afrinic" would likely "pick this up and follow the DBWG consensus"

Since RADB does as far as i know not "have to" do what we ask, we have
to refine *how* and *what* we ask. We == DBWG + AfriNIC

and have to have consensus on it.

> Also, a co-chair has already call them to react.

Ehm, I asked AfriNIC staff to publish the list of blocks they control.
Hope that's what you refer to.

Regards,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi all,

I had some meta-info missing from my yesterday email.
Please allow me to correct/update.

On 24/07/2021 11:46, Frank Habicht wrote:
> Hi Ronald,
> 

> thanks for this longer explanation, and I personally think that it helps
> us all understand.


> 
> On 24/07/2021 00:58, Ronald F. Guilmette wrote:
>> ...
>> I should perhaps explain why I would like to have a list of all AFRINIC
>> administered IP space.
>>
>> As we all know, routing on the Internet is, at the present time, still quite
>> fraught with insecurity.  Until the whole world starts accepting (and also
>> enforcing) RPKI checks, there will remain quite a lot of goofy stuff on the
>> Internet when it comes to routing.
>>
>> Of course, anybody can just announce a route to any IP space they like and
>> nobody can really stop them from doing that.  But in the absence of any
>> "authority" that effectively "validates" a given route, the route 
>> announcement
>> itself is likely to get filtered.
>>
>> The world has not yet fully adopted RPKI so when it comes to validating
>> routes, the world still relies a lot on Internet Route Registries (IRRs).
>> And it is to be hoped that each of these will contain only "good" and
>> "valid" information.  Sadly, that is not even nearly the case.  I've
>> been researching this recently, so I know.
>>
>> Each of the five Regional Internet Registries operates its own IRR...
>> in the case of both RIPE and ARIN, they actually each operate -two-
>> of these... a so-called "AUTH" IRR and also a "NONAUTH" one.  Anyway,
>> my research has shown that -all- of the IRRs being operated by all of
>> the RIRs have had some provably invalid route objects in them... either
>> (a) routes that are invalid because they refer to "bogon" (unassigned) IP
>> address space or else (b) routes that refer to "bogon" (unassigned) AS
>> numbers.  I have been trying to work with all five of the RIRs to get
>> these "bogon" route objects eliminated from their respective IRRs.
>>
>> I am pleased to say that AFRINIC has been most cooperative in this effort,
>> and that AFRINIC now has exactly and only -zero- bogon route objects in
>> its IRR. 
> 


> That is great to hear and after 2nd read I noted the past tense in the
> previous paragraph :-)


> I think it's in all our interest to have and keep the IRRs as much as
> possible in a state that's extremely close to the truth, authoritative
> and trusted.


>> Alas, the IRRs that belong to the four other RIRs are still a
>> work in progress, and each are still in need of more cleanup to insure
>> that they contain only 100% valid route objects.
>>
>> The only other IRR that seems to be in really widespread use is is the
>> privately operated one that is run by Merit, Inc. in the U.S. and that
>> is called "RADB".  Sadly, this one has minimal security and apparently
>> no routine maintenance of any kind.  As a result, it has, over time
>> accumulated a LOT of bogon route objects, many of which were abandoned
>> by their creators, long long ago, and many of which have been quite
>> deliberately created by Internet criminals and miscreants.
>>
>> My long term hope is that I'll be able to get bogon route objects removed
>> not just from the IRRs that are operated by the five RIRs, but also from
>> the RADB data base as well.


> I agree that making RADB "cleaner" than now would make a positive
> operational impact.

>> Unfortunately, the folks at RADB don't listen to me when I tell them
>> about problems in their published route data.  (I think that maybe they
>> don't like me.  If so, they would certainly not be alone.)  But I've
>> been informed that they *do* listen when any RIR staff talks to them.
> 
> I've once-or-twice told them of much more specific problems, with
> explanation and supporting info for each case, and it went ok.
> *maybe* too much change at once makes it "suspicious" to them


>> So, here is the bottom line:
>>
>> Within the RADB there currently exists vast gobs of bogon route objects
>> that refer to IP space that is administered by AFRINIC but which is
>> currently not *assigned* by AFRINIC to any party.  The effect of at
>> least some of these RADB route objects is to allow various parties to
>> freeload off of unassigned AFRINIC-administered address space.
>>
>> Here is a clear example:
>>
>> https://bgp.he.net/AS37155#_prefixes
>>
>> I believe that all of the IPv4 address blocks shown on the 

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Below/inline.

On 25/07/2021 07:55, Ronald F. Guilmette wrote:
> I honestly was not aware of the fact that people had to pay money to
> get routes into the RADB data base until I saw this message that I am
> responding to (from Noah).  This puts a whole different light on the
> problem!
> 
> RADB is operated by Merit, Inc. which is located in the State of Michigan,
> U.S.A.  All I knew... up until now... was that it is a "non profit" entity:
> 
> https://en.wikipedia.org/wiki/Merit_Network
> 
> Based on that one small scrap of information, I had incorrectly assumed
> that it was 100% free for people to add routes to the RADB.  But apparently
> not so!  Far from it!  I see now that the company charges a HEFTY annual
> membership fee to all those who want to put route objects in their data
> base:
> 
>For-Profit Organization$595.00 USD
>Non-Profit Organization$425.00 USD
> 
> That is a LONG way from free!
> 
> So, this certainly raises a number of (awkward?) questions, such as
> 
> (*)  Does RADB -remove- routes from their data base when someone
>  stops paying the annual membership fee?  (The evidence suggests
>  that they fail to do such cleanups.)

I strongly believe YES, route objects get removed.


> (*)  Will RADB allow paying members to add routes to bogon IP space,
>  and/or to bogon AS numbers?

Oh yes!
also space that is not theirs.

> Now that I know they charge BIG money for allowing people to add routes to
> their RADB data base, I must say that I do view their past unhelpfulness
> in a somewhat different light.

sure it would be different if you paid something.

> P.S.  Do dues-paying resource members of AFRINIC have to pay anything
> extra to get routes added to the AFRINIC IRR? 

no.
btw: also resource members who don't pay (like IXPs) get the IRR
functions for free.

> Or is that free as part
> of the basic membership services?

It is.

Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi,

On 25/07/2021 07:27, Ronald F. Guilmette wrote:
> In message 
> 
> Noah  wrote:
> 
>> On Sat, 24 Jul 2021, 10:44 Frank Habicht,  wrote:   # <-- 
>> yes
>>
following line needed to be deleted.
>>> On 23/07/2021 23:43, Ronald F. Guilmette wrote:
>>>
>>> I think nobody wants for ticket #755910 to become much older than half a
>>> year. #  <-- Frank wrote
>>
>>
>> Someone is paid a salary to respond to tickets and close them in time and
>> clearly someone has been sleeping on their job.
> 
> Please be careful with attribution when quoting email.  I did not write
> the quoted thing above.  (I think Frank did.)

correct.
and I agree: Noah, be more careful.

Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] All AFRINIC-administered IP space

[Frank Habicht]

On 23/07/2021 23:43, Ronald F. Guilmette wrote:
> This is rather incredible.  The world only has five RIRs, AFRINIC being
> one of them.  The IPv4 address space, the IPv6 address space, and the
> AS number space should thus each be carved up into 5 parts and each RIR
> should know, on a day-to-day basis, what parts they are responsible for.
> And each should be able to tell us what their part is on a daily basis.
> If they can't, then how can they hand out new resources??
> 
> This isn't rocket science.

I agree. this should be available and it should be possible to make this
happen.

I'm wondering whether the -delegated files contain the complete set of
what is under administration of AfriNIC (or whichever RIR).

But:
a) I don't like to wonder, so AfriNIC staff: please clarify this little
detail, but

b) more importantly, AfriNIC staff: please make a list of
AfriNIC-administered blocks [1] available online, also as CSV or
similar, in a format like the -delegated files or
https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space-2.csv

... and obviously tell us about it and make it all reachable/linked from
the website.

I think nobody wants for ticket #755910 to become much older than half a
year.

Thanks,
Frank


[1]
of all 3 resource types, I suggest.

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [Community-Discuss] Why does AFRINIC continue to violate the court order?

[Frank Habicht]

Hi Sylvain,

On 16/07/2021 22:36, Sylvain Baya wrote:
> Please download the file from AFRINIC:
> 
> https://ftp.afrinic.net/pub/pub/dbase/afrinic.db.gz
> 
> 
> 
> Could the DB manager, please, help us to do this?
> 

I don't understand what your request is.

Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Why does AFRINIC continue to violate the court order?

[Frank Habicht]

Hi Anthony,


On 17/07/2021 15:09, Anthony Ubah wrote:
> Dear AfriNIC Community,
> 
> While it is inappropriate to comment on the ongoing legal process
> between AFRINIC and Cloud Innovation, may I say that this litigation has
> more so highlighted a lot of rot on how AfriNIC's processes are run? 
> 
> Making some of these "errors" on a resource owner's database while their
> case is under the lens is quite absurd. These "errors" and delays can
> easily be termed dubious. 
> What else can be changed on the database of other resource owners, and
> to what extent of damages? 


Please check the email I just sent responding to Owen's email.

Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Why does AFRINIC continue to violate the court order?

[Frank Habicht]

Hi Owen,

On 16/07/2021 23:28, Owen DeLong via Community-Discuss wrote:
>>
>> As of 12:26 PM Mauritius time, Wed. July 14, 2021:
>>
>> whois -h whois.afrinic.net 
>> 154.88.0.0                                                   
>>                            2021/07/14 1:25:44
>> [...]
>>
>> inetnum:        154.88.0.0 - 154.88.0.255
>> netname:        CloudInnovation
>> descr:          CloudInnovation infrastructure
>> country:        US
>>
>>  
>>  
>>  ...is this not an evidence of a AIR (*American* 
>> Internet Registry) Org rather than a LIR? {or a GIR 
>> (Global Internet Registry)} :-/
> 
> The US Country code was inserted by AFRINIC when they defaced our whois
> records. It is not the original entry, so you will have to ask AFRINIC
> about its meaning and reasoning.
> 

I have downloaded the (anonymised) DB as of June 27th (downloaded on
that day), and I see the same "US" country code in there.

[frank@fisi afrinic_2021-06-27]$ l
total 123476
drwxrwxr-x.  2 frank frank  4096 Jun 27 17:49 .
drwxr-xr-x. 15 frank root   4096 Jun 27 17:48 ..
-rw-rw-r--.  1 frank frank 126427360 Jun 27 05:08 afrinic.db
[frank@fisi afrinic_2021-06-27]$ grep -A 5 '154.88.0.0' afrinic.db
inetnum:154.88.0.0 - 154.88.0.255
netname:CloudInnovation
descr:  CloudInnovation infrastructure
country:US
admin-c:CIS1-AFRINIC
tech-c: CIS1-AFRINIC
[frank@fisi afrinic_2021-06-27]$


I am assuming "when they defaced" referred to changes in this July ?


[frank@fisi afrinic_2021-06-27]$ whois -h whois.afrinic.net --
--list-versions 154.88.0.0/24
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use.
See https://afrinic.net/whois/terms

% Version history for INETNUM object "154.88.0.0 - 154.88.0.255"
% You can use "--show-version rev#" to get an exact version of the object.


rev#  Date  Op.

1 2013-08-01 09:54  ADD/UPD
2 2014-05-14 15:10  ADD/UPD
3 2016-04-16 09:48  ADD/UPD
4 2016-05-05 19:25  ADD/UPD
5 2021-07-08 20:23  ADD/UPD
6 2021-07-15 10:08  ADD/UPD



[frank@fisi afrinic_2021-06-27]$ whois -h whois.afrinic.net --
--show-version 4 154.88.0.0/24
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use.
See https://afrinic.net/whois/terms

% Version 4 of object "154.88.0.0 - 154.88.0.255"
% This version was a UPDATE operation on 2016-05-05 19:25
% You can use "--list-versions" to get a list of versions for an object.

inetnum:154.88.0.0 - 154.88.0.255
netname:CloudInnovation
descr:  CloudInnovation infrastructure
country:US
admin-c:CIS1-AFRINIC
tech-c: CIS1-AFRINIC
status: ASSIGNED PA
mnt-by: CIL1-MNT
mnt-routes: CIL1-MNT
source: AFRINIC # Filtered


Owen, is my data shown incorrect somewhere?

Thanks,
Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Final Call for Comments on Code of Conduct

[Frank Habicht]

Hi,

On 16/07/2021 16:49, AFRINIC Communication wrote:
> Dear Colleagues,
> 
> Consistent with the Governance Committee’s Terms of Reference 
> (https://afrinic.net/govcom#tor), the Committee had been requested by 
> AFRINIC’s Chief Executive Officer to review the current Code of Conduct. 
> 
> On 31 March 2021, a Call for Comments was launched for one month.
> 
> The Governance Committee has considered the input received from the Community 
> and thus proposes the following draft new Code of Conduct for the Community’s 
> final review which shall be open for 3 weeks. 
> 
> Please comment on: https://afrinic.net/20210714-call-for-comment

... which says: "Please use the comment feature at the bottom of this
page to submit your comments."

and there, in order to send something, I have to:
-  "LOG IN WITH" "D" (disqus) or "F" (facebook) or "T" (twitter),
 or "G" (google)
- OR: "SIGN UP WITH DISQUS"

can it please be made possible for an ordinary person to send a message
to AfriNIC directly without passing through third parties and forcing us
(interested parties) to subscribe to 3rd parties?


Thank you.
Frank

PS: is AfriNIC getting commission from these 3rd parties for our user data?

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

[Community-Discuss] The purpose

[Frank Habicht]

Hi.

Subject changed. used to be "Re: [rpd] More confusion from Noah"
Also, this is not about resource policy development, so trying to move
to community-discuss, as i think all participants are there.

On 10/07/2021 04:48, Owen DeLong via RPD wrote:
>> On Jul 4, 2021, at 04:38 , Noah > > wrote:
>> 3.4) The Company shall have, both within and outside the Republic of
>> Mauritius, full capacity to carry and/or undertake any business or
>> activity, including but not limited to the following objects:
>>
>>  1. to provide the service of allocating and registering Internet
>> resources for the purposes of enabling communications via open
 
>> system network protocols and to assist in the development and
>> growth of the Internet in the African region;
>>  2. to promote the representation of AFRINIC membership and the
>> Internet community of the African region by ensuring open and
>> transparent communication and consensus-driven decision-making
>> processes;
>>  3. to promote responsible management of Internet resources throughout
>> the African region, as well as the responsible development and
>> operation of Internet infrastructures;       
> 
> He didn’t skip it, [...] on members.
> 
> Not one of those sentences enables AFRINIC to exercise any form of
> extraordinary control over the types of use of numbers other than
> possibly the implied ability to reject utilization plans which clearly
> violate applicable law.

I'd like to disagree.
I tried to highlight "the purposes" in above quote under 1.


So AfriNIC has to check that allocated/assigned Internet resources are
used (or going to be used) for *the purposes* ... of enabling
communications 
[at allocation time, and optionally later]

And I think it is legally implied to mean that this means used by the
recipient (ie AfriNIC member) for these purposes. [1]

And I believe that any AfriNIC member requesting resources does justify
those by stating
- I need the resources for these and these devices and services of my
   own   (end user)
   or
- I need the resources for some purposes of my own (infrastructure) and
   for this number and type of Internet connectivity customers and for
   this number and type of hosting services customers   (LIR)

And I trust that then AfriNIC assigns/allocates resources for these
purposes to the member.

[
And when the member (LIR) changes the specific service from dialup
customer to DSL customer or from GPON customer to VM-hosting customer,
then it would still fit under the above set of justifications.
]

When a member however uses the resources for something else, NOT for
providing their own connectivity or hosting services, not for
sub-allocating to connectivity customers, but instead to other parties
not getting these services from the member, then in my opinion, the
member is not using the resources according to AfriNIC's mandate any more.

And people have been frank in these lists before: then the member is
using the resources only for the purpose of profit.

And some members justify this by calling the resources (ie IPv4
addresses) *their assets*.
I disagree.

The resources were given to the member for *the purposes* of providing
services by the member. I am sure you can read this in the
justifications for the applications for the resources that we are all
thinking about now.
I know that I'm not entitled to see these, and that's fine.

I think we all agree that for most LIR members the resources are given
for commercial activities, of a for-profit company.
But only as long as they are used for these activities of Internet
connectivity or hosting services - in my opinion; and apparently not in
the opinion of others.


If an IPv4 address block was assigned/allocated to a member for a
purpose - without transfer of ownership, then the member is in my
opinion not entitled to give/sell/lease/allocate the same to another
party. Can anybody advise how/when/where AfriNIC has handed that right
to the member?


I know some will say we are talking about integers, noone has the right
to integers, .
But:
* we're talking about a set of 2^32 integers that have to have the
property of being unique all around this Internet we try to keep working.
* These integers need to be registered


I want to clarify that I see and want to make a big difference between
the narrow and wider interpretation of the word "purpose" which I'm so
on about.
Narrow purpose: I use these IPv4 addresses for a pool of 200 dialup
customers in Dar es Salaam on a POP in Mikocheni.
Wider purpose: I use these IPv4 addresses for any of my Internet
connectivity services or hosting services (managed, VM, dedicated,...)
in the network coverage area of this company.

If the narrow purpose changes and the wider stays the same, I believe it
is common understanding that a justification for the resources remains.

If a use of resources changes from within the wider purpose to 

Re: [db-wg] Removal of bogon route objects

[Frank Habicht via db-wg]

Hi Ronald,

On 11/06/2021 11:24, Ronald F. Guilmette via db-wg wrote:
> iana|ZZ|ipv4|192.175.48.0|256|20150501|reserved|ietf|iana
> 
> In reality the block isn't reserved and it doesn't belong to IANA.
> It's a regular old (assigned) ARIN block.

I think it once *was* regular.
and then: https://datatracker.ietf.org/doc/html/rfc7534#section-7.2.3

I think AS112 has a little bit a "special" history.
Route Objects for 192.175.48.0 and AS112 are a good thing, I hope not
only in ARIN IRR.

Frank

Re: [nsd-users] Building Up DNS server with NSD; Migration

[Frank Habicht via nsd-users]

Hi Mukul,

it is good you shared some detail.

DNS has good ways of implementing redundancies and achieving high
availability.

You can set up new separate servers and test their functionality
thoroughly [like Kaulkwappe described], even before telling any outsider
about them.
I'm just afraid getting the necessary public IP (IPv4) addresses might
be an issue for you - if your organisation really only has 16  --  [1]

One of the important ways towards high availability is to *not* put all
the authoritative name servers in the same place (ie all eggs in the
same basket).
This seems to be the case currently [2].
More elaborate advise is in RFC2182 -- [3].

It looks like all current authoritative servers are in direct sequential
IP addresses and one could guess that probably the outage of one router
could cause all of them to become unreachable.
I'd try to get a friendly organisation or your upstream provider to
provide secondary name service for your domain(s). with automatic
updates of zone data / changes from you to that server.

This is of course not what you were asking (how to run *your* servers),
but valid consideration for the person/team responsible for the overall
availability of the domain in DNS.

But since this is the mailing list for NSD, I should mention that
another mailing list:
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
would be more appropriate for the general DNS questions.

Regards,
Frank

[1]
inetnum:14.139.250.80 - 14.139.250.95

[2]
dig sgsits.ac.in. ns

[3]
https://datatracker.ietf.org/doc/html/rfc2182



On 06/06/2021 22:16, Mukul Shukla via nsd-users wrote:
> Dear All,
> 
> Let me give me a little background as to what I am trying to achieve.
> 
> 1. The domain which I want the Authoritative Name serve  to serve for is
> sgsits.ac.in .
> 2. The ERNET India (ac.in ) is the domain name registrar
> for academic institutes here in India.
> 3. We are hosting our Website, Email and Moodle servers for which right
> now djbdns is acting as a authoritative name server.
> 4. Although, djbdns is working fine since last ten years (I must say its
> a brilliantly crafted  DNS server), it lacks some security features
> which are now a must (eg. DNSSEC).
> 5. I want to migrate this name server to NSD, with al the security
> feature and high availability so that it meets the current requirements.
> 
> Can anybody please tell me how to plan for this migration so that I have
> a minimum downtime. Moreover, I want to build a setup with NSD so that
> it runs smoothly for the next 10 years. Of course want to know how to
> keep on upgrading will be an issue, I need to consider.
> 
> I am reading the only source of information, the man pages on NLNET's
> website, although there are few tutorial available (eg. Calomel)
> 
> Thank you all.
> 
> Mukul
> 
> 
> 
> On Mon, Jun 7, 2021 at 12:02 AM Mukul Shukla  > wrote:
> 
> Hi Ondřej,
> 
> Thanks for such encouraging words.
> Gave me a lot of confidence.
> It's decided at my end. I will try to migrate my University DNS
> authoritative setup to much improved NSD setup, of course with the
> help of all the members here.
> Thanks again.
> 
> Mukul
> 
> On Sun, Jun 6, 2021 at 10:57 PM Ondřej Surý  > wrote:
> 
> Hi Mukul,
> 
> don’t worry - the community here is friendly and helpful and you
> should not run into any hard problems. Take it as an opportunity
> to learn something new!
> 
> Ondřej
> - former Knot DNS team lead
> - current BIND 9 team lead
> --
> Ondřej Surý mailto:ond...@sury.org>> (He/Him)
> 
>> On 6. 6. 2021, at 18:50, Mukul Shukla via nsd-users
>> > > wrote:
>>
>> 
>>
>> Dear All,
>>
>> There are very  few articles/tutorials on NSD. This is making
>> me nervous to adapt it for a long use. If I am stuck, there is
>> no help to refer to. Man pages are just not sufficient for the
>> people like me who don't have much experience of the system
>> administration and implementing DNS Authoritative Server in
>> particular. Other DNS implementations have very good manuals.
>> The kind of software NSD is, there should have been books
>> written on them.
>>
>> Mukul
>>
>> On Sun, Jun 6, 2021 at 9:06 PM Anand Buddhdev via nsd-users
>> > > wrote:
>>
>> On 06/06/2021 16:26, mj via nsd-users wrote:
>>
>> Hi MJ,
>>
>> > Actually: we are in a similar situation. We're currently
>> running bind9,
>> > and were interested in to switching to NSD for the
>> authorative dns
>> > services, but it seems that you have to compile newer
>> releases (with
>>  

Re: [RPKI-Discuss] [routing-wg] RPKI Route Origin Validation on RIPE NCC Network

[Frank Habicht]

Hi,

I think there are contradicting requirements
a) do the right thing, reject invalid, clean stable network
b) have more info about RPKI (invalids)

So I guess there could/should be a split into 2 ASes:
1. for corporate, office, servers, services, almost everything
2. for research department, also to be used by training

The (1.) "normal" network can go ahead drop invalids, secure network per
BCP.
The (2.) "research" network should try to get more BGP feeds, even from
providers who are not dropping invalids, at minimal bandwidth, and
possibly unrelated location.

So I'd say:
research: get your own ASN (and router)
training: tell research which data you need, let them get it

Regards,
Frank


On 04/06/2021 07:53, Musa Stephen Honlue wrote:
> Hi 
> 
> Sent from my iPhone
> 
>> On 3 Jun 2021, at 22:24, Patrick Okui  wrote:
>>
>> 
>>
>> On 3 Jun 2021, at 21:18 EAT, Carlos M. Martinez wrote:
>>
>> So, IMO, ROV (either rejecting invalids or doing what you think is
>> appropriate) is a distinct operation from creating ROAs and I
>> believe that at this point in time every resource holder should be
>> creating their ROAs, but implementing ROV is something that it
>> might or might not make sense to a particular network.
>>
>> Agreed, which is why I said “in general”. Security researchers for
>> example may want to ignore “valids” and mostly concentrate on “invalids”.
>>
>> However, if in general my ROAs do not result in a decent possibility
>> that a hijack will be dropped (until I go kicking and screaming) then
>> I have less incentive to create them. This is the chicken and egg
>> issue I’ve faced when preaching ROA generation.
>>
> I fully agree here.
> 
> I mean, what is the essence of creating ROAs if no one is using them to
> stop propagating hijacks?
>>
>> -- 
>> patrick
>>
>> ___
>> RPKI-Discuss mailing list
>> RPKI-Discuss@afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpki-discuss
> 
> ___
> RPKI-Discuss mailing list
> RPKI-Discuss@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpki-discuss
> 

___
RPKI-Discuss mailing list
RPKI-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpki-discuss

Re: [Community-Discuss] Fwd: [members-discuss] Unsolicited Requests

[Frank Habicht]

On 30/05/2021 11:33, Paschal Ochang wrote:
> Well said Ronald. Jordis point of disqualification sounds like the
> judge, jury and executioner and is hasty in all ramifications. Even if
> there were some facts to prove the points, it may be possible that the
> candidate is not even aware of such and is dragged down the drain and
> smeared in the mud. Who knows it may be a strategy to bring down the
> candidate.

and I asked 52h ago that he clarifies, on the [members-discuss] mailing
list.
If there's no response, you can assume the best, or the worst, or
anything in-between.
If we want board members to answer to the community (and to members), we
probably also want candidates to be willing to do the same.

Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [db-wg] BOGON => 103.86.68.0/22

[Frank Habicht via db-wg]

Hi Ronald,

I think it was this:
https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
and
https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006885.html
"If there is no objection from the DB-WG, I'd like to turn this proposal
into a Numbered Work Item."

ie: should be on the way to Numbered Work Item

Frank


On 27/05/2021 02:35, Ronald F. Guilmette via db-wg wrote:
> My apologies to all.  My interests and attention are getting pulled
> in so many different directions these days that I tend to forget the
> answers to questions that I seem to vaguely remember having already
> asked.
> 
> So, at the risk of repeating myself, what's the current policy on stale
> route objects in the data base that refer to current bogon address space?
> 
> I'm specifically interested in 103.86.68.0/22 at the moment.
> 
> route:  103.86.68.0/22
> origin: AS131477
> mnt-by: HUAJUAN-MJJ-MNT
> created:2018-02-24T19:00:10Z
> last-modified:  2018-09-04T19:09:05Z
> source: RIPE-NONAUTH
> 
> 

Re: [db-wg] Route objects for space administered by other RIRs

[Frank Habicht via db-wg]

On 12/05/2021 09:35, Edward Shryane wrote:
> The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH 
> which are not registered in *any* region:
> https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
> 
> The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is 
> registered to AFRINIC.

I see that now. my bad.
Frank

Re: [db-wg] Route objects for space administered by other RIRs

[Frank Habicht via db-wg]

Hi Ronald,

less than a week ago, on this same list there was the conclusion that
these route objects would be removed.
real-soon-now, is my understanding.

That should resolve *this* issue.
But I think the holders could then create a similar route object in
AfriNIC...


Another thing that confuses me:

[I see the inetnum object in AfriNIC, but:]

$ whois -h whois.iana.org 62.61.192.0
says one should look at RIPE whois for the whole /8

and
$ whois -h whois.ripe.net 62.61.192.0
says "nothing here - look at IANA"

shouldn't IANA point to AfriNIC??

Regards,
Frank

On 12/05/2021 03:06, Ronald F. Guilmette via db-wg wrote:
> Can anyone please explain to me, preferably using small words that
> I can understand, why route objects such as the following still exist
> in the data base at the present time?
> 
> route:  62.61.192.0/18
> descr:  SRR
> origin: AS49902
> mnt-by: CEGETEL_LA_REUNION
> created:2014-09-30T15:01:51Z
> last-modified:  2018-09-04T18:00:38Z
> source: RIPE-NONAUTH
> 
> (Please note that the whole of 62.61.192.0/18 currently appears to be
> under the administration of AFRINIC.)
> 
> I understand that pre-existing route objects within the RIPE data base
> that relate to IP space which is under the administration of other
> (non-RIPE) RIRs was set to "RIPE-NONAUTH" awhile back, which is
> certainly a Good Thing, but I wonder if there is a date certain by
> which even these route objects will be sunsetted and removed from the
> RIPE db.
> 
> 
> Regards,
> rfg
> 

Re: [DBWG] English variant for WG docs

[Frank Habicht]

Hi Ben,

while i'd personally prefer the language from the island closer to
Europe [ouch!]...

...i also did a cursory check in an official afrinic document (bylaws)
and found "African Network Information Centre", so apparently also
preferring GB.

Not wearing any chair hat here, so this is just one vote counting as
much as others.

Frank


On 18/03/2021 12:03, Ben Maddison via DBWG wrote:
> Hi all,
> 
> I've written a little tool to check style and spelling for working group
> docs, to keep the editorial workload to a minimum.
> 
> I need to choose an English dictionary variant to use.
> 
> Does this group prefer:
> 
> - en_US
> - en_GB
> - something else?
> 
> Fast responses greatly appreciated. I am writing several docs at the
> moment, and it's going to create lots of extra work to switch down the
> line.
> 
> Cheers,
> 
> Ben
> 
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] ORG-TYPE definitions

[Frank Habicht]

Dear AfriNIC team,

my initial reaction on reading the list was that I'm eager to know more
about what the plans for 'CLOSED' are. Can you explain more?

o 'CLOSED'
This represents organisations that were at one point an active AFRINIC
resource or associate member but no longer holds an active agreement
with AFRINIC. (No applicable use case in AFRINIC for now but to be put
to use soon).


Thanks,
Frank

On 26/02/2021 12:20, Frank Habicht wrote:
> the content of the PDF can really easily be shared as plain text as well:
> 
> Org-type Status Descriptions
> org-type can have one of these values:
> o 'IANA'
> This represents the Internet Assigned Numbers Authority. The Public
> Technical Identifiers (PTI) performs the IANA functions related to the
> global IP and AS number spaces, such as allocations made to Regional
> Internet Registries
> o 'RIR'
> This represents Regional Internet Registries only, these registries have
> a primary role of managing and distributing public Internet address
> space within their respective service regions.
> Currently, there are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC
> o 'LIR'
> This represents all the Local Internet Registries, these are Internet
> Registries that receive allocations from an RIR and primarily assign
> address space to their customers also called 'end-users'. Their
> customers are other ISPs and end-users
> o 'EU-PI'
> This represents all the organisations (End-Sites) who receive portable
> IP address space directly from the RIR to run their own networks. These
> addresses cannot be sub-delegated or reassigned outside these organisations.
> o 'EU-AS'
> This represents all the End-Sites holding only ASN resources received
> directly from the RIR.
> o 'MEMBER-ONLY'
> This represents a non-active organisation that holds no IP resources
> from the RIR.
> The organisation may have applied for membership or is no longer an
> AFRINIC Resource Member.
> o 'CLOSED'
> This represents organisations that were at one point an active AFRINIC
> resource or associate member but no longer holds an active agreement
> with AFRINIC. (No applicable use case in AFRINIC for now but to be put
> to use soon).
> o 'INACTIVE-MEMBER'
> No applicable use case in AFRINIC (can be removed)
> o 'NON-REGISTRY'
> No applicable use case in AFRINIC (can be removed)
> o 'OTHER'
> These organisations can be created by any person on the AFRINIC WHOIS
> database for the purpose of sub-allocation, but does not represent an
> AFRINIC Resource Member
> o 'REGISTERED-MEMBER'These represent AFRINIC Board Members holding office.
> o 'ASSOCIATE-MEMBER'
> This represents an individual person or corporate body or the public
> sector who have signed the Associate Membership Agreement
> 
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] ORG-TYPE definitions

[Frank Habicht]

On 26/02/2021 04:00, Nishal Goburdhan wrote:
> could you please post this in plain text.  some of us don’t click on
> random attachments (and it’s bad faith for you to propagate that notion ..)
> (i did run this through strings, but i want to be sure that what i read,
> was actually that which was published, before commenting)
> 

the content of the PDF can really easily be shared as plain text as well:

Org-type Status Descriptions
org-type can have one of these values:
o 'IANA'
This represents the Internet Assigned Numbers Authority. The Public
Technical Identifiers (PTI) performs the IANA functions related to the
global IP and AS number spaces, such as allocations made to Regional
Internet Registries
o 'RIR'
This represents Regional Internet Registries only, these registries have
a primary role of managing and distributing public Internet address
space within their respective service regions.
Currently, there are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC
o 'LIR'
This represents all the Local Internet Registries, these are Internet
Registries that receive allocations from an RIR and primarily assign
address space to their customers also called 'end-users'. Their
customers are other ISPs and end-users
o 'EU-PI'
This represents all the organisations (End-Sites) who receive portable
IP address space directly from the RIR to run their own networks. These
addresses cannot be sub-delegated or reassigned outside these organisations.
o 'EU-AS'
This represents all the End-Sites holding only ASN resources received
directly from the RIR.
o 'MEMBER-ONLY'
This represents a non-active organisation that holds no IP resources
from the RIR.
The organisation may have applied for membership or is no longer an
AFRINIC Resource Member.
o 'CLOSED'
This represents organisations that were at one point an active AFRINIC
resource or associate member but no longer holds an active agreement
with AFRINIC. (No applicable use case in AFRINIC for now but to be put
to use soon).
o 'INACTIVE-MEMBER'
No applicable use case in AFRINIC (can be removed)
o 'NON-REGISTRY'
No applicable use case in AFRINIC (can be removed)
o 'OTHER'
These organisations can be created by any person on the AFRINIC WHOIS
database for the purpose of sub-allocation, but does not represent an
AFRINIC Resource Member
o 'REGISTERED-MEMBER'These represent AFRINIC Board Members holding office.
o 'ASSOCIATE-MEMBER'
This represents an individual person or corporate body or the public
sector who have signed the Associate Membership Agreement


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [Community-Discuss] Breach of the Code of Conduct by Mr Ronald Guilmette

[Frank Habicht]

Hi,

On 25/02/2021 21:33, Sylvain Baya wrote:
> ...out of the right to be forgotten [1]; which i 
> think we should first agree on its applicability into 
> our midst :-/
> 
> Is modifying a public mailinglist archive a good practice?
> __
> [1]:  >

I would treat the mailing list archives as a historic record.
Somebody has volunteered information, contributions, to the mailing
list, knowing that there would be an archive.

I believe if I put my name into the newspaper, then I don't have the
right to be forgotten.

Any attempt to modify the mailing list archives is in my opinion
comparable to some lost people trying to revise or deny historic facts,
or to the poor fellow who thinks that his inauguration audience was
bigger. It should not be allowed.

Thanks,
Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Blog: A Comprehensive audit of the AFRINIC WHOIS Database

[Frank Habicht]

On 13/02/2021 14:58, Ronald F. Guilmette wrote:
> In message <56ff34f4-04c8-48f3-bfc6-699669f55...@delong.com>, 
> Owen DeLong  wrote:
>> However, unannounced legacy resources are mostly in an unknown state of
>> utilization and it is essentially impossible to determine whether or not
>> they are actually in use.
> 
> I only wish that I had the first clue about what you are going on about
> here Owen.
> 
> If a tree falls in the forest, and if it is not routed on the public
> Internet, then why should I or anybody else give a damn about what
> you do in the privacy of your own intranet?  Your private intranet
> and what you do on it is of no concern whatsoever to the actual
> Internet community.  Nor does the administration of publicly routable
> IP addresses by the various RIRs have any bearing on what you elect
> to do on your own private intranet.

Hi Ronald,
I don't think it works like this.
Consider this:
There's an organisation headquartered in a building with 5 corners in
Arlington Virginia, about 23.9 miles (drive) from ARIN HQ (says Google
maps).
Let's call them "DOD".
They have legacy IP space and are not advertising some of it to the
public internet. [1]

If you go and tell ARIN you don't "give a damn" and ask ARIN they should
assign/allocate this to other deserving recipients, I believe the answer
will be a better formulation of "Hell NO".
But I don't want to talk for ARIN.

I think that's an example of what Owen talked about.
But hell, I also don't want to talk for Owen.

Frank

[1]
they might be using some of that "internally"

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Notice to all the legacy netblocks holders in AfriNIC

[Frank Habicht]

Hi,

On 05/02/2021 16:43, Owen DeLong wrote:
> Originally, the space was used for some rather specialized connectivity
> services. Due to changes in the market and the legal environment, those
> services became less lucrative and the organization pivoted. 
> 
> Hardly any organization that has been in this business for more than 10
> years is using every address they have for the exact purpose for which
> it was approved. 

True.
And i just stumbled upon many sections in
https://afrinic.net/membership/agreements?lang=en#rsa
where this is not permitted [1]
So I view this as you advocating a "flexible" interpretation...

> None the less, delegating addresses to customers for their legitimate
> use as unique internet addresses remains the primary purpose of any IR
> whether it be regional, national, or local. 

here comes the danger of mixing LIR and non-LIR ...

> There exists no requirement in policy that such delegations involve
> connectivity services.

For LIR: [1]

> In fact, no RIR provides connectivity services to
> any of the organizations it issues addresses to. 

I think noone was talking about RIRs [2]

> Certainly, if such a requirement were intended, it could have been
> written into the policy. 

... and here I see a more strict interpretation
  ^^

Frank

[1]
The Applicant hereby irrevocably:
(i) Commits itself to using the services solely for the purpose for
which it was requested.

[2]
https://lists.afrinic.net/pipermail/community-discuss/2021-February/003901.html

> FWIW, an LIR in Afrinic documentation means: “Any Network Operator
> that provides Internet services to distinct end-users and end-sites.”
> In the same context, LIRs are allocated IPv4 space of type Provider
> Aggregatable “Allocated PA”.
Yes.
(that's your paragraph I responded to)

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Notice to all the legacy netblocks holders in AfriNIC

[Frank Habicht]

Owen???

On 05/02/2021 14:53, AFRINIC Communication wrote:
> Dear Frank,
> 
> AFRINIC  has not approved any application for IP space for the
> purpose of leasing despite having received such requests.
> 
> Regards,
> 
> Ashil
> 
>> On 05/02/2021 03:56, Owen DeLong wrote:
>>> Yes. It does not specify the type of internet services. Are you
>>> arguing that the leasing of address blocks is not an internet
>>> service?


Thanks Ashil!

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Notice to all the legacy netblocks holders in AfriNIC

[Frank Habicht]

Hi Owen,

On 05/02/2021 03:56, Owen DeLong wrote:
> 
> 
>> On Feb 2, 2021, at 4:29 AM, Noah > > wrote:

>> FWIW, an LIR in Afrinic documentation means: “*Any Network Operator
>> that provides Internet services to distinct end-users and end-sites.*”
>> In the same context, LIRs are allocated  IPv4 space of type Provider
>> Aggregatable “Allocated PA”.
> 
> Yes. It does not specify the type of internet services. Are you arguing
> that the leasing of address blocks is not an internet service?

My initial 'gut' response was "YES" - leasing is not a service as
intended. But: I didn't check the scripture, IANAL, and I don't want to
get into *that* discussion.

But I have just one question:

Is *leasing* the kind of use, for which the IP space was applied for and
justified?


AfriNIC staff: has any LIR applied for IP space for the purpose of
*leasing* and received IP address space?

Thanks,
Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [db-wg] Deprecation of whitepages

[Frank Habicht via db-wg]

Hi,

On 28/01/2021 13:53, denis walker via db-wg wrote:
> I think we should now deprecate this concept. LinkedIn is much more
> suited to keeping in touch with networking people. Comments
> appreciated...

I support the cleanup.
Frank

PS: what's LinkedIn ?
;-)

Re: [db-wg] Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed

[Frank Habicht via db-wg]

Hi,

On 21/01/2021 01:27, Nick Hilliard via db-wg wrote:
> 196.52.0.0/14 seems to have been revoked by afrinic:
> 
>> $ whois -h whois.afrinic.net " --list-versions 196.52.0.0/14" | grep -i 
> delete
>> % This object was deleted on 2021-01-16 05:56
>> $
> 
> Regarding cleanup of route: objects for this this (and other)
> unregistered address space in the ripe irrdb, can this just be done? Or
> is it necessary to create a policy to ask the NCC to do it?

would like that too (to get done, and if policy needed clarity about it)
https://www.ripe.net/ripe/mail/archives/db-wg/2020-September/006645.html

Frank

Re: [Community-Discuss] Yet more data base problems/inconsistancies

[Frank Habicht]

Hi,

On 06/11/2020 01:55, Ronald F. Guilmette wrote:
> In message , 
> Frank Habicht  wrote:
> 
>> in the file i found:
>> ; Source AFRINIC
>> 203.196.in-addr.arpa. NSns1.ati.tn.
>> 203.196.in-addr.arpa. NSns2.ati.tn.
>>
>> if there is a delegation for the "/16 equivalent" then one can't create
>> a delegation for an enclosed "/24 equivalent" zone. [1]
>>
>> So probably the
>>> domain: 35.203.196.in-addr.arpa
>> object shouldn't have been allowed to be created / imported from RIPE...
> 
> Let me just say at the outset that I may perhaps not be on entirely
> solid ground here... I may need to drag out my Cricket book and double
> check this... but my belief at the moment is that what you just said
> is not actually correct, that DNS is a bit like routing, where a more
> specific can effectively override a less specific, and that there is
> nothing to prevent separate and different delegations to both a
> containing /16 and also to a /24 within that /16.

I have no idea why Cricket    ;-)
But have to say I agree.
I was writing what I was writing based on the 2nd paragraph from Anand in
https://www.ripe.net/ripe/mail/archives/db-wg/2020-October/006687.html
which maybe I have misinterpreted.


> Regardless of whether that is correct or not, as I have already noted,
> there is clearly a mismatch between what is present in the AFRINIC
> WHOIS data base and the data that is present within the various files
> within ftp://ftp.afrinic.net/pub/zones/ and this mismatch, this
> anomaly, should be addressed in some manner, either by removing invalid
> entries from the WHOIS or by adding entries to the zone files.

Completely agree.

Frank


___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Yet more data base problems/inconsistancies

[Frank Habicht]

Hi Ronald,

in the file i found:
; Source AFRINIC
203.196.in-addr.arpa. NSns1.ati.tn.
203.196.in-addr.arpa. NSns2.ati.tn.

if there is a delegation for the "/16 equivalent" then one can't create
a delegation for an enclosed "/24 equivalent" zone. [1]

So probably the
> domain: 35.203.196.in-addr.arpa
object shouldn't have been allowed to be created / imported from RIPE...

Frank

[1]
see Randy on RIPE-DB recently


On 05/11/2020 18:00, Ronald F. Guilmette wrote:
> In addition to the problem I have just posted about i.e. the problem of
> dublicate (and inconsistant) records in the WHOIS describing various
> reverse DNS delegations, I am also seeing something else that I did not
> anticipate, i.e. reverse DNS delegation records that are present within
> the WHOIS data base, but which, for no very obvious reason, are *not*
> also represented within the set of zone files present within the
> ftp://ftp.afrinic.net/pub/zones/ directory.
> 
> I here provide one example:
> 
> domain: 35.203.196.in-addr.arpa
> descr:  reverse delagation for the
> descr:  HEXABYTE-10 dial-UP elmanzah
> org:ORG-ATIA2-AFRINIC
> admin-c:PA1317-AFRINIC
> tech-c: LD822-AFRINIC
> zone-c: LD822-AFRINIC
> nserver:ns1.hexabyte.tn
> nserver:ns2.hexabyte.tn
> remarks:data has been transferred from RIPE Whois Database 20050221
> notify: ***@ati.tn
> mnt-by: ATI-MNT
> mnt-lower:  ATI-MNT
> changed:***@ati.tn 20040322
> changed:***@afrinic.net 20050221
> changed:***@ati.tn 20140520
> changed:***@ati.tn 20181023
> source: AFRINIC
> 
> The above reverse DNS delegation record in in the WHOIS data base but it
> appears to me that it has no corresponding counterpart within this file:
> 
> ftp://ftp.afrinic.net/pub/zones/196.in-addr.arpa-AFRINIC
> 
> So, either this is due to some misunderstanding I am having regarding
> what shiould be persent in that zone file, or else that zone file is
> incomplete.
> 
> I am looking forward to having someone in authority tell me which is
> actually the case.
> 
> If in fact a record describing the delegation shown above should in fact
> be represented within the zone file, and if it is improperly missing
> from that file, then it would seem to have a LOT of company.   In fact,
> the entire list below of some 1,952 specific delegations are all mentioned
> within the WHOIS data base but as far as I can tell, none of them are
> mentioned within the file in the ftp://ftp.afrinic.net/pub/zones/ directory.
> 
> 
> 196.203.0 ns4.ati.tn
> 196.203.0 ns6.ati.tn
> 217.52.0 ns.aucegypt.edu
> 217.52.0 ns3.aucegypt.edu
> 196.203.1 ns4.ati.tn
> 196.203.1 ns6.ati.tn
> 217.52.1 ns.aucegypt.edu
> 217.52.1 ns3.aucegypt.edu
> 62.139.104 ns1.nile-online.net
> 62.139.104 ns2.nile-online.net
> 62.139.105 ns1.nile-online.net
> 62.139.105 ns2.nile-online.net
> 62.139.109 ns1.nile-online.net
> 62.139.109 ns2.nile-online.net
> 62.139.130 ns1.nile-online.net
> 62.139.130 ns2.nile-online.net
> 196.203.2 ns4.ati.tn
> 196.203.2 ns6.ati.tn
> 217.52.2 ns.aucegypt.edu
> 217.52.2 ns3.aucegypt.edu
> 62.139.253 ns2.egynet.com.eg
> 62.139.253 ns22.egynet.com.eg
> 217.52.3 ns.aucegypt.edu
> 217.52.3 ns3.aucegypt.edu
> 196.203.32 ns4.ati.tn
> 196.203.32 ns6.ati.tn
> 196.203.33 ns4.ati.tn
> 196.203.33 ns6.ati.tn
> 196.203.34 ns4.ati.tn
> 196.203.34 ns6.ati.tn
> 196.203.35 ns1.hexabyte.tn
> 196.203.35 ns2.hexabyte.tn
> 196.203.36 ns4.ati.tn
> 196.203.36 ns6.ati.tn
> 217.52.4 ns.aucegypt.edu
> 217.52.4 ns3.aucegypt.edu
> 217.52.5 ns.aucegypt.edu
> 217.52.5 ns3.aucegypt.edu
> 217.52.6 ns.aucegypt.edu
> 217.52.6 ns3.aucegypt.edu
> 217.52.7 ns.aucegypt.edu
> 217.52.7 ns3.aucegypt.edu
> 217.52.8 ns.aucegypt.edu
> 217.52.8 ns3.aucegypt.edu
> 196.205.11 ns1.link.net
> 196.205.11 ns2.link.net
> 212.0.159 sun1.sudatel.net
> 212.0.148 ns1.sudanmail.net
> 212.0.148 ns2.sudanmail.net
> 212.0.129 main.sdn-mobitel.com
> 212.0.129 main.sdn-mobinet.net
> 196.202.144 ns1.sudacom.net
> 196.202.144 ns2.sudacom.net
> 196.202.145 ns1.sudacom.net
> 196.202.145 ns2.sudacom.net
> 212.0.138 sun1.sudanet.net
> 212.0.146 sun1.sudanet.net
> 163.196 ns1.qdata.net
> 163.196 ns2.qdata.net
> 196.25.226 igubu.saix.net
> 196.25.226 sangoma.saix.net
> 196.205.177 ns1.link.net
> 196.205.177 ns2.link.net
> 196.205.0 ns1.link.net
> 196.205.0 ns2.link.net
> 196.205.1 ns1.link.net
> 196.205.1 ns2.link.net
> 196.205.2 ns1.link.net
> 196.205.2 ns2.link.net
> 196.205.3 ns1.link.net
> 196.205.3 ns2.link.net
> 196.205.4 ns1.link.net
> 196.205.4 ns2.link.net
> 196.205.5 ns1.link.net
> 196.205.5 ns2.link.net
> 196.205.6 ns1.link.net
> 196.205.6 ns2.link.net
> 196.205.7 ns1.link.net
> 196.205.7 ns2.link.net
> 196.205.8 ns1.link.net
> 196.205.8 ns2.link.net
> 196.205.9 ns1.link.net
> 196.205.9 ns2.link.net
> 196.205.10 ns1.link.net
> 196.205.10 ns2.link.net
> 196.205.12 ns1.link.net
> 196.205.12 ns2.link.net
> 196.205.13 

[DBWG] inconsistency?

[Frank Habicht]

Hi Staff,

assuming "EU-AS" means an end-user resource member of AfriNIC with only
AS ("aut-num") and *not* IP resources,

organisation:   ORG-UCT1-AFRINIC
org-name:   University of Cape Town
org-type:   EU-AS

inet6num:   2001:43f8:70::/45
netname:UCT-IPV6-PI1
descr:  University of Cape Town
country:ZA
org:ORG-UCT1-AFRINIC

inetnum:197.239.128.0 - 197.239.191.255
netname:UCT-ResNet
descr:  University of Cape Town
country:ZA
org:ORG-UCT1-AFRINIC
[parent is the /8]

inetnum:196.47.192.0 - 196.47.255.255
netname:UCT-Wireless
descr:  University of Cape Town
country:ZA
org:ORG-UCT1-AFRINIC
[parent is the /8]



it also seems ORG (type EU-AS) ORG-TA29-AFRINIC has no resources at all...
same: ORG-ACoS1-AFRINIC
same: ORG-SP1-AFRINIC

ORG-MIXP1-AFRINIC (type EU-AS) also has IPs.
also: ORG-TJSE1-AFRINIC

no, this list is not complete.
I only checked some where i felt like...

Greetings,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] actual existing org-type values

[Frank Habicht]

Hi!
Frank again ;-)

number of actual org-type values existing (not checking and really
hoping these are only in 'organisation' objects)

$ egrep '^org-type' afrinic.db | sort | uniq -c
  6 org-type:   ASSOCIATE-MEMBER
 94 org-type:   EU-AS
634 org-type:   EU-PI
  1 org-type:   IANA
   1895 org-type:   LIR
 84 org-type:   MEMBER-ONLY
  1 org-type:   NON-REGISTRY
  1 org-type:   other
 10 org-type:   OTHER
  8 org-type:   REGISTERED-MEMBER
  5 org-type:   RIR

request:
can the one organisation be changed from org-type 'other' to org-type
'OTHER' ?

Or better remove, if it's just a duplication of 'ORG-ZZ8-AFRINIC' and
the resource-member agrees?

Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] ORG-TYPE definitions

[Frank Habicht]

Hi Madhvi,

thanks for your email.
it corrects my perception. [and i am happy that i brought it up]

I guess that we can expect both items to be done within the coming week.

Regards,
Frank

On 04/10/2020 20:45, Madhvi Gokool wrote:
> Hello Frank
> 
> The commitment was for staff to provide a definition of the org-types to
> the database working group and I further added that the definitions
> should then be made available when we perform a whois query. This way,
> they shall be publicly available to any person wanting to know what each
> org type means .
> 
> Logically it shall happen as follows :-
> 
> 1. The org-types  definition will be provided to the database working group
> 
> 2. The whois database will be updated with the definitions so that they
> are then visible through the query whois -v organisation
> 
> Regards
> 
> Madhvi
> 
> On 04/10/2020 9:10 PM, Frank Habicht wrote:
>> Hi all,
>>
>> so, in order to try to start chop away from all the pending items from
>> the meeting:
>>
>> there was a request (from SM, iirc) about the exact definitions what the
>> different 'org-type:' attribute values are and what the definitions are,
>> when to use which.
>>
>> Iirc, Madhvi responded that these can be obtained through whois queries.
>>
>> I just tried and reached as far as getting an (apparently authoritative)
>> list of possible values. (below)
>>
>> I didn't find any definitions as to which value is to be used for which
>> ORG. Can staff (maybe Madhvi) point us in the right direction?
>> Also: if it involves the manual (which was noted to have outdated info),
>> please confirm how current the referenced info/definitions are.
>>
>> Thanks,
>> Frank
>>
>>
>> [frank@fisi ~]$ whoisaf -- -v organisation
>> [Querying whois.afrinic.net]
>> [whois.afrinic.net]
>> % This is the AfriNIC Whois server.
>>
>> The organisation class:
>>
>>   The organisation class provides information identifying
>>   an organisation such as a company, charity or university,
>>   that is a holder of a network resource whose data is stored
>>   in the whois database.
>>   Organisation objects are not created automatically, but are forwarded
>>   to AfriNIC Database Administration (afrinic-...@rafrinic.net).
>>
>> organisation:   [mandatory]  [single] [primary/lookup key]
>> org-name:   [mandatory]  [single] [lookup key]
>> org-type:   [mandatory]  [single] [ ]
>> descr:  [optional]   [multiple]   [ ]
>> country:[mandatory]  [multiple]   [ ]
>> remarks:[optional]   [multiple]   [ ]
>> address:[mandatory]  [multiple]   [ ]
>> phone:  [optional]   [multiple]   [ ]
>> fax-no: [optional]   [multiple]   [ ]
>> e-mail: [mandatory]  [multiple]   [lookup key]
>> org:[optional]   [multiple]   [inverse key]
>> admin-c:[optional]   [multiple]   [inverse key]
>> tech-c: [optional]   [multiple]   [inverse key]
>> ref-nfy:[optional]   [multiple]   [inverse key]
>> mnt-ref:[mandatory]  [multiple]   [inverse key]
>> notify: [optional]   [multiple]   [inverse key]
>> abuse-mailbox:  [optional]   [multiple]   [inverse key]
>> mnt-by: [mandatory]  [multiple]   [inverse key]
>> changed:[mandatory]  [multiple]   [ ]
>> source: [mandatory]  [single] [ ]
>>
>> The content of the attributes of the organisation class are defined below:
>>
>> .
>> org-type
>>
>>Specifies the type of the organisation. The possible values are 'IANA'
>>for Internet Assigned Numbers Authority, 'RIR' for Regional Internet
>>Registries, 'NIR' for National Internet Registries and 'LIR' for Local
>>Internet Registries.
>>
>>  org-type can have one of these values:
>>
>>  o 'IANA'
>>  o 'RIR'
>>  o 'LIR'
>>  o 'EU-PI'
>>  o 'EU-AS'
>>  o 'MEMBER-ONLY'
>>  o 'CLOSED'
>>  o 'INACTIVE-MEMBER'
>>  o 'NON-REGISTRY'
>>  o 'OTHER'
>>  o 'REGISTERED-MEMBER'
>>  o 'ASSOCIATE-MEMBER'
>>
>>
>> ___
>> DBWG mailing list
>> DBWG@afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
> 
> 
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] ORG-TYPE definitions

[Frank Habicht]

Hi all,

so, in order to try to start chop away from all the pending items from
the meeting:

there was a request (from SM, iirc) about the exact definitions what the
different 'org-type:' attribute values are and what the definitions are,
when to use which.

Iirc, Madhvi responded that these can be obtained through whois queries.

I just tried and reached as far as getting an (apparently authoritative)
list of possible values. (below)

I didn't find any definitions as to which value is to be used for which
ORG. Can staff (maybe Madhvi) point us in the right direction?
Also: if it involves the manual (which was noted to have outdated info),
please confirm how current the referenced info/definitions are.

Thanks,
Frank


[frank@fisi ~]$ whoisaf -- -v organisation
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.

The organisation class:

  The organisation class provides information identifying
  an organisation such as a company, charity or university,
  that is a holder of a network resource whose data is stored
  in the whois database.
  Organisation objects are not created automatically, but are forwarded
  to AfriNIC Database Administration (afrinic-...@rafrinic.net).

organisation:   [mandatory]  [single] [primary/lookup key]
org-name:   [mandatory]  [single] [lookup key]
org-type:   [mandatory]  [single] [ ]
descr:  [optional]   [multiple]   [ ]
country:[mandatory]  [multiple]   [ ]
remarks:[optional]   [multiple]   [ ]
address:[mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]
e-mail: [mandatory]  [multiple]   [lookup key]
org:[optional]   [multiple]   [inverse key]
admin-c:[optional]   [multiple]   [inverse key]
tech-c: [optional]   [multiple]   [inverse key]
ref-nfy:[optional]   [multiple]   [inverse key]
mnt-ref:[mandatory]  [multiple]   [inverse key]
notify: [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by: [mandatory]  [multiple]   [inverse key]
changed:[mandatory]  [multiple]   [ ]
source: [mandatory]  [single] [ ]

The content of the attributes of the organisation class are defined below:

.
org-type

   Specifies the type of the organisation. The possible values are 'IANA'
   for Internet Assigned Numbers Authority, 'RIR' for Regional Internet
   Registries, 'NIR' for National Internet Registries and 'LIR' for Local
   Internet Registries.

 org-type can have one of these values:

 o 'IANA'
 o 'RIR'
 o 'LIR'
 o 'EU-PI'
 o 'EU-AS'
 o 'MEMBER-ONLY'
 o 'CLOSED'
 o 'INACTIVE-MEMBER'
 o 'NON-REGISTRY'
 o 'OTHER'
 o 'REGISTERED-MEMBER'
 o 'ASSOCIATE-MEMBER'


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [db-wg] NWI reviews: NWI-3 - Afrinic IRR Homing

[Frank Habicht via db-wg]

Hi,

On 30/09/2020 23:07, Job Snijders via db-wg wrote:
> There is nothing left for RIPE to further improve here.  RIPE-NONAUTH is
> slowly and steadily decreasing in size. AFRINIC resource holders have
> all the tools available to publish their routing intentions in either
> the AFRINIC IRR or under the AFRINIC RPKI TAL.
> 
> NWI-3 can be closed.

Yes.

but slightly different topic:
if an inetnum from AfriNIC gets reclaimed by AfriNIC (with consent of
the holder, not that it matters), can the route object from RIPE-NONAUTH
get deleted?
assuming maintainer access is lost - person left company, for years no
RIPE DB activity.
In fact: I (upstream) asked NCC to delete, and got a "no". (understandable)

In the meantime the inetnum got deleted in AfriNIC.
Should I try again?

For the possible benefit of one single prefix getting out of IRRs and
not getting added into lots of filters all over the world?

real case:  196.10.147.0/24
http://irrexplorer.nlnog.net/search/196.10.147.0/24

I feel without some help RIPE-NONAUTH will not drain enough.

Frank Habicht
Tanzania

PS: sorry for thread hijacking
feel free to change subject:

Re: [DBWG] Register for the AFRINIC Database Working Group Session

[Frank Habicht]

Hi DBWG,

This is to remind that today 9:00am UTC we'll meet online using zoom.


for preparation, minutes of the last meeting can be accessed at:
https://lists.afrinic.net/pipermail/dbwg/attachments/20191217/8cc76ccd/attachment-0003.pdf

Regards,
Frank
co-chair


On 24/09/2020 12:28, Simon Seruyinda wrote:
> Dear colleagues,
> 
> The AFRINIC Database Working Group (DBWG) is pleased to invite you to a 
> working session on whois database issues.
> 
> The session aims to discuss whois database issues and gather ideas  and 
> feedback from the community on how we can improve the database.
> 
> Date: 30 September 2020
> 
> Time: 09:00 - 13:30  UTC
> 
> Register here: 
> 
>  
> 
> The agenda for the event is as follows:
> 
> 1. Introductory remarks
> 2. Agenda discussion and confirmation 
> 3. Discussion of Working Group  procedures
> 4. 2nd co-chair election or nomination
> 5. Review of previous Database Working Group session minutes
> 6. Update from the AFRINIC Applications unit
> 7. Update from AFRINIC Member Services department on database accuracy 
> improvement
> 
> Break: 20 mins
> 
> 8. Database security enhancement proposal
> 9. Database Working Group work items
> 10. Presentation from other Working Group members
> 11. RPKI ANS0 implementation plan presented by Research & Innovation team
> 12. AOB
> 
> We look forward to your registration and active participation in the session.
> 
> Kind Regards;
> Simon
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] object from dump not showing in whois

[Frank Habicht]

Thanks.
Sounds good to me.

Frank

On 24/09/2020 11:14, Simon Seruyinda wrote:
> Dear Frank,
> 
> Thank you for pointing this out. We have done some investigation and we found 
> that the domain objects with the trailing dot were all created in 2005. This 
> is likely because the old version of the database did not have the syntax 
> checks that exist now.
> The version with the trailing dot stayed in the database because its not 
> recognised any more by the WHOIS during removal of child objects
> These objects currently cannot be queried via port 43 because the WHOIS 
> automatically removes any trailing dot from the key.  Its also not possible 
> to delete them using the syncupdates for the same reason. We shall therefore 
> use a Database Migration job to clean them out.
> Development on this will begin very soon and we should have them cleaned out 
> by end of October 2020.
> We shall update you incase the timelines change.
> 
> Kind regards;
> Simon.
> 
> 
>> On 13 Sep 2020, at 22:08, Frank Habicht  wrote:
>>
>> Hi AfriNIC Staff,
>>
>> We cleaned up all domains objects for non-assigned/non-allocated
>> inet[6]num ?
>>
>> In today's DB dump on FTP I see:
>>
>>
>> domain: 0.216.196.in-addr.arpa.
>> descr:  -
>> descr:  Temporarily registered for the
>> descr:  assignment of a IP addresses
>> descr:  to be used in the ISOC-ccTLD
>> descr:  Training : 12-15th Sept 2005
>> descr:  -
>> org:ORG-KNIC1-AFRINIC
>> admin-c:KNIC1-AFRINIC
>> tech-c: KNIC1-AFRINIC
>> zone-c: KNIC1-AFRINIC
>> nserver:noc.cctkd.or.ke
>> nserver:a.ns.hopcount.ca
>> mnt-by: AFRINIC-HM-MNT
>> changed:***@afrinic.net 20050912
>> source: AFRINIC
>>
>> and the inetnum doesn't exist.
>>
>>
>> Does this show that the ones ending with 'arpa' were removed and the
>> ones ending with 'arpa\.' were not removed?
>>
>>
>> there are many domains duplicated with both versions.
>>
>>
>> Regards,
>> Frank
>>
>>
>> [frank@fisi db_2020-09-13]$ egrep
>> '^domain.*16.\.2\.196\.in-addr\.arpa\.?$' afrinic.db
>>
>> domain: 160.2.196.in-addr.arpa.
>> domain: 161.2.196.in-addr.arpa.
>> domain: 162.2.196.in-addr.arpa.
>> domain: 163.2.196.in-addr.arpa.
>> domain: 164.2.196.in-addr.arpa.
>> domain: 165.2.196.in-addr.arpa.
>> domain: 166.2.196.in-addr.arpa.
>> domain: 167.2.196.in-addr.arpa.
>> domain: 168.2.196.in-addr.arpa.
>> domain: 169.2.196.in-addr.arpa.
>> domain: 160.2.196.in-addr.arpa
>> domain: 161.2.196.in-addr.arpa
>> domain: 162.2.196.in-addr.arpa
>> domain: 163.2.196.in-addr.arpa
>> domain: 164.2.196.in-addr.arpa
>> domain: 165.2.196.in-addr.arpa
>> domain: 166.2.196.in-addr.arpa
>> domain: 167.2.196.in-addr.arpa
>> domain: 168.2.196.in-addr.arpa
>> domain: 169.2.196.in-addr.arpa
>> [frank@fisi db_2020-09-13]$ egrep
>> '^domain.*17.\.2\.196\.in-addr\.arpa\.?$' afrinic.db
>>
>> domain: 170.2.196.in-addr.arpa.
>> domain: 171.2.196.in-addr.arpa.
>> domain: 172.2.196.in-addr.arpa.
>> domain: 173.2.196.in-addr.arpa.
>> domain: 174.2.196.in-addr.arpa.
>> domain: 175.2.196.in-addr.arpa.
>> domain: 176.2.196.in-addr.arpa.
>> domain: 177.2.196.in-addr.arpa.
>> domain: 178.2.196.in-addr.arpa.
>> domain: 179.2.196.in-addr.arpa.
>> domain: 170.2.196.in-addr.arpa
>> domain: 171.2.196.in-addr.arpa
>> domain: 172.2.196.in-addr.arpa
>> domain: 173.2.196.in-addr.arpa
>> domain: 174.2.196.in-addr.arpa
>> domain: 175.2.196.in-addr.arpa
>> domain: 176.2.196.in-addr.arpa
>> domain: 177.2.196.in-addr.arpa
>> domain: 178.2.196.in-addr.arpa
>> domain: 179.2.196.in-addr.arpa
>> [frank@fisi db_2020-09-13]$ egrep
>> '^domain.*18.\.2\.196\.in-addr\.arpa\.?$' afrinic.db
>>
>> domain: 180.2.196.in-addr.arpa.
>> domain: 181.2.196.in-addr.arpa.
>> domain: 182.2.196.in-addr.arpa.
>> domain: 183.2.196.in-addr.arpa.
>> domain: 184.2.196.in-addr.arpa.
>> domain: 185.2.196.in-addr.arpa.
>> domain

Re: [DBWG] duplicate domain objects

[Frank Habicht]

Hi Simon,

On 24/09/2020 11:07, Simon Seruyinda wrote:
>> Would disallowing and deleting all domain objects ending with 'arpa\.'
>> resolve this issue?
>>
> We currently do not allow creation of this type of domains.
> We are working towards having them deleted by end of October 2020.

sounds great to me.

Frank


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] stale route6 and domain objects for removed inet6num

[Frank Habicht]

Thanks James.
Frank

On 24/09/2020 10:18, James wrote:
> Dear Frank,
> 
> Thank you for the follow up.
> 
> The fix has been developed and tested in dev-environment, we are
> expecting staging environment to be ready for testing by close of
> business tomorrow.
> 
> With an assumption that we won't experience any challenges on staging,
> production deployment should happen by end of next week.
> 
> In any case, a status update will be provided.
> 
> Regards,
> 
> James
> 
> 
> On 13/09/2020 22:56, Frank Habicht wrote:
>> Hi James,
>>
>> can we get some times lines for the bug fixes (if not completed
>> already), please?
>>
>> Thanks,
>> Frank
>>
>> On 25/08/2020 08:34, James wrote:
>>> Hello Frank,
>>>
>>> We now have the child orphan monitoring tool in place and I can confirm
>>> that all orphan objects have been cleaned up, now our focus turns to
>>> getting the bug fixes implemented asap.
>>>
>>> Regards,
>>>
>>> James   
>>>
>>> On 23/08/2020 20:27, Frank Habicht wrote:
>>>> Great. Thanks.
>>>> Frank
>>>>
>>>> On 23/08/2020 18:48, James wrote:
>>>>> Hello  Frank,
>>>>>
>>>>> Indeed the plan is to get all the orphaned objects out of the database
>>>>> and this will be done as soon as the monitoring tool is available, and
>>>>> we expect this to be available as earliercommunicated.
>>>>>
>>>>> Regards,
>>>>>
>>>>> James   
>>>>>
>>>>> On 20/08/2020 19:04, Frank Habicht wrote:
>>>>>> Thanks James.
>>>>>>
>>>>>> hoping that the general check, capture of orphans and clean up can be
>>>>>> done by mid next week.
>>>>>>
>>>>>> Regards,
>>>>>> Frank
>>>>>>
>>>>>> On 20/08/2020 17:19, James wrote:
>>>>>>> Dear Frank,
>>>>>>>
>>>>>>> Thanks for the inquiry.
>>>>>>>
>>>>>>> The mechanism being referred to is implemented within the WHOIS  and the
>>>>>>> bug has been reported with our software team. As soon as I have an ETA
>>>>>>> you shall be kept in the loop.
>>>>>>>
>>>>>>> Before removing the objects you highlighted, we are running a general
>>>>>>> check to establish the extent of the issue and ensure we capture any
>>>>>>> other orphan objects that may exist so that the clean up is done at
>>>>>>> once. Furthermore, the proactive monitory tool in this regard was
>>>>>>> something already requested internally and is under development with an
>>>>>>> ETA of Monday.
>>>>>>>
>>>>>>> My previous update was in the interest of keeping you updated as the
>>>>>>> team works in the background to resolve the issue.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> On 19/08/2020 22:14, Frank Habicht wrote:
>>>>>>>> Dear James,
>>>>>>>>
>>>>>>>> Thanks for your email.
>>>>>>>>
>>>>>>>> I want to respond as an AfriNIC member, *not* as DBWG co-chair.
>>>>>>>> Also, I'm known to be sometimes a bit too blunt, and i'm currently not
>>>>>>>> sure if i can avoid this here. Apologies in advance.
>>>>>>>>
>>>>>>>> We (non-staff outsiders) probably don't need to know all the internals,
>>>>>>>> but in this case i think it would comfort me if we had some indication
>>>>>>>> that internal details are being looked at (critically) and this and 
>>>>>>>> more
>>>>>>>> bug(s) get fixed. with intention of pro-activeness.
>>>>>>>> We don't know whether the 'mechanisms that checks for child objects' is
>>>>>>>> a script for a human to follow and a passage should be more 
>>>>>>>> highlighted,
>>>>>>>> or whether that's a script for a machine where a '6?' is missing in a
>>>>>>>> regular expression right after 'route' .
>>>>&

Re: [DBWG] WG Scope [Was: online meeting - Sept 30 - 9:00 - 13:30 UTC]

[Frank Habicht]

Hi Ben, all,

On 14/09/2020 16:26, Ben Maddison wrote:
> Hi Frank, all,
> 
> On 09/10, Frank Habicht wrote:
>> Dear colleagues,
>>
>> We are planning to have a virtual meeting of the AfriNIC DB working group.
>>
>> 
>>
>> 12. RPKI ASN0 is an item Staff have suggested, and I trust interesting
>> to most, but maybe not in the core of the DB functions, and since likely
>> no other agenda items will be influenced by this, we can have this
>> towards the end of the agenda [which does not mean lower importance ;-)]
>>
> I would suggest that RPKI and WHOIS operations are sufficiently
> interdependent that this WG probably wants to make the former part of
> its business, explicitly.
> Perhaps a point for discussion under the WG procedure item?

thanks for the note.
We can do that. We can even call the item "WG procedure and scope".

Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] stale route6 and domain objects for removed inet6num

[Frank Habicht]

Hi James,

can we get some times lines for the bug fixes (if not completed
already), please?

Thanks,
Frank

On 25/08/2020 08:34, James wrote:
> Hello Frank,
> 
> We now have the child orphan monitoring tool in place and I can confirm
> that all orphan objects have been cleaned up, now our focus turns to
> getting the bug fixes implemented asap.
> 
> Regards,
> 
> James   
> 
> On 23/08/2020 20:27, Frank Habicht wrote:
>> Great. Thanks.
>> Frank
>>
>> On 23/08/2020 18:48, James wrote:
>>> Hello  Frank,
>>>
>>> Indeed the plan is to get all the orphaned objects out of the database
>>> and this will be done as soon as the monitoring tool is available, and
>>> we expect this to be available as earliercommunicated.
>>>
>>> Regards,
>>>
>>> James   
>>>
>>> On 20/08/2020 19:04, Frank Habicht wrote:
>>>> Thanks James.
>>>>
>>>> hoping that the general check, capture of orphans and clean up can be
>>>> done by mid next week.
>>>>
>>>> Regards,
>>>> Frank
>>>>
>>>> On 20/08/2020 17:19, James wrote:
>>>>> Dear Frank,
>>>>>
>>>>> Thanks for the inquiry.
>>>>>
>>>>> The mechanism being referred to is implemented within the WHOIS  and the
>>>>> bug has been reported with our software team. As soon as I have an ETA
>>>>> you shall be kept in the loop.
>>>>>
>>>>> Before removing the objects you highlighted, we are running a general
>>>>> check to establish the extent of the issue and ensure we capture any
>>>>> other orphan objects that may exist so that the clean up is done at
>>>>> once. Furthermore, the proactive monitory tool in this regard was
>>>>> something already requested internally and is under development with an
>>>>> ETA of Monday.
>>>>>
>>>>> My previous update was in the interest of keeping you updated as the
>>>>> team works in the background to resolve the issue.
>>>>>
>>>>> Regards,
>>>>>
>>>>> James
>>>>>
>>>>> On 19/08/2020 22:14, Frank Habicht wrote:
>>>>>> Dear James,
>>>>>>
>>>>>> Thanks for your email.
>>>>>>
>>>>>> I want to respond as an AfriNIC member, *not* as DBWG co-chair.
>>>>>> Also, I'm known to be sometimes a bit too blunt, and i'm currently not
>>>>>> sure if i can avoid this here. Apologies in advance.
>>>>>>
>>>>>> We (non-staff outsiders) probably don't need to know all the internals,
>>>>>> but in this case i think it would comfort me if we had some indication
>>>>>> that internal details are being looked at (critically) and this and more
>>>>>> bug(s) get fixed. with intention of pro-activeness.
>>>>>> We don't know whether the 'mechanisms that checks for child objects' is
>>>>>> a script for a human to follow and a passage should be more highlighted,
>>>>>> or whether that's a script for a machine where a '6?' is missing in a
>>>>>> regular expression right after 'route' .
>>>>>>
>>>>>> And we shouldn't be involved in this. I just want to express that it
>>>>>> would be very comforting if we could get to see - by results, of course
>>>>>> - that this is taken seriously and being looked at.
>>>>>>
>>>>>> Maybe there should or could be some incentives to find issues. and to
>>>>>> fix them. Anything i can think of can probably be "gamed", and i
>>>>>> shouldn't get into details.
>>>>>> [I included Arthur for that. he had asked me ages ago for feedback, took
>>>>>> me long to give some;-)]
>>>>>>
>>>>>> So I wanted also to mention:
>>>>>> If I found an embarrassing bug or mistake in my database, I would really
>>>>>> try hard to fix it, if not before sending the response email, then at
>>>>>> least immediately after.
>>>>>>
>>>>>> If not done 2.5 hours after the email is sent, a troublesome outsider
>>>>>> (named Frank) could already think the issue gets neglected or forgotten.
>>>>>>
>>>>>> the route6 object is still there:
>>

Re: [DBWG] Possible solutions to the changed attribute issue

[Frank Habicht]

Dear DBWG,

I'd like to revive this, since I'm not sure we got to a conclusion.

On 04/09/2020 12:45, Simon Seruyinda wrote:
> Dear Nishal/DBWG,
> 
> We thank you for your feedback regarding this proposal. We have taken note of 
> all the submissions. We need community consensus around the approach. 
> 1. Should we auto-generate the changed attribute from mntner->upd-to 
> email/mntner->admin-c->email
> 2. Should we deprecate the changed attribute and replace it with 
> created/last-modified attributes.


I think we agreed that the "liberties" we have with the current
'changed:' attribute are not desirable.

option 1. above, to have this automatically generated, is a clear
improvement.
but syntax restrictions limit the content to one email address.
while the maintainer handle was preferred by some.

option 2. above is a bigger change
I think that impact analysis and implementation timelines from staff
could help us to judge?

Please share input.


> Regarding the session at the AIS, we shall work with the DBWG chair and 
> revert back to you on this.
> A zoom session can be arranged and may be it should not necessarily be tied 
> around AIS as some members of the working group may be participating in the 
> policy discussions.
> 

Was done in separate email.


Regards,
Frank


> Regards;
> Simon
> 
>> On 4 Sep 2020, at 04:30, Nishal Goburdhan  wrote:
>>
>>
>> dear wg chair, and afrinic team,
>> at the risk of repeating myself, this remains unanswered:
>>
>> On 24 Aug 2020, at 17:29, Nishal  Goburdhan wrote:
>>
>>> what, from the above, do you need this working group to help with?   
>>> community consensus around mandatory maintainerS?  :-)
>>
>> i recognise that there’s no defined process for changing this.  (yet?).
>> i half-expected staff (aka this working group’s secretariat) to present a 
>> bullet point straw-man, which addresses the issues that have been presented 
>> (in this case, accurate information in whois), and potential solutions.  is 
>> this unreasonable?  should i be submitting a proposal a la rpd, and then 
>> trying to “defend” that at the next dbwg meeting?
>>
>> i received reminders that the “AIS” event will be taking place online 
>> (virtual event) this year.  i did not see an announcement on this list, for 
>> a meeting of the dbwg, where, presumably, i expect you (chair and staff) to 
>> engage with us mere mortals on dbwg issues.
>>
>> my apologies in advance if this message was caught up in the rest of the AIS 
>> clutter;  but i *did* check the archives too.  i’m really only interested in 
>> knowing :
>> # if there will be a virtual meeting of the dbwg, and
>> # when this is scheduled for, and
>> # how does one attend
>>
>> and perhaps, since this is virtual, does it even have to be tied around AIS 
>> at all .. ?
>>
>> -n.
>>
>> ___
>> DBWG mailing list
>> DBWG@afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
> 
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] object from dump not showing in whois

[Frank Habicht]

Hi AfriNIC Staff,

We cleaned up all domains objects for non-assigned/non-allocated
inet[6]num ?

In today's DB dump on FTP I see:


domain: 0.216.196.in-addr.arpa.
descr:  -
descr:  Temporarily registered for the
descr:  assignment of a IP addresses
descr:  to be used in the ISOC-ccTLD
descr:  Training : 12-15th Sept 2005
descr:  -
org:ORG-KNIC1-AFRINIC
admin-c:KNIC1-AFRINIC
tech-c: KNIC1-AFRINIC
zone-c: KNIC1-AFRINIC
nserver:noc.cctkd.or.ke
nserver:a.ns.hopcount.ca
mnt-by: AFRINIC-HM-MNT
changed:***@afrinic.net 20050912
source: AFRINIC

and the inetnum doesn't exist.


Does this show that the ones ending with 'arpa' were removed and the
ones ending with 'arpa\.' were not removed?


there are many domains duplicated with both versions.


Regards,
Frank


[frank@fisi db_2020-09-13]$ egrep
'^domain.*16.\.2\.196\.in-addr\.arpa\.?$' afrinic.db

domain: 160.2.196.in-addr.arpa.
domain: 161.2.196.in-addr.arpa.
domain: 162.2.196.in-addr.arpa.
domain: 163.2.196.in-addr.arpa.
domain: 164.2.196.in-addr.arpa.
domain: 165.2.196.in-addr.arpa.
domain: 166.2.196.in-addr.arpa.
domain: 167.2.196.in-addr.arpa.
domain: 168.2.196.in-addr.arpa.
domain: 169.2.196.in-addr.arpa.
domain: 160.2.196.in-addr.arpa
domain: 161.2.196.in-addr.arpa
domain: 162.2.196.in-addr.arpa
domain: 163.2.196.in-addr.arpa
domain: 164.2.196.in-addr.arpa
domain: 165.2.196.in-addr.arpa
domain: 166.2.196.in-addr.arpa
domain: 167.2.196.in-addr.arpa
domain: 168.2.196.in-addr.arpa
domain: 169.2.196.in-addr.arpa
[frank@fisi db_2020-09-13]$ egrep
'^domain.*17.\.2\.196\.in-addr\.arpa\.?$' afrinic.db

domain: 170.2.196.in-addr.arpa.
domain: 171.2.196.in-addr.arpa.
domain: 172.2.196.in-addr.arpa.
domain: 173.2.196.in-addr.arpa.
domain: 174.2.196.in-addr.arpa.
domain: 175.2.196.in-addr.arpa.
domain: 176.2.196.in-addr.arpa.
domain: 177.2.196.in-addr.arpa.
domain: 178.2.196.in-addr.arpa.
domain: 179.2.196.in-addr.arpa.
domain: 170.2.196.in-addr.arpa
domain: 171.2.196.in-addr.arpa
domain: 172.2.196.in-addr.arpa
domain: 173.2.196.in-addr.arpa
domain: 174.2.196.in-addr.arpa
domain: 175.2.196.in-addr.arpa
domain: 176.2.196.in-addr.arpa
domain: 177.2.196.in-addr.arpa
domain: 178.2.196.in-addr.arpa
domain: 179.2.196.in-addr.arpa
[frank@fisi db_2020-09-13]$ egrep
'^domain.*18.\.2\.196\.in-addr\.arpa\.?$' afrinic.db

domain: 180.2.196.in-addr.arpa.
domain: 181.2.196.in-addr.arpa.
domain: 182.2.196.in-addr.arpa.
domain: 183.2.196.in-addr.arpa.
domain: 184.2.196.in-addr.arpa.
domain: 185.2.196.in-addr.arpa.
domain: 186.2.196.in-addr.arpa.
domain: 187.2.196.in-addr.arpa.
domain: 188.2.196.in-addr.arpa.
domain: 189.2.196.in-addr.arpa.
domain: 180.2.196.in-addr.arpa
domain: 181.2.196.in-addr.arpa
domain: 182.2.196.in-addr.arpa
domain: 183.2.196.in-addr.arpa
domain: 184.2.196.in-addr.arpa
domain: 185.2.196.in-addr.arpa
domain: 186.2.196.in-addr.arpa
domain: 187.2.196.in-addr.arpa
domain: 188.2.196.in-addr.arpa
domain: 189.2.196.in-addr.arpa
[frank@fisi db_2020-09-13]$



$ egrep '^domain.*arpa\.$' afrinic.db

domain: 160.2.196.in-addr.arpa.
domain: 161.2.196.in-addr.arpa.
domain: 162.2.196.in-addr.arpa.
domain: 163.2.196.in-addr.arpa.
domain: 164.2.196.in-addr.arpa.
domain: 165.2.196.in-addr.arpa.
domain: 166.2.196.in-addr.arpa.
domain: 167.2.196.in-addr.arpa.
domain: 168.2.196.in-addr.arpa.
domain: 169.2.196.in-addr.arpa.
domain: 170.2.196.in-addr.arpa.
domain: 171.2.196.in-addr.arpa.
domain: 172.2.196.in-addr.arpa.
domain: 173.2.196.in-addr.arpa.
domain: 174.2.196.in-addr.arpa.
domain: 175.2.196.in-addr.arpa.
domain: 176.2.196.in-addr.arpa.
domain: 177.2.196.in-addr.arpa.
domain: 178.2.196.in-addr.arpa.
domain: 179.2.196.in-addr.arpa.
domain: 180.2.196.in-addr.arpa.
domain: 181.2.196.in-addr.arpa.
domain: 182.2.196.in-addr.arpa.
domain: 183.2.196.in-addr.arpa.
domain: 184.2.196.in-addr.arpa.
domain: 185.2.196.in-addr.arpa.
domain: 186.2.196.in-addr.arpa.
domain: 187.2.196.in-addr.arpa.
domain: 188.2.196.in-addr.arpa.
domain: 189.2.196.in-addr.arpa.
domain: 190.2.196.in-addr.arpa.
domain: 191.2.196.in-addr.arpa.
domain: 159.0.212.in-addr.arpa.
domain:  

[DBWG] duplicate domain objects

[Frank Habicht]

Hi AfriNIC Staff,

found this in the DB:

domain: 196.163.in-addr.arpa.
descr:  Reverse DNS for Nissan South Africa
admin-c:ZRV-AFRINIC
tech-c: ZRV-AFRINIC
zone-c: ZRV-AFRINIC
nserver:ns1.qdata.net
nserver:ns2.qdata.net
notify: ***@nissan.co.za
mnt-by: AFRINIC-HM-MNT
mnt-lower:  TF-163-196-MNT
changed:***@afrinic.net 20050913
source: AFRINIC

domain: 196.163.in-addr.arpa
descr:  Reverse DNS for Nissan South Africa
admin-c:GH2-AFRINIC
tech-c: GH2-AFRINIC
zone-c: GH2-AFRINIC
nserver:ns1.infovan.co.za
nserver:ns.infovan.co.za
nserver:ns2.infovan.co.za
nserver:ns3.infovan.co.za
notify: ***@nissan.co.za
mnt-by: AFRINIC-HM-MNT
mnt-lower:  TF-163-196-MNT
changed:***@afrinic.net 20050913
changed:***@afrinic.net 20070419
changed:***@afrinic.net 20081010
changed:***@afrinic.net 20090820
source: AFRINIC


Are domain objects with a dot ('.') at the end legal in the DB?
Are they ignored when the version without the dot also exists?

I believe we shouldn't have both of these in the DB.

Would disallowing and deleting all domain objects ending with 'arpa\.'
resolve this issue?

Thanks,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] Possible solutions to the changed attribute issue

[Frank Habicht]

Hi,

On 10/09/2020 23:46, Nishal Goburdhan wrote:
> On 10 Sep 2020, at 20:26, Cedrick Adrien Mbeyet wrote:
> 
> 
>> A project to revamp of MyAfrinic has kicked off already and development
>> is ongoing.
> 
> hi cedrick,
> 
> thank you for the note about the security status of my.afrinic, but
> that’s not really a matter for discussion here.  the real issue, is that
> there was a suggestion from your staff, to move from something that is
> considered secure (pgp) to something *less* secure (the my.afrinic
> portal)  and, whilst we appreciate your efforts to secure your portal,
> that does not make it better than me, having my own pgp key, and
> performing updates via pgp-signed mail.
> 
> unless there’s a common feeling otherwise?
> 
> please continue your work;  but for dbwg purposes, there are at least
> three, demonstrably human participants of this list and users of your
> database, that have said a loud “NO” to removing updates via signed mail.

I just want to confirm what Nishal has said.

It was mentioned [1] by staff that "${portal}" could become the only
supported way of whois updates.

There have been multiple postings with strong reasons against this
intention to remove existing ways of updating Whois.

In my personal capacity I would also have added my voice, but as chair
had to wait for others to voice opinions first.

Unless there is anything else, in one weeks time, I believe we can put
this to rest (in a week), with the understanding that a restriction of
the ways to update Whois should not be done until another more detailed
and justified, and then agreed upon, proposal passes.

Nishal wrote:
> unless there’s a common feeling otherwise?

there is not.


Regards,
Frank
co-chair

PS: maybe to be even more clear:
revamping MyAfrinic is fine.
But not for the reason of removing other means of whois updates.

[1]
24/08/2020, 12:05 UTC+3
"1. Eliminate other avenues of creating and updating WHOIS objects such
as webupdate and auto-dbm and leave only myafrinic."

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] person without email... and domain object size

[Frank Habicht]

Dear Cedrick,

It is ok with me if you use one of the 2 VMs in Dar es Salaam for auth
DNS to also do the digging for the lameness, ie as a second node.

I trust these are sufficiently diverse from your 1st node, they are in
AS327844, with upstreams AS37084 and AS30844.

Hope that can help.

Regards,
Frank


On 10/09/2020 21:20, Cedrick Adrien Mbeyet wrote:
> Dear dbwg,
> 
> 
> Referring to the previous email from my colleague Simon.
> 
> We indeed delayed the deletion of the lame records for multiple reason
> among them the absence of a second nodes. We had some security
> challenges that needed to be addressed before being able to plan the
> second nodes.
> 
> We do apologize for the delay on the second node implementation and rest
> tune as deployment will be scheduled very soon. And usual, announced on
> the usual channels.
> 
> Thanks and regards,
> 
> 
> -- 
> ___
> Cedrick Adrien Mbeyet   
> IT Infrastructure Unit Manager, AFRINIC Ltd.
> t:  +230 403 5100 / 403 5115 | f: +230 466 6758 | tt: @afrinic | w: 
> www.afrinic.net
> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia
> __
> 
> On 07/09/2020 16:59, Simon Seruyinda wrote:
>> Hi Frank,
>>
>> The e-mail attribute was made mandatory in July 2012.
>> I have done a quick check in the database and we have 1048 person objects 
>> without the email attribute.
>> Most of these objects belong to legacy resource holders and were imported 
>> into the database during the initial setup.
>> Many are referenced in different objects. Below are some stats regarding 
>> number of objects that are referencing these person objects as 
>> admin-c,tech-c or zone-c.
>>
>> zone-c:
>> ===
>> 51 domain objects
>>
>> tech-c
>> ===
>> as-block 248
>> as-set   11
>> domain   35
>> inetnum  574
>> mntner   60
>> org  162
>> role 7
>> route-set6
>>
>> admin-c:
>> ==
>> as-block 248
>> as-set   11
>> aut-num  2
>> domain   49
>> inet6num 1
>> inetnum  731
>> mntner   71
>> org  137
>> role 4
>> route-set6
>>
>> There is an ongoing project internally focused on contacting these legacy 
>> holders in order to update their contact details in the database. Another 
>> activity, under the scope of the whois business rules inconsistencies is 
>> also planned to get the emails updated for any resource members who may be 
>> having no emails in the any of their person objects. Incases where efforts 
>> to get in touch with the resource holder proves futile, a temporary measure 
>> using AFRINIC’s placeholder email accounts is undertaken. These activities 
>> are expected to decrease the number significantly.
>>
>> With regards to the lame delegation handling, we are not doing deletion yet 
>> since we are running only one node to do the lame delegation checks. Once 
>> the second node is setup, we shall begin the deletion otherwise for now we 
>> run the risk of a few false positives.
>>
>> Regarding the rdns objects size, thanks for bringing this up for discussion. 
>> Currently we have a limit for IPv4 set to minimum of /24, but there is no 
>> limit implemented for IPv6, so it will go up to 128.
>> I agree this could lead to unnecessary db growth and i think a limit should 
>> be set. Input from the DBWG members on what would be the appropriate minimum 
>> would highly be appreciated.
>>
>> Regards;
>> Simon
>>
>>> On 6 Sep 2020, at 22:22, Frank Habicht  wrote:
>>>
>>> Hi AfriNIC staff,
>>>
>>> since when is the 'e-mail:' attribute for 'person' objects mandatory?
>>>
>>> I just found
>>> nic-hdl:SE1-AFRINIC
>>> that does not have an email.
>>>
>>> It's got a GENERATED maintainer, and I'm also wondering how these new
>>> maintainer credentials were communicated to the "person".
>>>
>>> Yes, I don't want to rely on 'changed:' attributes.
>>>
>>> Staff:
>>> How many 'person' objects don't have an 'e-mail:' attribute ?
>>>
>>>
>>> [slowly getting to another issue]
>>>
>>> Why did I get to check this person object at all?
>>>
>>> Because in a domain object it is
>>> tech-c: SE1-AFRINIC
>>> zone-c: S

[DBWG] online meeting - Sept 30 - 9:00 - 13:30 UTC

[Frank Habicht]

Dear colleagues,

We are planning to have a virtual meeting of the AfriNIC DB working group.

Because the week of the AIS is relatively full and some AfriNIC staff
were booked in the following week as well, we have decided on the 30th
of September for the meeting.

Like events during the AIS week, we plan to start at 9:00 UTC in an
attempt to accommodate the variety of time zones that people will
participate from, given that we're not all in the same place.

Since surely more than 2 hours will be needed, we plan to have a break
for stretching and coffee in the middle of the time window.

This is the current draft agenda, for which you can send change
suggestions and we can update and confirm this at the beginning of the
meeting:

1. Introductory remarks
2. Agenda discussion/confirmation; scribe
3. WG procedures - discussion
4. 2nd co-chair nomination / election / appointment
5. Review of previous dbwg session minutes (10 min)
6. Update from the applications unit
7. Update from MS on database accuracy improvement

Break 20 mins

8. DB security enhancement proposal
9. DBWG work items
10. Presentation from other WG member
11. Presentation from other WG member
12. RPKI ANS0 implementation plan -R
13. AOB

Updates from AfriNIC staff are towards the beginning, as they can give
news of what was already done and inform later discussions

I expect the bulk of the DB discussion topics that are not concluded yet
to be worked on in "9. DBWG work items".

Then 10. and 11. are placeholders if any WG members with to present any
problems and/or proposals. Please let me know if this is the case.

12. RPKI ASN0 is an item Staff have suggested, and I trust interesting
to most, but maybe not in the core of the DB functions, and since likely
no other agenda items will be influenced by this, we can have this
towards the end of the agenda [which does not mean lower importance ;-)]


Regards,
Frank Habicht
co-chair


___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] person without email... and domain object size

[Frank Habicht]

again...

I can't see domain objects for longer/smaller prefixes than /24 in IPv4.

Frank

On 06/09/2020 21:33, Frank Habicht wrote:
> I forgot to mention that there are a total of 9 reverse-DNS delegations
> for /128 prefixes.
> 
> the 2nd one I checked was not lame.
> didn't check more.
> 
> 
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.f.f.f.0.c.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.f.0.c.2.ip6.arpa
> domain:
> b.3.3.0.f.4.e.f.f.f.3.4.3.c.4.9.0.0.0.0.0.0.2.2.8.e.4.f.f.0.c.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.3.4.1.0.0.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.a.f.f.0.c.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.2.a.f.f.0.c.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.2.f.f.0.c.2.ip6.arpa
> domain:
> 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa
> domain:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.6.f.f.0.c.2.ip6.arpa
> 
> 
> PS: that's from an FTP database from August 20th.
> 
> Frank
> 
> 
> On 06/09/2020 21:22, Frank Habicht wrote:
>> Hi AfriNIC staff,
>>
>> since when is the 'e-mail:' attribute for 'person' objects mandatory?
>>
>> I just found
>> nic-hdl:SE1-AFRINIC
>> that does not have an email.
>>
>> It's got a GENERATED maintainer, and I'm also wondering how these new
>> maintainer credentials were communicated to the "person".
>>
>> Yes, I don't want to rely on 'changed:' attributes.
>>
>> Staff:
>> How many 'person' objects don't have an 'e-mail:' attribute ?
>>
>>
>> [slowly getting to another issue]
>>
>> Why did I get to check this person object at all?
>>
>> Because in a domain object it is
>> tech-c: SE1-AFRINIC
>> zone-c: SE1-AFRINIC
>>
>>
>> Also, the domain object is since "2020-02-02 02:02"
>> ( nice time stamp!! ;-) ) marked as all 'nserver' being *lame*.
>> So when is it meant to get deleted?
>> I hope we're not waiting for the tech-c or zone-c to respond to the
>> email, which we could not send, because the 'person' doesn't have an
>> email address?
>>
>> But what really got me to check the domain object:
>>
>> domain:
>> 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa
>>
>> yes, it's a bit long. a reverse DNS delegation for a /128
>>
>> This is probably "legal".
>> But:
>> a) if disputable 'usefulness', and
>> b) I see "tremendous' potential for growth in the DB - in a bad way
>>
>>
>> All, Staff and WG:
>>
>> should creation of domain objects be limited to certain prefix sizes?
>>
>>
>> Thanks,
>> Frank
>>
>> ___
>> DBWG mailing list
>> DBWG@afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
>>
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] person without email... and domain object size

[Frank Habicht]

I forgot to mention that there are a total of 9 reverse-DNS delegations
for /128 prefixes.

the 2nd one I checked was not lame.
didn't check more.


domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.f.f.f.0.c.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.f.0.c.2.ip6.arpa
domain:
b.3.3.0.f.4.e.f.f.f.3.4.3.c.4.9.0.0.0.0.0.0.2.2.8.e.4.f.f.0.c.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.3.4.1.0.0.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.a.f.f.0.c.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.2.a.f.f.0.c.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.2.f.f.0.c.2.ip6.arpa
domain:
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa
domain:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.6.f.f.0.c.2.ip6.arpa


PS: that's from an FTP database from August 20th.

Frank


On 06/09/2020 21:22, Frank Habicht wrote:
> Hi AfriNIC staff,
> 
> since when is the 'e-mail:' attribute for 'person' objects mandatory?
> 
> I just found
> nic-hdl:SE1-AFRINIC
> that does not have an email.
> 
> It's got a GENERATED maintainer, and I'm also wondering how these new
> maintainer credentials were communicated to the "person".
> 
> Yes, I don't want to rely on 'changed:' attributes.
> 
> Staff:
> How many 'person' objects don't have an 'e-mail:' attribute ?
> 
> 
> [slowly getting to another issue]
> 
> Why did I get to check this person object at all?
> 
> Because in a domain object it is
> tech-c: SE1-AFRINIC
> zone-c: SE1-AFRINIC
> 
> 
> Also, the domain object is since "2020-02-02 02:02"
> ( nice time stamp!! ;-) ) marked as all 'nserver' being *lame*.
> So when is it meant to get deleted?
> I hope we're not waiting for the tech-c or zone-c to respond to the
> email, which we could not send, because the 'person' doesn't have an
> email address?
> 
> But what really got me to check the domain object:
> 
> domain:
> 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa
> 
> yes, it's a bit long. a reverse DNS delegation for a /128
> 
> This is probably "legal".
> But:
> a) if disputable 'usefulness', and
> b) I see "tremendous' potential for growth in the DB - in a bad way
> 
> 
> All, Staff and WG:
> 
> should creation of domain objects be limited to certain prefix sizes?
> 
> 
> Thanks,
> Frank
> 
> ___
> DBWG mailing list
> DBWG@afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[DBWG] person without email... and domain object size

[Frank Habicht]

Hi AfriNIC staff,

since when is the 'e-mail:' attribute for 'person' objects mandatory?

I just found
nic-hdl:SE1-AFRINIC
that does not have an email.

It's got a GENERATED maintainer, and I'm also wondering how these new
maintainer credentials were communicated to the "person".

Yes, I don't want to rely on 'changed:' attributes.

Staff:
How many 'person' objects don't have an 'e-mail:' attribute ?


[slowly getting to another issue]

Why did I get to check this person object at all?

Because in a domain object it is
tech-c: SE1-AFRINIC
zone-c: SE1-AFRINIC


Also, the domain object is since "2020-02-02 02:02"
( nice time stamp!! ;-) ) marked as all 'nserver' being *lame*.
So when is it meant to get deleted?
I hope we're not waiting for the tech-c or zone-c to respond to the
email, which we could not send, because the 'person' doesn't have an
email address?

But what really got me to check the domain object:

domain:
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa

yes, it's a bit long. a reverse DNS delegation for a /128

This is probably "legal".
But:
a) if disputable 'usefulness', and
b) I see "tremendous' potential for growth in the DB - in a bad way


All, Staff and WG:

should creation of domain objects be limited to certain prefix sizes?


Thanks,
Frank

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

Re: [DBWG] whois historic queries

[Frank Habicht]

this is with the whois client included in CentOS:

$ whois -h whois.afrinic.net -- --list-versions 196.216.2.0/23
[Querying whois.afrinic.net]
[whois.afrinic.net]
% This is the AfriNIC Whois server.
% The AFRINIC whois database is subject to  the following terms of Use.
See https://afrinic.net/whois/terms

% Version history for INETNUM object "196.216.2.0 - 196.216.3.255"
% You can use "--show-version rev#" to get an exact version of the object.


rev#  Date  Op.

1 2005-02-21 15:30  ADD/UPD
2 2005-04-09 11:00  ADD/UPD
3 2006-11-23 08:22  ADD/UPD
4 2007-03-20 08:21  ADD/UPD
5 2007-09-02 21:15  ADD/UPD
6 2012-03-09 12:35  ADD/UPD
7 2012-03-09 12:57  ADD/UPD
8 2013-04-19 13:33  ADD/UPD
9 2013-05-27 12:42  ADD/UPD
102013-09-04 10:09  ADD/UPD
112014-09-15 08:15  ADD/UPD
122016-05-26 06:49  ADD/UPD
132020-08-18 12:16  ADD/UPD


On 02/09/2020 15:47, Yang Yu wrote:
> whois -h whois.afrinic.net --list-versions 196.216.2.6

___
DBWG mailing list
DBWG@afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg

[Community-Discuss] requesting database cleanup

[Frank Habicht]

Hi,

sorry for the disturbance in the regular programming.

I was about to ask (on this list or another) for a contact to help clean
up a suspicious entry in the RADB IRR - yes, not related to AfriNIC.

but looking at the entry:

$ whois AS64500
[Querying whois.radb.net]
[whois.radb.net]
aut-num:AS64500
as-name:LARUS-2
descr:  Larus Cloud Service Limited
admin-c:Tingting Xu
tech-c: tingting xu
mnt-by: MAINT-LARUS
changed:h...@laruscloudservice.net 20180622  #08:42:16Z
source: RADB

I was wondering if maybe someone subscribed to *this* mailing list was
the creator and has full ability to remove an aut-num object, which per
RFC5398
https://tools.ietf.org/html/rfc5398
[how did I get to that?
https://www.iana.org/assignments/as-numbers/as-numbers.xhtml]

... is an ASN reserved for documentation.

Does anyone have the power to just remove this object referring to an
ASN that is not theirs?

PS: yes, I was reading some documentation with this ASN and was not
aware of the reservation, and looked it up in whois, and got the "funny"
entry in RADB...

PPS: possible improvement: if anyone can get RADB to prevent reserves
ASNs to be created in their DB as aut-num, that'd be great.

Thanks,
Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Ongoing thefts of AFRINIC Legacy Resources -- Ongoing collusion?

[Frank Habicht]

On 20/08/2020 07:52, Frank Habicht wrote:
> Now an observation I just made:
> from Feb 2007 until May 2014 "ORG-IA41-AFRINIC" was an LIR!
> and a change from LIR to "MEMBER-ONLY" (at 2014-05-26 13:15) should have
> come with removal of all resources, I believe.

But this change to "MEMBER-ONLY" seems to be 2.5 months after the ORG
received a /14 block.
Surely that was a substantial saving for ORG "ORG-IA41-AFRINIC".
And not for AfriNIC.

Frank

___
Community-Discuss mailing list
Community-Discuss@afrinic.net
https://lists.afrinic.net/mailman/listinfo/community-discuss

Re: [Community-Discuss] Ongoing thefts of AFRINIC Legacy Resources -- Ongoing collusion?

[Frank Habicht]

Hi Ronald,

I found this:
https://afrinic.net/become-member
- under "3. Type of Resource Membership" is some explanation.
LIRs provide internet services to other entities, and give IP addresses
to those other entities to use on their devices.

"EU" - end user organisations do not give IPs or internet services to
other organisations ("customers"). practically any corporate entity
(that's not an ISP) should fall under this.
Universities - should likely mostly be "EU", but I know already two in
Tanzania alone that are currently listed as LIR...
Research Networks on the other hand should surely be LIRs - giving IPs
to universities.

"PA" vs "PI"
https://en.wikipedia.org/wiki/Provider-aggregatable_address_space
https://en.wikipedia.org/wiki/Provider-independent_address_space
https://afrinic.net/support/resource-members/what-is-an-allocation-or-pa-provider-aggregatable-ip-space
https://www.ripe.net/participate/member-support/copy_of_faqs/isp-related-questions/pa-pi

you won't see a difference out on the real Internet and in BGP.

generally, for PI space the Org of the user is the Org having the IP
from the RIR.
for PA space: the Org of the user (or the individual) is a customer of
the LIR (read: ISP) who got the IPs from the RIR.

a new member declares to AfriNIC "I'm an ISP" - they can justify IPs by
saying they will use it to provide Internet services to customers.
AfriNIC is known to ask for an ISP license to get convinced.
If a new university AfriNIC member says "I'm not going to give Internet
services to external organisations", they should become an EU-PI.

There are different "defaults" for the blocks sizes, but if justified,
more than the default is an option. At least when we have enough IPs.

Now an observation I just made:
from Feb 2007 until May 2014 "ORG-IA41-AFRINIC" was an LIR!
and a change from LIR to "MEMBER-ONLY" (at 2014-05-26 13:15) should have
come with removal of all resources, I believe.

Regards,
Frank


On 20/08/2020 03:42, Ronald F. Guilmette wrote:
> In message , 
> Owen DeLong  wrote:
> 
>> I would suggest instead that the following is a superior alternative:
>> (i) Membership shall be open to any person or organization which has a
>> nexus in the AFRINIC service region and is a user of Internet Number
>> Resources.
> 
> Excuse me for interrupting, but during my research last year I was
> informed that there are different categories of AFRINIC "membership",
> and that not all of these entail the actual use of number resources.
> 
> In partcular, I was informed that a designation of MEMBER-ONLY in the
> org-type: field of an ORG indicated something like a United Nations
> "observer status" membership.
> 
> At present, the data base contains a number of different org-type:
> designators, which I have just tabulated as follows:
> 
>  1871 org-type:   LIR
>   632 org-type:   EU-PI
>94 org-type:   EU-AS
>84 org-type:   MEMBER-ONLY
>10 org-type:   OTHER
> 8 org-type:   REGISTERED-MEMBER
> 6 org-type:   ASSOCIATE-MEMBER
> 5 org-type:   RIR
> 1 org-type:   other
> 1 org-type:   IANA
> 1 org-type:   NON-REGISTRY
> 
> Google as I might, I have been unable to find any listing or any online
> documentation providing any information whatsoever about any of these
> AFRINIC org-types.
> 
> Could some kind soul please describe for me the significance of each one?
> 
> I am especially interested in know what the heck an "EU-PI" organization is,
> not least because that seems to be the type asosciated with ORG-IA41-AFRINIC
> which is itself the owner of the valuable 196.16.0.0/14 block, which was
> and is provably stolen.  (And it *remains* stolen, even more than 7 months
> after both the AFRINIC Board and AFRINIC management should have become
> well and truly aware of its stolen status.)
> 
> Am I correct that MEMBER-ONLY organizations pay no annual dues or fees to
> AFRINIC?  Are EU-PI organzations likewise exempt from all dues and fees?
> If so, what is the justification for that?  If not, then in the space of
> time since this ORG was mysteriously changed from a MEMBER-ONLY to an
> EU-PI org[1], has this shadowy and mysterious "offshore" organization
> paid any dues or fees to AFRINIC?  And if so, what bank acount(s) did
> those payments come from and who signed those checks?
> 
> [1] The org-type of this specific org was changed on 2020-05-07 by SOME
> UNIDENTIFIED AFRINIC STAFF MEMBER.  It is not at all clear who did that,
> or why, but apparently staff have been given permission to "imrpovise"
> when it comes to ongoing fraud.
> 
> To be blunt, I am frankly appalled that all of you folks in the AFRINIC
> region seem to be carrying on with "business as usual" when it is so
> abundantly self-evident that both AFRINIC management and the AFRINIC
> board are so clearly still covering up for thefts and for thieves.
> 
> What is the motivation for them trying to sweep these things under the
> carpet still, and to this day?