Is there a reason for networkConfig over just network?

We already have system.network.

Also, I don't like just 'network' because 'network' often refers to
"network traffic" or "network communication" instead of "configuring an
Ethernet, WiFi, or Cellular network".

'networking' would be a little better, but we already have
'networking.config' (a public API used for configuring captive portals).

Another option might be networking.privelagedConfig, but that's a mouthful.

I think that networkConfig is the least confusing, reasonably succinct
option.

names are hard. :/

The fact that we would have a networkConfig and networking.config makes me more than a little sad.  Hmm...

Yeah. networking.config was kind of unfortunate.

Part of me likes leveraging the 'networking' namespace, assuming we can
have both whitelisted/kiosk and public apis within a namespace and are OK
with that.

Hmmm... how about networking.onc? The networkingPrivate API was designed to
conform with the ONC
<https://www.chromium.org/chromium-os/chromiumos-design-docs/open-network-configuration>
(open network configuration) spec. It's short, leverages an existing
namespace, and isn't any more confusing than the alternatives...

I like the idea of leveraging the networking namespace, too.

I'm ok with networking.onc - it probably does not describe the API ideally, but I can't think of a better alternative at the moment.

networking.onc at least means we only have one networking namespace-y thing.  I have no knowledge of network standards, so I don't know if onc is going to be understood by most people, but I'll defer to Steven's expertise.  If everyone's okay with that, it sounds better to me than the alternatives.

rdevlin@ - Do you forsee any problems with networking.config = public and
networking.onc = kiosk/webui/whitelist only?

If not, then my recommendation is that we go with networking.onc.

This is an API that changes networking configuration. I am still not completely sure what is wrong with just calling it chrome.networkConfig.

To summarize the discussion above:

If we introduce chrome.networkConfig, we would have:

chrome.networkConfig (kiosk/webui)
chrome.networking.config (public, used to configure captive portals)
chrome.system.network (public)

Some of us feel that would be confusing. The alternate proposal is:

chrome.networking.onc (kiosk/webui)
chrome.networking.config (public)
chrome.system.network (public)

That would at least group the two network configuration APIs under chrome.networking.

Right, chrome.networking.config...

Since 'these' specific set of calls are ONC compliant, putting them in chrome.networking.onc seems fine.

For any other networking config calls we add (which are not necessarily onc compliant), I am okay with just adding our methods under chrome.networking.config.

As Devlin has pointed out before, the pattern of having certain methods available for only specific conditions (till now, OS, channel, etc, now sessions) is prevalent in the chrome API.


So for these specific APIs, chrome.networking.onc.
Any additional APIs not following the ONC spec, chrome.networking.config

SG?

Well, without having any sense of what "Any additional APIs not following the ONC spec" might be, I would suggest that we judge them on a case by case basis.

Certainly any non privileged (public) configuration related APIs would make sense to add to networking.config. (I believe that was the idea when the API was developed).

For any networking related non-configuration privileged API methods, we would probably want to use a new networking.foo namespace.

Again, we can cross that bridge when we get there.

Ideally we should be using chrome.networking.config.onc.* for these APIs, but, that does seem a bit excessive.

re #12: Not only excessive, but also not possible (afaik, extension bindings do not support nested APIs)

We can't use networking.config as both an API name and a namespace, but even if we could I think that would be unnecessarily verbose (and redundant - onc stands for open network configuration).

I think that the idea here is that "networking" will be used for things related to managing networks, i.e. wifi / EAP / etc configuration, connect and disconnect, captive portals, etc.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/975d838eca97d3cac1578861c9df42fe46e2a9d5

commit 975d838eca97d3cac1578861c9df42fe46e2a9d5
Author: tbarzic <tbarzic@chromium.org>
Date: Wed Dec 14 19:12:35 2016

Introduces alias networking.onc for networkingPrivate API.

Adds networking.onc permission, which guards the introduced
networking.onc alias - for now, the permission is bound to dev channel
and available to the same whitelist as networkingPrivate API.

To avoid duplicating whitelist for the two permissions, the whitelist
is moved to behavior features and the behavior feature is added as a
dependency for both of them.

Refactors networking private API tests to enable parameterizing the
networking API to be used in the test and adds tests that exercise
alias - networking.onc code path.
Also groups some sub tests (which were all run in a separate browser
test) together in order to reduce total overhead of starting browser
for browser tests.

This is the first step towards renaming networkingPrivate API to
networking.onc (which will be made available to kiosk sessions).

BUG=672186

Review-Url: https://codereview.chromium.org/2470193002
Cr-Commit-Position: refs/heads/master@{#438574}

[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/browser/extensions/api/networking_private/networking_private_chromeos_apitest.cc
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/common/extensions/permissions/chrome_permission_message_rules.cc
[add] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/test/data/extensions/api_test/networking_private/alias/manifest.json
[add] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/test/data/extensions/api_test/networking_private/alias/test.js
[delete] https://crrev.com/ad3ee42510afda09e00cb73c694bfa4626980d1d/chrome/test/data/extensions/api_test/networking_private/chromeos/main.html
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/test/data/extensions/api_test/networking_private/chromeos/manifest.json
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/chrome/test/data/extensions/api_test/networking_private/chromeos/test.js
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/api/_api_features.json
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/api/_behavior_features.json
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/api/_permission_features.json
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/extension_api.cc
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/features/behavior_feature.cc
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/features/behavior_feature.h
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/permissions/api_permission.h
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/extensions/common/permissions/extensions_api_permissions.cc
[modify] https://crrev.com/975d838eca97d3cac1578861c9df42fe46e2a9d5/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1

commit c1e3e116e8b8b3fd88eade4dae3521354ff8efd1
Author: tbarzic <tbarzic@chromium.org>
Date: Wed Dec 21 18:41:02 2016

Remove networking API permissions depdendency on behavior feature

Docs server does not handle API dependency on behavior features, so
having networkingPrivate and networking.onc depend on a behavior
feature to provide white list breaks docserver preview.py.
To avoid the issue, replicate whitelists in _permission_features file
for each of the permissions.

BUG= 676105 ,672186

Review-Url: https://codereview.chromium.org/2592613003
Cr-Commit-Position: refs/heads/master@{#440164}

[modify] https://crrev.com/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1/extensions/common/api/_behavior_features.json
[modify] https://crrev.com/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1/extensions/common/api/_permission_features.json
[modify] https://crrev.com/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1/extensions/common/extension_api.cc
[modify] https://crrev.com/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1/extensions/common/features/behavior_feature.cc
[modify] https://crrev.com/c1e3e116e8b8b3fd88eade4dae3521354ff8efd1/extensions/common/features/behavior_feature.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7628154b26186300379aa54027d019dd186f657d

commit 7628154b26186300379aa54027d019dd186f657d
Author: tbarzic <tbarzic@chromium.org>
Date: Fri Jan 13 20:38:16 2017

Enable networking.onc for autolaunched kiosk sessions (on dev)

Enables networking.onc alias for networkingPrivate in kiosk sessions,
modulo few methods, whose implementation will keep requiring
networkingPrivate permissions (i.e. will be available only to
whitelisted set of apps). Methods in question are:
* deprecated methods - getVisibleNetworks
                     - getEnabledNetworkTypes
* Chromecast specific methods (so they can be moved to a separate
  namespace)
    - verifyDestination
    - verifyAndEncryptCredentials
    - verifyAndEncryptData
    - setWifiTDLSEnabledState
    - getWifiTDLSStatus

BUG=672186

Review-Url: https://codereview.chromium.org/2628673002
Cr-Commit-Position: refs/heads/master@{#443652}

[modify] https://crrev.com/7628154b26186300379aa54027d019dd186f657d/chrome/test/data/extensions/api_test/networking_private/alias/test.js
[modify] https://crrev.com/7628154b26186300379aa54027d019dd186f657d/extensions/browser/api/networking_private/networking_private_api.cc
[modify] https://crrev.com/7628154b26186300379aa54027d019dd186f657d/extensions/common/api/_permission_features.json

Am I correct in understanding that networkingPrivate is not currently being renamed to, but simply aliased as, networking.onc?  And that the rename will occur later?  Will existing occurrences of networkingPrivate get replaced at that time?  I'm specifically interested in:

https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/connectivity_diagnostics/manifest.json

and

https://developer.chrome.com/extensions/networkingPrivate

(because they're both referenced in the CrOS PDD).

It's *being* renamed, but current state is that both networkingPrivate and networking.onc exist (networking.onc aliasing networkingPrivate) so the current networkingPrivate usages can be updated.

The plan is to replace existing occurrences of networkingPrivate with networking.onc (after networking.onc is enabled on stable) and eventually completely remove networkingPrivate.

Ok,got it, thanks!  I'll keep an eye on those two docs for changes, and update the PDD when needed.