Ben Cartwright-Cox via db-wg wrote on 05/01/2024 14:49:
Sadly --show-personal over whois port 43 also does not return email
for person objects:
$ whois-h whois.ripe.net --show-personal BC6775-RIPE |& grep email:
$
The only way to do this is I guess to scrape the website...
oops, pebkak.
Job Snijders via db-wg wrote on 24/11/2023 09:21:
Wouldn't it be an opportune time to support UTF-8 instead of LATIN-1?
punycode??
Nick
(Sorry, couldn't resist.)
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
Edward Shryane via db-wg wrote on 29/09/2023 15:24:
Following is the impact analysis for NWI-4 "Role of status: field in
multivalued status context" based on the use of the "inetnum:" and
"status:" tuple as a primary key.
Hmm. Ok.
Would it be useful to have a discussion about this at the
denis walker wrote on 21/07/2023 06:22:
On Thu, 20 Jul 2023 at 16:41, Nick Hilliard via db-wg wrote:
the job of a chair is to ensure that the business of the forum is done,
in an orderly and efficient way.
Where is this stated?
Denis,
It's stated in pretty much every formal description
Edward Shryane via db-wg wrote on 20/07/2023 14:50:
As mentioned in my Operational Update at RIPE86, I propose to remove
these obsolete remarks from all objects, on *Thursday 27th July*.
this + removal of the "LOCKED" notice look completely reasonable.
Nick
--
To unsubscribe from this
Randy Bush via db-wg wrote on 20/07/2023 00:22:
I approve of more active WG management for the good of the internet.
i do not.
i am ok with a co-chair explicitly taking their co-chair hat off and
having an opinion with the same weight as everyone else.
i am as happy with activist wg-chairs
Kaupo Ehtnurm wrote on 12/07/2023 14:43:
I was hoping that somebody is experienced with this situation and
could advise me, what the correct way by-the-book would be.
a /32 will work just fine. The IRRDB design is too simplistic to model
even basic inter-domain routing policies properly, so
Kaupo Ehtnurm wrote on 10/07/2023 08:06:
No, but I was wondering what do other AS-s do with my ipv6 prefix, if
they are using IRR filtering in bgp.
I am not talking only about providers and providers providers. I am
talking about all the AS-s in that participate in the global table and
accept
Did your ddos provider say that their upstreams required exact route6
matches for your announcements? The bgp session between you and your
DDOS provider definitely won't require this, and the likelihood is that
a covering /32 route6: object will be sufficient in many cases for your
provider's
Edward Shryane via db-wg wrote on 09/02/2023 13:31:
The DB team wishes to update these inetnums with the responsible
LIR's default maintainer, so they can be maintained by the LIR
without needing to contact the RIPE NCC. We will inform the affected
maintainers.
Please let me know your comments.
Edward Shryane via db-wg wrote on 12/12/2022 13:43:
Dear colleagues,
Please find attached our proposed service criticality form for your review.
We hope to receive your feedback by 23 December.
Hi Ed,
there's no mention in here of the rpki database. Is this handled
separately?
Nick
--
Cynthia Revström wrote on 30/11/2022 22:59:
I am not sure if this feature is used or not however I think this is a
very good reason to not go forward with a clean-up (at least until we
have properly evaluated things).
We will probably have to figure out some other way to deal with
objects that
Niall O'Reilly via db-wg wrote on 30/11/2022 16:15:
If we indeed don't need a policy, I think it would be cleaner
to make this a new NWI, as adding to an NWI after implementation
work has begun seems, IMESHO, likely to cause confusion.
agreed. In terms of breakage, we're carrying a 25yo
denis walker wrote on 30/11/2022 14:26:
This is an interesting point. I know nothing about bgpq3 or peval
(even though it has been around since the beginning of time). So I
just read the documentation on GitHub for them. I never realised this
feature existed. What you have described here Nick is
Cynthia Revström wrote on 29/11/2022 18:56:
I agree with Nick.
However there are currently as-set objects in RIPE based on aut-num
objects in RIPE-NONAUTH.
I think it might be worth considering if these should be cleaned up.
I posted about this about a week ago in a separate thread on db-wg.
denis walker wrote on 29/11/2022 13:00:
If we allow these objects to authorise hierarchical AS-SET objects with
'source: RIPE' we have in effect turned non authoritative data back into
authoritative data. If we give the related AS-SET objects 'source:
RIPE-NONAUTH' we make it clear that these
Niall O'Reilly via db-wg wrote on 23/11/2022 18:17:
What I have in mind is AS-NIALLSPECIAL, which I populate with a list of
AS numbers which I want to advertise to let others know that these
are to be handled in some special way, unlike those in AS-NIALLNORMAL.
According to operational
denis walker via db-wg wrote on 22/11/2022 19:00:
Any thoughts on this? There are 2128 AUT-NUM objects with source
RIPE-NONAUTH. Do we want these to be able to authorise the creation of
hierarchical AS-SET objects when we don't know who maintains the
AUT-NUM objects?
I don't see a particular
Job Snijders via db-wg wrote on 20/11/2022 13:07:
I'd argue that the rules for what constitute valid hierarchical names
should not be changed; so the second component of the name doesn't need
to start with 'AS-'.
you mean "does need to start with 'AS-'"? I don't see how rfc2622
allows naked
James Bensley via db-wg wrote on 04/11/2022 08:46:
I want to discuss a format change to the "members" field of the
AS-SET and Route-Set objects in the RIPE DB. I do not know what the
process is for this so please guide me if this is the wrong place to
raise this.
you're not wrong about the
Sander Steffann via db-wg wrote on 09/10/2022 12:33:
The executive board feedback corresponds to my opinion on this policy,
especially these points:
- It significantly reduces the usability for one of its core purpose - being
able to contact resource holders about their number resources.
- It
denis walker via db-wg wrote on 13/09/2022 14:16:
I was struggling to know exactly
what is meant by the phrase "using the RIPE Database as an IPAM
solution".
the dbtf interpreted this as something along the lines of: "using the
RIPE Database as the canonical reference for the holder's
denis walker via db-wg wrote on 19/07/2022 17:16:
Does anyone think we actually need a postal address for a contact for a
CSIRT team?
the irt object was requested by the CSIRT community. It would be good to
get input from them about this.
Nick
--
To unsubscribe from this mailing list, get
Ron,
Ronald F. Guilmette via db-wg wrote on 24/06/2022 00:40:
Second as was previously discussed, responsiblity, both legal and otherwise,
for any unnecessary "leakage" of PII under GDPR belongs to the party that
first leaked the data. So if some telecom company is carelessly shoveling
their
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 the RIPE NCC.
fwiw, the ripe ncc has consistently been clear that there is a handful
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.
There are some fairly serious structural
Gert Doering via db-wg wrote on 02/06/2022 14:59:
On Thu, Jun 02, 2022 at 04:55:12PM +0300, Max Tulyev via db-wg wrote:
May be you know, if you have a 16-bit ASN, you have a /24 IPv4 network
reserved for you for multicast purposes. It is
233.asnum-hi-octets.asnum-lo-octets.0/24:
Leo Vegoda via db-wg wrote on 25/05/2022 19:28:
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 that the future will look different from
This came up quite a bit at the dbtf, where several of us came into the
discussion with fingers on the throttle of their chain saws.
By the end of the TF discussions, there was a pretty sober realisation
that it was not going to be trivial to get from where we are now, to
where we might want
George Michaelson via db-wg wrote on 13/05/2022 01:59:
Really? Geo is better solved. by Geofeed. There's an RFC for how to tell
people where a network documents its intended use of resources, we do
better to follow it in my opinion
country: isn't intended for geolocation. It's the country
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this
assignment? Why can the allocation not be left as it is and assumed to
be used by the organisation holding it?
What am I missing?
it's a fly in the ointment.
There are three options to handle this situation,
denis walker wrote on 04/04/2022 17:00:
Maybe you can start by explaining why this change 'will' cause
breakage in the wild and how significant that breakage will be.
Denis,
you were clear in your email earlier today that you believe that your
proposed solution for NWI-4 will cause problems.
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...
Sounds good - so long as the discussion comes before the solution!
denis walker via db-wg wrote on 04/04/2022 13:38:
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.
Denis,
This came up in an email of yours from
Ronald F. Guilmette via db-wg wrote on 18/08/2021 13:35:
Regardless of the exact status, I remain perplexed to see blocks with
prefix lengths greater than /24 in the daily RIPE stats file.
not sure why you're perplexed? They're legitimate assignments. The
public DFZ isn't the only game in
Ronald F. Guilmette via db-wg wrote on 05/08/2021 14:10:
I would like to suggest that at the very least these should be moved
to NONAUTH, but preferably deleted altogether.
there's no way of updating a route(6) object with an bogus ASN, i.e.
these objects cannot be corrected.
If you
Gert Doering via db-wg wrote on 23/07/2021 14:54:
While Anycast 6to4 needs to die, it isn't fully dead yet. So routes for
these two prefixes are legitimate.
the discussion is whether it's appropriate for the RIPE NCC to continue
to publish route objects for this prefix, which is a different
Edward Shryane via db-wg wrote on 20/07/2021 21:11:
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g.
RFC 3068) to the implementation?
it's had an interesting history, but as Cynthia points out, the
192.88.99.0/24 assignment is now terminated, so it's unassigned /
Edward Shryane via db-wg wrote on 07/07/2021 15:05:
So 23456 is*not* excluded, but it can be if the DB-WG agrees.
just to be clearer: AS23456 should be included in the list of ASNs which
cannot be used as the origin.
Any objects which refer to it should be flagged for deletion.
Nick
Cynthia Revström via db-wg wrote on 07/07/2021 15:44:
I think that AS23456 should be excluded as I can't think of any good
reason for having such a route object and seemingly no one else either
as there are none currently.
at one point years ago, before asn32s-capable software was widely
Edward Shryane via db-wg wrote on 29/06/2021 10:27:
If you have any feedback, please let us know.
yip - any route which overlaps any prefix block which was marked as
reserved or invalid between 2018-09-04 and today, by any RIR, for more
than the RIR's reclamation pool cool-down period,
Cynthia Revström via db-wg wrote on 29/06/2021 14:00:
I might have a different opinion if it is a huge amount of objects that
could be cleaned up or if it is such a tiny amount that maybe just
contacting the maintainers manually would be enough.
Summary: I don't think it is a good idea unless
Edward Shryane via db-wg wrote on 14/06/2021 15:16:
Thanks, that was my question, should we validate that*either* the IP
or AS is unregistered, or*both* IP and AS are unregistered (and you
indicated*either*).
definitely if the prefix is unregistered.
If there's a nonauth route object
Ronald F. Guilmette via db-wg wrote on 13/06/2021 23:30:
Assuming that that is the current plan, then Ed's results and mine are
in reasonably close agreement with regards to the number of IPv4 route
objects that need to be purged, i.e. some 800+.
Your figure is nearly double that, so obviously,
Edward Shryane via db-wg wrote on 11/06/2021 08:35:
In total I found 825 route objects and 57 route6 objects with
unregistered prefixes, and which are now eligible for deletion.
Taking both non-merger transfers and unregistered / reserved prefixes
into account, I figure 1555 ipv4 prefixes and
Ronald F. Guilmette via db-wg wrote on 11/06/2021 22:19:
Could you please post the 5 URLs for those 5 RIR delegated stats files?
There's a convention. Each RIR has a short name:
afrinic apnic arin lacnic ripencc
and a stats ftp directory:
ftp://ftp.afrinic.net
Edward Shryane via db-wg wrote on 11/06/2021 13:44:
192.175.48.0/24
That last one appears to be an error on my part... and I will be
trying to figure out how & why that one got into my set.
This prefix is listed in ARIN's delegated stats
Ronald F. Guilmette via db-wg wrote on 08/06/2021 00:48:
The last time I checked, there was
nothing within any of the relevant RFCs that explicity stipulated
that the user-id portion of an email address either SHALL or MUST or
SHOULD be treated as case insensitive
the part of an
Ronald F. Guilmette via db-wg wrote on 28/05/2021 04:10:
Given that 1970-01-01T00:00:00Z is rather well known to be the beginning
of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of
the value in the created: field of the record shown above.
It just means that the object
Marcel Zimmer via db-wg wrote on 13/03/2021 08:07:
Do you have a tip for me where I should go troubleshooting?
the prefixes are being originated by both as8422 and as212033. If you
ask as8422 to stop announcing it, it should swing over to 212033.
Nick
Marco Schmidt wrote on 26/01/2021 14:43:
We don’t think a policy is necessary for this work, but we strongly
believe we need an approach similar to NWI-5: "Inform the object holder
that these IRR object(s) refer to an unallocated space. We will then
delete them after a reasonable
Niall O'Reilly wrote on 22/01/2021 09:55:
Creating a policy seems to me to be too heavy an approach in this case.
I would think that a simple request from the DB WG to the NCC
should be enough.
If a greater degree of formality were considered necessary,
a new NWI could be created.
there are
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,
Randy Bush via db-wg wrote on 10/01/2021 23:36:
as today's legal authority, can you tell me if gdpr applies to all parts
of the british isles? asking for a friend.
If you're referring to the UK, the EU GDPR no longer applies there, at
least not since our close colleagues left the EU. They
Ronald F. Guilmette via db-wg wrote on 05/11/2020 13:12:
And more to the point, where may I find the real, actual, and complete set
of zone files? Are they hidden away behind some curtain, or in some secret
room? Who do I have to know in order to be invited to view the real zonefiles
that are
Job Snijders wrote on 30/09/2020 21:38:
A change of scope probably warrants a new NWI, as NWI-3 was (at the
time, in that context) specificly targetted to help mop up after the
transfer of inetnum/inetnum6s when AFRINIC was instantiated.
you're probably right here.
The thinking in developing
Frank Habicht via db-wg wrote on 30/09/2020 22:15:
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
Job Snijders via db-wg wrote on 30/09/2020 21:07:
I agree. The combination of NWI-5 and RIPE-731 obsoleted NWI-3.
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
Ronald F. Guilmette via db-wg wrote on 22/09/2020 20:41:
I should also mention however that I find one small bit of ISO-3166 itself
objectionable. This calls for the territories known as her majesty's
kingdom of Great Britian & Northern Ireland to be designated as "GB",
which I personally find
Aftab Siddiqui wrote on 22/09/2020 12:30:
Just for my understanding, do you need a policy for the NCC to offer
"whowas[1]" service?
I wouldn't see why that was necessary tbh. There's already a good deal
of historical information in the ripedb about previous versions of
objects, which means
Ronald F. Guilmette via db-wg wrote on 22/09/2020 03:13:
I'm not sure that the created date should be altered however when an
existing block, legacy or otherwise, is simply shrunk, as appears
to have happaned in this case.
the better long-term fix might be to make network block history
Ronald F. Guilmette via db-wg wrote on 21/09/2020 09:47:
inetnum:57.224.0.0 - 57.255.255.255
Wasn't the whole of 57.0.0.0/8 registered to SITA?
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks
57.0.0.0/8 RIPE NCC1995-05 Formerly SITA.
ripedenis--- via db-wg wrote on 01/09/2020 23:56:
Let me try to revive this conversation and see if we have a consensus.
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
Horváth Ágoston János wrote on 16/08/2020 19:57:> The ripe whois
database (https://github.com/RIPE-NCC/whois) has an
excellent (=clean, performant and heavily tested) RPSL parser in it for
java. It's minimal work to copy the package, or, since this is BSD
licence, you could release a copy of it
George Michaelson via db-wg wrote on 10/07/2020 01:15:
Raw UTF-8 would work better here. It would permit the model to be
extended naturally into multiple script models. I understand its
inherently more complex than uplift to punycode of the domain elements
in things, but the underlying problem
ripedenis--- via db-wg wrote on 13/07/2020 13:12:
There has been support shown to introduce Puny code as a first step
towards internationalisation of the data, which can be done quickly by
the RIPE NCC.
Do we therefore have support to introduce Puny code now and then
consider how to move
Gert Doering via db-wg wrote on 07/07/2020 16:21:
On Tue, Jul 07, 2020 at 05:03:01PM +0200, Benedikt Neuffer wrote:
I think at the moment it would be easier to update the clients to
convert punycode in whatever encoding you prefer.
Cementing this abomination even more...
No-one likes
Tom Hill via db-wg wrote on 02/07/2020 18:32:
In the case of (i), who in their right mind expects that data to be
accurate?
the last time I looked at this (preso in ripe59, routing-wg) there was
no discernible relationship between rpsl and what was appearing in the
dfz, i.e. r looked like it
Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
I try to be a bit more expressive in the aut-num of ASN199284, but
fail to get accepted at least the valid parts by the RPSL parser.
rpsl(ng) hasn't seen any significant development work since the 1990s,
and the only real update since then
Tom Hill via db-wg wrote on 01/07/2020 15:56:
I'm unable to construct a query to the RIPEDB that looks for mntner
objects beginning with 'as', in order to gauge how common this is. I
suspect that's because the phrase is too short, but if it is possible
please do enlighten me! :)
No direct way
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 or physical location -?
There's no short or easy answer to this - if there
Peter Müller via db-wg wrote on 29/06/2020 18:30:
While the RIPE Whois server returned "NL" as the country of that
subnet [1], the "delegated-ripencc-extended-latest" file available at
ftp.ripe.net [2] only contains 51.15.0.0/16, which points to "FR".
Since the first one result contains the
Leo Vegoda via db-wg wrote on 26/06/2020 17:54:
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 conservative deployment that has a low probability
of causing interoperability problems
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 that the RIPE Database should support internationalized
e-mail addresses. The RIPE region includes a number of
ripedenis--- via db-wg wrote on 07/10/2019 10:28:
While the country code attribute in the RIPE Database can be updated
directly by the resource holder, the Extended Delegated Statistics are
maintained by the RIPE NCC and they were created as part of a joint
effort from the RIRs with a specific
Ronald F. Guilmette via db-wg wrote on 30/07/2019 05:11:
Which can easily be forged.
Ron,
Yes, obviously. Everything which can be created can also be forged.
This includes company registration documentation with national legal
authorities. I.e. national registration authorities are well
Ronald F. Guilmette via db-wg wrote on 29/07/2019 18:39:
In that document section 1.1 (a) seem to the one one and only section
relevant to my question:
a. Proof of establishment/registration
Normally, proof of establishment of a legal person can be registration
with the national
There are ways of flagging whether this process was carried out. One
option would be to use a binary flag. Another would be to implement a
datestamp for the last due diligence process carried out if it's not
been set by the NCC. Lack of data could be flagged by either the
absence of the
Randy Bush via db-wg wrote on 29/07/2019 14:40:
i am not speaking for or against, as i do not understand what the threat
model is.
the idea is that some org objects are created by users and inserted into
the ripe database while others are subject to due diligence by the ripe
ncc. I.e.
On 29 Jul 2019, at 12:02, Carlos Friaças wrote:
>
> Perhaps excluding jurisdictions *outside* the RIPE NCC service region, where
> company related data *can't* be verified by the RIPE NCC.
The RIPE NCC doesn’t claim verification. It only states due diligence.
Nick
Jacob Slater via db-wg wrote on 29/07/2019 06:25:
In this context, RIPE's published guidelines on due diligence
(https://www.ripe.net/publications/docs/ripe-700) cover what exactly is
checked. From my experience, the guidelines are always enforced as written.
As you mention, due to a variety of
Ronald F. Guilmette via db-wg wrote on 03/07/2019 11:49:
My recollection is that there came a time ... I can no longer remember
if that was just last year or the year before... when it was decided
and implmented that the RIPE DB would no longer allow the addition of
route objects for
Edward Shryane via db-wg wrote on 28/05/2019 12:12:
Unfortunately, no cleanup was done when this rule was implemented,
but in recent times we try to do this. I will also contact the
maintainers of these route objects and ask them to fix the holes
attribute(s).
I wonder if this key should be
Cynthia Revström via db-wg wrote on 23/05/2019 14:26:
Ed proposed a change to the WHOIS release process at the DB-WG session @
RIPE78.
This change would be to immediately deploy bug fixes without a release
candidate.
I would just like to voice my opinion on it, so my thought is that maybe
Gert Doering wrote on 10/04/2019 09:22:
Well, it wasn't clear if "store unencrypted" referred to the client or
server side. On the server side, yes, please store one-way hashed in
a secure fashion.
How though? Again, thinking out loud, it's easy enough if you implement
using an unsalted
Gert Doering wrote on 10/04/2019 08:52:
You could, certainly, argue that nobody should do RIPE DB updates in an
automated way...
not at all - I love APIs. We need more APIs.
I was just wondering out loud about how to store access tokens securely.
Nick
Tore Anderson wrote on 10/04/2019 06:19:
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose
an NWI to allow for creating API keys for database maintenance at
https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and
the RESTful API).
you mean a single-factor
Cynthia Revström via db-wg wrote on 09/04/2019 16:38:
I would also like to add that for my purposes, I would need an MD5-PW
auth on that mntner too since I use the WHOIS API.
it might be a better idea to look at ways of improving authentication on
the whois api rather than going a step
denis walker wrote on 07/01/2019 11:51:
then we can get even more flexible if the LIR portal allows you to
define set names for lists of SSO auths. So instead of just flagging a
contact to be included in 'the' list of expanded SSO auths, you can add
a csl of list names in the portal. Then you
Cynthia Revström via db-wg wrote on 07/01/2019 10:27:
I think the current main suggestion is to add a new DB auth scheme, such
as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked
to the LIR except for Billing accounts.
Denis is just pointing out that it may not be advisable
Tore Anderson via db-wg wrote on 07/01/2019 09:32:
* Cynthia Revström via db-wg
I do think that something like SSO would be good but
probably another DB auth scheme, like this:
auth: SSO-LIR no.foobar
I prefer this so that it is just clear that it is a different
thing.
No objections from
On 15 Oct 2018, at 13:00, Job Snijders wrote:
>
> If we deconstruct RIPE-NONAUTH’s current state of affairs we already are
> facing a irreversible concept: if one deletes an object in RIPE-NONAUTH, it
> can never be restored.
If someone deletes their nonauth route/route6, they’re making an
On 15 Oct 2018, at 11:31, Job Snijders wrote:
>
> I'm hesitant to add such things because we don't have such a
> notification & grace period in BGP Origin Validation process when
> processing BGP route announcements either.
You don’t need one there. If there’s a problem with those you can back
Job Snijders via db-wg wrote on 14/10/2018 11:40:
This policy proposal concerns exclusively the RIPE-NONAUTH IRR
database. If you feel strongly about the information in the "RIPE" IRR
source feel free to make a new proposal.
There's no need for a new proposal: a notification mechanism and a
Job Snijders wrote on 14/10/2018 07:48:
When an operator makes a mistake, they've made a mistake.
When someone needs to create multiple ROAs, but only publishes one - it
is an operator error. When one misconfigures things... they are
misconfigured, no big deal.
operator error happens all
denis walker wrote on 25/09/2018 23:55:
So really the only question that must be answered is "Can we justify
holding this amount of personal data on the basis of contacts for
administrative and technical issues relating to internet resources and
network operations?" If the answer is 'no' then
Yes please. This is a very sensible thing to do. Bogons do not belong
in a public IRR.
Nick
Job Snijders via db-wg wrote on 04/09/2018 11:46:
Dear WG,
I'd like to raise the issue of bogon prefixes in the RIPE IRR, and ask
RIPE NCC to remove all "bogon" route object registrations from the
denis walker via db-wg wrote on 20/09/2018 13:04:
This does raise a number of questions:
the requirement for admin-c and tech-c derive from what was thought to
be useful information to have at hand at the time when network
registrations were starting out at the InterNIC, way back in the late
Ronald F. Guilmette via db-wg wrote on 14/08/2018 21:53:
None of them have even had the courtesy to send me a FOAD message in
response.
Their silence on these matters is deafening.
Yes, and there is not a problem with this. The RIPE NCC board of
directors are not involved in day-to-day
BUSH, RANDY, DBWGOPS would like to recall the message, "A test on
AFRINIC range announcing without RIPE route object".
?
1 - 100 of 130 matches
Mail list logo
