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

[Randy Presuhn]

Hi -

My recollection is that part of the motivation for the use of
zero-length strings as sentinel values in situations like this
in MIB modules (rather than skipping the object instance) was
to permit a clear distinction between "information not available"
and "access denied".

Randy

On 12/15/2016 7:21 AM, Juergen Schoenwaelder wrote:

I do not think the goal should be to emulate SMIv2 compliance levels
using features. So I propose to do nothing about entity4CRCompliance.

The other question (which should perhaps have been a separate issue)
is whether non-existing values are indicated by zero-length strings or
non-existing objects. I think in general we prefer to simply not
report those objects in the YANG world. If so, I am not sure whether
the goal to not depart too much from the ENTITY-MIB overrules
this. Note that there are a couple of objects where non-existing
values lead to zero-length string or other special values. (The
'alias' description is kind of interesting - the server may set the
value of this node to a locally unique value; entPhysicalAlias says
something different, namely On the first instantiation ... is set to
the zero-length string.)

Looking at the YANG fragment, I am also not sure how useful it is to
carry the 32 'something' restriction forward. Note that 32 means
unicode characters in YANG but space of the UTF-8 encoding of
characters for SMIv2 (since it all ends up being a restriction for the
OCTET STRING). Perhaps this deserves a feature, namely, whether an
implementation supports flexible names or restricts names according to
the SMIv2 ENTITY-MIB rules.

/js

On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote:

Hi,

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

  RFC 6933 introduced a new compliance level for constrained resources
  - entity4CRCompliance. Do we need a corresponding feature?

In YANG, we cannot to the equivalent of compliance levels, so we would
need to mark all nodes with some optional feature, except the few
nodes that a constrained device would implement.

OTOH, most nodes are already optional and config false.  So a
constrained server that doesn't know the serial number for example
could just no return it.  There is one catch though; the current text,
copied from the MIB, says e.g.:

   If the manufacturer name string associated with the
   physical component is unknown to the server, then this
   node will contain a zero-length string.

Maybe we should change this so that the object isn't returned at all
instead of returning a zero-length string.



/martin

___
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] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

[Dean Bogdanovic]

> On Dec 15, 2016, at 10:24 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Dean Bogdanovic > wrote:
>> Authors,
>> 
>> Need some clarification about applied data store
>> 
>> In the draft, applied data store can contain data from 
>> 
>> This data can come from several sources; from , from dynamic
>> configuration protocols (e.g., DHCP), or from control-plane datastore.
>> 
>> The control-plane stores are not well clarified in my opinion
>> 
>> The model foresees control-plane datastores that are by definition
>>   not part of the persistent configuration of a device.  In some
>>   contexts, these have been termed ephemeral datastores since the
>>   information is ephemeral, i.e., lost upon reboot.  The control-plane
>>   datastores interact with the rest of the system through the 
>>   or  datastores, depending on the type of data they
>>   contain.  Note that the ephemeral datastore discussed in I2RS
>>   documents maps to a control-plane datastore in the revised datastore
>>   model described here.
>> 
>> The other issue I have is with that control-plane data stores are
>> shown connected to applied and operational-state. Which control plane
>> data stores are directly influencing operational-state?
> 
> We wanted to allow for other to-be-defined data stores by showing
> where they can fit into the architecture.  When/if such a data store
> is defined, it can relate to this architecture and explain exactly how
> it fits in and how it affects applied config and/or operational state.
> 
>> Also, in the diagram control-plane protocols are connected only to
>> operational-state data store. But isn’t the previous state exchanged
>> via control plane protocols taken into account when validating data
>> that is copied into applied data store?
> 
> When you say "data that is copied into applied", are you referring to
> the arrow between intended and applied?

Yes, correct
> 
> The answer is that the arrows show data flow.  The mechanism that
> copies data from intended to applied will surely have to check
> operational state and maybe physical resources in roder to do its job.

But from the same diagram, it states that control protocols are not impacting 
applied data store, except the operational state. This is something I have to 
wrap my mind around it, as when the applied state is computed, it is taking 
into account data exchanged via control protocols.

Dean


> 
> 
> /martin

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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics true;", 
additional datastore and NETCONF protocol change. IMO that sounds heavy 
but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.

* The solution with RPC enabling the containers only for a certain session.

I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to s without filter or s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.


Example for /interfaces-state/interfaces/diagnostics (using xpath filter 
for brevity but valid for the "subtree" case):


These skip "diagnostics":



These return "diagnostics":

select="/interfaces-state/interface/diagnostics"\>



This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.


/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:


Hi Robert,

You’re right, it should’ve been the  (not ).   
However, I think that it’s better to use a flag on the 
 datastore, rather than to define a new datastore.  
Not only would it mimic how with-defaults works, but it also seems 
more intuitive from a retrieval perspective, as the diagnostics nodes 
could be sprinkled throughout a data model, and a single  
could return all nodes (not just the diagnostics) for a given 
subtree.Thoughts?


Separately, from a modelling perspective, presumably there would have 
to be an additional flag to go with the config false flag, something 
like the below.  Is this what you were envisioning?


container thermostat {

leaf configured-temperature {

type int8;

}

leaf current-temperature {

config false;

type int8;

}

container diagnostics {

config false;

diagnostics true;<-- new flag here

...

}

Is all this leading up to a draft?  ;)

Kent  // contributor

*From: *Robert Wilton 
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen , Andy Bierman 
*Cc: *"netmod@ietf.org" 
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   

  

 

  

<--- note this flag here

  

 http://example.com/schema/1.2/config;
>



  



 

  

   

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically 
return the contents of any datastore,
- defining a new  datastore that contains the contents of 
the  along with all config false schema nodes 
labelled as "diagnostics true".


   

  

 

  

  



  


Thanks,
Rob



> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra
'diag-stats',

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?

Kent  // contributor



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

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Iftekhar Hussain]

Yes/support.

I have read this draft and believe it would be very useful for enabling many 
Layer 2 and Layer 3 services.

However, I do have few comments and that I would like the authors to address 
once the document is a WG document.

a)  Suggest to replace this text:
"These modules allow IETF forwarding protocols (such as IPv6 and VPLS) ..." 
 with the following text:
" These modules allow configuration Layer 2 and Layer 3 subinterfaces 
(e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, 
EVPN) and L3VPN services". 

b) The document should clearly identify the scope. For example, suggest replace 
this text:
"... to interoperate with VLAN tagged traffic orginated from an IEEE 
802.1Q compliant bridge". 
   with the following text:
   "... to interoperate with traffic originated from an IEEE 802.1D, 
802.1Q, or 802.1AD compliant bridge."

   Note: In the data model, the draft is talking about untagged as well as 
802.1AD (see  "tag type (802.1Q or 802.1ad)")

 c)  Are there any sub-interface level common statistics counters that the 
model should address?  Currently, I don't see any.

Thanks,
Iftekhar
-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Monday, December 12, 2016 3:32 PM
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

* Given the holiday, the poll ends December 28.

Thank you,
NetMod WG Chairs

___
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] WG Last Call for draft-ietf-netmod-syslog-model-11

[Clyde Wildes (cwildes)]

Hi Alex,

Thanks for your review. My comments are inline as [clyde]…

On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" 
 wrote:

I am considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately 
decreasing order of severity:

* In the "selector-facility" choice statement the cases have misleading 
names - the case where no facility is matched is named "facility", and the case 
where specific facilities are matched is named "name". I suggest 
"no-facilities" and "specified-facilities", or similar.

[clyde] I understand your concern and agree. Please see the next answer where I 
have removed the no-facilities case from the model.


* I disagree with the premise of the "no-facilities" case, which is that it 
can be used to disable a log action, according to the description:

 description
"This case specifies no facilities will match when
 comparing the syslog message facility. This is a
 method that can be used to effectively disable a
 particular log-action (buffer, file, etc).";

  If an administrator wants to disable a log action they should do it by 
either removing it from the configuration, or by setting an "enabled" leaf to 
false.
  With that in mind, there is no reason for the "no-facilities" case to 
exist.

[clyde] I agree with your suggestion to simplify by removing the no-facilities 
case. Please see the revised selector grouping which will appear in the next 
draft:

  grouping selector {
description
  "This grouping defines a syslog selector which is used to 
   select log messages for the log-action (console, file, 
   remote, etc.). Choose one or both of the following:
 facility [ ...]
 pattern-match regular-expression-match-string
   If both facility and pattern-match are specified, both must 
   match in order for a log message to be selected.";
container selector {
  description
"This container describes the log selector parameters 
 for syslog.";
  list facility-list {
key facility;
description
  "This list describes a collection of syslog 
   facilities and severities.";
leaf facility {
  type union {
type identityref {
  base syslogtypes:syslog-facility;
}
type enumeration {
  enum all {
description
  "This enum describes the case where all 
   facilities are requested.";
  }
}
  }
  description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
  }
  leaf pattern-match {
if-feature select-match;
type string;
description
  "This leaf desribes a Posix 1003.2 regular expression 
   string that can be used to select a syslog message for 
   logging. The match is performed on the RFC 5424 
   SYSLOG-MSG field.";
  }
}
  }


* What is the behaviour of a selector if neither "no-facilities" nor 
"facility-list" is present?

[clyde] At least one or both of the following must be specified: facility; 
pattern-match (if supported).

I have updated the description at the beginning of the selector – please see 
above.


* In the "selector" grouping it is not clear how the facility and pattern 
conditions are combined to decide whether a message is selected.

  Must they both match the message, or is it sufficient for either one to 
match the message?

[clyde] If both are specified they must both match the message. This is 
consistent with the syslog implementations by Cisco and Juniper.


* Not all servers have a console; there should be a feature to indicate 
whether logging to the console is supported.

[clyde] I have received comments in earlier reviews that we should implement 
the minimum set of functionality that is contained in at least three vendor 
implementations.

Console is supported by Alcatel/Lucent, Brocade, Cisco (XE, XR, and NXOS), 
Juniper, and Linux-rsyslog. Removal of the console action for your case could 
be done through a vendor specific deviation statement.


* Likewise, not all servers may support logging to user sessions.

[clyde] User sessions are supported by Alcatel/Lucent, and Juniper. I will make 
this a feature in the next revision of the draft since only two vendors 
implement it.


* Likewise, not all servers may support a user-accessible filesystem.

[clyde] Files are supported by Alcatel/Lucent, Cisco (XE, XR, and NXOS), 
Juniper, and Linux-rsyslog. Removal of the file action for your case could be 
done through a vendor specific deviation statement.


* RFC 5424 states that the severity and 

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[William Lupton]

The current draft-ietf-netmod-entity-01 defines ietf-hardware and iana-entity 
modules. Is it intended that iana-entity will become iana-hardware? Thanks, W.
___
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 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

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

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 15, 2016 at 04:03:40PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Issue https://github.com/netmod-wg/entity/issues/12
> > 
> >   entConfigChange is useful but maybe covered by netconf-config-change
> >   notification, or pub/sub. it is also a bad name, since it fires when
> >   the opstate changes...  Need to think about which notifs to define.
> > 
> > Currently we have three notifications:
> > 
> >   harwdare-state-change
> >   hardware-state-oper-enabled
> >   hardware-state-oper-disabled
> 
> It seems harwdare-state-change is not netconf-config-change. The
> harwdare-state-change indicates that the '/hardware-state/component'
> list has changed, i.e., operational state has changed not config.  (It
> is always important to read the descriptions and not to draw wrong
> conclusions from the fact the SNMP notification was called
> entConfigChange.)

Yes.

> > Jason Sterne also made the observation on the ML that maybe pub/sub is
> > a better mechanism for these simple notifs.
> 
> Not sure what 'better' means. I assume that generating these specific
> notifications can likely be done way more efficiently than doing the
> same via a pub/sub interface unless the pub/sub backend code is really
> really smart.

Yes, I share this concern.  I don't think it would be a good idea to
remove all notifications and just provide state nodes, and then assume
that clients write clever filters in order to get the notificaitons
they want.

However, in this particular case, the notifications
hardware-state-oper-enabled and hardware-state-oper-disabled are
simple in the sense that they defined to be generated when a certain
node changes its value.

> That said, I would not be surprised if application
> writers will use pub/sub for everything because the hammer makes
> everything look like a nail.

We'll see.  Specific notifications are often designed to deliver
related information, and this might not be to easy to do with a
generic solution like pub/sub.


/martin

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

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

[Juergen Schoenwaelder]

On Thu, Dec 15, 2016 at 04:03:40PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Issue https://github.com/netmod-wg/entity/issues/12
> 
>   entConfigChange is useful but maybe covered by netconf-config-change
>   notification, or pub/sub. it is also a bad name, since it fires when
>   the opstate changes...  Need to think about which notifs to define.
> 
> Currently we have three notifications:
> 
>   harwdare-state-change
>   hardware-state-oper-enabled
>   hardware-state-oper-disabled

It seems harwdare-state-change is not netconf-config-change. The
harwdare-state-change indicates that the '/hardware-state/component'
list has changed, i.e., operational state has changed not config.  (It
is always important to read the descriptions and not to draw wrong
conclusions from the fact the SNMP notification was called
entConfigChange.)
 
> Jason Sterne also made the observation on the ML that maybe pub/sub is
> a better mechanism for these simple notifs.

Not sure what 'better' means. I assume that generating these specific
notifications can likely be done way more efficiently than doing the
same via a pub/sub interface unless the pub/sub backend code is really
really smart. That said, I would not be surprised if application
writers will use pub/sub for everything because the hammer makes
everything look like a nail.

/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 #11

[Juergen Schoenwaelder]

On Thu, Dec 15, 2016 at 04:31:10PM +0100, Martin Bjorklund wrote:
 
> > Looking at the YANG fragment, I am also not sure how useful it is to
> > carry the 32 'something' restriction forward. Note that 32 means
> > unicode characters in YANG but space of the UTF-8 encoding of
> > characters for SMIv2 (since it all ends up being a restriction for the
> > OCTET STRING). Perhaps this deserves a feature, namely, whether an
> > implementation supports flexible names or restricts names according to
> > the SMIv2 ENTITY-MIB rules.
> 
> Hmm, this cannot easily be done with a YANG feature, but maybe we can
> simply change these strings to unrestricted strings, and then state
> that a server MAY impose additional restrictions on valid values?

Yes, I would go towards less restrictions in general with a caveat
that systems implementing a direct mapping to the ENTITY-MIB MAY
impose additional length restrictions on valid values.

/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 #11

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> I do not think the goal should be to emulate SMIv2 compliance levels
> using features. So I propose to do nothing about entity4CRCompliance.

Ok.

> The other question (which should perhaps have been a separate issue)
> is whether non-existing values are indicated by zero-length strings or
> non-existing objects. I think in general we prefer to simply not
> report those objects in the YANG world.

I agree.

> If so, I am not sure whether
> the goal to not depart too much from the ENTITY-MIB overrules
> this. Note that there are a couple of objects where non-existing
> values lead to zero-length string or other special values.

I think this "depature" is fine.

> (The
> 'alias' description is kind of interesting - the server may set the
> value of this node to a locally unique value; entPhysicalAlias says
> something different, namely On the first instantiation ... is set to
> the zero-length string.)

The MIB says that the object is set to a zero-length string OR a
locally unique value.  After this a manager can change this value.  So
I believe this semantics is reflected in the YANG model (esp. if we
make it clear that a zero-length string in the MIB maps to a
non-existing node in YANG).

> Looking at the YANG fragment, I am also not sure how useful it is to
> carry the 32 'something' restriction forward. Note that 32 means
> unicode characters in YANG but space of the UTF-8 encoding of
> characters for SMIv2 (since it all ends up being a restriction for the
> OCTET STRING). Perhaps this deserves a feature, namely, whether an
> implementation supports flexible names or restricts names according to
> the SMIv2 ENTITY-MIB rules.

Hmm, this cannot easily be done with a YANG feature, but maybe we can
simply change these strings to unrestricted strings, and then state
that a server MAY impose additional restrictions on valid values?


/martin


> /js
> 
> On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Issue https://github.com/netmod-wg/entity/issues/11
> > 
> >   RFC 6933 introduced a new compliance level for constrained resources
> >   - entity4CRCompliance. Do we need a corresponding feature?
> > 
> > In YANG, we cannot to the equivalent of compliance levels, so we would
> > need to mark all nodes with some optional feature, except the few
> > nodes that a constrained device would implement.
> > 
> > OTOH, most nodes are already optional and config false.  So a
> > constrained server that doesn't know the serial number for example
> > could just no return it.  There is one catch though; the current text,
> > copied from the MIB, says e.g.:
> > 
> >If the manufacturer name string associated with the
> >physical component is unknown to the server, then this
> >node will contain a zero-length string.
> > 
> > Maybe we should change this so that the object isn't returned at all
> > instead of returning a zero-length string.
> > 
> > 
> > 
> > /martin
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> 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] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

[Martin Bjorklund]

Hi,

Dean Bogdanovic  wrote:
> Authors,
> 
> Need some clarification about applied data store
> 
> In the draft, applied data store can contain data from 
> 
> This data can come from several sources; from , from dynamic
> configuration protocols (e.g., DHCP), or from control-plane datastore.
> 
> The control-plane stores are not well clarified in my opinion
> 
>  The model foresees control-plane datastores that are by definition
>not part of the persistent configuration of a device.  In some
>contexts, these have been termed ephemeral datastores since the
>information is ephemeral, i.e., lost upon reboot.  The control-plane
>datastores interact with the rest of the system through the 
>or  datastores, depending on the type of data they
>contain.  Note that the ephemeral datastore discussed in I2RS
>documents maps to a control-plane datastore in the revised datastore
>model described here.
> 
> The other issue I have is with that control-plane data stores are
> shown connected to applied and operational-state. Which control plane
> data stores are directly influencing operational-state?

We wanted to allow for other to-be-defined data stores by showing
where they can fit into the architecture.  When/if such a data store
is defined, it can relate to this architecture and explain exactly how
it fits in and how it affects applied config and/or operational state.

> Also, in the diagram control-plane protocols are connected only to
> operational-state data store. But isn’t the previous state exchanged
> via control plane protocols taken into account when validating data
> that is copied into applied data store?

When you say "data that is copied into applied", are you referring to
the arrow between intended and applied?

The answer is that the arrows show data flow.  The mechanism that
copies data from intended to applied will surely have to check
operational state and maybe physical resources in roder to do its job.


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

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

[Juergen Schoenwaelder]

I do not think the goal should be to emulate SMIv2 compliance levels
using features. So I propose to do nothing about entity4CRCompliance.

The other question (which should perhaps have been a separate issue)
is whether non-existing values are indicated by zero-length strings or
non-existing objects. I think in general we prefer to simply not
report those objects in the YANG world. If so, I am not sure whether
the goal to not depart too much from the ENTITY-MIB overrules
this. Note that there are a couple of objects where non-existing
values lead to zero-length string or other special values. (The
'alias' description is kind of interesting - the server may set the
value of this node to a locally unique value; entPhysicalAlias says
something different, namely On the first instantiation ... is set to
the zero-length string.)

Looking at the YANG fragment, I am also not sure how useful it is to
carry the 32 'something' restriction forward. Note that 32 means
unicode characters in YANG but space of the UTF-8 encoding of
characters for SMIv2 (since it all ends up being a restriction for the
OCTET STRING). Perhaps this deserves a feature, namely, whether an
implementation supports flexible names or restricts names according to
the SMIv2 ENTITY-MIB rules.

/js

On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Issue https://github.com/netmod-wg/entity/issues/11
> 
>   RFC 6933 introduced a new compliance level for constrained resources
>   - entity4CRCompliance. Do we need a corresponding feature?
> 
> In YANG, we cannot to the equivalent of compliance levels, so we would
> need to mark all nodes with some optional feature, except the few
> nodes that a constrained device would implement.
> 
> OTOH, most nodes are already optional and config false.  So a
> constrained server that doesn't know the serial number for example
> could just no return it.  There is one catch though; the current text,
> copied from the MIB, says e.g.:
> 
>If the manufacturer name string associated with the
>physical component is unknown to the server, then this
>node will contain a zero-length string.
> 
> Maybe we should change this so that the object isn't returned at all
> instead of returning a zero-length string.
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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

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

[Martin Bjorklund]

Hi,

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

  entConfigChange is useful but maybe covered by netconf-config-change
  notification, or pub/sub. it is also a bad name, since it fires when
  the opstate changes...  Need to think about which notifs to define.

Currently we have three notifications:

  harwdare-state-change
  hardware-state-oper-enabled
  hardware-state-oper-disabled


Jason Sterne also made the observation on the ML that maybe pub/sub is
a better mechanism for these simple notifs.


/martin


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

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

[Martin Bjorklund]

Hi,

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

  RFC 6933 introduced a new compliance level for constrained resources
  - entity4CRCompliance. Do we need a corresponding feature?

In YANG, we cannot to the equivalent of compliance levels, so we would
need to mark all nodes with some optional feature, except the few
nodes that a constrained device would implement.

OTOH, most nodes are already optional and config false.  So a
constrained server that doesn't know the serial number for example
could just no return it.  There is one catch though; the current text,
copied from the MIB, says e.g.:

   If the manufacturer name string associated with the
   physical component is unknown to the server, then this
   node will contain a zero-length string.

Maybe we should change this so that the object isn't returned at all
instead of returning a zero-length string.



/martin

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

[netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

[Dean Bogdanovic]

Authors,

Need some clarification about applied data store

In the draft, applied data store can contain data from 

This data can come from several sources; from  , from dynamic 
configuration protocols (e.g., DHCP), or from control-plane datastore.

The control-plane stores are not well clarified in my opinion

 The model foresees control-plane datastores that are by definition
   not part of the persistent configuration of a device.  In some
   contexts, these have been termed ephemeral datastores since the
   information is ephemeral, i.e., lost upon reboot.  The control-plane
   datastores interact with the rest of the system through the 
   or  datastores, depending on the type of data they
   contain.  Note that the ephemeral datastore discussed in I2RS
   documents maps to a control-plane datastore in the revised datastore
   model described here.

The other issue I have is with that control-plane data stores are shown 
connected to applied and operational-state. Which control plane data stores are 
directly influencing operational-state? 

Also, in the diagram control-plane protocols are connected only to 
operational-state data store. But isn’t the previous state exchanged via 
control plane protocols taken into account when validating data that is copied 
into applied data store?

Thx

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

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[Benoit Claise]

On 12/15/2016 2:57 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

Dear draft-ietf-netmod-entity authors,

As mentioned by Tim Carey during the last IETF meeting, BBF work
depends on the draft-ietf-netmod-entity-01.

Message from BBF:

We are now in the final stages of reviewing “TR-383” “Common YANG”
modules that have the following dependencies:

  * iana-entity
  * iana-if-type
  * ietf-hardware
  * ietf-inet-types
  * ietf-interfaces
  * ietf-system
  * ietf-yang-types

If all goes to plan, the TR-383 modules will be published in March
2017, but you can see that there is a dependency on iana-entity and
ietf-hardware, which are currently taken from
draft-ietf-netmod-entity-01. We will potentially need to reference
draft versions?

I hope we all agree that referencing a draft version is not ideal.
Would it be possible to progress draft-ietf-netmod-entity, and
therefore help our BBF friends?

What we need is a WG discussion on the open issues.  I will send out
one mail per open issue.


Is the March deadline a reachable goal?

Even if we started WGLC today we would not have an RFC published in
March...

That's a very pessimistic view.
https://datatracker.ietf.org/doc/rfc8022/history/
2016-10-20, IETF WG state changed to "Submitted to IESG for 
Publication"

2016-11-10, RFC 8022 published

Regards, Benoit



/martin


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

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[Martin Bjorklund]

Benoit Claise  wrote:
> Dear draft-ietf-netmod-entity authors,
> 
> As mentioned by Tim Carey during the last IETF meeting, BBF work
> depends on the draft-ietf-netmod-entity-01.
> 
> Message from BBF:
> 
>We are now in the final stages of reviewing “TR-383” “Common YANG”
>modules that have the following dependencies:
> 
>  * iana-entity
>  * iana-if-type
>  * ietf-hardware
>  * ietf-inet-types
>  * ietf-interfaces
>  * ietf-system
>  * ietf-yang-types
> 
>If all goes to plan, the TR-383 modules will be published in March
>2017, but you can see that there is a dependency on iana-entity and
>ietf-hardware, which are currently taken from
>draft-ietf-netmod-entity-01. We will potentially need to reference
>draft versions?
> 
> I hope we all agree that referencing a draft version is not ideal.
> Would it be possible to progress draft-ietf-netmod-entity, and
> therefore help our BBF friends?

What we need is a WG discussion on the open issues.  I will send out
one mail per open issue.

> Is the March deadline a reachable goal?

Even if we started WGLC today we would not have an RFC published in
March...


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

[netmod] BBF work depending on draft-ietf-netmod-entity-01

[Benoit Claise]

Dear draft-ietf-netmod-entity authors,

As mentioned by Tim Carey during the last IETF meeting, BBF work depends 
on the draft-ietf-netmod-entity-01.


Message from BBF:

   We are now in the final stages of reviewing “TR-383” “Common YANG”
   modules that have the following dependencies:

 * iana-entity
 * iana-if-type
 * ietf-hardware
 * ietf-inet-types
 * ietf-interfaces
 * ietf-system
 * ietf-yang-types

   If all goes to plan, the TR-383 modules will be published in March
   2017, but you can see that there is a dependency on iana-entity and
   ietf-hardware, which are currently taken from
   draft-ietf-netmod-entity-01. We will potentially need to reference
   draft versions?

I hope we all agree that referencing a draft version is not ideal.
Would it be possible to progress draft-ietf-netmod-entity, and therefore 
help our BBF friends?

Is the March deadline a reachable goal?

Regards, Benoit

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