Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)" <bart.bogaert@nokia.com> Tue, 24 January 2017 10:29 UTC

Return-Path: <bart.bogaert@nokia.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894B9129586 for <netmod@ietfa.amsl.com>; Tue, 24 Jan 2017 02:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level:
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVDr4W1twiDr for <netmod@ietfa.amsl.com>; Tue, 24 Jan 2017 02:29:05 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B955A12949E for <netmod@ietf.org>; Tue, 24 Jan 2017 02:29:04 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 627ECFAB4EABA; Tue, 24 Jan 2017 10:29:00 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0OAT2DZ001489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 10:29:02 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0OASjsx022060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 10:28:58 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 11:28:53 +0100
From: "Bogaert, Bart (Nokia - BE)" <bart.bogaert@nokia.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHUN8Q///73ACAABOm0P//88OAgAAZaeA=
Date: Tue, 24 Jan 2017 10:28:52 +0000
Message-ID: <D62E05768DBAFF42A72B9F4954476D65010EB1F6F6@FR712WXCHMBA09.zeu.alcatel-lucent.com>
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com> <D62E05768DBAFF42A72B9F4954476D65010EB1F592@FR712WXCHMBA09.zeu.alcatel-lucent.com> <20170124.102800.608993362937407790.mbj@tail-f.com> <D62E05768DBAFF42A72B9F4954476D65010EB1F63E@FR712WXCHMBA09.zeu.alcatel-lucent.com> <20170124095431.GA35667@elstar.local>
In-Reply-To: <20170124095431.GA35667@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_016A_01D27635.09616DD0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EGK2z7ycxKl9uQwWY-1d5FOruag>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2017 10:29:07 -0000

Juergen,

I've been discussing internally here after observing that the current action
definition has no output and hence it is not possible to report whether the
reset is supported for a specific hardware instance.  Further reflection is
required on this.

Best regards - Vriendelijke groeten,
Bart Bogaert
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: 24 January 2017 10:55
To: Bogaert, Bart (Nokia - BE) <bart.bogaert@nokia.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Assuming that not all hardware components support the same set of reset
types (or resets at all), how do I find out which reset types I can apply to
a specific hardware component? Or is the idea to let the management system
do trial and error pushing of reset buttons?

/js

On Tue, Jan 24, 2017 at 09:48:00AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 24 January 2017 10:28
> To: Bogaert, Bart (Nokia - BE) <bart.bogaert@nokia.com>
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> "Bogaert, Bart (Nokia - BE)" <bart.bogaert@nokia.com> wrote:
> > Hi,
> > 
> > If I'm not mistaken, the following BBF addition was also proposed as 
> > to be added to the IETF entity model.  Is there no consensus about 
> > this
> one?
> 
> Not many spoke up.  I think there was just one comment, and that was 
> not in favor of adding this.
> [Bart Bogaert] Ok... don't these people require the need to offer an 
> explicit reset capability of a HW entity to operators?  I would expect 
> that this is something that could be made available generically 
> (possibly under a feature if not everybody wants to implement this) 
> rather than having various own implementations to achieve the same...
> 
> Bart
> 
> /martin
> 
> 
> > 
> > 1. Enabling a reset of an entity by means of an action
> > 
> > module bbf-entity-reset-action {
> >   yang-version 1.1;
> > 
> >   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> > 
> >   prefix "bbf-entity-reset-action";
> > 
> >   import ietf-entity {
> >     prefix ent;
> >   }
> >   ...
> > 
> >   identity reset-type {
> >     description
> >         "Type of reset requested of entity.  Examples of resets can be:
> >            hardware-reset, reset-with-selftest, reset-without-selftest,
> >            software-reset, possibly others.";
> >   }
> > 
> >   identity hardware-reset {
> >     base reset-type;
> >     description
> >         "Hardware reset";
> >   }
> > 
> >   augment "/ent:entity-state/ent:physical-entity" {
> >     description
> >         "Augment entity model with an action to request a reset of the
> >           entity";
> >     action reset {
> >       description "Request a reset of the entity";
> >       input {
> >         leaf reset-type {
> >           type identityref {
> >             base "reset-type";
> >           }
> >             description
> >                 "Type of reset requested of entity";
> >         }
> >       }
> >     }
> >   }
> > }
> > 
> > Best regards - Vriendelijke groeten, Bart Bogaert
> > 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin 
> > Bjorklund
> > Sent: 23 January 2017 11:59
> > To: j.schoenwaelder@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> > 
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > Hi,
> > > 
> > > I wonder when we use 'state' and when 'status' - is there a subtle 
> > > distinction or should be just consistently use lets say 'state', 
> > > i.e., changed to alalarm-status to alarm-state and standby-status 
> > > to standby-state?
> > 
> > The reason in this case is that we just used the MIB names.  This 
> > said, I agree that "standby-state" and "alarm-state" are better.
> > 
> > BTW, RFC 4268, which defines the original objects, says:
> > 
> >    The terms "state" and "status" are used interchangeably in this memo.
> > 
> > 
> > > I also wonder about the mapping of the MIB object names to YANG 
> > > leaf
> > > names:
> > > 
> > >
+-------------------------------------+-----------------------------+
> > >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object
|
> > >    | state/component/sensor-data         |
|
> > >
+-------------------------------------+-----------------------------+
> > >    | data-type                           | entPhySensorType
|
> > >    | data-scale                          | entPhySensorScale
|
> > >    | precision                           | entPhySensorPrecision
|
> > >    | value                               | entPhySensorValue
|
> > >    | oper-status                         | entPhySensorOperStatus
|
> > >    | sensor-units-display                | entPhySensorUnitsDisplay
|
> > >    | value-timestamp                     | entPhySensorValueTimeStamp
|
> > >    | value-update-rate                   | entPhySensorValueUpdateRate
|
> > >    
> > > +-------------------------------------+-----------------------------+
> > > 
> > > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > > for 'precision' (scale and precision really go hand in hand).
> > 
> > Unclear.  I think I'm the one to blame for this inconsistency, and 
> > it goes back to the very first commit, but I can't remeber why.
> > 
> > > Why is it
> > > 'sensor-units-display' and not just 'units-display'? One option 
> > > could
> > > be:
> > > 
> > >   value-type
> > >   value-scale
> > >   value-precision
> > >   value
> > >   oper-status
> > >   units-display
> > >   value-timestamp
> > >   value-update-rate
> > 
> > Yes this is better.
> > 
> > > RFC 3433 points out that entPhySensorType and entPhySensorScale 
> > > and entPhySensorPrecision SHOULD NOT change during operation. What 
> > > about the YANG objects? I actually do not know what the SHOULD 
> > > buys a client since you can't rely on it. To be robust, you have 
> > > to fetch an n-tuple anyway and be prepared that a sensor may have 
> > > changed its
> properties.
> > > Should there be explicit text providing guidance that it is better 
> > > to fetch the whole n-tuple?
> > 
> > This is certainly the simplest solution.   Any comments?
> > 
> > > Or alternatively, if supporting caching of values is a goal, we 
> > > may need to provide a 'sensor-data/properties-last-changed' object 
> > > that allows to make caching of value properties robust.
> > 
> > 
> > /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         <http://www.jacobs-university.de/>