IVT is Ivytown aka. Ivy Bridge EX (past Xeon codenames: Clovertown, Gulftown, Harpertown, Jaketown, Gainestown -- although not all *town codenames covered Xeons, a lot did). All of these are easy to figure abbreviations of Intel code names, perhaps the newest ones a bit harder because we are not as used to them yet (CFL for Coffee Lake, GLK for Gemini Lake -- both of which are probably class action lawsuit targets as they shipped after Intel was told).

The characters after the shorthand are probably chip revision.

{HSW,BDW,SKL,KBL,CFL} are probably Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake.

{HSX,BDX,SKX} appear to be the codenames for some variants of Haswell/Broadwell/Skylake - I find mixes of references to those being the Xeons, associated chipsets, and otherwise.

GLK appears to be Gemini Lake, a codename for some of Intel's really low power SoCs.

From the command 'cpuid'

I believe the [XX]-[XX]-[XX] is:

<extended family><family>-<extended model><model>->stepping id>

Those values are all in the first few lines of output from 'cpuid'.

The [XX]->[XX] is probably [old microcode version]->[new microcode version]

If the cpuid for a processor is not listed in those release notes, I don't think there's a reason to believe the processor has received a microcode update. It might be worth comparing the microcode blob to Intel's last release in 2017-11 to confirm.

It looks to me like the microcode version can be read out from

hexdump <XX-XX-XX from .tgz> | head -n1 | cut -f4,5 -d' '

where the first field is the lower 16 bits and the second field is the upper 16 bits. I don't have any documentation to prove this assumption, it is just based on comparing the listed microcode versions to those fields in the binary blobs. But doing a straight 'diff' would probably be good enough to tell if the microcode file has changed.

Some Linux vendors like CentOS, Debian and Ubuntu may have microcode updates for processors that weren't part of this release, I'm not sure.

I hate to say it, but I'm also finding myself scratching my head at this one. I've randomly chosen 3 separate Xeon E5 family processors that are in production, and _each time_ I look at the intel-ucode files, _absolutely none_ of the family-model-stepping outputs from lscpu/dmidecode match.

I'd guess that the format above (using HSW-ULT Cx/Dx as an example), that 01:72 means stepping 1 through 72?

These are the updates, sorted by microcode update date, with a cursory look at the generation:

sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263907 Skylake Core

sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=329443 Skylake Core & Xeon

sig 0x000306f4, pf_mask 0x80, 2017-11-17, rev 0x0010, size 17408 Haswell-EX

sig 0x00040671, pf_mask 0x22, 2017-11-17, rev 0x001b, size 13312 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263793 Broadwell Core

sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198356 Broadwell Core

sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198386 Haswell Core & Xeon

sig 0x00040661, pf_mask 0x32, 2017-11-20, rev 0x0018, size 25600 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263777 Crystal Well Core

sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263761 Haswell Core

sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198339 Haswell Core & Xeon

sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198372 Ivy Bridge Core & Xeon

sig 0x00050654, pf_mask 0xb7, 2017-12-08, rev 0x200003c, size 27648 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=329300 Skylake Core

sig 0x00050662, pf_mask 0x10, 2017-12-16, rev 0x0014, size 31744 Broadwell

sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x7000011, size 22528 Broadwell

sig 0x000706a1, pf_mask 0x01, 2017-12-26, rev 0x0022, size 73728 Gemini Lake

sig 0x000906ea, pf_mask 0x22, 2018-01-04, rev 0x0080, size 97280 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591594 Coffee Lake Core

sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=526057 Kaby Lake Core

sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=526058 Kaby Lake Core

sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591593 Kaby Lake Core & Xeon

sig 0x000906eb, pf_mask 0x02, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591595 Coffee Lake

I believe the oldest processors in the list are the Ivy Bridge sig=0x306e4. That includes E5-xxxx v2 Xeons, circa 2013.