Skip to content

Include API incubation in charter scope for Cloud-Edge-Client Coordination CG #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Include API incubation in charter scope for Cloud-Edge-Client Coordination CG #24

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions proposals/cloudedgeclientCG/charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
## {Draft} : CLOUD-EDGE-CLIENT COORDINATION COMMUNITY GROUP
## {Draft} : CLOUD-EDGE-CLIENT COORDINATION COMMUNITY GROUP

## Short name: CloudEdge

Expand All @@ -13,7 +13,7 @@ The mission of this group is to provide mechanisms and interfaces between Centra
## Scope of Work
This group aims to discuss proposals for Client-Edge-Cloud coordination, including:
* Use cases and requirements for Client-Edge-Cloud coordination
* Proposals for APIs and mechanisms that enable computing workload offloading and orchestration between Central Cloud, Edge Cloud, and Client
* Proposal, design, and incubation of APIs and mechanisms that enable computing workload offloading and orchestration between Central Cloud, Edge Cloud, and Client.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think API incubation is not outside of scope for CGs in general.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's still something to clarify, as the current draft (and #25) says the group won't produce specifications (and it certainly can't produce Recommendation track specs), but does the group intend to work on API designs, or stop at use cases and requirements?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 - I think the group should include producing specifications in its scopes (even though they would obviously not be standards-track at that stage yet); L34 forbids it at the moment, which I don't think it should

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the group intend to work on API designs

The group needs to decide that. There are several APIs that have been incubated/developed in a CG (whether it continued or not on the standardization track) - but keep in mind the difference between CG vs. WG, and also these notes:
https://www.w3.org/standards/types/#x2-pre-standardization-proposals-notes
https://www.w3.org/policies/process/
When an API reaches a certain maturity, it makes sense to continue developing it in a WG on the standardization track.
But the proposed formulation for incubating API development is fine for a CG.

* Secure networking and trust model requirements in the context of edge computing and offload to edge.

## Out of Scope
Expand Down