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

Martin Bjorklund <mbj@tail-f.com> Thu, 21 December 2017 11:58 UTC

Return-Path: <mbj@tail-f.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 228A112421A for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 03:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 cmHrgtSAiMWb for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 03:58:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 808B112D848 for <netmod@ietf.org>; Thu, 21 Dec 2017 03:58:27 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 69DAF1AE0311; Thu, 21 Dec 2017 12:58:26 +0100 (CET)
Date: Thu, 21 Dec 2017 12:58:26 +0100 (CET)
Message-Id: <20171221.125826.1295894140821866805.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20171221115010.annbhb4vs3roo4dk@elstar.local>
References: <cb06b12e-59d9-148e-03f0-2ffdb1e4e15f@cisco.com> <20171221.123746.382540578845045602.mbj@tail-f.com> <20171221115010.annbhb4vs3roo4dk@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gfxU-SSD5x867h67fQRTvX63OEw>
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 11:58:29 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, Dec 21, 2017 at 12:37:46PM +0100, 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.
> > 
> > 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).
> 
> The last sentence is not useful since nobody knows what 'preferred'
> value means. So remove it.

This text comes from RFC 6933.  Do you really think it is not clear
what the intention is?

> >            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.
> 
> I do not think 'post-it' note helps to clarify things. What about
> changing the second sentence to:
> 
>   The configured value is used only if the server cannot determine the
>   vendor-specific serial number from the component itself.

Works for me.

> I do not understand the pre-provisioning part. Something
> pre-provisioning won't appear in <operational> and when it appears,
> then the normal rules apply, no?

Yes.


> 
> >            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.";
> 
> This may not be needed if we use the above formulation.

Agreed.  So we'd have a single paragraph:

   This leaf can be configured.  The configured value is used only if
   the server cannot determine the vendor-specific serial number from
   the component itself.


/martin