Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

Andy Bierman <andy@yumaworks.com> Fri, 05 October 2018 16:53 UTC

Return-Path: <andy@yumaworks.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 9E0FA130E29 for <netmod@ietfa.amsl.com>; Fri, 5 Oct 2018 09:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.64
X-Spam-Level:
X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 mLpnZSy_zDZw for <netmod@ietfa.amsl.com>; Fri, 5 Oct 2018 09:53:35 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07783130DC1 for <netmod@ietf.org>; Fri, 5 Oct 2018 09:53:35 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id a82-v6so9834874lfa.4 for <netmod@ietf.org>; Fri, 05 Oct 2018 09:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lYQYKYShP+OBYnC+EK90dX3FNfKQnxq4bfvj1LRzrgk=; b=eQBd0QnSEG+OUDw0LdgFsZavmCPUX3SfMFImSDoiU9auC5IMCNTwHITDin+xNApyMI +eimqWzZnaAQ/E44hTY3kfD/vJCUl9TZAtRUJ3QjVM7kEZp8wB054LEqkLjgokkWjt5l 7nN/JBeBs+w5VwqWqYD5142pa+9E2tHwRqhT789Hc8t4wxA8hkpf3Gi/y8flX19MJ0Pw jXegzXY79bH9p0180bw0Jfxhw93V70fGutlfB5pVdgnUs2wQz5z7ergLNt26jSTBsc5u R+Mto9CtTx7ZbuIOtyxDBov3YLaVDob78OGAiucWVbBwIvB7CyfLq2+TXG7VNzURH/02 wyYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lYQYKYShP+OBYnC+EK90dX3FNfKQnxq4bfvj1LRzrgk=; b=JM4Wl4lrUKpCeI9FluzfUOXfI5eYA6U5dcxjv+7pqTTSYd4zUB1btJusFK20hUAuJj BbUfmPvauAvIPlsdabyph6ud9J2DMGtRPkFL52SpDjq7PuLe/qhPm4F4qP8A5IgL7Cam yAqqtlbKey87fsoaUCelYi3uarHJF4nbS3anKcYO5k4MQ7CO0CF6cBfVFQV+DamPxnOg +ObF3Xs+p5fKtgw9ZDl74GcQSP/scq4CxkGP0h42xaz+CGCsLs7XEAoikoTx7UbMbamf ul/eHwdDE3zt/4Cx6/VSgcq4ewObUKxjPaLQErnkZGs7pePL5LbZfF4qknrhaFuqqlre XoAQ==
X-Gm-Message-State: ABuFfoidXbXr4ZUNjNJpOW+nIYlp6UmeX1HwMpqeUuccxyUqXaIYgyQv x4KlR44qvwmuTN9ZmmiMFc1jn0XmY+DbGyYsc00h+Q==
X-Google-Smtp-Source: ACcGV60Ztcf3qg6aoiiD9qBReSYVCRfXVHQ98GRTDy1kK/aw8QQkqE5REw+7O6g4K3hh1bVgsCiNsTDf/sPyQFAUA+o=
X-Received: by 2002:a19:f00a:: with SMTP id p10-v6mr7053617lfc.43.1538758413078; Fri, 05 Oct 2018 09:53:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Fri, 5 Oct 2018 09:53:32 -0700 (PDT)
In-Reply-To: <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net>
References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 05 Oct 2018 09:53:32 -0700
Message-ID: <CABCOCHS4GOVYC0FRJEtCpzQ+VB=u6g0LDEmL1ULqysBA=yhzNg@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Martin Bjorklund <mbj@tail-f.com>, Phil Shafer <phil@juniper.net>, Kent Watsen <kwatsen@juniper.net>, Robert Wilton <rwilton@cisco.com>, Ignas Bagdonas <ibagdona@gmail.com>, Warren Kumari <warren@kumari.net>, Joel Jaeggli <joelja@bogus.com>, Rohit R Ranade <rohitrranade@huawei.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b6b0d05777e1c7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LGlyTzrfCWi_ysK4qgBszY_uAz8>
X-Mailman-Approved-At: Fri, 05 Oct 2018 10:05:15 -0700
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 05 Oct 2018 16:53:39 -0000

On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <lberger@labn.net> wrote:

> My personal opinion (with any hat on) is that it isn't appropriate to make
> a technical change that impacts implementation in an errata.
> Clarifications of original intent, corrections of inconsistencies and
> editorial corrections are perfectly appropriate.  I'm happy to learn that
> this intended use/scope of errata is wrong.
>
>
Strongly agree.
Errata cannot be used to change technical decisions.
It can only be used to correct text that is incorrect.


> Lou
>

Andy


>
>
> On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote:
>
>> Well, if you think an errata does not work, we can file a one page
>> document with N pages of boilerplate around it.
>>
>> /js
>>
>> On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:
>>
>>> Juergen,
>>>
>>>      The document says what it says, i.e., "The origin for any top-level
>>> configuration data nodes must be specified."  Changes to this would
>>> require
>>> a BIS or an RFC that updates this document.
>>>
>>> Lou
>>>
>>>
>>> On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:
>>>
>>>> Hi,
>>>>
>>>> the authors have been discussing whether the top-level requirement is
>>>> too strict but there has not been a clear conclusion yet I think. In
>>>> the example, all nodes to have a defined origin and hence the origin
>>>> at the root will have zero effect.
>>>>
>>>> /js
>>>>
>>>> On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:
>>>>
>>>>> The following errata report has been submitted for RFC8342,
>>>>> "Network Management Datastore Architecture (NMDA)".
>>>>>
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata/eid5514
>>>>>
>>>>> --------------------------------------
>>>>> Type: Technical
>>>>> Reported by: Rohit R Ranade <rohitrranade@huawei.com>
>>>>>
>>>>> Section: C.1
>>>>>
>>>>> Original Text
>>>>> -------------
>>>>>      <system
>>>>>          xmlns="urn:example:system"
>>>>>          xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>>>>>
>>>>>        <hostname or:origin="or:learned">bar.example.com</hostname>
>>>>>
>>>>>        <interface or:origin="or:intended">
>>>>>          <name>eth0</name>
>>>>>          <auto-negotiation>
>>>>>            <enabled or:origin="or:default">true</enabled>
>>>>>            <speed>1000</speed>
>>>>>          </auto-negotiation>
>>>>>          <speed>100</speed>
>>>>>          <address>
>>>>>            <ip>2001:db8::10</ip>
>>>>>            <prefix-length>64</prefix-length>
>>>>>          </address>
>>>>>          <address or:origin="or:learned">
>>>>>            <ip>2001:db8::1:100</ip>
>>>>>            <prefix-length>64</prefix-length>
>>>>>          </address>
>>>>>        </interface>
>>>>>
>>>>>        <interface or:origin="or:system">
>>>>>          <name>lo0</name>
>>>>>          <address>
>>>>>            <ip>::1</ip>
>>>>>            <prefix-length>128</prefix-length>
>>>>>          </address>
>>>>>        </interface>
>>>>>
>>>>>      </system>
>>>>>
>>>>> Corrected Text
>>>>> --------------
>>>>>      <system
>>>>>          xmlns="urn:example:system"
>>>>>          xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>>>>>          or:origin="or:intended">
>>>>>
>>>>>        <hostname or:origin="or:learned">bar.example.com</hostname>
>>>>>
>>>>>        <interface or:origin="or:intended">
>>>>>          <name>eth0</name>
>>>>>          <auto-negotiation>
>>>>>            <enabled or:origin="or:default">true</enabled>
>>>>>            <speed>1000</speed>
>>>>>          </auto-negotiation>
>>>>>          <speed>100</speed>
>>>>>          <address>
>>>>>            <ip>2001:db8::10</ip>
>>>>>            <prefix-length>64</prefix-length>
>>>>>          </address>
>>>>>          <address or:origin="or:learned">
>>>>>            <ip>2001:db8::1:100</ip>
>>>>>            <prefix-length>64</prefix-length>
>>>>>          </address>
>>>>>        </interface>
>>>>>
>>>>>        <interface or:origin="or:system">
>>>>>          <name>lo0</name>
>>>>>          <address>
>>>>>            <ip>::1</ip>
>>>>>            <prefix-length>128</prefix-length>
>>>>>          </address>
>>>>>        </interface>
>>>>>
>>>>>      </system>
>>>>>
>>>>> Notes
>>>>> -----
>>>>> There was no "origin" attribute to the "system" top-level container,
>>>>> though it is a configuration node.
>>>>> As per the extension definition "The origin for any top-level
>>>>> configuration data nodes must be specified."
>>>>>
>>>>> To choose an extension for top-level container in such cases, I would
>>>>> prefer one of the origin of its children and used "intended". , instead of
>>>>> "unknown".
>>>>>
>>>>> This has already been discussed in the mail chain, but also mentioned
>>>>> here to help readers in future.
>>>>>
>>>>> 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.
>>>>>
>>>>> --------------------------------------
>>>>> RFC8342 (draft-ietf-netmod-revised-datastores-10)
>>>>> --------------------------------------
>>>>> Title               : Network Management Datastore Architecture (NMDA)
>>>>> Publication Date    : March 2018
>>>>> Author(s)           : M. Bjorklund, J. Schoenwaelder, P. Shafer, K.
>>>>> Watsen, R. Wilton
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Network Modeling
>>>>> Area                : Operations and Management
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>>>
>>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>