Hi Tom,
Thanks a lot for providing your opinion. Actually this new YANG model is similar to the one defined in rfc7317( [email protected]) and mainly will be used for Network node management. This will help the administrator for network automation using the YANG model as current method of upgrade may be through CLI. We have below container in this YANG model that give the information about the current system state > /* > * Operational state data nodes > */ > > container system-state { > config false; > description > "System group operational state."; > > container platform { > description > "Contains vendor-specific information for > identifying the system platform and operating system."; > reference > "IEEE Std 1003.1-2008 - sys/utsname.h"; > leaf os-name { > type string; > description > "The name of the operating system in use - > for example, 'Linux'."; > reference > "IEEE Std 1003.1-2008 - utsname.sysname"; > } > leaf os-release { > type string; > description > "The current release level of the operating > system in use. This string MAY indicate > the OS source code revision."; > reference > "IEEE Std 1003.1-2008 - utsname.release"; > } > leaf os-version { > type string; > description > "The current version level of the operating > system in use. This string MAY indicate > the specific OS build date and target variant > information."; > reference > "IEEE Std 1003.1-2008 - utsname.version"; > } > leaf machine { > type string; > description > "A vendor-specific identifier string representing > the hardware in use."; > reference > "IEEE Std 1003.1-2008 - utsname.machine"; > } > } For example the leaf os-release current value is 2.0(returned by the device through NETCONF <get> operation) and now the system administrator would like to upgrade to a new value 2.4. So I feel the [email protected] does not provide an option to change to different version. I just thought that the new YANG model can bridge this gap. Also most of the devices will have the same set of information(new image, config file, paf file and patch) as per my knowledge. Regards, Shiva On Wed, 20 Feb 2019 at 15:59, tom petch <[email protected]> wrote: > > ----- Original Message ----- > From: "Shiva Kumar Pathori" <[email protected]> > To: <[email protected]> > Sent: Tuesday, February 19, 2019 1:40 PM > > > I think there is a need to extend the ietf-system.yang or have new > model to > > get the current system startup information(like current system > software > > name, configuration file name, paf file name and patch file name > etc..) > > from the device and also set the next startup information for upgrade. > This > > can help the device administrator during system upgrade scenario to > operate > > with the YANG model. So first step will be copying these files(image, > > config file, paf file and patch file) to the device and then set the > next > > startup information. After this YANG RPC > "/ietf-system/system-restart" > > can be used to reboot the system to upgrade to the new version. > > > > I request the WG to provide the opinion on this. > > Shiva > > The IETF is good at protocols, what must go on between boxes of > different origins else they do not work. The internals of those boxes > have no such need to be standardised and while the IETF does delve into > those areas, e.g. Host MIB module or, arguably, much of the routing YANG > module, it is less successful because, well, there is no need for them > to be standardised for the Internet to work. > > So, a YANG module for startup information would need find common ground > between, say, iPhone, Juniper router, Windows 10, Linux distro and so on > when those products work quite happily with radically different views of > what is needed. I recall one discussion which failed to get agreement > on what the order of precedence of the fields version, release, level; > different manufacturers have different interpretations thereof while any > one manufacturer will likely be consistent in their usage across a wide > range of hardware and software products. > > Thus it seems more likely an area for proprietary extensions than for > the IETF. > > Tom Petch > > > Regards, > > Shiva > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
