Requirements for mounting of local and remote YANG subtrees
draft-voit-netmod-yang-mount-requirements-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Eric Voit , Alexander Clemm , Sander Mertens | ||
Last updated | 2016-09-19 (Latest revision 2016-03-18) | ||
Replaces | draft-voit-netmod-peer-mount-requirements | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Applications want simple ways to reference and access YANG objects and subtrees. These simplifications might include aliasing of local YANG information. These simplifications might include remote referencing of YANG information distributed across network. For such applications, development complexity is a barrier to YANG usage and therefore must be minimized. Specific aspects of complexity developers want to ignore include: o whether context specific aliases and paths to the same information can be exposed on a single device, o whether authoritative information is actually sourced from local or remote datastores, o whether the application needs to manage the overhead of session establishment and maintenance in order to access information on remote datastores, o whether objects have been locally cached or not, and o whether there is a mix of controllers, NMSs, and/or CLI which have access permission to update the primary copy of a particular object. The solution requirements described in this document detail what is needed to support application access to authoritative network YANG objects locally (via aliasing), or remotely from controllers or peering network devices in such a way to meet these goals.
Authors
Eric Voit
Alexander Clemm
Sander Mertens
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)