OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-domains message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [oslc-domains] Re: [oslc-sc] Re: OASIS OSLC Open Project Proposal


Jim, thanks for the feedback. This is an excellent exercising, especially where my broad assumptions run into your particular questions. Also becauseÂI see that there are several details I thought I'd have time to address. But the future is now. Anyhow, answers and discussion below. Text from you in bold. Text from me in bold purple.Â

1. We would like to migrate all current CS and WD documents to the OP in order to use a single repo, process and TSC for managing all OSLC standards track documents. The team is too small and there are too many documents to handle multiple processes

> That makes sense.Â

<from the document> Can the current Committee Specifications be migrated to Project Specifications?

> Yes. The way to accomplish that will be to contribute the Committee Specs to the project, revise them into Project Specifications (we'll help with that), and approve them as such by Special Majority Vote. That's needed so that they are bound under the OP's CLAs. We'll work with you on those steps.Â

<from the document> Iâm thinking a new site for the OP might be preferred. [note - meaning in place of open-services.net] This separation of concerns might lead to less coupling and more flexibility on how to collaborate on the development of OSLC and its use.

Then these can be cross linked to explain how they are related and lead people to the right place for what they want to do.Â

> OK. We will take that up with Carol and work with you.Â

2. We would like to accelerate the process and infrastructure changes for the OP so that the ongoing technical work can proceed as seamlessly as possible.Â

> OK. I think you need to get the approvals done in the MS and the TCs before work products can be moved. I'll get the motion language drafted quickly.Â

3. We would like to have a single GitHub repo for the OSLC OP, using and renaming the current oslc-core repo. We will migrate the Domains TC repo to appropriate folders in the oslc repo.

> Do you mean the TC's Open Repository? I don't think we can repurpose that. The work done there has been contributed under the Open Repo CLAs and the Open Project CLAs are different. However, our design was to have the open project set up as its own Github organization anyhow, not under /oasis-open. The notion of a single repo is not a problem.ÂÂ

4. We would like to keep the current GitHub OSLC organization, open-services.net, eclipse/lyo and the OSLC OP as separate but linked entities focused on different aspects of application integration enablement and supporting initiatives and work products.

> Yes, I assumed that to be the case.Â

5. The only standards track process thing that is unclear is where the electronic ballots for OP Project Specification are created and managed.

> I thought I was going to have time to solve that. But the future is now. <grin> Since the required votes are Special Majority Vote, I have been thinking that I'd set up an Open Project Voting Kavi group similar to the Voting group for OASIS member ballots. It will be a little clunky but I think I know how to make that work. Alternatively, I will be looking into balloting apps to add to either Github or the website.ÂÂ

6. The specification publishing process needs to be outlined, prototyped and tested.

> Yes. We'll work with you on that first thing.Â

--- from the document ---Â

<from the future state> Meeting minutes are published on the TC mailing list

> I think you mean 'TSC mailing list'?Â

<from the future state> will the project specification lifecycle be similar to the current specification lifecycle?

> Yes except that you won't need to engage with us to publish drafts. That will all be under your control up to the publication of an approved Project Specification. Should be simpler for you. We'll work out the details with you.Â

<from the future state> will new TC admin requests be created for Project Specifications?Â

Yes. I thought I had time.ÂThe future is now.Â

<from the future state> this is your description of the Project Specification Publication Process

> This looks right to me. Again, Paul and I will work with you all on the templates and the steps. This will be a good for us to put all the mechanics in place.Â

We'll talk further next week. Meanwihile, have a great weekend.Â

/chet

On Fri, Jan 18, 2019 at 1:53 PM Jim Amsden <jamsden@us.ibm.com> wrote:
Chet,
I added comments and some additional items for consideration using change tracking in the attached document. In summary:

1. We would like to migrate all current CS and WD documents to the OP in order to use a single repo, process and TSC for managing all OSLC standards track documents. The team is too small and there are too many documents to handle multiple processes

2. We would like to accelerate the process and infrastructure changes for the OP so that the ongoing technical work can proceed as seamlessly as possible.

3. We would like to have a single GitHub repo for the OSLC OP, using and renaming the current oslc-core repo. We will migrate the Domains TC repo to appropriate folders in the oslc repo.

4. We would like to keep the current GitHub OSLC organization, open-services.net, eclipse/lyo and the OSLC OP as separate but linked entities focused on different aspects of application integration enablement and supporting initiatives and work products.

5. The only standards track process thing that is unclear is where the electronic ballots for OP Project Specification are created and managed.

6. The specification publishing process needs to be outlined, prototyped and tested.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From: Â Â Â ÂChet Ensign <chet.ensign@oasis-open.org>
To: Â Â Â ÂJim Amsden <jamsden@us.ibm.com>
Cc: Â Â Â ÂCarol Geyer <carol.geyer@oasis-open.org>, OSLC Core TC <oslc-core@lists.oasis-open.org>, OASIS OSLC Domains TC Discussion List <oslc-domains@lists.oasis-open.org>, oslc-sc@lists.oasis-open.org, Scott McGrath <scott.mcgrath@oasis-open.org>
Date: Â Â Â Â01/17/2019 04:54 PM
Subject: Â Â Â ÂRe: [oslc-domains] Re: [oslc-sc] Re: OASIS OSLC Open Project Proposal




Jim, please have a look at the attached and let me know if this gives everybody what they need to understand what needs to happen, etc.. If not, let's discuss what else you would like to see.Â

Best,Â

/chet

On Thu, Jan 17, 2019 at 9:15 AM Jim Amsden <jamsden@us.ibm.com> wrote:
Chet,
The TCs are looking forward to your roadmap to OASIS OSLC Open Project. What would be helpful is a short table that highlights the impact on the current OSLC MS StC and Core and Domains TCs, and their processes, specification lifecycle governance and work product deliveries.


We would also like to prototype the changes by using the OSLC Core CSPRD04 as our first Open Project Project Specification.


I would like to consider merging the domains and core TCs into a single OP TSC, and combine our current two meetings into one. This implies merging both charters into the new Open Project charter.


I'd be happy to meet with you anytime to start working through the details.


Regarding some of the document editing changes Paul requested for the OSLC Query CSPRD01 specification:
* moving to https
* updated IPR Policy statement
* links to
open-services.net2.0 specifications are all broken
* OASIS headings text colors and logo in spec.css
* <hr>Âtag in the HTML, just before each major section
Would it be possible for Paul to be and adjunct member of the OP TSC and make these edits directly? That could speed things up and make it easier for everyone. Alternatively, it would be helpful if these were raised as GitHub issues, labeled as "formatting" so that its easier to track them instead of using emails that can get lost.





Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575





From: Â Â Â Â
Chet Ensign <chet.ensign@oasis-open.org>
To: Â Â Â Â
Jim Amsden <jamsden@us.ibm.com>
Cc: Â Â Â Â
Carol Geyer <carol.geyer@oasis-open.org>, OSLC Core TC <oslc-core@lists.oasis-open.org>, OASIS OSLC Domains TC Discussion List <oslc-domains@lists.oasis-open.org>, oslc-sc@lists.oasis-open.org, Scott McGrath <scott.mcgrath@oasis-open.org>
Date: Â Â Â Â
01/14/2019 05:44 PM
Subject: Â Â Â Â
[oslc-domains] Re: [oslc-sc] Re: OASIS OSLC Open Project Proposal
Sent by: Â Â Â Â
<oslc-domains@lists.oasis-open.org>




Hi Jim,Â

Here are the answers to your questions. I am working on a timeline, a package of draft motions, and an outline of the actions everybody will need to take. Maybe later this week it would be good to get the right group of people together to review all that and make sure it lines up with your expectations. Have a look and these and then let me know.Â

> 1. Clarification: OASIS waiver of Project Backer fees for OSLC Open Project:Â OASIS will waive the Backer fees for the organizations that are represented on the current OSLC MS StC for the foreseeable future, provided that those companies retain their OASIS Foundational Sponsor, Sponsor, or Contributor memberships. Organizations not represented on the current OSLC MS StC, including OSLC Member Section organizations that are not currently on the StC, will be able to become OSLC Project Backers and members of the PGB by paying the annual fees listed above.


Yes, that is correct.Â


> 2. Clarification: For practical and technical reasons, I propose that PROMCODE continue on its current standards track, maintaining its current TC and not be part of the OASIS OSLC Open Project.


This is really a decision for the members of the PROMCODE TC to make. Since they are a part of the Member Section with representation on the MS (though not represented on the StC) and an active OSLC TC, it wouldn't be right to close the door on them. We recommend that a representative have a discussion with them about whether they want to go through all the work to close their TC and move the work to the OP. I'm happy to help with that. I suspect they'll prefer to carry on as a TC.


> 3. Issue: All PGB members must sign the CLA regardless of whether or they contribute content. This could create a legal hurdle for PGB members who wish to participate in project governance but may be unable to sign the CLA. Each of the current StC members will need to research this issue within their own organization to see if this is an issue for them.

Yes, members will certainly want to consult with their counsel. Our rules are crafted this way on the assumption that projects may want, at some point, to bring some of their work to Project Specification status (the OP equivalent of a CS). For work that gets to that level, users will expect companies on the body running the project not to make legal problems for them if they implement it. The CLA for PGB members provides that assurance to users and implementers of the Open Project's work.Â


Parties who want to stay involved but not give a license beyond the simple FOSS for their own contributions *can* do so. They just won't have the benefit of putting their name on the marquee or voting on standards submissions.


Also, anyone who is in the TC now has an equal or great licensing commitment today than they take on as a PGB member under the OP (with the sole exception that their NEW increments of contribution after the transition also will be usable by all freely in derivations or forks). We'd be surprised if that seems MORE onerous to any of the current players. We are always ready to chat with members and their counsel if it will help.Â
 Â
Also, you can somewhat mitigate and smooth a transition by working, within the proponents' group, to find the new FOSS license variant under which most would be most comfortable contributing.Â


> For current OSLC TC members, what IP agreements already exist for OASIS specification contribution, and how does this relate to the CLA?Â


In a TC, members have several IPR commitments, under our rules and the signed Membership Agreement, including (1) an ongoing copyright license from everything sent in, and (2) a patent license promise on all final specs, based on the mode (like "RF on Limited Terms") and the contingency that it only becomes enforceable after certain periods and votes occur.


In an OP, there are 3 levels: (1) Anyone can submit bug reports and non-substantive edits. (2) Contributors of material, technical work must sign a CLA, and thus grant the designated FOSS license rights in their contributions. (These might or might not include patent protection, depending on the license chosen.) and (3) PGB members also promise to give a patent non-assert very similar to our TC non-assert mode, with similar conditions and "outs" through their signing of the entity CLA.


In both places, the obligation is triggered by showing up and signing stuff. But they're separate, so existing TC members will need to RE-sign up to trigger their promises as to any future new material.


> Is the CLA a separate agreement covering the Open Project artifacts, and any standards track documents that arise from the Open Project still have to adhere to the current OASIS standards track IP rules?/

Yes, the CLA is a separate agreement covering OP contributions. The sponsors pick the license applicable to the project as part of the charter. When Open Project work goes into the standards track workflow (by being approved as a Project Specification), that work will be covered by the OP Process rules and the CLA; they will not have to do anything special to comply with TC IPR mode as well.Â


Let us know if this answers everything. Always happy to get on a call to discuss further.Â


Best regards,Â


/chetÂ


On Mon, Jan 14, 2019 at 10:15 AM Jim Amsden <
jamsden@us.ibm.com> wrote:
Carol,
I think we are getting close to being ready to commit to OSLC becoming an OASIS Open Project. We have a few remaining clarifications/questions/issues to resolve. I hope these are not blockers, but it would be nice to get some clarification/resolution as soon as possible.

1. Clarification: OASIS waiver of Project Backer fees for OSLC Open Project: ÂOASIS will waive the Backer fees for the organizations that are represented on the current OSLC MS StC for the foreseeable future, provided that those companies retain their OASIS Foundational Sponsor, Sponsor, or Contributor memberships. Organizations not represented on the current OSLC MS StC, including OSLC Member Section organizations that are not currently on the StC, will be able to become OSLC Project Backers and members of the PGB by paying the annual fees listed above.

2. Clarification: For practical and technical reasons, I propose that PROMCODE continue on its current standards track, maintaining its current TC and not be part of the OASIS OSLC Open Project.

3. Issue: All PGB members must sign the CLA regardless of whether or they they contribute content. This could create a legal hurdle for PGB members who wish to participate in project governance but may be unable to sign the CLA. Each of the current StC members will need to research this issue within their own organization to see if this is an issue for them.

For current OSLC TC members, what IP agreements already exist for OASIS specification contribution, and how does this relate to the CLA? Is the CLA a separate agreement covering the Open Project artifacts, and any standards track documents that arise from the Open Project still have to adhere to the current OASIS standards track IP rules?

4. Issue: We need to outline the process for publishing Open Project artifacts as OASIS standards track documents.

Our preferred approach would be to have the HTML source documents in the Git repo be the normative documents (since they are version managed), and to use ReSpec to provide an HTML representation of these documents for consumption. We would control the document file names and URL references in the Git repo, avoiding the creation of broken links in the publish step.

We would also like to maintain the specification track document lifecycles in the Git repo, using appropriate tags to designate the status of documents. Again, this links document status with preserved versions in the repo change history.

Could publishing the standards track documents with specific naming conventions, formats and/or MIME types in
docs.oasis-open.orgbe part of the Open Project core services provided by OASIS, and not be the responsibility of the PGB or TSC? This could be done with redirects or additional script automation to limit publishing errors.

5. Issue: We need to understand how the existing
open-services.netsite would be integrated with, linked to, be part of, etc. the OASIS OSLC Open Project. Would it be possible to use the current open-services.netsite as the Open Project site, and use a redirect to provide an additional URL alias for OASIS? This would leverage a lot of site development work and infrastructure that is already done.





Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575





From: Â Â Â Â
Carol Geyer <carol.geyer@oasis-open.org>
To: Â Â Â Â
oslc-sc@lists.oasis-open.org, OSLC Core TC <oslc-core@lists.oasis-open.org>, OASIS OSLC Domains TC Discussion List <oslc-domains@lists.oasis-open.org>
Cc: Â Â Â Â
TC Administrator <chet.ensign@oasis-open.org>, Scott McGrath <scott.mcgrath@oasis-open.org>
Date: Â Â Â Â
12/20/2018 01:29 PM
Subject: Â Â Â Â
[oslc-sc] Re: OASIS OSLC Open Project Proposal
Sent by: Â Â Â Â
<oslc-sc@lists.oasis-open.org>




OSLC StC and TCs,
We are excited by the possibility of transitioning the OSLC Member Section and TCs to an Open Project.Â

Our answers to your questions are in red below. We're happy to discuss on or in advance of the StC call on Jan 21.


On Mon, Dec 17, 2018 at 1:13 PM Jim Amsden <
jamsden@us.ibm.com> wrote:
The OASIS OSLC Membership Steering Committee (StC) proposes to migrate the current OASIS OSLC standardization activities to a new OASIS OSLC Open Project. The purposes of this migration are to:

* Engage a broader community in OSLC technical work by allowing participation and contribution from non-members without incurring dues or fees
* Increase OSLC adoption by encouraging more contribution, awareness and users
* Provide a context in which to develop related work products including open source reference implementations, sample applications, and other collateral that expand and complement the OASIS Standards track documents
* Simplify the infrastructure and processes for developing OASIS Standards
* Reduce fragmentation in the OSLC community by providing a central, world wide, respected organization in which to develop OSLC related work products

Specifically, the StC proposes the following:

1. Utilize the current StC members to form the initial OSLC Project Governing Board (PGB), retaining the current chair
2. The current Core and Domains TC members are merged and become the initial OSLC Technical Steering Committee, retaining the current chairs and cochairs.
3. The existing OSLC Core and Domains GitHub repositories will be migrated as is to the OSLC Open Project
4. The existing OSLC4JS project will also be migrated to the OSLC Open Project and will provide a code base that establishes a Statement of Use of the OSLC Standards and a code base for exploring and validating proposed changes to the standards
5. The existing eclipse/Lyo Open Source project at
eclipse.orgwill remain unchanged in order to leverage the eclipse governance process and Type B due diligence.

This proposal is subject to approval by the StC, with the decision scheduled to be addressed at the next StC meeting, Jan 21, 2019.

In order to facilitate the decision process, the StC would like clarification on the following questions.

1. What exactly are the Open Project fees and who pays them?


Open Project fees are used to fund core services provided by OASIS (legal, technical, and fiscal administration, basic marketing support, etc.).

Unlike OASIS TCs (which are funded by inclusive OASIS membership dues and where dues are required for technical participation), each Open Project is funded by fees paid by its own sponsoring organizations (we're calling these "Project Backers"). The funding provided by Project Backers enables anyone in the community to participate technically without paying dues.

Basic Project Backer fees are paid annually. The fees are scaled, based on the organizationâs employee headcount:

Â$ 25,000: 2,000+ employees

Â$ 15,000: 500-1,999 employees

Â$ 10,000: 100-499 employees

Â$ Â5,000: 10-99 employees

Â$ Â2,000: <10 employees

Â$ Â1,000: Nonprofit, university, local or non-OECD government

Project Backer organizations each receive a seat on the Project Governing Board (PGB) as well as exclusive visibility and promotional benefits.

For OSLC... if the StC and TCs decide in January to form the Open Project (in time for inclusion in OASISâ program roll-out in late March), OASIS will waive the Backer fees for the organizations that are represented on the current OSLC MS StC for the foreseeable future, provided that those companies retain their OASIS Foundational Sponsor, Sponsor, or Contributor memberships.

Organizations not represented on the current OSLC MS StC will be able to become OSLC Backers by paying the annual fees listed above.

Note: This offer covers core services provided by OASIS. If the OSLC PGB determines the need for supplemental activities (code auditing, event hosting, consultants, etc.), then additional funding will be required. OASIS staff will work with the OSLC PGB to determine its funding requirements and how to best meet them.



1.1. What are the startup and annual fees for an Open Project?

1.2. It is our understanding that the PGC requires a minimum threshold in annual sponsorship commitments by OASIS member companies. What is this minimum threshold?


Normally, OASIS requires new projects to identify commitments of at least $25,000 in annual Project Backers fees and at least two organizations for its PGB before it can be launched.

Current OASIS OSLC members will enjoy the fee waiver noted above, but still will need to have at least two organizations on its PGB. These may be either current MS StC organizations (holding OASIS Foundational, Sponsor, or Contributors membership) or new organizations that pay the annual OSLC Project Backer fee.



Â

1.3. What are OASIS members of the PGC expected to contribute to the Open Project fees?


Current OSLC MS organizations are not expected to contribute additional funding for the foreseeable future to cover the core services provided by OASIS. If the OSLC PGB decides supplemental activities/services are needed, fees may be necessary.

Â

1.4. What is the relationship between the OASIS member dues and Open Project fees?

That is, if an OASIS member company participates in many Open Projects that develop different OASIS Standards, will the member company have to pay OASIS membership fees as well as additional fees for each Open Project for which they are PGC members?


Technically, thereâs no relationship between OASIS membership and Open Project sponsorship. Each Open Project is funded by its own Project Backers. Â

In special cases, we may offer OASIS members a reduced or waived fee to become Project Backers for specific Open Projects (e.g., our current offering to OSLC MS members).


1.5. What happens of the member participation in the PGC falls below the minimum threshold, but there is still ongoing work by the Technical Steering Committee in the open source and/or specification deliverables?


The OP program is designed to gracefully degrade in such cases. If the OP no longer has at least two Project Backers:

Â


2. What are the rules for non-member participants, contributors, maintainers and PGB members?

2.1. Do non-members of either the Technical Steering Committee or Project Governing Board have voting rights?


Â

In keeping with common open source practices, Open Projects rules allow most decisions to be made by group consensus.

Members of the PGB approve major governance and advancement actions via ballot when needed.

Members of the Technical Steering Committee (TSC) are free to determine how to manage achieving consensus; voting is not required.



Â



2.2. How are these voting rights calculated? At the discretion of the PGB?



Decisions are made on the PGB by one-org/one-vote. Each Project Backer organization has one seat on the PGB. Â

TSC
members are selected for their technical contributions to the project, regardless of whether or not they are employed by Project Backers. Thisgives the project another opportunity for inclusive leadership.



2.3. Do all voting members have to sign the CLA (even if they don't contribute content)?


All PGB members must sign the CLA regardless of whether or not they contribute content.
Â


3. Regarding Legal entity, oversight, management of IP and licensing agreements, trademarks and copyrights: Specifically what services will OASIS provide in order to assess the IP of Open Project work products, including dependencies on components outside the project?

For example, open source projects often have dependencies on other open source projects. In order to assess IP exposure, it is typically necessary to examine all direct and transitive dependencies to ensure there are no licensing issues. This often requires code scans to detect potential issues. Will OASIS provide these services?



Upon request from a PGB, OASIS will contract with a third-party to provide code scan services. OASIS will work with the PGB to identify the provider and scope of service that best meets their projectâs needs.

Code scans are not included in the core services provided by OASIS for all Open Projects. The cost to provide this service will have to be covered by supplemental funding (e.g. fees for Project Backers).

If OSLC requires code scans, let us know as soon as possible. OASIS will work with the StC to determine specific needs, evaluate service provider options, and agree on how the cost will be covered.



4. Will the current OSLC TC GitHub repos, wikis and issues be migrated as is to the new open project?


Yes (assuming participants agree to re-contribute them). When the outgoing license is royalty-free, and the selected incoming FOSS license is reasonably permissive, itâs an easy ask from the participants. This is made even easier when a known, stable group is involved, as is the case with OSLC.

Â

4.1. Will there be any impact on existing TC work products?


Not on the TC-approved versions. Once a published OASIS Committee Specification, always a published OASIS Committee Specification.

Â

4.2. Will the open project specification template be different than what is currently being used by the OSLC TCs, and automated through ReSpec? We are trying to minimize spec rework and ReSpec updates.


Specification templates for Open Project work are based on the current TC templates. While there will be some labeling differences, rework will be minimal.

Â

4.3. The Open Project specification lifecycle appears to require statements of use before public review. What are the implications for OSLC Domain and Core TC documents that are already in progress?


Open Projects Specifications only require public reviews and Statements of Use when they move forward as Candidate OASIS Standards (in the same way a TC would proceed). SoU are not required for a public review. Migrating to Open Projects should have little effect on existing work. Â
ÂÂ



4.4. Are there any changes in how Open Project standards track work products are published by OASIS?

Specifically I'm trying to understand if the issue we had with document relative links being broken by the OASIS publishing process will be resolved by migrating to an Open Project so that we don't have do the work to modify ReSpec to fix up links on document publish.



The specifics on this are TBD, but we are confident we can work out an arrangement where the canonical standard lives on the OP repo with a backup verified copy on
docs.oasis-open.org.



5. What are the hosting constraints and any additional costs associated with utilizing the Open Project Web site?

We have just deployed a new
open-servicers.netsite. This site was developed using HUGO (https://gohugo.io). Can we continue using this technology and URL for the Open Project web site? Note that it is necessary to preserve the open-service.netdomain since the OSLC namespaces utilize this domain name for backward compatibility and access to machine readable vocabulary documents.



Details on this will require investigation, but we donât expect a problem. We will want to add boilerplate text and minimal branding to the site, and some kind of linking or mirroring so that material cross-references into OASIS resources. Staying with this current infrastructure and URLs will make life easier for all of us.



Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575




--

Carol Geyer

Chief Development Officer
Open Source and Standards Communities

OASIS








--

/chetÂ
----------------
Chet Ensign

Chief Technical Community Steward

OASIS: Advancing open standards for the information society

http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â




--

/chetÂ
----------------

Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society

http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â[attachment "OSLC-Open-Project-transition.docx" deleted by Jim Amsden/Raleigh/IBM]





--

/chetÂ
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]