On 10/24/2017 07:06 PM, Andy Bierman wrote:
On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev
<[email protected] <mailto:[email protected]>> wrote:
On 10/24/2017 03:42 AM, Andy Bierman wrote:
On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
Vladimir Vassilev <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Hello,
I would like to use the occasion of this Errata
report to
point out
some additional issues with the
instance-identifier type
definition.
IMO the instance-identifier built-in type has 2
additional
problems
that can be addressed with alternative and
significantly
more radical
errata or fixed in a new version of YANG.:
Problem 1: The obvious limitation inherited from
Xpath 1.0
- inability
to escape single or double quote characters. In Xpath
world this
limitation is worked around by use of concat()
which is
not available
in the YANG 1.1 instance-identifier definition. 2
examples
of this
limitation:
1. It is impossible to create value of type
instance-identifier
referencing nodes in lists with key string values
containing both a
single and a double quote characters e.g.
...<interface><name>"It's
valid string!"</name></interface>.
2. Another example of the same problem would be a
leaf of type
instance-identifier referencing another leaf of type
instance-identifier. With 2 references it works
provided
one is
encoded with single quotes and the other with
double but it is
impossible to create third e.g.
YANG:
list id-list {
key "id";
leaf id {
type instance-identifier;
}
}
Although the instance-identifier is problematic, it is rarely
used at all,
let alone using it as a list key.
It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
The XPath mixed-quotes problem is well-known, and the suggested
solution seems to be use the "concat" function
/foo/bar[name=concat("It's a", ' "valiid" string')]
Not very user friendly, is it?
I think people naming their interfaces "It's a valid string!" can
take it. Prettier escaping solutions are available e.g. C string
but it will require more work then a line in the next YANG version
RFC. IMO solution is needed either concat or an alternative one.
Practical reason: YANG 1.1 can not create instance-identifier to
the alarm /alarms/alarm-list/alarm[...
resource="/interfaces/interface[name='eth0']"]. And this is not
the "That's a valid string!" named interface. The "That's a valid
string!" interface alarms can not be reported as a valid
ietf-alarms instance-identifier based resource alarm at all.
Actually the XPath designers made a reasonable trade-off by using
concat as the solution to
a problem that rarely happens. It is up to the IETF to define YANG
in a way that does
not ignore the XPath solutions.
Yes. How about some proper rules mandating th use of quotes and concat
like: 1. Only allow use of double quotes when there is single quote
present. 2. Only use concat when there is both single and double quotes
present to split the string into 1 char single quote strings and the rest.
Then /foo/bar[name=concat('It',"'",'s a valid string!"')] is the only
possible canonic representation for all implementations and the solution
is solving the rare problem without reinventing the wheel.
Vladimir
Andy
Data:
* /top/id-list[id="/top/list[idx='4']"]
*
/top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]
<assuming the
* proposed errata is also in effect>
* <next reference not possible with YANG 1.1>
Problem 2: The instance-identifier type lacks
canonical
form (which
makes it the only data type with implementation
dependent
representation at the data level ... think of the
integer
types
allowing optional spaces between the digits). This
is in
fact the only
built-in data type that allows the server
implementation
to change the
configuration data replacing double quotes with
single or
the other
way around. Inserting white spaces where you did
not have
them when
the configuration was submitted. You can not
simply read a
configuration and use fast data comparison without
schema
support just
because of this type. This is useless flexibility for
simple data
type.
And this can be fixed if:
1. white spaces in instance-identifiers are prohibited
2. list key predicates are required in
alphabetical order
Or perhaps use the order the keys are defined in the data
model (the
"keys" statement").
This is an option but then the e.g. xpath2instid() function
implementations will need schema support.
All the YANG tools I have seen generate the predicates in YANG
key order.
Yes.
If Xpath came with a canonical form definition (prohibiting
spaces, redundant duplication of namespace prefixes in children,
order of predicates, canonical quotation rule, and some
flexibility as of the node prefix semantics) we would not need to
have this discussion. Seems no other modeling language of
hierarchical data has reusable instance-identifier datatype with
the necessary properties and I can see this as something that can
go in separate RFC specifying generic data type making canonic
definition from Xpath that YANG can reuse. In that case the
alphabetic order makes sense moving some constraints into the
generic definition of the type one can validate without the
context schema but it is not of significant importance.
The issue of canonical instance-identifier has been discussed
many times,
and it is not possible to require the usage of specific
prefixes in XML.
(Note that Lada fixed this for JSON in RFC 7951)
Yes.
Only the string + expanded names can be properly compared in
XML, not the literal string
representing the XPath expression.
Yes.
I do not see the need of major rework just making the Xpath subset
rules stricter with canonical requirement and either allowing
concat() (also with canonic rule producing predictable result e.g.
to be used only for escaping single quotes and prohibiting double
quotes in predicates otherwise). Even with RFC7951 prefix rules
added in the instance-identifier can still be a valid Xpath subset
requiring trivial prefix replacements so that it can be used with
non-YANG aware XML tools keeping that option open.
Vladimir
Vladimir
Andy
3. strict quotation convention with escape option is
added. (only
3. contradicts the sec. 9.13 "..
instance-identifier is a
subset of
the XPath ..")
I would like to change one more thing - I think it is
unfortunate that
the lexical representation depends on the lexical context;
specifically that prefixes declared in the XML instance
document is
used. This applies also to identityref. YANG 2.0
should use
the same
encoding as JSON does for these datatypes.
/martin
Vladimir
On 10/21/2017 08:16 PM, Andy Bierman wrote:
On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
wrote:
Dear all,
Shall I validate this one?
To add more context, this relates to the the
RESTCONF
JSON vs. XML
discussions in the NETCONF WG.
leaf broken {
type union {
type int32;
type string;
}
}
If all values of key leaf "broken" are sent as
strings
in an
instance-identifier,
then the int32 value may not match in all
implementations, instead of
the string.
Allowing numbers as literals in addition to quoted
strings allows the
sender
to be specific, and all implementations to be
consistent.
Regards, Benoit
Andy
The following errata report has been
submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5157
<http://www.rfc-editor.org/errata/eid5157>
<http://www.rfc-editor.org/errata/eid5157
<http://www.rfc-editor.org/errata/eid5157>>
<http://www.rfc-editor.org/errata/eid5157
<http://www.rfc-editor.org/errata/eid5157>
<http://www.rfc-editor.org/errata/eid5157
<http://www.rfc-editor.org/errata/eid5157>>>
--------------------------------------
Type: Technical
Reported by: Andy Bierman
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>
Section: 14
Original Text
-------------
key-predicate-expr =
node-identifier *WSP
"=" *WSP
quoted-string
Corrected Text
--------------
key-predicate-expr =
node-identifier *WSP
"=" *WSP
(quoted-string / integer-value /
decimal-value)
Notes
-----
An instance identifier is forced to
specify
every key value to
be a string
even though the YANG key leaf type
could be a
numeric type.
XPath does not require a quoted
string here,
just YANG.
Old: /top/list[idx="4"]
New: /top/list[idx=4]
Instructions:
-------------
This erratum is currently posted as
"Reported". If necessary,
please
use "Reply All" to discuss whether it
should
be verified or
rejected. When a decision is reached, the
verifying party
can log in to change the status and
edit the
report, if necessary.
--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title : The YANG 1.1 Data
Modeling Language
Publication Date : August 2016
Author(s) : M. Bjorklund, Ed.
Category : PROPOSED STANDARD
Source : NETCONF Data
Modeling
Language
Area : Operations and
Management
Stream : IETF
Verifying Party : IESG
.
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
