Hi, Orv! Thank You so much or raising this issue!! It's been a burning problem for years! Frankly, your nice description in itself already presents an excellent justification for this vital capability. So I'm sure you will understand my modest suggestions... And may I respectfully note that a likely reason that you perceive that it is "rarely used" is because it does not seem to be well publicized, and frankly I do not recall any users in our region who even knew it exists. BUT we really do need it! As you know, the NodeName is normally required to contain the OperatorCallSign, plus it is highly recommended to include other useful data characters. And that collective NodeName is the _only_ visible ID available on the MeshStatus pages. We urgently need the ability to ADD a TacticalCallSign as an _additional_ data element, for very many reasons. And if at all feasible, to not only enable discovery via DNS, as you note, but also easy and clear visibility via the MeshStatus display! Then we can just scan for the TacticalCallSign we need, vs trying to decrypt the gaggle of other characters. Yeah, who cares if the same Node has two duplicate entries, because the significant value added far outweighs the enhanced operational mission and situational awareness capabilities. Example: During the highly visible and successful Marine Corps Marathon (MCM), I recall we deploy well over 30 AREDN nodes in very difficult urban terrain in the Washington DC area. Every year, we have to hack our NodeNames, just for the event! We have been compelled to cobble the NodeName to somehow retain the OperatorCallSign, plus all the other needed NodeCharacteristics data (node type, channel, device ID, location, whatever). Such as NodeName = "OperatorCallSign+NodeCharacteristics" Plus we try to stuff in some kind of characters that would indicate the Node's function and/or location in the system. Yes, a TacticalCallSign would have been perfect for this essential functionality! Note- your description is a bit ambiguous... Are you saying that the present system presents a Node"s ID in the MeshStatus display as a) "OperatorCallSign+NodeCharacteristics/TacticalCallSign" as a single long entry, OR as b) "OperatorCallSign+NodeCharacteristics" (as one MeshStatus entry) and c) "TacticalCallSign" (as an additional separate entry)??? My strong preference would be for the latter separate b) and c) case, for simplicity and clarity. And may I also respectfully request that the AREDN SW simply implement a DUAL Node identifier by ADDing an _additional_ field, so the TacticalCallSign, or _any_ desired suitable ID or designation, could be independently added. And _not_ require use of a "/" symbol separator (especially if case a) above. Operators who do _not_ need the Dual-ID field can simply ignore it. Operators who _do_ need it can enter, or delete, easily and simply, and _without_ hacking their well crafted Primary NodeName ( "OperatorCallSign+NodeCharacteristics" ). With such a pragmatic upgrade, deployed Operators could quickly ADD any needed TacticalCallSigns into their existing Nodes, reboot, and join the AREDN MESH. (After perhaps the traditional modest wait for the DNS caches to clear and enable the new NodeNames to register and proliferate). As an additional benefit, simple TacticalCallSign would enable a) Nodes with duplicate TacticalCallSigns could be swapped, in case of failure or exchange, while retaining the correct network TacticalCallSign, b) Multiple Nodes with similar TacticalCallSigns could be deployed to the same _location_ (like ICP1 & ICP2 or NetControl1 & NetControl2, etc), with enhanced FailOver (manual or automatic) clarity, c) Multiple Nodes with similar TacticalCallSigns could be assigned to similar _functions_ (like GateWay1 & GateWay2 or WinLinkNode1 & WinLinkNode2, etc). Therefore, we respectfully urge the retention and _upgrade_ of this vital capability. Thanks again for asking! Gene :) N3EV N3EV@arrl.net HamShackHotLine 5003

First of all, I am a STRONG supporter of the use of tactical calls.  For an event, it generally completely unimportant that the amateur callsign of the station at "Stage 1" is WA6ABC or K6XYZ - you care that it is the operator at "Stage 1".  Yes, we are supposed to meet the FCC ID requirements, but except for that, the tactical call is the only one that matters.  I have worked enough events where you practically had to hit hams over the head with a 2x4 to get them to understand that.
One thing to keep in mind with a tactical call in an AREDN environment is the need to remove the tactical call after the event is completed.  Why you ask?  Using Orv's example of Shelter 1, Shelter 2, and Shelter north works just fine, but if the station that is sending a tactical call of Shelter 1 does not remove that tactical call, and some other incident pops up a few weeks later that also has a Shelter 1, you now have two stations transmitting a tactical call of Shelter 1.  DNS can't figure out what the IP of Shelter 1 is, and traffic is lost or mis-routed.
BTW, as a test, I set a tactical call of "tactical-call" for one of my nodes.  When I run a mesh status of an adjacent node, this is what I get.

Current Neighbors    LQ NLQ TxMbps    Services

K6CCC-RocM3-1		100%	100%	55.5
Tactical-call / K6CCC-RocM3-3.local.mesh		88%	91%	32.5

Interesting that the tactical call is shown first.  Also the link is tactical-call.local.mesh:8080 - not the callsign of the node.  However the display on the node shows the tactical call second:

K6CCC-RocM3-3 / Tactical-call

Location: 34.10960622 -117.85309797
Just testing for now. Out in my garage. Pointed to K6CCC-RocM3-2 in the family room.
 

Aren't these "tactical" hostnames basically the same thing as this?
https://github.com/aredn/aredn_ar71xx/issues/516

DNS aliases seem easier. no need to fiddle with the nodes actual name...