1. OMG Mailing List
  2. OMG Process Change Management

Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSXTY14-20 Inconsistent Definitions of RTPS Encapsulation DDS-XTypes 1.3b1 open
ABPSC-28 P&P needs to be more explicit about which documents are subject to the 4 wk rule ABPSC 3.3 open
ABPSC-29 Clarify meaning of 'attendance' to include online presence ABPSC 3.3 open
ABPSC-9 There is no way to recall (deprecate, or whatever a Process (RFP...) ABPSC 3.3 open
ABPSC-10 AB Email vote closure trigger is not well-formed. ABPSC 3.3 open
ABPSC-25 Revisit copyright license in RFI template ABPSC 3.3 open
ABPSC-18 Boilerplate includes ISO 8859-1 as a document format ABPSC 3.3 open
ABPSC-22 BCQ requested too frequently, and unclear in the P&P ABPSC 3.3 open
ABPSC-21 Board approval should not be treated as a change in Issue status ABPSC 3.3 open
ABPSC-19 RFPs shall be presented and discussed at least one meeting prior to the issuing meeting ABPSC 3.3 open
ABPSC-14 Use of OMG LOI Template should be a requirement, not a suggestion ABPSC 3.3 open
ABPSC-4 P&P 3.7.4.1 does not exist ABPSC 3.3 open
ABPSC-11 "American English" requirement is not in P&P ABPSC 3.3 open
ABPSC-15 Deadline for submission of request for Vote to Vote should be added to the P&P ABPSC 3.3 open
ABPSC-13 Clarification needed on Submitters, Supporters, and Contributors ABPSC 3.3 open
ABPSC-12 Review date limitation for allowing RTFs to extend functionality ABPSC 3.3 open
ABPSC-8 Derivative Templates Need Updating ABPSC 3.3 open
ABPSC-7 Need a new process - Request for Curation Inclusion (RFCI) Process ABPSC 3.3 open

Issues Descriptions

Inconsistent Definitions of RTPS Encapsulation

  • Status: open  
  • Source: OCI ( Frederick Hornsey)
  • Summary:

    There are inconsistencies in the two definitions of the RTPS Encapsulation Header I've found so far. The major issue is that the values for the encoding identifiers are different between 7.4.3.4 and 7.6.3.1.2 for non-XCDR1 encodings. These are the big-endian values compared:

    Type 7.4.3.4 7.6.3.1.2
    Plain XCDR2 0x00, 0x10 0x00, 0x06
    Parameter List XCDR2 0x00, 0x12 0x00, 0x0a
    Delimited XCDR2 0x00, 0x14 0x00, 0x08
    XML 0x01, 0x00 0x00, 0x04

    The other issue is that while 7.6.3.1.2 describes the two options byte of the encapsulation header that follow the encoding identifier and extends it for padding info, 7.4.3. is lacking in details as far as I can see. The serialization rules in 7.4.3.5.3 as `OPTIONS`, but doesn't define it in any of the tables before the rules like all the other symbols are. It does mention encapsulation in 7.4.3.5, but doesn't mention anything about extending the options bytes.

  • Reported: DDS-XTypes 1.3b1 — Thu, 4 Jun 2020 17:51 GMT
  • Updated: Wed, 8 Jul 2020 04:18 GMT

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: Fri, 13 Mar 2020 00:09 GMT

Clarify meaning of 'attendance' to include online presence

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

    The P&P uses two terms to discuss the presence of a representative at a meeting (of any sort): 'attend' (present tense) and 'in person' (past tense). The meaning is clear from context that it is an individual who has engaged in a meeting.

    Given that many (most?) of our meetings now incorporate a dial-in line or online screen presentation tool of some sort, it is important for us to reflect this shift.

    Suggestion to add language specifying that online engagement (with bidirectional communication capability, voice, typed, or both) counts for purposes of attendance, including 'in person', and that attendance records should include anyone calling in to a meeting.

    Section 3.3 would be a good place to add this, as it currently does not exist.

  • Reported: ABPSC 3.3 — Thu, 12 Mar 2020 00:41 GMT
  • Updated: Thu, 12 Mar 2020 22:12 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: 88solutions ( 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: 88solutions ( 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 4.4.1.3:
    [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: 88solutions ( 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

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 3.7.4.1 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 3.7.4.1.
    • 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
        and
      • have previously submitted an LOI
        and
      • 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

    Desired:

    • Submitters are:
      • OMG members, able to put forth a specification for voting
        and
      • have previously submitted an LOI
        and
      • have contributed IP, and are bound by the IPR
    • Contributors are:
      • NOT OMG members, not able to put forth a specification for voting
        and
      • have contributed IP, and are bound by the IPR
        and
      • 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)
        and
      • NOT submitted an LOI (or have withdrawn it via notification of intent to TechDir (P&P 3.7.2 and IPR 5))
        and
      • 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.

    [1]
    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 4.4.1.1, 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