On 2021-02-25 , at 20:00, Chet Ensign <chet.ensign@...> wrote:

A new poll has been created:

Please make two choices below to indicate whether you approve or disapprove the respective Project Specifications becoming candidates for OASIS Standards. 

OSLC Requirements Management Version 2.1 Project Specification 01 [1] was approved as a Project Specification on 03 September 2020. The Open Project received 3 Statements of Use from SodiusWillert, IBM, and KTH Royal Institute of Technology [2]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?

 

OSLC Change Management Version 3.0 Project Specification 01 [3] was approved as a Project Specification on 17 September 2020. The Open Project received 3 Statements of Use from KTH Royal Institute of Technology, SodiusWillert, and IBM [4]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?

 

Approving this ballot will result in a 60-day public review after which, if no comments are received, the PSs will be submitted to an OASIS-membership-wide call for consent. If comments are received, additional steps will need to be taken as explained in TC Process section 3.4.2, Public Review of a Candidate OASIS Standard [5], the rules applicable here.  

 

This ballot requires a Special Majority Vote [6]. The PGB has 3 voting members. In order to pass, at least 2 (2/3 x 3) have to vote Yes and none may vote No.

 

[1] URI to the PS:

https://lists.oasis-open-projects.org/g/oslc-op-pgb/attachment/107/0/rm-2.1-cos01.zip

 

 

[2] Links to Statements of Use for Requirements Management

 

- SodiusWillert :

https://lists.oasis-open-projects.org/g/oslc-op/topic/sodiuswillert_statement_of/78363625?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78363625

 

- IBM: 

https://lists.oasis-open-projects.org/g/oslc-op/topic/ibm_statements_of_use_for/78712131?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78712131

 

- KTH Royal Institute of Technology

https://lists.oasis-open-projects.org/g/oslc-op/topic/kth_statement_of_use_of_oslc/78206691?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78206691

 

[3] URI to the PS:

https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/ps01/change-mgt-spec.html

 

[4] Links to Statements of Use for Change Management

 

- KTH Royal Institute of Technology

https://lists.oasis-open-projects.org/g/oslc-op/topic/kth_statement_of_use_of_oslc/78206683?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78206683

 

- SodiusWillert

https://lists.oasis-open-projects.org/g/oslc-op/topic/sodiuswillert_statement_of/78363625?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78363625

 

- IBM

https://lists.oasis-open-projects.org/g/oslc-op/topic/ibm_statements_of_use_for/78712131?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78712131

 

[5] http://www.oasis-open.org/policies-guidelines/tc-process#OASISstandard

 

[6] Special Majority Vote: http://www.oasis-open.org/committees/process-2010-07-28.php#dSpecialMajority

1. OSLC Requirements Management Version 2.1 - yes
2. OSLC Requirements Management Version 2.1 - no
3. OSLC Requirements Management Version 2.1 - abstain
4. OSLC Change Management Version 3.0 - yes
5. OSLC Change Management Version 3.0 - no
6. OSLC Change Management Version 3.0 - abstain

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.

On 2021-02-23 , at 18:19, Michelle Cotton via RT <iana-prot-param@...> wrote:

Dear Andrew,

Your request has been approved by the designated expert for a provisional registration.

Review from the expert:
<start review>
It can then progress to permanent status when approved as an Oasis Standard.

This on the basis that:
1. OASIS is recognised as an open standards development organisation (per previous discussions about another submission).

2. The OASIS process includes formal public review in progressing from Candidate OASIS Standard to OASIS Standard, but not before. (If I’ve misunderstood this, I’d be happy to reconsider my recommendation.)

One comment about the registration template itself:

There is no email address given for the change controller. This is not strictly necessary if OASIS is specified, but it might be helpful if anyone wishes to enquire about our comment on the specification.

Something to consider when it becomes permanent:
You have indicated the change controller can be the OASIS PGB: does this group survive the work of the technical committee once the standard is published? If not, I’d suggest the change controller be OASIS, or a permanent role in that organisation. In any case, I think OASIS should be clearly identified here as the sponsoring standards organisation.
<end review>

Before we continue with the provisional registration, do you have an email that we can include in case anyone has questions?


Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services


On Mon Feb 22 12:15:16 2021, andriib@... wrote:

Dear IANA administrator,

I would like to submit the registration application as per the
procedure outlined in https://tools.ietf.org/html/bcp90#section-4.3.
Please find the registration request template forwarded below from our
original submission to ietf-message-headers@...<mailto:ietf-
message-headers@...> from 2 weeks ago. No objections have been
received on the mailing list as far as I can tell.

Thank you kindly for your time.

Kind regards,
Andrew Berezovskyi

OSLC OP PGB co-chair

Begin forwarded message:

From: Andrii Berezovskyi <andriib@...<mailto:andriib@...>>
Subject: [Ietf-message-headers] OSLC-Core-Version header registration
request
Date: 6 February 2021 at 13:38:41 CET
To: "ietf-message-headers@...<mailto:ietf-message-
headers@...>" <ietf-message-headers@...<mailto:ietf-message-
headers@...>>

Hello,

OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project
(OP) would like to submit the following registration request:


Header field name: OSLC-Core-Version

Applicable protocol: http (RFC 2616 and its successors)

Status:
  standard (Project Specification 01 as per OASIS classification, has
all the statements from the implementers to progress to the Candidate
OASIS Standards once PS02 is published with the changes related to
this registration request)

Author/Change controller:
  OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing
Board (PGB) itself)

Specification document(s):
  https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-
core.html (§4.2, Part 1, approved Project Specification 01)
  https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html
(latest draft that will have to be voted on again once this
registration request has been considered by IETF, contains ABNF as per
the registration requirements)
  https://archive.open-
services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning
(spec that introduced the header)

Related information:
  OSLC-Core-Version header has been in active use by OSLC
implementations since 2009.
  https://github.com/oslc-op/oslc-specs/issues/459
  This submission is made in preparation to progressing OSLC Core
specification to the OASIS Standard stage (currently Project
Specification stage has passed and Candidate OASIS Specification stage
is next).


Answers to the considerations in
https://tools.ietf.org/html/rfc7231#section-8.3:

1) Field is a single value.
2) The field can be used for both requests and responses; the spec
defines the expected behaviour.
3) The header is not to be stored by the origin servers on PUT
requests.
4) The semantics of the header only depend on whether a server or a
client is sending it.
5) The header field is not hop-by-hop.
6) Intermediaries between OSLC servers and OSLC clients shall not
insert or alter this header unless they are themselves OSLC servers or
OSLC clients.
7) Yes, the header may be listed in the Vary header because the server
may serve different content depending on the OSLC-Core-Version
capability of the client.
8) No, the header is not generated dynamically and is not useful as a
chunked trailer.
9) Yes, the header is to be preserved across redirects.
10) No private data is disclosed in the header. No security
implications arise from this header alone as it only guides clients
and servers on the version of the high-level protocol and is
independent of the protocols that constitute a larger attack surface
such as HTTP, TLS, oAuth. The attacker may infer from a value of a
header that a certain feature is not supported by an old client or
server (e.g. OSLC 2 uses oAuth 1.0 and OSLC 3 recommends OIDC 1.0).
The attacker may also indirectly try to guess that an old client or
server may run old software such as JDK 7 and use insecure settings
due to a lack of new TLS version support etc. We don't think, however,
that this header introduces any significant information for the
attacked they could not gather on their own.

Thank you kindly for your time and the consideration of our
application.

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair


_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@...<mailto:Ietf-message-headers@...>
https://www.ietf.org/mailman/listinfo/ietf-message-headers

On 12 February 2021, at 13:00, Andrii Berezovskyi <andriib@...> wrote:

CCing the PGB

--

Best regards,

Andrew

On 12 February 2021, at 12:59, Andrew Berezovskyi via lists.oasis-open-projects.org <andrew=berezovskyi.me@...> wrote:

Hello OP,

Given what we heard from Chet yesterday that a new document is not needed for COS, shall we push CM to COS directly? If I understood him correctly, we can simply file a new ticket under https://github.com/oasis-open-projects/administration/issues for CM COS today and they will take it from there.

What do you think? PGB members, are you in favour of that (there will be an SMV ballot so this is not a binding reply)?

Here is the milestone for the CM COS: https://github.com/oslc-op/oslc-specs/milestone/23. Can someone confirm that the one issue in that milestone is not blocking us from going to COS?

–Andrew

On 12 February 2021, at 12:59, Andrew Berezovskyi via lists.oasis-open-projects.org <andrew=berezovskyi.me@...> wrote:

Hello OP,

Given what we heard from Chet yesterday that a new document is not needed for COS, shall we push CM to COS directly? If I understood him correctly, we can simply file a new ticket under https://github.com/oasis-open-projects/administration/issues for CM COS today and they will take it from there.

What do you think? PGB members, are you in favour of that (there will be an SMV ballot so this is not a binding reply)?

Here is the milestone for the CM COS: https://github.com/oslc-op/oslc-specs/milestone/23. Can someone confirm that the one issue in that milestone is not blocking us from going to COS?

–Andrew

On 11 February 2021, at 18:13, Andrii Berezovskyi <andriib@...> wrote:

Dear PGB members,

The rules require us to notify you at least 14 days before submitting the ballots for the spec drafts publication. We are hereby notifying you of the OP intention to publish OSLC Requirements Management 2.1 Candidate OASIS Standard 01 in 2 weeks’ time.

Pull request with the draft: https://github.com/oslc-op/oslc-specs/pull/487 (ZIP file attached for your convenience)

Best regards,
Andrew Berezovskyi on behalf of the OSLC OP maintainers






<rm-2.1-cos01.zip>

On 2021-02-05 , at 17:45, Axel Reichwein <axel.reichwein@...> wrote:

Hello Jane, 

I would be very happy to give this presentation on OSLC. I have done this kind of presentation very often.

Do the PBG members agree if I give it?

Best regards,

Axel

On Fri, Feb 5, 2021 at 6:30 AM Jane Harnad <jharnad@...> wrote:

Hi Everyone,

We received this speaker request. Is there anyone from the PGB that might be interested? I'd be happy to help. 

Please let me know. Thanks so much, Jane

---------- Forwarded message ---------
From: 'Gully, Michael J CIV USARMY HQDA ASA ALT (USA)' via Communications Alias<Communications@...>
Date: Wed, Feb 3, 2021 at 4:52 PM
Subject: OSLC Speaker for OSD Digital Engineering Working Group
To: communications@... <communications@...>
Cc: Bucher, Nancy M CIV USARMY HQDA ASA ALT (USA) <nancy.m.bucher.civ@...>

Hello,

 

I’m reaching out looking for a speaker to present the OSLC to the upcoming United States Department of Defense Digital Engineering Working Group in March 2021 (specific date TBD).  The special topic for the meeting is engineering data exchange and the Army believes a presentation from the OSLC would be an excellent fit.  

 

Please respond to myself or Dr. Nancy Bucher (cc’ed) to coordinate next steps.

 

Michael J Gully

Army Digital Engineering Co-Lead

ASA(ALT) Office of the Chief Systems Engineer 

(256) 808 9184 (M / Telework)

(703) 545-4738 (O - NCR)

(256) 313 6197 (O - HSV)

Michael.J.Gully2.civ@...

 

On 2021-01-12 , at 16:21, Andrii Berezovskyi <andriib@...> wrote:

A new poll has been created:

Do the PGB members approve publishing OSLC Automation 2.1 as the PSD 01?

Release materials are located under https://github.com/oslc-op/oslc-specs/releases Intent to publish: https://lists.oasis-open-projects.org/g/oslc-op/message/427?p=,,,50,0,0,0::Created,,am,50,2,0,78714754

The ballot opens immediately and will close on January 19.

Best regards, Andrew Berezovskyi

1. YES, approve the publication
2. NO, reject the publication

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.

On 2020-12-04 , at 17:08, Jim Amsden <jamsden@...> wrote:

IBM is pleased to provide statements of use to the following OASIS OSLC Open Project specifications. 

IBM Statements of use: for OSLC Core Version 3.0 Project Specification

IBM has successfully implemented the OASIS OSLC Core Version 3.0 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/ps01/oslc-core.html dated 17 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically the Engineering Lifecycle Management suite of products, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.

Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 

IBM Statements of use: for OSLC Requirements Management Version 2.1

IBM has successfully implemented the OASIS OSLC Requirements Management Version 2.1 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/requirements-management-spec.html dated 03 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically DOORS Next, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.

Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 

IBM Statements of use: for OSLC Change Management Version 3.0

IBM has successfully implemented the OASIS OSLC Change Management Version 3.0 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/ps01/change-mgt-spec.html dated 17 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically Engineering Workflow Management, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.

Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 

IBM Statements of use: for OSLC Quality Management Version 2.1

IBM has successfully implemented the OASIS OSLC Quality Management Version 2.1 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/qm/v2.1/ps01/quality-management-spec.html dated 27 August 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically Engineering Test Management, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.

Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses.