The same thing occurs if there's a less specific route(6) object.
I would suspect that this is probably unintended behaviour?
-Cynthia
On Mon, 15 Apr 2024, 13:12 Aleksi Suhonen via db-wg, wrote:
> Hi,
>
> When migrating a route from one ASN to another, the best practice is to
> create a
+1
On Fri, 5 Apr 2024, 14:08 Edward Shryane via db-wg, wrote:
> Dear colleagues,
>
> Currently, Whois query does not support the "sponsoring-org:" attribute in
> an inverse query, i.e. to find all resources sponsored by an organisation.
>
> The "sponsoring-org:' attribute was added to the RIPE
Ah, that makes sense!
Thanks for the explanation. :)
-Cynthia
On Fri, 29 Mar 2024, 01:57 David Tatlisu, wrote:
> Hi Cynthia,
>
> One of the reasons volunteers are asked to send their names off-list is to
> prevent people from assuming they don't need to bother if somebody else has
> already
Hi David,
May I ask what the reasoning behind contacting you directly is?
It seems quite strange and lacking in transparency to me.
-Cynthia
On Fri, 29 Mar 2024, 01:25 David Tatlisu via db-wg, wrote:
>
> **
>
Hi,
In the DB-WG interim session I mentioned that there's currently a
discrepancy between person objects and role objects with regards to
contact information.
More specifically, person objects currently require a phone number
while role objects require an email address.
I think we should try to
If we have time after the main topics, I would like to discuss RDAP a
bit as I feel like there are some issues that need to be addressed.
-Cynthia
On Mon, Jan 8, 2024 at 11:00 PM David Tatlisu via db-wg wrote:
>
> Hi,
> Picking up from RIPE87, the first interim working group session for the
>
Hi Ed,
I do feel like there should be some way to opt out from receiving
personal data and avoid rate limits.
Would it maybe make sense to have an alternative RDAP service with
rate limits at another "base URL"? (such as
https://rdap-rl.db.ripe.net/[...] or whatever)
This is assuming that it is
I agree with Peter.
I assume the NCC legal team thinks this is what is needed to allow for
geofeeds for /48s and such, and if so I am happy with that.
-Cynthia
On Thu, Nov 2, 2023 at 10:03 PM Peter Hessler via db-wg wrote:
>
> Hi Denis,
>
> That text seems fine to me. I think the key point is
Hi Ed,
I really appreciate the detailed impact analysis and there are some
things in there that I hadn't considered before.
Among those things is the effect on RDAP which for me honestly feels
like a showstopper (especially in combination with the rest of the
issues).
I was initially for this
I think I still support this proposal if it would be realistic to
implement without breaking too many things.
Like what would the impact on RDAP be for example?
I guess what I am saying is that I want to see a proper impact
analysis before I can decide if I support it or not.
-Cynthia
On Wed,
Look, you can never be certain that 100% of networks are going to
accept your prefixes but for DDoS that shouldn't matter as others have
pointed out.
What I can say is please don't create 65536 route6 objects or
otherwise I feel like we are going to have to start discussion about a
policy to
Hi William,
I assume there has been a mistake here regarding the role of Maria?
-Cynthia
On Sun, 14 May 2023, 22:45 William Sylvester via db-wg,
wrote:
> Below is the agenda for the Database Working Group for RIPE86. If you
> would like to present, have questions, comments, or requested
Hi Ed,
I still support this solution just as I was back in March 2022 and I
would like to see it implemented.
-Cynthia
On Thu, May 11, 2023 at 2:38 PM Edward Shryane via db-wg wrote:
>
> Dear Colleagues,
>
> Following is an update for NWI-14, to protect references to objects in the
> RIPE
Hi Tobias,
There is a very good reason for why you probably don't want to use a /48
for more than one site and that is routing.
You pretty much can't get anything more specific than a /48 into the DFZ
and as most orgs using PI space probably don't have their own backbone
networks it wouldn't
Hi db-wg,
I just want to start out by saying that I support efforts to try to better
understand and document this.
What I don't (currently) support is changing DB policy (policy in the form
of RIPE documents or policy enforced by the RIPE DB software), especially
before we really know much about
Seems like a reasonable thing to do.
However with anything that changes after such a long time I think you
should notify all relevant admin contacts and maintainers a week or two in
advance. This is just so they have a chance to object if it would be the
wrong maintainer or whatever. Also make
Ah, I guess I misunderstood you then.
However I still don't really see this as an issue if it can help some orgs
work around weird geoip providers.
I still don't support this proposal, sorry.
-Cynthia
On Thu, Jan 12, 2023 at 11:31 AM denis walker wrote:
> Hi Cynthia
>
> On Tue, 10 Jan 2023 at
Hi denis,
I have to say that I don't agree with you at all here.
The current state of this is just the same as the org-name attribute which
is user editable in organisations without co-maintained resources.
It doesn't make sense to me to somehow give this country attribute more
weight than the
Hi denis,
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 are currently causing issues I
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.
-Cynthia
On Tue, Nov 29, 2022 at 7:30 PM Nick
I have just been informed that AS-AMAZON in the RIPE DB is indeed
causing issues for Amazon currently, so please disregard that
question.
-Cynthia
On Fri, Nov 25, 2022 at 12:20 AM Cynthia Revström wrote:
>
> Based on what has been said in this thread so far, I cannot support
> automatic
Based on what has been said in this thread so far, I cannot support
automatic clean-up of AS-SETs even if they are empty.
There is simply way too little to be gained compared to the issues it
could cause.
Also if there is someone who maliciously created a short AS-SET, they
could simply just add
Hi Denis,
While I agree with your goal of trying to clean up the DB more
generally, I think all of the more general issues have to be left for
another time as I don't think that is appropriate for a NWI and should
be done through the PDP.
I think we should purely tackle the issue of as-sets for
Hi DB-WG,
While looking into the discussion about requiring hierarchical as-sets
I wanted to see if all current hierarchical as-sets were authorized by
the ASN holders and I found two separate issues (in my opinion).
I could find at least two cases of hierarchical as-sets that were
likely
Hi,
I am not going to outright support this proposal as I think that this
is not really the way we should be dealing with it.
The main reason for this is because I think it is quite pointless
unless every common IRR database does it. (all RIRs + RADB, ALTDB,
etc...).
Also there is no way to
Hi Ed,
I noticed that my personal org object got updated but I didn't get a
notification email to the mnt-nfy email (on the maintainer that has
mnt-by), was this intentional?
If it was intentional it is not a huge issue, but I would prefer
getting notifications for all edits (including this one).
Hi William and Denis,
Is Denis talking about the proposal as co-chair or as proposal author?
If it is the latter then I think it would be good to clarify that.
-Cynthia
On Mon, Oct 10, 2022 at 7:23 PM William Sylvester via db-wg
wrote:
>
> Below is the agenda for the Database Working Group
It is an optional attribute and as far as I know it is going to stay that
way.
-Cynthia
On Mon, 22 Aug 2022, 10:13 Horváth Ágoston János via db-wg,
wrote:
> I, for one, with my regular internet user hat on, am strongly against any
> form of geolocation and consider it an invasion of my
I am not sure how you came to that conclusion, the way I read Maria's
email didn't make me come to a conclusion anything like that.
Maria said:
> The RIPE Database is meant to contain specific information for the purposes
> that are defined in the RIPE Database Terms and Conditions.
The RIPE DB
After having looked closer at Article 3 of the RIPE DB T[1], I have
to agree with Denis and the legal team, geofeed doesn't really fit
into any of those purposes.
I should have done this earlier but I have to admit that I had never
properly read the RIPE DB T before and it was quite dumb of me to
Hi Denis,
You raise some very good points and I agree with you that we should
update the purposes and establish procedures for doing so.
Also could someone explain to me how I should interpret Article 8.3,
does that mean that the T can be altered by the Policy Development
Process?
Article 8.3:
Hi Ronald,
I do not think that this is the issue here and I think I probably
agree with you and most others on the db-wg when it comes to geofeed.
I think this is possibly at least in part a misunderstanding between
the db-wg/db team and the ncc legal team.
The purposes could change to include
I think I agree with Randy here, geofeed is not really for research
purposes but rather for content providers.
-Cynthia
On Thu, Jul 28, 2022 at 3:52 PM Randy Bush via db-wg wrote:
>
> > I don't think that is a reasonable conclusion to draw from what was
> > said.
>
> to be honest, and maybe
Hi Ronald,
Please see replies below.
On Wed, Jul 20, 2022 at 4:52 AM Ronald F. Guilmette via db-wg
wrote:
>
> In message
>
> denis walker wrote:
>
> >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.
>
>
Oh wow, honestly not sure how I missed that, thanks!
-Cynthia
On Tue, Jul 19, 2022 at 5:47 PM Edward Shryane wrote:
>
> Hi Cynthia,
>
> > On 19 Jul 2022, at 02:25, Cynthia Revström wrote:
> >
> > The reasoning totally makes sense to me.
> >
> > Honestly just having a good central place with
The reasoning totally makes sense to me.
Honestly just having a good central place with links to documentation for
the RIPE (NCC) services would solve the issue I had.
-Cynthia
On Mon, Jul 18, 2022, 09:39 Edward Shryane wrote:
> Hi Cynthia,
>
> Thanks for your feedback,
>
> > On 15 Jul 2022,
This looks great!
I just have one small question, why did you choose to have it on
apps.db.ripe.net instead of some more general RIPE (NCC) services
documentation thing to have it all in one place?
I think it was RIS or Atlas that I saw that have this same style of
docs so to me it would make
I don't think I really made any big comment so I am guessing it was
that but if a /16 wasn't needed for demonstration purposes, I prefer
using the documentation specific prefixes (as you mentioned) of
course.
-Cynthia
On Mon, Jul 11, 2022 at 11:09 PM Edward Shryane via db-wg
wrote:
>
> Hi
Hi Sylvain,
Is your issue simply with using 128.9.0.0/16 and 128.9.128.5/32 as
examples rather than a prefix reserved for documentation or something
like 192.168.0.0/16? (there is no /16 for documentation purposes
afaik)
It is a bit difficult for me to understand what you mean so please
correct
Hi denis,
I agree that this might be an issue (although personally I haven't looked
into it) but I am not quite sure what we can do about it beyond just
removing the field.
Free form text fields are complicated and maybe it should be considered
separately as I think we want to get a good picture
Hi db-wg,
I just want to say that I mostly support the current proposal of 2022-01 (v2).
I would prefer it if the following section was reworded in some way to
make it more clear how the full home address is never justified and
how the default should be no address at all for individuals.
Also I
Personally, I think that we should write e-mail into the policy as I
do think requiring a policy change to change this is reasonable given
how I don't see this changing in the foreseeable future.
Sure it might be different in 10 years, but maybe we can be ok with
needing to use the PDP if/when
Hi,
On Wed, May 25, 2022 at 8:28 PM Leo Vegoda 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 the db-wg,
NCC Access account as far as I know.
>
> -Cynthia
>
>
> On Wed, May 25, 2022, 18:38 Leo Vegoda wrote:
>
>> 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
d, 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
Even if it could mean that email might also be broken that is not
necessarily the case.
Many companies use cloud services for email so they might be completely
unaffected by their network issues.
Also just because something is broken doesn't mean it's so broken email
stops working.
And of
>
> > 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 RI
Hi,
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
; > personal) address.
> >
> > Having a simple rule like 'we don't publish names or addresses of
> > natural persons' is easier to apply and less error prone. But we are
> > turning the RIPE Database into more like a domain registry where lots
> > of details are hidden
I can't think of a good reason to ever have history for attributes like
descr and remarks.
And I totally agree with Sebastian that just because the data might have
been copied by others on the internet doesn't mean that the NCC should keep
redistributing it.
-Cynthia
On Wed, May 18, 2022, 11:42
Hi,
I am generally in support of this policy, however I do wonder why
publish legal names of individuals in the cases of natural persons
holding resources?
Like why can't it just be some alias and the real name needs to be
requested from the RIPE NCC by court order or whatever would be
required
Hi,
Sorry for the late reply, I didn't see that you had replied.
The reason that I think the last deletion should be the cut-off point
is that it feels quite natural, you deleted the object, it should no
longer exist.
Also given how a decent number of individuals now have resources from
the NCC
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)
Quite a few LIRs do lease out address space and some of them will
probably be /24s that are leased out in their entirety.
While there
Hi,
I am sorry for the delayed response but I object to removing that constraint.
It feels problematic to me from a privacy perspective, and it feels
like the last deletion point is a fair balance between providing
useful info and not providing too much info.
I don't think this restriction
Hi Ed,
I might be misunderstanding but mnt-ref on mntners sounds like a catch 22.
If mnt-ref would only be needed for mnt-by and any other references to
mntners except mnt-ref I suppose it would be fine.
But generally speaking here I think I support it for the object types
excluding mntners but
Hi Sasha,
I think you have partially understood it but also just the NCC's side.
I think both myself and others have argued basically the same thing
you are arguing here but in slightly different words.
I have talked about how it makes no sense to not be able to publish a
geofeed url for a
> The RIPE NCC are creating /24 top-level allocations, but this size could also
> be used as a single (second level) assignment. However, we don't have a way
> (yet, see NWI-4) to distinguish between an allocation and assignment of the
> same size. Geofeed is allowed on a top-level resource but
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
protected.
It is just because you will not know if it is protected until it
> Just a side point for people to think about, should the NCC only offer
to protect ROLE objects that do not contain personal data?
I do not think so, I still want to keep the functionality of
whitepages, I only agree with removing duplicate implementations of
it.
I know that both me and several
Hi Denis,
While I kinda support this, I also like how the whitepages feature
allows you to easily see if an object was protected from deletion or
not.
Would it be possible to add some kind of extra data in the whois
response for protected objects? (like the data about abuse email when
you query
Hi,
My opinions on this can probably be summed up with me pretty much
entirely agreeing with Job, Randy, and mostly with Gert.
With regards to Gert's reply I would just like to say that I think
trying to decide who is and isn't a legal entity is something really
complicated and last I checked
+1
This seems like legal might have forgotten that end user could mean a
legal entity (and probably does in far more cases than not).
Also I don't get why the geofeed attribute would not be acceptable,
when you can add an admin-c attribute with the individual end-users
name, address, and phone
This seems weird, I would assume it should be greater than 48, not
greater than or equal to 48.
Ed, can you confirm if this is intended or not?
Also I agree with Peter Hessler, you should always be able to add a
geofeed attribute to all blocks assigned/allocated by the NCC.
And to not make it a
I also want to add that I don't personally see any real issue with keeping
the route objects for a /24 that's either going to be used for a deprecated
purpose or not used at all.
This is in contrast to the potential issues that could arise from removing
route objects that were used.
I think the
I think the best option here would simply be to ask IANA (possibly through
the NRO) how these prefixes should be handled as I don't think we are
necessarily the correct people to answer these questions.
-Cynthia
On Fri, Oct 8, 2021, 12:01 Gert Doering via db-wg wrote:
> Hi,
>
> On Wed, Oct 06,
Hi Ed,
This looks great, and this kind of transparency seems like a really good
idea.
-Cynthia
P.S. I did note that the thing about geofeeds is linking to an old draft
still, however it has now been published as RFC9092.
On Thu, Sep 30, 2021, 16:24 Edward Shryane via db-wg wrote:
> Dear
Hi Bijal,
> Regarding data minimisation, the question of “data inheritance” is
interesting but probably out of scope for this document.
Why is this out of scope?
I would personally consider this an essential part when talking about data
minimisation and not something you can just ignore.
I have
Hi,
I would prefer option 3 but option 2 is also fine imo.
-Cynthia
On Wed, Sep 15, 2021, 17:28 denis walker via db-wg wrote:
> 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
I just want to add a +1 for what Nick is saying here.
Also, it was terminated according to IANA over 6 years ago, so it is not
really a recent depreciation.
-Cynthia
On Fri, Jul 23, 2021 at 5:54 PM Nick Hilliard via db-wg
wrote:
> Gert Doering via db-wg wrote on 23/07/2021 14:54:
> > While
oops, I replied about this to the previous thread, didn't realize it had
split.
https://www.ripe.net/ripe/mail/archives/db-wg/2021-July/007118.html
-Cynthia
On Wed, Jul 21, 2021 at 12:08 AM Job Snijders via db-wg
wrote:
> Hello db group,
>
> On Tue, Jul 20, 2021 at 10:11:46PM +0200, Edward
Hi,
> (To Ronald and the list) Should we add other sources of bogon prefixes
(e.g. RFC 3068) to the implementation?
With regards to that specific prefix I feel like that should absolutely be
added given that it was also deprecated and terminated in the IANA
registry in 2015.
With regards to
Hi Ed,
Thank you for the quick change :)
-Cynthia
On Tue, Jul 13, 2021 at 10:03 AM Edward Shryane via db-wg
wrote:
> Hi Denis, Colleagues,
>
> I've added AS23456 as a reserved AS number to Whois.
>
> It's no longer possible to create a route(6) object with origin: AS23456,
> now an error will
Hi Ronald,
> Do dues-paying members want to be underwriting the use of bogon ASNs
by members whose ASN registrations have lapased due to non-payment of
relevant annual fees?
I feel like that is not what we are trying to discuss here and is outside
our scope, maybe in the scope of AP-WG. (I don't
Hi Hank,
As Ed mentioned earlier in the thread all of those except AS23456 are
already blocked.
-Cynthia
On Thu, Jul 8, 2021, 08:14 Hank Nussbacher via db-wg wrote:
> On 08/07/2021 00:29, Nick Hilliard via db-wg wrote:
> > Edward Shryane via db-wg wrote on 07/07/2021 15:05:
> >> So 23456
Hi Job,
I just replied to the previous thread regarding this so I have reposted it
below (summary: +1/LGTM)
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.
Hi Ed,
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.
https://apps.db.ripe.net/db-web-ui/query?bflag=false=false=origin=true=AS23456=RIPE
So assuming that I didn't mess up
Hi Ed,
Thanks for the data, based on this I will stand by my opinion that there
should be no action taken here currently.
This opinion is also mainly based on the fact that it is not validated in
the RIPE database.
I am not sure if this is right or not, but I think it should probably not
be
Hi Ed,
Thanks for implementing this :)
I mainly wanted to give my initial take on the AS origin status part which
is in short: I don't think we should clean up based on origin AS.
This is as you do not need any technical authorization from the AS holder
to create a route(6) object.
Additionally,
Hi Ronald,
Could I request that you provide a pastebin of the actual list of prefixes
that you think are at issue here?
-Cynthia
On Thu, Jun 10, 2021, 21:43 Ronald F. Guilmette via db-wg
wrote:
> Friends,
>
> As previously discussed, the decision was made awhile back to remove from
> the data
Hi,
I would just like to say that I would also like this to be implemented if
the DB team determines it to be feasible. :)
-Cynthia
On Tue, Jun 8, 2021 at 1:31 PM Edward Shryane via db-wg
wrote:
> Hi Carsten,
>
> The DB team will create a proof of concept to see if this is feasible, and
> I
For what it's worth, this still has my support.
-Cynthia
On Fri, May 7, 2021 at 12:56 PM denis walker wrote:
>
> HI Ed
>
> As no one has objected I think we can assume you can go ahead with this plan.
>
> cheers
> denis
> co-chair DB-WG
>
> On Fri, 7 May 2021 at 09:20, Edward Shryane wrote:
>
Hi Ed,
This looks good to me :)
-Cynthia
On Tue, May 4, 2021 at 10:36 PM Edward Shryane via db-wg wrote:
>
> Hello Denis, Colleagues,
>
> Following is the impact analysis for the implementation of the "geofeed:"
> attribute in the RIPE database, based on the problem statement below and the
>
Hi Ed and WG,
I am sorry for not looking at this during it's time in RC, but I have
some comments on the new website templates.
I very much appreciate trying to do a more responsive design, to
support mobile and other non-landscape screen layouts etc. (I have
actually needed to use the hosted
Hi Carlos,
> However, in attributes where professional contact data is supposed to be,
> there shouldn't be any kind of filtering.
Just reading this makes me think a bit.
Why would anyone need historical contact information?
And how do those needs exceed the trade off with potentially having
Hi Bijal,
I do not believe more data than is currently available should be made available.
I suppose trying to filter fields that shouldn't contain personal data
could be a good idea but I am not sure how practical that would be.
If you remove all free text attributes other than org-name I
Hi Bijal,
I am strongly against this recommendation and see the "cost" as being
extremely high for the "benefit".
There are quite a few issues and potential issues I can see here, with
seemingly quite little in terms of benefits.
You note this potential benefit:
> This will clarify which
gzip compression. So, basically,
> completion of a data exchange.
>
> Probably in the spirit of what you meant. As long as thats what "200"
> means, I'd be fine!
>
> cheers
>
> -G
>
> On Thu, Apr 8, 2021 at 8:42 AM Cynthia Revström via db-wg
> wrote:
>
e in itself its worth doing. Checking the integrity of what
> they say goes beyond the role of a steerage/directory function.
>
> (my opinion)
>
> cheers
>
> -G
>
> On Thu, Apr 8, 2021 at 8:19 AM Cynthia Revström via db-wg
> wrote:
> >
> > Hi,
> >
&
Hi,
I just wanted to clarify my stance on validation a bit more.
I am totally against trying to validate the data itself, that is not
what the NCC is supposed to do.
Validating the format of the CSV might be okay but honestly anything
beyond validating that it is not a 404 not found is a bit too
it is their job to
> do this for the good of the internet.
>
> cheers
> denis
> co-chair DB-WG
>
>
> On Tue, 6 Apr 2021 at 19:50, Job Snijders wrote:
> >
> > Thanks for the extensive note Denis, thanks Cynthia for being
> > first-responder. I wa
specific subthread.
>
> On Tue, Apr 06, 2021 at 06:38:29PM +0200, Cynthia Revström via db-wg wrote:
> > > Questions:
> >
> > > -Should the database software do any checks on the
> > > existence/reachability of the url as part of the update with
Hi Denis,
I have CCed Randy Bush as I thought he might be able to clarify what
was meant by the following:
> To minimize the load on RIR whois [RFC3912] services, use of the
> RIR's FTP [RFC0959] services SHOULD be the preferred access. This
> also provides bulk access instead of fetching with a
Hi,
I will be honest I wasn't even aware of the TF's existence until quite
recently and just looking at the PDF that denis linked, I have some
questions...
> While the RIPE Database Working Group and the RIPE NCC are able to solve a
> lot of the
operational issues, a high-level approach was
Hi,
I think this thread got stalled last time by getting outside the scope
of the db-wg.
There was more talk of if Geofeed is good or bad etc, but really the
question for the db-wg is the following...
> geofeed:
or
> remarks: Geofeed
And if we limit it to that question, and realize that the
Hi Marcel,
I just want to start out by saying that the working groups are not a
support channel and this more routing than anything db related.
But with regards to your case, according to ripestat the prefixes are
announced by 2 ASNs but overall have 100% visibility (99% for the v6).
I am
Hi Edward,
I can confirm that this appears to be fixed, thanks :)
-Cynthia
On Thu, Mar 11, 2021, 14:34 Edward Shryane wrote:
> Hi Cynthia,
>
> > On 20 Jan 2021, at 17:45, Cynthia Revström wrote:
> >
> > Thanks for the quick response as always :)
> >
> > -Cynthia
> >
>
> We have now fixed
Hi Antti,
I don't believe there currently is a way, but it sounds like a good idea to
me.
-Cynthia
On Mon, Mar 1, 2021, 08:44 Antti Ristimäki via db-wg wrote:
> Hi list,
>
> Is it possible or could it be possible to force two-factor authentication
> for RIPE Access SSO accounts that are being
Hi Robert,
Thank you for the information, is it just anchor hosts or also probe hosts
out of interest?
Personally I don't think this is an issue as long as the DB team has
something to document all other use cases of the handles within the other
parts of the RIPE NCC or RIPE.
I think not
While the whitepages org type system might be a bit odd, I see the need for
some way to explicitly say "I don't want my handle to be cleaned up", for
Atlas and anything else that might rely upon it.
If there is a current system for this that is not whitepages (as Ed seems
to suggest), I would
Thanks for the quick response as always :)
-Cynthia
On Wed, Jan 20, 2021 at 2:50 PM Edward Shryane wrote:
> Hi Cynthia,
>
> > On 20 Jan 2021, at 14:30, Cynthia Revström via db-wg
> wrote:
> >
> > Hi DB-WG,
> >
> > When creating a new object via
1 - 100 of 171 matches
Mail list logo
