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.
--------------------------------------------
> > > - Why MUST XML attributes be ignored, why is there no text about
> > > unknown JSON data, 'attributes' (or annotations)? What should
> > > implementations generally do about unknown elements, attributes,
> > > objects, arrays, ...)? Why are we specific about only one specific
> > > case?
> > > BALAZS: Generally we want to allow users/creators to decorate the
> > > data with additional information, that is not standardized. Like
> > > YANG extensions these may be useful, but at least should not
> > > cause
> problems.
> > > XML attributes are often used as meta-data and I was asked to list
> > > them specifically.
> > >
> > I do not understand why there are specific rules for XML encodings
> > but not equivalent JSON rules. It looks like either the XML rules
> > are not needed or equivalent JSON rules are missing if the XML rules
> > are needed or there should be an explanation why the different
> > encodings lead to different results (which is operationally rather
surprising).
> > BALAZS2:XML has 2 distinct ways to encode information XML attributes
> > and elements. JSON only has one uniform way. XML attributes are
> > often used to carry metadata which is a useful facility and they are
> > not used to encode "real" YANG defined data. So we want to allow the
> > use of XML attributes and not go for a least common denominator of
> > the 2 encodings. IMHO it is a useful facility, IMHO it belongs here,
> > but if you
> insist I can remove it.
>
> I believe this text is odd for what I wrote below.
> BALAZS3: IMO as XML attributes are encoding specific (they do not
> exists in
> JSON) the rules about them are also inherently encoding specific.
> I see no problem with allowing a special rule about them to allow the
> customers to make use of this richer encoding.
I strongly prefer to stay as much as possible encoding independent. If the
intention is to say that 'unknown metadata MUST be ignored', then say this
in an encoding neutral way. In fact, -09 has already:
implementation specific metadata relevant to individual data
nodes. Unknown metadata MUST be ignored by users of instance
data, allowing it to be used later for other purposes.
Hence, I think the following item talking specifically about XML attributes
is not needed.
BALAZS4: OK. I will remove it.
> > If we want rules that apply to all encodings, they should be
> > expressed in an encoding neutral way. The current text and your
> > response leaves me puzzled what the specification really wants to
> > say here. And do we have to say something at all?
> >
--------------------------------------------
> > > * Delivery of Instance Data
> > >
> > > - Why do we need this SHOULD? I do not think we should use RFC 2119
> > > keywords to define how organizations may use the instance data
> > > format. My proposal is to delete this entire section.
> > > BALAZS: I will change it to lower case may.
> > > I was asked to and I want to state that we want to use instance
> > > data both for offline delivery of design time information and for
> > > run-time delivery of other data.
> >
> > But should this not be stated in the use cases and principles list
> > in section 2? I think section 5 is a mixture of a use-case concern
> > and a requirement (oops principle):
> >
> > PX: Instance data sets may be read from or produced by a live server
> > [is YANG server the proper term?] or they can be the result of a
> > specification or design effort that does not involve a live
> > server.
> >
> > I think the essence of section 5 should be integrated into section 2.
> > What it says seems misplaced in the middle of the document. (I
> > personally prefer to talk about objectives rather than principles
> > but that may be just
> > me.)
> > BALAZS: OK, I will move it into chapter 2 Introduction. This is
> > really not something mandatory on the implementation.
>
> I still do not see why one use case gets a subsection while others are
> elaborated on in the appendix. I am still not sure section 2.2 is
> needed. I would rather add the proposed PX to the principles and dump
section 2.2.
> BALAZS3: This was explicitly requested by the group, on multiple
occasions.
> IMHO it is good information.
See, I even proposed to turn some of this into a 'principle' (while
suggesting to move the use-case specific text to the use cases).
BALAZS4: While I would be OK with your PX: principle, I was explicitly asked
to write about the DELIVERY of the instance data, not just about how it is
produced.
(Looking at 2.1 again, I would in the first P1 indicate that the solution
should allow for encoding extensibility but too late to bring this up.)
P1 Two standard formats shall be defined based on the XML and JSON
encodings and extensibility should be provided to support future
YANG encoding formats.
BALAZS4: I agree with your idea. It is also stated in chapter3.
> > How much simplification is there really compared to the inline
> > method if I only list modules in the yang library schema without
> > derivations etc? See my earlier point about which schema formats are
> > mandatory to implement and whether the simplification is worth the
> > extra code and possible interoperability issues.
> > BALAZS2:
> > Compare:
> > INLINE method:
> > <content-schema>
> > <inline-module>
> > ietf-yang-library@2016-06-21
> > </inline-module>
> > <inline-schema>
> > <module-state
> > xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
> > <module>
> > <name>ietf-yang-library</name>
> > <revision>2016-06-21</revision>
> > </module>
> > <module>
> > <name>ietf-netconf-monitoring</name>
> > <revision>2010-10-04</revision>
> > </module>
> > </module-state>
> > </inline-schema>
> > <content-schema>
> >
> > SIMPLIFIED INLINE method:
> > <content-schema>
> > <module> ietf-yang-library@2020-01-14</module>
> > <module> ietf-netconf-monitoring@2020-01-14</module>
> > </content-schema>
>
> The begining is static overhead (does not increase with # of modules)
> and the rest marginal when it comes to tools reading this, at least
> not a big enough argument for me to invent another format. And once
> you have a deviation or a feature not implemented, you will need the
> longer format anyway (or simply announce a schema that is not quite
> correct - I guess this is what people will do).
>
> BALAZS3: In practice (at least in Ericsson) humans also read and write
> the instance data files, so static overhead is bad. It is 18 lines versus
4.
> People (Rob, and someone else maybe Reshad ?) explicitly asked for the
> simple-inline format.
Several lines are static that the core is
<module>ietf-yang-library@2020-01-14</module>
<module>ietf-netconf-monitoring@2020-01-14</module>
vs
<module><name>ietf-yang-library</name><revision>2016-06-21</revision></modul
e>
<module><name>ietf-netconf-monitoring</name><revision>2010-10-04</revision><
/module>
so this is just syntactic sugar if I understand correctly. But if I can turn
the syntactic sugar format algorithmically into the more powerful
yang-library format, then I will shut up on this.
BALAZS4: You can translate the simplified format into the powerful inline
(yang-library format) algorithmically. Note: You should only use the
"complicated" inline format if there is a need to specify deviations or
supported features.
--
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/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
