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:

The other issue is that while 7.6.3.1.2 describes the two options bytes 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 has them 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.

Update Table 39 to match 7.6.3.1.2 Table 60

Follow 7.6.3.1.2 Table 60

page 263. you still have a reference to "CommunicationsLink" which is no longer anywhere else in spec.
Further, the properties defined here:
"1. capacity : String[] Details how much information can be passed on the Communications Link.
2. infrastructureTechnology : String[] Details the technology to be used to provide the communications infrastructure. "
should be defined for ResourceConnector instead.

UAF RTF 1.3 scope is limited to Mission Engineering only

Out of scope for 1.3

Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationship are missing in the BACM.

This duplicates BACM-38

This duplicates BACM-38 which has been approved

pp/20-06-01 jumps from 3.2 to 3.4, fix is to poke Word to use contiguous numbering, and adjust necessary references elsewhere in document.

Obsoleted by ABPSC-30

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
<<<

resolved completely outside the ABPSC