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

Robert Wilton <rwilton@cisco.com> Fri, 05 October 2018 10:39 UTC

Return-Path: <rwilton@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 42024130E44 for <netmod@ietfa.amsl.com>; Fri, 5 Oct 2018 03:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level:
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 rCnGBf80gLoG for <netmod@ietfa.amsl.com>; Fri, 5 Oct 2018 03:39:33 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA8A130E02 for <netmod@ietf.org>; Fri, 5 Oct 2018 03:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4449; q=dns/txt; s=iport; t=1538735973; x=1539945573; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=MZJ/q8gHDryDMuhgTKKK8AenfYGaXGhK6yONPY+nr5Q=; b=DHrMdUOHB0JbgoBNFtEBknd/6qjhG6+pUFHRN0JydBNnj/BVZO4uQRmS sAtHT1CKm8vXytdq6CDREqVLAumLfeJ6+Hkcpsb9Eu0JvgS9DAqjyikZp 2PBhSGcII9bl1x//UowRZh1yAh+Th6rRZTiHa63hJ3Ue14QKX5fySuspV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAACHPrdb/xbLJq1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgmt/KIN0iHSNKyWWXoF6DSOESQKESzUMDQEDAQECAQECbRwMhToBBSMVUQsSBgICJgICSQ4GAQwGAgEBgx0BggEPo3yBLoQAAXaFG4ELijmBQT+BEicMgl+BQYEdggABAYMfglcCiFckhSJAfI4JCYZMiXQGF4FMhGWCZ4ZcjzyGKoFEAjSBVTMaCBsVGoMNCYIpg1GFFIUINz4wjA2CPgEB
X-IronPort-AV: E=Sophos;i="5.54,344,1534809600"; d="scan'208";a="7013945"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2018 10:39:30 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w95AdUQW000389; Fri, 5 Oct 2018 10:39:30 GMT
To: RFC Errata System <rfc-editor@rfc-editor.org>, mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org
References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <f6141ad2-2364-7f87-932b-3d49a188261b@cisco.com>
Date: Fri, 05 Oct 2018 11:39:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/72OYuTkXIA7butwRd2C7ZHn8RlM>
X-Mailman-Approved-At: Fri, 05 Oct 2018 05:11: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 10:39:36 -0000

I agree that we need to reach a conclusion on the discussion before we 
can know what to do with this errata.

Thanks,
Rob


On 05/10/2018 11:14, 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