Misuse of the word "Unique" in property tables

[Vasileios-Mavroeidis]

According to the language specification, overview section: " Actuator Profiles may define Command Arguments and Targets that are relevant and/or unique to those Actuator functions. "

According to SLPF: "The purpose of SLPF is to: Identify Actuator-Specifiers and Arguments for each Action/Target pair that are applicable and/or unique to the SLPF class of Actuators"

SLPF makes bad use of the word "unique".

The word "applicable" has the following meaning: We get properties from the LS for the SLPF/actuator profile. So properties from the LS are applicable to SLPF.

The word unique means that a property exists or can only exist in a particular profile. The introduction of the same property to another profile makes it non-unique. All the "unique" properties in SLPF will be used in SFPF and maybe other profiles.

In our case, Unique means that the properties do not exist in the LS and were defined only for SLPF. This is going to change soon.

The word "unique" should be replaced by another word in the following tables. Maybe the word "defined" is more appropriate?

Table 2.1.2-2. Targets Unique to SLPF Table 2.1.3-2. Command Arguments Unique to SLPF

[Table 2.1.2-2. Targets Defined for SLPF] [Table 2.1.3-2. Command Arguments Defined for SLPF]

[alevere]

Agreed, created a pull request for you to review.

[sparrell]

I'm fine with using another word than "unique" (ie "defined") BUT I would like to remind everyone that I advocate ALL the terms used in profiles be specified in language specification eventually. Some people are of the opinion that only 'common' terms need to be in language specification. My suspicion is most terms will be common to at least one other profile - and even if they are not, I would still want them in the language spec. I would not want to hold up an AP until the term is in the language spec - but I see zero reason not to put the term in the language spec. Some people worry about 'changing the language spec too often' if we take my approach. I have no issue with changing the language spec monthly, and I see zero chance of us getting to that point on our current path - ie the rate of change has not been and issue and I don't see it becoming one. If it does, we'll deal with it at that point - but I reiterate I will take bets this will never be an issue.

[sparrell]

Logistics question - are these changes being proposed as 'errata' (ie reissue of 1.0) or as new point release (ie 1.1) or as 'changes to make should be ever have to make other changes'? And how are these changes being configuration managed relative to 1.0 (ie is it easy to find the 'official' 1.0 and see that this copy is next 'working copy'? I think I see only 1.0 in releases and this would be 1.1 working doc 9 or something like that depending on answer to errata/1.1/future.

[jmbrule]

In the context of boiling up all arguments, all target extensions etc to the language specification, this issue has been proposed, deliberated at great length and voted on for several iterations. We can take bets if you want to, but as of now we do not have new points being made, a wave of new members who will overwhelm the original votes nor do we have a widely promulgated spec that has provided tons of new experience that we can draw on. An argument such as 'drop_process' means nothing to a virus scanner. Based on the fact that it took us over two years to get the language spec out, I suspect that it will be a challenge to get new revisions out at a Moores law pace.
Suggest closing the totalizing instinct issue for now.

[jmbrule]

Can we stick a fork in this one?

[davaya]

I propose that when we create a version 1.1 of SLPF we include this in the set of pull requests against it. DaveL has the versioning and release guide; we want to get started on 1.1 in accordance with the guide.

I think changing a word in prose text is an errata, but I don't think it's worth creating a CS02 errata to SLPF v1.0 at this point. Just do it in 1.1.

As a completely separate issue, there is a "unique" keyword for ArrayOf types that is already used in LS CS02. It appears in the prose sense in sections 1.6 and 2.1 and should probably be fixed the same way as in SLPF. But it appears in a formal sense in section 3.1.1 "IDs and Names are unique within each type definition.", which is correct, and in the tables of 3.3.2.2, 3.4.1.5, etc, which are also correct.

We can stick a fork in it when we create SLPF v1.1 WD01.

[sparrell]

I am not sure what you mean by “stick a fork in it” and English is my first language so I’m sure ESL is even more confused.

If you mean “close the issue”, then I disagree. I do not think an issue should be closed until the text to resolve it is in a CS. Ie WD or CSD is not enough. Two reasons for this. First because it’s actually not resolved until spec passed. Second because the doc for voting on CS can say it resolves issues X with PR-y, issue Z with PR ....

I do agree we can close issues that we agree to make no changes. But this is not one of them.

We can make tags to note that text is in and just waiting next version approval. But we haven’t made the 1.1 WD with the text in it yet.

iPhone, iTypo, iApologize

---

From: David Kemp notifications@github.com Sent: Thursday, February 27, 2020 6:20:19 PM To: oasis-tcs/openc2-apsc-stateless-packet-filter openc2-apsc-stateless-packet-filter@noreply.github.com Cc: duncan sfractal.com duncan@sfractal.com; Comment comment@noreply.github.com Subject: Re: [oasis-tcs/openc2-apsc-stateless-packet-filter] Misuse of the word "Unique" in property tables (#111)

I propose that when we create a version 1.1 of SLPF we include this in the set of pull requests against it. DaveL has the versioning and release guide; we want to get started on 1.1 in accordance with the guide.

I think changing a word in prose text is an errata, but I don't think it's worth creating a CS02 errata to SLPF v1.0 at this point. Just do it in 1.1.

As a completely separate issue, there is a "unique" keyword for ArrayOf types that is already used in LS CS02. It appears in the prose sense in sections 1.6 and 2.1 and should probably be fixed the same way as in SLPF. But it appears in a formal sense in section 3.1.1 "IDs and Names are unique within each type definition.", which is correct, and in the tables of 3.3.2.2, 3.4.1.5, etc, which are also correct.

We can stick a fork in it when we create SLPF v1.1 WD01.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter/issues/111?email_source=notifications&email_token=AANEXD22B2VT3H5HVKSWRGDRFBDDHA5CNFSM4KCWFXEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENGK2GA#issuecomment-592227608, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AANEXD2Y4KYKR3ZPFWMP7STRFBDDHANCNFSM4KCWFXEA.

[jmbrule]

Stick a fork in it is an expression that means 'it is done'. In the context of this issue, I believe we are done. The issue was identified, deliberated and an pull request was made for review. I consider this done and we should close the issue. The change will be clearly highlighted in the next revision therefore no danger of the change being made while anyone is unaware.
If the general consensus is that we cannot close this issue until the next CSD, then can we at least put a TAG on it that says something like 'Resolved, awaiting next revision'

[davaya]

I vote #2 - leave the issue open with a Resolved tag until the CS is published, for the reasons Duncan listed.