IETF Logo Mail Archive

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

"Acee Lindem (acee)" <acee@cisco.com> Wed, 18 October 2017 14:09 UTC

Return-Path: <acee@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 58FD21326ED; Wed, 18 Oct 2017 07:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.3
X-Spam-Level:
X-Spam-Status: No, score=-17.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, 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 bcEnzIfDUVCn; Wed, 18 Oct 2017 07:09:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDE91270AB; Wed, 18 Oct 2017 07:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1508335763; x=1509545363; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ONseO6QtooqDJKICd/+xEVs4OByaITsdGXH/6Yc4K9o=; b=PMgAUHQK02ICQw2lqDsH+mipobjIijYaYDcnzD+lODyU+2hzr0Uw6TQL +eHA/oqJCg1BTkjtjDxOcUra61MkmQL8qu9F23PCV7IAJFQ9avjW3Oj8E mplTKyWRGyf9F/9zGuG/W7XUMfpE3WBc+l8jWNsVEni6QoY7y1v+kU1hM A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CkAAAuYOdZ/51dJa1ZAxkBAQEBAQEBAQEBAQcBAQEBAYNfZG4nB4Nzih+POIF4ljOCFAoYC4RJTwIahF8/GAECAQEBAQEBAWsohR0BAQEDAQEBIRE6Cw4CAgEIEAUDAgImAgICGQwLFRACBAENBRuJfQgQqlCCJ4s5AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoIgggeGaIUFFwomgkyCYQWhSwKUapMYlUYCERkBgTgBHziBW3oVSYJkCYRWdoglLIEFgREBAQE
X-IronPort-AV: E=Sophos;i="5.43,397,1503360000"; d="scan'208";a="307464802"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 14:09:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v9IE9MAQ009188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Oct 2017 14:09:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 18 Oct 2017 10:09:21 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 18 Oct 2017 10:09:21 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-rfc6087bis@ietf.org" <draft-ietf-netmod-rfc6087bis@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLoAkGAgADU1oCAABYiAIAANyAAgAB5vgCAAGhAAP//1wyA
Date: Wed, 18 Oct 2017 14:09:21 +0000
Message-ID: <D60CD7EA.CFE39%acee@cisco.com>
References: <DE7DEC2E-F737-4020-8830-AF556A65EEF5@juniper.net> <001701d3470b$8f473fe0$add5bfa0$@clemm.org> <EA300017-CDE0-4006-95D5-D2E81CBBE9E3@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com> <20171018062228.dx7etbayhuslswkx@elstar.local> <d79e33af5ec5409aafe3dcbc3184c37f@XCH-RTP-013.cisco.com>
In-Reply-To: <d79e33af5ec5409aafe3dcbc3184c37f@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: <018B7B8ECFF9654389D8C21AC6DBA7F3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gsO-bQxt-OyrKk0UNUgOtoCT594>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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 Oct 2017 14:09:25 -0000


On 10/18/17, 8:35 AM, "netmod on behalf of Eric Voit (evoit)"
<netmod-bounces@ietf.org on behalf of evoit@cisco.com> wrote:

>> From: Juergen Schoenwaelder, October 18, 2017 2:22 AM
>> 
>> On Tue, Oct 17, 2017 at 11:06:44PM +0000, Eric Voit (evoit) wrote:
>> >
>> > Section 3.10: There should be a normative set of YANG validation
>>tools which
>> are run on upload of an Internet draft.   Errors and warnings found
>>later (and
>> perhaps through tools a user doesn't have) should not result in a
>>module being
>> given an error designation.
>> >
>> 
>> I disagree. An error is an error regardless when or how it was detected.
>
>What I am trying to avoid is YANG errors being discovered via validation
>tools for which the model author has no access to before a submitted
>draft is accepted.   However this can be accomplished is fine with me.
>
>One solution is to ensure the RFC upload process has access to all tools
>currently used for model validation.

Right now YANG validation errors and warnings do not block submittal. This
good since there are some very annoying false positives in the draft YANG
validation. For example, submodule validation is broken even if the module
and submodule are in the same draft. Additionally, the status validation
spouts out false warnings. I reported the first problem and it was blown
off. 

Thanks,
Acee 




>
>Eric
>
>> /js
>> 
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

v2.26.15 | Report a Bug | By Email | System Status