Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Jan 2018 05:05:09 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-revised-datastores-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

      protocol interactions with other systems and that is neither
      conventional nor dynamic configuration.
Could you provide an example of this?

   datastore that holds the complete current configuration on the
   device.  It MAY include configuration that requires further
   transformation before it can be applied, e.g., inactive

If I am reading the text, this doesn't seem to be true because "system
configuration" is not included.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2018 14:15:42 +0100

Many DHCP implementations do not go through a dynamic datastore and
deliver configuration state straight into the operational state. An IP
address learned via DHCP on such a system will be tagged with
or:learned.
 
> configuration" is not included.
 
Yes, it might make sense to remove 'complete' here to align the
sentence in 5.1.3 with the definition of 'running configuration
datastore'.

/js

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Jan 2018 07:00:18 -0800

> address learned via DHCP on such a system will be tagged with

I don't think it's imperative, but it would be nice to have this example in
the
text.

> sentence in 5.1.3 with the definition of 'running configuration

Thanks,

-Ekr

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2018 17:18:13 +0100

> I don't think it's imperative, but it would be nice to have this example in

There is more explanatory text in section 5.3.4 and I believe this
should be sufficient:

   o  learned: represents configuration that has been learned via
      protocol interactions with other systems, including protocols such
      as link-layer negotiations, routing protocols, DHCP, etc.

/js