On Wed, 17 Jan 2024 at 08:09, Cynthia Revström via db-wg wrote:
[...]
> I think we should try to bring person objects more in line with role
> objects by removing the phone number requirement. Ideally I would want
> it to be mandatory to have either a phone number or an email address
> in order
Hi Denis,
On Mon, 8 Jan 2024 at 15:16, denis walker via db-wg wrote:
>
> Hi
>
> Maybe Leo or Dmitry could give an intro into what they mean by 'alternative
> modes of contact' so people can think about it before the discussion.
Sure. We were thinking about making it possible for people to
Hi,
On Fri, 24 Nov 2023 at 03:02, Edward Shryane via db-wg wrote:
[...]
> We can migate internally to UTF-8 while keeping the current syntax rules, so
> nothing changes for the user yet (i.e. the database changes but not the
> interfaces).
>
> Once we use UTF-8 internally we can start to
Hi Denis,
On Tue, 7 Mar 2023 at 18:52, denis walker wrote:
> From my perspective as an analyst it's getting interesting now... Yes
> we can consider it as a complex problem needing a complex
> solution...but are either really complex? Maybe it is the environment
> that is complex and not this
Hi Denis,
On Tue, 7 Mar 2023 at 16:20, denis walker wrote:
> > On Tue, 7 Mar 2023 at 14:29, George Michaelson via db-wg
> > wrote:
> >
> > [...]
> >
> > > I don't necessarily disagree with you about the risks here, but I
> > > suggest that the decision to deprecate or alter behavior with this
Hi,
I strongly support what George has written.
On Tue, 7 Mar 2023 at 14:29, George Michaelson via db-wg wrote:
[...]
> I don't necessarily disagree with you about the risks here, but I
> suggest that the decision to deprecate or alter behavior with this
> field is not something which a
Hi Denis,
[...]
On Tue, 21 Feb 2023 at 05:42, denis walker wrote:
> On Mon, 20 Feb 2023 at 16:37, Leo Vegoda wrote:
> > My concern is that lots of users will not be aware of the change, or
> > not have the resources to adapt to it in a timely fashion. So, if any
> > change is made, it ought
On Mon, 20 Feb 2023 at 07:25, denis walker wrote:
> On Mon, 20 Feb 2023 at 15:58, Leo Vegoda wrote:
[...]
> > Setting semantics aside... I don't know whether changing definitions —
> > and adding a missing definition is a de facto change — would improve
> > things or make them worse. What
On Thu, 26 Jan 2023 at 07:18, denis walker wrote:
[...]
> This is exactly what I said. In the quoted para above I said "the
> country codes have a well defined meaning", which you agree with. Then
> I said "but when entered by users no one knows what it's purpose is.".
> Another way of saying
On Thu, 26 Jan 2023 at 03:55, denis walker via db-wg wrote:
>
> Hi Ed
>
> Thanks for the explanation. But as I explained to Cynthia, "org-name:"
> and "country:" are very different attributes. The org-name is just a
> free text label by which an organisation is known. Whatever label is
>
Hi Denis,
Thank you for your response.
I broadly agree with your detailed expansion of the problem statement.
As I wrote before, we need to ensure we are meeting our legal
responsibilities.
And thank you for fleshing out some possible implementations. I think
most people will recognise the need
Hi,
Thank you for producing this proposal. It's important to regularly
review policy and implementation to ensure we are meeting our legal
responsibilities.
Parts of the text in this proposal are clear and easy to interpret.
For example section 3.0 on Notifications is well written.
Other parts
Hi Denis,
On Wed, Jun 1, 2022 at 8:16 AM denis walker wrote:
[...]
> > I think we should try to establish if the proportion of natural people
> > that are LIRs is so low
>
> It is not only LIRs. So many assignment objects also contain name and
Both problems result in the same outcome -
Hi Denis,
On Tue, May 31, 2022 at 5:12 PM denis walker wrote:
[...]
> That might be interesting to know but unless the RIPE NCC's internal
> database has a flag to indicate a natural person they would have the
> same problem.
I expect they do. Or a reasonable proxy, like whether they
Hi,
On Tue, May 31, 2022 at 2:49 PM denis walker wrote:
[...]
> > It would also be good to understand whether this issue relates to a
> > tiny fraction of the registrations. What proportion of registrations
> > and what proportion of the registered number resources are we
> > discussing?
>
>
On Thu, May 26, 2022 at 7:30 AM denis walker via db-wg wrote:
>
> Colleagues
>
> Now we move on to the more difficult issue of identifying resource
> holders.
What do you mean by "resource holders"? Are you referring to someone
who has resources allocated or assigned to them directly by the RIPE
On Wed, May 25, 2022 at 2:33 PM Gert Doering wrote:
[...]
> > But if we must define a single technology that is mandatory then
> > e-mail is a better choice than phone.
>
> I actually disagree with that - speaking from my use case as a user
> of the RIPE DB. If I bother going there, it's
Hi Denis,
On Wed, May 25, 2022 at 11:58 AM denis walker wrote:
[...]
> > I think that the reason phone was mandatory is that it was the
> > de-facto standard. I agree that e-mail is now. But will it remain so?
> > If we are building for the future then we should consider the
> > possibility
Hi,
On Wed, May 25, 2022 at 10:04 AM Cynthia Revström wrote:
>
> I forgot to mention this
>
> > [...], why should we dictate what the mandatory technology is?
>
> I kinda agree with you here if you by "we" mean the db-wg, this might be a
> larger question that should involve multiple other
Hi,
On Wed, May 25, 2022 at 9:16 AM Cynthia Revström via db-wg
wrote:
>
> Even if it could mean that email might also be broken that is not necessarily
> the case.
Yes.
> Many companies use cloud services for email so they might be completely
> unaffected by their network issues.
Yes.
>
Hi Denis,
On Tue, Apr 5, 2022 at 12:17 PM denis walker wrote:
[...]
> > I agree with everyone else that ensuring the published contact data
> > are accurate is most important. Does that require a software solution?
> > Could it be accomplished with a process change? For instance, if an
> > LIR
On Mon, Apr 4, 2022 at 1:43 PM denis walker wrote:
[...]
> > What am I missing?
>
> What you are missing is that many, many, many of these /24 allocations
> are not being used by the resource holder';s organisation. They are
> assigned to end users.
Thanks for stating this clearly.
I agree
On Mon, Apr 4, 2022 at 12:34 PM denis walker wrote:
[...]
> I think you are arguing here for deleting assignments...that is
> another discussion...
I'm not arguing for deleting anything.
People have stated that they need to register an assignment which is
an exact duplicate of the allocation.
HI Denis,
On Mon, Apr 4, 2022 at 10:45 AM denis walker wrote:
> On Mon, 4 Apr 2022 at 19:08, Leo Vegoda wrote:
[...]
> > > If there are no objections to this, the co-chairs now ask the RIPE NCC
> > > to produce an impact/implementation report to add this new status
> > > value and include the
Hi,
On Mon, Apr 4, 2022 at 5:39 AM denis walker via db-wg wrote:
[...]
> If there are no objections to this, the co-chairs now ask the RIPE NCC
> to produce an impact/implementation report to add this new status
> value and include the business rules to restrict it's use. We will
> then seek a
On Wed, Oct 6, 2021 at 6:22 AM Aleksi Suhonen via db-wg wrote:
[...]
> Personally I feel that IANA should come to an agreement with one of the
> RIRs that the globally routeable blocks in that list could be adopted by
> that RIR, and then we could even have RPKI for them.
Decisions of this
On Wed, Sep 15, 2021 at 10:09 AM Gert Doering wrote:
> On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote:
> > The CSC focuses on naming and not numbering issues. That said, rather
> > than making a complaint, it might be more helpful to decide what the
> >
On Tue, Sep 14, 2021 at 9:42 PM Hank Nussbacher via db-wg
wrote:
[...]
> > Well, good luck with that. I asked the IANA folks some long time ago
> > now to fix the issue. They apparently have no interest in doing so.
>
> To whom did you submit a complaint?
>
> The place to lodge a complaint in
On Thu, Jul 22, 2021 at 3:18 PM Ronald F. Guilmette
wrote:
>
> In message
>
> Leo Vegoda wrote:
>
> >On Wed, Jul 21, 2021 at 8:23 PM Ronald F. Guilmette via db-wg
> > wrote:
> >
> >[...]
> >
> >> All things considered, I think it would be best if some helpful RIR
> >> effectively "claimed" the
On Wed, Jul 21, 2021 at 8:23 PM Ronald F. Guilmette via db-wg
wrote:
[...]
> All things considered, I think it would be best if some helpful RIR
> effectively "claimed" the 192.31.196.0/24 block, started putting the
> block into that RIR's daily stats file, and if the route object
> pertaining
On Mon, Jun 7, 2021 at 4:48 PM Ronald F. Guilmette via db-wg
wrote:
[...]
> P.S. It also complicates parsing... rather needlessly in my view...
> to have some field values optionally followed by commentary text
> beginning with #. I can't remember now if this was only a problem
> I saw with
On Fri, May 28, 2021 at 3:19 PM Ronald F. Guilmette via db-wg
wrote:
[...]
> And as long as we are on the subject, may I safely infer from the
> presence, in the data base, of a dozen different networks named "ABC"
> that no attempt has ever been made to insure uniqueness of netnames
> within
On Fri, May 28, 2021 at 10:51 AM Ronald F. Guilmette via db-wg
wrote:
[...]
> All I meant was that I was "suspicious" that the created: date/time value
> could
> be, you know, wrong... which it self-evidently is.
And there lies the value. Within the constraints of the format, the
RIPE NCC
Hi Denis,
This message is in response to several in the discussion .
In brief: I have seen network operators distraught because their
network was misclassified as being in the wrong geography for the
services their customers needed to access and they had no way to fix
that situation. I feel that
On Thu, Sep 24, 2020 at 7:30 AM ripedenis--- via anti-abuse-wg
wrote:
[...]
> Unless we go back to the drawing board and redesign the abuse contact system
> (again) this is not going to be simplified any time soon.
If the current design is not good enough and needs to be supplemented
with
On Tue, Sep 1, 2020 at 3:58 PM ripedenis--- via db-wg wrote:
[...]
> There seemed to be two main issues:
> 1/ MNTNER names not having a clear 'tag' indicating a MNTNER object
> 2/ MNTNER names specifically confused with ASNs
>
> For the first part we can add a prefix (MNT-) or suffix (-MNT), or
Hi Denis,
These are good questions. As so many of the answers lie with the RIPE
NCC or the NRO, I suppose we need input from them to proceed further.
Kind regards,
Leo
On Wed, Jul 29, 2020 at 3:47 PM ripede...@yahoo.co.uk
wrote:
>
> Hi Leo
>
> Some of the questions that need to be answered
Hi Denis,
I agree that this is a registry issue and not just a database issue,
which is why I sent the message I did on 8 July.
I'd like to understand how much of this work should be led by the RIPE
NCC versus the community. Also, because of the breadth of the issues,
should the discussion be
Hi,
Thanks for providing the impact analysis for this initial change.
What should the process be for introducing greater support for
internationalization in the RIPE Database? George, Cynthia and others
have made good points about the need to improve internationalization
of more than just e-mail
On Tue, Jul 7, 2020 at 6:05 PM ripedenis--- via db-wg wrote:
>
> Hi Nick
>
> "would it be possible to work towards a day in the future when
> the ripedb could formally support utf8 across multiple different field
> types, not just email addresses?"
>
> The technical aspect of utilising utf-8 in
On Mon, Jun 29, 2020 at 1:22 PM Nick Hilliard via db-wg wrote:
> Peter Müller wrote on 29/06/2020 20:54:
> > What would you do if you need to build a database to determine the
> > country assigned to an IP address - let's take the one assigned to it by
> > it's owner, regardless of jurisdiction
On Mon, Jun 29, 2020 at 10:31 AM Peter Müller via db-wg wrote:
>
> Dear RIPE DB mailing list people,
>
> we, the IPFire development team, just bumped across an IP address somewhere
> in the 51.15.0.0/17 network (no abuse, we were just curious :-) ).
>
> While the RIPE Whois server returned "NL"
Hi Ed,
On Fri, Jun 26, 2020 at 7:55 AM Edward Shryane via db-wg wrote:
[...]
> I welcome feedback from the community on this proposal.
>From my personal perspective, this is a welcome first step on the road
towards strong internationalization support in the RIPE Database. It
also seems like a
Hi Job,
On Fri, May 29, 2020 at 10:56 PM Job Snijders wrote:
>
> Dear Leo, group,
>
> On Mon, May 25, 2020 at 01:21:02PM -0700, Leo Vegoda via db-wg wrote:
> > On Mon, May 25, 2020 at 1:09 PM Piotr Strzyzewski
> > wrote:
> >
> > [...]
> >
> > &g
Hi Piotr,
On Mon, May 25, 2020 at 1:09 PM Piotr Strzyzewski
wrote:
[...]
> > The RIPE NCC service region includes countries whose language is not
> > written using Latin script. Languages using other scripts include (in
> > English alphabetical order) Arabic, Georgian, Greek, Hebrew, and
> >
Hi,
On Fri, May 22, 2020 at 10:52 AM ripedenis--- via db-wg wrote:
>
>
> Please do Leo :)
Here's my draft for people to kick around and improve.
Kind regards,
Leo Vegoda
The RIPE NCC service region includes countries whose language is not
written using Latin script. Languages using other
Hi Nick,
On Fri, May 22, 2020 at 8:51 AM Nick Hilliard wrote:
>
> Leo Vegoda via db-wg wrote on 21/05/2020 23:35:
> > At RIPE 80, Denis asked for feedback on some items that are not yet
> > NWIs, including internationalized domain names.
> >
> > My feedback is
Hi,
At RIPE 80, Denis asked for feedback on some items that are not yet
NWIs, including internationalized domain names.
My feedback is that the RIPE Database should support internationalized
e-mail addresses. The RIPE region includes a number of countries that
use a non-Latin script. Most of
Hi Arash,
Arash Naderpour wrote:
> Yes I know allocations and assignments can be announced from multiple
> countries, but a member has this option to set the country code for
> allocation and assignments based on their needs. If I can set my
> allocation's country code in RIPE DB why I should
Arash,
Arash Naderpour wrote:
> What you name it as "meaningless values" are not meaningless to
> the organizations that they are using it.
How do we know that all, or even most, users of the data infer the same
meanings? Has the RIPE NCC or anyone else ever measured what people understand
Sanjaya wrote:
> Just a thought, maybe we could redefine the RIR extended delegated
> file format to incorporate both cc values of inet(6)num|autnum and
> organisation Whois objects like this:
>
> registry|xx|type|start|value|date|status|yy-custodianid
> Where:
> xx = country code of
51 matches
Mail list logo