Re: [netmod] AD review of draft-ietf-netmod-entity-06

Robert Wilton <rwilton@cisco.com> Thu, 21 December 2017 15:13 UTC

Return-Path: <rwilton@cisco.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 BB05912D88D for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 07:13:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NsXWi6_i9oAn for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 07:13:45 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7487B12D886 for <netmod@ietf.org>; Thu, 21 Dec 2017 07:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8836; q=dns/txt; s=iport; t=1513869224; x=1515078824; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=c35SJTPeRy9/4CnQf/k2oG67u8frGh13vhjIvl8th9g=; b=OCmGZx/iJiuhYYsGjfuCSXojsAPz6a8Hp77ZSX3PictZedOgpXZH0jy3 KJFnRrImum0EpAYnO5dSWrplmzjzN++W9RISec+rckpc0bGpCOGsJ55wj vkdTVwktQmbRzeFEFTGNuvFl3am8mw1mKVCxWWEhnygl6fnrKWYg5+c3u o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQD3zjta/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBosYkB2ZPgoYC4FegmtPAoUMFQEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEDAQEBIQ8BBTYbCw4KAgImAgInMAYBDAYCAQEWigkIEKRbgieKbgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQ+CcINogWkpgwWDLwGBTgEBCIMtgmUFilyHQZE?= =?us-ascii?q?riAGNLoIXigEkhz6NIYFZiAWBOzUjgU8yGggbFTyCKYRXQTeHXII7AQEB?=
X-IronPort-AV: E=Sophos;i="5.45,436,1508803200"; d="scan'208";a="1069550"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2017 15:13:35 +0000
Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBLFDZ53025390; Thu, 21 Dec 2017 15:13:35 GMT
To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <fd46c4ab-5c43-1b61-2b00-ca71f13fc932@cisco.com> <20171220.160020.956270997417344353.mbj@tail-f.com> <cb06b12e-59d9-148e-03f0-2ffdb1e4e15f@cisco.com> <20171221.123746.382540578845045602.mbj@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com>
Date: Thu, 21 Dec 2017 15:13:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171221.123746.382540578845045602.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yHy8yJqgiRcRfn0QVlCP0fhEfzc>
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 21 Dec 2017 15:13:47 -0000

Hi Martin,


On 21/12/2017 11:37, Martin Bjorklund wrote:
> Hi,
>
> I need WG input on this issue.  The question is how to handle
> 'serial-num', 'mfg-name', and 'model-name'.  I think they should all
> be treated the same.  Based on previous WG discussion (see e.g. the
> mail thread "draft-ietf-netmod-entity issue #13"), I think they should
> all be configurable, but the configured value is only used in
> operational state if the system cannot read it from the hardware.
I think that this approach is probably OK:
  - The client can always see the real value if it is available.
  - If it is not available then they can assign a value via configuration.

I was also considering an alternative approach of having a separate set 
of config false leaves for the "burnt in values".  And then having the 
configurable leaves always override the default operational values.  
E.g. similar to how an interface MAC address would expect to be handled.

But one set of leaves is probably sufficient.

Thanks,
Rob


>
> So I suggest the following changes:
>
> OLD:
>
>        leaf serial-num {
>          type string;
>          config false;
>          description
>            "The vendor-specific serial number string for the
>             component.  The preferred value is the serial number
>             string actually printed on the component itself (if
>             present).";
>          reference "RFC 6933: entPhysicalSerialNum";
>        }
>
> NEW:
>
>        leaf serial-num {
>          type string;
>          description
>            "The vendor-specific serial number string for the
>             component.  The preferred value is the serial number
>             string actually printed on the component itself (if
>             present).
>
>             This leaf can be configured.  There are two use cases for
>             this; as a 'post-it' note if the server cannot determine
>             this value from the component, or when pre-provisioning a
>             component.
>
>             If the server can determine the serial number from the
>             component, then that value is always used in operational
>             state, even if another value has been configured.";
>          reference "RFC 6933: entPhysicalSerialNum";
>        }
>
> And corresponding text for 'mfg-name' and 'model-name'.
>
> And also:
>
> OLD:
>
>           When the server detects a new hardware component, it
>           initializes a list entry in the operational state.
>
>           If the server does not support configuration of hardware
>           components, list entries in the operational state are
>           initialized with values for all nodes as detected by the
>           implementation.
>
>           Otherwise, the following procedure is followed:
>
>             1. If there is an entry in the /hardware/component list in
>                the intended configuration with values for the nodes
>                'class', 'parent', 'parent-rel-pos' that are equal to
>                the detected values, then:
>
>             1a. If the configured entry has a value for 'mfg-name'
>                 that is equal to the detected value, or if the
>                 'mfg-name' value cannot be detected, then the list
>                 entry in the operational state is initialized with the
>                 configured values for all configured nodes, including
>                 the 'name'.
>
>                 Otherwise, the list entry in the operational state is
>                 initialized with values for all nodes as detected by
>                 the implementation.  The implementation may raise an
>                 alarm that informs about the 'mfg-name' mismatch
>                 condition.  How this is done is outside the scope of
>                 this document.
>
>             1b. Otherwise (i.e., there is no matching configuration
>                 entry), the list entry in the operational state is
>                 initialized with values for all nodes as detected by
>                 the implementation.
>
>           If the /hardware/component list in the intended
>           configuration is modified, then the system MUST behave as if
>           it re-initializes itself, and follow the procedure in (1).";
>
> NEW:
>
>           When the server detects a new hardware component, it
>           initializes a list entry in the operational state.
>
>           If the server does not support configuration of hardware
>           components, list entries in the operational state are
>           initialized with values for all nodes as detected by the
>           implementation.
>
>           Otherwise, the following procedure is followed:
>
>             1. If there is an entry in the /hardware/component list in
>                the intended configuration with values for the nodes
>                'class', 'parent', 'parent-rel-pos' that are equal to
>                the detected values, then the list entry in operational
>                state is initialized with the configured values,
>                including the 'name'.  The leafs 'serial-num',
>                'mfg-name', and 'model-name' are treated specially; see
>                their descriptions for details.
>
>             2. Otherwise (i.e., there is no matching configuration
>                entry), the list entry in the operational state is
>                initialized with values for all nodes as detected by
>                the implementation.
>
>           If the /hardware/component list in the intended
>           configuration is modified, then the system MUST behave as if
>           it re-initializes itself, and follow the procedure in (1).";
>
>
>
> /martin
>
>
>
>
> Benoit Claise <bclaise@cisco.com> wrote:
>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
>>> Benoit Claise <bclaise@cisco.com> wrote:
>>>> Hi Martin,
>>>>
>>>> Thanks.
>>>> Only kept the relevant excerpts.
>>>>>> - Some objects are read-write in RFC6933:
>>>>>>          entPhysicalSerialNum
>>>>>>          entPhysicalAlias
>>>>>>          entPhysicalAssetID
>>>>>>          entPhysicalUris
>>>>>>
>>>>>> For example, entPhysicalSerialNum being read-write always bothered me.
>>>>>> serial-num is now "config false", which is a good news IMO.
>>>>> Actually, this was not the intention.  In draft-ietf-netmod-entity-03
>>>>> this is configurable.  I missed this in the conversion to NMDA.
>>>> Ah. So no good news in this case...
>>>>>> In the reverse direction, entPhysicalMfgName is read-only in RFC6933,
>>>>>> while it's "config true" in draft-ietf-netmod-entity
>>>>> Yes, this was added per request from the WG.  See e.g. the thread
>>>>> "draft-ietf-netmod-entity issue #13".
>>>> Sure. It was mainly an observation.
>>>>> However, I think that what we have now is probably not correct.  I
>>>>> think that all nodes 'serial-num', 'mfg-name', and 'model-name' should
>>>>> be config true, and the description of list 'component' updated to
>>>>> reflect that all these tree leafs are handled the same way.
>>>>>
>>>>> I would like to know what the WG thinks about this.
>>>> Talking as a contributor this time.
>>>> It seems that inventory management is kind of broken when someone can
>>>> change 'serial-num', 'mfg-name', and 'model-name.
>>> They can't really change them.  The configured values are only used
>>> (i.e. visible in the operational state) if the device cannot detect
>>> them automatically.  I.e., they work as "post-it" notes only.
>> If I look at, for example, the mfg-name, description, this is not what
>> it says.
>>
>>     leaf mfg-name {
>>             type string;
>>             description
>>               "The name of the manufacturer of this physical component.
>>                The preferred value is the manufacturer name string
>>                actually printed on the component itself (if present).
>>
>>                Note that comparisons between instances of the model-name,
>>                firmware-rev, software-rev, and the serial-num nodes are
>>                only meaningful amongst component with the same value of
>>                mfg-name.
>>
>>                If the manufacturer name string associated with the
>>                physical component is unknown to the server, then this
>>                node is not instantiated.";
>>             reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
>>             entPhysicalMfgName";
>>
>> Regards, Benoit
>>
>>>
>>> /martin
>>> .
>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>