 |
 |
This is actually the same registry, MIT has not-too-helpfullly linked to the company's website and not the IP Registry itself, but you can get there with a few clicks. We subscribe to a few of their journals so I suppose we have to add an entry to the registry now. Best, Eric On Wed, Dec 9, 2020 at 1:32 PM Tom Keays <[log in to unmask]> wrote: > Oh boy. MIT Press is migrating to a new platform and they want us to be on > yet another IP registry platform. From the email... > > *Sign up for PSI’s IP registry*, if you are not already registered. > https://www.psiregistry.org/ > < > https://mit.us2.list-manage.com/track/click?u=7caff40e82d72e9429c33df2a&id=2cb79f8b34&e=4349323911 > > > . > > Does anybody have any experience with them? > > Tom > > On Sun, Dec 6, 2020 at 9:30 PM Fitchett, Deborah < > [log in to unmask]> wrote: > > > In my experience, since we signed up, they do email us very occasionally > > to say “Oh we heard such-and-such an IP range is you, can you confirm?” > so > > we can login and say “No, no that hasn’t been our IP range for 10 years, > > who on earth still has that on file?” > > > > --More precisely, we can say “No.” But at least that’s something. > > > > It’s… problematic that they’re maintaining ranges for institutions who > > haven’t signed up. I guess they’re thinking then there’s more incentive > to > > get publishers to come on board, since it is one of those services that > > will work best if most people are on board, and getting momentum when few > > people are on board is a challenge. > > > > I do really like the idea of the service. I come at this from having to > go > > through the “email/login to ALL the publishers to update IP ranges” about > > three times in not very many more years, it was painful and I remain > > traumatised. The idea of just being able to update a single place (or at > > least a single place for most publishers and a few outliers individually) > > is really appealing. > > > > I note a couple of their publishers are now using the IP Registry’s API > to > > stay updated with IP addresses, which seems like another great > development. > > > > Maybe it’s worth sending them feedback that if they provide IP addresses > > for institutions who haven’t signed up, they need to make it clear to > > publishers that these are non-verified and publishers should always > confirm > > with the institution before making changes. > > > > Deborah > > > > > > From: Code for Libraries <[log in to unmask]> On Behalf Of Lolis, > > John > > Sent: Saturday, 5 December 2020 12:25 PM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] The IP Registry > > > > It seems to me that they have a glaring omission in not notifying a > > registrant when someone submitted or modified an IP address range for > their > > institution. Seems like a no-brainer to me. > > > > As for *publishers* providing IP address ranges to update an > institution's > > IP range, *what are they thinking?* > > > > John Lolis > > Coordinator of Computer Systems > > > > 100 Martine Avenue > > White Plains, NY 10601 > > > > tel: 1.914.422.1497 > > fax: 1.914.422.1452 > > > > https://whiteplainslibrary.org/<https://whiteplainslibrary.org> > > > > *When you think about it, *all* security is ultimately security by > > ignorance.* > > > > > > > > On Fri, 4 Dec 2020 at 18:09, Will Martin <[log in to unmask]<mailto: > > [log in to unmask]>> wrote: > > > > > They portray themselves as offering accurate IP ranges, when what > > > they've got amounts to some guess-work. They don't really have any way > > > to catch errors like the Choopa.net example Tom Keays gave, or the > > > consortium sub-range in mine. Unless, of course, the way they catch > > > those is to rely on people from the institutions to eventually log in > > > and correct those for them. > > > > > > I'm going to go ahead and update my institutions ranges with them > > > anyway, because I think I have to. But I'm not going to like them for > > > it. > > > > > > Will > > > > > > On 2020-12-04 16:49, Tom Keays wrote: > > > > A couple of years ago, when I was reviewing the IP set up for > Scitation > > > > for > > > > my institution, I noticed it included an unfamiliar IP range, > > > > 216.155.128.000 - 216.155.128.063. This was not the first time I had > > > > encountered this range (although I don't have a record of what the > > > > previous > > > > vendors were where I found it). After spending some time > investigating, > > > > I > > > > determined that it belonged to an internet hosting company called > > > > Choopa.net. Definitely a bogus listing for us. > > > > > > > > Anyway, when I first set up my account at The IP Registry, they also > > > > listed > > > > this range. When I told them about it and asked them how they got it > > > > and > > > > explained that it should never have been there in their records, they > > > > replied, "This IP range was supplied to us by a number of publishers > > > > who > > > > are using it to provide access." > > > > > > > > I don't really know how this range got listed as being valid for my > > > > institution. Was it there because individual social engineered > > > > somebody's > > > > support team in order to get free access to online resources? I have > to > > > > assume so. I also don't know if The IP Registry got it from the > > > > e-resource > > > > vendors and accepted it without question or the vendors got it from > > > > them, > > > > again without question. Either way, it made me worry about trusting > > > > them > > > > too far. > > > > > > > > Tom > > > > > > > > On Fri, Dec 4, 2020 at 2:33 PM Jeremiah Kellogg <[log in to unmask] > > <mailto:[log in to unmask]>> > > > > wrote: > > > > > > > >> Yikes, this does sound like we're being forced into a service > whether > > > >> we > > > >> want to use it or not. At our institution we're the default owner of > > > >> a > > > >> range of IPs we manage on behalf of a public library consortium that > > > >> we're > > > >> not actually a part of (so the consortium shouldn't be accessing our > > > >> databases). The IP registry had grabbed that range of IPs and > > > >> included > > > >> them in our profile, but had them pending verification from our > > > >> institution > > > >> that we actually owned them before making them available to > > > >> publishers. I > > > >> ended up editing that range to exclude the consortium IPs, and then > no > > > >> longer had to verify the remaining range of IPs that were correct. > > > >> Now > > > >> that I really think about this, had I not made those edits, our > proxy > > > >> server would have been excluded and we would have faced a situation > > > >> where > > > >> our students, faculty and staff were denied access to the services > > > >> they > > > >> should be able to access. So we would have faced the opposite > problem > > > >> that > > > >> you experienced, Will, where people would be denied access rather > than > > > >> given access they shouldn't have. Either way, the only apparent way > > > >> these > > > >> problems can be fixed is by signing up with the IP registry and > > > >> updating > > > >> things ourselves... and that's kind of underhanded. I'm not sure I'd > > > >> worry > > > >> too much about the legalities because it appears vendors, unlike our > > > >> institutions, participate willingly, and if they're willing to take > > > >> the > > > >> ipregistry's word that our IP ranges are accurate that's on them. > > > >> It's > > > >> just really frustrating to think that we'd face these kinds of > > > >> problems due > > > >> to an outside entity getting things wrong on our behalf, and the > only > > > >> way > > > >> to fix them is by signing up with them and making corrections. > > > >> > > > >> I don't think I mind them selling our improved IP data to vendors > > > >> because > > > >> that's the kind of thing most free services need to do to pay the > > > >> bills > > > >> these days. I might be putting the work into it, but it's not so > much > > > >> that > > > >> I feel like I'm putting more in than I'm getting out of it. However, > > > >> as > > > >> you point out, Will, there doesn't appear to be a mechanism for > opting > > > >> out > > > >> of their system, and that really stinks. I haven't dug too deep, but > > > >> I > > > >> wonder if there's a way of setting things up with vendors who use > that > > > >> service to stop using it when we make such a request? I think I'm > > > >> pretty > > > >> much on the same page as you, Will. It's a great idea for a service, > > > >> but > > > >> being forced into it will understandably leave a bad taste in > people's > > > >> mouths, and it also casts a bit of shadow on the service's > integrity. > > > >> I > > > >> get that participation is important for this kind of thing, but I > > > >> suspect > > > >> there are better ways of getting people onboard! > > > >> > > > >> On Thu, Dec 3, 2020 at 6:02 PM Will Martin <[log in to unmask] > > <mailto:[log in to unmask]>> > > > >> wrote: > > > >> > > > >> > I am concerned by the fact that the IP Registry appears to have > gone > > > >> > around figuring out the IP ranges for schools based on public > > records > > > >> > from the IANA and a bunch of vendor records. I'm sure that was > > > >> > difficult, and their site says it took four years. When it was > done, > > > >> > they announced that 58% of IP ranges were wrong, and began selling > > the > > > >> > service to vendors and telling them what our IP addresses are > based > > on > > > >> > their analysis. > > > >> > > > > >> > I claimed the account for my institution and discovered that there > > > were > > > >> > 26 vendors already pulling my university's IP ranges from the IP > > > >> > Registry. Unfortunately, the IP ranges were wrong. To name a few > > > >> > problems: > > > >> > > > > >> > 1) They conflated us with another school in the same university > > > system. > > > >> > > > > >> > 2) They could not know that there are a couple of IP ranges that > we > > > >> > prefer to be treated as "off campus" even though they belong to > the > > > >> > University. > > > >> > > > > >> > 3) They had no way to know that one particular range of our IPs is > > > >> > assigned to a library consortium in our state, and used for proxy > > > >> > servers that serve the other institutions in the university system > > > plus > > > >> > several dozen public libraries. > > > >> > > > > >> > The third point is critical. By distributing these erroneous IP > > > ranges > > > >> > on my school's behalf, without permission, the IP registry has > > > >> > effectively granted access to 26 of our subscriptions to basically > > > >> > everyone in my state. We are thus in violation of our license > > > >> > agreements and will be at risk of legal action by the publishers > > > until I > > > >> > can sort this mess out. > > > >> > > > > >> > Because this involves multiple institutions -- my own, the broader > > > >> > university system, the aforementioned library consortium -- I am > > going > > > >> > to have to contact and explain the situation to a lot of people, > and > > > >> > spend a lot of time checking and re-checking IP ranges, all in > > service > > > >> > of updating the IP Registry's records. > > > >> > > > > >> > Then they get to turn around and charge the publishers for my > work. > > > >> > > > > >> > But frankly, their business model feels like extortion to me. We > > have > > > to > > > >> > verify their records, or there's a chance that our resources will > be > > > >> > accessible to people who should not have access because their > > analysis > > > >> > was incorrect. They appear to have engineered a situation that > puts > > > my > > > >> > institution in potential legal jeopardy, which we can only get out > > of > > > by > > > >> > improving the data that the IP Registry is selling for a profit. > > > >> > > > > >> > I am not happy with them. The basic idea -- a centralized > repository > > > of > > > >> > IP ranges for bulk updating publisher records -- is both sound and > > > >> > useful. But their business model leaves a bad taste in my mouth. > If > > > I > > > >> > could, I would opt out of the system. But they do not appear to > have > > > >> > made a mechanism available to do so. > > > >> > > > > >> > Will Martin > > > >> > > > > >> > Head of Digital Initiatives, Systems and Services > > > >> > Chester Fritz Library > > > >> > University of North Dakota > > > >> > > > > >> > > > >> > > > >> -- > > > >> Jeremiah Kellogg > > > >> Systems Librarian > > > >> Pierce Library > > > >> Eastern Oregon University > > > >> [log in to unmask]<mailto:[log in to unmask]> > > > >> (541) 962-3017 > > > >> > > > > > > > ________________________________ > > > > "The contents of this e-mail (including any attachments) may be > > confidential and/or subject to copyright. Any unauthorised use, > > distribution, or copying of the contents is expressly prohibited. If you > > have received this e-mail in error, please advise the sender by return > > e-mail or telephone and then delete this e-mail together with all > > attachments from your system." > > >