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."
>
|
