On Mon, Mar 09, 2020 at 04:17:40PM +0000, Balázs Lengyel wrote: > See BALAZS4 below > > -----Original Message----- > From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> > Sent: 2020. március 9., hétfő 10:44 > To: Balázs Lengyel <balazs.leng...@ericsson.com> > Subject: Re: [netmod] WG Last Call: > draft-ietf-netmod-yang-instance-file-format-06 > > > > -----Original Message----- > > > From: Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de> > > > Sent: 2020. február 12., szerda 10:07 > > > Subject: [Not Scanned] - Re: [netmod] WG Last Call: > > > draft-ietf-netmod-yang-instance-file-format-06 > > > > > > > - Is it necessary to describe P2 in terms of (presumably) NETCONF > > > > operations? I would prefer to have the document written in a > > > > protocol agnostic style. Perhaps simply drop "similar to the > > > > response of a <get> operation/request". > > > > BALAZS: This is a reference both to NETCONF and RESTCONF. It was > > > > explicitly asked for by other reviewers. > > > > > > Well, then the correct wording would be "similar to the response of > > > a NETCONF <get> operation or the RESTCONF response to a GET method > > > invocation on the (unified) datastore resource". Sounds complex and > > > I still prefer the text to be agnostic to specific operations - in > > > particular since <get> and the unified datastore have their > > > limitations. The format is simply reusing the already defined data > > > model encoding formats, i.e., the format has nothing to do with the > > operations used to retrieve the data. So I suggest: > > > > > > P2 Instance data shall reuse existing encoding rules for > > > YANG defined data. > > > > > > There is no need to refer to specific protocol operations. > > > BALAZS: I will use both of your texts. That is the most common > > > question I > > > get: Will this use the same format as a get-reply? People like to > > > think in terms of a specific easy-to-grasp function instead of a > > > non-descript set of "existing" rules. Existing means you need to > > > understand X number of RFCs, while just looking up a get-reply is > > > easy. It is not precise, but IMHO that's how people think. > > > > If you write "reuse existing encoding rules", then actually fewer > > documents need to be understood. And operations have additional issues > > in how they interact with 'datastores', so they may even be misleading > > and I rather have the standards precise (and minimal normative > dependencies). > > BALAZS3: Sorry, I don't fully understand your point. What would you > > like in P2? > > The text now is: > > P2 Instance data shall reuse existing encoding rules for YANG > > defined data. Its format will be similar to the response of a > > NETCONF <get> operation or the RESTCONF response to a GET method > > invocation on the (unified) datastore resource. > > It refers to existing rules as you asked for and also says" similar" > > to a get response, using phrasing from your email on 2020-02-12. > > Are you OK with this? Or how would you like to change it? > > What I proposed above: > > P2 Instance data shall reuse existing encoding rules for > YANG defined data. > > Your additional sentence is simply wrong. Instance data from lets say > <operational> with _not_ be 'similar' to the response of a NETCONF <get> > operation or the RESTCONF response to a GET method invocation on the > (unified) datastore resource. The same holds true for instance data from > <running>. > BALAZS4: I would like to keep the second part of the sentence. > 4+ people asked me explicitly to state this similarity during the > development of the draft. While your methodical and somewhat abstract way of > thinking has greatly helped me/us in many cases, IMHO other people often > think in the terms of examples and in recognizing known similar > methodology. As the we use the same encoding rules for get replies and for > instance data, IMHO they are similar even if instance data allows some > additions/omissions. (People liked/requested this statement, even though > "similar" is a rather subjective term.) > Anyway it is only included in the introduction part, so while it helps some > people, it should not cause problems with the precise definition of the > format. On your request I already removed a similar statement from the > normative parts.
What the sentence says is unclear or plain wrong in a number of valid use cases (depends on how one understands the word "similar") and thus this sentence is misleading and asking for trouble down the road. I fully understand the value of examples but here we define what is called a 'basic principle' - and a basic principle that is not quite correct for all use cases sounds like a bad idea to me. If you want to write an example after the principles that is identifiable as an example, I am fine with that. As the sentence is worded right now as part of a 'basic principle', I am having an issue with the 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
