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

From: henkbirkholz <[email-masked]>
Date: Fri, 13 Jan 2017 07:26:30 -0800

first draft is now in the editor's version (including a corresponding definition of state)

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

---

From: henkbirkholz <[email-masked]>
Date: Fri, 13 Jan 2017 07:46:21 -0800

Please note that:

1.) the NETMOD wg started to define provenance metadata ("origin") in https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/, which also includes

2.) a definition of static configuration data ("data that determines how a device behaves. Configuration data can originate from different sources. In YANG 1.1, configuration data is the "config true" nodes.").

Some of the terminology defined in draft-ietf-netmod-revised-datastores-00 does not align very well with our definitions. I am under the impression that the "dynamic configuration" defined in the document ("obtained dynamically during the operation of a device through interaction with other systems and not persistent.") is actually state.

The draft provides good examples of state in cases where configuration consists of the selection of an available automation feature that results in a specific state (section 7.1.). "auto-negotiation of link speed" is one of them.

For now, I tried to address the discrepancy by highlighting in our definition of state that dynamic configuration is state. We should reach out and try to find out the line of thought behind the terminology in draft-ietf-netmod-revised-datastores-00 (including the choice of the term "origin", which is seems to be the equivalent to our term "data source"). 

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

---

From: adammontville <[email-masked]>
Date: Sat, 28 Jan 2017 03:32:16 -0800

I like that they're decomposing "configuration data", but I do not follow the decomposition as defined.  Reaching out seems like a good idea.  @henkbirkholz did you have a recommendation about how such outreach should be done?  I'm happy to do so initially, but I presume one of our terminology authors would then be in the loop with one of the draft-ietf-netmod-revised-datastores-00 authors...

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