ONC: Add IPConfigType.

ONC: Add IPConfigType.

BUG=

[pneubeck (no reviews), 2014-11-29 12:33:33]

Patchset #1 (id:1) has been deleted

[pneubeck (no reviews), 2014-11-29 12:36:59]

pneubeck@chromium.org changed reviewers:
+ stevenjb@chromium.org

[pneubeck (no reviews), 2014-11-29 12:36:59]

@Steven,
this is how I imagined to distinguish Automatic and Static IPConfig.
Does this look right to you?

[pneubeck (no reviews), 2014-11-29 15:48:05]

Patchset #1 (id:20001) has been deleted

[stevenjb, 2014-12-01 18:29:45]

LGTM

This looks fine, and I very much appreciate you doing the legwork (I never would
have successfully dotted all of the ONC i's or crossed all of the t's).

My only reservation is that we now have extra opportunities for
inconsistent/invalid configurations (i.e. if the type is set to DHCP and a
static config is provided or vice versa), and Shill will "lose" any static
configuration provided if the type is set to DHCP, but that's probably fine and
this is certainly more explicitly clear.

[stevenjb, 2014-12-04 00:14:30]

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
File components/onc/docs/onc_spec.html (right):

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
components/onc/docs/onc_spec.html:259: <span class="value">DHCP</span>)
Actually, e.g., ethernet.onc contains a StaticIPConfig entry, but no
IPConfigType. Should that be valid, i.e. should the presence of a StaticIPConfig
struct imply IPConfigType = 'Static' if not specified? 

The thing that makes this complicated is the need (or at least, desire) to
support partial ONC configurations. We are kind of committed to that since
networkingPrivate supports it in the API description and I believe that existing
extensions already make use of that. It is certainly more convenient than
requiring a round trip + merge resolution with existing settings.

So, I believe there are three valid scenarios we need to consider:

a) IPConfigType = DHCP : Clear any existing StaticIPConfig properties.
StaticIPConfig must not be present.
b) IPConfigType = Static: Apply the StaticIPConfig properties which must be
valid.
c) IPConfigType unspecified, StaticIPConfig exists: treat as (b).
d) IPConfigType unspecified, no StaticIPConfig entry: No change to the current
configuration.

If we want to support c), I believe that IPConfigType needs to default to
undefined instead of 'DHCP'.

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
components/onc/docs/onc_spec.html:285: <span class="value">DHCP</span>)
Shouldn't this be Static?

[pneubeck (no reviews), 2014-12-04 12:17:42]

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
File components/onc/docs/onc_spec.html (right):

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
components/onc/docs/onc_spec.html:259: <span class="value">DHCP</span>)
On 2014/12/04 00:14:30, stevenjb wrote:
> Actually, e.g., ethernet.onc contains a StaticIPConfig entry, but no
> IPConfigType. Should that be valid, i.e. should the presence of a
StaticIPConfig
> struct imply IPConfigType = 'Static' if not specified? 

Depending on the source/usage of ONC, we remove 'irrelevant'
values/subdictionaries.
The Validator doesn't care about 'irrelevant' or 'ignored' fields, it also
doesn't remove them.
The Normalizer takes care of removing these irrelevant fields and is applied for
example to policies.

Currently, we apply the Normalizer to any ONC before we convert it to the Shill
dictionary (e.g. in CreateShillConfiguration:
https://code.google.com/p/chromium/codesearch#chromium/src/chromeos/network/p...)
One reason for that was: if a 'type' field changes (e.g. EAP type), any
properties that were required by the old type shouldn't be written anymore to
Shill, independent on whether we remember the old properties for the user or
not.
Similarly, we could end-up in situations where the user setting says
'EAP.Outer=LEAP' and the policy says 'EAP.Outer=EAP-TLS', in which case LEAP
specific settings shouldn't be sent to Shill.

> The thing that makes this complicated is the need (or at least, desire) to
> support partial ONC configurations. We are kind of committed to that since
> networkingPrivate supports it in the API description and I believe that
existing
> extensions already make use of that. It is certainly more convenient than
> requiring a round trip + merge resolution with existing settings.
Supporting partial updates to consumers of the API, I think, is fine.
But just sending these partial dictionaries to Shill is AFAIU rather difficult,
the moment policies come into play. We could have different control flows
depending on whether a policy exists or not, but I think that would be an
avoidance strategy rather than a solution.

I didn't finish that implementation, but my original plan was to handle a
SetProperties call by:
1) obtain the old user settings
2) merge the new (partial) user settings update with the old user settings
3) merge with policy
4) convert to Shill and send to Shill. This step should include any cleanup work
like the 'Clear IPConfig' mechanism or the ONCNormalizer that removes
irrelevant/ignored fields.

Step 1) and 2) are not implemented. I didn't get to it and wanted to discuss
this with you further when I'm in MTV.

One nice side effect would be that you can very easily compare the old and the
new ONC settings and trigger ipconfig updates.

> 
> So, I believe there are three valid scenarios we need to consider:
> 
> a) IPConfigType = DHCP : Clear any existing StaticIPConfig properties.
> StaticIPConfig must not be present.
> b) IPConfigType = Static: Apply the StaticIPConfig properties which must be
> valid.
> c) IPConfigType unspecified, StaticIPConfig exists: treat as (b).
> d) IPConfigType unspecified, no StaticIPConfig entry: No change to the current
> configuration.

IMO, a partial update can be partial in every sense. The partial update should
simply be merged with old settings and policy.
After the merging however, the settings must be sufficiently complete. E.g. the
IPConfigType=Static could have come from policy and the user only has to specify
the content of StaticIPConfig.

I think we should not support c) _after_ we merged the settings, because then we
would be back to the problem of how to transition from Static to DHCP settings
and we would again have to consider special 'NULL' values which we already found
out to be in conflict with Recommended policy settings.

> 
> If we want to support c), I believe that IPConfigType needs to default to
> undefined instead of 'DHCP'.

It must default to DHCP because that is the current behavior of policy that we
have to continue to support.

https://codereview.chromium.org/750313003/diff/40001/components/onc/docs/onc_...
components/onc/docs/onc_spec.html:285: <span class="value">DHCP</span>)
On 2014/12/04 00:14:30, stevenjb wrote:
> Shouldn't this be Static?

doh, of course,

[stevenjb, 2014-12-04 18:23:28]

On Thu, Dec 4, 2014 at 4:17 AM, <pneubeck@chromium.org> wrote:

>
> ...
>
> I didn't finish that implementation, but my original plan was to handle
> a SetProperties call by:
> 1) obtain the old user settings
> 2) merge the new (partial) user settings update with the old user
> settings
> 3) merge with policy
> 4) convert to Shill and send to Shill. This step should include any
> cleanup work like the 'Clear IPConfig' mechanism or the ONCNormalizer
> that removes irrelevant/ignored fields.
>
> Step 1) and 2) are not implemented. I didn't get to it and wanted to
> discuss this with you further when I'm in MTV.
>
> One nice side effect would be that you can very easily compare the old
> and the new ONC settings and trigger ipconfig updates.
>
> While this sounds reasonable in theory, I am concerned about our ability
to maintain that. The translation code is already pretty complicated;
ensuring that all round trip configurations are complete and valid may
prove... daunting. Especially since we don't currently run any tests with
an actual Shill instance (which would be great to change, and essential if
we want to maintain that model, but... also challenging).



>
>>  If we want to support c), I believe that IPConfigType needs to default
>>
> to
>
>> undefined instead of 'DHCP'.
>>
>
> It must default to DHCP because that is the current behavior of policy
> that we have to continue to support.
>
>
Here is the implementation we currently have in onc_to_shill:
* If IPConfigType == DHCP, clear static properties
* If a StaticIPConfig object exists, set the properties (overriding any
prior clear)

So, even though the default is DHCP, the presence of StaticIPConfig will
effectively override that.

If we require (IPConfigType == Static) we will break any existing configs
that have a StaticIPConfig object but do not specify IPConfigType.

Whereas, if IPConfigType defaults to 'undefined', and the *behavior* defaults
to DHCP, then we are OK - existing configurations that do not specify
either will use DHCP, and existing configurations that define
StaticIPConfig but not IPConfigType will use the static config.

That said, it looks like in
onc_to_shill, LocalTranslator::TranslateNetworkConfiguration(),
if IPConfigType is not set, it is in fact *undefined*, i.e. we don't
actually fill in default values, so (IPConfigType == 'DHCP') is false and
the code behaves as we need it to (the Shill StaticIPConfig properties are
neither set nor cleared).

So, maybe we are actually on the same page but thinking about it (or at
least describing it) differently.

Regardless, I think the documentation could use some clarification, all
things considered :)

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[pneubeck (no reviews), 2014-12-04 18:47:04]

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
File chromeos/network/onc/onc_normalizer.cc (right):

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
chromeos/network/onc/onc_normalizer.cc:184:
::onc::network_config::kStaticIPConfig,
this line should remove a 'irrelevant' StaticIPConfig in every flow that goes
through MNCH before we sent a configuration to Shill.

[pneubeck (no reviews), 2014-12-04 18:52:29]

On 2014/12/04 18:23:28, stevenjb wrote:
> On Thu, Dec 4, 2014 at 4:17 AM, <mailto:pneubeck@chromium.org> wrote:
> 
> >
> > ...
> >
> > I didn't finish that implementation, but my original plan was to handle
> > a SetProperties call by:
> > 1) obtain the old user settings
> > 2) merge the new (partial) user settings update with the old user
> > settings
> > 3) merge with policy
> > 4) convert to Shill and send to Shill. This step should include any
> > cleanup work like the 'Clear IPConfig' mechanism or the ONCNormalizer
> > that removes irrelevant/ignored fields.
> >
> > Step 1) and 2) are not implemented. I didn't get to it and wanted to
> > discuss this with you further when I'm in MTV.
> >
> > One nice side effect would be that you can very easily compare the old
> > and the new ONC settings and trigger ipconfig updates.
> >
> > While this sounds reasonable in theory, I am concerned about our ability
> to maintain that. The translation code is already pretty complicated;
> ensuring that all round trip configurations are complete and valid may
> prove... daunting. Especially since we don't currently run any tests with
> an actual Shill instance (which would be great to change, and essential if
> we want to maintain that model, but... also challenging).

The UI already relies on exactly this round-trip.
Note also that what I propose makes the round-trip _less_ complex, because I
want to store the user settings as ONC. That means, we don't have to rely so
much on the translation from Shill to ONC (only to support user settings from
old ChromeOS versions).

> 
> 
> 
> >
> >>  If we want to support c), I believe that IPConfigType needs to default
> >>
> > to
> >
> >> undefined instead of 'DHCP'.
> >>
> >
> > It must default to DHCP because that is the current behavior of policy
> > that we have to continue to support.
> >
> >
> Here is the implementation we currently have in onc_to_shill:
> * If IPConfigType == DHCP, clear static properties
> * If a StaticIPConfig object exists, set the properties (overriding any
> prior clear)
> 
> So, even though the default is DHCP, the presence of StaticIPConfig will
> effectively override that.
> 
> If we require (IPConfigType == Static) we will break any existing configs
> that have a StaticIPConfig object but do not specify IPConfigType.
> 
> Whereas, if IPConfigType defaults to 'undefined', and the *behavior* defaults
> to DHCP, then we are OK - existing configurations that do not specify
> either will use DHCP, and existing configurations that define
> StaticIPConfig but not IPConfigType will use the static config.
> 
> That said, it looks like in
> onc_to_shill, LocalTranslator::TranslateNetworkConfiguration(),
> if IPConfigType is not set, it is in fact *undefined*, i.e. we don't
> actually fill in default values, so (IPConfigType == 'DHCP') is false and
> the code behaves as we need it to (the Shill StaticIPConfig properties are
> neither set nor cleared).
That's right. I actually thought a while about this and the current patch is, I
think, consistent with other places, i.e. onc_to_shill translator just
translates exactly the parts of ONC that are provided in the input.
This is only required if the translator should be useable for partial ONCs. If
we change to the full Shill updates that I proposed above, then we can either
fail on an incomplete ONC or translate it to the defaults.

> 
> So, maybe we are actually on the same page but thinking about it (or at
> least describing it) differently.
> 
> Regardless, I think the documentation could use some clarification, all
> things considered :)
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[stevenjb, 2014-12-04 18:54:44]

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
File chromeos/network/onc/onc_normalizer.cc (right):

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
chromeos/network/onc/onc_normalizer.cc:184:
::onc::network_config::kStaticIPConfig,
On 2014/12/04 18:47:04, pneubeck wrote:
> this line should remove a 'irrelevant' StaticIPConfig in every flow that goes
> through MNCH before we sent a configuration to Shill.

Then I'm confused why the translation of ethernet.onc doesn't fail since it
doesn't specify IPConfigType?

[pneubeck (no reviews), 2014-12-04 18:59:52]

On 2014/12/04 18:54:44, stevenjb wrote:
>
https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
> File chromeos/network/onc/onc_normalizer.cc (right):
> 
>
https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
> chromeos/network/onc/onc_normalizer.cc:184:
> ::onc::network_config::kStaticIPConfig,
> On 2014/12/04 18:47:04, pneubeck wrote:
> > this line should remove a 'irrelevant' StaticIPConfig in every flow that
goes
> > through MNCH before we sent a configuration to Shill.
> 
> Then I'm confused why the translation of ethernet.onc doesn't fail since it
> doesn't specify IPConfigType?

the test that you're referring to is testing the onc_translator directly. The
translator translates whatever you through at it. I.e. a StaticIPConfig is
translated if it exists in the input.
Also if there would be both a VPN and a Wifi entry, it should translate both
currently.

The normalizer is only used by MNCH to remove 'redundant' entries. If we would
run the same test by using MNCH::SetProperties, it would fail.

[stevenjb, 2014-12-04 19:28:01]

I see. That's a bit confusing.

So, with this change,  existing configurations (which I believe do go
through MNCH) that define StaticIPConfig but not IPConfigType will fail.
This isn't a problem for Settings since we can always set that, but won't
there be backwards compatibility problems with existing ONC files?


On Thu, Dec 4, 2014 at 10:59 AM, <pneubeck@chromium.org> wrote:

> On 2014/12/04 18:54:44, stevenjb wrote:
>
> https://codereview.chromium.org/750313003/diff/60001/
> chromeos/network/onc/onc_normalizer.cc
>
>> File chromeos/network/onc/onc_normalizer.cc (right):
>>
>
>
> https://codereview.chromium.org/750313003/diff/60001/
> chromeos/network/onc/onc_normalizer.cc#newcode184
>
>> chromeos/network/onc/onc_normalizer.cc:184:
>> ::onc::network_config::kStaticIPConfig,
>> On 2014/12/04 18:47:04, pneubeck wrote:
>> > this line should remove a 'irrelevant' StaticIPConfig in every flow that
>>
> goes
>
>> > through MNCH before we sent a configuration to Shill.
>>
>
>  Then I'm confused why the translation of ethernet.onc doesn't fail since
>> it
>> doesn't specify IPConfigType?
>>
>
> the test that you're referring to is testing the onc_translator directly.
> The
> translator translates whatever you through at it. I.e. a StaticIPConfig is
> translated if it exists in the input.
> Also if there would be both a VPN and a Wifi entry, it should translate
> both
> currently.
>
> The normalizer is only used by MNCH to remove 'redundant' entries. If we
> would
> run the same test by using MNCH::SetProperties, it would fail.
>
> https://codereview.chromium.org/750313003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-12-04 19:32:33]

On Thu, Dec 4, 2014 at 8:28 PM, Steven Bennetts <stevenjb@chromium.org>
wrote:

> I see. That's a bit confusing.
>
> So, with this change,  existing configurations (which I believe do go
> through MNCH) that define StaticIPConfig but not IPConfigType will fail.
> This isn't a problem for Settings since we can always set that, but won't
> there be backwards compatibility problems with existing ONC files?
>
Which files would that be?
The only thing that should currently officially (or in production) write
ONC is policy and policy does not support StaticIPConfig but only automatic
one (note: it forces automatic configuration).

If I'm missing something here, then yes, we would have to rethink for
backwards compatibility.


>
>
> On Thu, Dec 4, 2014 at 10:59 AM, <pneubeck@chromium.org> wrote:
>
>> On 2014/12/04 18:54:44, stevenjb wrote:
>>
>> https://codereview.chromium.org/750313003/diff/60001/
>> chromeos/network/onc/onc_normalizer.cc
>>
>>> File chromeos/network/onc/onc_normalizer.cc (right):
>>>
>>
>>
>> https://codereview.chromium.org/750313003/diff/60001/
>> chromeos/network/onc/onc_normalizer.cc#newcode184
>>
>>> chromeos/network/onc/onc_normalizer.cc:184:
>>> ::onc::network_config::kStaticIPConfig,
>>> On 2014/12/04 18:47:04, pneubeck wrote:
>>> > this line should remove a 'irrelevant' StaticIPConfig in every flow
>>> that
>>>
>> goes
>>
>>> > through MNCH before we sent a configuration to Shill.
>>>
>>
>>  Then I'm confused why the translation of ethernet.onc doesn't fail since
>>> it
>>> doesn't specify IPConfigType?
>>>
>>
>> the test that you're referring to is testing the onc_translator directly.
>> The
>> translator translates whatever you through at it. I.e. a StaticIPConfig is
>> translated if it exists in the input.
>> Also if there would be both a VPN and a Wifi entry, it should translate
>> both
>> currently.
>>
>> The normalizer is only used by MNCH to remove 'redundant' entries. If we
>> would
>> run the same test by using MNCH::SetProperties, it would fail.
>>
>> https://codereview.chromium.org/750313003/
>>
>
>
Google Germany GmbH
Dienerstraße 12
80331 München
Deutschland

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[stevenjb, 2014-12-05 00:37:08]

Note: I think this CL will need to be rebased.

This won't be completely correct until I land my CL, but nothing should break
(any more than things currently are) with the change I suggested.

LGTM with the suggested change.

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
File chromeos/network/onc/onc_translator_onc_to_shill.cc (right):

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
chromeos/network/onc/onc_translator_onc_to_shill.cc:273:
base::Value::CreateNullValue());
So, this it turns out is incorrect. When setting kStaticIPConfigProperty, we
need to either specify the complete object, or clear the property if the
dictionary is empty.

I have a CL that addresses this (it gets a little tricky with NameServers), but
the most correct thing to do in this CL is:

if (ipconfig_type == ::onc::network_config::kIPConfigTypeDHCP) {
     shill_dictionary_->SetWithoutPathExpansion(shill::kStaticIPConfigProperty,
                                             base::Value::CreateNullValue());
}

That will simplify my merge once this CL has landed.

[stevenjb, 2014-12-05 01:11:47]

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
File chromeos/network/onc/onc_normalizer.cc (right):

https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
chromeos/network/onc/onc_normalizer.cc:184:
::onc::network_config::kStaticIPConfig,
On 2014/12/04 18:54:44, stevenjb wrote:
> On 2014/12/04 18:47:04, pneubeck wrote:
> > this line should remove a 'irrelevant' StaticIPConfig in every flow that
goes
> > through MNCH before we sent a configuration to Shill.
> 
> Then I'm confused why the translation of ethernet.onc doesn't fail since it
> doesn't specify IPConfigType?
> 

I just realized that this is potentially confusing if a configuration only
specifies specific NameServers, e.g.:

StaticIPConfig: {
  NameServers = [ "8.8.4.4" ]
}

In this case, IPConfigType will need to be 'Static', even though the IPAddress
is not set (which will cause Shill to use DHCP for the IP address). This seems
OK, and works fine for the Settings code, but we might want to make that clear
in the spec.

[pneubeck (no reviews), 2014-12-05 10:25:01]

On 2014/12/05 01:11:47, stevenjb wrote:
>
https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
> File chromeos/network/onc/onc_normalizer.cc (right):
> 
>
https://codereview.chromium.org/750313003/diff/60001/chromeos/network/onc/onc...
> chromeos/network/onc/onc_normalizer.cc:184:
> ::onc::network_config::kStaticIPConfig,
> On 2014/12/04 18:54:44, stevenjb wrote:
> > On 2014/12/04 18:47:04, pneubeck wrote:
> > > this line should remove a 'irrelevant' StaticIPConfig in every flow that
> goes
> > > through MNCH before we sent a configuration to Shill.
> > 
> > Then I'm confused why the translation of ethernet.onc doesn't fail since it
> > doesn't specify IPConfigType?
> > 
> 
> I just realized that this is potentially confusing if a configuration only
> specifies specific NameServers, e.g.:
> 
> StaticIPConfig: {
>   NameServers = [ "8.8.4.4" ]
> }
> 
> In this case, IPConfigType will need to be 'Static', even though the IPAddress
> is not set (which will cause Shill to use DHCP for the IP address). This seems
> OK, and works fine for the Settings code, but we might want to make that clear
> in the spec.

Yes, I realized that during the discussion in your CL as well.
Shall we change IPConfigType to IPAddressType + NameserverType ?

[stevenjb, 2014-12-05 18:23:59]

Yeah, this is all giving me a headache. I've flip flopped a couple of times
now in my thinking. Now I'm thinking that, since we are now setting
StaticIPConfig as an object in Shill, maybe we don't actually need
IPConfigType, i.e:

To specify both static IP address and name servers:
StaticIPConfig = { IPAddress = "foo", NameServers = "bar" }

To specify a static IP address with automatic name servers:
StaticIPConfig = { IPAddress = "foo" }

To specify specific name servers with automatic IP address:
StaticIPConfig = { NameServers = "bar" }

To specify automatic IP Address and name servers:
StaticIPConfig = {}

To specify neither, i.e. leave the settings unchanged, do not provide
StaticIPConfig.

We would not support changing just IP address config or just name server
config; to set one both must be specified.

WDYT?

(It may just make sense to discuss this in person when you are here. I'll
set up a time and start an agenda).


On Fri, Dec 5, 2014 at 2:25 AM, <pneubeck@chromium.org> wrote:

> On 2014/12/05 01:11:47, stevenjb wrote:
>
> https://codereview.chromium.org/750313003/diff/60001/
> chromeos/network/onc/onc_normalizer.cc
>
>> File chromeos/network/onc/onc_normalizer.cc (right):
>>
>
>
> https://codereview.chromium.org/750313003/diff/60001/
> chromeos/network/onc/onc_normalizer.cc#newcode184
>
>> chromeos/network/onc/onc_normalizer.cc:184:
>> ::onc::network_config::kStaticIPConfig,
>> On 2014/12/04 18:54:44, stevenjb wrote:
>> > On 2014/12/04 18:47:04, pneubeck wrote:
>> > > this line should remove a 'irrelevant' StaticIPConfig in every flow
>> that
>> goes
>> > > through MNCH before we sent a configuration to Shill.
>> >
>> > Then I'm confused why the translation of ethernet.onc doesn't fail
>> since it
>> > doesn't specify IPConfigType?
>> >
>>
>
>  I just realized that this is potentially confusing if a configuration only
>> specifies specific NameServers, e.g.:
>>
>
>  StaticIPConfig: {
>>    NameServers = [ "8.8.4.4" ]
>> }
>>
>
>  In this case, IPConfigType will need to be 'Static', even though the
>> IPAddress
>> is not set (which will cause Shill to use DHCP for the IP address). This
>> seems
>> OK, and works fine for the Settings code, but we might want to make that
>> clear
>> in the spec.
>>
>
> Yes, I realized that during the discussion in your CL as well.
> Shall we change IPConfigType to IPAddressType + NameserverType ?
>
> https://codereview.chromium.org/750313003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.