1. OMG Mailing List
  2. OMG Process Change Management

Open Issues

  • Issues not resolved
  • Name: abpsc
  • Issues Count: 17

Issues Descriptions

P&P needs to be more explicit about which documents are subject to the 4 wk rule

  • Key: ABPSC-28
  • Status: open  
  • Source: Jackrabbit Consulting ( Charlotte Wales)
  • Summary:

    I've just today come to the embarrassed realization that I've been assuming for years (my bad!) that RFIs (issuance of) are not subject to the 4 wk rule. That folks can decide during a meeting week to prepare an RFI and get it issued that same week. And I've been spinning what I realize now is a fairy tale for years. After reviewing the P&P today (and the HH Guide), my opinion is that the P&P's handling of the 4 week rule is quite clear on the subject of submissions but with regards to documents like RFPs, RFCs, and RFIs is quite obtuse. It does not state explicitly which documents issued by a subgroup are subject to the 4 week rule – all it says is "Where a poll at a meeting requires documentation (i.e., on adoption of particular documents or based on the content of a document), one third of the Voting Members represented at the meeting may invoke the requirement that documentation supporting the poll must be available at least four weeks prior to the poll." This may be OK in the sections concerning the AB polls (Sxn 3.5.4) and DTC/PTC polls (Sxn 3.5.2) but IMHO is not OK for subgroups. One is forced to infer that "based on the content of a document" refers to things like RFPs, RFCs, and RFIs. A subgroup chair should not be forced to have to infer the intent of some obscure line in the P&P .. it should be clear. It also doesn't state clearly that the 4 wk rule applies – all it says is that somebody can choose to invoke it, if they wish.

    My suggestion is that the wording of the paragraph cited above should be changed to indicate exactly which documents are subject to the 4 week rule. Am referring here to the ones covered by "based on the content of a document" ("adoption of particular documents" clearly refers to submissions). One could also add the qualification that the 4 wk rule applies to any document voted on by a subgroup that will subsequently be voted on by the AB and TC or the TC alone. Furthermore, the wording should be more direct... clearly state the cases where a 4 wk rule applies instead of stating it indirectly (almost backwards or by exception) – "Members represented at the meeting may invoke the requirement that documentation supporting the poll must be available at least four weeks prior to the poll." This makes it sound like one can ignore the 4 wk rule unless somebody objects. In which case what kind of a rule is it?

    I know we've operated under this subtle wording for years .. but let's abandon subtlety for clear and direct. Please!

  • Reported: ABPSC 3.3 — Mon, 24 Feb 2020 20:19 GMT
  • Updated: Mon, 24 Feb 2020 20:19 GMT

There is no way to recall (deprecate, or whatever a Process (RFP...)

  • Key: ABPSC-9
  • Status: open  
  • Source: Object Management Group ( Larry Johnson)
  • Summary:

    As it stands now an RFP remains in existence after all its deadlines are passed... its a Zompie RFP which theoretically can be reactivated by resetting its schedule... but for the most part they linger in the database as an active process; which its not.

  • Reported: ABPSC 3.3 — Fri, 10 May 2019 15:56 GMT
  • Updated: Thu, 20 Feb 2020 01:55 GMT

AB Email vote closure trigger is not well-formed.

  • Key: ABPSC-10
  • Status: open  
  • Source: Object Management Group ( Jason Smith)
  • Summary:

    Section 3.5.4 states that "There are no proxies for electronic polls, but neither is there is a time limit - instead, the ABC must continue gathering votes until no further voting could affect outcome."

    Since AB members may change their votes at any time prior to closure, this sets up a never-closing vote.

    By traditional fiat, a two week window has been used by the AB Chair. Codify this, or clarify the above language.

  • Reported: ABPSC 3.3 — Wed, 9 Oct 2019 18:24 GMT
  • Updated: Thu, 20 Feb 2020 01:37 GMT

Revisit copyright license in RFI template

  • Key: ABPSC-25
  • Status: open  
  • Source: Object Management Group ( Jason Smith)
  • Summary:

    The current copyright license that respondents to an RFI place in their response is included in the RFI template v1.6 (omg/19-07-01).

    The current text is:

    We hereby grant OMG the right to make an unlimited number of copies of the Copyrighted Material as part of the OMG adoption process.
    We hereby grant each OMG member the limited right to make up to twenty-five (25) copies of the Copyrighted Material for review purposes only as part of the OMG adoption process.

    It has been pointed out that this makes no claim of revocability or irrevocability of the material provided in an RFI response, and that the concept of 'copies' of the material is less meaningful in the age of primarily digital documents.

    This license should be redone to reflect current distribution mechanisms, and clarify the revocability (or not) of information supplied in the response to an RFI.

  • Reported: ABPSC 3.3 — Thu, 20 Feb 2020 00:56 GMT
  • Updated: Thu, 20 Feb 2020 00:56 GMT

Boilerplate includes ISO 8859-1 as a document format

  • Key: ABPSC-18
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The Cyber Security RFI (and I suspect most others) includes the following in section 3.2 How to Respond:

    Acceptable formats are ODF (ISO/IEC 26300), PDF (ISO 32000), ISO Latin-1 (ISO/IEC 8859-1) or MS Word .doc or .docx files.

    ISO Latin-1 is not a format but a character encoding so does not seem to fit in this list alongside the other options. Is any word processing or file format OK so long as it uses that character encoding? Why not also include UTF-8? I think we should just delete this as an option.

  • Reported: ABPSC 3.3 — Wed, 18 Dec 2019 22:56 GMT
  • Updated: Wed, 19 Feb 2020 23:38 GMT

BCQ requested too frequently, and unclear in the P&P

  • Key: ABPSC-22
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    We seem to ask for a post-finalization BCQ in addition to the post-adoption one.
    Requiring an additional one makes little sense to me and seems somewhat of a process absurdity – is that something the Board really requires?
    Surely all that's needed is commitment that the Finalized spec is implemented.

    I also think it’s absurd to require a new BCQ for each minor revision. If someone is committed to implement the Finalized spec, it's reasonable to assume they're going to implement the spec with bugs and ambiguities fixed!

    Finally the BCQ does not ask for any more detail than "an implementation". Since most specs have several conformance points it seems useful to ask a further question about which will be provided. More useful IMO than asking about platform.

    Looking at the P&P it does not seem clear, and only seems to require one BCQ at time of adoption (which also applies to Finalization).

    For RFCs only step 6 says:
    [When the TC adoption vote begins the submitter(s) can expect to receive the
    standard Questionnaire from the Board’s Business Committee asking about
    IPR ownership of the Specification and commercial availability of
    implementations, and requesting a grant of copyright for publication.]

    The only other mention seems related to Veto power in
    [this judgement is usually made by the Board's Business
    Committee, based upon responses to a questionnaire sent to submitters
    whilst the TC adoption recommendation vote is in progress.]

  • Reported: ABPSC 3.3 — Tue, 11 Feb 2020 14:44 GMT
  • Updated: Tue, 11 Feb 2020 14:44 GMT

Board approval should not be treated as a change in Issue status

  • Key: ABPSC-21
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Everyone on the xTF list gets an annoyingly huge flood of unnecessary emails, one per issue resolved by that revision, when the Board finally approves the spec.

  • Reported: ABPSC 3.3 — Thu, 6 Feb 2020 16:07 GMT
  • Updated: Thu, 6 Feb 2020 16:07 GMT

RFPs shall be presented and discussed at least one meeting prior to the issuing meeting

  • Key: ABPSC-19
  • Status: open  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    It is a (very) long standing practice to have new RFPs presented and discussed in the issuing Taskforce at least one meeting before the meeting in which the RFP is reviewed by the Architecture Board and eventually issued by the Technical Committee parent to the originating Taskforce. This common practice proved very valuable, but is nowhere mandated in the current version of the P&P.

    I suggest to insert at the appropriate place in section 4.2 of the P&P the sentence:

    "RFPs must be presented to, and discussed in, the originating Taskforce at least one meeting prior to the meeting, in which the RFP is intended to be issued by the Technical Committee parent to the originating Taskforce."

  • Reported: ABPSC 3.3 — Wed, 22 Jan 2020 03:25 GMT
  • Updated: Fri, 24 Jan 2020 19:35 GMT

OMG should have a Code of Conduct

  • Key: ABPSC-6
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Which covers expected behavior and courtesy at physical meetings, phone meetings and online. Along with process and sanctions for not following it.

    Many other conferences and communities have been caught out by lack of such, and there have been several publicized incidents which has led to people withdrawing from participation since they did not feel safe or comfortable, or to support such people. Here's the latest example https://twitter.com/MatthewGerstman/status/1110363827655376897

    In terms of precedent, here is a generic conference one https://confcodeofconduct.com/ and what the W3C has: https://www.w3.org/Consortium/cepc/

    And here is what I wrote to a current OMG working group:
    In the meantime let’s please be polite to each other, whether in meetings or via email. And bear in mind that:
    • 1) We’re all doing this as volunteers in parallel with our “day job”;
    • 2) Hence we may have different levels of availability for this, and that may vary over time; both for calls and to read materials or work on assignments;
    • 3) Let’s show appreciation for any contributions people do make even, if they do need more work
    • 4) We each bring a different background, perspective and expertise. What may be obvious to us may need explanation to others, or them pointed to background reading (but see 2) above)
    • 5) Similarly, what may be interesting to some may not be to others.
    • 6) interpersonal issues are best dealt with one-to-one (ideally by speaking directly) rather than email to the whole list since emails can easily be misunderstood (as I’ve personally found from experience)
    • 7) we’re still new as a team so can expect to go through a “storming” stage as we get used to each other and develop a way of working and communicating. See https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development

  • Reported: ABPSC 3.3 — Thu, 28 Mar 2019 10:12 GMT
  • Updated: Fri, 24 Jan 2020 09:42 GMT

Use of OMG LOI Template should be a requirement, not a suggestion

  • Key: ABPSC-14
  • Status: open  
  • Source: Jackrabbit Consulting ( Charlotte Wales)
  • Summary:

    Section 4.4 of the RFP, which describes the required Letter of Intent (LOI), treats the use of the OMG's LOI template as a suggestion.. not a requirement. This is not a good idea. Should be a requirement to ensure that the legally binding words contained in the LOI template are provided in a consistent way. In like fashion, it should be clear (stated somewhere – P&P?) that the same applies to RFC submissions – that use of the OMG's LOI template is not a suggestion but a requirement.

  • Reported: ABPSC 3.3 — Fri, 18 Oct 2019 17:06 GMT
  • Updated: Tue, 29 Oct 2019 00:08 GMT

P&P does not exist

  • Key: ABPSC-4
  • Status: open  
  • Source: Object Management Group ( Larry Johnson)
  • Summary:

    4.2.1 Outline of RFP Process: 

    • Step 4:  The membership list for voting on issues related to the RFP may be closed, as described in section
    • That section does not exist... likely means to refer to Section 3.7.3 Subgroup Polls
      This is the only reference to the section number.
  • Reported: ABPSC 3.3 — Mon, 11 Mar 2019 18:29 GMT
  • Updated: Tue, 29 Oct 2019 00:08 GMT

"American English" requirement is not in P&P

  • Key: ABPSC-11
  • Status: open  
  • Source: Object Management Group ( Jason Smith)
  • Summary:

    There is a common understanding on the AB that documents must be in English, and must be in American dialect.

    There is no such stipulation in the P&P.

  • Reported: ABPSC 3.3 — Thu, 10 Oct 2019 03:19 GMT
  • Updated: Tue, 29 Oct 2019 00:07 GMT

Deadline for submission of request for Vote to Vote should be added to the P&P

  • Key: ABPSC-15
  • Status: open  
  • Source: Jackrabbit Consulting ( Charlotte Wales)
  • Summary:

    Have inspected the P&P for the deadline for submitting a request for a Vote to Vote. It is commonly understood that it needs to be 4 weeks in advance (so says Juergen's emails prior to each meeting) but where is this requirement codified? Right now, the only place where the rules governing a Vote-to-Vote are described is in the Hitchhiker's Guide (V7.8) but that is not a normative document – just a guide. It really needs to be in the P&P.

  • Reported: ABPSC 3.3 — Fri, 18 Oct 2019 17:12 GMT
  • Updated: Fri, 18 Oct 2019 17:12 GMT

Clarification needed on Submitters, Supporters, and Contributors

  • Key: ABPSC-13
  • Status: open  
  • Source: Object Management Group ( Jason Smith)
  • Summary:

    A recent discussion on the AB mailing list led to the following observations regarding Submitters, Supporters, and Contributors in OMG Submissions:

    1) Sanitized description of issue, from a non-public example
    Contributor was defined as a Participating Organization who is not a Submitter. Submitter is defined as OMG Member who provides an LOI. Participating Organization is defined as anyone who signs onto the agreement. Document states that all POs are bound to the IPR, at least in intent.

    PartOrg = IPRBound
    Submitter = OMGMember && LOI
    Contributor = !Submitter = !(OMGMember && LOI) = !OMGMember || !LOI

    Contributor => IPRBound && (!OMGMember || !LOI)

    So a Contributor could be either: not an OMG Member, or an OMG Member who didn’t file an LOI. Since not filing an LOI is supposed to be a non-starter for contributing, I assumed this was to include non-OMG Members in the process. (Additionally, if they’re not an OMG Member, then can they even file an LOI?)

    In all cases, a Contributor is bound by the IPR, which is intended for those contributing IP. All signs point to this being a back-door for IP-contributing non-OMG Members. Please correct me if I’m wrong. If wrong, then this entire thing gets easier, because....

    2) IPR Definition of ‘Contributor’ vs. ‘Member'
    Document: https://omg.org/cgi-bin/doc.cgi?ipr
    OMG Doc #: ipr/12-09-02

    IPR 1.2: "Certain OMG members who participate in the development of OMG Formal Specifications make commitments to license their IPR as set forth below.”

    --> This applies to OMG members only.

    This is supported by:

    IPR 8.1K: "“Obligated Party” means an OMG Member that has incurred a Contribution Obligation or a Participation Obligation. “Obligated Party” includes Affiliates of the OMG Member.”

    IPR 4.4A: "Obligated Parties. OMG Members are Obligated Parties only under the following circumstances:"

    However, in other places OMG membership is left completely out:

    IPR 2.1: "Each contributor of any material to an OMG Specification is [...]

    --> ‘contributor’ is never defined as exclusive to OMG members.

    IPR 3.2A: "Contributors. Anyone who makes a Submission or Contribution to an OMG Specification [...]

    IPR 8.1D: "“Contribution” means any written submission in response to an RFP or RFC, or to an FTF or RTF, that is intended to be included in an OMG Formal Specification. The variants “Contribute” and “Contributor” are subject to this definition."

    --> This is as close as it gets.

    The way it reads, non-Members can theoretically contribute, but only OMG Members can be bound to obligation under 4.4.

    The Document appears to extend this to non-members, but it isn’t precisely clear, and it would be sloppy to leave this to the legalese authoring skills of each team, don’t you think?

    Currently in the P&P (https://www.omg.org/cgi-bin/doc.cgi?pp/17-06-01)/ IPR:

    • Submitters are:
      • OMG members
      • have previously submitted an LOI
      • have contributed IP, and are bound by the IPR
    • Contributors are a somewhat defined entity of unclear OMG membership, but who are bound by the IPR, in theory
    • Supporters are an undefined non-entity


    • Submitters are:
      • OMG members, able to put forth a specification for voting
      • have previously submitted an LOI
      • have contributed IP, and are bound by the IPR
    • Contributors are:
      • NOT OMG members, not able to put forth a specification for voting
      • have contributed IP, and are bound by the IPR
      • MAY have previously submitted an LOI <--- This was unclear in the SysML2 Agreement. See 1) above
    • Supporters are defined as:
      • NOT having contributed IP, and therefore not involved in the IPR (or have formally withdrawn the IP)
      • NOT submitted an LOI (or have withdrawn it via notification of intent to TechDir (P&P 3.7.2 and IPR 5))
      • OMG status is irrelevant <--- Curious on thoughts here [1]

    As per IPR 5, once a Member contributes IP, they are bound to the Contribution Obligation. This is clear, but it is not clear what the outcome is for a non-Member Contributor, if such a thing is being allowed. Non-members cannot be on an Adoption Process Voting List (IPR 8.1B), but withdrawal from an Adoption Process Voting List is the single trigger for establishing the outcome of obligation with respect to IP in IPR 5.2. I see a loophole. The Document appears to pull in Contributors to this process, and I think that is the intent, but again, it’s not precisely clear.

    To get back to the original Submitter vs. Supporter (vs. Contributor) question:

    A Member signs on as Submitter, contributes IP, then lets their membership lapse. They’re no longer able to be listed as a Submitter, but they still need to be clearly bound by the IPR in the specification. Contributor would suffice here. If the Contribution Obligation is in effect, then the organization should be listed as Submitter or Contributor, based on OMG Membership.

    An organization can drop to a theoretical Supporter status only if clause 5.2C is met, neither Contribution nor Participation Obligations.

    I think that having this be clear would be an improvement. Supporters should be, IMO, bystanders who support the effort but who did not contribute to the creation of the document in a way that would worry their internal legal staff.

    Allowing non-OMG Members to sign on as Supporters at will is a nice gesture, but requiring membership to do so could help drive, well, Memberships. One for the BoD, I think.

    Larry had the following comment:

    There is no such thing as a supporter in P&P. Supporters are cultural artifacts and have no standing. There are only submitters... however; under IPR (see Jason's [comments]), submitters are responsible for the IPR claims on material in the submission, hence stuff rolls downhill should someone else contribute... and note there is no requirement that contributors be declared (as are the Supporters with no standing) unless there is an issue/condition to be declared under the IPR agreement.

  • Reported: ABPSC 3.3 — Wed, 16 Oct 2019 19:16 GMT
  • Updated: Wed, 16 Oct 2019 19:16 GMT

Review date limitation for allowing RTFs to extend functionality

  • Key: ABPSC-12
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    P&P Section, paragraph 4, defines the circumstances under which "an RTF may respond to an Issue by proposing an extension that adds functionality to a Specification." However, this allowance is limited to RTF's whose report is "delivered before 15th September 2020". The AB should review the policy as it stands well before this sunset date and decide whether to recommend that the subject policy be made permanent.

  • Reported: ABPSC 3.3 — Tue, 15 Oct 2019 23:33 GMT
  • Updated: Tue, 15 Oct 2019 23:33 GMT

Derivative Templates Need Updating

Need a new process - Request for Curation Inclusion (RFCI) Process

  • Key: ABPSC-7
  • Status: open  
  • Source: Lockheed Martin ( Laura Hart)
  • Summary:

    Request that a new Request for Curation Inclusion (RFCI) process template and associated document template be created to support the review and vetting of reusable content that is considered valuable to our OMG communitiy. Examples of content include FIBO updates, CubeSat Reference Model (CSRM), other domain model examples, libraries, and methods. Our current RFP process ab-18-12-10 RFP, is not appropriate for non-language content but could be tailored and streamlined to support the review, approval, maintenance and archival of content that is generated using OMG specifications (OMG UML, SysML, UAF, BPM....).

    Curation: 1. The action or process of selecting, organizing, and looking after the items in the collection.. 2. The selection, organization, and presentation of online content, merchandise, information etc., typically using professional or expert knowledge.

  • Reported: ABPSC 3.3 — Mon, 8 Apr 2019 14:05 GMT
  • Updated: Mon, 8 Apr 2019 16:50 GMT