Hi Lada,
I don't feel strongly, but basically agree with Martin.
The YANG 1.0 spec is ambiguous, YANG 1.1 has fixed that. I guess that
most pragmatic YANG 1.0 implementations would treat a backslash followed
by something other than n,t,", or / as just a backslash character.
This issue seems to only come up in the context of pattern statements.
The best pragmatic answer that I've seen to this is from rfc6087bis
section 5.11.2: "Patterns and Ranges" which states that implementations
SHOULD use single quotes rather than double quotes for patterns and
hence carefully side steps the issue.
This is the solution that we used to fix the issue in our proprietary
modules, and also the one that I recommended to OpenConfig for their
models (but I don't know whether they will implement this).
Rob
On 18/01/2017 14:24, Ladislav Lhotka wrote:
On 18 Jan 2017, at 14:55, Martin Bjorklund <[email protected]> wrote:
RFC Errata System <[email protected]> wrote:
The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
--------------------------------------
Type: Technical
Reported by: Ladislav Lhotka <[email protected]>
Section: 6.1.3
Original Text
-------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:
\n new line
\t a tab character
\" a double quote
\ a single backslash
Corrected Text
--------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:
\n new line
\t a tab character
\" a double quote
\ a single backslash
The backslash MUST NOT be followed by any other character.
Notes
-----
The text doesn't state whether other characters may follow the
backslash, and if yes, what it means. Existing implementations have
used three approaches:
1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example,
"\x" is the same as "x".
3. keep both the backslash and the character following it.
This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
adopted option #1. However, many modules are still being written using
YANG version 1.0, so it is important to clarify this issue in RFC 6020
as well.
I don't think this errata should be accepted. As stated, the spec is
unclear, and YANG 1.1 has fixed this problem. But it is not clear
that the original intention when RFC 6020 was written was #1.
Accepting this errata now would make existing implementations and
modules invalid.
The problem is that the spec is clearly ambiguous and it is impossible to
decide whether such a module is valid or not and, if it is, what the other
backslash-escaped characters mean. Existing implementations can already reject
such modules - the fact that pyang (and probably other tail-f tools) adopted
one interpretation doesn't mean that everybody does the same.
The solution moving forward is to use YANG 1.1.
YANG 1.0 modules continue to be written, and I think it is important to stop
this problem from spreading further. I think tools should at least issue a
warning because otherwise future upgrades to YANG 1.1 may become a nightmare -
modules will suddenly break in unexpected places.
If this erratum is rejected, what is the basis for accepting erratum #4909 that
started this discussion?
Lada
/martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
