Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Mar 09, 2020 at 04:17:40PM +0000, Balázs Lengyel wrote:
> See BALAZS4 below
> 
> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]> 
> Sent: 2020. március 9., hétfő 10:44
> To: Balázs Lengyel <[e-mail]>
> Subject: Re: [netmod] WG Last Call:
> draft-ietf-netmod-yang-instance-file-format-06
> 
> > > -----Original Message-----
> > > From: Schönwälder, Jürgen <[e-mail]>
> > > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>