HI guys
This is not an issue about the mechanics of the RIPE Database. AFAIK these are
the rules that have been developed over time by the routing community. The RIPE
Database software simply enforces these rules. If you think the rules need
updating to change the who/why/when/how ROUTE(6) obje
Hi Lee
With the current data model it is not possible to have two independent objects
with the same primary key. Creating 2 smaller objects is a work around. Having
2 status attributes is another work around. The question is, which work around
is preferable?
cheersdenis
co-chair DB-WG
On Tu
Colleagues
This is the last of the NWIs from 4 years
agohttps://www.ripe.net/ripe/mail/archives/db-wg/2016-June/005272.html
For this one I am not even sure what is being asked for and I don't agree with
some of the points in the problem statement. Maybe Job can expand on it.
Any comments appreci
If only things had been created in such an orderly way :) Unfortunately not.
In a NIK-HDL the source is a suffix and on set objects the function is a prefix.
On Thursday, 1 October 2020, 14:00:16 CEST, Lutz Donnerhacke via db-wg
wrote:
Of course it’s not necessary.
I just want to po
Hi Ronald
You are mistaken :) The query string can be a single IP address or CIDR or a
range. And the range doesn't even need to be an exact matching range. So if you
search for:
x.y.0.0 - x.y.0.100
and the actual object in the database is:
x.y.0.0 - x.y.0.255
it will still return this database
Hi Lutz
There is no requirement for a source on a MNTNER name. So in your example the
MNTNER could simply be NCC-MNT.
cheersdenis
co-chair DB-WG
On Thursday, 1 October 2020, 08:53:56 CEST, Lutz Donnerhacke via db-wg
wrote:
So the general scheme is SOURCE-NAME-FUNCTION, i.e. RIPE-NCC-M
...with the cut/paste formatting fix...
On Wednesday, 30 September 2020, 19:11:56 CEST, ripedenis--- via db-wg
wrote:
Hi Ronald
The RIPE NCC mirrors the other 4 RIR databases and the mirrored data is updated
daily. If you add '--resource' to your query of the RIPE Databas
Hi Ronald
The RIPE NCC mirrors the other 4 RIR databases and the mirrored data is updated
daily. If you add '--resource' to your query of the RIPE Database you will get
the correct response from the RIR database (mirror) that holds the resource.
for example:whois -h whois.ripe.net -r --resource
Dear Colleagues
This is another 4 year old task about 'encouraging' the transfer of ROUTE(6)
objects for Afrinic resources from the RIPE Database to the Afrinic
Database.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html
Is this still an ongoing task? Is there anything more that
Dear Colleagues
This is another action point that has been open for 4 years. We either need to
progress it or cancel
it.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005240.html
It is basically asking for full history of existing and deleted resource
objects. In the link above on this N
Hi Lutz
Good try but this script does not do it. Firstly, if you start with the
allocation object it needs to be -rM in the first query. Then you are only
looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:"
attribute in the object. It may have both in which case the
Colleagues
We need to take some action on these old NWIs. Either we move forward with them
or we cancel them. It is difficult to draw a consensus on 2 comments. Can you
please give us a couple of minutes of your time and let us know if this NWI-1
is needed, useful or a waste of time.
cheersdeni
Colleagues
Just to be clear the "created:" attribute relates to an 'object' not to a
'resource'. So in this case the creation date has not been changed. This is a
new object and the "created:" attribute reflects the date this object was
created. The main issue with historical data in the RIPE D
he line?
Final comments please?
cheersdenis
co-chair DB-WG
On Thursday, 2 July 2020, 15:19:53 CEST, ripedenis--- via db-wg
wrote:
Colleagues
"We can't change that anymore" Anything is possible and anything can be changed
and any new rules/filters can be implemented. The RIPE NC
cts that could be confused
as a resource object. So if we go down this route where do we draw the line?
Final comments please?
cheersdenis
co-chair DB-WG
On Thursday, 2 July 2020, 15:19:53 CEST, ripedenis--- via db-wg
wrote:
Colleagues
"We can't change that anymore" Any
Colleagues
We have a problem with UTF-8. Many people keep saying you want it, we should
have it, lets do it...But every time we get to these difficult, non technical
questions every one goes silent. This is why we have never implemented UTF-8
since it was first mentioned many years ago. No one
Hi Leo
Some of the questions that need to be answered include:
-who needs to be able to read/understand/interpret which parts of the data in
the RIPE Database (maybe both the community and the NCC need input to answer
this)?-is any of the data contained in the RIPE Database essential for the
op
Hi Leo
As I have said many times, internationalising the RIPE Database is not a
technical issue, it is a registry issue. I think it does need a separate
process from the database requirements. Especially if we consider it as a cross
registry issue.
Incidentally I did suggest on this mailing lis
Hi Ed
The chairs see there is a consensus to move forward with implementing Punycode.
Can you present an impact analysis explaining what changes you propose, what
effect those changes will have on updates and queries (by all the different
methods), if anyone needs to modify their software intera
Hi Nick, George
"fundamentally yeah - it's a bit colonial to continue ignoring the reality that
us-ascii is inappropriate for large chunks of the world."
I totally agree with the drive to disengage with the colonial past and move on
in all areas of life. However, the RIR Databases reflect a publ
Colleagues
After the recent discussion it seems their is support for the idea of UTF-8,
whilst there is also support for Puny code as an interim step.
To implement UTF-8 in the RIPE Database requires much more detailed
discussions, including non technical aspects of the change. This is not likely
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 the RIPE Database has been looked at
several times by the RIPE NCC, but it n
valid.
When querying the RIPE database, any Punycode encoded email address is returned
in Punycode (i.e it is not decoded).
I welcome feedback from the community on this proposal.
RegardsEd ShryaneRIPE NCC
On 22 Jun 2020, at 22:49, ripedenis--- via db-wg wrote:
Colleagues
There has been
Hi Lutz
Is your problem with the RPSL syntax in an AUT-NUM you try to create in the
RIPE Database, or with some RPSL parser you are using on data you have
extracted from the RIPE Database?
Nick, "You may want to think twice about whether it's worth investing time and
effort in rpsl in 2020". Gi
Colleagues
"We can't change that anymore" Anything is possible and anything can be changed
and any new rules/filters can be implemented. The RIPE NCC can, and has on many
occasions in the past, done updates across the whole database to 'fix problems'.
I would suggest that you don't concern yours
NCC.
it is just available at: whois.ripe.net:
- Cynthia
On Sat, Jun 27, 2020 at 10:30 PM ripedenis--- via db-wg wrote:
Hi Lars
There is NRTM, an option to run a 'local copy' of the RIPE Database's
operational data. Of course personal data is excluded from your local copy
Hi Lars
There is NRTM, an option to run a 'local copy' of the RIPE Database's
operational data. Of course personal data is excluded from your local copy. But
you need interaction with the RIPE NCC to set that up. So it is not likely to
happen by Monday.
cheersdenis
co-chair DB-WG
On Saturd
Colleagues
There has been some discussion recently and many times over the years about
addressing this issue. The chairs believe there has been enough support shown
to move forward with this. We would therefore like to present this as 'NWI-11
Internationalised Domain Names'. We propose a problem
Hi Rob
RFC2725 only defines the mechanism, which we already know as it still works
this way (except for the ASN authorisation). But it does not explain 'why' it
is done this way. That was probably discussed in the process of writing RFC2725
:)
cheersdenis
co-chair DB-WG
On Thursday, 11 Jun
situations on
the Routing WG mailing list. The impact of any change is a routing issue. Then
come back to DB WG if something needs changing.
cheersdenis
co-chair DB-WG
On Thursday, 11 June 2020, 15:30:46 CEST, Job Snijders via db-wg
wrote:
On 11/06/2020 03:26, ripedenis--- via db-wg
Hi Sascha
If there is an existing, exact matching ROUTE object the creation of the new
ROUTE object must be authorised by the existing object. There is a flow chart
here explaining the sequence of
checks:https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/
Please do Leo :)
cheersdenis
co-chair DB-WG
On Friday, 22 May 2020, 18:02:07 CEST, Leo Vegoda via db-wg
wrote:
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 t
Hi Tore
Sorry if you misunderstood what I meant. I didn't say that 'you' proposed this.
I said only 'the proposer' of having user defined groups wanted it. I couldn't
remember who it was who suggested it. It may have even been myself who first
suggested that this 'could' be extended to user gr
I would like to second Brian's comments below. The DB-WG has no mandate to
concern itself with issues concerning the RIPE NCC Exec Board. Any discussion
would be inappropriate on this mailing list.
cheersdenis
co-chair DB-WG
On Thursday, 16 April 2020, 10:34:54 CEST, Brian Nisbet via db-wg
Colleagues
The RIPE Database Requirements Task Force recently published notes on their
last meeting showing some of their current thinking and progress so far. This
can be read
here:https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/2020-March/45.html
I am going to play devil's
Actually RE-opened NRTM. It used to be open until it was made a member only
service. But yes it is good news :) Thanks to the RIPE NCC engineers, legal
team and board for coming together to do this.
cheersdenis
co-chair DB-WG
On Wednesday, 18 March 2020, 17:46:10 CET, Cynthia Revström via db
Colleagues
I said at Ripe 79 that I would review the open NWIs. So lets start with NWI-1.
This has been open and virtually static since 2016. The original summary is
here:https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html
The situation has changed since then with the "abuse-c:" at
Colleagues
The chairs of the DB-WG declared a consensus on NWI-10 at RIPE 79. This is to
add a "country:" attribute to the ORGANISATION object which will be managed by
the RIPE NCC in ORGANISATION objects for resource holders.
This email is to document that consensus and ask the RIPE NCC to imple
Hi Arash
If many organisations are using these values then, unfortunately, you are
basing decisions on meaningless values.
The country attribute in resource objects is undefined. Users can set this to
any country they wish with no meaning to anyone reading the value from the
database.
>From th
Hi Cynthia
The country attribute in the INET(6)NUM objects is totally meaningless. The
resource holder can set it to anything they want. Maybe it is the country their
grandmother was born in. It is that useful. NWI-10, which was agreed at RIPE
79, will create a country attribute in the ORGANISA
Colleagues
The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is
an issue that has been debated many times over many years and needs a solution.
The Solution Definition below is based on a presentation made at RIPE 78 by the
RIPE NCC.
There has been very little discussio
Hi Randy
You can also use the restful API described
here:https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/how-to-query-the-ripe-database/14-3-restful-api-queries
for your specific query it returns this:
denis$ curl 'http://rest.db.ripe.net/ripe/inet
Hi Ronald
I am sure the more searching you do you may find more cases like this. But you
are still making the same point. We hear you. Can you suggest any improvements
to the process that will address any of the cases you have already highlighted?
cheersdenis
co-chair DB-WG
(I apologise for not
xists - search for 'ASSIGNED PI' (on IP space) or
'ASSIGNED (on ASNs) with the associated ORG object to see if any exist. Not
exactly (currently) straight forward but it is still definitely doable.
Jacob Slater
On Wed, Jul 31, 2019 at 6:31 PM ripedenis--- via db-wg wrote:
HI Nick
Hi Ronald
I have followed this whole discussion and it seems to be going round in
circles. You have made a valid point, but the whole discussion seems to be
focusing on the negative. Some people have referred you to a number of
published documents about the due diligence process carried out by
Hi Ronald
"If ARIN doesn't vet WHOIS -modifications- then I rather doubt that RIPEdoes
so."
I think it is a little presumptuous to think if America doesn't do something
then no one does it :)
Whilst changes to whois records in the RIPE Database are not all monitored
there are some parts of som
HI Nick
The ORGANISATION object has an "org-type:" attribute. Most ORGANISATION
objects have a value of either 'LIR' or 'OTHER'. If it is 'LIR' that
ORGANISATION object was created by the RIPE NCC for a resource holder and has
been through the due diligence process. If it is type 'OTHER' it wa
and also keep in mind what the goal of this is. Anyone can create a new
PERSON/ROLE object with the same content as one of yours. In other words make
an exact copy. They can then add your MNTNER and then remove theirs after
making references to it. Adding an additional MNTNER doesn't require
a
Colleagues
Problem Definition
There is a need within the routing community to have changes to all/nominated
routing data objects in the RIPE Database pushed out to them, regardless of
membership status.
Last week Aris was the only person to confirm that he wants this feature. If we
are to move f
Colleagues
I think we have now agreed on these problem and solution definitions:
Problem Definition
LIRs would like a mechanism to easily add/remove users to centralised SSO
authentication groups for maintaining objects in the RIPE Database.
Solution Definition
Stage 1
-Non billing Users listed i
Hi Tore
It is not quite true to say the MNTNER objects serve no useful purpose. You are
overlooking the mandatory "upd-to:' and optional "mnt-nfy:" attributes.
The "upd-to:" notifies the maintainer of any unsuccessful attempts to modify an
object maintained by that MNTNER. This could be an indic
Colleagues
We would like some feedback on the following NWIs and their current status.
I would also like to remind colleagues that we have posted a couple of
questions on the Address Policy WG mailing list about policy requirements for
contact details. We would appreciate some feedback on those q
HI guys
You seem to now be suggesting that a form of NRTM for only routing information
(IRR data) and open to anyone without a contract would satisfy what you are
looking for. I thought NRTM is a pull mechanism not a push? Aris mentioned you
need this info to 'create filters'. Not being a routi
ns. An
investigation would then be impacted by consequent changes as a result of the
policy violations being recognised and immediate knowledge of the changes would
serve to best direct the course of an investigation.
Thanks,Liam
On 23 Mar 2019, at 21:34, ripedenis--- via db-wg wrote:
Hi Aris
T
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear.
Knowing how the database is structured I can think of ways of doing this, but
it would be for the RIPE NCC to assess feasibility. I think it may be easier to
do it as a service to members than making it a more
Hi Aris
Can you clarify one point about this. Are you saying you want to be notified if
someone changes their data that you have no direct relationship with? So if I
maintain a set object and you are not part of my company and have no direct
business relationship with me and I have no idea who
Colleagues
All the responses made indicated a preference for the lightweight option to
move forward. Elvis Velea and James Kennedy indicated that they are interested
in working with myself on a policy proposal. We will make a start on this and
bring some issues to the community as we go along th
Colleagues
I made a presentation at RIPE 77 last year about personal data in the RIPE
Database. Whilst I have been thinking a lot about this since then, and some
other comments have been made on different mailing lists recently, no action
has yet been considered.
This is not a trivial issue to
Hi Elvis
We don't need to 'update' any existing policy it could be a new policy
concerning personal data in the RIPE Database. I've been thinking about this
since the last meeting so yes I am fine working with you Elvis on a proposal.
cheersdenisco-chair DB-WG
On Friday, 22 February 2019, 2
Thanks Ed. But keep in mind that there is no consensus yet on the final
solution definition the community wants. The discussion has ranged from a
'magic' MNTNER object, to groups of SSO authorisations managed through the
portal UI to Tore's latest suggestion of directly referencing these groups
Hi Paul
The file name tells you what type of data is in each file. For example the file
ripe.db.inetnum.gz contains information on INETNUM objects.
The information you are looking for on organisations is not available in bulk
format.
In the ripe.db.inetnum.gz file there is a country code so y
61 matches
Mail list logo
