Re: [db-wg] Whois Inverse Query by "sponsoring-org:" Attribute
Hi, On Fri, Apr 05, 2024 at 02:08:03PM +0200, Edward Shryane via db-wg wrote: > If there is no objection, I propose for consistency to also add > "sponsoring-org:" to the list of inverse query attributes. *support* Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
Hi, On Tue, Mar 19, 2024 at 03:55:26PM +0100, denis walker via db-wg wrote: > This new anti-spam measure is a convenient point to reflect on how one > part of the RIPE Database is used. Notifications are just one part of > an audit system. Many other parts are missing. To be sending out 30k > emails a day to hundreds of thousands of email addresses stored in a > public database as part of an incomplete audit system has to stop. > Notification emails on this scale are a relic of the past. Just as a counterpoint, I do like my notification e-mails. Push notification in case I do need to care, and *only then*. And I totally dislike having to actually look into some sort of portal / web UI "is there anything I should be aware of?", because this sort of polling is eating brain cycles for no good. (Having a good audit trail is fine, in case I know I'm looking for something - but I do just want to see "something under my administration has changed", in case I do not yet know I should be looking) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] email's disappeared from RDAP output
Hi, On Tue, Jan 09, 2024 at 04:39:01PM +0100, Edward Shryane via db-wg wrote: > Any RDAP client that is making /entity/ requests must comply with the daily > limit according to the AUP: > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-acceptable-use-policy > > We will continue to filter e-mail in entities in RDAP /ip/ and /autnum/ > responses, so that clients do not get blocked just by querying for resources > (i.e. if you want an unfiltered entity, make an /entity/ request separately). Sounds good to me. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] email's disappeared from RDAP output
Hi, On Fri, Jan 05, 2024 at 02:49:43PM +, Ben Cartwright-Cox wrote: > 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: > $ I mixed up options, sorry for that. "-B" works, --show/-no-personal seem to be for filtering whole object classes (-r/-R). -B is documented there, as % -B, --no-filtering % Disables the filtering of "notify:" and "e-mail:" attributes. so... whois3 -h whois.ripe.net -B BC6775-RIPE |grep e-mail e-mail: ripe-whois@benjojo... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] email's disappeared from RDAP output
Hi, On Fri, Jan 05, 2024 at 03:30:23PM +0100, Miguel Herran via db-wg wrote: > I am sorry to say that currently ???no??? there is no any option to return > the personal data in RDAP. We want to be consistent across the interfaces so > since the beginning returning email there was inconsistent and we don???t > want to block users due to inadvertently reaching the daily limit. whois always had the corresponding options, so unilateraly breaking this for RDAP without prior discussion with the WG (at least I did not see anything) might not have been such a good plan after all... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] email's disappeared from RDAP output
Hi, On Fri, Jan 05, 2024 at 11:37:29AM +, Ben Cartwright-Cox via db-wg wrote: > Is there some kind of magic flag I can pass into the RDAP system to > get personal data and be held against a limit? I'm not sure I know of > a way also to get the email addresses out of the whois interface > either, meaning I am simply left with scraping the website (something > I really don't want to do) whois will give you mail addresses if you pass in "-B", or, more modern "--show-personal". The whois server conveniently understands "help" as well ;-) gert@moebius4:/home/gert$ telnet whois.ripe.net 43 ... help % NAME % whois query server % % DESCRIPTION % The following options are available: ... % --show-personal % Include PERSON and ROLE objects in results passing those options to the server might need some fiddling with -- to stop the local whois client from trying to interpret them (I use the RIPE "whois3" client which doesn't try to, but YMMV). Having never used RDAP, I am not sure if an option exists for it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Where are we with NWIs?
Hi,
On Fri, Jul 21, 2023 at 08:44:14PM +0100, Sylvain Baya via db-wg wrote:
> 1. remove your Co-chair hat
> 2. submit a formal proposal
> {other Co-chairs would drive discussions
> regarding that proposal.}
> 3. i am open to discuss it.
So, instead of telling Denis what not to do - why don't you just do
just that: submit a formal policy proposal, and engage in discussing it?
Denis clearly stated that he's getting more active *because nobody else
is doing anything*.
If you do not like Denis' being active - you know what to do.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Where are we with NWIs?
Hi, On Wed, Jul 19, 2023 at 07:41:52PM +0200, denis walker via db-wg wrote: > So I will continue to engage with the community, push out ideas (even > crazy ideas sometimes), start and drive conversations until we get > resolutions. While I might not agree with some of the actual ideas pushed out (and will clearly voice my opinion if that is so), I *do* appreciate having the mix of WG chairs - having some that step back and watch, and also having some that do push for process on topics that they find important. Not all WGs are equal. In address policy, the chair role must be more neutral regarding the actual topics discussed, but still can and should moderate, steer, and if needed, stir the discussions. I see DB as a more technical forum, where NWIs can be discussed on technical merits - so having expert knowledge support this process is, in my opinion, valuable. (Also, this is all on a public and open mailing list, so everybody is free to stand up at all times and say "Denis, this is not what I want"). Gert Doering -- list member -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Route(6) objects
Hi, On Mon, Jul 10, 2023 at 03:13:16PM +0300, Kaupo Ehtnurm via db-wg wrote: > As I can conclude from all the answers earlier, then still my only option if > I want my ip transit provider to be able to advertise some /48 within my /32 > at random times and for random durations is using /32 as route6 object and > hope that everyone in the internet filters "2001:1234::/32 le 48 permit" or > "2001:1234::/32 eq 48 permit" instead of "2001:1234::/32 permit"? > Or actually make the 65536 route6 objects (for each of the /48 that fits into > that /32)? > Or is there a third possibility instead hoping that AS-s from all over the > internet are familiar with this kind of issue and allow /48 prefixes into > their routers instead of exact /32 prefix (although the route6 object states > that our provider should advertise only /32) or making unnecessary > amount(65536 objects for 1x/32) of route6 objects? I think you missed my point that there is no way you can ensure that A Random Network out there will accept any/all /48s from your /32. Router memory is costly, and deaggregation eats up costly memory to the point that people are forced to decide between "I need to buy a new router, to carry someone else's deaggreated prefixes, which I'm not paid for" or "just drop /48s, lots of money saved". Your transit ISPs are paid by you to accept and propagate what you agree between each other. Most other parties are not contractually bound, and as such, free to do what is reasonable for them. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Route(6) objects
Hi, On Fri, Jul 07, 2023 at 05:35:40PM +0300, Kaupo Ehtnurm via db-wg wrote: > "you should be fine for almost all cases" - the "should" part is my problem. > I cannot be certain that all the AS-s in the global internet will accept all > the /48 routes of that /32 route6 object. You certainly can't be certain of that, ever. I, for one, might decide that I will never ever accept /48s out of /32 allocations, and there is nothing you can do - except give me money - to make me change my mind. ... but this is highly non-relevant for "you will be DDoSed by many many networks out in the world" (D = distributed), as long as *enough* networks high enough in the routing food chain will accept the /48. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, On Tue, Nov 22, 2022 at 08:00:47PM +0100, denis walker via db-wg wrote: > Another suggestion. There are 1361 short named AS-SET objects that > don't have any 'members' or 'mbrs-by-ref' attributes. In other words > they are operationally empty objects. (This includes AS-AMAZON.) We > could introduce an automated cleanup process similar to the way we > remove unreferenced PERSON and ROLE objects. If an AS-SET object > remains operationally empty for 90 days it will be automatically > deleted. This would include hierarchical objects. The hierarchical > objects can easily be recreated by the ASN maintainers at any time if > they are needed later. This gets around the problem of who has the > authority to remove rogue objects. It becomes a database cleanup > operation. Any thoughts? I would support that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, On Mon, Nov 14, 2022 at 05:41:16PM +, Job Snijders via db-wg wrote: > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. Support. (Though I think that ASes that use RADB as their primary documentation store deserve some amount of pain, but that's a different crusade) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] NWI-10 Populating End User Organisation Country Attribute
Hi, On Mon, Oct 31, 2022 at 07:42:11PM +0100, Peter Hessler via db-wg wrote: > Notifications are _mandatory_ for all changes, period. Always, always, > always send a notification for changes, even by RIPE NCC. There are no > exceptions. This. (I think we've asked for this before?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] NWI-13 Geofeed Legal Analysis
Hi, On Fri, Jul 29, 2022 at 02:33:07PM +0200, Edward Shryane via db-wg wrote: > We are following the discussion on updating the purposes of the RIPE Database > to accommodate geolocation. Until then we need to perform validation > according to the legal analysis based on the current purpose. If there are > updates on the discussion on the purposes of the database, we will > re-evaluate the situation. In the meantime, this is how we plan to update the > validation of the "geofeed:" attribute: > > (1) Firstly, the current validation based on prefix size is inadequate as it > doesn't account for the intended use. We will replace the validation by > prefix size with validation by "status:" value. In which way would "status:" differenciate between business customers and personal end users? > (4) Resources that are reasonably assumed to be related to one individual > user cannot use the "geofeed:" attribute. > inetnum: ASSIGNED PA > inet6num: ASSIGNED "ASSIGNMENT" = "one *individual* user" is not a valid assumption. It's a customer. Maybe. It might be an enterprise with 100 offices, or Joe Random Personal User. Why is nobody listening here? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] NWI-13 Geofeed Legal Analysis
Hi, On Thu, Jul 28, 2022 at 01:33:07PM +0200, Maria Stafyla via db-wg wrote: > As mentioned in the Legal Review Impact Analysis, if the geofeed > attribute is inserted for registrations of assignments that are > reasonably assumed to be related to one individual user, then the > attribute will be considered as containing personal data and GDPR will > apply. This is why we have proposed to implement restrictions. I maintain that this part of the analysis is fundamentally flawed. The size of an assignment does not have any correlation to the entity that the prefix is assigned to - we can assign IPv4 /32s to corporate customers, and we can assign IPv4 /28s to private end users, and this is perfectly within the scope of the relevant RIPE policies. Inventing restrictions based on "but it looks like!!" guesswork is not what we are paying the RIPE NCC for. *Especially* as the information entered is not PII itself, but a pointer to a URL which could, as has been stated, contain anything from "ZZ" to very detailed addresses, fully under control and fully in the responsibility of the entity maintaining that list. I have the nagging suspicion that people are not listening here, because all this was already said months ago, and we're still running in circles. Gert Doering -- totally not interested in geofeed:, but annoyed by arbitrary restrictions not in line with RIPE policies -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Updating Descr part of object with # results in No Operation
Hi, On Tue, Jun 28, 2022 at 05:13:13PM +0200, Edward Shryane via db-wg wrote: > The DB team will investigate the impact and complexity of making this change > in Whois update. > > If there are no objections we can plan to include it in the next release. Thanks :) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Updating Descr part of object with # results in No Operation
Hi, On Mon, Jun 27, 2022 at 01:47:23PM +0200, Edward Shryane via db-wg wrote: > The comparison logic ignores comments as it's not considered part of an > attribute's value, i.e. it's not significant (it's only for humans to read as > metadata). I find that approach flawed. If I send you an update that differs in parts humans will find interesting to read, and that you are going to *store*, ignoring it as part of the "has anything changed" check will do no good, and create friction at times. Ignoring bits that are *not stored* (like, whitespace normalizations, or possible uppercase/lowercase stuff on attribute names, etc.) makes sense to me. Emphasis on "not stored". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] rfc2770
Hi, On Thu, Jun 02, 2022 at 05:08:36PM +0300, Max Tulyev via db-wg wrote: > Sure, I know this. Now there is a global lack of IPv4 address space, so > things can be changed. I would like to try. And may be to push some > things globally. > > I do not know any example of 233 net usage like it was designed. Are > there any? This is multicast. It will not work as unicast. And, the GLOP RFC does not authorize use as anything else but multicast. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] rfc2770
Hi, 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: > https://datatracker.ietf.org/doc/html/rfc2770 > > My ASN is 29632, so the prefix is 233.115.192.0/24 > > I would like to start using it (well, for testing purposes now). To do > so, I need a route object in the RIPE database. Multicast networks are not announced in BGP, so, why do you need a route: object for? (These addresses must never be used as a source IP, and for destination resolution, a multicast tree needs to be built by MP-BGP, MSDP, PIM) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] phone number required for person objects
Hi, On Thu, May 26, 2022 at 12:55:50AM +0200, denis walker wrote: > I can't imagine anyone dictating an abuse report over the phone. I *can* imagine myself calling someone and saying "there is a massive DoS attack coming out of your network. NOW. This is urgent". Abuse is more than "yeah, someone on your network sent spam, slap him when you feel it's convenient". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] phone number required for person objects
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 technologies must be listed. Then we can add and remove > technologies as needed without having to make decisions about what > people *must* use. I like that suggestion. > But if we must define a single technology that is mandatory then > e-mail is a better choice than phone. I actually disagree with that - speaking from my use case as a user of the RIPE DB. If I bother going there, it's urgent, and I want something to happen *now* (otherwise, I'm not going to bother). E-Mail might arrive with any delay, or never, and feedback might come, or not. So, no, *for the purpose of contact data in the RIPE DB*, I do not think that "e-mail is better than phone". (Of course I personally hate it if people call me. But people who do so pretty quickly learn the difference between "it is urgent *now*, so phone is perfectly fine" and "an e-mail would have been sufficient") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] phone number required for person objects
Hi, On Wed, May 25, 2022 at 04:50:57PM +0200, Cynthia Revström wrote: > P.S. Yes all of these networks could just use role objects and as such > not have to publish phone numbers but I argued for why they shouldn't > be required as it seemed to me like Gert didn't quite understand why I > think it is a bad idea to require them, beyond the inconsistency. Maybe I expressed myself badly. I was primarily describing my use case "why would I want to look at *anything* in the RIPE-DB" - and that is, usually, because something is broken and I find myself in the need to contact people. In that situation, their network might be broken (or mine, or something in between) so e-mail or a web form might just not work - this is why we have a phone system. If nothing is broken, I do not look at person or role objects at all. That said, of course having "no phone number" is a better data set than "a phone number that looks good to the DB but is useless" :-) *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 reason we store contact data there, to reach responsible persons/teams when there is something with their network that needs attention. On this particular discussion: I agree that it makes no sense to have the phone number optional on a role: (*this* is usually a NOC that has a phone...) and mandatory on a person: - make it optional on both. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] phone number required for person objects
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 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 I think should be fixed (as in not require > it for person objects either). I'm not sure I agree - as in "why is there a person/role object in the first place? -> so I know who to call in case things need an urgent resolution!". And, calling people needs phone numbers... So, I agree that the inconsistency between person: and role: does not make much sense (I might see a role: object and want a phone number to call...) - but the more fundamental question is "if that object is of no use to a person looking for a point of contact, why have that object there in the first place?"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
Hi, On Fri, May 13, 2022 at 02:23:48PM +0200, Bill Woodcock via db-wg wrote: > Exposing something other than a reserved country-code in RIPE???s > user-facing software is a Simple Matter of Programming, and keeps > RIPE from looking like they???re overstepping their mandate in a > particularly clueless way. "Simple"? Maybe you can enlighten us how to achieve that Simple Matter, in the context of "country:" attributes which have a well defined syntax. This is not about "any arbitrary web interface which displays a list of fully spelt-out country names" (where internal representation would, indeed, not matter). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] [exec-board] Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
Hi Job, On Fri, May 13, 2022 at 01:11:23PM +0200, Job Snijders wrote: > I???ll ask to add the topic of recognising Kosovo in software and processes > to the agenda of an upcoming executive board meeting. Thanks a lot. gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
Hi, On Fri, May 13, 2022 at 12:51:12PM +0200, William Weber via db-wg wrote: > My main problem is i cannot even sign up a LIR from Kosovo easily - I get > told by RIPE to select either Serbia or Albania and provide documents from > either country, direct quote from support: > > > You will be asked to select the country the company is registered in > > depending on the company registration papers provided. > This documents are obviously issued by the ministry of finance of *Kosovo*, > so what the hell should i provide? Do i go s*** d*** at the Albans to issue > me an Albanian incorporation cert with "Pristina, Albania"? I think this is not so much a DB-WG issue, but a NCC members / board issue. Board, are you listening? :-) (Wether or not something can be put into the DB is a trivial code change, but if membership processes do not allow that "thing" in the first place, DB-WG can't fix it) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi, On Thu, Feb 24, 2022 at 06:21:55PM +0100, Edward Shryane via db-wg wrote: > We need to satisfy the Legal review to not allow geofeed on a prefix > reasonably assumed to be related to one individual user, Yes. > by not allowing it on ASSIGNED PA or ASSIGNED PI (not assigned by > the RIPE NCC). No. ASSIGNED status does not allow the assumption "this will be one individual user". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi,
On Thu, Feb 24, 2022 at 04:28:39PM +0100, Edward Shryane via db-wg wrote:
> The Legal review in November recommended:
>
> "if the geofeed attribute is inserted for registrations of assignments that
> are reasonably assumed to be related to one individual user, then the
> attribute will be considered personal data. "
This is something I'd agree to.
The consequences of that ("insert arbitrary rules into the RIPE DB based
on assumptions on what might or might not consider an end-user assignment,
and disallow some attributes on that"), not.
We don't ever register inet(6)num: for individuals, only for corporate
customers.
Even if we did, if I had agreement from the customer (in writing!) that
they are fine with me putting their full name, phone number, postal
address *and* geofeed attribute in the DB, this is not the NCC's
business to disallow "geofeed", while allowing all the other PII data.
(Just for completeness, I don't actually intend to *use* geofeed, but
this discussion really upsets me, because it's wasting life time for no
good reason)
Gert Doering
-- LIR contact
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi, On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane via db-wg wrote: > Please let us know what you think. I think the NCC's legal team is still off a weird tangent... Prefixes assigned to legal entities (non-persons) are never PII. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi, On Tue, Jan 04, 2022 at 10:00:54AM +0100, Edward Shryane via db-wg wrote: > We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* > than /48, the message is consistent (i.e. greater than or equal to /48 is > *not* allowed). > > We are following Legal's recommendation not to allow geofeed to be added for > assignments that are reasonably assumed to be related to one individual user. The IPv6 address policy clearly states that it's up to the ISP what size they want to assign to end users (up to a maximum of /48 per end user site, or something). So an ISP registering a /48 as AGGREGATED-BY-LIR and assigning /56s out of that would be fully compliant with the existing policy, and the NCC should not meddle with their intent to register that block any way they want. Please tell Legal to re-read the existing IPv6 policies and re-think their opinion on what can be "reasonably assumed to be related to one individual user", based on actual policy text. Maybe speak with one or two large operators on existing deployments. > The /48 prefix size is the maximum size suggested in the "BCOP for Operators: > IPv6 prefix assignment for end-users": > https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-options The /48 size in the BCOP is a recommendation, but *policy* gives the ISPs leeway to assign whatever they find suitable. Typically, this has been /56 in many large eyeball provides, for a long time now - and /48s for "business customers". Gert Doering -- somewhat involved with policy and IPv6 -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Bogon route object cleanup
Hi, On Wed, Oct 06, 2021 at 04:21:41PM +0300, Aleksi Suhonen via db-wg wrote: > People keep repeating that 6to4 and Teredo are deprecated technologies, > but they've obviously not read the deprecation RFCs themselves. The RFCs > clearly state that while new implementations and installations of these > tunneling methods are strongly discouraged, existing installations > should be allowed to function for the near future for backward > compatibility. So on these grounds I oppose removing those route objects > too. Now, how long is "near future"? > Yes, I run one instance of these services at AS29432, and would be > affected by this change. How much traffic to you see? We run a local 6to4 relay - not announced to "the Internet" - and I hardly see any traffic anymore. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] running in whios-circles...?
Hi, On Fri, Sep 17, 2021 at 05:39:14PM -0700, Ronald F. Guilmette via db-wg wrote: > I don't know who pays those IANA people or who thus controls their tasking > and priorities. All I know is that it isn't me. I suspect it is me/us, after all... a fair amount of ICANN financing comes from the joint RIRs, if I'm not mistaken. So yes, if we tell the RIRs, they should be able to achieve an effect. (Inter-RIR politics leading to non-agreement on ICANN requirements aside, but that would be remarkably short-sighted in a simple case as this) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] running in whios-circles...?
Hi, On Thu, Sep 16, 2021 at 07:14:13AM +, Lutz Donnerhacke via db-wg wrote: > Despite your appropriate sarcasm, there are options to urge IANA > to fix this automatically. The first step would be to recognise the > problem at the review level. It would be helpful to start this with > an ASO action on ICANN72. (*SOs are allowed to start PDPs, also > known as policy changes) Not sure which is the best way forward here - "individual members of the community trying to understand ICANN mechanics" or "raising the issue in the RIR community, handing the problem statement to the NRO, and letting the NRO deal with ICANN". As I'm lazy (and not good in dealing with other organization's processes) I'd much prefer "NRO deals with this" :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] running in whios-circles...?
Hi, On Thu, Sep 16, 2021 at 07:00:01AM +, Lutz Donnerhacke via db-wg wrote: > Did you ever tried to correct wrong entries in the IANA whois? > I did and the entries were fixed (within a period of about a year). > It's certainly possible to have correct data in the IANA server. > OTOH if the problem is serious enough, an IANA review can be triggered. I'm not sure it's the community's job to review IANA data continuously and fix their DB every time a network transfer between RIRs is done. I'm fairly sure a smart mind can come up with some solution involving computers here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] running in whios-circles...?
Hi, On Thu, Sep 16, 2021 at 02:59:04AM +0200, denis walker wrote: > The RIPE NCC effectively already provides > this referral service with RIPE GRS. It solves this problem 100% for > all RIR administered address space. Why do we need the NRO to start > discussions with IANA on how to fix a problem that already has a fully > implemented and working solution? The NCC is not the root of the address distribution tree. IANA is. So pointing people from all over the world to the RIPE NCC "because IANA can't get their part right" is conceptually the wrong approach. In practice, it might provide a fast and convenient approach today, but why can't IANA just do that? Mirror the RIR stats files, point people asking *at the root of the tree* to the right branch. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] running in whios-circles...?
Hi, On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote: > The CSC focuses on naming and not numbering issues. That said, rather > than making a complaint, it might be more helpful to decide what the > desired future state is and then ask the RIRs to work on that with the > IANA team. In general, they'll make changes to the way they deliver > services to the numbering community when the NRO makes a request. My take on this is: referrals MUST NOT loop. That is, if IANA points me to the RIPE NCC, and the network got moved *elsewhere*, the RIPE NCC should have a referral to "elsewhere", and not point "back to IANA". Ideally, IANA should point to the final RIR right away. (I see the "use RDAP, not whois" comment as sort of confusing - if the data source is good, the query method should not matter, and if the data source is bad, it definitely won't matter. If RDAP gives a proper referral and whois gives a bad one, the server needs to be fixed - but that's not a *protocol* issue) Gert Doering -- LIR contact and whois user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] IPv6 transition mechanism prefixes (Was: Bogon cleanup -- Current anomalies)
Hi, On Tue, Jul 20, 2021 at 10:07:53PM +, Job Snijders via db-wg wrote: > Perhaps the topic of what to do IPv4/IPv6 transition prefixes in the > RIPE-NONAUTH DB should be brought up in the RIPE IPv6 WG? I think this is a good idea. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Bogon cleanup -- Current anomalies
Hi, On Tue, Jul 20, 2021 at 10:11:46PM +0200, Edward Shryane via db-wg wrote: > (To Ronald and the list) Should we add other sources of bogon prefixes (e.g. > RFC 3068) to the implementation? While Anycast 6to4 needs to die, it isn't fully dead yet. So routes for these two prefixes are legitimate. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Removal of bogon route objects
Hi, On Fri, Jun 11, 2021 at 02:44:37PM +0200, Edward Shryane via db-wg wrote: > 192.88.99.0/24 > 2002::/16 These two are 6to4 anycast relays (v4 and v6 side). While that is deprecated, it's still "special". > 2001::/32 This is Teredo. > 2001:4:112::/48 This one seems to be intentional route6: 2001:4:112::/48 descr: RFC7535 AS112 DNAME prefix descr: See: http://www.as112.net/ and is indeed visible and 2001:4:112::1 accepts DNS queries. > 2011:4188::/48 This seems to be a typo... to my knowledge, nothing was ever allocated out of 2011: Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] "status:" attribute values in the RIPE database
Hi, On Mon, Jun 07, 2021 at 11:09:31AM +0200, Edward Shryane via db-wg wrote: > Should the DB team implement a rule to always force the "status:" attribute > value to uppercase, for consistency? As a DB user, I would find this useful. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Restricting WHOIS searches to type: netname
hi, On Fri, May 28, 2021 at 03:19:18PM -0700, Ronald F. Guilmette via db-wg wrote: > One of the helpful options provided by the RIPE WHOIS server is the > --types option which provides a list of what specific object types > a given set of query results may be restricted to. > > That list is as follows: > > inetnum > inet6num [..] > Can anyone explain to me why "netname" is not on the above list? If I'm not misunderstanding you, what you want to see is these objects: inetnum:82.108.52.0 - 82.108.53.255 netname:ABC so that's the "type" you need to specify: "inetnum". "netname:" is not an object type, but an attribute. $ whois3 -r -T inetnum ABC -> 15 objects (-r restricts returning of referred person: objects) Or do you want to restrict your search to "only match ABC in the netname: attribute"? I'm not sure if it can be done, but that's not what "--type" is for in any case. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Org-types
Hi, On Wed, Jan 20, 2021 at 02:28:59PM +0100, Cynthia Revström via db-wg wrote: > I personally feel like marking the NCC as a member of itself is a bit odd, > but honestly this is so minor so I understand if it was just not considered > much. While minor from a database issue, this was actually a fairly major issue from an address policy point of view - we do have a special policy that permits the NCC to assign addresses to itself, with the policy check being done not by the hostmasters but by the board of arbiters (if I remember correctly). So yes, this is intentional... the NCC is member of the NCC, regarding address space assignments. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] in-addr.arpa glue?
Hi, On Thu, Oct 22, 2020 at 06:46:17PM -0700, Randy Bush via db-wg wrote: > domain: 0.28.147.in-addr.arpa > descr: RG79-147-28-0 > admin-c:RB45695-RIPE > tech-c: RB45695-RIPE > zone-c: RB45695-RIPE > nserver:rip.psg.com > nserver:nlns.globnix.net Maybe this has already been fixed and my reply is "stale" - but taking that risk. From what I can see, the NCC isn't authoritative on the 28.147.in-addr.arpa zone, so trying to add an in-addr arpa object with "nserver:" in it tries to instruct it to do something it can't do - put a delegation in the parent zone. This seems to confuse the tool... Since the parent zone is (now?) running on these servers already, there is no technical need for this domain: object to delegate the 0. subzone. What are you trying to achieve? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWI-11 Internationalised Domain Names
Hi, On Mon, Jul 13, 2020 at 04:49:16PM +, ripedenis--- via db-wg wrote: > This is why I believe we should go for a simple Punycode option now and then > start to consider the bigger picture and finally address difficult questions > that have been brushed under the carpet for many years. I think nobody is disagreeing with you there - as long as we get going :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Puny code or UTF-8 (or both)?
hi, On Mon, Jul 13, 2020 at 12:12:42PM +, ripedenis--- via db-wg wrote: > Do we therefore have support to introduce Puny code now and then consider how > to move forward with UTF-8? Works for me. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWI-11 Internationalised Domain Names
Hi, On Tue, Jul 07, 2020 at 10:53:40PM +0100, Nick Hilliard wrote: > Do you have a better suggestion? Would raw utf8 work here? How much > would it break? If there were broader support in the ripedb codebase > for utf8, 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? That was my suggestion. UTF8 internal, with an output filter to whatever charset the client can handle, possibly defaulting to ISO8859-1 on "whois" sessions. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWI-11 Internationalised Domain Names
Hi, 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... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWI-11 Internationalised Domain Names
Hi, On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote: > I don't get it. Does the RIPE DB prevent the usage of punycode? > > Can someone give me an example, where punycode doesn't work or why > punycode isn't good enough? From what I understand, the intent is to convert incoming e-mail: attributes in "non-punycode format" to punycode before storing in the DB. I do not have a very strong opinion on this proposed implementation. In the long run, I think punycode is a horrible, horrible hack and must die in flames. So if we can have a proper database with proper charset support, my surname would appreciate. And yes, this will most likely involve UTF-8 internally and export filters (I do not want to see UTF-8, ever, if I can have ISO8859-15 instead - yeah, come, sue me) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] mntner with misleading primary key
Hi, On Wed, Jul 01, 2020 at 09:00:44PM +0200, Job Snijders wrote: > On Wed, Jul 1, 2020, at 20:52, Gert Doering wrote: > > On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote: > > > I am not sure how feasible the mandatory "-mnt" would be at this point > > > tbh. [..] > As I understand the conversation, the one option on the table to discuss is > how to deal with primary keys that clash with other scopes of context, > specifically autnums. Of those only 26 exist > > SPACENET-P does not look like an AS number so isn't an issue and doesn't need > to change. This is true, but I was responding to Cynthia's suggestion of having a mandatory "-mnt". Which would affect us - as I said, doable, but it needs to make sense. Of course if it's only about "looks like an ASN" mntners, I'll go back in my lurking corner and watch with interest :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] RIPE DB Route Object fails creation
Hi, On Thu, Jun 11, 2020 at 01:28:16PM +0100, Tom Hill via db-wg wrote: > On 11/06/2020 03:26, ripedenis--- via db-wg wrote: > > ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed > > using "mnt-by:" > > not authenticated by: PLUSNET-NOC > > Could we reduce the confusion, and/or spread some more clue, by being > more specific with this error? e.g. > > Authorisation for [blah] failed using "mnt-by:" > - matching route object already exists > - not authenticated by: PLUSNET-NOC And, while at it, can someone enlighten me why this is actually a desirable characteristic? If the owner of the inetnum and the owner of the aut-num agree about the creation of a new route: object, why is the owner of an existing route: object relevant? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Set Default Maintainer on all Top-level Resources
Hi,
On Mon, Oct 21, 2019 at 11:51:12AM +0200, Edward Shryane via db-wg wrote:
> as presented during the DB-WG session at RIPE 79, we wish to extend the
> "Default Maintainer" functionality for LIR organisations.
I haven't seen that presentation, so forgive me if I haven't understood
things properly.
> Secondly, to automatically (re-)set the Default Maintainer on a nightly
> basis, on *all* top-level resources:
>
> - Fix inconsistencies due to manual updates
> - Add the default maintainer (with an mnt-by: attribute), and remove other
> user maintainer(s)
Why so? If a LIR puts something into the database, which is allowed by
business rules, I see no rationale for resetting it.
Now if we as a group decide that certain changes should not be allowed,
that's a different matter - but do not arbitrarily undo user changes unless
specifically asked for ("I have lost my maintainer password").
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [db-wg] ORG record vetting ?
Hi, On Sun, Jul 28, 2019 at 04:27:04PM -0700, Ronald F. Guilmette via db-wg wrote: > >I think this depends on the context that you want to *use* said org > >object. If you put it in as a standalone and unreferenced database > >object, I think no vetting takes place. > > > >If you want to tie resources to it that are maintained by the NCC > >(allocations [PA] or end user assignments [PI]) this needs to go through > >a NCC ticket, and they want to see paperwork. > > In the context of your response, would one or more ASNs count as "resources" > which would trigger manditory vetting of the associated ORG? > > Or is it only the association of some IP address block that causes NCC to > vet the ORG? I'd assume that an AS would be handled the same as a PI block - you (the LIR who acts as contact between end user and NCC) need to present a contract with the end user, and company registration papers for said end user. The org object would then need to match the paperwork (name, address). At least this has always been my experience when we had to clean up end user resources (company name changes, change of sponsoring LIR, etc.) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] ORG record vetting ?
Hi, On Sat, Jul 27, 2019 at 10:53:28PM -0700, Ronald F. Guilmette via db-wg wrote: > Just a point of curiosity... > > For each newly created ORG record that is put into the data base, if > the ORG record represents something other than a natural person, does > NCC staff make any effort to check to make sure that the alleged > non-person entity actually exists, I mean, you know, as a legal entity, > somewhere on planet earth? > > Or is this just another one of those niceties that cannot, in practice, > be performed within the RIPE region because the membership has not > explicitly approved it? I think this depends on the context that you want to *use* said org object. If you put it in as a standalone and unreferenced database object, I think no vetting takes place. If you want to tie resources to it that are maintained by the NCC (allocations [PA] or end user assignments [PI]) this needs to go through a NCC ticket, and they want to see paperwork. If you want to tie resources to it that are maintained by yourself (I have this customer, they have received a /27 out of my /22 PA, and, because I can, I want to put in an org object for them), they are not vetted, but by putting false data into the DB for your customer assignments you are violating your LIR contract - so that would be a good way to get a LIR into trouble should the NCC be made aware. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Authenticating References to Objects
Hi, On Mon, May 27, 2019 at 12:02:41PM +0200, Piotr Strzyzewski via db-wg wrote: > > However, we could extend this protection to other types of objects: > > > > - Abuse-c role > > - Technical contact, admin contact, zone contact etc. (person/role) > > - Organisation maintainer(s) > > Sounds good. Please, go ahead. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWI-9 In-band notification mechanism? ???
Hi, On Mon, Apr 15, 2019 at 03:33:01PM +0100, Sascha Luck [ml] via db-wg wrote: > As long as that stream is restricted to routing-relevant objects > (route/6, as-set, aut-num come to mind) I can see the need for > this for automated filter-building and have at least no > objections. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWIs update
Hi, On Wed, Apr 10, 2019 at 09:40:05AM +0100, Nick Hilliard wrote: > 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 hash except that's not considered to be secure. The attack vector against unsalted hashes is "rainbow tables"... make the API key something like 80 characters long, and no machine in the world can do anything but brute force. But why store the API key anyway. Have it contain permissions plus a crytographically sane signature, and all you need to know is "in the key". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] NWIs update
Hi, On Wed, Apr 10, 2019 at 08:48:38AM +0100, Nick Hilliard via db-wg wrote: > 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 read/write authentication token, typically > stored in a database in unencrypted format? :-) syncupdates needs some sort of credential. Either you put your LIR access (or mntner md5 password) into the script - which is arguably a bad idea - or you have API tokens that are restricted to *only* API, not "API and all else". You could, certainly, argue that nobody should do RIPE DB updates in an automated way... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Idea: magic mntner for all LIR contacts
Hi, On Mon, Jan 07, 2019 at 10:48:09AM +, Nick Hilliard via db-wg wrote: > One possible option to work around this limitation would be to create a > new db object type, "sso-set", which could contain a list of SSO account > names, e.g.: > > sso-set: FOOBAR1-RIPE > descr:List of SSO tokens for no.foobar > members: f...@example.com > members: b...@example.org > mnt-by: TBD1-RIPE > source: RIPE > > Each LIR would be able to define sso-sets with arbitrary contents and > tie them to objects, e.g. like this: > > auth: SSO-SET FOOBAR1-RIPE > > There would need to be some thought put into how to handle mnt-by: for > the sso-set object (quis custodiet ipsos custodes)? Not sure how that is better than what we have today? Tore's problem statement is "I have added a user to the LIR portal and I do not want to subsequently update a database object to give DB privs to said user" - SSO-SET won't help with that problem statement. Your case would help a LIR that has umpteen different mntner: objects that should all use the same (sub-)set of SSO credentials, and you want to update them in a single place. While I can see that use case, it's solving a different problem. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Idea: magic mntner for all LIR contacts
Hi, On Mon, Jan 07, 2019 at 09:33:58AM +, Nick Hilliard via db-wg wrote: > >> auth: SSO-LIR no.foobar > > This is a sensible idea. I'd like to see it, or something equivalent, > implemented. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] usage of LIR-PARTITIONED status
Hi, On Wed, Dec 19, 2018 at 03:51:20PM +0100, Alexander Stranzky via db-wg wrote: > recently I stumbled upon some less-used status of the INETNUM object, > namely LIR-PARTITIONED PA & LIR-PARTITIONED PI. Since there is no > difference in the docs > (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object), > can anyone tell me when to use PA and when PI? If you partition a PA block, the result is PA. If you partition a PI block, the result is PI. (Though I wonder if "LIR-PARTITIONED PI" is actually a real thing, and strictly speaking the documentation quoted *can not* be correct, because you can't partition "an allocation" into "PI") More verbose explanation on these values is here: https://www.ripe.net/ripe/mail/archives/db-wg/2001-September/001732.html Section "Functionality". (And "oh my god was this long ago") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] [address-policy-wg] [Ext] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks
Hi, On Tue, Nov 06, 2018 at 12:03:10AM +0700, Töma Gavrichenkov wrote: > Just to make it 100% clear for me: do you mean to say that you support my > proposal No. 2? Please keep the discussion on the address-policy-wg list (reply-to: set), and please try to quote only those parts of the original e-mail that are relevant for your answer. We have a list archive and a nice threaded view, so there is no need to contain the whole discussion in every single e-mail sent. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
Hi, On Mon, Nov 05, 2018 at 04:12:10PM +0100, Edward Shryane via db-wg wrote: > Should the RIPE database refuse to apply updates that were signed more than > 'n' minutes ago (or in the future) ? I think this would be a valuable improvement. > > Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used > > any more. But the RIPE NCC Database does still allow this currently. > > This is relevant in the case I ever lose a private GPG-key|X509-cert to > > less than friendly 3rd-parties. And the lost private GPG-key|X509-cert > > is the one used for signing updates to the database. > > Revoked keys indeed cannot be used any more. To revoke a key, you will need > to update the existing key-cert object with the revoked version. You can also > delete the key-cert object. > > Is it enough to update or delete a revoked key? Should the RIPE database > process key revocation certificates? One of the problems here is that the RIPE DB cannot reliably know if a GPG key is revoked, unless it is *told*. "Telling it" can be done nicely by removing the key-cert object - otherwiese it would need to poll key-servers and hope for a key revocation to appear there. A catch-22 arises if the key-cert object needs a signed update with that very key to be deleted... (Not providing solutions, just bringing up aspects to consider) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Fri, Jun 15, 2018 at 02:12:54PM +0100, Sascha Luck [ml] via db-wg wrote: > There is nothing stupid or unreasonable about asking to delay an > action that *will* cause operational issues even if their root > cause lies elsewhere. Since no existing objects will be removed, it will not break anything relying on these objects today. New objects cannot be created anymore, right. Which is the whole point. Job has pointed out alternatives if people feel they must create an unauthorized route: object somewhere. And this really is something that people need to discuss with their upstream providers how *those* do filtering, and what needs to be registered where. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Fri, Jun 15, 2018 at 09:55:14PM +0900, Lu Heng wrote: > > Internet doesn't distingish *traffic*, but that is not the relevant > > question here anyway. Address management, delegation and authority > > are very clearly regionalized, so any beef you have with Afrinic-delegated > > space must be solved over there. > > It???s internet, one internet, and it belong to everyone. just don???t tell > someone else what must to be doing. Please learn to read. "Address management, delegation and authority are very clearly regionalized", which means you cannot just go to some place you find convenient and complain about problems elsewhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Wed, Jun 13, 2018 at 08:11:34PM +0800, Lu Heng wrote: > On Wed, Jun 13, 2018 at 20:10 Gert Doering wrote: > > > On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > > > And until then, I think there is not enough consensus from the community > > to > > > implement this change in the future. > > > > This has been discussed extensively and there has been consensus to go > > ahead with this. > > That???s a bullying answer. It's the way our community works. We discuss a problem, propose a solution, get agreement on problem and solution, get an implementation plan, agree to this, and *then implement it*. We do *not* go through all the process and stop right at the end because someone decides to disagree *months after the time for discussion was ended*. > An consensus define as an acceptable resolution to all parties, and we > being one of the party find the solution unacceptable with sounding > argument, therefore no consensus. Please read RFC7282 - while we're not the IETF, this is comparably to the way the RIPE working groups operate wrt consensus and "someone is always complaining". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > And until then, I think there is not enough consensus from the community to > implement this change in the future. This has been discussed extensively and there has been consensus to go ahead with this. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Proxy proposal large communities
Hi,
On Tue, Nov 14, 2017 at 10:12:11PM +1030, Mark Prior wrote:
> 1. Are you planning on doing that via a script or by eye-balling the policy?
eyeballing does not scale
> 2. How useful is that if their export policy is
> announce { 0.0.0.0/0^0-24 } and community.contains(something)?
>Do you hunt for the import policies where community "something" is set?
We look for "which ASes are they going to announce, and which routes
originate by those".
This fine-grained crap is something we ignore anyway (so, a tool that
parses this and warns about non-understood extentions is ok, a tool
that errors out is not helpful).
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [db-wg] Proxy proposal large communities
Hi, On Mon, Nov 13, 2017 at 10:05:55PM +1030, Mark Prior via db-wg wrote: > As for breaking other people's interpretation of your policy that is > also probably a good thing for the same reason. I would be interested to > know about a use case for people parsing other people's policy objects. "see what they intend to export to me, and verify that it matches what I'm willing to import"? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
--- Begin Message ---
Hi,
On Mon, Oct 09, 2017 at 03:48:43PM +0200, denis walker via db-wg wrote:
> Question - Should the RIPE Database allow creation of ROUTE objects for non
> RIPE resources?
I wonder if this is the right question to ask, or we should step back
and ask the question
what can we do to provide a secure routing registry where people
can document "this prefix will be announced by that AS" in a way
that is a) strongly authenticated (= only the current holder of the
address space can create such a route: object), and b) easy to use
for people building filters (= not having to walk 5 different IRRDBs
to find the set of prefixes announced by a possible customer)?
instead? A, B or C may be a consequence of this.
In any case, given that we have no proper global registry, and we have
lots of cross-region routes ("addresses from RIR A, AS number from RIR B"),
we need to find a way to document these properly.
From a user perspective, I like to have all route: objects for my customers
in a single place (RIPE BD, that is), so for me, "A" would be most convenient
- but we need to add some sort of cross-RIR authentication layer.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
--- End Message ---
Re: [db-wg] out of region routing in the RIPE Database
--- Begin Message --- Hi, On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: > > its a broken process. it inherently permits things to be said, which > > should not have been said. > > Time to set up a joint IRR database where only authoritative data from > participating RIRs is stored? This might indeed be the way forward for "I have a customer in my RIPE AS which has APNIC space and wants to document that in a way that that provisioning tools can pick this with sufficient trust on data quality". (And no, RADB is not) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature --- End Message ---
Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
--- Begin Message --- Hi, On Fri, Apr 21, 2017 at 10:40:19PM +0900, Randy Bush wrote: > are we really spending time discussing how many iterations of irr object > search we will perform to find an email address of an abuse contact to > which we can send email which will be ignored? :)/2 There are those that actually do read their incoming abuse reports, and that care to direct those properly for the resources they have taken stewardship. We *do* read our abuse reports, and we have a few customers that we trust to do their own reading - and since I'm a lazy bastard, I want the system to make this easy for me to maintain (with the abuse contact finder, it's already easy for the reporter, no matter what the final implementation will be) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature --- End Message ---
