-----邮件原件----- 发件人: Juergen Schoenwaelder [mailto:[email protected]] 发送时间: 2019年5月20日 14:20 收件人: Qin Wu <[email protected]> 抄送: [email protected] 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
On Mon, May 20, 2019 at 05:57:02AM +0000, Qin Wu wrote: > -----邮件原件----- > 发件人: Juergen Schoenwaelder > [mailto:[email protected]] > 发送时间: 2019年5月17日 19:15 > 收件人: Qin Wu <[email protected]> > 抄送: [email protected] > 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt > > I think this does not work: > > [...] For <copy-config> operation,it can be used to copy > the factory default content to another datastore, however the > content of the datastore is not propagated automatically to any > other datastores. > > You can't change the way things work. If something is committed to lets say > <running>, then this triggers the propagation to <intended> and eventually > <operational>. You can't come along and say that copy-config from a > particular source stops this. > [Qin]:Automatic propagation we were referred to is that when we have > three datastores, let's say datastore A, datastore B, datastore C, one time > <copy-config> operation can not copy content of datastore A to datstore B and > datastore C at the same time, But you are right, content of <running> will be > automatically propagated to <intended> and <operational>, we will see how to > tweak the text. This is not what the text says. And given the parameters of copy-config, it is obvious that you can't copy to multiple datastores. > Is it really useful to expose factory default to copy config? Or said > differenlty, would it not make sense to fix copy-config (at some other > place) so that it can generically work with new datastores? > [Qin]: Note that this is just an option feature to <copy-config> to assign > one single target datastore with factory default content, I am wondering why > it can not be defined in this draft in a more generic way? > Even in RFC6241bis or a separate draft, if you add this feature support to > <copy-config>, you will augment <copy-config> in the same way, if my > understanding is correct. No. You would allow any datastore, not a specific one. [Qin]: I see, I think we could put such generic extension in this draft? e.g., define "leaf any" > The content of the factory-default datastore is usually not security > sensitive as it is the same on any device of a certain type. > > I am not sure this is true. > > For non-trivial devices, the default is likely not static but something that > takes into account device features available and the specific hardware > configuration present. It is actually somewhat unclear what the > factory-default datastore contains; the stuff I can expect to see in > <running> after the reset or some static stuff that may be tweaked during the > boot process to yield the initial <running>. > Or are we pretending these two are always the same? > [Qin]: We emphasize "usually not", to address your comments, we could add: > " > When its contents are considered sensitive, It is RECOMMENDED that the > factory default Data is encrypted." You propose to invent another layer of encryption??? [Qin]: Not my intention, I think factory default data may have be encrypted already. We could reuse it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
