Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

Benoit Claise <bclaise@cisco.com> Mon, 23 January 2017 10:29 UTC

Return-Path: <bclaise@cisco.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 CCDE71294F8 for <netmod@ietfa.amsl.com>; Mon, 23 Jan 2017 02:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 DFKnN_4TZWj9 for <netmod@ietfa.amsl.com>; Mon, 23 Jan 2017 02:29:31 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CAE129B11 for <netmod@ietf.org>; Mon, 23 Jan 2017 02:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9370; q=dns/txt; s=iport; t=1485167370; x=1486376970; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=yMofqgJSQrBijV51UxO4R6G6Qv6obV2JwtKXxprLarc=; b=BI/ulY0M/nvm92wahpIlfvW4wKRhkvkUne1HeCqrZ98TzcmO7y3Tsa3o HUAzDc7pg2pWImaedYIp8aEIYJ9P+uEaxq795lgT5c7C7P6LzcXHg/c/K Nubiwtk/5qDp/hc/6gQMVlrVnRecnGaKeBdgoYl00JyPXiAa4imRXaM5q o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AmAQC62oVY/xbLJq1CGhkBAQEBAQEBAQEBAQcBAQEBAYM9AQEBAQF/AydfjVtykROQA4Urgg0shXYCgl0YAQIBAQEBAQEBYyiEagZyBxALRlcHDAYCAQEXiHEOLa4LK4oUAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZLggWBYoEJgTyBUIchBYkAEYdhilmGYoJUiDSBd4UPgyqGPogfglmHfh84EYEGEwgVFRiEWw0PgWI9NQETh28BAQE
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400"; d="scan'208,217";a="651894898"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2017 10:29:28 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0NATRdC011702; Mon, 23 Jan 2017 10:29:27 GMT
To: mbj@tail-f.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net
References: <20170118114858.62A63B80FFD@rfc-editor.org>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <fc729e9c-2a65-282b-c12e-ba359347e5fb@cisco.com>
Date: Mon, 23 Jan 2017 11:29:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170118114858.62A63B80FFD@rfc-editor.org>
Content-Type: multipart/alternative; boundary="------------5C13EB695ECCC66D04FCF411"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EODqqwbsf4zbZOqu0GtjnP7zr44>
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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: Mon, 23 Jan 2017 10:29:33 -0000

Dear all,

Let me summarize the situation.
     - The RFC 6020 spec is clearly ambiguous.
     - The solution is to use YANG 1.1
     - RFC 7950 doesn't update or obsolete RFC 6020 (*)
     - We should stop this problem from spreading further: updating 
tooling is one good aspect, we should update the spec. too to at least 
warn the users.

There is no perfect solution.
Because of (*), I believe I should accept this errata.
Any strong objections? If you have, propose a better plan. And I don't 
believe that "do nothing" is sufficient.

Regarding the "update" solution, see the RFC 7950 writeup at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/

    (16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header, listed
    in the abstract, and discussed in the introduction? If the RFCs are not
    listed in the Abstract and Introduction, explain why, and point to the
    part of the document where the relationship of this document to the
    other RFCs is discussed. If this information is not in the document,
    explain why the WG considers it unnecessary.

       No. YANG 1.0 [RFC6020] is not expected to change its status since
       there are data models on the standards-track that conform to YANG
       1.0. YANG 1.0 may be considered for retirement once all data models
       have naturally been updated to a future version of YANG.

Regards, Benoit
> 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.
>
> 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.
>
> --------------------------------------
> RFC6020 (draft-ietf-netmod-yang-13)
> --------------------------------------
> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
> Publication Date    : October 2010
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : NETCONF Data Modeling Language
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>