Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

"SADOVNIKOV, ALEXEI" <AS549R@att.com> Thu, 17 February 2022 21:13 UTC

Return-Path: <AS549R@att.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 128783A12D5 for <netmod@ietfa.amsl.com>; Thu, 17 Feb 2022 13:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 Voymkd6z4jev for <netmod@ietfa.amsl.com>; Thu, 17 Feb 2022 13:13:45 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BC83A12D3 for <netmod@ietf.org>; Thu, 17 Feb 2022 13:13:45 -0800 (PST)
Received: from pps.filterd (m0288869.ppops.net [127.0.0.1]) by m0288869.ppops.net-00191d01. (8.17.1.5/8.17.1.5) with ESMTP id 21HLAkrm017763; Thu, 17 Feb 2022 16:13:42 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288869.ppops.net-00191d01. (PPS) with ESMTPS id 3e9senm8ht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Feb 2022 16:13:41 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 21HLDdTX012985; Thu, 17 Feb 2022 16:13:40 -0500
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 21HLDamp012927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Feb 2022 16:13:36 -0500
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 9F7FB16A598; Thu, 17 Feb 2022 21:13:36 +0000 (GMT)
Received: from MISOUT7MSGEX2BB.ITServices.sbc.com (unknown [135.66.184.223]) by zlp27125.vci.att.com (Service) with ESMTP id 7093416A597; Thu, 17 Feb 2022 21:13:36 +0000 (GMT)
Received: from MISOUT7MSGEX2DE.ITServices.sbc.com (135.66.184.219) by MISOUT7MSGEX2BB.ITServices.sbc.com (135.66.184.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.18; Thu, 17 Feb 2022 16:13:35 -0500
Received: from MISOUT7MSGETA03.tmg.ad.att.com (144.160.12.222) by MISOUT7MSGEX2DE.ITServices.sbc.com (135.66.184.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.18 via Frontend Transport; Thu, 17 Feb 2022 16:13:35 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by edgeso3.exch.att.com (144.160.12.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Thu, 17 Feb 2022 16:13:34 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsKUzw5gBmEN830ROcXC/6G1a0Tn21Ox9cmVOtPaowgv0134LYd7evnurXkoxouJ/TxQXWT6iFcQEHlMqZPjaLSd6sXD5Eesm8V218h6f8wW47MtC0d2D+O0ysj2liCABbPhm7sQlyCsvWiyXD/NwqjRWe0vB9seG8OtM7m9CexKrV0I1aKSIZWFVED9IdP0prEpeYAY1wIgVPF/SoJovZLEtvbeCogoeWjXMipk8MFeOQDcyOLh3zkZAmk7TH986Edbtu+nHjy3hxFNaCkiRpWR7GVp9heSVfYUBevsJC25lWB2k995uvHBIS4jm9DQuhXipjx6T2UtYlXZCS6MWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LwAwDs0wYPGkvmqBfmTLG5M0cv4oKjY1CX28FhuRu84=; b=R0nStBBKr/vwh9xUJiKlM1Im7+zNSHSLu4bjzNMQ+BAl67HnlgyqCumKUJPhrP1MZLOvC53XI2dE+YorKO7ejuSFH0/j0J+cvGiw0r1m6ZUBqiGftzusXIB/JWBDcqrRQ7bnaMRnSpIMCu3zsvl41tKykRM9Am1aPZoGO5fFx4qqmkfu26fXW4B7rGqFEbBXkNMjoAm9rswCGFu2Mxtv1PUGR3ovUt0N/HTc5VpoZ+GyHZ9NQHLxLL6yo7ZYGDT9BQ1aCLfMQuJHPtoGnASJI6AIHevY/EIoiTko7snlvcqvqrwYK/qnEu15Iub2pzal6x83U5rV2k8iGMQiuIniow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LwAwDs0wYPGkvmqBfmTLG5M0cv4oKjY1CX28FhuRu84=; b=oa/TAzj2xo5LD4GDfd0vipwoaPACfQc6GJofpJ6U9OxXL15avg1/3m4DDeuC5sXGYju2UVNbP31f7aEGOTGBV92VZ38yqd5raeISG61B6gCVhk5x2BJFq+ma3co3LxJxNlPq4TYTsNs1SPodIepoUEQKRXNs63s9o+Kb/hg7b3Q=
Received: from SA0PR02MB7132.namprd02.prod.outlook.com (2603:10b6:806:e2::5) by CO6PR02MB7794.namprd02.prod.outlook.com (2603:10b6:303:b1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.14; Thu, 17 Feb 2022 21:13:32 +0000
Received: from SA0PR02MB7132.namprd02.prod.outlook.com ([fe80::25fe:ba64:84f5:d15a]) by SA0PR02MB7132.namprd02.prod.outlook.com ([fe80::25fe:ba64:84f5:d15a%5]) with mapi id 15.20.4995.016; Thu, 17 Feb 2022 21:13:31 +0000
From: "SADOVNIKOV, ALEXEI" <AS549R@att.com>
To: Andy Bierman <andy@yumaworks.com>
CC: RFC Errata System <rfc-editor@rfc-editor.org>, Martin Bjorklund <mbj@tail-f.com>, Warren Kumari <warren@kumari.net>, Robert Wilton <rwilton@cisco.com>, Joel Jaeggli <joelja@bogus.com>, Kent Watsen <kent+ietf@watsen.net>, Berger Lou <lberger@labn.net>, NetMod WG <netmod@ietf.org>, Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (6855)
Thread-Index: AQHYJC9YATqq8x5CIUumGkuf19y4oqyYJ/0AgAAEy4D//71wgA==
Date: Thu, 17 Feb 2022 21:13:31 +0000
Message-ID: <E027C644-FB28-408C-BD27-C60B4EF8E17E@att.com>
References: <20220217185035.13A2F4C1D9@rfc-editor.org> <c342b121-efe9-30f0-22dd-f931e1378e79@alumni.stanford.edu> <CABCOCHRvoYL88Q5+GQOVgmo4vu1LmAiE5nDQFVFRhyk0a=+UGA@mail.gmail.com>
In-Reply-To: <CABCOCHRvoYL88Q5+GQOVgmo4vu1LmAiE5nDQFVFRhyk0a=+UGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3b25c2a4-9f5d-4e81-e20f-08d9f25a59d5
x-ms-traffictypediagnostic: CO6PR02MB7794:EE_
x-microsoft-antispam-prvs: <CO6PR02MB779488422BD90490883F379D8C369@CO6PR02MB7794.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XT4GW7HrqatqQtFHBDyVSOd25M5Y9ic+/uJnklVxifZz3vdQnbXLLcILum2XOZ0CDX6hcboVo4RhyhDWLoRBbZK+LMq9uf7fLrGDRMN8qzEhyhGcxYQcujor3p9p/X9AQR4/woFrR5davnKfqTRc8Flaojff1W0Fu14haeN+CQfrcGdL6So5VTpvzIy0BvH+cVbSOWysNI/wrP0eZx37ExIwkyYys2U1QYckJGuMSqrFAimqmSP39lI7KiBWQi+KPLwkNJlwd8yHNesRIQ4c/LlZMsmPWxSpqAGGasBOt2EXnfDk3+n51+WXIxMG1G5CSaJuodvhO0k8waj5Y6sivTXomRCKckSf+v4uv8VhdDp+sDjxgDUQFG2evjQoI3TrXOeW25+p/1XK1wgfiZOvMXxdZbHmj/bK5i/srju2+X/hZoRtGHIhyTap3/IG9YIVyR8y7+Rqmb9HCM1z02fFo5djBMxRFsB/NgSNLmgmX+GEmOxbNf1wHWVcuKbsyWhuLIe+49SgHtfn72bvYyAiHBVHNe6exFAJdCNk7inazb00ccyJv8z6pI9h+V4aUV+tdAWc55/AtBJDIQOh8kypCqm7B5wFtskdBVZGYSgvXIu79+xCBPfEYeGE+HOIpLeVYrGkw3OCJeJ5iPRNhfyU/KndocybVoSAG9ToWIo6UgBgK1wThECK0v1ryCLbj9CP+tIyXKtL/HObYW0xM8mq+JQkwTxYQ0J/+EzWGlPuVMglU+l+KBo6Pd4qUv8PhfnVREr/wWZLEuNJDNw63CXtfN4wal5LVpGgeiqdeaUo8QPcaTR6yN7fy5EBnMaFgROh
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR02MB7132.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(64756008)(91956017)(66476007)(7416002)(76116006)(66946007)(66556008)(66446008)(6512007)(82202003)(8676002)(4326008)(86362001)(71200400001)(53546011)(40140700001)(8936002)(186003)(5660300002)(26005)(83380400001)(508600001)(6916009)(6506007)(54906003)(33656002)(966005)(36756003)(2906002)(166002)(6486002)(82960400001)(38100700002)(122000001)(316002)(38070700005)(2616005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: VdMiGnlA67a3g6RWA30Y7s3SYInFO2D0/Jj9O7vyuPeLkqEZaFHvMybtmZTZQuLVpJACAx8JqL0qpDIHKP6UhK5DIMYrATXfQc5Si6slxFt1K3ZyHDMvaHb2YIInvk3dmocacrLPEF+/FcbRuf4QRIS+LFOvyIlkL16qll6HiDg4B1RXKKWTtmITvpRm3F39qZQbsY5hyG5VU52yUKW8FsIsgT4MEqKt0X6dyUBNI60KF3O1sCOWsBLeVGbA2q9VcAATVyFgH6rwsQxjfQT5RamXwe0GuwHxurQBOYhVl4uJHrAPvEqLBb0XM9inNzRVt0M+7q+KFj1RtrXWaVxtB3tFh8U1d6jhkFcm2JJMSjCo1h+1iqXt9EfK77KinyyW8OaOLgoPGLWihCABmoguudqPmsJuChqtf8xIfgaHmhl4R9udmUVAk0bdR3Dyft5yKJelgrM/AbRu45qp8og4SYvJaPh0+lK3buE3GdBQz/SsuqjoQLUfvkSmXUQfgDvyUCxgjVk+hkrfRIhGbjANFnNchv470OAqlBSNXadAhHX0dW0Rk5yNmsgXKH2wGnwt87KGcs2x6nXjFoV4ojMykBZEW5hxHkS+3psOEZw+x9cK/gMXUf5gbXynL6duJaTYhjKqa/TUN57zwi+1SEofiDv+o+5kpBge8UkugqqnH1zw+j37q3V05T0QtrQEkYkyu8RMultqYtpzxcEjkx6bXKlJXNgFlU/eHmQE2mamAvodug+D/6sB+Fs1H6+7SdTEg8+2Po7YcCfc8gVFrl6DkRsD6Vgb6g0ZC7oL+bSQF8Qhns3x1Z+wG2+36PiWz4Pp+YMx+kA2jHUaPMTm9fS81h01kA+6NtdiAYypinQkh/wTaNPJJ5YgHnZycyQij8xznWLTUrTMCRAUzhBbe6H32Jlg09x/D9YmCsLnFRqdrSaTZ/M75GPOXTJLqRUj2QNpl2aW8HkCvfjSDxxpnXfBDLdEhfBDQGe6FHCn9SAMDH825vAQSO2/0XG3aU2JR7X4jfOqZ2jQxi4bq1yrdMqMQbHsrVsfT7YUo6R3dv9sbdkw0jUG4xPqXzHKhm6BZFCQiUAYZI0MXM1aRvAUXVbH7Bs0/hjjT24ydsHmJuWjT+7qJFkODeS4dvYfQGKfEK69ESX3DcTHkJl+Z6eoykA14WyKIa2cf8tINgRks3TWqdAoZVQCTf8ZLX/mf7C1IbPzPRXD4/Nbwrx37YpK4DngPuj37wVosS1CJoNmBl2Ypgq7RA0Ug1DZGb/o5qNxzwOUXFfyHxGX/o30D3wxc4u8cmRiJScqw54kmA6VvoOxK1hzdCuV926w8pZqpSuLq8kp7267budShf34FrHladSgG08Q4B633DDS1bC2EGJQRuN2cf5Adw/0bmj+sIy/KKkpMS/sgCNuvmBp8Ga/tpJ3kPgI74jMElPtIHeQ9ZaA5ojxLuGLc6DVPjyH7ua52erouziIvZLu2GppQrlPZL0/OoD2LJtHqLZjDmeIq3rXtZ2LJnx5F4nmd8mPN2t0AZtu0c0V4L+pvqcoU3YDNJUAFjAHQxoaRbhNBErnh+RXCOA=
Content-Type: multipart/alternative; boundary="_000_E027C644FB28408CBD27C60B4EF8E17Eattcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR02MB7132.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b25c2a4-9f5d-4e81-e20f-08d9f25a59d5
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2022 21:13:31.7022 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wB0Rp31yXH5BasX3f47hzMbh5SaY8sty78Hr1oNTp7joaVVum1kbt0FPKL21yljI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7794
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 40BA2888E10CAC9482EBC1781F056769094A88DA63CB98C6F143522628A351352
X-Proofpoint-ORIG-GUID: 9I9m_rkGRmh8klt4_IV7uqdv5TPzxiC4
X-Proofpoint-GUID: 9I9m_rkGRmh8klt4_IV7uqdv5TPzxiC4
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-17_08,2022-02-17_01,2021-12-02_01
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 adultscore=0 impostorscore=0 priorityscore=1501 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202170101
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Mj3GcNTJZ4UumR4Id2WYaLyEJzQ>
X-Mailman-Approved-At: Tue, 22 Feb 2022 09:16:04 -0800
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
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: Thu, 17 Feb 2022 21:32:46 -0000

Andy,

The errata form specifically describes submission of RFC 2119 keywords:

> Technical – error in the technical content (Note that changes in the usage of RFC 2119 keywords are considered technical.)

So, it is definitively something which is appropriate to raise errata to.

I have already replied to Randy’s point of sparing usage.

I continue to see ambiguity in how strong the requirement of ordering of XML payload.  However, it sounds like what you saying that there is no ambiguity, and the language is strong enough already to be read as if “MUST” was in there; did I get it right?  And if I did what is the harm of accepting errata?

Best regards,

Alexei Sadovnikov
Principal System Architect
Business Solutions
AT&T Business

AT&T Services, Inc.
550 Cochituate Road, Framingham, MA 01701
m  781.249.1516 |  o  781.249.1516 |  as549r@att.com<mailto:as549r@att.com>

This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s),  or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited.



From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, February 17, 2022 at 3:12 PM
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Martin Bjorklund <mbj@tail-f.com>, Warren Kumari <warren@kumari.net>, Robert Wilton <rwilton@cisco.com>, Joel Jaeggli <joelja@bogus.com>, Kent Watsen <kent+ietf@watsen.net>, Berger Lou <lberger@labn.net>, as549r <AS549R@att.com>, NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)



On Thu, Feb 17, 2022 at 11:54 AM Randy Presuhn <randy_presuhn@alumni.stanford.edu<mailto:randy_presuhn@alumni.stanford.edu>> wrote:
Hi -

This seems like a remarkably pointless change, and arguably
at odds with section 6 of RFC 2119. ("Imperatives of the type
defined in this memo must be used with care and sparingly.")

+1

IMO RFC 2119 keywords MUST NOT be added, modified, or removed using an Errata.
In this specific case, there is no ambiguity that needs to be corrected.


Randy


Andy


On 2022-02-17 10:50 AM, RFC Errata System wrote:
 > The following errata report has been submitted for RFC7950,
 > "The YANG 1.1 Data Modeling Language".
 >
 > --------------------------------------
 > You may review the report below and at:
 > https://www.rfc-editor.org/errata/eid6855<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-tBUYkKx$>
 >
 > --------------------------------------
 > Type: Technical
 > Reported by: Alexei Sadovnikov <as549r@att.com<mailto:as549r@att.com>>
 >
 > Section: GLOBAL
 >
 > Original Text
 > -------------
 > 7.5.  The "container" Statement
 > 7.5.7.  XML Encoding Rules
 >
 >     A container node is encoded as an XML element.  The element's local
 >     name is the container's identifier, and its namespace is the module's
 >     XML namespace (see Section 7.1.3).
 >
 >     The container's child nodes are encoded as subelements to the
 >     container element.  If the container defines RPC or action input or
 >     output parameters, these subelements are encoded in the same order as
 >     they are defined within the "container" statement.  Otherwise, the
 >     subelements are encoded in any order.
 >
 > 7.8. The "list" Statement
 > 7.8.5.  XML Encoding Rules
 >
 >     The list's key nodes are encoded as subelements to the list's
 >     identifier element, in the same order as they are defined within the
 >     "key" statement.
 >
 >     The rest of the list's child nodes are encoded as subelements to the
 >     list element, after the keys.  If the list defines RPC or action
 >     input or output parameters, the subelements are encoded in the same
 >     order as they are defined within the "list" statement.  Otherwise,
 >     the subelements are encoded in any order.
 >     . . . . .
 >
 > 7.14.  The "rpc" Statement
 > 7.14.4.  NETCONF XML Encoding Rules
 >
 >     . . . . .
 >
 >     Input parameters are encoded as child XML elements to the rpc node's
 >     XML element, in the same order as they are defined within the "input"
 >     statement.
 >
 >     If the RPC operation invocation succeeded and no output parameters
 >     are returned, the <rpc-reply> contains a single <ok/> element defined
 >     in [RFC6241].  If output parameters are returned, they are encoded as
 >     child elements to the <rpc-reply> element defined in [RFC6241], in
 >     the same order as they are defined within the "output" statement.
 >
 >
 > 7.15.  The "action" Statement
 > 7.15.2.  NETCONF XML Encoding Rules
 >
 >     . . . . .
 >
 >     The <action> element contains a hierarchy of nodes that identifies
 >     the node in the datastore.  It MUST contain all containers and list
 >     nodes in the direct path from the top level down to the list or
 >     container containing the action.  For lists, all key leafs MUST also
 >     be included.  The innermost container or list contains an XML element
 >     that carries the name of the defined action.  Within this element,
 >     the input parameters are encoded as child XML elements, in the same
 >     order as they are defined within the "input" statement.
 >
 >     . . . . .
 >
 >     If the action operation invocation succeeded and no output parameters
 >     are returned, the <rpc-reply> contains a single <ok/> element defined
 >     in [RFC6241].  If output parameters are returned, they are encoded as
 >     child elements to the <rpc-reply> element defined in [RFC6241], in
 >     the same order as they are defined within the "output" statement.
 >
 >
 > Corrected Text
 > --------------
 > 7.5.  The "container" Statement
 > 7.5.7.  XML Encoding Rules
 >
 >     . . . . .
 >
 >     The container's child nodes are encoded as subelements to the
 >     container element.  If the container defines RPC or action input or
 >     output parameters, these subelements MUST be encoded in the same
order as
 >     they are defined within the "container" statement.  Otherwise, the
 >     subelements are encoded in any order.
 >
 > 7.8. The "list" Statement
 > 7.8.5.  XML Encoding Rules
 >
 >     The list's key nodes MUST be encoded as subelements to the list's
 >     identifier element, in the same order as they are defined within the
 >     "key" statement.
 >
 >     The rest of the list's child nodes are encoded as subelements to the
 >     list element, after the keys.  If the list defines RPC or action
 >     input or output parameters, the subelements MUST be encoded in
the same
 >     order as they are defined within the "list" statement.  Otherwise,
 >     the subelements are encoded in any order.
 >     . . . . .
 >
 > 7.14.  The "rpc" Statement
 > 7.14.4.  NETCONF XML Encoding Rules
 >
 >     . . . . .
 >
 >     Input parameters MUST be encoded as child XML elements to the rpc
node's
 >     XML element, in the same order as they are defined within the "input"
 >     statement.
 >
 >     If the RPC operation invocation succeeded and no output parameters
 >     are returned, the <rpc-reply> contains a single <ok/> element defined
 >     in [RFC6241].  If output parameters are returned, they MUST be
encoded as
 >     child elements to the <rpc-reply> element defined in [RFC6241], in
 >     the same order as they are defined within the "output" statement.
 >
 >
 > 7.15.  The "action" Statement
 > 7.15.2.  NETCONF XML Encoding Rules
 >
 >     . . . . .
 >
 >     The <action> element contains a hierarchy of nodes that identifies
 >     the node in the datastore.  It MUST contain all containers and list
 >     nodes in the direct path from the top level down to the list or
 >     container containing the action.  For lists, all key leafs MUST also
 >     be included.  The innermost container or list contains an XML element
 >     that carries the name of the defined action.  Within this element,
 >     the input parameters MUST be encoded as child XML elements, in
the same
 >     order as they are defined within the "input" statement.
 >
 >     . . . . .
 >
 >     If the action operation invocation succeeded and no output parameters
 >     are returned, the <rpc-reply> contains a single <ok/> element defined
 >     in [RFC6241].  If output parameters are returned, they MUST be
encoded as
 >     child elements to the <rpc-reply> element defined in [RFC6241], in
 >     the same order as they are defined within the "output" statement.
 >
 > Notes
 > -----
 > The RFC 2119 keywords are missing in description of ordering for XML
encoding rules for RPC, actions and references thereto and in additional
instance of list keys encoding.
 >
 > Although the text of RFC suggests reading this as if "MUST" was
present, without keyword it is open to interpretation if the sentences
actually mean "MUST" or "SHOULD" or may be even "MAY".
 >
 > In other places discussing ordering, for example 7.7.8., 7.8.5. and
7.9.5. the "MUST" is actually present, hence proposed errata would make
ordering description usage of keywords consistent.
 >
 > 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.
 >
 > --------------------------------------
 > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
 > --------------------------------------
 > Title               : The YANG 1.1 Data Modeling Language
 > Publication Date    : August 2016
 > Author(s)           : M. Bjorklund, Ed.
 > Category            : PROPOSED STANDARD
 > Source              : Network Modeling
 > Area                : Operations and Management
 > Stream              : IETF
 > Verifying Party     : IESG
 >
 > _______________________________________________
 > netmod mailing list
 > netmod@ietf.org<mailto:netmod@ietf.org>
 > https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>