YANG parser in this document context is XML/JSON parser for YANG defined data,
in my understanding.
Not sure this is right term or whether there is any better term. We will figure
it out. Thanks.
-Qin
-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
发送时间:
What is a 'YANG parser'? For me, a YANG parser is something that parses
YANG, i.e., not an XML or JSON parser.
/js
On Thu, May 31, 2018 at 03:21:27AM +, Qin Wu wrote:
> This is exactly what we proposed in v-(02) ,
>
This is exactly what we proposed in v-(02) ,
https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-02
Regarding machine parsing data, please see last paragraph of abstract:
"
There are no implications in this
document for YANG parsers: this document does not change the
Agree with Jurgen, I think what need to be emphasized is how machine parse the
data should not be changed,in draft-wu-netmod-yang-xml-doc-conventions, what is
required is additional encoding and decoding mechanism to make data better fit
into RFC and I-D.
Xiaojian
-Original Message-
Thanks Juergen's comments on draft-wu-netmod-yang-xml-doc-conventions
The v-(02) has been posted to address his comments
In v-(02),
a. The title is changed into "Documentation Conventions for Expressing
b. XML and JSON encoded YANG Data Node Instance"
c. The terminologies are added to section
As those in London recall, I suggested an alternative solution for handling
long lines in artwork in drafts. FWIW, I have captured this idea in the
following I-D:
https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-00
Kent // contributor
The phrase 'will be defined' is not good. Anyway, for a notification
nested in data tree, the data tree must exist in and
the context in which XPath expressions are evaluated is ,
see section 6.1. of RFC 8342.
/js
On Wed, May 30, 2018 at 09:38:05AM +, Rohit R Ranade wrote:
> Hi Juergen,
>
OLD
The recommended approach to populate "/modules-state" is to report
the schema for YANG modules that are configurable via conventional
datastores and for which config false data nodes are returned via a
NETCONF operation, or equivalent.
NEW
The recommended approach to
Hi Juergen,
Modules which define only notifications(ietf-netconf-notifications) will be
defined in data-store ONLY. Right ?
With Regards,
Rohit R Ranade
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: 30 May 2018 12:28
To: Rohit R
On Wed, May 30, 2018 at 06:40:02AM +, Rohit R Ranade wrote:
> A module having only "ro" nodes , can be considered to be implemented in any
> data-store ? operational/ephemeral etc
No.
> A module having "rw" nodes, what is the rules for it to be considered
> implemented in a data-store ?
Hi Juergen,
My intention is only to get clarity about what is the meaning of implementing a
module in a data-store, as it used in below places,
" It must be possible to NOT implement a module or feature in
, even if it is implemented in some other datastore"
" 2. A dynamic
11 matches
Mail list logo
