Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

William Lupton  wrote:
> So could “being writable” be associated with a feature (which might
> potentially apply to multiple such nodes)? W.

We can put a if-feature statement on the node 'mfg-name' in the config
tree, but not in the state tree.

But the issue is that there are two conflicting use cases:

  1)  use the writable nodes for validation with the real hw
  2)  use the writable nodes as a "post-it" function

Currently the only such node is 'serial-num', and it is used as (2).

But maybe we can actually combine these two cases.

  If the node has a value in the config, and the system can detect the
  real value from the hardware, then they MUST be equal, otherwise the
  config is not applied. (case (1) above)

  If the node has a value in the config, and the system cannot detect
  the real value from the hardware, the config is applied and the
  state value will be the config value. (case (2) above)

Maybe this violates the principle of least astonishment though...


/martin


> 
> (and if so, what’s the cleanest way to achieve this? it seems that
> “if-feature” can’t be used with “config” but that it could be used by
> refining a grouping?)
> 
> > On 22 Dec 2016, at 05:14, Randy Presuhn
> >  wrote:
> > 
> > Hi -
> > 
> > On 12/21/2016 6:56 AM, Martin Bjorklund wrote:
> > ...
> >> This procedure would change how serial-num currently is handled.  I
> >> don't have a strong opinion on this, but I note that serial-num is
> >> writable in the ENTITY-MIB.  Maybe someone can comment on why it is
> >> writable in the MIB, and if this is a use case that we want to
> >> support?
> > 
> > I *think* this is an example of what were known as "post-it note"
> > objects.  Their values could be set by management action
> > to accommodate implementations in which, for example, the hardware
> > provided no way for software to access the information printed on an
> > inventory sticker affixed to a card.
> > 
> > Randy
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[William Lupton]

So could “being writable” be associated with a feature (which might potentially 
apply to multiple such nodes)? W.

(and if so, what’s the cleanest way to achieve this? it seems that “if-feature” 
can’t be used with “config” but that it could be used by refining a grouping?)

> On 22 Dec 2016, at 05:14, Randy Presuhn  
> wrote:
> 
> Hi -
> 
> On 12/21/2016 6:56 AM, Martin Bjorklund wrote:
> ...
>> This procedure would change how serial-num currently is handled.  I
>> don't have a strong opinion on this, but I note that serial-num is
>> writable in the ENTITY-MIB.  Maybe someone can comment on why it is
>> writable in the MIB, and if this is a use case that we want to
>> support?
> 
> I *think* this is an example of what were known as "post-it note"
> objects.  Their values could be set by management action
> to accommodate implementations in which, for example, the hardware
> provided no way for software to access the information printed on an
> inventory sticker affixed to a card.
> 
> Randy
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Randy Presuhn]

Hi -

On 12/21/2016 6:56 AM, Martin Bjorklund wrote:
...

This procedure would change how serial-num currently is handled.  I
don't have a strong opinion on this, but I note that serial-num is
writable in the ENTITY-MIB.  Maybe someone can comment on why it is
writable in the MIB, and if this is a use case that we want to
support?


I *think* this is an example of what were known as "post-it note"
objects.  Their values could be set by management action
to accommodate implementations in which, for example, the hardware
provided no way for software to access the information printed on an
inventory sticker affixed to a card.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Bogaert, Bart (Nokia - BE)]

--- snip ---

> > > I think the idea would be explained along these lines:
> > > 
> > > The sytem conceptually behaves like this:
> > > 
> > > 1.  When a physical component is detected, the system will initialize
> > > an entry in the /hardware-state/component list.
> > > 
> > > If there is an entry in /hardare/component list with a matching
> > > (class,parent,parent-rel-pos) triple, then the state entry is
> > > initialized with the configured values for all configured leafs
> > > (name, mfg-name, ...).
> [Bart Bogaert] this is correct

I assume that you do the validation check that you describe below also in
this case?
[Bart Bogaert] Indeed

> > > 
> > > If there is no such matching entry, the system assigns a 'name'
> > > in an implementation-specific manner.
> [Bart Bogaert] This is correct
> > > 
> > > If there is an entry in /hardare/component list with a matching
> > > 'name' and where the triple (class,parent,parent-rel-pos) is not
> > > set, then the state entry is initialized with the configured
> > > values for all configured leafs (name, mfg-name, ...).
> [Bart Bogaert] We currently expect that these leafs contain meaningful 
> values but we will not copy the leaf values from config to state but 
> populate the state fields with what is detected from the HW and raise 
> a mismatch alarm.

Do you expect all configured leafs to contain meaningful values, i.e., do
you validate that all leafs (serial-num, mfg-name, model-name) match?

This procedure would change how serial-num currently is handled.  I don't
have a strong opinion on this, but I note that serial-num is writable in the
ENTITY-MIB.  Maybe someone can comment on why it is writable in the MIB, and
if this is a use case that we want to support?
[Bart Bogaert] No, in this case we expect the triplet to be meaningful
(class,parent,parent-rel-pos) as this identifies the HW entity and on top of
that the mfg-name and model-name are checked.  In case there is a mismatch
an alarm is generated.  The other leafs (defined in ietf-entity) are
implemented as described in the entity YANG model.

Regards, Bart

> Possibly the operational state is set to disabled.  So when a mismatch 
> Is found between what is set in /hardware/component and what is 
> detected a mismatch alarm is raised.
> > > 
> > > Otherwise, the state entry is initialized with the detected values
> > > for all leafs.
> [Bart Bogaert] This is correct
> > > 
> > > 2.  If the /hardware/component list is modified (i.e., someone changed
> > > the config), then the system MUST behave as if it was restarted
> > > and followed the procedure in (1).
> [Bart Bogaert] This is correct
> 
> Regards,
> Bart
> > 
> > This way of pre-configuring that name may indeed make sense. Lets 
> > see if this is what BBF really wanted.
> > 
> > /js

/martin


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Please find response interleaved
> 
> --- snip ---
> 
> It would be very useful if you could comment explicitly on the
> pre-provisioning algorithm I described in
> https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs
> (also cited below).
> 
> From you text above it seems that you do not agree with my algorithm.
> 
> 
> /martin
> 
> 
> > Best regards,
> > Bart
> >  
> > > > And the config list is still indexed by a name; so for list 
> > > > elements that have a (class, parent, position) triple, the name 
> > > > would be arbitrary and not necessarily matching the component name.
> > > 
> > > I think that the idea is that if there is a matching triple, then 
> > > the system MUST use the configured 'name' as the 'name' also in the 
> > > state list.  One reason for pre-confiugring these components is to 
> > > be able to refer to them in other config.
> > 
> > This may make sense.
> > 
> > > > Well, if you understand the edits,...
> > > 
> > > I think the idea would be explained along these lines:
> > > 
> > > The sytem conceptually behaves like this:
> > > 
> > > 1.  When a physical component is detected, the system will initialize
> > > an entry in the /hardware-state/component list.
> > > 
> > > If there is an entry in /hardare/component list with a matching
> > > (class,parent,parent-rel-pos) triple, then the state entry is
> > > initialized with the configured values for all configured leafs
> > > (name, mfg-name, ...).
> [Bart Bogaert] this is correct

I assume that you do the validation check that you describe below also
in this case?

> > > 
> > > If there is no such matching entry, the system assigns a 'name'
> > > in an implementation-specific manner.
> [Bart Bogaert] This is correct
> > > 
> > > If there is an entry in /hardare/component list with a matching
> > > 'name' and where the triple (class,parent,parent-rel-pos) is not
> > > set, then the state entry is initialized with the configured
> > > values for all configured leafs (name, mfg-name, ...).
> [Bart Bogaert] We currently expect that these leafs contain meaningful
> values but we will not copy the leaf values from config to state but
> populate the state fields with what is detected from the HW and raise a
> mismatch alarm.

Do you expect all configured leafs to contain meaningful values, i.e.,
do you validate that all leafs (serial-num, mfg-name, model-name)
match?

This procedure would change how serial-num currently is handled.  I
don't have a strong opinion on this, but I note that serial-num is
writable in the ENTITY-MIB.  Maybe someone can comment on why it is
writable in the MIB, and if this is a use case that we want to
support?

> Possibly the operational state is set to disabled.  So when
> a mismatch Is found between what is set in /hardware/component and what is
> detected a mismatch alarm is raised.
> > > 
> > > Otherwise, the state entry is initialized with the detected values
> > > for all leafs.
> [Bart Bogaert] This is correct
> > > 
> > > 2.  If the /hardware/component list is modified (i.e., someone changed
> > > the config), then the system MUST behave as if it was restarted
> > > and followed the procedure in (1).
> [Bart Bogaert] This is correct
> 
> Regards,
> Bart
> > 
> > This way of pre-configuring that name may indeed make sense. Lets see 
> > if this is what BBF really wanted.
> > 
> > /js

/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Bogaert, Bart (Nokia - BE)]

Please find response interleaved

--- snip ---

It would be very useful if you could comment explicitly on the
pre-provisioning algorithm I described in
https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs
(also cited below).

>From you text above it seems that you do not agree with my algorithm.


/martin


> Best regards,
> Bart
>  
> > > And the config list is still indexed by a name; so for list 
> > > elements that have a (class, parent, position) triple, the name 
> > > would be arbitrary and not necessarily matching the component name.
> > 
> > I think that the idea is that if there is a matching triple, then 
> > the system MUST use the configured 'name' as the 'name' also in the 
> > state list.  One reason for pre-confiugring these components is to 
> > be able to refer to them in other config.
> 
> This may make sense.
> 
> > > Well, if you understand the edits,...
> > 
> > I think the idea would be explained along these lines:
> > 
> > The sytem conceptually behaves like this:
> > 
> > 1.  When a physical component is detected, the system will initialize
> > an entry in the /hardware-state/component list.
> > 
> > If there is an entry in /hardare/component list with a matching
> > (class,parent,parent-rel-pos) triple, then the state entry is
> > initialized with the configured values for all configured leafs
> > (name, mfg-name, ...).
[Bart Bogaert] this is correct
> > 
> > If there is no such matching entry, the system assigns a 'name'
> > in an implementation-specific manner.
[Bart Bogaert] This is correct
> > 
> > If there is an entry in /hardare/component list with a matching
> > 'name' and where the triple (class,parent,parent-rel-pos) is not
> > set, then the state entry is initialized with the configured
> > values for all configured leafs (name, mfg-name, ...).
[Bart Bogaert] We currently expect that these leafs contain meaningful
values but we will not copy the leaf values from config to state but
populate the state fields with what is detected from the HW and raise a
mismatch alarm.  Possibly the operational state is set to disabled.  So when
a mismatch Is found between what is set in /hardware/component and what is
detected a mismatch alarm is raised.
> > 
> > Otherwise, the state entry is initialized with the detected values
> > for all leafs.
[Bart Bogaert] This is correct
> > 
> > 2.  If the /hardware/component list is modified (i.e., someone changed
> > the config), then the system MUST behave as if it was restarted
> > and followed the procedure in (1).
[Bart Bogaert] This is correct

Regards,
Bart
> 
> This way of pre-configuring that name may indeed make sense. Lets see 
> if this is what BBF really wanted.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi,
> 
> --- snip ---
> 
> > > Well, this is not what I read out of
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > > 
> > > since there are leafs like mfg-name and model-name that seem to be 
> > > hardware component properties.
> > 
> > The description statements in this email are just copied from the 
> > corresponding config false nodes.  I think they need to be rewritten; 
> > compare with serial-num.  This text can probably be further improved.
> > The idea is that the user probably would configure say mfg-name only 
> > if the system cannot detect it automatically.
> 
> I still wonder why it could be useful to provision things like the mfg-name
> or the serial-num. I would rather like to know what is really there instead
> of overwriting these properties.
> [Bart Bogaert] BBF did not propose to add serial-num, this is in the base
> ietf-entity YANG model.  For pluggable items it makes sense to add the model
> name and mfg-name.  In case of pre-provisioning (so preparing and sending a
> configuration to the device while the HW entity is actually not there yet)
> it makes sense to indicate what is the intended configuration.  When the HW
> entity is inserted at a later point in time the device could raise a
> mismatch alarm in case another entity is detected then the one that was
> "predicted" to be inserted at that position.

It would be very useful if you could comment explicitly on the
pre-provisioning algorithm I described in 
https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs
(also cited below).

>From you text above it seems that you do not agree with my algorithm.


/martin


> Best regards,
> Bart
>  
> > > And the config list is still indexed by a name; so for list elements 
> > > that have a (class, parent, position) triple, the name would be 
> > > arbitrary and not necessarily matching the component name.
> > 
> > I think that the idea is that if there is a matching triple, then the 
> > system MUST use the configured 'name' as the 'name' also in the state 
> > list.  One reason for pre-confiugring these components is to be able 
> > to refer to them in other config.
> 
> This may make sense.
> 
> > > Well, if you understand the edits,...
> > 
> > I think the idea would be explained along these lines:
> > 
> > The sytem conceptually behaves like this:
> > 
> > 1.  When a physical component is detected, the system will initialize
> > an entry in the /hardware-state/component list.
> > 
> > If there is an entry in /hardare/component list with a matching
> > (class,parent,parent-rel-pos) triple, then the state entry is
> > initialized with the configured values for all configured leafs
> > (name, mfg-name, ...).
> > 
> > If there is no such matching entry, the system assigns a 'name'
> > in an implementation-specific manner.
> > 
> > If there is an entry in /hardare/component list with a matching
> > 'name' and where the triple (class,parent,parent-rel-pos) is not
> > set, then the state entry is initialized with the configured
> > values for all configured leafs (name, mfg-name, ...).
> > 
> > Otherwise, the state entry is initialized with the detected values
> > for all leafs.
> > 
> > 2.  If the /hardware/component list is modified (i.e., someone changed
> > the config), then the system MUST behave as if it was restarted
> > and followed the procedure in (1).
> 
> This way of pre-configuring that name may indeed make sense. Lets see if
> this is what BBF really wanted.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Bogaert, Bart (Nokia - BE)]

Hi,

--- snip ---

> > Well, this is not what I read out of
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > 
> > since there are leafs like mfg-name and model-name that seem to be 
> > hardware component properties.
> 
> The description statements in this email are just copied from the 
> corresponding config false nodes.  I think they need to be rewritten; 
> compare with serial-num.  This text can probably be further improved.
> The idea is that the user probably would configure say mfg-name only 
> if the system cannot detect it automatically.

I still wonder why it could be useful to provision things like the mfg-name
or the serial-num. I would rather like to know what is really there instead
of overwriting these properties.
[Bart Bogaert] BBF did not propose to add serial-num, this is in the base
ietf-entity YANG model.  For pluggable items it makes sense to add the model
name and mfg-name.  In case of pre-provisioning (so preparing and sending a
configuration to the device while the HW entity is actually not there yet)
it makes sense to indicate what is the intended configuration.  When the HW
entity is inserted at a later point in time the device could raise a
mismatch alarm in case another entity is detected then the one that was
"predicted" to be inserted at that position.

Best regards,
Bart
 
> > And the config list is still indexed by a name; so for list elements 
> > that have a (class, parent, position) triple, the name would be 
> > arbitrary and not necessarily matching the component name.
> 
> I think that the idea is that if there is a matching triple, then the 
> system MUST use the configured 'name' as the 'name' also in the state 
> list.  One reason for pre-confiugring these components is to be able 
> to refer to them in other config.

This may make sense.

> > Well, if you understand the edits,...
> 
> I think the idea would be explained along these lines:
> 
> The sytem conceptually behaves like this:
> 
> 1.  When a physical component is detected, the system will initialize
> an entry in the /hardware-state/component list.
> 
> If there is an entry in /hardare/component list with a matching
> (class,parent,parent-rel-pos) triple, then the state entry is
> initialized with the configured values for all configured leafs
> (name, mfg-name, ...).
> 
> If there is no such matching entry, the system assigns a 'name'
> in an implementation-specific manner.
> 
> If there is an entry in /hardare/component list with a matching
> 'name' and where the triple (class,parent,parent-rel-pos) is not
> set, then the state entry is initialized with the configured
> values for all configured leafs (name, mfg-name, ...).
> 
> Otherwise, the state entry is initialized with the detected values
> for all leafs.
> 
> 2.  If the /hardware/component list is modified (i.e., someone changed
> the config), then the system MUST behave as if it was restarted
> and followed the procedure in (1).

This way of pre-configuring that name may indeed make sense. Lets see if
this is what BBF really wanted.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder  wrote:
> > > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > > > 
> > > > > >   Should the model support pre-configuration of hardware components?
> > > > > >   The current model supports pre-configuration of components 
> > > > > > provided
> > > > > >   the operator knows the name of the component to be installed. A 
> > > > > > more
> > > > > >   useful model would use the parent component, class, and
> > > > > >   parent-rel-pos as identification. If the system detects a 
> > > > > > component
> > > > > >   and there is configuration available for the parent component,
> > > > > >   class, and parent-rel-pos then the system would instatiate the
> > > > > >   component with the provided name, and optionally additional
> > > > > >   parameters.
> > > > > > 
> > > > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > > > issue.
> > > > > > 
> > > > > > Personally, I think that we should add these nodes, since the ML
> > > > > > comments indicated that pre configuration is pretty useful.
> > > > > >
> > > > > 
> > > > > I am still not sure what exactly this will do. I have been looking at
> > > > > .
> > > > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > > > string actually printed on the component itself (if present).) but all
> > > > > I have is that something of a certain expected class has been plugged
> > > > > into a certain position of the parent container. Also note that
> > > > > mfg-name scopes comparisons of other properties. I would have similar
> > > > > questions concerning the model-name; how can a provisioning system
> > > > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > > > idea that if I plug something that does not match, the component is
> > > > > left in a special state (which one)? If this is the intention, then
> > > > > this needs to be spelled out clearly somewhere.
> > > > 
> > > > The current model works fine if the user looks into the state list and
> > > > finds a component that he wants to configure.  To do this, he uses the
> > > > name of the component as found in the state list, and writes the
> > > > config for this component.
> > > > 
> > > > The current model also supports pre-configuration if the user somehow
> > > > can predict the name of a component to-be-inserted.  In this case he
> > > > can write the config, and when the component is plugged in, the system
> > > > will derive the component name, and check the config list for this
> > > > name.  This is a fragile model.
> > > > 
> > > > In the proposed model, the user can provide configuration for a tuple
> > > > (parent, class, parent-rel-pos).   If the server finds a component in
> > > > the state list (or such a component is later plugged in), then the
> > > > corresponding config leafs are used for the state of this component
> > > > (including the name).
> > > > 
> > > > If you plug in something that doesn't match the config list, well that
> > > > just means that nothing has been configured for this component, and
> > > > the system will populate the state list accordingly.
> > > >
> > > 
> > > Well, this is not what I read out of
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > > 
> > > since there are leafs like mfg-name and model-name that seem to be
> > > hardware component properties.
> > 
> > The description statements in this email are just copied from the
> > corresponding config false nodes.  I think they need to be rewritten;
> > compare with serial-num.  This text can probably be further improved.
> > The idea is that the user probably would configure say mfg-name only
> > if the system cannot detect it automatically.
> 
> I still wonder why it could be useful to provision things like the
> mfg-name or the serial-num. I would rather like to know what is really
> there instead of overwriting these properties.

Note that entPhysicalSerialNum is read-write in the MIB.  I assume
that the reason for this is that operators can use this as an
inventory list, and manually enter the values that the system cannot
detect automatically.

> > > And the config list is still indexed by
> > > a name; so for list elements that have a (class, parent, position)
> > > triple, the name would be arbitrary and not necessarily matching the
> > > component name.
> > 
> > I think that the idea is that if there is a matching triple, then the
> > system MUST use the configured 'name' as the 'name' also in the state
> > list.  One reason for pre-confiugring these components is to be able
>

Re: [netmod] draft-ietf-netmod-entity issue #13

[Juergen Schoenwaelder]

On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > > Hi,
> > > > > 
> > > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > > 
> > > > >   Should the model support pre-configuration of hardware components?
> > > > >   The current model supports pre-configuration of components provided
> > > > >   the operator knows the name of the component to be installed. A more
> > > > >   useful model would use the parent component, class, and
> > > > >   parent-rel-pos as identification. If the system detects a component
> > > > >   and there is configuration available for the parent component,
> > > > >   class, and parent-rel-pos then the system would instatiate the
> > > > >   component with the provided name, and optionally additional
> > > > >   parameters.
> > > > > 
> > > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > > issue.
> > > > > 
> > > > > Personally, I think that we should add these nodes, since the ML
> > > > > comments indicated that pre configuration is pretty useful.
> > > > >
> > > > 
> > > > I am still not sure what exactly this will do. I have been looking at
> > > > .
> > > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > > string actually printed on the component itself (if present).) but all
> > > > I have is that something of a certain expected class has been plugged
> > > > into a certain position of the parent container. Also note that
> > > > mfg-name scopes comparisons of other properties. I would have similar
> > > > questions concerning the model-name; how can a provisioning system
> > > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > > idea that if I plug something that does not match, the component is
> > > > left in a special state (which one)? If this is the intention, then
> > > > this needs to be spelled out clearly somewhere.
> > > 
> > > The current model works fine if the user looks into the state list and
> > > finds a component that he wants to configure.  To do this, he uses the
> > > name of the component as found in the state list, and writes the
> > > config for this component.
> > > 
> > > The current model also supports pre-configuration if the user somehow
> > > can predict the name of a component to-be-inserted.  In this case he
> > > can write the config, and when the component is plugged in, the system
> > > will derive the component name, and check the config list for this
> > > name.  This is a fragile model.
> > > 
> > > In the proposed model, the user can provide configuration for a tuple
> > > (parent, class, parent-rel-pos).   If the server finds a component in
> > > the state list (or such a component is later plugged in), then the
> > > corresponding config leafs are used for the state of this component
> > > (including the name).
> > > 
> > > If you plug in something that doesn't match the config list, well that
> > > just means that nothing has been configured for this component, and
> > > the system will populate the state list accordingly.
> > >
> > 
> > Well, this is not what I read out of
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > 
> > since there are leafs like mfg-name and model-name that seem to be
> > hardware component properties.
> 
> The description statements in this email are just copied from the
> corresponding config false nodes.  I think they need to be rewritten;
> compare with serial-num.  This text can probably be further improved.
> The idea is that the user probably would configure say mfg-name only
> if the system cannot detect it automatically.

I still wonder why it could be useful to provision things like the
mfg-name or the serial-num. I would rather like to know what is really
there instead of overwriting these properties.
 
> > And the config list is still indexed by
> > a name; so for list elements that have a (class, parent, position)
> > triple, the name would be arbitrary and not necessarily matching the
> > component name.
> 
> I think that the idea is that if there is a matching triple, then the
> system MUST use the configured 'name' as the 'name' also in the state
> list.  One reason for pre-confiugring these components is to be able
> to refer to them in other config.

This may make sense.

> > Well, if you understand the edits,...
> 
> I think the idea would be explained along these lines:
> 
> The sytem conceptually behaves like this:
> 
> 1.  When a physical component is detected, the system will initialize
> an entry in the /hardware-state/component list.
> 
> If there is an entry in /hardare/component list with a matching
> (class,parent,parent-rel-pos) triple, then t

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > Hi,
> > > > 
> > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > 
> > > >   Should the model support pre-configuration of hardware components?
> > > >   The current model supports pre-configuration of components provided
> > > >   the operator knows the name of the component to be installed. A more
> > > >   useful model would use the parent component, class, and
> > > >   parent-rel-pos as identification. If the system detects a component
> > > >   and there is configuration available for the parent component,
> > > >   class, and parent-rel-pos then the system would instatiate the
> > > >   component with the provided name, and optionally additional
> > > >   parameters.
> > > > 
> > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > issue.
> > > > 
> > > > Personally, I think that we should add these nodes, since the ML
> > > > comments indicated that pre configuration is pretty useful.
> > > >
> > > 
> > > I am still not sure what exactly this will do. I have been looking at
> > > .
> > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > string actually printed on the component itself (if present).) but all
> > > I have is that something of a certain expected class has been plugged
> > > into a certain position of the parent container. Also note that
> > > mfg-name scopes comparisons of other properties. I would have similar
> > > questions concerning the model-name; how can a provisioning system
> > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > idea that if I plug something that does not match, the component is
> > > left in a special state (which one)? If this is the intention, then
> > > this needs to be spelled out clearly somewhere.
> > 
> > The current model works fine if the user looks into the state list and
> > finds a component that he wants to configure.  To do this, he uses the
> > name of the component as found in the state list, and writes the
> > config for this component.
> > 
> > The current model also supports pre-configuration if the user somehow
> > can predict the name of a component to-be-inserted.  In this case he
> > can write the config, and when the component is plugged in, the system
> > will derive the component name, and check the config list for this
> > name.  This is a fragile model.
> > 
> > In the proposed model, the user can provide configuration for a tuple
> > (parent, class, parent-rel-pos).   If the server finds a component in
> > the state list (or such a component is later plugged in), then the
> > corresponding config leafs are used for the state of this component
> > (including the name).
> > 
> > If you plug in something that doesn't match the config list, well that
> > just means that nothing has been configured for this component, and
> > the system will populate the state list accordingly.
> >
> 
> Well, this is not what I read out of
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> 
> since there are leafs like mfg-name and model-name that seem to be
> hardware component properties.

The description statements in this email are just copied from the
corresponding config false nodes.  I think they need to be rewritten;
compare with serial-num.  This text can probably be further improved.
The idea is that the user probably would configure say mfg-name only
if the system cannot detect it automatically.

> And the config list is still indexed by
> a name; so for list elements that have a (class, parent, position)
> triple, the name would be arbitrary and not necessarily matching the
> component name.

I think that the idea is that if there is a matching triple, then the
system MUST use the configured 'name' as the 'name' also in the state
list.  One reason for pre-confiugring these components is to be able
to refer to them in other config.

> Well, if you understand the edits,...

I think the idea would be explained along these lines:

The sytem conceptually behaves like this:

1.  When a physical component is detected, the system will initialize
an entry in the /hardware-state/component list.

If there is an entry in /hardare/component list with a matching
(class,parent,parent-rel-pos) triple, then the state entry is
initialized with the configured values for all configured leafs
(name, mfg-name, ...).

If there is no such matching entry, the system assigns a 'name'
in an implementation-specific manner.

If there is an entry in /hardare/component list with a matching
'name' and where the triple (class,parent,parent-rel-pos) is not
set, then the state entry is initialized with the configured
values for all configured le

Re: [netmod] draft-ietf-netmod-entity issue #13

[Juergen Schoenwaelder]

On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Issue https://github.com/netmod-wg/entity/issues/13
> > > 
> > >   Should the model support pre-configuration of hardware components?
> > >   The current model supports pre-configuration of components provided
> > >   the operator knows the name of the component to be installed. A more
> > >   useful model would use the parent component, class, and
> > >   parent-rel-pos as identification. If the system detects a component
> > >   and there is configuration available for the parent component,
> > >   class, and parent-rel-pos then the system would instatiate the
> > >   component with the provided name, and optionally additional
> > >   parameters.
> > > 
> > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > issue.
> > > 
> > > Personally, I think that we should add these nodes, since the ML
> > > comments indicated that pre configuration is pretty useful.
> > >
> > 
> > I am still not sure what exactly this will do. I have been looking at
> > .
> > I am provisioning mfg-name (Preferred value is the manufacturer name
> > string actually printed on the component itself (if present).) but all
> > I have is that something of a certain expected class has been plugged
> > into a certain position of the parent container. Also note that
> > mfg-name scopes comparisons of other properties. I would have similar
> > questions concerning the model-name; how can a provisioning system
> > predict the 'vendor-specific model name identifier'? Or is the whole
> > idea that if I plug something that does not match, the component is
> > left in a special state (which one)? If this is the intention, then
> > this needs to be spelled out clearly somewhere.
> 
> The current model works fine if the user looks into the state list and
> finds a component that he wants to configure.  To do this, he uses the
> name of the component as found in the state list, and writes the
> config for this component.
> 
> The current model also supports pre-configuration if the user somehow
> can predict the name of a component to-be-inserted.  In this case he
> can write the config, and when the component is plugged in, the system
> will derive the component name, and check the config list for this
> name.  This is a fragile model.
> 
> In the proposed model, the user can provide configuration for a tuple
> (parent, class, parent-rel-pos).   If the server finds a component in
> the state list (or such a component is later plugged in), then the
> corresponding config leafs are used for the state of this component
> (including the name).
> 
> If you plug in something that doesn't match the config list, well that
> just means that nothing has been configured for this component, and
> the system will populate the state list accordingly.
>

Well, this is not what I read out of

https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html

since there are leafs like mfg-name and model-name that seem to be
hardware component properties. And the config list is still indexed by
a name; so for list elements that have a (class, parent, position)
triple, the name would be arbitrary and not necessarily matching the
component name.

Well, if you understand the edits,...

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Issue https://github.com/netmod-wg/entity/issues/13
> > 
> >   Should the model support pre-configuration of hardware components?
> >   The current model supports pre-configuration of components provided
> >   the operator knows the name of the component to be installed. A more
> >   useful model would use the parent component, class, and
> >   parent-rel-pos as identification. If the system detects a component
> >   and there is configuration available for the parent component,
> >   class, and parent-rel-pos then the system would instatiate the
> >   component with the provided name, and optionally additional
> >   parameters.
> > 
> > See also various mails from Timothy Carey and Bart Bogaert on this
> > issue.
> > 
> > Personally, I think that we should add these nodes, since the ML
> > comments indicated that pre configuration is pretty useful.
> >
> 
> I am still not sure what exactly this will do. I have been looking at
> .
> I am provisioning mfg-name (Preferred value is the manufacturer name
> string actually printed on the component itself (if present).) but all
> I have is that something of a certain expected class has been plugged
> into a certain position of the parent container. Also note that
> mfg-name scopes comparisons of other properties. I would have similar
> questions concerning the model-name; how can a provisioning system
> predict the 'vendor-specific model name identifier'? Or is the whole
> idea that if I plug something that does not match, the component is
> left in a special state (which one)? If this is the intention, then
> this needs to be spelled out clearly somewhere.

The current model works fine if the user looks into the state list and
finds a component that he wants to configure.  To do this, he uses the
name of the component as found in the state list, and writes the
config for this component.

The current model also supports pre-configuration if the user somehow
can predict the name of a component to-be-inserted.  In this case he
can write the config, and when the component is plugged in, the system
will derive the component name, and check the config list for this
name.  This is a fragile model.

In the proposed model, the user can provide configuration for a tuple
(parent, class, parent-rel-pos).   If the server finds a component in
the state list (or such a component is later plugged in), then the
corresponding config leafs are used for the state of this component
(including the name).

If you plug in something that doesn't match the config list, well that
just means that nothing has been configured for this component, and
the system will populate the state list accordingly.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[Juergen Schoenwaelder]

On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Issue https://github.com/netmod-wg/entity/issues/13
> 
>   Should the model support pre-configuration of hardware components?
>   The current model supports pre-configuration of components provided
>   the operator knows the name of the component to be installed. A more
>   useful model would use the parent component, class, and
>   parent-rel-pos as identification. If the system detects a component
>   and there is configuration available for the parent component,
>   class, and parent-rel-pos then the system would instatiate the
>   component with the provided name, and optionally additional
>   parameters.
> 
> See also various mails from Timothy Carey and Bart Bogaert on this
> issue.
> 
> Personally, I think that we should add these nodes, since the ML
> comments indicated that pre configuration is pretty useful.
>

I am still not sure what exactly this will do. I have been looking at
.
I am provisioning mfg-name (Preferred value is the manufacturer name
string actually printed on the component itself (if present).) but all
I have is that something of a certain expected class has been plugged
into a certain position of the parent container. Also note that
mfg-name scopes comparisons of other properties. I would have similar
questions concerning the model-name; how can a provisioning system
predict the 'vendor-specific model name identifier'? Or is the whole
idea that if I plug something that does not match, the component is
left in a special state (which one)? If this is the intention, then
this needs to be spelled out clearly somewhere.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Hi,

Issue https://github.com/netmod-wg/entity/issues/13

  Should the model support pre-configuration of hardware components?
  The current model supports pre-configuration of components provided
  the operator knows the name of the component to be installed. A more
  useful model would use the parent component, class, and
  parent-rel-pos as identification. If the system detects a component
  and there is configuration available for the parent component,
  class, and parent-rel-pos then the system would instatiate the
  component with the provided name, and optionally additional
  parameters.


See also various mails from Timothy Carey and Bart Bogaert on this
issue.

Personally, I think that we should add these nodes, since the ML
comments indicated that pre configuration is pretty useful.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod