Juergen,
On on side, Balazs mentions:
4+ people asked me explicitly to state this similarity during the
development of the draft.
The current text 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.
This modification is based on your feedback:
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
On the other side, you insist now on removing the latter sentence.
Could you propose a similar sentence that would satisfy your concern?
Regards, Benoit
On Mon, Mar 09, 2020 at 04:17:40PM +0000, Balázs Lengyel wrote:
See BALAZS4 below
-----Original Message-----
From: Juergen Schoenwaelder <[email protected]>
Sent: 2020. március 9., hétfő 10:44
To: Balázs Lengyel <[email protected]>
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06
-----Original Message-----
From: Schönwälder, Jürgen <[email protected]>
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
