(this reply in mainly targeted towards the points Gert made) Hi, denis summarized my take on this pretty well here and we (me, denis, and I think William Sylvester too) had a brief chat about this at RIPE84 which in my view pretty much boiled down to: 1. email is the de-facto standard method of communication and is very reasonable to be required for contacts 2. any other method of contact should probably be optional/voluntary, this would include things like phone number, fax number, and probably postal address. As denis also pointed out, if you want to operate a NOC that people can call into to fix issues urgently, that is fine, you can add that attribute then. Requiring phone numbers results in cases where someone might just write a phone number like +46000000000 or put in a personal phone number which might also be unsupported for NOC purposes. I can tell you that if you call the number listed for the tech contact for my network, I will either not pick up the phone or if I do I will likely just tell you to send an email instead. Clearly requiring networks like mine to put a phone number there just results in PII being published for no good reason. I would assume that many small networks do not operate NOCs that can respond to phone calls 24/7 or even phone calls at all, especially from non-customers. P.S. Yes all of these networks could just use role objects and as such not have to publish phone numbers but I argued for why they shouldn't be required as it seemed to me like Gert didn't quite understand why I think it is a bad idea to require them, beyond the inconsistency. -Cynthia On Wed, May 25, 2022 at 1:56 PM denis walker <ripedenis@gmail.com> wrote:
Hi Gert, Cynthia
On Wed, 25 May 2022 at 12:39, Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Wed, May 25, 2022 at 12:22:53PM +0200, Cynthia Revström via db-wg wrote:
TL;DR: stop requiring the "phone" attribute for person objects.
This is something that I quickly brought up during the db-wg session at RIPE84 but thought would be good to bring up here as well.
Currently you need to specify a phone number for person objects but not for role objects, which I think should be fixed (as in not require it for person objects either).
I'm not sure I agree - as in "why is there a person/role object in the first place? -> so I know who to call in case things need an urgent resolution!".
And, calling people needs phone numbers...
And if they want you to call them, they will offer you an optional phone number. Otherwise you can send them an email or fill in their web form. If someone is operating a network and thinks it is important for anyone to be able to contact them quickly if they detect a problem, they will offer the means to do that, even if it is by using optional data. If their network problems don't need 24/7 cover with immediate problem solving they will respond to an email.
So, I agree that the inconsistency between person: and role: does not make much sense (I might see a role: object and want a phone number to call...) - but the more fundamental question is "if that object is of no use to a person looking for a point of contact, why have that object there in the first place?"...
An email address or a URL is a point of contact. A natural person working alone from home running a public network may not have the capability to respond to problems with such urgency. So why would they give you a phone number? Not all networks are equal - in size, importance, staffing, operation...
There is a fine balance between what a registry needs and what someone is willing to give. If you cross the line, the database will be full of rubbish. Then we have to consider verification on entry and regular validation to ensure it is still correct.
cheers denis proposal author
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --
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