15-022-DS, Remove Redundant Control Measures

[abouffard]

Remove the following control measures as they are all redundant (all of the following control measures duplicate information already captured in standard identity and/or status and can still be represented with the control measures that remain). The SIDCs shown in parentheses are the parent SIDCs that can still be used to represent the removed symbols.

25-140101 (25-140100) 25-140102 25-140103 25-140104

25-140401 (25-140400)

25-150101 (25-150100) 25-150102 25-150103 25-150104

25-150400 (25-150300)

25-151201 (25-151200)

25-151405 (25-151404) 25-151407 25-151408

25-140604 (25-140603) 25-140606 25-140607

25-151801 (25-151800) 25-151802

25-240807 (25-240806)

25-270702 (25-270701) 25-270703 25-270704

In all of the above cases, the same information portrayed by each of these redundant control measures can already be captured with one of its parent control measures. These corrections comply with the proper use of the SIDC’s standard identity and status coding positions.

Within the standard, the examples/templates should be edited to reflect these facts. Examples of the planned or on order and/or hostile version of these control measures may still be useful, but they should just remain as examples, not be assigned unique entity subtype IDs.

[ottenw]

@abouffard FYI - I drafted a new CP to submit to Army rep to remove redundant 110101, 110102, and 110103.

[abouffard]

Thanks for the warning @ottenw . I plan to have all these approved 15-1 CPs implemented in JMSML prior to 15-2. After 15-2 I'll add everything approved from that meeting to our open issue list and we'll continue in that pattern until and if DISA takes it over. We'll then encourage them to do the same moving forward, when they own it.

[csmoore]

I'm not 100% sure we should implement this now (particularly in the .stylx we generate from this) until it is in a published standard we can reference. Removing symbols seems more than a typo/administrative-type change. I'm mainly concerned about getting bug reports from customers saying they can't create these (and I'm not sure where I would refer them to for an explanation-unless such an explanation for the process of immediate incorporation of CPs gets added to this repo)

Would it be possible to move this to the "after next" milestone (with the most of the other CPs)?

[abouffard]

I feel pretty strongly that we should implement this as soon as possible, for exactly the reason you cite, we want to do everything in our power to prevent users from creating these erroneous and potentially very misleading symbols.

I am happy to go find the DoD DISR words and references needed to add to our repo documentation, words that explain in no uncertain terms the importance and currency of change proposals, as they relate to what is published in a MIL-STD, like 2525D.

I think we just need to educate our users (many of whom I believe are savvy enough to appreciate this already) that change proposals approved for use with 2525D are effective immediately and users (and implementers) needn't, and in this particular case I believe shouldn't, wait until they are published to be implemented.

Depending on your definition of "published", these change proposals won't be published in pdf/book form until 2525D Change 1 is published, which, given DISA's difficulties staffing 2525, has been postponed another good six months. I'd say no sooner that 2017 will we see 2525D Change 1 completed.

@ottenw and @wmcgrane can you both please chime in here with your understanding of the DISR and the relevant merits of implementing this particular CP sooner rather than later? @ottenw , I'm particularly concerned with this particular CP because the status/standard identity-redundant control measures affected by this particular CP can really cause a system and a user confusion if they are allowed to exist. @mepler should never have assigned separate entity codes to them in the first place, making them symbols in their own right.

[csmoore]

Sounds reasonable to me - if the explanation of this process can be clearly published/explained somewhere (e.g. as a section of the readme in this repo or as a link to a public memo we can reference) that we can link to if/when we get bug reports against the as-published standard.

I also didn't realize that >2017 was the next published doc, so maybe good to iron out this use-case of how an implementer (even a non-savvy one like myself) can readily understand the "current" standard.

[abouffard]

Oh, come on @csmoore ! You slight yourself, methinks :-) When it comes to military symbology and 2525, how long have you been working with it? I wouldn't consider you "non-savvy".

Apart from Dr. MOLE, I can't imagine anyone at Esri any more knowledgeable about how this all works than CMoore.

[joebayles]

@abouffard So is this approved for 2525D or 2525D Change 1?