Since it’s come up on the list and we haven’t given a public update recently, I thought I’d just write a quick note on the state of INOC-DBA. For those who aren’t familiar with it, INOC-DBA is a SIP-based hotline communications system between NOCs and CERTs: https://www.pch.net/services/INOC_DBA https://en.wikipedia.org/wiki/INOC-DBA PCH has been the secretariat for INOC-DBA for the past thirteen years as a function of our not-for-profit purpose, serving network operators. During that time, the INOC-DBA back-end and self-provisioning systems have been completely replaced three times, and we’re currently at work on moving from the SER-driven 3.0 series of releases to a more modern BE7k-driven 4.0 system. Because INOC-DBA has only been intermittently directly grant-funded, sometimes, like now, it is funded entirely out of our overhead budget, so progress can be slow. The consequence is that, in order to make headway on the 4.0 transition, we’ve had to move people off of active support of the old 3.0 self-provisioning system. So, it’s fine for people who are already using it, but there’s not currently a way to create a new user within the 3.0 system, nor for existing users to make significant changes to call routing. ASNs have proven to be a good identifier, allowing network operators to communicate with each other in a way that’s vetted, while avoiding putting PCH in the position of judging who qualifies to join and who doesn't. Whether you know the name of a network, or where it’s located, or even what timezone they’re in, you know them by their ASN. And a hotline system that bypasses directories and receptionists and escalation chains is a quick and low-friction way of reaching someone who has the authority and access to resolve a problem. While email is the most venerable and well-known communication method it is often filtered, missed, or funneled through helpdesks that don’t have sufficient clue, or are stymied by dealing with someone who isn’t one of their own customers. Facebook and general-purpose chat systems are less than ideal as well, as they’re un-vetted and quickly suffer the same fate as email: if they’re paid attention to at all, filters or automated systems are put in place to block the noise. So, a closed network for voice, video, presence and chat has proven to be an immediate, low-noise way for those network operators who choose to use it, to communicate with each other. In the 4.0 system, XMPP chat using the same identifiers in the same closed network is a natural extension and the new feature that, though hardly revolutionary, we’re most looking forward to releasing. The technical issues that were discussed in this thread about NAT/PAT problems are certainly valid, but can be circumvented in a number of different ways, some of which are addressed in our documentation. SIP and RTP can work through NAT if correctly configured in simple circumstances, or in the presence of a NAT-traversal server, such as is included in INOC-DBA. An organization may have multiple INOC-DBA users and opt to have a SIP-capable system at the border of their network with one side facing the public Internet, and one side facing their private network, and which manages call flow and media handling (Asterisk, Freeswitch, or any one of a number of free or commercial SIP PBX-like systems will do this fairly easily; again, there are tutorials in our documentation). This also allows after-hours routing to PSTN lines or to call groups as needed, controlled by a local administrator. We also have considered keeping the media path through our servers, which aids the NAT traversal issue while not precluding local SIP enclaves as described above. One of the things that we struggle with is maintaining an appropriate balance between, on the one hand, keeping the network operations community informed of the status of the system, so they don’t feel compelled to ask on NANOG, versus not pro-actively over-sharing on lists and making a nuisance of ourselves. Admittedly, if the 4.0 transition were going faster, this would be less of an issue. So, we’re glad of the continued interest (particularly in the NANOG community, where INOC-DBA is not as widely used as in, for instance, the LACNIC community), and we apologize for the slow transition to the new 4.0 back-end and self-provisioning system. As always, you can contact us directly about INOC-DBA related stuff on operator@pch.net JT --- John Todd - jtodd@pch.net - +1-415-831-3123 On 29 Sep 2015, at 8:05, Bob Evans wrote:
Nice of you to check Jim. This brings up the old idea - A long time ago I had an INOC phone by PCH.NET - It never rang, as we filter our outbound with detail everywhere we announce. ISPs need to provide us their address list.
And the few times I needed to use it , no one ever answered. ( It was a decade ago before NANOG membership.) So after a while I too ignored it. Maybe this was an idea ahead of it's time ? From this painful mishap, it could have been a great solution for NOC Engineers to help each. I find peeringdb often outdated as companies change around and sluggish return call if at all. Most are like a sales line number post.
I see now a long list of registered networks in the PCH directory. Are networks actually paying attention and using it. Is it time to take another look ? At midnight in your organization could you get a NOC person with " proper BGP skills and access " to answer and care about a bad announcement ?
https://inoc-dba-web.pch.net/inoc-dba/console.cgi?op=show_pubdir&list=org Link above shows lots more networks listed on the INOC-DBA Public Directory: Organizations
But have you used it? Did it work for you when you needed it ? Any further comments are appreciated.
This seems like a very good proper civil approach - maybe this or something like it ARIN might help promote and endorse as a benefit to the community ? Be nice if with the cash they did something simple like this and got all of us to use it? Special line forwarding ? A Emergency Only NOC App for our phones for just this kind of situation - one that registers a specific ASN and pin code we set on the registration page ?
Thank You Bob Evans CTO
[snip]