Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > On Thu, Dec 06, 2018 at 10:15:30AM +0000, Balázs Lengyel wrote: > > > > Jürgen stated that it would be better to use the YANG XML/JSON encoding > > as > > a format instead of referencing the get operation/request. I might even > > agree with him, but for 2 reasons I did not follow his idea: > > > > * Currently there is no RFC I could reference either for XML or JSON. > > AFAIK even RFC7951 does not define how multiple modules should be > > encoded side by side. > > * It is not the job of the instance data draft to dictate how to encode > > YANG data generally e.g. on the wire. > > * The contents of the get operation/request are well defined > > > > The first bullet needs to be taken care of but it is not too difficult > I think. > > I fail to understand what bullet two is about or why it matters. We > are talking about the instance file format, no more and no less. > > Yes, the contents of the get operation/request are well defined but > the definitions are not generically applicable to define instance file > formats and the dependincy of the instance file format on protocols > is problematic from a maintenance perspective.
I agree. I'm not even convinced that the current text is clear and correct: The content-data part of the XML format SHALL follow the format returned for a NETCONF GET operation. The <content-data> anydata node SHALL contain all elements that would be inside the <data> wrapper element of a reply to the <get> operation. What exactly does "all elements that would be inside the <data>" mean? Does it mean that if a server supports 10 modules, all 10 modules MUST be part of all instance files? Probably not. Since the "content-data" is of type "anydata", I think that we don't need much additional text. Maybe something like: The "content-data" part may contain data from multiple modules, in any order. For any node in "content-data", the path from the data model root node down to the node, including any elements necessary to uniquely identify the node, is included in the response message. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod