Colleagues
During the conversion we had some time ago about contacts we concluded that
no one is going to visit a contact or post them a letter.
The IRT object also had a mandatory address attribute that is defined in
the documentation as:
"This is a full postal address for the business contact
Colleagues
[Apologies to Job for copying your email from the Routing WG but you
explained it well :) ]
The RIPE NCC has asked the Database WG Chairs to facilitate a working
group conversation on framing the RIPE Database service subcomponents
in terms of criticality.
At the bottom of this email
uthor
>
> These are just my initial thoughts on the topic and there are probably many
> other things that I haven't considered.
>
> -Cynthia
>
> On Mon, Jul 4, 2022, 13:47 denis walker via db-wg wrote:
>>
>> Colleagues
>>
>> I know this has been a
Colleagues
I know this has been a long discussion with several elements to
consider. But with just over a week of this discussion period
remaining, are there any comments or thoughts on the "descr:"
attribute containing personal data?
cheers
denis
Proposal author
-- Forwarded message ---
Hi Leo
Thanks for the email and thoughts. It seems you have two main concerns
about clarity - verification and compliance. So I will try to expand a
bit more on these concepts without getting too deep into
implementation details. In this email I will focus on verification.
For some people the fac
Colleagues
Up to now we have focused mostly on member's personal data. But this
isn't only about members. The database contains lots of personal data
for end users as well. The INET(6)NUM objects have a "descr:"
attribute. This has been used extensively for (personal) data about
end users, mostly
Colleagues
Some people are still questioning the GDPR in relation to the RIPE
Database and this policy proposal and a series of articles written by
the RIPE NCC a few years ago. Most of us on this list are not lawyers.
This is why the RIPE NCC employs a team of expert legal professionals
to (re)as
On Mon, 27 Jun 2022 at 18:23, Sylvain Baya via db-wg wrote:
>
>> have adequately addressed these points in my earlier reply here:
>> https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007482.html
>>
>>
> ...i went through it again, and it appears to not satify me, though :-
>
>> Now let's tr
Colleagues
There were 2 very long emails this weekend, both pretty much along the
same lines. These points have been made several times. I believe I
have adequately addressed these points in my earlier reply here:
https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007482.html
Now let's try t
On Fri, 24 Jun 2022, 01:40 Ronald F. Guilmette via db-wg,
wrote:
> In message ,
> Nick Hilliard wrote:
>
> >denis walker via db-wg wrote on 22/06/2022 23:54:
> >> Perhaps the RIPE NCC can publish the top entries from a new set of
> these
> >> stats. If anyon
Hi Ronald
Nice to read that you vigorously support parts of my policy proposal at
least.
On Thu, 23 Jun 2022, 10:39 Ronald F. Guilmette via db-wg,
wrote:
> In message ,
> Niels Bakker wrote:
>
> >The current proposal is also a solution to people entering wrong
> >information, as denis has clea
Yes Carlos you are absolutely right. There is no suggestion whatsoever that
any membership will be revoked or any resources de-registered if any
verification fails.
Cheers
denis
Proposal author
On Thu, 23 Jun 2022, 11:48 Carlos Friaças via anti-abuse-wg, <
anti-abuse...@ripe.net> wrote:
>
>
> Hi
On Thu, 23 Jun 2022, 12:27 Nick Hilliard, wrote:
> denis walker via db-wg wrote on 22/06/2022 23:54:
> > Perhaps the RIPE NCC can publish the top entries from a new set of these
> > stats. If anyone then wishes to contest the numbers they can take it up
> > directly with t
Colleagues
Let me try to summarise a few points before we move on.
Some numbers I have previously quoted have been questioned. Occasionally
the RIPE NCC publish some anonymous statistics on the number of person
objects related to member organisations. From these authoritative
statistics it can be
Hi Nick
I'll give you the short answers first, then the detailed reply. So
people who don't like to read long emails can skip the detail.
On Sun, 19 Jun 2022, 16:06 Nick Hilliard, wrote:
> denis walker via db-wg wrote on 16/06/2022 16:05:
> > I have listened to your
Ronald
Throughout this and other discussions you constantly use unprofessional
language and personal insults and make unsubstantiated accusations.
You don't call a spade a spade, you call a spade a "privacy fetishist" and
an "extremist". Personally I don't care what you call me. But if you turn
o
liard, wrote:
> denis walker via db-wg wrote on 16/06/2022 16:05:
> > I have listened to your comments in recent discussions and had some
> > preliminary talks with the RIPE NCC about what could be implemented. So
> > now we have a second version of my proposal on personal data.
Ronald
Many of your comments are insulting and unprofessional. Much of what you've
written below is utter nonsense. Some of your most emotive nonsense I've
simply cut out. As the proposal author I feel compelled to keep reinforcing
the truth over you nonsense. Your style is totally contrary to the
Ronald
On Sun, 19 Jun 2022, 11:50 Ronald F. Guilmette via db-wg,
wrote:
> I have already and on multiple occasions made my views known regarding the
> currently pending proposal to have RIPE NCC perform a unrequested and
> blanket
> redaction of all natural person snail-mail address information
Hi Ronald
On Fri, 17 Jun 2022 at 11:45, Ronald F. Guilmette via db-wg
wrote:
>
> In message
>
> denis walker wrote:
>
> >I was getting comments from people that LEAs need addresses for their
> >investigations, but also people had serious privacy concerns about
> >publishing their home address
Hi Ronald
On Fri, 17 Jun 2022 at 09:46, Ronald F. Guilmette via db-wg
wrote:
>
> In message <579e6eed-f28e-bf83-f111-a69b2be9a...@ripe.net>,
> Angela Dall'Ara wrote:
>
> >RIPE policy proposal 2022-01, "Personal Data in the RIPE Database" is
> >now available for discussion again.
> >
> >The goal
Colleagues
I have listened to your comments in recent discussions and had some
preliminary talks with the RIPE NCC about what could be implemented. So now
we have a second version of my proposal on personal data.
I was getting comments from people that LEAs need addresses for their
investigations
Hi Leo
On Wed, 1 Jun 2022 at 18:03, Leo Vegoda wrote:
>
> 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 object
Hi Leo
On Wed, 1 Jun 2022 at 16:27, Leo Vegoda wrote:
>
> 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 probl
Hi Leo
On Wed, 1 Jun 2022 at 00:22, Leo Vegoda wrote:
>
> 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 pr
Hi Leo
On Tue, 31 May 2022 at 21:04, Leo Vegoda wrote:
>
> 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 b
Hi Jeroen
On Tue, 31 May 2022 at 16:20, Jeroen Massar via db-wg wrote:
>
>
>
> > On 31 May 2022, at 15:31, Ángel González Berdasco via db-wg
> > wrote:
> >
> > 30-05-2022 a las 13:17 +0200, denis walker writes:
> >> If no one is able to present the public interest case for publishing
> >> the n
Hi Angel
On Tue, 31 May 2022 at 15:31, Ángel González Berdasco via db-wg
wrote:
>
> 30-05-2022 a las 13:17 +0200, denis walker writes:
> > If no one is able to present the public interest case for publishing
> > the name and address of natural persons holding resources then the
> > privacy case t
x27;m
> not sure if my points mentioned above make a lot of sense or not. (It's
> currently 7:00 in the morning and I've been up all night debugging
> hardware. :) )
>
> Kind regards,
> Tyrasuki
>
> https://tyrasuki.be
> F587 F089 1655 A5E0
>
> On 5/30/2022 1:17 P
Colleagues
We had a good discussion on contact details, I am hoping we can do the
same on resource holder identity. I know there is reluctance in the
community to get into a deep discussion on the purposes of the RIPE
Database. The Task Force sidestepped the issue as far as any public
discussion i
Thanks Ed. Another little tweak you may consider...when I click on the
menu items for query, full text search or syncupdates it would be nice
if you put the cursor focus into the search box rather than make me do
that extra click every timecos I'm lazy :)
cheers
denis
co-chair DB-WG
On Fri, 2
Hi
Why can I not create an AUT-NUM object in the test database using the
web UI? It is not in the drop down menu on the create page. That of
course means I can't create ROUTE(6) objects either. So I can't do
anything with the routing registry in test mode.
Although there is an orange banner acros
Colleagues
Now we move on to the more difficult issue of identifying resource
holders. For any resource holder that is not a natural person I don't
think there is a privacy issue. For natural persons we seem to have
this conflict between privacy and public interest. The privacy issue
is well under
Hi
On Wed, 25 May 2022 at 23:33, Gert Doering wrote:
>
> Hi,
>
> On Wed, May 25, 2022 at 12:02:48PM -0700, Leo Vegoda wrote:
> > I was actually suggesting that instead of saying that technology #1 is
> > mandatory and technology #2 is optional we just say that one of the
> > supported technologie
Hi Leo
On Wed, 25 May 2022 at 20:28, Leo Vegoda via db-wg wrote:
>
> 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
Hi
On Wed, 25 May 2022 at 17:07, Gert Doering wrote:
>
> *That* said - if people do not want to be contacted about issues with
> their network, then we should ask ourselves if putting these contacts
> into the RIPE-DB is the correct thing to do - phone numbers or not -
> to me this is the prime
acts listed for any other reasons should be removed.
> >
> > With regards to this I do think that there might be legitimate use
> > cases that I just can't think of currently or that currently don't
> > exist but may exist in the future.
> >
> > -Cynt
nal
data subject to the GDPR or not, we still need to know what purposes
the database is being used for.
cheers
denis
proposal author
>
> -Cynthia
>
> On Tue, May 24, 2022 at 5:02 PM denis walker via db-wg wrote:
> >
> > Colleagues
> >
> > I received quite
Hi Gert, Cynthia
On Wed, 25 May 2022 at 12:39, Gert Doering via db-wg 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 d
Colleagues
I received quite a lot of feedback at RIPE 84 on this policy proposal.
This was mainly on two aspects, resource holders name and address and
contacts. I will start with a summary of the views on contacts as this
is the easier one to deal with.
Contacts are listed in the RIPE Database t
.
cheers
denis
co-chair DB-WG
On Wed, 18 May 2022 at 10:05, Sebastian Wiesinger via db-wg
wrote:
>
> * denis walker via db-wg [2022-04-22 01:33]:
> > Colleagues
> >
> > Although I am replying to your email Cynthia, my comments are
> > generally expressed to all. Let me t
Hi Cynthia and Peter
You both raise some interesting points and I will address them all in
one email. Let's start with 'why' do we publish the name and address
of resource holders. The RIPE Database is one of a set of 5 databases
that collectively document the registration of all global internet
r
Colleagues
The chairs propose creating a series of NWIs to address the
recommendations recently made by the Database Task Force that are
considered to be relevant to the DB-WG.
NWI-15 Baseline requirements for registration information
NWI-16 Using RIPE Database as an IPAM solution
NWI-17 Historic
Colleagues
The chairs propose creating NWI-14 for expanding the optional use of
the "mnt-ref:" attribute to protect objects from accidental or
intentional mis-representation of responsibility.
See slide 14 of this presentation for the problem definition:
https://ripe78.ripe.net/presentations/129-
Colleagues
There has been no interest in this item for several years so the
chairs recommend cancelling NWI-1. We ask the RIPE NCC to mark it as
'Cancelled'.
cheers
denis
co-chair DB-WG
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, ple
Colleagues
The RIPE NCC is working on an impact analysis and new legal review for
NWI-2 Historical Queries.
The chairs ask the RIPE NCC to also produce an impact analysis on
NWI-4 Status Value based on the addition of a new value
'ALLOCATED-ASSIGNED PA'
The chairs ask the RIPE NCC to mark NWI-8
Ronald
This style of email achieves nothing and is unacceptable on this
mailing list. Most people don't read long emails at all. The language
you use like "bovine excrement", "You throw up irrelevant arguments",
"do not materially screw around" has no place in a professional
discussion. You are in
Ronald
This is more of an Address Policy issue than Database. But as you have
raised it here, I will respond. You suggested that "I" told you to
shut up and go away. If you have ever felt anything I have said gave
you that impression I apologise. In fact for years I have been trying
to do the oppo
Colleagues
This work item had two defined stages. Stage 1 was to introduce a
default authentication group for LIRs. This has been implemented and
is in widespread use now.
Stage 2 was to introduce user defined authentication groups. This has
had no discussion with little support or objection. If
Colleagues
This has been discussed over many years. The co-chairs recently asked
the RIPE NCC to produce an impact/implementation report on the
suggestion to introduce a new status value 'ALLOCATED-ASSIGNED PA'.
This had one supporter and one objection. The objection was basically
that 'something'
Colleagues
Over the last few years several community members have asked for the
arbitrary restriction on deleted objects in historical queries of
operational data to be removed. The DB-WG co-chairs recently
recommended that the RIPE NCC goes ahead with producing an
impact/implementation report, in
operational data or we don't.
> > Offering a partial data set based on random events makes no sense.
> >
> > cheers
> > denis
> > co-chair DB-WG
> >
> > On Mon, 4 Apr 2022 at 23:33, Cynthia Revström wrote:
> > >
> > > Hi,
> > >
Colleagues
Now we have the "geofeed:" attribute, what should we do with
"geoloc:"? Right now far more people are using "geoloc:" than
"geofeed:".
denis$ zgrep "^geofeed:" ~/Desktop/ripe.db.inetnum.gz | wc -l
289
denis$ zgrep "^remarks:\s*geofeed" ~/Desktop/ripe.db.inetnum.gz | wc -l
Hi Arcadius
If you download the inetnum split file from the RIPE ftp site you will
see there are already some "geofeed:" attributes in there as well as
some still using the earlier "remarks: geofeed" option.
denis$ zgrep "^geofeed:" ~/Desktop/ripe.db.inetnum.gz | wc -l
289
denis$ zgrep "^re
Colleagues
Over the years we have made many changes to the status values. For the
INETNUM status we added 'LIR-PARTITIONED PA' and 'LIR-PARTITIONED PI',
then later removed 'LIR-PARTITIONED PI'. We added and then later
removed another status similar to the partitioned (can't remember the
name now).
On Tue, 5 Apr 2022 at 17:51, Leo Vegoda wrote:
>
> 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
> > ass
Hi Cynthia
On Mon, 4 Apr 2022 at 23:48, Cynthia Revström via db-wg wrote:
>
> I think the only thing that would really offer a proper solution here
> is to change the primary key to inetnum + status. (as mentioned in
> option 2 of Nick's email)
Forget this option. It cuts too deeply into the dat
east not without
> a very good reason to do so.
>
> -Cynthia
>
> On Thu, Mar 31, 2022 at 1:32 PM denis walker via db-wg wrote:
> >
> > Colleagues
> >
> > When I wrote the spec for historical queries, almost 10 years ago, I
> > included an arbitrary
On Mon, 4 Apr 2022 at 21:50, Leo Vegoda wrote:
>
> 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 regi
On Mon, 4 Apr 2022 at 20:42, Leo Vegoda wrote:
>
> 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:
>
> [...]
> > > I'd like to understand if there is a technical need for exact match
> > > assignments that duplicate all the con
Hi Leo
On Mon, 4 Apr 2022 at 19:08, Leo Vegoda wrote:
>
> 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
On Mon, 4 Apr 2022 at 17:41, Nick Hilliard wrote:
>
> denis walker wrote on 04/04/2022 16:16:
> > Many people have asked for a solution to this problem over recent years.
> > The chairs have tried to get some discussion on the topic many times.
> > Perhaps now we can have that discussion...
>
> So
Hi Nick
Many people have asked for a solution to this problem over recent years.
The chairs have tried to get some discussion on the topic many times.
Perhaps now we can have that discussion...
Cheers
denis
Co-chair DB-WG
On Mon, 4 Apr 2022, 14:55 Nick Hilliard, wrote:
> denis walker via
Colleagues
For many years people have been asking for a way to assign a whole
allocation without having to create 2 smaller assignments. The
situation is more relevant now with so many /24 allocations. After the
RIPE NCC rejected the idea of a dual primary key, for technical
reasons, there were tw
Colleagues
When I wrote the spec for historical queries, almost 10 years ago, I
included an arbitrary constraint to only show history back to the most
recent deletion point. This was to get something in production quickly
and see how useful it was. Over the years several people have asked
for this
Colleagues
There has been no objection to deprecating the Whitepages. The chairs
therefore ask the RIPE NCC to contact the 4 people still using it and
make alternative arrangements for them. Then they can remove the
Whitepages functionality from the database. (One old issue finally
resolved...)
c
Colleagues
"documenting an assignment the same size as an allocation"
Is this a problem that you think needs to be solved? If 'yes' then we
need to hear your thoughts. If 'no' then the chairs will cancel NWI-4
and move on...
cheers
denis
co-chair DB-WG
-- Forwarded message -
Fro
Hi Ed, Colleagues
Following on from all the responses here, perhaps the RIPE NCC legal
team can take another look at this matter and re-evaluate their legal
analysis.
cheers
denis
co-chair DB-WG
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription opt
Colleagues
The co-chairs recently had a zoom meeting with the RIPE NCC. One of
the things we discussed was clearing up a number of old issues. We
need to clear the deck and move on with new and perhaps more relevant
issues. We will address a number of issues for the last time. In some
cases the ch
Hi Cynthia
On Tue, 22 Feb 2022 at 21:02, Cynthia Revström wrote:
>
> Oh right I forgot to add:
>
> > Why is it important to know what objects are protected from deletion?
> If it is not referenced by any resource object (directly or
> indirectly) and it is still in the DB in 3 months time, it is
or an ASN or IP address/prefix)
>
> Regardless, given the low number of protected handles, I think it
> makes sense to contact them before doing this and protect them using
> the new method unless they object to it.
>
> -Cynthia
>
> On Mon, Feb 21, 2022 at 3:56 PM denis walker via
Hi Ed
On Tue, 22 Feb 2022 at 09:54, Edward Shryane via db-wg wrote:
>
> Hi Massimo,
>
> > On 21 Feb 2022, at 16:29, Massimo Candela via db-wg wrote:
> >
> > Hi Ed,
> >
> > Thanks for the work done.
> >
>
> Thank you!
>
> >
> > On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
> >
> >> We will
Hi Ed
Can you clarify this comment...
>
> Our Legal team have considered the concerns from a part of the community
> regarding the eligible size for “geofeed:” validation and concluded the
> following:
> Since resources with prefix size equal to the size distributed/registered by
> the RIPE NC
Colleagues
The co-chairs recently had a zoom meeting with the RIPE NCC. One of
the things we discussed was clearing up a number of old issues. We
need to clear the deck and move on with new and perhaps more relevant
issues. We will address a number of issues for the last time. In some
cases the ch
Hi Sasha
Thanks for the update and all the work you have put into this.
cheers
denis
co-chair DB-WG
On Fri, 4 Feb 2022 at 13:12, Sasha Romijn via db-wg wrote:
>
> Hello all,
>
> FYI, following up on various discussions and the BoF we had on this list
> about NRTMv4 and NWI-12, a draft has now
Jan 04 (Tue) at 10:28:04 +0100 (+0100), denis walker via db-wg wrote:
> :Hi all
> :
> :If people want to add geofeed for smaller sizes this runs the risk of
> :maintaining a dual system, "geofeed:" and "remarks: geofeed". We could
> :end up with "remark
Hi all
If people want to add geofeed for smaller sizes this runs the risk of
maintaining a dual system, "geofeed:" and "remarks: geofeed". We could
end up with "remarks:" values being parsed as they used to be for
abuse contacts before we added "abuse-c:".
My understanding was that a "geofeed:" c
Colleagues
In advance of my presentations tomorrow, if you have a spare 15
minutes please watch the pre-recorded presentation:
https://ripe83.ripe.net/wp-content/uploads/presentations/DB_WG-Denis_Walker-Purposes83.mp4
cheers
denis
co-chair DSB-WG
To unsubscribe from this mailing list, get a pass
Hi All
My presentation on "RIPE Database Purposes in the 2020s and Beyond" is
pre-recorded. It is available to be viewed here:
https://ripe83.ripe.net/wp-content/uploads/presentations/DB_WG-Denis_Walker-Purposes83.mp4
I hope as many people as possible will watch this over the next week.
It is an
Hi all
In the Legal Review it seems to assume that for assignments "that are
reasonably assumed to be related to one individual user", that user is
a natural person. A /32 can be a business.
There is a suggestion to allow geofeed for registrations over a
certain size. What is the implication of t
Colleagues
At a recent BoF Ed suggested adopting Sasha's design as the solution
definition for NWI-12. We would like some feedback on this. Do you
agree/disagree with this proposed solution? If we can reach a
consensus the RIPE NCC can move ahead with an impact analysis.
cheers
denis
co-chair DB-
Hi Bijal
Thanks for publishing your final draft. Despite my strong critical
reviews, the chairs would like to thank all the members of the Task
Force for the work you have done over the last two years in difficult
circumstances. We look forward to some interesting discussions ahead.
cheers
denis
Routing Policy Specification Language (RPSL)
> We do think that it’s worth clarifying that RPSL is not a requirement of the
> RIPE Database and that the relevant working groups should look into
> deprecating this old standard.
>
> 5.4 Purpose: Facilitating Internet operations and coordinat
Hi Ronald
On Thu, 16 Sept 2021 at 03:16, Ronald F. Guilmette via db-wg
wrote:
>
>
> I have already made the decision not to wait for the year or two it might
> take for some functionally useful change to percolate up through the
> various relevant departments, organs, and discussion lists. I've
Hi guys
What you are suggesting here is quite a significant change to the way
the RIPE Database (and maybe IANA) works. The block 82.156/16 is not
(or no longer) in the RIPE Database. There are place holder objects in
the RIPE Database for non RIPE address space. All these place holder
objects con
Hi
I would say forget IANA, forget RDAP and if you don't know which
region a resource may be in use the RIPE GRS service. The mirrors are
updated daily so you will get an accurate answer for the resource
wherever it is today.
cheers
denis
co-chair DB-WG
On Wed, 15 Sept 2021 at 19:09, Gert Doerin
Colleagues
We had one comment on this. Does anyone else have an opinion?
cheers
denis
co-chair DB-Wg
On Mon, 6 Sept 2021 at 15:19, denis walker wrote:
>
> Colleagues
>
> There have been a number of cosmetic changes to the RIPE Database in
> recent months. There is no agreed procedure for making
Hi Frank
The RIPE NCC mirrors all the RIR's whois databases and provides a
Global Resource Service (GRS). This can be easily accessed using the
webupdates interface
https://apps.db.ripe.net/db-web-ui/query
You select the option "Search resource objects in all available
databases" and you will get
Hi Ronald
Just to clarify what we mean by notifications.
'individual notification in advance' - means sending an email to the
contacts of the MNTNER objects of all the objects to be updated by the
cosmetic change before the change takes place
'update notifications' - these are the notification e
Colleagues
There have been a number of cosmetic changes to the RIPE Database in
recent months. There is no agreed procedure for making these type of
changes. In particular the extent to which the community is informed.
Examples of the type of changes we are talking about are:
1/ When the ORGANISAT
Colleagues
The DBTF asked for comments about their latest draft document by 13
August. So far I have seen only one comment. So I am taking off my
co-chairs hat and putting my devil's advocate hat on again and I will
make some comments of my own and raise a number of questions. I make
no apologies
Hi
Taking my co-chair hat off, my personal view is, yes it is a bad idea
to add a remark. This has been done many times in the past where
objects have been modified as part of an agreed update. Some of these
remarks have never been removed. They have been there for over 10
years. Objects then get
Colleagues
At RIPE 82 during the NWI review, the chairs recommended two changes
to the way historical queries for operational data work:
1/ Drop arbitrary restriction of most recent deletion point of
re-created objects
2/ Allow access to history of deleted objects that have not been re-created
T
Colleagues
The chairs recognise a consensus to force "status:" values to
uppercase on updates and for the RIPE NCC to perform a one time update
across the database to convert existing "status:" values to uppercase
where necessary.
We ask the RIPE NCC to go ahead with this process and inform the
c
Colleagues
Has anyone read this latest draft report from the Database Task Force?
Does anyone have any comments about any aspect of it's content? Do you
agree or disagree with any of the recommendations? Does the report
cover topics you expected the Task Force to consider? Has any topic
been misse
Colleagues
Whilst part of the discussion continues, there does seem to be a
consensus on adding AS23456 to the reserved list maintained by the
RIPE NCC. This would prevent anyone creating a ROUTE(6) object with
AS23456 as the origin.
The chairs also recognise the consensus to not delete or modify
Hi Niall
On Fri, 2 Jul 2021 at 17:21, Niall O'Reilly via db-wg wrote:
>
> George, Ed, everybody,
>
> This seems as good a moment as any to wave the POLA, transparency,
> and due-process banners.
>
> On 1 Jul 2021, at 23:46, George Michaelson via db-wg wrote:
>
> > I don't think this problem has a
Hi Job
I admit to being a 'not well informed' routing person but let me try
to interpret what you have just said.
The origin ASN may or may not be registered when the ROUTE object is created.
The origin ASN can be returned (AUT-NUM deleted) after the ROUTE
object is created
The ROUTE object may o
Hi Ed
Thanks for the data. This is quite bad. As recently as March this year
someone created a ROUTE object referencing an unregistered ASN:
193.110.94.0/24AS16712,20210318
This is not 'accurate data' that resource holders are contracted to
enter into the RIPE Database. It could simply be a typo
Hi Guys
To create a ROUTE(6) object in the RIPE Database, the referenced
origin AUT-NUM object doesn't need to exist in the RIPE Database. But
should the ASN have been allocated by one of the RIRs?
So perhaps the first questions to answer aren't about whether or not
we should delete these ROUTE(6
101 - 200 of 326 matches
Mail list logo
