Re: [sacm] [sacmwg/draft-ietf-sacm-terminology] defining configuration (#31)

Henk Birkholz <notifications@github.com> Fri, 08 June 2018 12:46 UTC

Return-Path: <noreply@github.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04750124D68 for <sacm@ietfa.amsl.com>; Fri, 8 Jun 2018 05:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 1A5CUReM7vst for <sacm@ietfa.amsl.com>; Fri, 8 Jun 2018 05:46:04 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F129124C04 for <sacm@ietf.org>; Fri, 8 Jun 2018 05:46:04 -0700 (PDT)
Date: Fri, 08 Jun 2018 05:46:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1528461963; bh=1wVoWt4iMi5CK1yk5eNwT/use6KxiV2oJLk1mP66iWg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PJwpf8q0YMwvSOcYsFRw+rG0mkqSahvwSRpuoB6kbRIBy81BOz73gu4rNmLOu3aw8 tpofl0ULJA766cdFiR/MJ9RvCUiCnL1fOYxRrtekwAArqC6RozknXRMtF11XR0PYhN wmcPyWqp9/46Z17lsi36o1SQ8c6ea55IHmSewJG0=
From: Henk Birkholz <notifications@github.com>
Reply-To: sacmwg/draft-ietf-sacm-terminology <reply+00a6c4d144a2e92942bdb3d5c2a4ec3d6fc38134db8711c092cf0000000117323c8b92a169ce0866c5bd@reply.github.com>
To: sacmwg/draft-ietf-sacm-terminology <draft-ietf-sacm-terminology@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <sacmwg/draft-ietf-sacm-terminology/issues/31/395749990@github.com>
In-Reply-To: <sacmwg/draft-ietf-sacm-terminology/issues/31@github.com>
References: <sacmwg/draft-ietf-sacm-terminology/issues/31@github.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b1a7a8ba06a6_73cf2b206fd24f509382f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: henkbirkholz
X-GitHub-Recipient: sacm
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: sacm@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/0zEnBD2YEtZcQUi1cNYXxjg3Z_A>
Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-terminology] defining configuration (#31)
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.26
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 12:46:08 -0000

NMDA is an RFC now (that took longer than expected).

In general, I'd recommend to read this section and its sub-sections:
https://tools.ietf.org/html/rfc8342#section-5

This is the taxonomy of configuration from NMDA in a nutshell:
* Conventional Configuration
  * running
  * candidate
  * startup
  * intended
* Dynamic Configuration (configuration that does not survive a boot-cycle but is not state....)
* Operational Configuration (configuration and its state (!) that is actually used by the target endpoint)
* "some important flavors of configuration that seem to have no parent term"....
  * learned configuration: neither dynamic configuration nor conventional configuration....)
  * system configuration: configuration that is supplied by the hardware components themselves)
  * default configuration: configuration that is not explicitly provided, but a default value exists)
  * applied configuration: configuration that is actively in use by a device.

As a complement there is:
* system state: the additional data on a system that is not configuration, such as read-only status
  information and collected statistics. System state is transient and modified by interactions with
  internal components or other systems.
This is pretty much what SACM always defined as State.

In essence, the configuration interesting to SACM is "applied configuration" and then the "system state".

The composite of both is actually also defined by NMDA:
* operational state: The combination of applied configuration and system state.

In consequence, my proposal is to directly adopt the three terms "applied configuration", "system state" and "operational state". Alternatively, we could just retain configuration and highlight that it means applied configuration and retain state and highlight that is means system state.

The term "operational state" would be a new addition and basically refer to the composite of current configuration and current state -> a big chunk of our collectible target endpoint attributes.

There might be a few types of conventional configuration (e.g. not activated features or inactive configuration) that I cannot personally map to the NMDA terminology. But maybe a more proficient group member can? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-terminology/issues/31#issuecomment-395749990