Re: [netmod] [Technical Errata Reported] RFC6020 (4911)

Martin Bjorklund <mbj@tail-f.com> Wed, 18 January 2017 13:55 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F18129721 for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 05:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHZxluusZqxb for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 05:55:37 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D16B012970A for <netmod@ietf.org>; Wed, 18 Jan 2017 05:55:36 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 662211AE0455; Wed, 18 Jan 2017 14:55:34 +0100 (CET)
Date: Wed, 18 Jan 2017 14:55:32 +0100
Message-Id: <20170118.145532.995038902796253716.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20170118114858.62A63B80FFD@rfc-editor.org>
References: <20170118114858.62A63B80FFD@rfc-editor.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lRaj9zAaEnqxYREhCeer0OS1p8Y>
Cc: netmod@ietf.org, joelja@bogus.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 13:55:38 -0000

RFC Errata System <rfc-editor@rfc-editor.org> 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 <lhotka@nic.cz>
> 
> 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 solution moving forward is to use YANG 1.1.


/martin