From nobody Thu Jan 12 07:37:16 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4FE1293D8 for ; Thu, 12 Jan 2017 05:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.de 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 cV1mv8d-LO8E for ; Thu, 12 Jan 2017 05:26:01 -0800 (PST) Received: from nm31-vm8.bullet.mail.ir2.yahoo.com (nm31-vm8.bullet.mail.ir2.yahoo.com [212.82.97.95]) (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 A68171295F8 for ; Thu, 12 Jan 2017 05:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1484227558; bh=r2ORghMBl0GiE2AD8jgKQlaae9lnJ9PlvS2d9uXmJSk=; h=From:To:Subject:Date:From:Subject; b=ogKgsrbrVJmANf4YwMP6lJrKySQ4IBCE408DCm2ZT2ZqmQ9pUe45Tplwn542mJhlMFIVz3ZIAVA7+3F9pB0wjl08bdLXBzs/iaLAhZI5imOoag6uUFFmazI2V11YNjOeI/Pv69bULo6ucflhnqGC5DIb12cXAu5B1iCzJwlpR24Vikpv33UxX1cwSqgHYHFy4JNQWYKl8cQTgf2A0BV7licC2mc3twsyPW0sGuC0F3XJ5cN3d8LNmm5IHZso7/IhR3A2fGfKJm1rO7X9vev71KWizWp/CeZdXWAe+2dGEvSoOEtzRmwsZZmdJ9sJPDpRAl2ZUBWs3TvfiJOEOLpicg== Received: from [212.82.98.52] by nm31.bullet.mail.ir2.yahoo.com with NNFMP; 12 Jan 2017 13:25:58 -0000 Received: from [46.228.39.97] by tm5.bullet.mail.ir2.yahoo.com with NNFMP; 12 Jan 2017 13:25:55 -0000 Received: from [127.0.0.1] by smtp134.mail.ir2.yahoo.com with NNFMP; 12 Jan 2017 13:23:18 -0000 X-Yahoo-Newman-Id: 420912.41665.bm@smtp134.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rVturmUVM1m0KghmabysQ4WtJqZ9m0jnMeVQ2sIUh2BRpFT 7XsfaSFUA10TQrL6sy6axtpX.TqmaSnGg_2699XJEJmG103OBc0ZY3jW4Vwn MjRasAIh0hatKJzzSEYc5TyRbqBgeCoPfTBhd3KaFM5baqLh79_osDfKTyuQ pESkPdDmorBWtversPFyYH40xf4PE2Z.zaphCfIVYxlgPxy3AY266OAmjFGs CHxFovSH7UzCEJmrtYNr2VG23opq48XgyiGb3y9VL522yXrE.bBXLyS1IR4f 4vcwZMbFd45k6SWg8G2qEmKCgw5J1R0YkwLItwVGAmepaQAYBbNooMrr9dF7 Lyk8nkGOECB5Q4E_DI0AhTRgNFUO7vpi9tFn60cL42MMwfVhVn3CcBuFv8sn Ga4pvH6Vxmv9dlosesaa31ifJMixLwc52OZr4svHs.UK_4mKc7yZhiSk_4ou h_HVgm9Ei7rCbJlzX1a41iL7X7a78djoX_ARNccuedhjBei8VUEqGDCWVEUG 0Idvxeqzg65Last3Mg_s5P5OdXE14.1srfZQ.iudtA5dMbc0- X-Yahoo-SMTP: A2X7QISswBAowFeUAE8L1nQV128_rV.gGg-- From: "Mehmet Ersue" To: Date: Thu, 12 Jan 2017 14:23:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01D26CDF.6C8F8EA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJs1wotOpKihegVS3Oksw+nFBOVaA== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0202.58778346.00D9,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: X-Mailman-Approved-At: Thu, 12 Jan 2017 07:37:15 -0800 Subject: [yang-doctors] Testing whether anybody at IETF can send a mail to YANG Doctors Team X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:26:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0112_01D26CDF.6C8F8EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test Cheers, Mehmet ------=_NextPart_000_0112_01D26CDF.6C8F8EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Test

 

Cheers,

Mehmet

 

------=_NextPart_000_0112_01D26CDF.6C8F8EA0-- From nobody Fri Jan 13 05:54:02 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B5C129C13; Fri, 13 Jan 2017 05:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_H4=-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 shKhAa82wRdC; Fri, 13 Jan 2017 05:53:56 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1BB129BC6; Fri, 13 Jan 2017 05:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3215; q=dns/txt; s=iport; t=1484315635; x=1485525235; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mZlFrmfHE9ipWzpQFEnRJLubYyBNmyQImeAPSEItJ98=; b=deoPUebcZ36NFCLWCpWmnfQNNTUtqUeHnMyJUn9+HvnnvrbpXrGyf0pD rOqR4u77JgDQ/OqlrZZM7laD0RzdwVo6ZuurBloSFBj/OMx27s2Q80K8d Zp+sI9WLJxrv9agU39C/EblQViRWyfocIlLy0M7ArRcqorfc5RVyCRwlk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgAq23hY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAYEBJ48ppD+EHIYiAoJSEQECAQEBAQEBAWMohGoGODM?= =?us-ascii?q?HBxALRlcGAQwIAQGIf7J+igwBAQEBAQEBAQEBAQEBAQEBAQEghkWCAoJfigsfA?= =?us-ascii?q?QSVKoYIkVmKL4Y+imqHezUigRUSCBUVOoQ1HIFgPYkbAQEB?= X-IronPort-AV: E=Sophos;i="5.33,221,1477958400"; d="scan'208";a="691315725" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2017 13:53:53 +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 v0DDrpw5006623; Fri, 13 Jan 2017 13:53:52 GMT To: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= , draft-ietf-rtgwg-yang-vrrp@tools.ietf.org References: From: Benoit Claise Message-ID: <2ce9c556-9a97-f353-34bb-e545ad3b70cf@cisco.com> Date: Fri, 13 Jan 2017 14:53:48 +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: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org, "rtgwg@ietf.org" Subject: Re: [yang-doctors] YANG Doctors review for draft-ietf-rtgwg-yang-vrrp X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 13:53:57 -0000 Including the rtgwg list. Regards, B. > Hi, > > I was asked to review the draft-ietf-rtgwg-yang-vrrp document, here > are my comments: > > - overall, the module is in a good shape, the common compilers are > able to parse it and do not complain about anything > > - the I-D text is very brief - some more detailed text about the > scope, relationship to other (augmented) modules and use cases for the > module would be welcome. Similarly, I would appreciate more detailed > description of the specific sections of the module. The use cases can > be demonstrated on configuration data examples which are now > completely missing. > > - it seems to me that at least some of the leafs in notifications are > supposed to be mandatory, maybe not only in notifications, but I'm not > expert in this area. > - e.g. the interface leaf in vrrp-virtual-router-error-event > notification, the leaf is then also used in path expression for > vrid-v4 (vrid-v6) leafref > > - module imports ietf-interfaces and ietf-ip, thus it MUST contain > normative references to RFC 7223 and RFC RFC 7277 - in I-D's reference > section as well as in the module (as other imported modules are > already referenced) > > - unify the new-master-reason-type enums' names: (master-)preempted vs > master-no-response > > - the local module prefix SHOULD be used instead of no prefix in all > path expressions (e.g. vrid-v4, vrid-v6) > > - consider changing type of the version leaf in vrrp-common-attributes > grouping to identityref - that way it would be possible only to > augment the current module for any future version of the protocol, > enumeration is limiting > > - vrrp-v3-attributes grouping seems as an addition to the > vrrp-common-attributes (at least it is always used together with > vrrp-common-attributes). Do you see (e.g. in some other module) a use > case to instantiate vrrp-common-attributes without vrrp-v3-attributes? > If not, the vrrp-v3-attributes should be placed into > vrrp-v3-attributes grouping. It is also question if it needs in that > case a separate grouping, the accept-mode leaf could be placed > directly into the common grouping just with the when condition. > > - having a key of the "network" list named "network" (in > vrrp-ipv4-attributes/track) seems as a bad design, try to rename the > list or its key, also the descriptions of the network list and its > container networks are not very clear. > > - the names in the comments behind the closing brackets inside the > vrrp-ipv4-attributes/track container are wrong (e.g. track-interfaces > instead of interfaces or track-networks instead of networks) > > - the previous 2 notes also apply to vrrp-ipv6-attributes grouping > > - vrrp-state-attributes/up-time - uptime is usually interpreted as a > time duration, but here it is used as a moment in time, so if it is > not defined this way in VRRP protocol, consider renaming > > - vrrp-state-attributes/last-event - are the events really so generic > that the type here must be a string? Maybe having identities for them > could help readability and understandability. > > > Radek > > . > From nobody Mon Jan 16 13:35:45 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130EF12969F; Mon, 16 Jan 2017 13:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.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 UWtAASQiuVSV; Mon, 16 Jan 2017 13:35:40 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0116.outbound.protection.outlook.com [104.47.32.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2943812969B; Mon, 16 Jan 2017 13:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CKtszOphzgm7xx1FSmk4+hST+sMk6/Pvvl/LL0Li7zw=; b=gZQiICwjG3GARHb0aaz2HnxNaKpTG1Cy6VxtAxM5NuVCJyk1QK9al37JJ3Rl1QaRoN2a7fUp44sEr9ZfqUd2tcZ5bo+/Rz04NZEY3sDwzxSISWXKQBIbuPeohtec2w0N5ZU+t1IhVi9/o/X7XykcWoEb/xDviROwrX9KyNTJD+4= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1143.namprd02.prod.outlook.com (10.162.168.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Mon, 16 Jan 2017 21:35:37 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0845.013; Mon, 16 Jan 2017 21:35:37 +0000 From: Xufeng Liu To: Ladislav Lhotka , "draft-ietf-rtgwg-yang-rip.all@ietf.org" Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 Thread-Index: AQHSUKM3mq8eSl8wzkmA/k4AouAueKE3DBMg Date: Mon, 16 Jan 2017 21:35:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [72.209.195.86] x-ms-office365-filtering-correlation-id: 5e0a99a0-d713-4236-e5cb-08d43e579cb9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR02MB1143; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1143; 7:3yrUN5+AAeaPw0vbg59F82BBCkVoUAWqZdITx0JDWtUjejQfWbayupnyddwOmASjJJpYiEVpXa7kJ7dpUVxEuvwHO9JsyZo4AUnE/AcnH6xZGOHH98U5NlLchK+uZEyTS0Y2phw+Lz1SZ2i0l/xNHEVVhe7ZUYnzsHqZZYUKeeG1sBrfbfeNZeWc07G9oUJoye8A8clqt2pPXZ+WKFioxmJzhNBlf6Ojiiq1V7K4+KbnPoOD4izrQNH6cW6/mypHNI1hsH77w1yMKX8E6mcDs7PrNSZ35zSW6h9TgICi1TsHnKLog7ELyknlHTmcY7wrO8pE4khD1W1NACdMyXct45oOcNWFJVm65XUPvD2F9c0PW/7O74Rbgh8ovSGHmb0kD/rLemcT4SkiLcTo01uB3sH+G7Vg/Ilr1IuZ58tQFvyjxFwhbaqE9UkGZY5Qt47pe8SRSrPCPKNUEnHYmKBuyg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR02MB1143; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1143; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(13464003)(189002)(199003)(377454003)(51914003)(2950100002)(4326007)(68736007)(102836003)(7736002)(106116001)(2906002)(189998001)(66066001)(5660300001)(8936002)(92566002)(3280700002)(50986999)(9686003)(6116002)(5001770100001)(76176999)(31001)(33001)(43001)(35001)(36001)(32001)(229853002)(30001)(230783001)(106356001)(3846002)(105586002)(54356999)(80792005)(2501003)(101416001)(74316002)(99286003)(33656002)(38730400001)(77096006)(2900100001)(55016002)(34001)(6306002)(575784001)(6436002)(305945005)(7696004)(25786008)(3660700001)(86362001)(81156014)(122556002)(6506006)(81166006)(97736004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1143; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2017 21:35:37.2523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1143 Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-rip-02 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:35:43 -0000 SGkgTGFkYSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBBbiB1cGRhdGVkIHZlcnNpb24gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1yaXAtMDMgaGFz IGp1c3QgYmVlbiBwb3N0ZWQgdG8gYWRkcmVzcyBtb3N0IG9mIHRoZXNlIGl0ZW1zLg0KUGxlYXNl IGxldCB1cyBrbm93IGZvciBhbnkgZnVydGhlciBpc3N1ZXMuDQoNClRoYW5rcywNCi0gWHVmZW5n DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGFkaXNsYXYgTGhvdGth IFttYWlsdG86bGhvdGthQG5pYy5jel0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA3LCAy MDE2IDExOjAxIEFNDQo+IFRvOiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctcmlwLmFsbEBpZXRmLm9y Zw0KPiBDYzogeWFuZy1kb2N0b3JzQGlldGYub3JnDQo+IFN1YmplY3Q6IFlBTkcgZG9jdG9yIHJl dmlldyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctcmlwLTAyDQo+IA0KPiBIaSwNCj4gDQo+IEkg d2FzIGFzc2lnbmVkIHRvIGJlIHRoZSBZQU5HIGRvY3RvciBmb3IgdGhpcyBkb2N1bWVudC4gSGVy ZSBpcyBteQ0KPiByZXZpZXc6DQo+IA0KPiAqKioqIEdlbmVyYWwgY29tbWVudHMNCj4gDQo+IE92 ZXJhbGwsIHRoZSBtb2R1bGUgaXMgaW4gYSBnb29kIHNoYXBlIGFuZCBpbnRlZ3JhdGVzIG5pY2Vs eSB3aXRoIHRoZSBjb3JlDQo+IHJvdXRpbmcgZGF0YSBtb2RlbCBbUkZDIDgwMjJdLg0KPiANCj4g VGhlIEktRCB0ZXh0IGlzIHJhdGhlciBzY2FyY2UsIGFwYXJ0IGZyb20gdGhlIG1vZHVsZSBpdCBl c3NlbnRpYWxseSBjb250YWlucyBvbmx5DQo+IGJvaWxlcnBsYXRlIHN0dWZmLiBTb21lIGluZm9y bWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IGluIHdoaWNoIHRoaXMgbW9kdWxlIGlzDQo+IHN1cHBv c2VkIHRvIGJlIHVzZWQsIGRlc2lnbiBkZWNpc2lvbnMgZXRjLiB3b3VsZCBiZSBjZXJ0YWlubHkg dXNlZnVsLg0KPiANCltYdWZlbmddIA0KQWRkZWQgc2VjdGlvbnMgMi4xIHRvIDIuNyAgdG8gZGVz Y3JpYmUuDQoNCj4gQSBub24tbm9ybWF0aXZlIGFwcGVuZGl4IHdpdGggYSBjb25maWd1cmF0aW9u IGV4YW1wbGUgKGluc3RhbmNlIGRhdGEpIHdvdWxkDQo+IGFsc28gaGVscCBwZW9wbGUgdGhhdCBh cmUgbm90IGZsdWVudCBpbiBZQU5HIHRvIHVuZGVyc3RhbmQgd2hhdCBkYXRhIGFyZQ0KPiBpbmNs dWRlZCBpbiB0aGlzIG1vZGVsLg0KPiANCltYdWZlbmddIA0KQWRkZWQgQXBwZW5kaXggQS4gdG8g c2hvdyBhbiBleGFtcGxlLg0KDQo+IFNvbWUgcGFydHMgb2YgdGhlIG1vZGVsIOKAkyAiZGlzdHJp YnV0ZS1saXN0IiwgInJlZGlzdHJpYnV0ZSIsICJiZmQiLA0KPiAiYXV0aGVudGljYXRpb24iIG9u IGludGVyZmFjZXMgKG9yIGF0IGxlYXN0IHRoZSAia2V5IiBsaXN0KSDigJMgYXJlIHByb2JhYmx5 IG5vdA0KPiBzcGVjaWZpYyB0byBSSVAgYW5kIGNvdWxkIGJlIHVzZWQgYnkgb3RoZXIgcHJvdG9j b2xzIGFzIHdlbGwuIElmIGl0IGlzIHNvLCBpdCB3b3VsZA0KPiBiZSBiZXR0ZXIgdG8gbW9kZWwg dGhlbSBzZXBhcmF0ZWx5IGFzIGdlbmVyYWwgbWVjaGFuaXNtcy4NCj4gDQpbWHVmZW5nXSANClRo ZSAiYmZkIiBhbmQgImF1dGhlbnRpY2F0aW9uIiAgc2VjdGlvbnMgaGF2ZSBiZWVuIHJlLXVzZWQg YnkgaW1wb3J0aW5nIHRoZSBjb3JyZXNwb25kaW5nIG1vZGVscy4gVGhlIHdheXMgdGhhdCB3ZSB1 c2UgdGhlbSBhcmUgYmFzZWQgb24gdGhlIHJlY29tbWVuZGF0aW9ucyBmcm9tIHRoZSBjb3JyZXNw b25kaW5nIG1vZGVscy4gRm9yIHNvbWUgcG9ydGlvbnMgb2YgImRpc3RyaWJ1dGUtbGlzdCIgYW5k ICJyZWRpc3RyaWJ1dGUiLCB3ZSBwcmV2aW91c2x5IHJlLXVzZWQgc29tZSByZWZlcmVuY2VzIGZy b20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRnd2ctcG9saWN5LW1v ZGVsLTAxLCBidXQgdGhhdCBkcmFmdCBoYXMgZXhwaXJlZCBhbmQgZ290IG91dCBvZiBzeW5jaCB3 aXRoIHRoZSBvdGhlciBjdXJyZW50IElFVEYgbW9kZWwgZHJhZnRzLiBNb3Jlb3Zlciwgc29tZSBv ZiB0aGUgInJlZGlzdHJpYnV0ZSIgYXJlIG5vdCBjb21tb24gd2l0aCBvdGhlciBwcm90b2NvbHMs IGFuZCBtYXkgYmUgYmV0dGVyIHRvIHNwZWNpZmllZCBpbiB0aGlzIHByb3RvY29sIHNwZWNpZmlj IHdheS4NCg0KPiBEb2N1bWVudHMgY29udGFpbmluZyBZQU5HIG1vZHVsZXMgdGhhdCBhcmUgaW1w b3J0ZWQgYnkgaWV0Zi1yaXAgc2hvdWxkDQo+IGFwcGVhciBhbW9uZyBub3JtYXRpdmUgcmVmZXJl bmNlcy4gT25lIHdheSB0byBhY2hpZXZlIHRoaXMgKHdoaWNoIGlzIGFsc28NCj4gdXNlZnVsIGJ5 IGl0c2VsZikgaXMgdG8gaW5jbHVkZSBhIHRhYmxlIG9mIG5hbWVzcGFjZSBwcmVmaXhlcywgc2Vl IGUuZy4NCj4gDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDIyI3NlY3Rpb24t Mi4zDQpbWHVmZW5nXSBBZGRlZCBhY2NvcmRpbmcgdGhlIHJlZmVyZW5jZS4gVGhhbmtzLg0KPiAN Cj4gKioqKiBTcGVjaWZpYyBjb21tZW50cw0KPiANCj4gICAgICAtIE1hdGNoaW5nIGlkZW50aXRp ZXMgaXMgZG9uZSBpbiB0aGUgb2xkIFlBTkcgMS4wIHdheSwgZm9yDQo+ICAgICAgICBleGFtcGxl Og0KPiANCj4gICAgICAgIHdoZW4gInJ0OnR5cGUgPSAncmlwOnJpcHYyJyBvciBydDp0eXBlID0g J3JpcDpyaXBuZyciDQo+IA0KPiAgICAgICAgVGhpcyBpcyBmcmFnaWxlIGJlY2F1c2UgdGhlIGlk ZW50aXRpZXMgYXJlIG1hdGNoZWQgYmFzZWQgb24NCj4gICAgICAgIHN0cmluZyBlcXVhbGl0eSwg c28gdGhlIHJlc3VsdCBkZXBlbmRzIG9uIHRoZSBjaG9pY2Ugb2YgdGhlDQo+ICAgICAgICBuYW1l c3BhY2UgcHJlZml4LiBVbmxlc3MgdGhlcmUgaXMgYSBzdHJvbmcgcmVhc29uIG5vdCB0byB1c2UN Cj4gICAgICAgIFlBTkcgMS4xLCB0aGlzIGlzIG11Y2ggc2ltcGxlciBhbmQgbW9yZSBydWJ1c3QN Cj4gDQo+ICAgICAgICB3aGVuICJkZXJpdmVkLWZyb20ocnQ6dHlwZSwgJ3JpcDpyaXAnKSINCltY dWZlbmddIERvbmUuIFRoYW5rcy4NCj4gDQo+ICAgICAgLSBJbiAicmVkaXN0cmlidXRpb24iLCB0 aGUgbXVzdCBleHByZXNzaW9ucyBhcmUgb3V0cmlnaHQgYnJva2VuLA0KPiAgICAgICAgZS5nLiBm b3IgSVMtSVM6DQo+IA0KPiAgICAgICAgbXVzdCAiLi4vLi4vLi4vLi4vLi4vcnQ6Y29udHJvbC1w bGFuZS1wcm90b2NvbCINCj4gICAgICAgICsgIltydDpuYW1lID0gY3VycmVudCgpXS90eXBlID0g J2lzaXMnIiB7IC4uLiB9DQo+IA0KPiAgICAgICAgRmlyc3QsIHRoZSBpZXRmLXJpcCBtb2R1bGUg YWxzbyBuZWVkcyB0byBpbXBvcnQgaWV0Zi1pc2lzLCBhbmQNCj4gICAgICAgIHRoZW4gdGhlIG11 c3Qgc3RhdGVtZW50IGNhbiBiZSByZXdyaXR0ZW4gbGlrZSBzbzoNCj4gDQo+ICAgICAgICBtdXN0 ICJkZXJpdmVkLWZyb20tb3Itc2VsZigiDQo+ICAgICAgICArICIuLi8uLi8uLi8uLi8uLi9ydDpj b250cm9sLXBsYW5lLXByb3RvY29sIg0KPiAgICAgICAgKyAiW3J0Om5hbWUgPSBjdXJyZW50KCld L3R5cGUsICdpc2lzOmlzaXMnKSINCltYdWZlbmddIEZpeGVkLg0KPiANCj4gICAgICAtIFNvbWUg ZGVzY3JpcHRpb25zIGNvdWxkIG1lbnRpb24gdGhhdCB0aGUgcGFyYW1ldGVyIChmZWF0dXJlDQo+ ICAgICAgICBldGMuKSBvbmx5IGFwcGxpZXMgdG8gUklQLiBGb3IgZXhhbXBsZSwgaW4NCj4gDQo+ ICAgICAgICBmZWF0dXJlIGludGVyZmFjZS1zdGF0aXN0aWNzIHsNCj4gICAgICAgICAgZGVzY3Jp cHRpb24NCj4gICAgICAgICAgICAiVGhpcyBmZWF0dXJlIGluZGljYXRlcyB0aGF0IHRoZSBzeXN0 ZW0gc3VwcG9ydHMgY29sbGVjdGluZw0KPiAgICAgICAgICAgICBwZXItaW50ZXJmYWNlIHN0YXRp c3RpYyBkYXRhLiI7DQo+ICAgICAgICB9DQo+IA0KPiAgICAgICAgSSB3b3VsZCBhZGQgIi4uLiBy ZWxhdGVkIHRvIFJJUC4iIGF0IHRoZSBlbmQuDQpbWHVmZW5nXSBDaGFuZ2VkIGZvciB0aGlzIGFu ZCBzb21lIG90aGVyIGRlc2NyaXB0aW9ucy4NCj4gDQo+ICAgICAgLSBNYXliZSBpdCdzIGFic29s dXRlbHkgY2xlYXIgdG8gZXhwZXJ0cyBidXQgdGhlIG5hbWUgYW5kDQo+ICAgICAgICBkZXNjcmlw dGlvbiBvZiB0aGUgIm5laWdoYm9yLWNvbmZpZ3VyYXRpb24iIGZlYXR1cmUgbG9vayBsaWtlDQo+ ICAgICAgICB0aGUgZmVhdHVyZSBjYW4gbWFrZSBuZWlnaGJvcnMgcmVtb3RlbHkgY29uZmlndXJh YmxlLiBJIGhhZCB0bw0KPiAgICAgICAgbG9vayB1cCB3aGVyZSBpdCBpcyB1c2VkIHRvIGZpbmQg b3V0IHdoYXQncyB0aGUgcmVhbA0KPiAgICAgICAgbWVhbmluZy4gUGVyaGFwcyBzb21ldGhpbmcg bGlrZSAiZXhwbGljaXQtbmVpZ2hib3JzIiBtaWdodCBiZQ0KPiAgICAgICAgZWFzaWVyIHRvIHVu ZGVyc3RhbmQ/DQpbWHVmZW5nXSBDaGFuZ2VkLg0KPiANCj4gICAgICAtIFRoZSBuYW1lIG9mICJu by1zdXBwbHkiIGxlYWYgbG9va3Mgc3RyYW5nZS4gSSBjaGVja2VkIGEgY291cGxlDQo+ICAgICAg ICBvZiBDTElzIGFuZCB0aGV5IHVzZSAicGFzc2l2ZSIsICJwYXNzaXZlLWludGVyZmFjZSIgb3IN Cj4gICAgICAgICJzZW5kLW9wdGlvbnMiIGZvciBwcmV2ZW50aW5nIFJJUCB1cGRhdGVzIGZyb20g YmVpbmcgc2VudC4NCltYdWZlbmddIENoYW5nZWQuDQo+IA0KPiAgICAgIC0gSW4gInNwbGl0LWhv cml6b24iIGxlYWYsIEkgd291bGQgdXNlICJwb2lzb24tcmV2ZXJzZSIgZW51bQ0KPiAgICAgICAg cmF0aGVyIHRoYW4gInBvaXNvbiIuDQpbWHVmZW5nXSBGaXhlZC4NCj4gDQo+IExhZGENCj4gDQo+ IC0tDQo+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogRTc0RThD MEMNCg== From nobody Mon Jan 16 23:29:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A767B1294A8 for ; Mon, 16 Jan 2017 23:29:29 -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 OmCbmJnEvnw2 for ; Mon, 16 Jan 2017 23:29:27 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F01B1293FD for ; Mon, 16 Jan 2017 23:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7315; q=dns/txt; s=iport; t=1484638167; x=1485847767; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=wu/w9ceVz7ir73aBd4G5WTR13LxnUbbXuMPuVJFB0F4=; b=GXq9W8p4vA2/nJGdbbuhH3frvpi8ru+zHLJmPbQBQCAlSmAeDeQs53OL ZCdbGPYupwfzvAKqb8XusXRQXU2HNYnHltYzjUwpg0/bq72GSdYtHnYFg 44nBVkH+/gNKbgcMFV/SFw8uGBezbS0pBnsJ6UMKG9eLQ65Aa9yBk0O6q E=; X-IronPort-AV: E=Sophos;i="5.33,243,1477958400"; d="scan'208,217";a="691416759" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 07:29:25 +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 v0H7TOlt031234; Tue, 17 Jan 2017 07:29:24 GMT References: <20170116221511.9D5C4B81A09@rfc-editor.org> To: YANG Doctors , Gerhard Muenz , Paul Aitken , Paul Aitken , Benoit Claise From: Benoit Claise X-Forwarded-Message-Id: <20170116221511.9D5C4B81A09@rfc-editor.org> Message-ID: <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> Date: Tue, 17 Jan 2017 08:29:23 +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: <20170116221511.9D5C4B81A09@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------3953965CB03C0CE253D4452A" Archived-At: Cc: Nevil Brownlee , Juergen Quittek Subject: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 07:29:30 -0000 This is a multi-part message in MIME format. --------------3953965CB03C0CE253D4452A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit YANG-doctors, Would you mind checking this errata? Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if this errata is correct, it's worth documenting IMO. Regards, Benoit -------- Forwarded Message -------- Subject: [Technical Errata Reported] RFC6728 (4909) Date: Mon, 16 Jan 2017 14:15:11 -0800 From: RFC Errata System To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6728, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 -------------------------------------- Type: Technical Reported by: Pavol Vican Section: 6 Original Text ------------- pattern "\S+" ... pattern "\S(.*\S)?" Corrected Text -------------- pattern '\S+' ... pattern '\S(.*\S)?' or pattern "\S+" ... pattern "\S(.*\S)?" Notes ----- RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash. 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. -------------------------------------- RFC6728 (draft-ietf-ipfix-configuration-model-11) -------------------------------------- Title : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols Publication Date : October 2012 Author(s) : G. Muenz, B. Claise, P. Aitken Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG . --------------3953965CB03C0CE253D4452A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit YANG-doctors,

Would you mind checking this errata?
Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if this errata is correct, it's worth documenting IMO.

Regards, Benoit


-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC6728 (4909)
Date: Mon, 16 Jan 2017 14:15:11 -0800
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu
CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC6728,
"Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909

--------------------------------------
Type: Technical
Reported by: Pavol Vican <vican.pavol@gmail.com>

Section: 6

Original Text
-------------
pattern "\S+"
...
pattern "\S(.*\S)?"

Corrected Text
--------------
pattern '\S+'
...
pattern '\S(.*\S)?'

or 

pattern "\S+"
...
pattern "\S(.*\S)?"

Notes
-----
RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash.

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. 

--------------------------------------
RFC6728 (draft-ietf-ipfix-configuration-model-11)
--------------------------------------
Title               : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols
Publication Date    : October 2012
Author(s)           : G. Muenz, B. Claise, P. Aitken
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.
--------------3953965CB03C0CE253D4452A-- From nobody Mon Jan 16 23:36:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05298129420 for ; Mon, 16 Jan 2017 23:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no 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 xMVVf6Gci3kE for ; Mon, 16 Jan 2017 23:36:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B151293F9 for ; Mon, 16 Jan 2017 23:36:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 36A246BD; Tue, 17 Jan 2017 08:36:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dF_bH2sC_-a9; Tue, 17 Jan 2017 08:36:22 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Jan 2017 08:36:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3EBF20090; Tue, 17 Jan 2017 08:36:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UoZ0d3b39vQH; Tue, 17 Jan 2017 08:36:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 350D2200A3; Tue, 17 Jan 2017 08:36:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7B5F3E272C1; Tue, 17 Jan 2017 08:36:25 +0100 (CET) Date: Tue, 17 Jan 2017 08:36:25 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20170117073625.GB1152@elstar.local> Mail-Followup-To: Benoit Claise , YANG Doctors , Gerhard Muenz , Paul Aitken , Paul Aitken , Nevil Brownlee , Juergen Quittek References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Paul Aitken , Juergen Quittek , Nevil Brownlee , Gerhard Muenz , Paul Aitken , YANG Doctors Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 07:36:29 -0000 Benoit, I do not understand the double quote corrected text - I think it should have been pattern "\\S+" and pattern "\\S(.*\\S)?" but I prefer the single quote version anyway. Hence I suggest to remove the second corrected text (having a single correction is generally better anyway). /js On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: > YANG-doctors, > > Would you mind checking this errata? > Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if > this errata is correct, it's worth documenting IMO. > > Regards, Benoit > > > -------- Forwarded Message -------- > Subject: [Technical Errata Reported] RFC6728 (4909) > Date: Mon, 16 Jan 2017 14:15:11 -0800 > From: RFC Errata System > To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, > bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, > quittek@neclab.eu > CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org > > > > The following errata report has been submitted for RFC6728, > "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 > > -------------------------------------- > Type: Technical > Reported by: Pavol Vican > > Section: 6 > > Original Text > ------------- > pattern "\S+" > ... > pattern "\S(.*\S)?" > > Corrected Text > -------------- > pattern '\S+' > ... > pattern '\S(.*\S)?' > > or > > pattern "\S+" > ... > pattern "\S(.*\S)?" > > Notes > ----- > RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash. > > 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. > > -------------------------------------- > RFC6728 (draft-ietf-ipfix-configuration-model-11) > -------------------------------------- > Title : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols > Publication Date : October 2012 > Author(s) : G. Muenz, B. Claise, P. Aitken > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 16 23:43:26 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43948129513 for ; Mon, 16 Jan 2017 23:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 zzYMjxctWcBR for ; Mon, 16 Jan 2017 23:43:23 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124181294A8 for ; Mon, 16 Jan 2017 23:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3290; q=dns/txt; s=iport; t=1484639003; x=1485848603; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=OVQJt6+7u7hUvovxbO2lY1QG62kEiCRU0ygcamFR2n0=; b=HR/NyhvXfEwcEddnBV3saQGefYEp6DWtIKbMIZ4RIbb4AleJgDV0iXHi Pjb2+D9IA+v+6X41biwLrIHiyhH+TAED34A3dYLB4BVGCL4kGLzuH47uH yLA9ewrxUoE6AU9JjU0LNcy/dnKXXKMSSorZaEh1BNYl67HOrCEj+Ra/Q I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQBnyn1Y/xbLJq1DGg4LAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDOQEBAQEBfgMnX41YcpEFH4gEjSiCCx8LhXgCgk0YAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQQBATABBTYbCxEDAQIBLiEGKAgGAQwGAgEBiGQDGA4tsGiHM?= =?us-ascii?q?A2CTAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICCIJdgTuBFTuBBIV+HwWIehG?= =?us-ascii?q?HXooZOI1bhASBd4UOgyqGPooYWYd7HzgQgQUSCBUVGCKENw0PgSQ8PTUBE4hEA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.33,243,1477958400"; d="scan'208";a="691416994" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 07:43:18 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0H7hIeF003151; Tue, 17 Jan 2017 07:43:18 GMT To: YANG Doctors , Gerhard Muenz , Paul Aitken , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> From: Benoit Claise Message-ID: <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> Date: Tue, 17 Jan 2017 08:43:18 +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: <20170117073625.GB1152@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 07:43:25 -0000 Jürgen, Let me copy Vican, who reported the errata (which I should have done initially) Regards, Benoit > Benoit, > > I do not understand the double quote corrected text - I think it > should have been > > pattern "\\S+" > > and > > pattern "\\S(.*\\S)?" > > but I prefer the single quote version anyway. Hence I suggest to > remove the second corrected text (having a single correction is > generally better anyway). > > /js > > On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: >> YANG-doctors, >> >> Would you mind checking this errata? >> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if >> this errata is correct, it's worth documenting IMO. >> >> Regards, Benoit >> >> >> -------- Forwarded Message -------- >> Subject: [Technical Errata Reported] RFC6728 (4909) >> Date: Mon, 16 Jan 2017 14:15:11 -0800 >> From: RFC Errata System >> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, >> bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, >> quittek@neclab.eu >> CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org >> >> >> >> The following errata report has been submitted for RFC6728, >> "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >> >> -------------------------------------- >> Type: Technical >> Reported by: Pavol Vican >> >> Section: 6 >> >> Original Text >> ------------- >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Corrected Text >> -------------- >> pattern '\S+' >> ... >> pattern '\S(.*\S)?' >> >> or >> >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Notes >> ----- >> RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash. >> >> 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. >> >> -------------------------------------- >> RFC6728 (draft-ietf-ipfix-configuration-model-11) >> -------------------------------------- >> Title : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >> Publication Date : October 2012 >> Author(s) : G. Muenz, B. Claise, P. Aitken >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > From nobody Tue Jan 17 00:35:39 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15C212952C for ; Tue, 17 Jan 2017 00:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 etohjDXh1l0M for ; Tue, 17 Jan 2017 00:35:36 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 2956C129407 for ; Tue, 17 Jan 2017 00:35:36 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id e4so22081021pfg.1 for ; Tue, 17 Jan 2017 00:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Zz1Y2VPr/8SuRTct/31PxvLHg83FiF3QsCCL25Re8mg=; b=m3BZtNwygSKP17ZRWuRhjGU+z/WAlzTtUb1TZbSpkxRg4sYnJ6x4qbHFFLcgq9dZVt k4TPOdIUz5ZvUP656CkPHN1DkLDneLz6tT/lCXj/XVQkOVihHzxhcwnvtcgPvhryIZJt s3nb5llYPe2jV03vq2DV6rRpiuOiqHROdHC5yUMiRVtlTDRSM22ppcdrztfPl3QfzTyi 5guReRLuJ0+onwNjQh1EexTd70sNtuQ3sVrTS70yQbXPLp1k9iqGKmyL8Kr5EjRlC53e a2BfhEEYzhKVEKAM1f0YhPJ2rbZYYiKmQenmITqCr3TUI3I2GkxN07i7yGWZaWY6XLL2 /o8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Zz1Y2VPr/8SuRTct/31PxvLHg83FiF3QsCCL25Re8mg=; b=mUYWS6O217LGw0FULbuRZemEF4aVdihSjycgui7Jr5s20m1pHuBTyCPA8pD5qB77/E AJgSXzlot+mdZPYR6TgNjWAoTdBu2N2hyFTRREyLn5Mjm5jqabYbNmAkzN1bZAT66C3b abZibKziWBTsJItLQCqlM5PLW6o59A8tglerussuqjO62CrGkmJbgM/RBz+/gojSYEkA bUE/unZt38EU1OZo+4SiWE1PkKPoJigdDce3MVhUF6RbhKmgSjBO5v7qFDynJeu76BIA uFse/mxs7TedVkMIdOew+BFhqRAXGMpbkbWiws2vRO3KumQ5L5rp14KZ9zokNhNs4sy8 /+LQ== X-Gm-Message-State: AIkVDXJ/NHJEN+JXo1krvUp5g4bPJRdmaJN2j5banP6imsPEwtqkmZfOle6Ti7C0qphbDQ== X-Received: by 10.99.38.3 with SMTP id m3mr45029224pgm.113.1484642135666; Tue, 17 Jan 2017 00:35:35 -0800 (PST) Received: from [172.27.212.154] (212.44.21.120.ip.redstone-isp.net. [212.44.21.120]) by smtp.gmail.com with ESMTPSA id a25sm53766666pgd.26.2017.01.17.00.35.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 00:35:35 -0800 (PST) To: Benoit Claise , YANG Doctors , Gerhard Muenz , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> From: Paul Aitken Message-ID: Date: Tue, 17 Jan 2017 08:35:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 08:35:38 -0000 I suspect that the "double backslash" version was lost in email. It can be seen in the original errata: https://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 Q: has anyone checked for the same issue in other recent RFCs and drafts? P. On 17/01/17 07:43, Benoit Claise wrote: > Jürgen, > > Let me copy Vican, who reported the errata (which I should have done > initially) > > Regards, Benoit >> Benoit, >> >> I do not understand the double quote corrected text - I think it >> should have been >> >> pattern "\\S+" >> >> and >> >> pattern "\\S(.*\\S)?" >> >> but I prefer the single quote version anyway. Hence I suggest to >> remove the second corrected text (having a single correction is >> generally better anyway). >> >> /js >> >> On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: >>> YANG-doctors, >>> >>> Would you mind checking this errata? >>> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. >>> However, if >>> this errata is correct, it's worth documenting IMO. >>> >>> Regards, Benoit >>> >>> >>> -------- Forwarded Message -------- >>> Subject: [Technical Errata Reported] RFC6728 (4909) >>> Date: Mon, 16 Jan 2017 14:15:11 -0800 >>> From: RFC Errata System >>> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, >>> bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, >>> quittek@neclab.eu >>> CC: vican.pavol@gmail.com, ipfix@ietf.org, >>> rfc-editor@rfc-editor.org >>> >>> >>> >>> The following errata report has been submitted for RFC6728, >>> "Configuration Data Model for the IP Flow Information Export (IPFIX) >>> and Packet Sampling (PSAMP) Protocols". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Pavol Vican >>> >>> Section: 6 >>> >>> Original Text >>> ------------- >>> pattern "\S+" >>> ... >>> pattern "\S(.*\S)?" >>> >>> Corrected Text >>> -------------- >>> pattern '\S+' >>> ... >>> pattern '\S(.*\S)?' >>> >>> or >>> >>> pattern "\S+" >>> ... >>> pattern "\S(.*\S)?" >>> >>> Notes >>> ----- >>> RFC 7950 in section 6.3.1 says that backslash has special meaning if >>> it is in the double-quoted string. The only characters immediately >>> following the backslash are n, t, \, ". Other characters are >>> forbidden. This can be solved using single-quoted string or double >>> backslash. >>> >>> 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. >>> >>> -------------------------------------- >>> RFC6728 (draft-ietf-ipfix-configuration-model-11) >>> -------------------------------------- >>> Title : Configuration Data Model for the IP Flow >>> Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >>> Publication Date : October 2012 >>> Author(s) : G. Muenz, B. Claise, P. Aitken >>> Category : PROPOSED STANDARD >>> Source : IP Flow Information Export >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> . >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >> > From nobody Tue Jan 17 00:40:35 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9188612952C for ; Tue, 17 Jan 2017 00:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no 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 Po8h7lO4qbSW for ; Tue, 17 Jan 2017 00:40:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F59F129407 for ; Tue, 17 Jan 2017 00:40:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3B1606EC; Tue, 17 Jan 2017 09:40:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 54yjilyhzd52; Tue, 17 Jan 2017 09:40:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Jan 2017 09:40:29 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8721B200A5; Tue, 17 Jan 2017 09:40:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VGVMDAndlfFD; Tue, 17 Jan 2017 09:40:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88E9520090; Tue, 17 Jan 2017 09:40:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 390243E2751E; Tue, 17 Jan 2017 09:40:32 +0100 (CET) Date: Tue, 17 Jan 2017 09:40:32 +0100 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20170117084032.GD1152@elstar.local> Mail-Followup-To: Paul Aitken , Benoit Claise , YANG Doctors , Gerhard Muenz , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Juergen Quittek , vican.pavol@gmail.com, Nevil Brownlee , Paul Aitken , Gerhard Muenz , YANG Doctors Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 08:40:33 -0000 This is an explanation - (although this makes me wonder whether I can play dirty tricks with the errata form). Still I prefer a single alternative and this is for me the single quote correction. /js On Tue, Jan 17, 2017 at 08:35:26AM +0000, Paul Aitken wrote: > I suspect that the "double backslash" version was lost in email. It can be > seen in the original errata: > > https://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 > > Q: has anyone checked for the same issue in other recent RFCs and drafts? > > P. > > > On 17/01/17 07:43, Benoit Claise wrote: > > Jürgen, > > > > Let me copy Vican, who reported the errata (which I should have done > > initially) > > > > Regards, Benoit > > > Benoit, > > > > > > I do not understand the double quote corrected text - I think it > > > should have been > > > > > > pattern "\\S+" > > > > > > and > > > > > > pattern "\\S(.*\\S)?" > > > > > > but I prefer the single quote version anyway. Hence I suggest to > > > remove the second corrected text (having a single correction is > > > generally better anyway). > > > > > > /js > > > > > > On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: > > > > YANG-doctors, > > > > > > > > Would you mind checking this errata? > > > > Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. > > > > However, if > > > > this errata is correct, it's worth documenting IMO. > > > > > > > > Regards, Benoit > > > > > > > > > > > > -------- Forwarded Message -------- > > > > Subject: [Technical Errata Reported] RFC6728 (4909) > > > > Date: Mon, 16 Jan 2017 14:15:11 -0800 > > > > From: RFC Errata System > > > > To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, > > > > bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, > > > > quittek@neclab.eu > > > > CC: vican.pavol@gmail.com, ipfix@ietf.org, > > > > rfc-editor@rfc-editor.org > > > > > > > > > > > > > > > > The following errata report has been submitted for RFC6728, > > > > "Configuration Data Model for the IP Flow Information Export > > > > (IPFIX) and Packet Sampling (PSAMP) Protocols". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Pavol Vican > > > > > > > > Section: 6 > > > > > > > > Original Text > > > > ------------- > > > > pattern "\S+" > > > > ... > > > > pattern "\S(.*\S)?" > > > > > > > > Corrected Text > > > > -------------- > > > > pattern '\S+' > > > > ... > > > > pattern '\S(.*\S)?' > > > > > > > > or > > > > > > > > pattern "\S+" > > > > ... > > > > pattern "\S(.*\S)?" > > > > > > > > Notes > > > > ----- > > > > RFC 7950 in section 6.3.1 says that backslash has special > > > > meaning if it is in the double-quoted string. The only > > > > characters immediately following the backslash are n, t, \, ". > > > > Other characters are forbidden. This can be solved using > > > > single-quoted string or double backslash. > > > > > > > > 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. > > > > > > > > -------------------------------------- > > > > RFC6728 (draft-ietf-ipfix-configuration-model-11) > > > > -------------------------------------- > > > > Title : Configuration Data Model for the IP Flow > > > > Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols > > > > Publication Date : October 2012 > > > > Author(s) : G. Muenz, B. Claise, P. Aitken > > > > Category : PROPOSED STANDARD > > > > Source : IP Flow Information Export > > > > Area : Operations and Management > > > > Stream : IETF > > > > Verifying Party : IESG > > > > . > > > > > > > > _______________________________________________ > > > > yang-doctors mailing list > > > > yang-doctors@ietf.org > > > > https://www.ietf.org/mailman/listinfo/yang-doctors > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 17 00:45:35 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC942129412 for ; Tue, 17 Jan 2017 00:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kh2j8N70MnDb for ; Tue, 17 Jan 2017 00:45:32 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 D0F5A129407 for ; Tue, 17 Jan 2017 00:45:32 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0H8iSH3001085; Tue, 17 Jan 2017 00:45:25 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 281ehxr5q6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Jan 2017 00:45:25 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 01:45:22 -0700 Received: from [172.27.212.154] (172.27.212.154) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 09:45:18 +0100 To: Paul Aitken , Benoit Claise , "YANG Doctors" , Gerhard Muenz , "Nevil Brownlee" , Juergen Quittek , References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> <20170117084032.GD1152@elstar.local> From: PJ Aitken Message-ID: <50884552-1b59-30c6-3e05-a82aae39bb17@brocade.com> Date: Tue, 17 Jan 2017 08:45:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170117084032.GD1152@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.212.154] X-ClientProxiedBy: hq1wp-excas11.corp.brocade.com (10.70.36.102) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-17_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701170107 Archived-At: Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 08:45:34 -0000 Juergen, > This is an explanation - (although this makes me wonder whether I can > play dirty tricks with the errata form). > > Still I prefer a single alternative and this is for me the single > quote correction. +1 The loss of the double-backslashed version in this email thread argues against its inclusion in the RFC. P. From nobody Tue Jan 17 01:16:54 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354BE12945F for ; Tue, 17 Jan 2017 01:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 2xSwmI_YdM4e for ; Tue, 17 Jan 2017 01:16:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FA9129407 for ; Tue, 17 Jan 2017 01:16:49 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 4E0F3615FD; Tue, 17 Jan 2017 10:16:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484644608; bh=nR3bt7t8lNFgEEeMdiFJNSbNsrjbnwlR4ZXQclVC/zo=; h=From:Date:To; b=OXnulvthLyNR7N9hqJs05+W5TQSOXN1lTreDgMxsIovqupUVMGmnZ/zA5C+HsZep9 CTBobmP2s5HSO4qDhtzJgHTbWoEWfusmziyZuHmF3tXWANiWRmYRc2JebKHCl5hs4q TUr8/HSHxoxG1OFG2dw61JMFhL/WWW1grdNZrU9U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> Date: Tue, 17 Jan 2017 10:16:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 09:16:52 -0000 > On 17 Jan 2017, at 08:29, Benoit Claise wrote: >=20 > YANG-doctors, >=20 > Would you mind checking this errata? > Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. = However, if this errata is correct, it's worth documenting IMO. I just learnt independently that the same problem is quite common also = in proprietary modules: https://github.com/llhotka/yang-parser-coffee/pull/1 So it may be worthwhile to "backport" the clarification of this issue = from YANG 1.1 as an erratum to RFC 6020 because its text is clearly = ambiguous. Lada >=20 > Regards, Benoit >=20 >=20 > -------- Forwarded Message -------- > Subject: [Technical Errata Reported] RFC6728 (4909) > Date: Mon, 16 Jan 2017 14:15:11 -0800 > From: RFC Errata System > To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, = bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, = quittek@neclab.eu > CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org >=20 > The following errata report has been submitted for RFC6728, > "Configuration Data Model for the IP Flow Information Export (IPFIX) = and Packet Sampling (PSAMP) Protocols". >=20 > -------------------------------------- > You may review the report below and at: >=20 > http://www.rfc-editor.org/errata_search.php?rfc=3D6728&eid=3D4909 >=20 >=20 > -------------------------------------- > Type: Technical > Reported by: Pavol Vican=20 > >=20 >=20 > Section: 6 >=20 > Original Text > ------------- > pattern "\S+" > ... > pattern "\S(.*\S)?" >=20 > Corrected Text > -------------- > pattern '\S+' > ... > pattern '\S(.*\S)?' >=20 > or=20 >=20 > pattern "\S+" > ... > pattern "\S(.*\S)?" >=20 > Notes > ----- > RFC 7950 in section 6.3.1 says that backslash has special meaning if = it is in the double-quoted string. The only characters immediately = following the backslash are n, t, \, ". Other characters are forbidden. = This can be solved using single-quoted string or double backslash. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6728 (draft-ietf-ipfix-configuration-model-11) > -------------------------------------- > Title : Configuration Data Model for the IP Flow = Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols > Publication Date : October 2012 > Author(s) : G. Muenz, B. Claise, P. Aitken > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 17 07:42:35 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56711294D0 for ; Tue, 17 Jan 2017 07:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 1r0lajKDNKAR for ; Tue, 17 Jan 2017 07:42:32 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51414129405 for ; Tue, 17 Jan 2017 07:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4653; q=dns/txt; s=iport; t=1484667752; x=1485877352; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WvHT65bYUu3JgtfW42qt/1pPzqsEbMwRI7HiUWXaTFg=; b=EbVW9F9D5Crkj5wa+COcqB6wnvzawWqRVoTYjw4WSK9y1PiV+l2A4g/K l7/ICZGE1MMvK0CT2M7AABhtNiXxiMAPVQuuPOVG1mhbQgBhdrXHtE323 mwG+AIWv+eK1tB5Xl+AGLoTXbqCn1X8uBrF0dmCZjfB1cG2zosxXyXPTo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQBuOn5Y/xbLJq1DGg4LAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDOQEBAQEBfgMnX41YcpEmiASNKIILHwuFeAKCURgBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQEBBAEBMAEFNhsLDgMDAQIBLiEGKAgGAQwGAgEBiGQDGA4tsSGHO?= =?us-ascii?q?g2CPgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICgmWBO4EVO4EECxEBhWEfBYh?= =?us-ascii?q?6EYdeihk4jVuEBIF3hQ6DKoY+ihhZh3sfOBBhJBIIFRUYIoQ3DQ+BJDw9NQETh?= =?us-ascii?q?haCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208";a="649891476" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:42:27 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFgRa6013944; Tue, 17 Jan 2017 15:42:27 GMT To: Paul Aitken , YANG Doctors , Gerhard Muenz , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> <20170117084032.GD1152@elstar.local> From: Benoit Claise Message-ID: Date: Tue, 17 Jan 2017 16:42:27 +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: <20170117084032.GD1152@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:42:35 -0000 Hi Jürgen, > This is an explanation - (although this makes me wonder whether I can > play dirty tricks with the errata form). > > Still I prefer a single alternative and this is for me the single > quote correction. You prefer it, I understand, but since this is an errata, the question is: are the two proposals legal according to RFC 7950? I yes, then both should be in the errata. Regards, Benoit > > /js > > On Tue, Jan 17, 2017 at 08:35:26AM +0000, Paul Aitken wrote: >> I suspect that the "double backslash" version was lost in email. It can be >> seen in the original errata: >> >> https://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >> >> Q: has anyone checked for the same issue in other recent RFCs and drafts? >> >> P. >> >> >> On 17/01/17 07:43, Benoit Claise wrote: >>> Jürgen, >>> >>> Let me copy Vican, who reported the errata (which I should have done >>> initially) >>> >>> Regards, Benoit >>>> Benoit, >>>> >>>> I do not understand the double quote corrected text - I think it >>>> should have been >>>> >>>> pattern "\\S+" >>>> >>>> and >>>> >>>> pattern "\\S(.*\\S)?" >>>> >>>> but I prefer the single quote version anyway. Hence I suggest to >>>> remove the second corrected text (having a single correction is >>>> generally better anyway). >>>> >>>> /js >>>> >>>> On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: >>>>> YANG-doctors, >>>>> >>>>> Would you mind checking this errata? >>>>> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. >>>>> However, if >>>>> this errata is correct, it's worth documenting IMO. >>>>> >>>>> Regards, Benoit >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: [Technical Errata Reported] RFC6728 (4909) >>>>> Date: Mon, 16 Jan 2017 14:15:11 -0800 >>>>> From: RFC Errata System >>>>> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, >>>>> bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, >>>>> quittek@neclab.eu >>>>> CC: vican.pavol@gmail.com, ipfix@ietf.org, >>>>> rfc-editor@rfc-editor.org >>>>> >>>>> >>>>> >>>>> The following errata report has been submitted for RFC6728, >>>>> "Configuration Data Model for the IP Flow Information Export >>>>> (IPFIX) and Packet Sampling (PSAMP) Protocols". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Pavol Vican >>>>> >>>>> Section: 6 >>>>> >>>>> Original Text >>>>> ------------- >>>>> pattern "\S+" >>>>> ... >>>>> pattern "\S(.*\S)?" >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> pattern '\S+' >>>>> ... >>>>> pattern '\S(.*\S)?' >>>>> >>>>> or >>>>> >>>>> pattern "\S+" >>>>> ... >>>>> pattern "\S(.*\S)?" >>>>> >>>>> Notes >>>>> ----- >>>>> RFC 7950 in section 6.3.1 says that backslash has special >>>>> meaning if it is in the double-quoted string. The only >>>>> characters immediately following the backslash are n, t, \, ". >>>>> Other characters are forbidden. This can be solved using >>>>> single-quoted string or double backslash. >>>>> >>>>> 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. >>>>> >>>>> -------------------------------------- >>>>> RFC6728 (draft-ietf-ipfix-configuration-model-11) >>>>> -------------------------------------- >>>>> Title : Configuration Data Model for the IP Flow >>>>> Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >>>>> Publication Date : October 2012 >>>>> Author(s) : G. Muenz, B. Claise, P. Aitken >>>>> Category : PROPOSED STANDARD >>>>> Source : IP Flow Information Export >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> . >>>>> >>>>> _______________________________________________ >>>>> yang-doctors mailing list >>>>> yang-doctors@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/yang-doctors >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Tue Jan 17 07:43:49 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603C01294EE for ; Tue, 17 Jan 2017 07:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 KRGByNdmg8ye for ; Tue, 17 Jan 2017 07:43:44 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF831294D4 for ; Tue, 17 Jan 2017 07:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3349; q=dns/txt; s=iport; t=1484667823; x=1485877423; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=IqaEDgDHMzj9gkAnZuCcr1ylGtDWVfvqFvrUJBDc4YE=; b=Tiyn5OyyOmRKPR4hcjdI33aJx55TC+GoSndAOmIRH1+IbkSwiEvu8e2l qrQzHt0hS+be9g8hnPBG1W5NFKIEt7t+jJRYYo/OFQ3uCPl7c3sd6DtAs RWcQk2hzub1DJzQ429c70xOHwNQNSvuXz8kU+9eMAUN9UqIxnft888jwf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQBmO35Y/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQF+AydfjVhykSaIBI0oggsfC4V4AoJRGAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEEAQE2NgsQCxEDAQIBLiEGKAgGDQYCAQGIZAMYDi2xJ4c5DYI+A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYZFggKCZYE7gRU7gQSFfh8FiHoRh16KGTi?= =?us-ascii?q?GXYZ+hASBd4UOgyqGPooYWYd7HzgQgQUSCBUVGCKENw0PgWA9NQETiEQBAQE?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208";a="691432719" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:43:35 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFhZC9017767; Tue, 17 Jan 2017 15:43:35 GMT To: Ladislav Lhotka References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> From: Benoit Claise Message-ID: Date: Tue, 17 Jan 2017 16:43:34 +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: <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:43:47 -0000 On 1/17/2017 10:16 AM, Ladislav Lhotka wrote: >> On 17 Jan 2017, at 08:29, Benoit Claise wrote: >> >> YANG-doctors, >> >> Would you mind checking this errata? >> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if this errata is correct, it's worth documenting IMO. > I just learnt independently that the same problem is quite common also in proprietary modules: > > https://github.com/llhotka/yang-parser-coffee/pull/1 > > So it may be worthwhile to "backport" the clarification of this issue from YANG 1.1 as an erratum to RFC 6020 because its text is clearly ambiguous. More people supporting this view? Regards, Benoit > > Lada > >> Regards, Benoit >> >> >> -------- Forwarded Message -------- >> Subject: [Technical Errata Reported] RFC6728 (4909) >> Date: Mon, 16 Jan 2017 14:15:11 -0800 >> From: RFC Errata System >> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu >> CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org >> >> The following errata report has been submitted for RFC6728, >> "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". >> >> -------------------------------------- >> You may review the report below and at: >> >> http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >> >> >> -------------------------------------- >> Type: Technical >> Reported by: Pavol Vican >> >> >> >> Section: 6 >> >> Original Text >> ------------- >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Corrected Text >> -------------- >> pattern '\S+' >> ... >> pattern '\S(.*\S)?' >> >> or >> >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Notes >> ----- >> RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash. >> >> 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. >> >> -------------------------------------- >> RFC6728 (draft-ietf-ipfix-configuration-model-11) >> -------------------------------------- >> Title : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >> Publication Date : October 2012 >> Author(s) : G. Muenz, B. Claise, P. Aitken >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Tue Jan 17 07:58:19 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5801912954C for ; Tue, 17 Jan 2017 07:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 RniiHGdk0kkA for ; Tue, 17 Jan 2017 07:58:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC9F129554 for ; Tue, 17 Jan 2017 07:58:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d47e:3133:ee59:587] (unknown [IPv6:2001:718:1a02:1:d47e:3133:ee59:587]) by mail.nic.cz (Postfix) with ESMTPSA id AB6D060ABD; Tue, 17 Jan 2017 16:58:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484668692; bh=N9sXQ0/MF01W0ZUxKEBN0Lo4zx+0qQ1BRzh8jqjI/lQ=; h=From:Date:To; b=I5EGa3/vdqnaN8iQW4w4cF3QClP/eVuUXypaH+FdN7ODpXrxZToxBx5go4o6zkCaT S2kBTS6SiQcyeST20ANKm2wRPaBfABZ7pkER2eF5y6FxK4hJCO58MYvjAdE8Z6PIFL LpTmT5LMZCDw8myX1s2XbCBXXS2ulNpVp2s9i49w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 17 Jan 2017 16:58:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0933D045-BDC3-484A-829C-3AE65F737B6F@nic.cz> References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> <20170117084032.GD1152@elstar.local> To: Benoit Claise X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Paul Aitken , Juergen Quittek , vican.pavol@gmail.com, Nevil Brownlee , Paul Aitken , Gerhard Muenz , Benoit Claise Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:58:16 -0000 > On 17 Jan 2017, at 16:42, Benoit Claise wrote: >=20 > Hi J=C3=BCrgen, >> This is an explanation - (although this makes me wonder whether I can >> play dirty tricks with the errata form). >>=20 >> Still I prefer a single alternative and this is for me the single >> quote correction. > You prefer it, I understand, but since this is an errata, the question = is: are the two proposals legal according to RFC 7950? > I yes, then both should be in the errata. Yes, both are legal but I think the erratum is supposed to provide a new = text (one version) that is correct, right? And I agree with Juergen that = single quotes are definitely better. Funny enough, the unquoted version = is also legal, but better don't tell it to anybody. :-) pattern \S(.*\S)?; Lada >=20 > Regards, Benoit >>=20 >> /js >>=20 >> On Tue, Jan 17, 2017 at 08:35:26AM +0000, Paul Aitken wrote: >>> I suspect that the "double backslash" version was lost in email. It = can be >>> seen in the original errata: >>>=20 >>> https://www.rfc-editor.org/errata_search.php?rfc=3D6728&eid=3D4909 >>>=20 >>> Q: has anyone checked for the same issue in other recent RFCs and = drafts? >>>=20 >>> P. >>>=20 >>>=20 >>> On 17/01/17 07:43, Benoit Claise wrote: >>>> J=C3=BCrgen, >>>>=20 >>>> Let me copy Vican, who reported the errata (which I should have = done >>>> initially) >>>>=20 >>>> Regards, Benoit >>>>> Benoit, >>>>>=20 >>>>> I do not understand the double quote corrected text - I think it >>>>> should have been >>>>>=20 >>>>> pattern "\\S+" >>>>>=20 >>>>> and >>>>>=20 >>>>> pattern "\\S(.*\\S)?" >>>>>=20 >>>>> but I prefer the single quote version anyway. Hence I suggest to >>>>> remove the second corrected text (having a single correction is >>>>> generally better anyway). >>>>>=20 >>>>> /js >>>>>=20 >>>>> On Tue, Jan 17, 2017 at 08:29:23AM +0100, Benoit Claise wrote: >>>>>> YANG-doctors, >>>>>>=20 >>>>>> Would you mind checking this errata? >>>>>> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. >>>>>> However, if >>>>>> this errata is correct, it's worth documenting IMO. >>>>>>=20 >>>>>> Regards, Benoit >>>>>>=20 >>>>>>=20 >>>>>> -------- Forwarded Message -------- >>>>>> Subject: [Technical Errata Reported] RFC6728 (4909) >>>>>> Date: Mon, 16 Jan 2017 14:15:11 -0800 >>>>>> From: RFC Errata System >>>>>> To: muenz@net.in.tum.de, bclaise@cisco.com, = paitken@cisco.com, >>>>>> bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, >>>>>> quittek@neclab.eu >>>>>> CC: vican.pavol@gmail.com, ipfix@ietf.org, >>>>>> rfc-editor@rfc-editor.org >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The following errata report has been submitted for RFC6728, >>>>>> "Configuration Data Model for the IP Flow Information Export >>>>>> (IPFIX) and Packet Sampling (PSAMP) Protocols". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6728&eid=3D4909 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Pavol Vican >>>>>>=20 >>>>>> Section: 6 >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> pattern "\S+" >>>>>> ... >>>>>> pattern "\S(.*\S)?" >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> pattern '\S+' >>>>>> ... >>>>>> pattern '\S(.*\S)?' >>>>>>=20 >>>>>> or >>>>>>=20 >>>>>> pattern "\S+" >>>>>> ... >>>>>> pattern "\S(.*\S)?" >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> RFC 7950 in section 6.3.1 says that backslash has special >>>>>> meaning if it is in the double-quoted string. The only >>>>>> characters immediately following the backslash are n, t, \, ". >>>>>> Other characters are forbidden. This can be solved using >>>>>> single-quoted string or double backslash. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC6728 (draft-ietf-ipfix-configuration-model-11) >>>>>> -------------------------------------- >>>>>> Title : Configuration Data Model for the IP Flow >>>>>> Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >>>>>> Publication Date : October 2012 >>>>>> Author(s) : G. Muenz, B. Claise, P. Aitken >>>>>> Category : PROPOSED STANDARD >>>>>> Source : IP Flow Information Export >>>>>> Area : Operations and Management >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>> . >>>>>>=20 >>>>>> _______________________________________________ >>>>>> yang-doctors mailing list >>>>>> yang-doctors@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 17 08:05:34 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99C12955B for ; Tue, 17 Jan 2017 08:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 ifg_EPBotRKz for ; Tue, 17 Jan 2017 08:05:28 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEBA12954C for ; Tue, 17 Jan 2017 08:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3950; q=dns/txt; s=iport; t=1484669127; x=1485878727; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=SOqdBldaJxEGYmh3Lb7jljP4D0BeTQraLuDXBE2GdCQ=; b=GGTntf4NkFjWG5hAujscLY30POAvii/uwH9wnRArIp74pj14leWzYfM8 kyHY4mx6hzHXmN3v3+JuN2Xrg5Xcg3nD9KATYZb/YzSxlkIACNnoHvm4Z aj2MBy7gK9W0xD/a4KIY34IPohmYBnN7owuc/oocQRgORcEh4je0DrsZm E=; X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208";a="691433373" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 16:05:26 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0HG5P9L020721; Tue, 17 Jan 2017 16:05:25 GMT To: Ladislav Lhotka References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> From: Benoit Claise Message-ID: Date: Tue, 17 Jan 2017 17:05: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: <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Einar Nilsen-Nygaard \(einarnn\)" , Benoit Claise Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:05:33 -0000 On 1/17/2017 10:16 AM, Ladislav Lhotka wrote: >> On 17 Jan 2017, at 08:29, Benoit Claise wrote: >> >> YANG-doctors, >> >> Would you mind checking this errata? >> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. However, if this errata is correct, it's worth documenting IMO. > I just learnt independently that the same problem is quite common also in proprietary modules: > > https://github.com/llhotka/yang-parser-coffee/pull/1 > > So it may be worthwhile to "backport" the clarification of this issue from YANG 1.1 as an erratum to RFC 6020 because its text is clearly ambiguous. btw, bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ pyang --ietf ietf-ipfix-psamp@2012-09-05.yang bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ pyang --ietf ietf-ipfix-psamp@2012-09-05-v11.yang ietf-ipfix-psamp@2012-09-05-v11.yang:260: error: the escape sequence "\S" is illegal in double quoted strings bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ diff ietf-ipfix-psamp@2012-09-05.yang ietf-ipfix-psamp@2012-09-05-v11.yang 2a3 > yang-version "1.1"; Is there a way to force a YANG 1.0 module to be compiled with YANG 1.1 rules? I would like to verify if Cisco proprietary YANG 1.0 modules face this issue. Regards, Benoit > > Lada > >> Regards, Benoit >> >> >> -------- Forwarded Message -------- >> Subject: [Technical Errata Reported] RFC6728 (4909) >> Date: Mon, 16 Jan 2017 14:15:11 -0800 >> From: RFC Errata System >> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu >> CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org >> >> The following errata report has been submitted for RFC6728, >> "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". >> >> -------------------------------------- >> You may review the report below and at: >> >> http://www.rfc-editor.org/errata_search.php?rfc=6728&eid=4909 >> >> >> -------------------------------------- >> Type: Technical >> Reported by: Pavol Vican >> >> >> >> Section: 6 >> >> Original Text >> ------------- >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Corrected Text >> -------------- >> pattern '\S+' >> ... >> pattern '\S(.*\S)?' >> >> or >> >> pattern "\S+" >> ... >> pattern "\S(.*\S)?" >> >> Notes >> ----- >> RFC 7950 in section 6.3.1 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash. >> >> 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. >> >> -------------------------------------- >> RFC6728 (draft-ietf-ipfix-configuration-model-11) >> -------------------------------------- >> Title : Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >> Publication Date : October 2012 >> Author(s) : G. Muenz, B. Claise, P. Aitken >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Tue Jan 17 08:11:53 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471A512955B for ; Tue, 17 Jan 2017 08:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 TtWsXANciXR5 for ; Tue, 17 Jan 2017 08:11:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A23129548 for ; Tue, 17 Jan 2017 08:11:49 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d47e:3133:ee59:587] (unknown [IPv6:2001:718:1a02:1:d47e:3133:ee59:587]) by mail.nic.cz (Postfix) with ESMTPSA id C281660ABD; Tue, 17 Jan 2017 17:11:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484669507; bh=JrBkl6Fx4iJ77oaUiSbpPlbdNAohBG2Nmj4JFAYlDrE=; h=From:Date:To; b=DWCi3lmduVyiaoULlj6EA1ANFgfMXHjvChzoGEC3FIQ0c8gi4KRqJw9UWvVb7oWzn qp1vSCotmt1hv+SON6hIUt05BfCTTp4Fy99AXplAkfjCdaY9kBxkgtrqDtUyyy6Vf2 n9l+yaWiP5c37wJD+fN4tYFIfhym2EVzZqrcGvDA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 17 Jan 2017 17:11:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F84001D-BA90-4A99-8131-ACD8EB3CC921@nic.cz> References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <6C2D7BD7-D469-41C4-BFBE-FFCFA6F4C7C4@nic.cz> To: Benoit Claise X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "Einar Nilsen-Nygaard \(einarnn\)" , Benoit Claise Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:11:51 -0000 > On 17 Jan 2017, at 17:05, Benoit Claise wrote: >=20 > On 1/17/2017 10:16 AM, Ladislav Lhotka wrote: >>> On 17 Jan 2017, at 08:29, Benoit Claise wrote: >>>=20 >>> YANG-doctors, >>>=20 >>> Would you mind checking this errata? >>> Note: I know that RFC6728 was based on YANG1.0 and not YANG1.1. = However, if this errata is correct, it's worth documenting IMO. >> I just learnt independently that the same problem is quite common = also in proprietary modules: >>=20 >> https://github.com/llhotka/yang-parser-coffee/pull/1 >>=20 >> So it may be worthwhile to "backport" the clarification of this issue = from YANG 1.1 as an erratum to RFC 6020 because its text is clearly = ambiguous. > btw, > bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ pyang --ietf = ietf-ipfix-psamp@2012-09-05.yang > bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ pyang --ietf = ietf-ipfix-psamp@2012-09-05-v11.yang > ietf-ipfix-psamp@2012-09-05-v11.yang:260: error: the escape sequence = "\S" is illegal in double quoted strings > bclaise@bclaise-VirtualBox:~/ietf/YANG-rfc$ diff = ietf-ipfix-psamp@2012-09-05.yang ietf-ipfix-psamp@2012-09-05-v11.yang > 2a3 > > yang-version "1.1"; >=20 > Is there a way to force a YANG 1.0 module to be compiled with YANG 1.1 = rules? > I would like to verify if Cisco proprietary YANG 1.0 modules face this = issue. The guy who sent me the pull request that I mentioned (Peter Lee) said = he had found this issue in some proprietary Cisco modules, too. I will ask him for details. Lada >=20 > Regards, Benoit >=20 >=20 >=20 >=20 >=20 >>=20 >> Lada >>=20 >>> Regards, Benoit >>>=20 >>>=20 >>> -------- Forwarded Message -------- >>> Subject: [Technical Errata Reported] RFC6728 (4909) >>> Date: Mon, 16 Jan 2017 14:15:11 -0800 >>> From: RFC Errata System >>> To: muenz@net.in.tum.de, bclaise@cisco.com, paitken@cisco.com, = bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, = quittek@neclab.eu >>> CC: vican.pavol@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org >>>=20 >>> The following errata report has been submitted for RFC6728, >>> "Configuration Data Model for the IP Flow Information Export (IPFIX) = and Packet Sampling (PSAMP) Protocols". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>>=20 >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6728&eid=3D4909 >>>=20 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Pavol Vican >>> >>>=20 >>>=20 >>> Section: 6 >>>=20 >>> Original Text >>> ------------- >>> pattern "\S+" >>> ... >>> pattern "\S(.*\S)?" >>>=20 >>> Corrected Text >>> -------------- >>> pattern '\S+' >>> ... >>> pattern '\S(.*\S)?' >>>=20 >>> or >>>=20 >>> pattern "\S+" >>> ... >>> pattern "\S(.*\S)?" >>>=20 >>> Notes >>> ----- >>> RFC 7950 in section 6.3.1 says that backslash has special meaning if = it is in the double-quoted string. The only characters immediately = following the backslash are n, t, \, ". Other characters are forbidden. = This can be solved using single-quoted string or double backslash. >>>=20 >>> 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. >>>=20 >>> -------------------------------------- >>> RFC6728 (draft-ietf-ipfix-configuration-model-11) >>> -------------------------------------- >>> Title : Configuration Data Model for the IP Flow = Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols >>> Publication Date : October 2012 >>> Author(s) : G. Muenz, B. Claise, P. Aitken >>> Category : PROPOSED STANDARD >>> Source : IP Flow Information Export >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> . >>>=20 >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 17 09:38:25 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D71129564 for ; Tue, 17 Jan 2017 09:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no 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 8IWuuYw564_v for ; Tue, 17 Jan 2017 09:38:22 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9D8128874 for ; Tue, 17 Jan 2017 09:38:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 70B706BF; Tue, 17 Jan 2017 18:38:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 28lEwh6foHBv; Tue, 17 Jan 2017 18:38:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Jan 2017 18:38:20 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A299200A3; Tue, 17 Jan 2017 18:38:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TUXe8PVw4qB4; Tue, 17 Jan 2017 18:38:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8D7D20090; Tue, 17 Jan 2017 18:38:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AB5063E281B4; Tue, 17 Jan 2017 18:38:21 +0100 (CET) Date: Tue, 17 Jan 2017 18:38:20 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20170117173820.GA3550@elstar.local> Mail-Followup-To: Benoit Claise , Paul Aitken , YANG Doctors , Gerhard Muenz , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> <20170117084032.GD1152@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Paul Aitken , Juergen Quittek , vican.pavol@gmail.com, Nevil Brownlee , Paul Aitken , Gerhard Muenz , YANG Doctors Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:38:24 -0000 On Tue, Jan 17, 2017 at 04:42:27PM +0100, Benoit Claise wrote: > Hi Jürgen, > > This is an explanation - (although this makes me wonder whether I can > > play dirty tricks with the errata form). > > > > Still I prefer a single alternative and this is for me the single > > quote correction. > You prefer it, I understand, but since this is an errata, the question is: > are the two proposals legal according to RFC 7950? > I yes, then both should be in the errata. > If people manually apply errata to their copies of YANG modules extracted from RFCs (like I do), would it no be nice if they end up also syntactically with the same result? But if you feel strongly that it is a feature to show multiple ways to fix the issue, go ahead (and I know which edit I apply to my copy). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 17 12:01:36 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E571294A1 for ; Tue, 17 Jan 2017 12:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vpRpbqz71jf6 for ; Tue, 17 Jan 2017 12:01:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D350129485 for ; Tue, 17 Jan 2017 12:01:25 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id BA4561AE02EF; Tue, 17 Jan 2017 21:01:22 +0100 (CET) Date: Tue, 17 Jan 2017 21:01:22 +0100 (CET) Message-Id: <20170117.210122.232981884250359823.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170117073625.GB1152@elstar.local> References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: pjaitken@gmail.com, Quittek@neclab.eu, paitken@Brocade.com, n.brownlee@auckland.ac.nz, muenz@net.in.tum.de, yang-doctors@ietf.org Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:01:34 -0000 Juergen Schoenwaelder wrote: > Benoit, > > I do not understand the double quote corrected text - I think it > should have been > > pattern "\\S+" > > and > > pattern "\\S(.*\\S)?" > > but I prefer the single quote version anyway. Hence I suggest to > remove the second corrected text (having a single correction is > generally better anyway). Yes, I agree. Actually the errata as specified is not quite clear. I would rephrase the errata like this: Section 6 says: pattern "\S+"; it should say: pattern '\S+'; and Section 6 also says: pattern "\S(.*\S)?"; it should say: pattern '\S(.*\S)?'; This way the errata can be applied without any knowledge of YANG just by doing text substitution. /martin From nobody Tue Jan 17 23:47:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9D129585 for ; Tue, 17 Jan 2017 23:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 TeFafmpZA1_4 for ; Tue, 17 Jan 2017 23:47:19 -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 DF3E3129428 for ; Tue, 17 Jan 2017 23:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=952; q=dns/txt; s=iport; t=1484725639; x=1485935239; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=K/CuYRE9rFeMQum3MAJscHwdi8gubK9ETeQVcn9BiZU=; b=cdsaaJeV30iqBRNHuY8/wQ2bwpPFVi1qt6x/gNbKRrtTUYMBgPjq9HFr RsyW9mbX6Bf/wQyDTehJFVPwIN1ld39slJsPxa/bEH4ayQeDNzxh54tU5 GG5zkyKDM4ZG5dF1+o29hJ1VkN/QUGdvTyKT7NIR7vDd3xstcnp77/LrI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgBDHX9Y/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQGBAY9RkSaVLIILhiICgiYWAQIBAQEBAQEBYyiEagE?= =?us-ascii?q?FMgEFUQsOCi5XBgEMCAEBiH+xXooqAQEBAQEBAQMBAQEBAQEBIYZFggKCZYE7i?= =?us-ascii?q?FIfAQSVMYYMkWGKL4Y+inOHeyYMJYEVEggVFYR+gTQ8PYkvAQEB?= X-IronPort-AV: E=Sophos;i="5.33,248,1477958400"; d="scan'208";a="651735689" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 07:47:13 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0I7lCmn003768; Wed, 18 Jan 2017 07:47:12 GMT To: Paul Aitken , YANG Doctors , Gerhard Muenz , Paul Aitken , Nevil Brownlee , Juergen Quittek , vican.pavol@gmail.com References: <20170116221511.9D5C4B81A09@rfc-editor.org> <8bbfaa23-25f7-7cbb-a6db-fb0fcd86a072@cisco.com> <20170117073625.GB1152@elstar.local> <4330e5ac-0588-056c-2f14-d3eff201d83c@cisco.com> <20170117084032.GD1152@elstar.local> <20170117173820.GA3550@elstar.local> From: Benoit Claise Message-ID: <98ce4076-a167-2b4c-ef61-a145249e52fe@cisco.com> Date: Wed, 18 Jan 2017 08:47:12 +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: <20170117173820.GA3550@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [yang-doctors] Fwd: [Technical Errata Reported] RFC6728 (4909) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:47:20 -0000 On 1/17/2017 6:38 PM, Juergen Schoenwaelder wrote: > On Tue, Jan 17, 2017 at 04:42:27PM +0100, Benoit Claise wrote: >> Hi Jürgen, >>> This is an explanation - (although this makes me wonder whether I can >>> play dirty tricks with the errata form). >>> >>> Still I prefer a single alternative and this is for me the single >>> quote correction. >> You prefer it, I understand, but since this is an errata, the question is: >> are the two proposals legal according to RFC 7950? >> I yes, then both should be in the errata. >> > If people manually apply errata to their copies of YANG modules > extracted from RFCs (like I do), would it no be nice if they end up > also syntactically with the same result? Ok, convinced now. The errata has been accepted. Regards, Benoit > > But if you feel strongly that it is a feature to show multiple ways to > fix the issue, go ahead (and I know which edit I apply to my copy). > > /js > From nobody Tue Jan 31 08:30:46 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117F9129C59; Mon, 30 Jan 2017 15:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 dKsO_hkmfSRk; Mon, 30 Jan 2017 15:27:05 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0095.outbound.protection.outlook.com [104.47.41.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F723129C58; Mon, 30 Jan 2017 15:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IINXNLf/nLFMKtNie9iEdASm35X465ltozB3+cKI/7s=; b=U8cIuq6Kfbktr8G5Uwj7ehnIqinD6Co/6of3+Nri7WZKxfhL4HUfvnfpvHeztC5Ck0NXaa7YJoo25XbtcG6JrOoWrHkl27/qe0cp/VhHNe/gcCqj//QRsuUUQcLCVSeT26CSdp/ZqAmDLdL9a1MZthcrgt3eCPvnifQLZiZw7zs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 30 Jan 2017 23:27:03 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 23:27:03 +0000 From: Kent Watsen To: Xufeng Liu , Alia Atlas , Alexander Clemm , Vishnu Pavan Beeram Thread-Topic: proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF003mrxpQG/YkWQXb+DOWQ2Z6FMYt4AgARMTQCAAHMegIAAYhGAgAATOYD//8SZAA== Date: Mon, 30 Jan 2017 23:27:03 +0000 Message-ID: <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR05MB2498; 7:zRko91ndq0oqvX5sFrGuilGs4v9Vt6yyt9YhTPOAhupyKfXdDHiaAvjDB8CJ7PlWkOsXiNKpnM97YbcVVJODKMmVyretCQNAd1dXJ/5JofYbssQvEPfjkKSgcIF3LRLbv/LKnT+0qp3GrFpRVZzmNwUFC2mXksAetzeYZdpNx2EkA57YeL2QZdwtrm32ilxxHNXEssX+bKF26T8T2tMlSoz6ZHj3n63Jrnf98BqzkoSL/LT73WtLrYdHusQnMb8J8Kg/z9INbiDNJj5iGRcm1SQcUyyrw0742S2BmTJgOuARnhjieCSDITS23/sM+7tBxhsiU4hA0+q89eYwqO81OJEl8teK6NG7I3PIHEVt6AgTbhjpeP1u2OKQ2hMt6Y4gRe+NuxA/Ui4yWvLskn61fLZurNoVZL3yfu3yEpy4iMesZ8WWK/iIKXjR/hJqHKChMqOICyezZKRhYJhPym/L5w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39840400002)(39410400002)(39860400002)(199003)(189002)(51444003)(6636002)(4326007)(93886004)(2950100002)(106116001)(33656002)(106356001)(8936002)(53936002)(6862003)(36756003)(2906002)(83716003)(229853002)(66066001)(68736007)(189998001)(3846002)(230783001)(3280700002)(8676002)(81156014)(83506001)(81166006)(102836003)(6116002)(82746002)(86362001)(105586002)(1941001)(38730400001)(97736004)(39060400001)(4001350100001)(54356999)(50986999)(3660700001)(76176999)(5001770100001)(77096006)(6486002)(122556002)(7736002)(305945005)(2900100001)(5660300001)(6436002)(101416001)(92566002)(6506006)(99286003)(54906002)(25786008)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: a15c92f3-bfa1-4685-efec-08d449677f5d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR05MB2498; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498; x-forefront-prvs: 0203C93D51 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <91C93E1EBF91814EAF2C28981E3CE3C9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 23:27:03.1216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 08:30:32 -0800 Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , YANG Doctors , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:27:07 -0000 Wyt5YW5nLWRvY3RvcnNdDQoNCg0KSGkgWHVmZW5nLA0KDQo+IEkgdGhpbmsgdGhhdCB0aGUgaXNz dWUgcmFpc2VkIGJ5IEtlbnQgaGFzIGJlZW4gZGlzY3Vzc2VkIG11bHRpcGxlIHRpbWVzIGJldHdl ZW4gdGhlDQo+IGF1dGhvcnMsIEkyUlMgV0csIGFuZCBzZXZlcmFsIFlhbmcgZG9jdG9ycyAoTWFy dGluLCBBbmR5LCBhbmQgTGFkYT8pLiANCg0KTXkgcmVhZGluZyBvZiB0aGUgcmVjZW50IEkyUlMg dGhyZWFkIGNvbWVzIHRvIGEgZGlmZmVyZW50IGNvbmNsdXNpb24uICBJdCBzZWVtcyB0aGF0DQpt YW55IHdlcmUgc3RydWdnbGluZyB3aXRoIGJhc2ljcyBzdWNoIGFzIGlmIHRoaXMgaXMgYSBzdGFu ZGFyZCBZQU5HIG1vZHVsZSBvciBzb21ldGhpbmcNCmNvbnN0cmFpbmVkIHRvIGVwaGVtZXJhbC9J MlJTIHVzZSBvbmx5LiAgVGhlcmUgbWF5IGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBiZWZvcmUsIGJ1 dA0KZ2l2ZW4gdGhpcyBkaXNjb25uZWN0LCBJIHF1ZXN0aW9uIHRoZWlyIHZhbGlkaXR5LiAgU3Rp bGwsIGluIGNhc2UgSSdtIG1pc3Npbmcgc29tZXRoaW5nDQpzdWJ0bGUsIHBsZWFzZSBwb2ludCBt ZSB0byB3aGVyZSBhIFlBTkcgZG9jdG9yIGJsZXNzZWQgdGhlICdzZXJ2ZXItcHJvdmlkZWQnIGZs YWcsIA0Ka25vd2luZyB0aGF0IDEpIHRoaXMgbW9kdWxlIGlzIGZvciBnZW5lcmFsIHVzZSwgMikg aXQgcHJvbW90ZXMgbm9uLWNvbmZpZyB0byBjb25maWcsDQphbmQgMykgaXQgYnJlYWtzIHN0YW5k YXJkIG9wZXJhdGlvbnMgYW5kIHdvcmtmbG93cyAoZS5nLiwgYmFja3VwL3Jlc3RvcmUpLg0KDQpB bHRlcm5hdGl2ZWx5LCBzaW5jZSBJIGp1c3QgQ0MtZWQgdGhlIFlBTkctZG9jdG9ycyBsaXN0LCBj YW4gc29tZW9uZSB0aGVyZSBxdWlja2x5DQp0ZWxsIG1lIHRoYXQgdGhpcyBpcyByZWFsbHkgYSBz YW5jdGlvbmVkIHNvbHV0aW9uPw0KDQoNCj4gVGhlIHJlc3VsdCBvZg0KPiB0aGUgZGlzY3Vzc2lv bnMgd2FzIHRvIGtlZXAgdGhlIGN1cnJlbnQgInNlcnZlci1wcm92aWRlZCIgYXMgYSBjb21wcm9t aXNlLCBiZWNhdXNlDQo+IHRoZXJlIGhhZCBiZWVuIG5vIGlkZWFsIHNvbHV0aW9uIGF2YWlsYWJs ZSBzbyBmYXIuIA0KDQpQZXIgNjA4N2JpcyBTZWN0aW9uIDUuMjMsIHRoZSBjdXJyZW50IG9mZmlj aWFsbHkgYWNjZXB0ZWQgYXBwcm9hY2ggZm9yIHJlcG9ydGluZyANCm9wZXJhdGlvbmFsIHN0YXRl IGZvciBzeXN0ZW0tZ2VuZXJhdGVkIHZhbHVlcyBpcyB0byBoYXZlIGEgc2VwYXJhdGUgY29uZmln IGZhbHNlDQovZm9vLXN0YXRlIHRyZWUuICAgV2h5IHdhcyB0aGlzIG5vdCBjb25zaWRlcmVkIGFu IGFjY2VwdGFibGUgc29sdXRpb24/DQoNCkp1bXBpbmcgYWhlYWQgb2YgdGhlIGV4cGVjdGVkIGFu c3dlciwgSSB1bmRlcnN0YW5kIHRoYXQgY29udHJvbGxlciBhcHBzIGxpa2UgT0RMDQpoYXZlIGNv bmZpZy9pbnRlbnQgc2VydmljZS1sZXZlbCBtb2RlbHMgdGhhdCBlc3NlbnRpYWxseSBkZWZpbmVk IG92ZXJsYXkgbmV0d29ya3MNCnRoYXQgbmVlZCB0byByZWZlcmVuY2UgcmVhbCB1bmRlcmxheSBu ZXR3b3Jrcy4gIFdoaWxlIGF0IGZpcnN0IGl0IG1heSBzZWVtIGxpa2UNCmEgY2FzZSB3aGVyZSBh IGNvbmZpZyB0cnVlIG5vZGUgd291bGQgbmVlZCB0byBwb2ludCB0byBhIGNvbmZpZyBmYWxzZSBu b2RlLCBJIGRvbid0IA0KYmVsaWV2ZSBpdCdzIHRoYXQgd2F5IGF0IGFsbC4gIFJhdGhlciBJIHRo aW5rIHRoYXQgdGhlIGNvbnRyb2xsZXIgYXBwLCB3b3VsZCBpbXBvcnQNCihhbmQgbWVyZ2UvZGUt ZHVwbGljYXRlKSB0aGUgbmV0d29yayBlbGVtZW50cycgdG9wbyBvcHN0YXRlIGludG8gaXRzIGRh dGFiYXNlIGFzDQpjb25maWcgKG5vdCBvcHN0YXRlKSwgd2hpY2ggd291bGQgcmVzdWx0IGluIGNv bmZpZyB0cnVlIHBvaW50aW5nIHRvIGNvbmZpZyB0cnVlLg0KVGhlIG9ubHkgdGhpbmcgdGhhdCBt YXkgbm90IGJlIGlkZWFsIGlzIHRoZSBjb250cm9sbGVyIGFwcCB3b3VsZG4ndCBiZSBhYmxlIHRv DQpkaWZmZXJlbnRpYXRlIHdoaWNoIHBhcnRzIG9mIHRoZSB0b3BvIG1vZGVsIGl0IGltcG9ydGVk IHZlcnN1cyBjcmVhdGVkLCBhbmQgaGVyZQ0KaXMgd2hlcmUgYSAnc2VydmVyLXByb3ZpZGVkJyBm bGFnIG1pZ2h0IG1ha2Ugc2Vuc2UgYnV0LCBpbiB0aGlzIGNhc2UsIGl0IHNob3VsZA0KYmUgYW4g YXVnbWVudGF0aW9uIGFkZGVkIGluIGF0IHRoZSBjb250cm9sbGVyLWxldmVsIGFzIG9wcG9zZWQg dG8gYmVpbmcgaW4gdGhlDQpiYXNlIG1vZGVsLCByaWdodD8NCg0KDQpUaGFua3MsDQpLZW50DQoN Cg0K From nobody Tue Jan 31 08:31:02 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1DA1296A8; Mon, 30 Jan 2017 15:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetdesign.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 cp2hLtzaOqwN; Mon, 30 Jan 2017 15:40:12 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0076.outbound.protection.outlook.com [104.47.38.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5FD1296A3; Mon, 30 Jan 2017 15:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetdesign.onmicrosoft.com; s=selector1-packetdesign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tDGgoawJ/NEPZHc1HGxIJLNG9O9kdRiddvVPjFDQ7JY=; b=hwHyM28CI8dfuELrRBCHHXBTIVBNLcJ2nts/9ND6hqRAZCehIkh8K8DFarD1dtQ7VY4lJhOO80YEiu4RujJU3GtfYJWZBu2O43y6OI8MHr5gyboHUwjib0cBViKe9OC9fuciwKFA4UZ7thN/zzYdhqu9o/jJDU4X8K35peXnPR4= Received: from BY2PR04MB2103.namprd04.prod.outlook.com (10.166.111.153) by BY2PR04MB2102.namprd04.prod.outlook.com (10.166.111.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Mon, 30 Jan 2017 23:40:10 +0000 Received: from BY2PR04MB2103.namprd04.prod.outlook.com ([10.166.111.153]) by BY2PR04MB2103.namprd04.prod.outlook.com ([10.166.111.153]) with mapi id 15.01.0874.018; Mon, 30 Jan 2017 23:40:10 +0000 From: Hariharan Ananthakrishnan To: Kent Watsen , Xufeng Liu , "Alia Atlas" , Alexander Clemm , "Vishnu Pavan Beeram" Thread-Topic: proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF01VU/eoG6ofkOpJo6+d604qKFMYt4AgARMTQCAAHMegIAAYhGAgAATOYCAABhrgIAAAdUA//97uIA= Date: Mon, 30 Jan 2017 23:40:09 +0000 Message-ID: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hari@packetdesign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [38.99.127.66] x-ms-office365-filtering-correlation-id: 8c857b00-5aff-417e-2383-08d449695443 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR04MB2102; x-microsoft-exchange-diagnostics: 1; BY2PR04MB2102; 7:gYISsP3AGisbDCeda5ZhG3Ig4El42z/xEIY/jG0TBfYSsSmAYF608DzF2Ftd4Lhd2A+TTF1Sc4ia55/kjvCZQrnyXCkp7M7mgjN2wht1OnU8NrOTeGJav4G+qXWMw4kHF47DfyiCfpwHo2Je6y/06Zx7bwB3fZcW2X3z5psQpN5LMpyB3omY+Ur+GrzxPnuMYxASRTh0SxQRKeyygTZcuBSsVYxmvW+zNLz/XEQxut8KHD+QmoZTz6XtOJWNwpe5Qhby0WThZwZd+cQM6vTuybkCPLKT9e5twwI2nVRWNhcQx0B8uzZ+Tw/x5PF9EbUqgQHTDcphRUPRQHhdT8MzmP1j7oymS9iLvTHUzOFoQ1qNzWI6+fTTC9E+20cIkXU9MQL0pOqmtu0XXzWnxstlwtHBXcIfNdNjsPWMFlXAW8wpakltqDsF+bxSwet7/q8AObk0If2oiMecbrLUJigSyg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(138986009662008)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(2016111802025)(6072148)(6043046); SRVR:BY2PR04MB2102; BCL:0; PCL:0; RULEID:; SRVR:BY2PR04MB2102; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(24454002)(199003)(189002)(51444003)(6512007)(33656002)(8676002)(76176999)(50986999)(54356999)(8666007)(6306002)(4326007)(54906002)(81156014)(81166006)(230783001)(2906002)(99286003)(6116002)(102836003)(77096006)(3846002)(66066001)(93886004)(6486002)(106356001)(39060400001)(38730400001)(105586002)(7416002)(106116001)(92566002)(6436002)(8936002)(25786008)(6506006)(101416001)(68736007)(36756003)(97736004)(5660300001)(5001770100001)(53936002)(305945005)(122556002)(1941001)(7736002)(3660700001)(229853002)(83716003)(2900100001)(189998001)(3280700002)(2950100002)(82746002)(86362001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR04MB2102; H:BY2PR04MB2103.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: packetdesign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <45B561F56A9F2B4BAE2C7CE4B853648A@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: packetdesign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 23:40:09.7662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1df5b6db-3686-4e87-9323-024e5bfe00f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR04MB2102 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 08:30:27 -0800 Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , "yang-doctors@ietf.org" , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:40:16 -0000 UmVwb3N0aW5nIFlBTkcgRG9jdG9yIHJldmlldyB0aHJlYWQgZm9yIHJlZmVyZW5jZToNCiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3lhbmctZG9jdG9ycy9jdXJyZW50L21z ZzAwMDMyLmh0bWwNCg0KLSBIYXJpDQoNCk9uIDMwLzAxLzIwMTcsIDE1OjMzLCAiS2VudCBXYXRz ZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KICAgIFt1cGRhdGU6IG5vdyBDQy1p bmcgdGhlIHlhbmctZG9jdG9yJ3MgbGlzdCFdDQogICAgDQogICAgWyt5YW5nLWRvY3RvcnNdDQog ICAgDQogICAgDQogICAgSGkgWHVmZW5nLA0KICAgIA0KICAgID4gSSB0aGluayB0aGF0IHRoZSBp c3N1ZSByYWlzZWQgYnkgS2VudCBoYXMgYmVlbiBkaXNjdXNzZWQgbXVsdGlwbGUgdGltZXMgYmV0 d2VlbiB0aGUNCiAgICA+IGF1dGhvcnMsIEkyUlMgV0csIGFuZCBzZXZlcmFsIFlhbmcgZG9jdG9y cyAoTWFydGluLCBBbmR5LCBhbmQgTGFkYT8pLiANCiAgICANCiAgICBNeSByZWFkaW5nIG9mIHRo ZSByZWNlbnQgSTJSUyB0aHJlYWQgY29tZXMgdG8gYSBkaWZmZXJlbnQgY29uY2x1c2lvbi4gIEl0 IHNlZW1zIHRoYXQNCiAgICBtYW55IHdlcmUgc3RydWdnbGluZyB3aXRoIGJhc2ljcyBzdWNoIGFz IGlmIHRoaXMgaXMgYSBzdGFuZGFyZCBZQU5HIG1vZHVsZSBvciBzb21ldGhpbmcNCiAgICBjb25z dHJhaW5lZCB0byBlcGhlbWVyYWwvSTJSUyB1c2Ugb25seS4gIFRoZXJlIG1heSBoYXZlIGJlZW4g ZGlzY3Vzc2lvbnMgYmVmb3JlLCBidXQNCiAgICBnaXZlbiB0aGlzIGRpc2Nvbm5lY3QsIEkgcXVl c3Rpb24gdGhlaXIgdmFsaWRpdHkuICBTdGlsbCwgaW4gY2FzZSBJJ20gbWlzc2luZyBzb21ldGhp bmcNCiAgICBzdWJ0bGUsIHBsZWFzZSBwb2ludCBtZSB0byB3aGVyZSBhIFlBTkcgZG9jdG9yIGJs ZXNzZWQgdGhlICdzZXJ2ZXItcHJvdmlkZWQnIGZsYWcsIA0KICAgIGtub3dpbmcgdGhhdCAxKSB0 aGlzIG1vZHVsZSBpcyBmb3IgZ2VuZXJhbCB1c2UsIDIpIGl0IHByb21vdGVzIG5vbi1jb25maWcg dG8gY29uZmlnLA0KICAgIGFuZCAzKSBpdCBicmVha3Mgc3RhbmRhcmQgb3BlcmF0aW9ucyBhbmQg d29ya2Zsb3dzIChlLmcuLCBiYWNrdXAvcmVzdG9yZSkuDQogICAgDQogICAgQWx0ZXJuYXRpdmVs eSwgc2luY2UgSSBqdXN0IENDLWVkIHRoZSBZQU5HLWRvY3RvcnMgbGlzdCwgY2FuIHNvbWVvbmUg dGhlcmUgcXVpY2tseQ0KICAgIHRlbGwgbWUgdGhhdCB0aGlzIGlzIHJlYWxseSBhIHNhbmN0aW9u ZWQgc29sdXRpb24/DQogICAgDQogICAgDQogICAgPiBUaGUgcmVzdWx0IG9mDQogICAgPiB0aGUg ZGlzY3Vzc2lvbnMgd2FzIHRvIGtlZXAgdGhlIGN1cnJlbnQgInNlcnZlci1wcm92aWRlZCIgYXMg YSBjb21wcm9taXNlLCBiZWNhdXNlDQogICAgPiB0aGVyZSBoYWQgYmVlbiBubyBpZGVhbCBzb2x1 dGlvbiBhdmFpbGFibGUgc28gZmFyLiANCiAgICANCiAgICBQZXIgNjA4N2JpcyBTZWN0aW9uIDUu MjMsIHRoZSBjdXJyZW50IG9mZmljaWFsbHkgYWNjZXB0ZWQgYXBwcm9hY2ggZm9yIHJlcG9ydGlu ZyANCiAgICBvcGVyYXRpb25hbCBzdGF0ZSBmb3Igc3lzdGVtLWdlbmVyYXRlZCB2YWx1ZXMgaXMg dG8gaGF2ZSBhIHNlcGFyYXRlIGNvbmZpZyBmYWxzZQ0KICAgIC9mb28tc3RhdGUgdHJlZS4gICBX aHkgd2FzIHRoaXMgbm90IGNvbnNpZGVyZWQgYW4gYWNjZXB0YWJsZSBzb2x1dGlvbj8NCiAgICAN CiAgICBKdW1waW5nIGFoZWFkIG9mIHRoZSBleHBlY3RlZCBhbnN3ZXIsIEkgdW5kZXJzdGFuZCB0 aGF0IGNvbnRyb2xsZXIgYXBwcyBsaWtlIE9ETA0KICAgIGhhdmUgY29uZmlnL2ludGVudCBzZXJ2 aWNlLWxldmVsIG1vZGVscyB0aGF0IGVzc2VudGlhbGx5IGRlZmluZWQgb3ZlcmxheSBuZXR3b3Jr cw0KICAgIHRoYXQgbmVlZCB0byByZWZlcmVuY2UgcmVhbCB1bmRlcmxheSBuZXR3b3Jrcy4gIFdo aWxlIGF0IGZpcnN0IGl0IG1heSBzZWVtIGxpa2UNCiAgICBhIGNhc2Ugd2hlcmUgYSBjb25maWcg dHJ1ZSBub2RlIHdvdWxkIG5lZWQgdG8gcG9pbnQgdG8gYSBjb25maWcgZmFsc2Ugbm9kZSwgSSBk b24ndCANCiAgICBiZWxpZXZlIGl0J3MgdGhhdCB3YXkgYXQgYWxsLiAgUmF0aGVyIEkgdGhpbmsg dGhhdCB0aGUgY29udHJvbGxlciBhcHAsIHdvdWxkIGltcG9ydA0KICAgIChhbmQgbWVyZ2UvZGUt ZHVwbGljYXRlKSB0aGUgbmV0d29yayBlbGVtZW50cycgdG9wbyBvcHN0YXRlIGludG8gaXRzIGRh dGFiYXNlIGFzDQogICAgY29uZmlnIChub3Qgb3BzdGF0ZSksIHdoaWNoIHdvdWxkIHJlc3VsdCBp biBjb25maWcgdHJ1ZSBwb2ludGluZyB0byBjb25maWcgdHJ1ZS4NCiAgICBUaGUgb25seSB0aGlu ZyB0aGF0IG1heSBub3QgYmUgaWRlYWwgaXMgdGhlIGNvbnRyb2xsZXIgYXBwIHdvdWxkbid0IGJl IGFibGUgdG8NCiAgICBkaWZmZXJlbnRpYXRlIHdoaWNoIHBhcnRzIG9mIHRoZSB0b3BvIG1vZGVs IGl0IGltcG9ydGVkIHZlcnN1cyBjcmVhdGVkLCBhbmQgaGVyZQ0KICAgIGlzIHdoZXJlIGEgJ3Nl cnZlci1wcm92aWRlZCcgZmxhZyBtaWdodCBtYWtlIHNlbnNlIGJ1dCwgaW4gdGhpcyBjYXNlLCBp dCBzaG91bGQNCiAgICBiZSBhbiBhdWdtZW50YXRpb24gYWRkZWQgaW4gYXQgdGhlIGNvbnRyb2xs ZXItbGV2ZWwgYXMgb3Bwb3NlZCB0byBiZWluZyBpbiB0aGUNCiAgICBiYXNlIG1vZGVsLCByaWdo dD8NCiAgICANCiAgICANCiAgICBUaGFua3MsDQogICAgS2VudA0KICAgIA0KICAgIA0KICAgIA0K ICAgIA0KICAgIA0KDQo= From nobody Tue Jan 31 08:31:13 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052AF129617; Mon, 30 Jan 2017 15:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Ru6DDzli1hzh; Mon, 30 Jan 2017 15:33:39 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDD9129603; Mon, 30 Jan 2017 15:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EqW8a9uDt8ZE+1eogeWyQUHhAP9LdZSo7tsnX7K47iw=; b=dwFK4hFHJVwnfT1V/cWpGN33LHcmbz19of01nlwFFIwgTAcaXWnw5Dtb2TPz3fa4Ex8wA4TA/Wn2czoYWKMIM6y2Ntw5U/JUHUxJx4txvNjO8bJwWBAQ/I9KH9e2QkSSTmbBtC16uDbMS5xkwKQVvY77kMIE6XWXYcPnOojtAZk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Mon, 30 Jan 2017 23:33:37 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 23:33:36 +0000 From: Kent Watsen To: Xufeng Liu , Alia Atlas , Alexander Clemm , Vishnu Pavan Beeram Thread-Topic: proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF003mrxpQG/YkWQXb+DOWQ2Z6FMYt4AgARMTQCAAHMegIAAYhGAgAATOYD//8SZAIAAAdSA Date: Mon, 30 Jan 2017 23:33:36 +0000 Message-ID: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> In-Reply-To: <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; CY1PR05MB2508; 7:07svCfsDd+0xep0qac4hbyJ6VVYYu1/Oc5k4RWc029+NXYxBmtmO2mfHhbzEKRTarDmYM6Fyrnn9i/reiDypWIr+gUwPGPijYlyVAUov107Jw6ke1FFYRDBKxNlqyyOzs48COPuUvtB50MWtgaIj5j7UNbTmTUZjYTSIjW6rIAkcsKW4VgwyLdGx02YXMB1dLA4hc5EHwzedegobXF82u9VJ5bIv0ndSrYs34pSAGHCSu/0+lN6F21RH9Oeg6XaZcsghjDZWaBNLY3nZl20skviw7iTOFFX3Wgv+W0LEx1+OsEWHY7391BPfYK2wcsDHsfJ03XN84vMtPRErmJA7z62yVzAwR2Sd41q97vGbxlX0l1VWRwYrZYx8KxZ5D+MUpwOwJT9Xgvkh+802uTYJKMuGUE2khF/OKzq5lv0mufkiLveJYPe6r61NcD6XIlMRdk7Lp7rlMZRBT7PshLOOXQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(199003)(189002)(51444003)(5660300001)(1941001)(6436002)(66066001)(36756003)(305945005)(7736002)(2900100001)(54356999)(76176999)(4326007)(50986999)(53936002)(6506006)(38730400001)(81166006)(39060400001)(6486002)(2906002)(101416001)(3280700002)(229853002)(54906002)(33656002)(77096006)(6512007)(8936002)(6862003)(122556002)(8676002)(68736007)(81156014)(106356001)(189998001)(99286003)(25786008)(106116001)(105586002)(82746002)(6116002)(86362001)(102836003)(6636002)(5001770100001)(2950100002)(83716003)(97736004)(83506001)(3846002)(4001350100001)(3660700001)(92566002)(93886004)(230783001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 80ee1385-b6b3-453a-d8c7-08d4496869d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:CY1PR05MB2508; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; x-forefront-prvs: 0203C93D51 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6CBACED576557F498AC1AE4455E7D4DD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 23:33:36.6143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 08:30:33 -0800 Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , "yang-doctors@ietf.org" , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:33:41 -0000 W3VwZGF0ZTogbm93IENDLWluZyB0aGUgeWFuZy1kb2N0b3IncyBsaXN0IV0NCg0KWyt5YW5nLWRv Y3RvcnNdDQoNCg0KSGkgWHVmZW5nLA0KDQo+IEkgdGhpbmsgdGhhdCB0aGUgaXNzdWUgcmFpc2Vk IGJ5IEtlbnQgaGFzIGJlZW4gZGlzY3Vzc2VkIG11bHRpcGxlIHRpbWVzIGJldHdlZW4gdGhlDQo+ IGF1dGhvcnMsIEkyUlMgV0csIGFuZCBzZXZlcmFsIFlhbmcgZG9jdG9ycyAoTWFydGluLCBBbmR5 LCBhbmQgTGFkYT8pLiANCg0KTXkgcmVhZGluZyBvZiB0aGUgcmVjZW50IEkyUlMgdGhyZWFkIGNv bWVzIHRvIGEgZGlmZmVyZW50IGNvbmNsdXNpb24uICBJdCBzZWVtcyB0aGF0DQptYW55IHdlcmUg c3RydWdnbGluZyB3aXRoIGJhc2ljcyBzdWNoIGFzIGlmIHRoaXMgaXMgYSBzdGFuZGFyZCBZQU5H IG1vZHVsZSBvciBzb21ldGhpbmcNCmNvbnN0cmFpbmVkIHRvIGVwaGVtZXJhbC9JMlJTIHVzZSBv bmx5LiAgVGhlcmUgbWF5IGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBiZWZvcmUsIGJ1dA0KZ2l2ZW4g dGhpcyBkaXNjb25uZWN0LCBJIHF1ZXN0aW9uIHRoZWlyIHZhbGlkaXR5LiAgU3RpbGwsIGluIGNh c2UgSSdtIG1pc3Npbmcgc29tZXRoaW5nDQpzdWJ0bGUsIHBsZWFzZSBwb2ludCBtZSB0byB3aGVy ZSBhIFlBTkcgZG9jdG9yIGJsZXNzZWQgdGhlICdzZXJ2ZXItcHJvdmlkZWQnIGZsYWcsIA0Ka25v d2luZyB0aGF0IDEpIHRoaXMgbW9kdWxlIGlzIGZvciBnZW5lcmFsIHVzZSwgMikgaXQgcHJvbW90 ZXMgbm9uLWNvbmZpZyB0byBjb25maWcsDQphbmQgMykgaXQgYnJlYWtzIHN0YW5kYXJkIG9wZXJh dGlvbnMgYW5kIHdvcmtmbG93cyAoZS5nLiwgYmFja3VwL3Jlc3RvcmUpLg0KDQpBbHRlcm5hdGl2 ZWx5LCBzaW5jZSBJIGp1c3QgQ0MtZWQgdGhlIFlBTkctZG9jdG9ycyBsaXN0LCBjYW4gc29tZW9u ZSB0aGVyZSBxdWlja2x5DQp0ZWxsIG1lIHRoYXQgdGhpcyBpcyByZWFsbHkgYSBzYW5jdGlvbmVk IHNvbHV0aW9uPw0KDQoNCj4gVGhlIHJlc3VsdCBvZg0KPiB0aGUgZGlzY3Vzc2lvbnMgd2FzIHRv IGtlZXAgdGhlIGN1cnJlbnQgInNlcnZlci1wcm92aWRlZCIgYXMgYSBjb21wcm9taXNlLCBiZWNh dXNlDQo+IHRoZXJlIGhhZCBiZWVuIG5vIGlkZWFsIHNvbHV0aW9uIGF2YWlsYWJsZSBzbyBmYXIu IA0KDQpQZXIgNjA4N2JpcyBTZWN0aW9uIDUuMjMsIHRoZSBjdXJyZW50IG9mZmljaWFsbHkgYWNj ZXB0ZWQgYXBwcm9hY2ggZm9yIHJlcG9ydGluZyANCm9wZXJhdGlvbmFsIHN0YXRlIGZvciBzeXN0 ZW0tZ2VuZXJhdGVkIHZhbHVlcyBpcyB0byBoYXZlIGEgc2VwYXJhdGUgY29uZmlnIGZhbHNlDQov Zm9vLXN0YXRlIHRyZWUuICAgV2h5IHdhcyB0aGlzIG5vdCBjb25zaWRlcmVkIGFuIGFjY2VwdGFi bGUgc29sdXRpb24/DQoNCkp1bXBpbmcgYWhlYWQgb2YgdGhlIGV4cGVjdGVkIGFuc3dlciwgSSB1 bmRlcnN0YW5kIHRoYXQgY29udHJvbGxlciBhcHBzIGxpa2UgT0RMDQpoYXZlIGNvbmZpZy9pbnRl bnQgc2VydmljZS1sZXZlbCBtb2RlbHMgdGhhdCBlc3NlbnRpYWxseSBkZWZpbmVkIG92ZXJsYXkg bmV0d29ya3MNCnRoYXQgbmVlZCB0byByZWZlcmVuY2UgcmVhbCB1bmRlcmxheSBuZXR3b3Jrcy4g IFdoaWxlIGF0IGZpcnN0IGl0IG1heSBzZWVtIGxpa2UNCmEgY2FzZSB3aGVyZSBhIGNvbmZpZyB0 cnVlIG5vZGUgd291bGQgbmVlZCB0byBwb2ludCB0byBhIGNvbmZpZyBmYWxzZSBub2RlLCBJIGRv bid0IA0KYmVsaWV2ZSBpdCdzIHRoYXQgd2F5IGF0IGFsbC4gIFJhdGhlciBJIHRoaW5rIHRoYXQg dGhlIGNvbnRyb2xsZXIgYXBwLCB3b3VsZCBpbXBvcnQNCihhbmQgbWVyZ2UvZGUtZHVwbGljYXRl KSB0aGUgbmV0d29yayBlbGVtZW50cycgdG9wbyBvcHN0YXRlIGludG8gaXRzIGRhdGFiYXNlIGFz DQpjb25maWcgKG5vdCBvcHN0YXRlKSwgd2hpY2ggd291bGQgcmVzdWx0IGluIGNvbmZpZyB0cnVl IHBvaW50aW5nIHRvIGNvbmZpZyB0cnVlLg0KVGhlIG9ubHkgdGhpbmcgdGhhdCBtYXkgbm90IGJl IGlkZWFsIGlzIHRoZSBjb250cm9sbGVyIGFwcCB3b3VsZG4ndCBiZSBhYmxlIHRvDQpkaWZmZXJl bnRpYXRlIHdoaWNoIHBhcnRzIG9mIHRoZSB0b3BvIG1vZGVsIGl0IGltcG9ydGVkIHZlcnN1cyBj cmVhdGVkLCBhbmQgaGVyZQ0KaXMgd2hlcmUgYSAnc2VydmVyLXByb3ZpZGVkJyBmbGFnIG1pZ2h0 IG1ha2Ugc2Vuc2UgYnV0LCBpbiB0aGlzIGNhc2UsIGl0IHNob3VsZA0KYmUgYW4gYXVnbWVudGF0 aW9uIGFkZGVkIGluIGF0IHRoZSBjb250cm9sbGVyLWxldmVsIGFzIG9wcG9zZWQgdG8gYmVpbmcg aW4gdGhlDQpiYXNlIG1vZGVsLCByaWdodD8NCg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCg== From nobody Tue Jan 31 08:31:15 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48E71297AB; Mon, 30 Jan 2017 17:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 AybSuO7-IXt4; Mon, 30 Jan 2017 17:07:38 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0184C1297A7; Mon, 30 Jan 2017 17:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mBzJkG3Hoeewu7D+pVClpFps2nL5hJHthmoNRF9Yoa8=; b=fNXp3u4aMeNHOb7GwcCgkhMjs1py1xfVgB7SbXabXCp2UGf8ez8PsCr3W3aWsHzpi2ehVnY3Uf3agTJlrDFwpKT03DqdCGVFjMdtVJs5az399oRXqhQhvPrGolueG+mJEEVVL7qOyyA7tHB41LRcYKQZGXoCQUX1vvobDRkeMMo= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 01:07:35 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.019; Tue, 31 Jan 2017 01:07:33 +0000 From: Kent Watsen To: Hariharan Ananthakrishnan , Xufeng Liu , Alia Atlas , Alexander Clemm , Vishnu Pavan Beeram Thread-Topic: proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF003mrxpQG/YkWQXb+DOWQ2Z6FMYt4AgARMTQCAAHMegIAAYhGAgAATOYD//8SZAIAAAdSAgABVp4D//8SZAA== Date: Tue, 31 Jan 2017 01:07:33 +0000 Message-ID: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; CY1PR05MB2506; 7:dFybJSMIgv/VyqRUVo02y3jaZAZNcBYA9C9u6hZ0t4YXoNnrRgo2fgH+YHWcYVz+wN9quF36shZ1vFSeUOYd/nTNJ4WptEIeryvIDbJr3IhZTMUA15vlMw1YMd56RHlGbtQugw5oBkZIiwFDN3qRbEtuOaE0ZN8gz34tDEsa55w5bZOmdd1WAZg8lrxXiKlNI5kIroYGaAksC5kO4xU/k/9VX8LWh9ReiTHXU0xPuTtl21KYKWq2/9L6Ewdi5dHmj+gzKMlaVl1aYDk7BODf/VNakgiGT15jOaCtXbArqQEFCqEuHxfCgEIy3bhjKhh/slkEkMu96n3u6WbFlMQ5AgJPG9FgJOr7APE28qB3/tCEzqpWEJPaJJM4m/k7sZJ2F5GVD2eURQyGp3Q4WtVOVdE8xlVKT6i5F9pAIRs7VwVOlWZBdCz2GXNK7KFvU/QnzNLuy/A1UgjvrUWmls6Sww== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(51444003)(189002)(199003)(24454002)(1941001)(33656002)(8936002)(8676002)(189998001)(81166006)(81156014)(8656002)(77096006)(2950100002)(6862003)(101416001)(6636002)(3280700002)(7416002)(105586002)(6506006)(6486002)(122556002)(54906002)(3660700001)(4001350100001)(229853002)(5660300001)(6306002)(39060400001)(106116001)(83506001)(82746002)(50986999)(54356999)(99286003)(76176999)(106356001)(25786008)(230783001)(7736002)(2900100001)(86362001)(68736007)(83716003)(6512007)(305945005)(5001770100001)(66066001)(53936002)(4326007)(102836003)(2906002)(97736004)(92566002)(3846002)(6116002)(6436002)(38730400001)(93886004)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 95907e1d-f89b-443d-a2b5-08d4497589e7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2506; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(138986009662008)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; x-forefront-prvs: 0204F0BDE2 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <248B958FC6019E45BA1A8164D5A9B2F4@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 01:07:33.7867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 08:30:33 -0800 Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , "yang-doctors@ietf.org" , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:07:40 -0000 DQpUaGFua3MgSGFyaSwNCg0KVGhhdCByZXZpZXcgd2FzIGEgd2hpbGUgYWdvLCBhbmQgdGhlcmUg aXMgbm8gc3VwcG9ydCBmb3IgdGhpcyBhcHByb2FjaCBmcm9tIG1lIG9mIEFuZHkgdGhlcmUuICBJ IHdhcyBob3BpbmcgdGhlcmUgd2FzIHNvbWV0aGluZyBtb3JlIHJlY2VudC4uLg0KDQpTZWFyY2hp bmcgJ3NlcnZlci1wcm92aWRlZCcgaW4gdGhlIEkyUlMgbWFpbGluZyBsaXN0LCBJIHNlZSB0aGUg IldHIExDIGZvciBUb3BvbG9neSAoMTAvMSB0byAxMC8xNCkiIGRpc2N1c3Npb24gaW4gT2N0b2Jl ciAyMDE1IGluIHdoaWNoIE1hcnRpbiwgSnVlcmdlbiwgYW5kIEFuZHkgY29udGludWFsbHkgc2F5 IHRoYXQgdGhpcyBpcyBhIG1pc3VzZSBvZiBZQU5HLiAgSSBjYW4ndCBmaW5kIGFueSBzdXBwb3J0 IGZvciB0aGlzIGFwcHJvYWNoIHRoZXJlLiAgW0ZXSVcsIHRoYXQgdGhyZWFkIGVuZHMgd2l0aG91 dCBhIHJlc29sdXRpb24gdGhhdCBJIGNhbiBzZWVdLg0KDQpTdHJhbmdlbHksIHRoZSBuZXh0IHRp bWUgJ3NlcnZlci1wcm92aWRlZCcgaXMgZGlzY3Vzc2VkIGlzIG5lYXJseSAxNCBtb250aHMgbGF0 ZXIsIGR1cmluZyB0aGUgbW9zdC1yZWNlbnQgSUVTRyBiYWxsb3RpbmcuICBBY3R1YWxseSwganVz dCBzZWFyY2hpbmcgZm9yIHRoZSB3b3JkICdwcm92aWRlZCcgeWllbGRzIHRoZSBzYW1lIHJlc3Vs dC4gIEluIGVpdGhlciBjYXNlLCBhcyB3ZSBhbGwga25vdywgdGhlIG1vc3QgcmVjZW50IGRpc2N1 c3Npb24gZGlkbid0IHlpZWxkIHN1cHBvcnQgZm9yIHRoaXMgYXBwcm9hY2ggZWl0aGVyLg0KDQpB cyBJJ20gdW5hYmxlIHRvIGZpbmQgYW55IHN1cHBvcnQgYW5kLCBpbiBmYWN0LCBmaW5kIHF1aXRl IHRoZSBvcHBvc2l0ZSwgSSBzdGFuZCBieSBteSBjb25jZXJuIHRoYXQgdGhpcyBpcyBhbiBpbGxl Z2FsIHVzZSBvZiBZQU5HLg0KDQpLZW50DQoNCg0KDQpSZXBvc3RpbmcgWUFORyBEb2N0b3IgcmV2 aWV3IHRocmVhZCBmb3IgcmVmZXJlbmNlOg0KIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIveWFuZy1kb2N0b3JzL2N1cnJlbnQvbXNnMDAwMzIuaHRtbA0KDQotIEhhcmkNCg0K T24gMzAvMDEvMjAxNywgMTU6MzMsICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+ IHdyb3RlOg0KDQogICAgW3VwZGF0ZTogbm93IENDLWluZyB0aGUgeWFuZy1kb2N0b3IncyBsaXN0 IV0NCiAgICANCiAgICBbK3lhbmctZG9jdG9yc10NCiAgICANCiAgICANCiAgICBIaSBYdWZlbmcs DQogICAgDQogICAgPiBJIHRoaW5rIHRoYXQgdGhlIGlzc3VlIHJhaXNlZCBieSBLZW50IGhhcyBi ZWVuIGRpc2N1c3NlZCBtdWx0aXBsZSB0aW1lcyBiZXR3ZWVuIHRoZQ0KICAgID4gYXV0aG9ycywg STJSUyBXRywgYW5kIHNldmVyYWwgWWFuZyBkb2N0b3JzIChNYXJ0aW4sIEFuZHksIGFuZCBMYWRh PykuIA0KICAgIA0KICAgIE15IHJlYWRpbmcgb2YgdGhlIHJlY2VudCBJMlJTIHRocmVhZCBjb21l cyB0byBhIGRpZmZlcmVudCBjb25jbHVzaW9uLiAgSXQgc2VlbXMgdGhhdA0KICAgIG1hbnkgd2Vy ZSBzdHJ1Z2dsaW5nIHdpdGggYmFzaWNzIHN1Y2ggYXMgaWYgdGhpcyBpcyBhIHN0YW5kYXJkIFlB TkcgbW9kdWxlIG9yIHNvbWV0aGluZw0KICAgIGNvbnN0cmFpbmVkIHRvIGVwaGVtZXJhbC9JMlJT IHVzZSBvbmx5LiAgVGhlcmUgbWF5IGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBiZWZvcmUsIGJ1dA0K ICAgIGdpdmVuIHRoaXMgZGlzY29ubmVjdCwgSSBxdWVzdGlvbiB0aGVpciB2YWxpZGl0eS4gIFN0 aWxsLCBpbiBjYXNlIEknbSBtaXNzaW5nIHNvbWV0aGluZw0KICAgIHN1YnRsZSwgcGxlYXNlIHBv aW50IG1lIHRvIHdoZXJlIGEgWUFORyBkb2N0b3IgYmxlc3NlZCB0aGUgJ3NlcnZlci1wcm92aWRl ZCcgZmxhZywgDQogICAga25vd2luZyB0aGF0IDEpIHRoaXMgbW9kdWxlIGlzIGZvciBnZW5lcmFs IHVzZSwgMikgaXQgcHJvbW90ZXMgbm9uLWNvbmZpZyB0byBjb25maWcsDQogICAgYW5kIDMpIGl0 IGJyZWFrcyBzdGFuZGFyZCBvcGVyYXRpb25zIGFuZCB3b3JrZmxvd3MgKGUuZy4sIGJhY2t1cC9y ZXN0b3JlKS4NCiAgICANCiAgICBBbHRlcm5hdGl2ZWx5LCBzaW5jZSBJIGp1c3QgQ0MtZWQgdGhl IFlBTkctZG9jdG9ycyBsaXN0LCBjYW4gc29tZW9uZSB0aGVyZSBxdWlja2x5DQogICAgdGVsbCBt ZSB0aGF0IHRoaXMgaXMgcmVhbGx5IGEgc2FuY3Rpb25lZCBzb2x1dGlvbj8NCiAgICANCiAgICAN CiAgICA+IFRoZSByZXN1bHQgb2YNCiAgICA+IHRoZSBkaXNjdXNzaW9ucyB3YXMgdG8ga2VlcCB0 aGUgY3VycmVudCAic2VydmVyLXByb3ZpZGVkIiBhcyBhIGNvbXByb21pc2UsIGJlY2F1c2UNCiAg ICA+IHRoZXJlIGhhZCBiZWVuIG5vIGlkZWFsIHNvbHV0aW9uIGF2YWlsYWJsZSBzbyBmYXIuIA0K ICAgIA0KICAgIFBlciA2MDg3YmlzIFNlY3Rpb24gNS4yMywgdGhlIGN1cnJlbnQgb2ZmaWNpYWxs eSBhY2NlcHRlZCBhcHByb2FjaCBmb3IgcmVwb3J0aW5nIA0KICAgIG9wZXJhdGlvbmFsIHN0YXRl IGZvciBzeXN0ZW0tZ2VuZXJhdGVkIHZhbHVlcyBpcyB0byBoYXZlIGEgc2VwYXJhdGUgY29uZmln IGZhbHNlDQogICAgL2Zvby1zdGF0ZSB0cmVlLiAgIFdoeSB3YXMgdGhpcyBub3QgY29uc2lkZXJl ZCBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uPw0KICAgIA0KICAgIEp1bXBpbmcgYWhlYWQgb2YgdGhl IGV4cGVjdGVkIGFuc3dlciwgSSB1bmRlcnN0YW5kIHRoYXQgY29udHJvbGxlciBhcHBzIGxpa2Ug T0RMDQogICAgaGF2ZSBjb25maWcvaW50ZW50IHNlcnZpY2UtbGV2ZWwgbW9kZWxzIHRoYXQgZXNz ZW50aWFsbHkgZGVmaW5lZCBvdmVybGF5IG5ldHdvcmtzDQogICAgdGhhdCBuZWVkIHRvIHJlZmVy ZW5jZSByZWFsIHVuZGVybGF5IG5ldHdvcmtzLiAgV2hpbGUgYXQgZmlyc3QgaXQgbWF5IHNlZW0g bGlrZQ0KICAgIGEgY2FzZSB3aGVyZSBhIGNvbmZpZyB0cnVlIG5vZGUgd291bGQgbmVlZCB0byBw b2ludCB0byBhIGNvbmZpZyBmYWxzZSBub2RlLCBJIGRvbid0IA0KICAgIGJlbGlldmUgaXQncyB0 aGF0IHdheSBhdCBhbGwuICBSYXRoZXIgSSB0aGluayB0aGF0IHRoZSBjb250cm9sbGVyIGFwcCwg d291bGQgaW1wb3J0DQogICAgKGFuZCBtZXJnZS9kZS1kdXBsaWNhdGUpIHRoZSBuZXR3b3JrIGVs ZW1lbnRzJyB0b3BvIG9wc3RhdGUgaW50byBpdHMgZGF0YWJhc2UgYXMNCiAgICBjb25maWcgKG5v dCBvcHN0YXRlKSwgd2hpY2ggd291bGQgcmVzdWx0IGluIGNvbmZpZyB0cnVlIHBvaW50aW5nIHRv IGNvbmZpZyB0cnVlLg0KICAgIFRoZSBvbmx5IHRoaW5nIHRoYXQgbWF5IG5vdCBiZSBpZGVhbCBp cyB0aGUgY29udHJvbGxlciBhcHAgd291bGRuJ3QgYmUgYWJsZSB0bw0KICAgIGRpZmZlcmVudGlh dGUgd2hpY2ggcGFydHMgb2YgdGhlIHRvcG8gbW9kZWwgaXQgaW1wb3J0ZWQgdmVyc3VzIGNyZWF0 ZWQsIGFuZCBoZXJlDQogICAgaXMgd2hlcmUgYSAnc2VydmVyLXByb3ZpZGVkJyBmbGFnIG1pZ2h0 IG1ha2Ugc2Vuc2UgYnV0LCBpbiB0aGlzIGNhc2UsIGl0IHNob3VsZA0KICAgIGJlIGFuIGF1Z21l bnRhdGlvbiBhZGRlZCBpbiBhdCB0aGUgY29udHJvbGxlci1sZXZlbCBhcyBvcHBvc2VkIHRvIGJl aW5nIGluIHRoZQ0KICAgIGJhc2UgbW9kZWwsIHJpZ2h0Pw0KICAgIA0KICAgIA0KICAgIFRoYW5r cywNCiAgICBLZW50DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQoNCg0KDQo= From nobody Tue Jan 31 08:31:19 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52196129428; Tue, 31 Jan 2017 00:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 qBQohUjoGF3V; Tue, 31 Jan 2017 00:24:19 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0114.outbound.protection.outlook.com [104.47.38.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D03129444; Tue, 31 Jan 2017 00:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qw72Zqeq1KsQng1eIwvQ4wmCH9QJNIrPOgXDpw+3gdc=; b=aMg3fS4QsD/kecXq+m9tFnmfkQlP/vu+EHXNKt7UsHFzBthVMEaWdv10I/HE0l6Hs887Q2EptrXTt4yY8GN8Ax9ku2ynZX0zPkfdq6dCnag1QIUl3v0oidSOJihJD0gsj6zYP77mplIFWTGMYuKD6ybJkWWny87tKnSX3zQo8Kc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 31 Jan 2017 08:24:15 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 08:24:14 +0000 From: Kent Watsen To: Hariharan Ananthakrishnan , Xufeng Liu , Alia Atlas , Alexander Clemm , Vishnu Pavan Beeram Thread-Topic: proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF003mrxpQG/YkWQXb+DOWQ2Z6FMYt4AgARMTQCAAHMegIAAYhGAgAATOYD//8SZAIAAAdSAgABVp4D//8SZAIAAegKA Date: Tue, 31 Jan 2017 08:24:14 +0000 Message-ID: <10D180C2-C4E7-4002-B390-E109DB2D44C6@juniper.net> References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; CO2PR05MB2502; 7:e7rwcAp+G9B9b4ZzjSXGGcW1PeKb0ZmGQcSvQixybMYkSBli/51rgiPvuUlSBcUOgZ4TX8/RqzZfPCxPZmGAbs6XZp96unolcg5UTwLDZy1tmqRuBV2qOPbJe6Txcx2wU7R219DUWIZlYzIQsVlMyy9E+8SNh/YUPd3svcvZsbKFP3Je3eVsFODumX9jX9t7zWnOt+kdlcRH6IWUe4brHBZNj/4ifZmNxZ790qgIQh/8FDk0V3+ElCQYyOwJLx8CTdjEjhlsfrS8bHn1EIzLEElgXZZYZYV6agVed/DA5tG6mTtLKRLGsWBfbwD37u0XbDhtFhvqtoH6MUIERxxMWFoPrL2Ps9zkQIA+TIR/Gyt7PuBYQn9H00WRwhcuDUGDNjCIAIOZe/r48Cgu187IzFNXaqR/sue4YRowR4rsD6iN001PJoxOItxNq2M6qLaPDKsePc6xpDbvC2F76leX9v+A4nqwoLNIpZAV3i0uDeaWRuyTDSIHRfjbB6r0xjp/30Un+2v+sNpMV39mcMzYag6Aq+EdiaKjMgqloFzBwkLUyBY4ogTUqyH6sSmk3MNr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(52314003)(189002)(51444003)(24454002)(199003)(8656002)(3846002)(4326007)(25786008)(6436002)(229853002)(38730400001)(189998001)(106116001)(106356001)(5660300001)(6512007)(6306002)(77096006)(105586002)(6506006)(39060400001)(102836003)(99286003)(97736004)(54906002)(5001770100001)(6116002)(305945005)(2950100002)(83506001)(7736002)(6636002)(6486002)(3280700002)(82746002)(83716003)(6862003)(7416002)(4001350100001)(2906002)(86362001)(92566002)(101416001)(36756003)(53936002)(68736007)(50986999)(54356999)(3660700001)(66066001)(122556002)(2900100001)(8676002)(33656002)(230783001)(8936002)(81166006)(81156014)(76176999)(93886004)(1941001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: e33ee04c-2dd9-4231-c009-08d449b28af0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:CO2PR05MB2502; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(138986009662008)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; x-forefront-prvs: 0204F0BDE2 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 08:24:14.6841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 08:30:33 -0800 Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , "yang-doctors@ietf.org" , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 08:24:21 -0000 SSBqdXN0IHdva2UgdXAgdGhpbmtpbmcgSSBhYm91dCB0aGlzIGFuZCBmZWx0IGxpa2UgSSBuZWVk ZWQgdG8gZXhwbGFpbiBteSB5YW5nLWRvY3RvciByZXZpZXcgc29tZSBiZWZvcmUgbXkgY29uc2Np b3VzIHdvdWxkIGxldCBtZSBnbyB0byBzbGVlcCBhZ2FpbiAoaWYgcG9zc2libGUgYWZ0ZXIgc3Rh cmluZyBhdCB0aGUgc2NyZWVuIHRvIHdyaXRlIHRoaXMpLg0KDQpBbnl3YXksIEkgcmVtZW1iZXIg dGhpcyB5YW5nLWRvY3RvciByZXZpZXcsIGl0IHdhcyBteSBmaXJzdCBhbmQgb25seSBzdWNoIHJl dmlldy4gIEknZCBuZXZlciBsb29rZWQgYXQgdGhlIHRvcG8gZHJhZnQgYmVmb3JlLiAgSSByZW1l bWJlciB0aGlua2luZyB0aGF0IEkgc2hvdWxkIG9ubHkgbmVlZCB0byBsb29rIGF0IHRoZSBZQU5H IG1vZHVsZSBpdHNlbGYgc2luY2UsIGdlbmVyaWNhbGx5IHNwZWFraW5nLCB5YW5nLWRvY3RvcnMg Y2FuJ3QgYmUgZG9tYWluLWV4cGVydHMgaW4gZXZlcnkgV0cuICBJIGxpdGVyYWxseSBqdXN0IHNl YXJjaGVkIGZvciB0aGUgWUFORyBtb2R1bGVzIGNvbnRhaW5lZCB3aXRoaW4gdGhlIGRyYWZ0LCBz a2lwcGluZyBhbGwgdGV4dCBsZWFkaW5nIHVwIHRvIHRoZW0uICBXaGF0IEkgc2F3IHdhcyBhIGNv bmZpZyBmYWxzZSBub2RlIGNhbGxlZCAnc2VydmVyLXByb3ZpZGVkJyBoYXZpbmcgYSBzb21ld2hh dCB1bnJlbWFya2FibGUgZGVzY3JpcHRpb24gc3RhdGVtZW50IGFuZCBuYWl2ZWx5IHdvbmRlcmVk IGlmIHRoZSBub2RlIGhhZCBhIGxpZmVjeWNsZSBkaWZmZXJlbnQgdGhhbiAvbmV0d29ya3MvbmV0 d29yay9uZXR3b3JrLWlkLCB3aGljaCBpcyB3aHkgbW9kZWxzIHR5cGljYWxseSBoYXZlIGEgdG9w LWxldmVsIC9mb28tc3RhdGUgdHJlZS4gSXQgbmV2ZXIgb2NjdXJyZWQgdG8gbWUgdGhhdCB0aGlz IGxpdHRsZSBmbGFnIHdhcyBhY3R1YWxseSBiZWluZyB1c2VkIHRvIGNoYW5nZSBmdW5kYW1lbnRh bCBZQU5HIHNlbWFudGljcy4gIEkgd2FzIG5vdCBhdCB0aGlzIHRpbWUgYXdhcmUgb2YgdGhlIHRo cmVhZCB0aGF0IGhhZCBvY2N1cnJlZCBvbiB0aGUgaTJycyBsaXN0IGJlZm9yZS4gIEFzIGFuIGFz aWRlLCBub3RlIHRoYXQgSSBjb21wbGV0ZWx5IG1pc3NlZCB0aGF0IChpbiAtMDMpICduZXR3b3Jr LXJlZicgd2FzIGEgY29uZmlnIGZhbHNlIG5vZGUgcG9pbnRpbmcgdG8gYSBjb25maWcgdHJ1ZSBu b2RlLCB3aGljaCBzaG91bGQndmUgZmFpbGVkIFlBTkcgdmFsaWRhdGlvbi4gIEFueXdheSwgdGhl IHJlc3BvbnNlIEkgZ290IGJhY2sgZGlkbid0IGFsZXJ0IG1lLCBhbmQgSSBmaWd1cmVkIGl0IHdh cyBhIFdHIG1hdHRlciB0byBzb3J0IG91dC4gIA0KDQpBcyBmYXIgYXMgcG9zdC1tb3J0ZW1zIGdv LCBJIHNob3VsZCd2ZSBkdWcgYSBsaXR0bGUgZGVlcGVyLCBwZXJoYXBzIGlucXVpcmluZyBhYm91 dCB0aGUgbmF0dXJlIG9mIHRoZSAiY29udHJvdmVyc2lhbCBkaXNjdXNzaW9ucyIgYW5kL29yIHJl YWRpbmcgbW9yZSBvZiB0aGUgZHJhZnQgdG8gdW5kZXJzdGFuZCB0aGUgJ3NlcnZlci1wcm92aWRl ZCcgZmxhZydzIHNlbWFudGljcy4gIEFuZCwgZm9yIEFsZXgncyBwYXJ0LCBoZSBtYXkgaGF2ZSBh c3N1bWVkIHRoYXQgSSdkIHNlZW4gdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBJMlJTIGxpc3QgZnJv bSBiZWZvcmUgYW5kL29yIHJlYWQgdGhlIGVudGlyZSBkcmFmdC4gIEFueXdheSwgaXQgc2VlbXMg dGhhdCB0aGlzIGZlbGwgdGhyb3VnaCB0aGUgY3JhY2tzIGFuZCBmb3IgdGhhdCBJIGFwb2xvZ2l6 ZS4gICBbR29vZCwgbm93IHRoYXQgSSdkIHNhaWQgdGhhdCwgbWF5YmUgSSBjYW4gZ2V0IGJhY2sg dG8gc2xlZXBdLg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpUaGFua3MgSGFyaSwNCg0KVGhhdCBy ZXZpZXcgd2FzIGEgd2hpbGUgYWdvLCBhbmQgdGhlcmUgaXMgbm8gc3VwcG9ydCBmb3IgdGhpcyBh cHByb2FjaCBmcm9tIG1lIG9yIEFuZHkgdGhlcmUuICBJIHdhcyBob3BpbmcgdGhlcmUgd2FzIHNv bWV0aGluZyBtb3JlIHJlY2VudC4uLg0KDQpTZWFyY2hpbmcgJ3NlcnZlci1wcm92aWRlZCcgaW4g dGhlIEkyUlMgbWFpbGluZyBsaXN0LCBJIHNlZSB0aGUgIldHIExDIGZvciBUb3BvbG9neSAoMTAv MSB0byAxMC8xNCkiIGRpc2N1c3Npb24gaW4gT2N0b2JlciAyMDE1IGluIHdoaWNoIE1hcnRpbiwg SnVlcmdlbiwgYW5kIEFuZHkgY29udGludWFsbHkgc2F5IHRoYXQgdGhpcyBpcyBhIG1pc3VzZSBv ZiBZQU5HLiAgSSBjYW4ndCBmaW5kIGFueSBzdXBwb3J0IGZvciB0aGlzIGFwcHJvYWNoIHRoZXJl LiAgW0ZXSVcsIHRoYXQgdGhyZWFkIGVuZHMgd2l0aG91dCBhIHJlc29sdXRpb24gdGhhdCBJIGNh biBzZWVdLg0KDQpTdHJhbmdlbHksIHRoZSBuZXh0IHRpbWUgJ3NlcnZlci1wcm92aWRlZCcgaXMg ZGlzY3Vzc2VkIGlzIG5lYXJseSAxNCBtb250aHMgbGF0ZXIsIGR1cmluZyB0aGUgbW9zdC1yZWNl bnQgSUVTRyBiYWxsb3RpbmcuICBBY3R1YWxseSwganVzdCBzZWFyY2hpbmcgZm9yIHRoZSB3b3Jk ICdwcm92aWRlZCcgeWllbGRzIHRoZSBzYW1lIHJlc3VsdC4gIEluIGVpdGhlciBjYXNlLCBhcyB3 ZSBhbGwga25vdywgdGhlIG1vc3QgcmVjZW50IGRpc2N1c3Npb24gZGlkbid0IHlpZWxkIHN1cHBv cnQgZm9yIHRoaXMgYXBwcm9hY2ggZWl0aGVyLg0KDQpBcyBJJ20gdW5hYmxlIHRvIGZpbmQgYW55 IHN1cHBvcnQgYW5kLCBpbiBmYWN0LCBmaW5kIHF1aXRlIHRoZSBvcHBvc2l0ZSwgSSBzdGFuZCBi eSBteSBjb25jZXJuIHRoYXQgdGhpcyBpcyBhbiBpbGxlZ2FsIHVzZSBvZiBZQU5HLg0KDQpLZW50 DQoNCg0KDQpSZXBvc3RpbmcgWUFORyBEb2N0b3IgcmV2aWV3IHRocmVhZCBmb3IgcmVmZXJlbmNl Og0KIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIveWFuZy1kb2N0b3JzL2N1 cnJlbnQvbXNnMDAwMzIuaHRtbA0KDQotIEhhcmkNCg0KT24gMzAvMDEvMjAxNywgMTU6MzMsICJL ZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgW3VwZGF0ZTog bm93IENDLWluZyB0aGUgeWFuZy1kb2N0b3IncyBsaXN0IV0NCiAgICANCiAgICBbK3lhbmctZG9j dG9yc10NCiAgICANCiAgICANCiAgICBIaSBYdWZlbmcsDQogICAgDQogICAgPiBJIHRoaW5rIHRo YXQgdGhlIGlzc3VlIHJhaXNlZCBieSBLZW50IGhhcyBiZWVuIGRpc2N1c3NlZCBtdWx0aXBsZSB0 aW1lcyBiZXR3ZWVuIHRoZQ0KICAgID4gYXV0aG9ycywgSTJSUyBXRywgYW5kIHNldmVyYWwgWWFu ZyBkb2N0b3JzIChNYXJ0aW4sIEFuZHksIGFuZCBMYWRhPykuIA0KICAgIA0KICAgIE15IHJlYWRp bmcgb2YgdGhlIHJlY2VudCBJMlJTIHRocmVhZCBjb21lcyB0byBhIGRpZmZlcmVudCBjb25jbHVz aW9uLiAgSXQgc2VlbXMgdGhhdA0KICAgIG1hbnkgd2VyZSBzdHJ1Z2dsaW5nIHdpdGggYmFzaWNz IHN1Y2ggYXMgaWYgdGhpcyBpcyBhIHN0YW5kYXJkIFlBTkcgbW9kdWxlIG9yIHNvbWV0aGluZw0K ICAgIGNvbnN0cmFpbmVkIHRvIGVwaGVtZXJhbC9JMlJTIHVzZSBvbmx5LiAgVGhlcmUgbWF5IGhh dmUgYmVlbiBkaXNjdXNzaW9ucyBiZWZvcmUsIGJ1dA0KICAgIGdpdmVuIHRoaXMgZGlzY29ubmVj dCwgSSBxdWVzdGlvbiB0aGVpciB2YWxpZGl0eS4gIFN0aWxsLCBpbiBjYXNlIEknbSBtaXNzaW5n IHNvbWV0aGluZw0KICAgIHN1YnRsZSwgcGxlYXNlIHBvaW50IG1lIHRvIHdoZXJlIGEgWUFORyBk b2N0b3IgYmxlc3NlZCB0aGUgJ3NlcnZlci1wcm92aWRlZCcgZmxhZywgDQogICAga25vd2luZyB0 aGF0IDEpIHRoaXMgbW9kdWxlIGlzIGZvciBnZW5lcmFsIHVzZSwgMikgaXQgcHJvbW90ZXMgbm9u LWNvbmZpZyB0byBjb25maWcsDQogICAgYW5kIDMpIGl0IGJyZWFrcyBzdGFuZGFyZCBvcGVyYXRp b25zIGFuZCB3b3JrZmxvd3MgKGUuZy4sIGJhY2t1cC9yZXN0b3JlKS4NCiAgICANCiAgICBBbHRl cm5hdGl2ZWx5LCBzaW5jZSBJIGp1c3QgQ0MtZWQgdGhlIFlBTkctZG9jdG9ycyBsaXN0LCBjYW4g c29tZW9uZSB0aGVyZSBxdWlja2x5DQogICAgdGVsbCBtZSB0aGF0IHRoaXMgaXMgcmVhbGx5IGEg c2FuY3Rpb25lZCBzb2x1dGlvbj8NCiAgICANCiAgICANCiAgICA+IFRoZSByZXN1bHQgb2YNCiAg ICA+IHRoZSBkaXNjdXNzaW9ucyB3YXMgdG8ga2VlcCB0aGUgY3VycmVudCAic2VydmVyLXByb3Zp ZGVkIiBhcyBhIGNvbXByb21pc2UsIGJlY2F1c2UNCiAgICA+IHRoZXJlIGhhZCBiZWVuIG5vIGlk ZWFsIHNvbHV0aW9uIGF2YWlsYWJsZSBzbyBmYXIuIA0KICAgIA0KICAgIFBlciA2MDg3YmlzIFNl Y3Rpb24gNS4yMywgdGhlIGN1cnJlbnQgb2ZmaWNpYWxseSBhY2NlcHRlZCBhcHByb2FjaCBmb3Ig cmVwb3J0aW5nIA0KICAgIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIHZh bHVlcyBpcyB0byBoYXZlIGEgc2VwYXJhdGUgY29uZmlnIGZhbHNlDQogICAgL2Zvby1zdGF0ZSB0 cmVlLiAgIFdoeSB3YXMgdGhpcyBub3QgY29uc2lkZXJlZCBhbiBhY2NlcHRhYmxlIHNvbHV0aW9u Pw0KICAgIA0KICAgIEp1bXBpbmcgYWhlYWQgb2YgdGhlIGV4cGVjdGVkIGFuc3dlciwgSSB1bmRl cnN0YW5kIHRoYXQgY29udHJvbGxlciBhcHBzIGxpa2UgT0RMDQogICAgaGF2ZSBjb25maWcvaW50 ZW50IHNlcnZpY2UtbGV2ZWwgbW9kZWxzIHRoYXQgZXNzZW50aWFsbHkgZGVmaW5lZCBvdmVybGF5 IG5ldHdvcmtzDQogICAgdGhhdCBuZWVkIHRvIHJlZmVyZW5jZSByZWFsIHVuZGVybGF5IG5ldHdv cmtzLiAgV2hpbGUgYXQgZmlyc3QgaXQgbWF5IHNlZW0gbGlrZQ0KICAgIGEgY2FzZSB3aGVyZSBh IGNvbmZpZyB0cnVlIG5vZGUgd291bGQgbmVlZCB0byBwb2ludCB0byBhIGNvbmZpZyBmYWxzZSBu b2RlLCBJIGRvbid0IA0KICAgIGJlbGlldmUgaXQncyB0aGF0IHdheSBhdCBhbGwuICBSYXRoZXIg SSB0aGluayB0aGF0IHRoZSBjb250cm9sbGVyIGFwcCwgd291bGQgaW1wb3J0DQogICAgKGFuZCBt ZXJnZS9kZS1kdXBsaWNhdGUpIHRoZSBuZXR3b3JrIGVsZW1lbnRzJyB0b3BvIG9wc3RhdGUgaW50 byBpdHMgZGF0YWJhc2UgYXMNCiAgICBjb25maWcgKG5vdCBvcHN0YXRlKSwgd2hpY2ggd291bGQg cmVzdWx0IGluIGNvbmZpZyB0cnVlIHBvaW50aW5nIHRvIGNvbmZpZyB0cnVlLg0KICAgIFRoZSBv bmx5IHRoaW5nIHRoYXQgbWF5IG5vdCBiZSBpZGVhbCBpcyB0aGUgY29udHJvbGxlciBhcHAgd291 bGRuJ3QgYmUgYWJsZSB0bw0KICAgIGRpZmZlcmVudGlhdGUgd2hpY2ggcGFydHMgb2YgdGhlIHRv cG8gbW9kZWwgaXQgaW1wb3J0ZWQgdmVyc3VzIGNyZWF0ZWQsIGFuZCBoZXJlDQogICAgaXMgd2hl cmUgYSAnc2VydmVyLXByb3ZpZGVkJyBmbGFnIG1pZ2h0IG1ha2Ugc2Vuc2UgYnV0LCBpbiB0aGlz IGNhc2UsIGl0IHNob3VsZA0KICAgIGJlIGFuIGF1Z21lbnRhdGlvbiBhZGRlZCBpbiBhdCB0aGUg Y29udHJvbGxlci1sZXZlbCBhcyBvcHBvc2VkIHRvIGJlaW5nIGluIHRoZQ0KICAgIGJhc2UgbW9k ZWwsIHJpZ2h0Pw0KICAgIA0KICAgIA0KICAgIFRoYW5rcywNCiAgICBLZW50DQogICAgDQogICAg DQogICAgDQogICAgDQogICAgDQoNCg0KDQoNCg0K From nobody Tue Jan 31 10:39:34 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BDD129FDB for ; Tue, 31 Jan 2017 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 J-wYRdvjEa4c for ; Tue, 31 Jan 2017 08:57:23 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 D86F6129FC5 for ; Tue, 31 Jan 2017 08:57:04 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id 11so170231017qkl.3 for ; Tue, 31 Jan 2017 08:57:04 -0800 (PST) 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=FMNq1xruyAZJ6SVOMy2ZVZxkX3XJUwkVDdCHnZEk2Lo=; b=ou0D8BNp/n9SEhwiWnUfC+qIm4r9j1ahwyoSsIcEc+uxRvkomMl5ae8P19e1pDLgGX vQ2eAO6+cKdP2umd+3+kqvYt3rgOBOZblWDTWBRagyeomuglacuIk44y/+1TyxMdf7u+ T4D+o9PyZqNvp5RheLHf9p5vGb7OecP/tKy/USGa+W/MAnKDhcAGDv+Q8Sw6rzRebsgE c4DWtFBjse2/V/NN5/1aZ0dWQNUtqGRxOXLjO7rQ3c6KVdZmQP8m9LhVylvDn9pSvPrz icikq7jKJ6oDQc8oWJPX2fDVh3eNjxEDbNZh6cX+EwI5ySE4/DFPukVAk4vDFzLzF72E GvhQ== 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=FMNq1xruyAZJ6SVOMy2ZVZxkX3XJUwkVDdCHnZEk2Lo=; b=CRExm82gcac5iNMqzQeEcuTEcM7clKKIZeZZtvkcgtFVC3r5Hq8/ZxAjDau+MgcnMS OQj1/nDRiM+Rf1AdFS7iM3nVgwLz1XsfQa45eflPLMouNTQrydoPYuJHrLSDaLNWTCGg izU5p5qonHsZyGkpthrc5Dd8sqG4ioDBth83I9JIlanzEf1Fo0apDBtcErMWRmjJMQiV sEvjFF8+ztlihvsoXxNuF9XKZEDb4aSC7yEXssJ+xIWA85DgJ6rFeo7ZBAW7imox7wX0 cDPYNfs6Rev3Y/PeiL+uZ8WKNdUFlvJxsOPPkkYB0Sk73IvgBEm6Sie6UASBVOlHTyte bg/Q== X-Gm-Message-State: AIkVDXJHnQ4r46xo0jCBkUIO7GaWlERXWwEh/LUhDsgvajblnKgYugYojaehx2GpYlUTrp7m5NQ8vKhcGAfF1w== X-Received: by 10.55.20.137 with SMTP id 9mr26724963qku.237.1485881823959; Tue, 31 Jan 2017 08:57:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 31 Jan 2017 08:57:03 -0800 (PST) In-Reply-To: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> From: Andy Bierman Date: Tue, 31 Jan 2017 08:57:03 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1144d2264bb2f4054766d2ba Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 10:39:32 -0800 Cc: "netmod-chairs@ietf.org" , Hariharan Ananthakrishnan , Xufeng Liu , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , Vishnu Pavan Beeram , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "yang-doctors@ietf.org" , Alexander Clemm , Alia Atlas , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:57:25 -0000 --001a1144d2264bb2f4054766d2ba Content-Type: text/plain; charset=UTF-8 Hi, I am concerned about different protocols deciding that the same YANG statement means 1 thing in protocol A and another in protocol B. The config=true statement is very clear in YANG. It is not defined in terms of protocol, but rather abstract configuration datastores. YANG says config=true means the node is part of configuration datastores. It is OK for protocol A to have access to datastores and protocol B to hide them, or protocol B has access to different datastores than A. But the YANG statements need to reflect the intent of the data model, not the protocols. There is no YANG rule that says config=false means read-only in every protocol. It doesn't say that at all. config=false also allows I2RS to write constraints that reference any node. Andy On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen wrote: > > Thanks Hari, > > That review was a while ago, and there is no support for this approach > from me of Andy there. I was hoping there was something more recent... > > Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for > Topology (10/1 to 10/14)" discussion in October 2015 in which Martin, > Juergen, and Andy continually say that this is a misuse of YANG. I can't > find any support for this approach there. [FWIW, that thread ends without > a resolution that I can see]. > > Strangely, the next time 'server-provided' is discussed is nearly 14 > months later, during the most-recent IESG balloting. Actually, just > searching for the word 'provided' yields the same result. In either case, > as we all know, the most recent discussion didn't yield support for this > approach either. > > As I'm unable to find any support and, in fact, find quite the opposite, I > stand by my concern that this is an illegal use of YANG. > > Kent > > > > Reposting YANG Doctor review thread for reference: > https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html > > - Hari > > On 30/01/2017, 15:33, "Kent Watsen" wrote: > > [update: now CC-ing the yang-doctor's list!] > > [+yang-doctors] > > > Hi Xufeng, > > > I think that the issue raised by Kent has been discussed multiple > times between the > > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?). > > My reading of the recent I2RS thread comes to a different conclusion. > It seems that > many were struggling with basics such as if this is a standard YANG > module or something > constrained to ephemeral/I2RS use only. There may have been > discussions before, but > given this disconnect, I question their validity. Still, in case I'm > missing something > subtle, please point me to where a YANG doctor blessed the > 'server-provided' flag, > knowing that 1) this module is for general use, 2) it promotes > non-config to config, > and 3) it breaks standard operations and workflows (e.g., > backup/restore). > > Alternatively, since I just CC-ed the YANG-doctors list, can someone > there quickly > tell me that this is really a sanctioned solution? > > > > The result of > > the discussions was to keep the current "server-provided" as a > compromise, because > > there had been no ideal solution available so far. > > Per 6087bis Section 5.23, the current officially accepted approach for > reporting > operational state for system-generated values is to have a separate > config false > /foo-state tree. Why was this not considered an acceptable solution? > > Jumping ahead of the expected answer, I understand that controller > apps like ODL > have config/intent service-level models that essentially defined > overlay networks > that need to reference real underlay networks. While at first it may > seem like > a case where a config true node would need to point to a config false > node, I don't > believe it's that way at all. Rather I think that the controller app, > would import > (and merge/de-duplicate) the network elements' topo opstate into its > database as > config (not opstate), which would result in config true pointing to > config true. > The only thing that may not be ideal is the controller app wouldn't be > able to > differentiate which parts of the topo model it imported versus > created, and here > is where a 'server-provided' flag might make sense but, in this case, > it should > be an augmentation added in at the controller-level as opposed to > being in the > base model, right? > > > Thanks, > Kent > > > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > --001a1144d2264bb2f4054766d2ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


I am concerned about= different protocols deciding that the same YANG statement
means = 1 thing in protocol A and another in protocol B.

T= he config=3Dtrue statement is very clear in YANG.
It is not defin= ed in terms of protocol, but rather abstract configuration datastores.
YANG says config=3Dtrue means the node is part of configuration datas= tores.

It is OK for protocol A to have access to d= atastores and protocol B to hide them,
or protocol B has access t= o different datastores than A.=C2=A0 But the YANG statements
need= to reflect the intent of the data model, not the protocols.

=
There is no YANG rule that says config=3Dfalse means read-only i= n every protocol.
It doesn't say that at all. config=3Dfalse = also allows I2RS to write constraints that
reference any node.


Andy



On Mon, = Jan 30, 2017 at 5:07 PM, Kent Watsen <kwatsen@juniper.net>= wrote:

Thanks Hari,

That review was a while ago, and there is no support for this approach from= me of Andy there.=C2=A0 I was hoping there was something more recent...
Searching 'server-provided' in the I2RS mailing list, I see the &qu= ot;WG LC for Topology (10/1 to 10/14)" discussion in October 2015 in w= hich Martin, Juergen, and Andy continually say that this is a misuse of YAN= G.=C2=A0 I can't find any support for this approach there.=C2=A0 [FWIW,= that thread ends without a resolution that I can see].

Strangely, the next time 'server-provided' is discussed is nearly 1= 4 months later, during the most-recent IESG balloting.=C2=A0 Actually, just= searching for the word 'provided' yields the same result.=C2=A0 In= either case, as we all know, the most recent discussion didn't yield s= upport for this approach either.

As I'm unable to find any support and, in fact, find quite the opposite= , I stand by my concern that this is an illegal use of YANG.

Kent



Reposting YANG Doctor review thread for reference:
=C2=A0https://www.ietf.org/m= ail-archive/web/yang-doctors/current/msg00032.html

- Hari

On 30/01/2017, 15:33, "Kent Watsen" <kwatsen@juniper.net> wrote:

=C2=A0 =C2=A0 [update: now CC-ing the yang-doctor's list!]

=C2=A0 =C2=A0 [+yang-doctors]


=C2=A0 =C2=A0 Hi Xufeng,

=C2=A0 =C2=A0 > I think that the issue raised by Kent has been discussed= multiple times between the
=C2=A0 =C2=A0 > authors, I2RS WG, and several Yang doctors (Martin, Andy= , and Lada?).

=C2=A0 =C2=A0 My reading of the recent I2RS thread comes to a different con= clusion.=C2=A0 It seems that
=C2=A0 =C2=A0 many were struggling with basics such as if this is a standar= d YANG module or something
=C2=A0 =C2=A0 constrained to ephemeral/I2RS use only.=C2=A0 There may have = been discussions before, but
=C2=A0 =C2=A0 given this disconnect, I question their validity.=C2=A0 Still= , in case I'm missing something
=C2=A0 =C2=A0 subtle, please point me to where a YANG doctor blessed the &#= 39;server-provided' flag,
=C2=A0 =C2=A0 knowing that 1) this module is for general use, 2) it promote= s non-config to config,
=C2=A0 =C2=A0 and 3) it breaks standard operations and workflows (e.g., bac= kup/restore).

=C2=A0 =C2=A0 Alternatively, since I just CC-ed the YANG-doctors list, can = someone there quickly
=C2=A0 =C2=A0 tell me that this is really a sanctioned solution?


=C2=A0 =C2=A0 > The result of
=C2=A0 =C2=A0 > the discussions was to keep the current "server-pro= vided" as a compromise, because
=C2=A0 =C2=A0 > there had been no ideal solution available so far.

=C2=A0 =C2=A0 Per 6087bis Section 5.23, the current officially accepted app= roach for reporting
=C2=A0 =C2=A0 operational state for system-generated values is to have a se= parate config false
=C2=A0 =C2=A0 /foo-state tree.=C2=A0 =C2=A0Why was this not considered an a= cceptable solution?

=C2=A0 =C2=A0 Jumping ahead of the expected answer, I understand that contr= oller apps like ODL
=C2=A0 =C2=A0 have config/intent service-level models that essentially defi= ned overlay networks
=C2=A0 =C2=A0 that need to reference real underlay networks.=C2=A0 While at= first it may seem like
=C2=A0 =C2=A0 a case where a config true node would need to point to a conf= ig false node, I don't
=C2=A0 =C2=A0 believe it's that way at all.=C2=A0 Rather I think that t= he controller app, would import
=C2=A0 =C2=A0 (and merge/de-duplicate) the network elements' topo opsta= te into its database as
=C2=A0 =C2=A0 config (not opstate), which would result in config true point= ing to config true.
=C2=A0 =C2=A0 The only thing that may not be ideal is the controller app wo= uldn't be able to
=C2=A0 =C2=A0 differentiate which parts of the topo model it imported versu= s created, and here
=C2=A0 =C2=A0 is where a 'server-provided' flag might make sense bu= t, in this case, it should
=C2=A0 =C2=A0 be an augmentation added in at the controller-level as oppose= d to being in the
=C2=A0 =C2=A0 base model, right?


=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Kent








_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors

--001a1144d2264bb2f4054766d2ba-- From nobody Tue Jan 31 10:39:38 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E616B129FD4; Tue, 31 Jan 2017 08:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hatpvqPHVXsl; Tue, 31 Jan 2017 08:59:52 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 19882129FD5; Tue, 31 Jan 2017 08:59:21 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id 123so126765508ybe.3; Tue, 31 Jan 2017 08:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=txksHULb2rI/ePua7y3qVkfQXqbjmdnoUe/ladiKCKE=; b=Z0ZgZMFtJKFhinh7iJxwlE7Ko0Ddu7qj/oieATE4lc7JOId09UT61HUJ8x512ox+cf wQ5Q7gVbA5VRLDeE25+6CdeX9U6TFEYgvfyxonf6WDd3DQqY41abq9Ji9tKzaMQ4MEEu Hz/6NBWg4rnXFq6GnzjxJh4W5tDv2Vfz7/GS7cD5FKoc0sGGEI+nqHbkerQfrEDUBrE4 KqROZBGKORIWSxR9L2Fu+BSUPdjQ6Qx3XYf+7L8/CSA04y2nVVmaWR997UBuEPUJg9JB JWP4mHGe6k1Rg2SBXjAeYCHz73a6O/5Z3GSJbNU5pDGRs5j2LIkgaWdrvEr6gsacS6mk X0Rw== 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=txksHULb2rI/ePua7y3qVkfQXqbjmdnoUe/ladiKCKE=; b=KjqP5l63/DgIZuIwWzB6/ZuhBV7Oi/ejikgy6ONQT+Fkh5sf72IReo0OMQbin7f6lA Fhvhd0t5CmDPj2N/i2NRPaUXeJ5eoAQxTC5jAG6VblZ1CyQm44SCY/CpWtjbx0avlN7y dRPbGkLpUhMX/gca+m0jMq34X0FHJEcsjhu/v1hAky8YQz6s1ESdy5oiY8aUxojM/i7x qT4EpDrFBXL/BSolaxs54/HLXFNG2zXWucmu2VYiu4SYMUwgJuVOOsqNI76WDXfiMKo1 vLZypDBphLiaG6ESvPIKOnkdWA8+wOM5PvGjmwim3Xky3ysOq5ukCKp5ItntvDiyNdGO xTFA== X-Gm-Message-State: AIkVDXKOZtLuQLBqFbis+Kr5hAbY2IiGCIgiTFo7nn3IAVy/uxCU8O27Za1k3cNXJ+WRkSbRxMfWnCj39wFZkA== X-Received: by 10.13.237.1 with SMTP id w1mr18116306ywe.291.1485881960195; Tue, 31 Jan 2017 08:59:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Tue, 31 Jan 2017 08:59:19 -0800 (PST) In-Reply-To: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> From: Alia Atlas Date: Tue, 31 Jan 2017 11:59:19 -0500 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=94eb2c0864a86a6bab054766dadf Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 10:39:32 -0800 Cc: "netmod-chairs@ietf.org" , Hariharan Ananthakrishnan , Xufeng Liu , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , Vishnu Pavan Beeram , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "yang-doctors@ietf.org" , Alexander Clemm , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:59:55 -0000 --94eb2c0864a86a6bab054766dadf Content-Type: text/plain; charset=UTF-8 Andy, It is quite clear that there is a technical concern here that wasn't adequately discussed or at least that the resulting conclusions were adequately documented. We are meeting today to talk through the technical issue and understand what our options are. I fully expect that the documents will need to be returned to the WG for improvement and clarification. I am waiting to do so until we've met today and have a bit more clarity for the WG in terms of what the technical options are. Regards, Alia On Tue, Jan 31, 2017 at 11:57 AM, Andy Bierman wrote: > Hi, > > > I am concerned about different protocols deciding that the same YANG > statement > means 1 thing in protocol A and another in protocol B. > > The config=true statement is very clear in YANG. > It is not defined in terms of protocol, but rather abstract configuration > datastores. > YANG says config=true means the node is part of configuration datastores. > > It is OK for protocol A to have access to datastores and protocol B to > hide them, > or protocol B has access to different datastores than A. But the YANG > statements > need to reflect the intent of the data model, not the protocols. > > There is no YANG rule that says config=false means read-only in every > protocol. > It doesn't say that at all. config=false also allows I2RS to write > constraints that > reference any node. > > > Andy > > > > On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen wrote: > >> >> Thanks Hari, >> >> That review was a while ago, and there is no support for this approach >> from me of Andy there. I was hoping there was something more recent... >> >> Searching 'server-provided' in the I2RS mailing list, I see the "WG LC >> for Topology (10/1 to 10/14)" discussion in October 2015 in which Martin, >> Juergen, and Andy continually say that this is a misuse of YANG. I can't >> find any support for this approach there. [FWIW, that thread ends without >> a resolution that I can see]. >> >> Strangely, the next time 'server-provided' is discussed is nearly 14 >> months later, during the most-recent IESG balloting. Actually, just >> searching for the word 'provided' yields the same result. In either case, >> as we all know, the most recent discussion didn't yield support for this >> approach either. >> >> As I'm unable to find any support and, in fact, find quite the opposite, >> I stand by my concern that this is an illegal use of YANG. >> >> Kent >> >> >> >> Reposting YANG Doctor review thread for reference: >> https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html >> >> - Hari >> >> On 30/01/2017, 15:33, "Kent Watsen" wrote: >> >> [update: now CC-ing the yang-doctor's list!] >> >> [+yang-doctors] >> >> >> Hi Xufeng, >> >> > I think that the issue raised by Kent has been discussed multiple >> times between the >> > authors, I2RS WG, and several Yang doctors (Martin, Andy, and >> Lada?). >> >> My reading of the recent I2RS thread comes to a different >> conclusion. It seems that >> many were struggling with basics such as if this is a standard YANG >> module or something >> constrained to ephemeral/I2RS use only. There may have been >> discussions before, but >> given this disconnect, I question their validity. Still, in case I'm >> missing something >> subtle, please point me to where a YANG doctor blessed the >> 'server-provided' flag, >> knowing that 1) this module is for general use, 2) it promotes >> non-config to config, >> and 3) it breaks standard operations and workflows (e.g., >> backup/restore). >> >> Alternatively, since I just CC-ed the YANG-doctors list, can someone >> there quickly >> tell me that this is really a sanctioned solution? >> >> >> > The result of >> > the discussions was to keep the current "server-provided" as a >> compromise, because >> > there had been no ideal solution available so far. >> >> Per 6087bis Section 5.23, the current officially accepted approach >> for reporting >> operational state for system-generated values is to have a separate >> config false >> /foo-state tree. Why was this not considered an acceptable solution? >> >> Jumping ahead of the expected answer, I understand that controller >> apps like ODL >> have config/intent service-level models that essentially defined >> overlay networks >> that need to reference real underlay networks. While at first it may >> seem like >> a case where a config true node would need to point to a config false >> node, I don't >> believe it's that way at all. Rather I think that the controller >> app, would import >> (and merge/de-duplicate) the network elements' topo opstate into its >> database as >> config (not opstate), which would result in config true pointing to >> config true. >> The only thing that may not be ideal is the controller app wouldn't >> be able to >> differentiate which parts of the topo model it imported versus >> created, and here >> is where a 'server-provided' flag might make sense but, in this case, >> it should >> be an augmentation added in at the controller-level as opposed to >> being in the >> base model, right? >> >> >> Thanks, >> Kent >> >> >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >> > > --94eb2c0864a86a6bab054766dadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,

It is quite clear that there is a= technical concern here that wasn't adequately discussed or at least
that the resulting conclusions were adequately documented.

We are meeting today to talk through the technical issue a= nd understand what our options are.
I fully expect that the docum= ents will need to be returned to the WG for improvement and clarification.<= /div>
I am waiting to do so until we've met today and have a bit mo= re clarity for the WG in terms of what
the technical options are.=

Regards,
Alia

On Tue, Jan 31, 2017 at 11:57 A= M, Andy Bierman <andy@yumaworks.com> wrote:
Hi,


I= am concerned about different protocols deciding that the same YANG stateme= nt
means 1 thing in protocol A and another in protocol B.

The config=3Dtrue statement is very clear in YANG.
<= div>It is not defined in terms of protocol, but rather abstract configurati= on datastores.
YANG says config=3Dtrue means the node is part of = configuration datastores.

It is OK for protocol A = to have access to datastores and protocol B to hide them,
or prot= ocol B has access to different datastores than A.=C2=A0 But the YANG statem= ents
need to reflect the intent of the data model, not the protoc= ols.

There is no YANG rule that says config=3Dfals= e means read-only in every protocol.
It doesn't say that at a= ll. config=3Dfalse also allows I2RS to write constraints that
ref= erence any node.


Andy


On Mon, Jan 30, 2017 at 5:07 PM, Kent Wat= sen <kwatsen@juniper.net> wrote:

Thanks Hari,

That review was a while ago, and there is no support for this approach from= me of Andy there.=C2=A0 I was hoping there was something more recent...
Searching 'server-provided' in the I2RS mailing list, I see the &qu= ot;WG LC for Topology (10/1 to 10/14)" discussion in October 2015 in w= hich Martin, Juergen, and Andy continually say that this is a misuse of YAN= G.=C2=A0 I can't find any support for this approach there.=C2=A0 [FWIW,= that thread ends without a resolution that I can see].

Strangely, the next time 'server-provided' is discussed is nearly 1= 4 months later, during the most-recent IESG balloting.=C2=A0 Actually, just= searching for the word 'provided' yields the same result.=C2=A0 In= either case, as we all know, the most recent discussion didn't yield s= upport for this approach either.

As I'm unable to find any support and, in fact, find quite the opposite= , I stand by my concern that this is an illegal use of YANG.

Kent



Reposting YANG Doctor review thread for reference:
=C2=A0https://www.ietf.org/m= ail-archive/web/yang-doctors/current/msg00032.html

- Hari

On 30/01/2017, 15:33, "Kent Watsen" <kwatsen@juniper.net> wrote:

=C2=A0 =C2=A0 [update: now CC-ing the yang-doctor's list!]

=C2=A0 =C2=A0 [+yang-doctors]


=C2=A0 =C2=A0 Hi Xufeng,

=C2=A0 =C2=A0 > I think that the issue raised by Kent has been discussed= multiple times between the
=C2=A0 =C2=A0 > authors, I2RS WG, and several Yang doctors (Martin, Andy= , and Lada?).

=C2=A0 =C2=A0 My reading of the recent I2RS thread comes to a different con= clusion.=C2=A0 It seems that
=C2=A0 =C2=A0 many were struggling with basics such as if this is a standar= d YANG module or something
=C2=A0 =C2=A0 constrained to ephemeral/I2RS use only.=C2=A0 There may have = been discussions before, but
=C2=A0 =C2=A0 given this disconnect, I question their validity.=C2=A0 Still= , in case I'm missing something
=C2=A0 =C2=A0 subtle, please point me to where a YANG doctor blessed the &#= 39;server-provided' flag,
=C2=A0 =C2=A0 knowing that 1) this module is for general use, 2) it promote= s non-config to config,
=C2=A0 =C2=A0 and 3) it breaks standard operations and workflows (e.g., bac= kup/restore).

=C2=A0 =C2=A0 Alternatively, since I just CC-ed the YANG-doctors list, can = someone there quickly
=C2=A0 =C2=A0 tell me that this is really a sanctioned solution?


=C2=A0 =C2=A0 > The result of
=C2=A0 =C2=A0 > the discussions was to keep the current "server-pro= vided" as a compromise, because
=C2=A0 =C2=A0 > there had been no ideal solution available so far.

=C2=A0 =C2=A0 Per 6087bis Section 5.23, the current officially accepted app= roach for reporting
=C2=A0 =C2=A0 operational state for system-generated values is to have a se= parate config false
=C2=A0 =C2=A0 /foo-state tree.=C2=A0 =C2=A0Why was this not considered an a= cceptable solution?

=C2=A0 =C2=A0 Jumping ahead of the expected answer, I understand that contr= oller apps like ODL
=C2=A0 =C2=A0 have config/intent service-level models that essentially defi= ned overlay networks
=C2=A0 =C2=A0 that need to reference real underlay networks.=C2=A0 While at= first it may seem like
=C2=A0 =C2=A0 a case where a config true node would need to point to a conf= ig false node, I don't
=C2=A0 =C2=A0 believe it's that way at all.=C2=A0 Rather I think that t= he controller app, would import
=C2=A0 =C2=A0 (and merge/de-duplicate) the network elements' topo opsta= te into its database as
=C2=A0 =C2=A0 config (not opstate), which would result in config true point= ing to config true.
=C2=A0 =C2=A0 The only thing that may not be ideal is the controller app wo= uldn't be able to
=C2=A0 =C2=A0 differentiate which parts of the topo model it imported versu= s created, and here
=C2=A0 =C2=A0 is where a 'server-provided' flag might make sense bu= t, in this case, it should
=C2=A0 =C2=A0 be an augmentation added in at the controller-level as oppose= d to being in the
=C2=A0 =C2=A0 base model, right?


=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Kent








_______________________________________________
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--94eb2c0864a86a6bab054766dadf-- From nobody Tue Jan 31 10:50:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0048412999C for ; Tue, 31 Jan 2017 10:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 M2wgmgu29lrW for ; Tue, 31 Jan 2017 10:50:22 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 531E4129570 for ; Tue, 31 Jan 2017 10:50:13 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id v77so1411201wmv.0 for ; Tue, 31 Jan 2017 10:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=bQbEvu5palFg0GUHohNsF0RPf3PbviieeX7encc9yTM=; b=ubvrIs8KcdW4DikBM06Ompz1TI5uzWI6vdozk54QSJmpxqpzatOHxdIRCio11+RKFC pNA6JO255xS80piGI+ESCP34E04NqvnbLR8rMuxhEkczFvoUhwmhn6E6XqelUP3BerS6 XM+Kw/Bk3EGSCOt9ZbXyVwURxHGBo7LnhqhE74GXe8vwj4zhVXRz58pqMClaFWBFD5Pg 7vL1CItTvXfbUQ20VdClg5laMYc+j6uypW+NaXT4XyRimv/3/9W+qIEjQjOHlaotik+D 1L6DyU2MZhdw3sboUYo/FH7q60VQae7c+UEXUhBduxZwWrBtg6BYDQU8c5bBXss6Sedc 4o6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=bQbEvu5palFg0GUHohNsF0RPf3PbviieeX7encc9yTM=; b=A+VQmSiphavORY9QaiwKDzytdkdcFXHqxdi4lDJ6PoDPHSCbpOaaiRMdFmOTQc4AVS ONvmg+60pBnWGWTm288OTNlqASwPb3zzI7YOFdGvj6ephtana0IFiUjwRXp2eWuImcSF QahA9fB/f2n6OVcjtDeK65H4qqzrBjlsBhxnXZalVGFRcb4/UCUtNWeaPRwhczRjzzRM gWsJHNTDpMuUfun/sdY6c16CAObZ1oOC9U7mSLCVy/nI1v6dxR4z5+TCasRt+Z3zJTxl b2Xf6Gu2xU58ct1knvoA0Z5jZ7yAUMiu/iynCRSe9wzBmBGMjRp8tYM7jYSlSCETg/5R fVvA== X-Gm-Message-State: AIkVDXIh1d+JYIt9VGzlQpT7QyXiE4fJ4cUC0gyEeRffHQXGsZtsl/n0kRueEZ/fC/QoWg== X-Received: by 10.223.129.4 with SMTP id 4mr29937697wrm.27.1485888611558; Tue, 31 Jan 2017 10:50:11 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341584.dip0.t-ipconnect.de. [91.52.21.132]) by smtp.gmail.com with ESMTPSA id o2sm29718696wra.42.2017.01.31.10.50.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 10:50:11 -0800 (PST) From: "Mehmet Ersue" To: Date: Tue, 31 Jan 2017 19:50:13 +0100 Message-ID: <01df01d27bf2$db90d5d0$92b28170$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJ78igmKJgWqACHQWqyDetIhDxy0Q== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0204.5890DC62.019F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: [yang-doctors] Too many recipients to the message WAS:FW: yang-doctors post from andy@yumaworks.com requires approval X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 18:50:29 -0000 FYI Mehmet -----Original Message----- From: yang-doctors [mailto:mailman-bounces@mail.ietf.org] On Behalf Of yang-doctors-owner@ietf.org Sent: Tuesday, January 31, 2017 5:57 PM To: yang-doctors-owner@ietf.org Subject: yang-doctors post from andy@yumaworks.com requires approval As list administrator, your authorization is requested for the following mailing list posting: List: yang-doctors@ietf.org From: andy@yumaworks.com Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network Reason: Too many recipients to the message At your convenience, visit: https://www.ietf.org/mailman/admindb/yang-doctors to approve or deny the request. From nobody Tue Jan 31 12:50:56 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794EA129A07; Tue, 31 Jan 2017 11:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.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 vqvv_vNNRWwH; Tue, 31 Jan 2017 11:43:52 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (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 AF7C1129A05; Tue, 31 Jan 2017 11:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1485891743; bh=xCffnbww/xoX9RSnhJ86tXzogzQJnZoMFL17D7lVJJQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yZgzvJLohH+yHGYTro9kNA0U4XkinaP8dknNzGesXvs3sUBzpjzAhCdnEytwwb76W 9pkX3bgWgWjgJP0YXd2Qh2d/d8khjjPw8GY6R8eXcM/eUVO/TX3Y7WB7VQ7gSOt3lB 7m3TKNtmJaAe3BOScT61DNT6WQkT8bPngvFlZbGQ= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_17CAB29A-6E24-4F51-A838-DDBE9DDD636B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 31 Jan 2017 14:42:45 -0500 Message-Id: References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 627, in=4766, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 12:50:54 -0800 Cc: "netmod-chairs@ietf.org" , Hariharan Ananthakrishnan , Xufeng Liu , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , Vishnu Pavan Beeram , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "yang-doctors@ietf.org" , Alexander Clemm , Alia Atlas , Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:43:54 -0000 --Apple-Mail=_17CAB29A-6E24-4F51-A838-DDBE9DDD636B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 > On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman = wrote: >=20 > Hi, >=20 >=20 > I am concerned about different protocols deciding that the same YANG = statement > means 1 thing in protocol A and another in protocol B. >=20 > The config=3Dtrue statement is very clear in YANG. > It is not defined in terms of protocol, but rather abstract = configuration datastores. > YANG says config=3Dtrue means the node is part of configuration = datastores. >=20 > It is OK for protocol A to have access to datastores and protocol B to = hide them, > or protocol B has access to different datastores than A. But the YANG = statements > need to reflect the intent of the data model, not the protocols. >=20 > There is no YANG rule that says config=3Dfalse means read-only in = every protocol. > It doesn't say that at all. config=3Dfalse also allows I2RS to write = constraints that > reference any node. >=20 >=20 > Andy >=20 >=20 >=20 > On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen > wrote: >=20 > Thanks Hari, >=20 > That review was a while ago, and there is no support for this approach = from me of Andy there. I was hoping there was something more recent... >=20 > Searching 'server-provided' in the I2RS mailing list, I see the "WG LC = for Topology (10/1 to 10/14)" discussion in October 2015 in which = Martin, Juergen, and Andy continually say that this is a misuse of YANG. = I can't find any support for this approach there. [FWIW, that thread = ends without a resolution that I can see]. >=20 > Strangely, the next time 'server-provided' is discussed is nearly 14 = months later, during the most-recent IESG balloting. Actually, just = searching for the word 'provided' yields the same result. In either = case, as we all know, the most recent discussion didn't yield support = for this approach either. >=20 > As I'm unable to find any support and, in fact, find quite the = opposite, I stand by my concern that this is an illegal use of YANG. >=20 > Kent >=20 >=20 >=20 > Reposting YANG Doctor review thread for reference: > = https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html = = >=20 > - Hari >=20 > On 30/01/2017, 15:33, "Kent Watsen" > wrote: >=20 > [update: now CC-ing the yang-doctor's list!] >=20 > [+yang-doctors] >=20 >=20 > Hi Xufeng, >=20 > > I think that the issue raised by Kent has been discussed = multiple times between the > > authors, I2RS WG, and several Yang doctors (Martin, Andy, and = Lada?). >=20 > My reading of the recent I2RS thread comes to a different = conclusion. It seems that > many were struggling with basics such as if this is a standard = YANG module or something > constrained to ephemeral/I2RS use only. There may have been = discussions before, but > given this disconnect, I question their validity. Still, in case = I'm missing something > subtle, please point me to where a YANG doctor blessed the = 'server-provided' flag, > knowing that 1) this module is for general use, 2) it promotes = non-config to config, > and 3) it breaks standard operations and workflows (e.g., = backup/restore). >=20 > Alternatively, since I just CC-ed the YANG-doctors list, can = someone there quickly > tell me that this is really a sanctioned solution? >=20 >=20 > > The result of > > the discussions was to keep the current "server-provided" as a = compromise, because > > there had been no ideal solution available so far. >=20 > Per 6087bis Section 5.23, the current officially accepted approach = for reporting > operational state for system-generated values is to have a = separate config false > /foo-state tree. Why was this not considered an acceptable = solution? >=20 > Jumping ahead of the expected answer, I understand that controller = apps like ODL > have config/intent service-level models that essentially defined = overlay networks > that need to reference real underlay networks. While at first it = may seem like > a case where a config true node would need to point to a config = false node, I don't > believe it's that way at all. Rather I think that the controller = app, would import > (and merge/de-duplicate) the network elements' topo opstate into = its database as > config (not opstate), which would result in config true pointing = to config true. > The only thing that may not be ideal is the controller app = wouldn't be able to > differentiate which parts of the topo model it imported versus = created, and here > is where a 'server-provided' flag might make sense but, in this = case, it should > be an augmentation added in at the controller-level as opposed to = being in the > base model, right? >=20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors = >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --Apple-Mail=_17CAB29A-6E24-4F51-A838-DDBE9DDD636B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy = Bierman <andy@yumaworks.com> wrote:

Hi,


I am concerned about different = protocols deciding that the same YANG statement
means= 1 thing in protocol A and another in protocol B.
The config=3Dtrue statement is very = clear in YANG.
It is not defined in terms of = protocol, but rather abstract configuration datastores.
YANG says config=3Dtrue means the node is part of = configuration datastores.

It is OK for protocol A to have access to datastores and = protocol B to hide them,
or protocol B has access = to different datastores than A.  But the YANG statements
need to reflect the intent of the data model, not the = protocols.

There= is no YANG rule that says config=3Dfalse means read-only in every = protocol.
It doesn't say that at all. config=3Dfalse = also allows I2RS to write constraints that
reference = any node.


Andy



On Mon, = Jan 30, 2017 at 5:07 PM, Kent Watsen <kwatsen@juniper.net> wrote:

Thanks Hari,

That review was a while ago, and there is no support for this approach = from me of Andy there.  I was hoping there was something more = recent...

Searching 'server-provided' in the I2RS mailing list, I see the "WG LC = for Topology (10/1 to 10/14)" discussion in October 2015 in which = Martin, Juergen, and Andy continually say that this is a misuse of = YANG.  I can't find any support for this approach there.  = [FWIW, that thread ends without a resolution that I can see].

Strangely, the next time 'server-provided' is discussed is nearly 14 = months later, during the most-recent IESG balloting.  Actually, = just searching for the word 'provided' yields the same result.  In = either case, as we all know, the most recent discussion didn't yield = support for this approach either.

As I'm unable to find any support and, in fact, find quite the opposite, = I stand by my concern that this is an illegal use of YANG.

Kent



Reposting YANG Doctor review thread for reference:
 https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

- Hari

On 30/01/2017, 15:33, "Kent Watsen" <kwatsen@juniper.net>= wrote:

    [update: now CC-ing the yang-doctor's list!]

    [+yang-doctors]


    Hi Xufeng,

    > I think that the issue raised by Kent has been = discussed multiple times between the
    > authors, I2RS WG, and several Yang doctors (Martin, = Andy, and Lada?).

    My reading of the recent I2RS thread comes to a different = conclusion.  It seems that
    many were struggling with basics such as if this is a = standard YANG module or something
    constrained to ephemeral/I2RS use only.  There may = have been discussions before, but
    given this disconnect, I question their validity.  = Still, in case I'm missing something
    subtle, please point me to where a YANG doctor blessed the = 'server-provided' flag,
    knowing that 1) this module is for general use, 2) it = promotes non-config to config,
    and 3) it breaks standard operations and workflows (e.g., = backup/restore).

    Alternatively, since I just CC-ed the YANG-doctors list, = can someone there quickly
    tell me that this is really a sanctioned solution?


    > The result of
    > the discussions was to keep the current = "server-provided" as a compromise, because
    > there had been no ideal solution available so far.

    Per 6087bis Section 5.23, the current officially accepted = approach for reporting
    operational state for system-generated values is to have a = separate config false
    /foo-state tree.   Why was this not considered = an acceptable solution?

    Jumping ahead of the expected answer, I understand that = controller apps like ODL
    have config/intent service-level models that essentially = defined overlay networks
    that need to reference real underlay networks.  While = at first it may seem like
    a case where a config true node would need to point to a = config false node, I don't
    believe it's that way at all.  Rather I think that = the controller app, would import
    (and merge/de-duplicate) the network elements' topo = opstate into its database as
    config (not opstate), which would result in config true = pointing to config true.
    The only thing that may not be ideal is the controller app = wouldn't be able to
    differentiate which parts of the topo model it imported = versus created, and here
    is where a 'server-provided' flag might make sense but, in = this case, it should
    be an augmentation added in at the controller-level as = opposed to being in the
    base model, right?


    Thanks,
    Kent








_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

_______________________________________________
yang-doctors= mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

= --Apple-Mail=_17CAB29A-6E24-4F51-A838-DDBE9DDD636B-- From nobody Tue Jan 31 12:51:00 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB158129A6D; Tue, 31 Jan 2017 12:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no 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 Q6T-tLSGEv4F; Tue, 31 Jan 2017 12:35:56 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 85DF3129489; Tue, 31 Jan 2017 12:35:55 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.16.251; From: "Susan Hares" To: "'Thomas Nadeau'" , "'Andy Bierman'" References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> In-Reply-To: Date: Tue, 31 Jan 2017 15:31:46 -0500 Message-ID: <019901d27c01$0b6d7520$22485f60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019A_01D27BD7.2298F3C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEMKHE3GKV1K7neXVfBkaMYbbCHfQKRk7WZAaACAfMBqSx+3AGHR3i0AeTE+gQBzhuJaAGEuYnsAOmOP8oBMYz1WgJapH8LAWoAo0eiS+NzQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 12:50:54 -0800 Cc: netmod-chairs@ietf.org, 'Hariharan Ananthakrishnan' , 'Xufeng Liu' , draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, 'Vishnu Pavan Beeram' , draft-ietf-i2rs-yang-l3-topology@ietf.org, yang-doctors@ietf.org, 'Alexander Clemm' , 'Alia Atlas' Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:35:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_019A_01D27BD7.2298F3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom and Andy: How would you suggest indicating configuration and operational state in ephemeral control plane data store? It is very useful to differentiate between the two in ephemeral state. Do you have a suggestion? Sue From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Tuesday, January 31, 2017 2:43 PM To: Andy Bierman Cc: Kent Watsen; netmod-chairs@ietf.org; Hariharan Ananthakrishnan; Xufeng Liu; draft-ietf-i2rs-yang-network-topo@ietf.org; i2rs-chairs@ietf.org; Vishnu Pavan Beeram; draft-ietf-i2rs-yang-l3-topology@ietf.org; yang-doctors@ietf.org; Alexander Clemm; Alia Atlas; Susan Hares Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network +1 On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman wrote: Hi, I am concerned about different protocols deciding that the same YANG statement means 1 thing in protocol A and another in protocol B. The config=true statement is very clear in YANG. It is not defined in terms of protocol, but rather abstract configuration datastores. YANG says config=true means the node is part of configuration datastores. It is OK for protocol A to have access to datastores and protocol B to hide them, or protocol B has access to different datastores than A. But the YANG statements need to reflect the intent of the data model, not the protocols. There is no YANG rule that says config=false means read-only in every protocol. It doesn't say that at all. config=false also allows I2RS to write constraints that reference any node. Andy On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen wrote: Thanks Hari, That review was a while ago, and there is no support for this approach from me of Andy there. I was hoping there was something more recent... Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for Topology (10/1 to 10/14)" discussion in October 2015 in which Martin, Juergen, and Andy continually say that this is a misuse of YANG. I can't find any support for this approach there. [FWIW, that thread ends without a resolution that I can see]. Strangely, the next time 'server-provided' is discussed is nearly 14 months later, during the most-recent IESG balloting. Actually, just searching for the word 'provided' yields the same result. In either case, as we all know, the most recent discussion didn't yield support for this approach either. As I'm unable to find any support and, in fact, find quite the opposite, I stand by my concern that this is an illegal use of YANG. Kent Reposting YANG Doctor review thread for reference: https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html - Hari On 30/01/2017, 15:33, "Kent Watsen" wrote: [update: now CC-ing the yang-doctor's list!] [+yang-doctors] Hi Xufeng, > I think that the issue raised by Kent has been discussed multiple times between the > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?). My reading of the recent I2RS thread comes to a different conclusion. It seems that many were struggling with basics such as if this is a standard YANG module or something constrained to ephemeral/I2RS use only. There may have been discussions before, but given this disconnect, I question their validity. Still, in case I'm missing something subtle, please point me to where a YANG doctor blessed the 'server-provided' flag, knowing that 1) this module is for general use, 2) it promotes non-config to config, and 3) it breaks standard operations and workflows (e.g., backup/restore). Alternatively, since I just CC-ed the YANG-doctors list, can someone there quickly tell me that this is really a sanctioned solution? > The result of > the discussions was to keep the current "server-provided" as a compromise, because > there had been no ideal solution available so far. Per 6087bis Section 5.23, the current officially accepted approach for reporting operational state for system-generated values is to have a separate config false /foo-state tree. Why was this not considered an acceptable solution? Jumping ahead of the expected answer, I understand that controller apps like ODL have config/intent service-level models that essentially defined overlay networks that need to reference real underlay networks. While at first it may seem like a case where a config true node would need to point to a config false node, I don't believe it's that way at all. Rather I think that the controller app, would import (and merge/de-duplicate) the network elements' topo opstate into its database as config (not opstate), which would result in config true pointing to config true. The only thing that may not be ideal is the controller app wouldn't be able to differentiate which parts of the topo model it imported versus created, and here is where a 'server-provided' flag might make sense but, in this case, it should be an augmentation added in at the controller-level as opposed to being in the base model, right? Thanks, Kent _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors ------=_NextPart_000_019A_01D27BD7.2298F3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom and Andy:

 

How would you suggest indicating configuration and operational state = in ephemeral control plane data store?  It is very useful to = differentiate between the two in ephemeral state.  Do you have a = suggestion?  

 

Sue

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, = January 31, 2017 2:43 PM
To: Andy Bierman
Cc: Kent = Watsen; netmod-chairs@ietf.org; Hariharan Ananthakrishnan; Xufeng Liu; = draft-ietf-i2rs-yang-network-topo@ietf.org; i2rs-chairs@ietf.org; Vishnu = Pavan Beeram; draft-ietf-i2rs-yang-l3-topology@ietf.org; = yang-doctors@ietf.org; Alexander Clemm; Alia Atlas; Susan = Hares
Subject: Re: [yang-doctors] proposed text to clarify use = of the ietf-network-topology and = ietf-network

 

+1

 

On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi,

 

 

I = am concerned about different protocols deciding that the same YANG = statement

means 1 thing in = protocol A and another in protocol B.

 

The config=3Dtrue statement is very clear in = YANG.

It is not defined in = terms of protocol, but rather abstract configuration = datastores.

YANG says = config=3Dtrue means the node is part of configuration = datastores.

 

It is OK for protocol A to have access to datastores = and protocol B to hide them,

or protocol B has access to different datastores than = A.  But the YANG statements

need to reflect the intent of the data model, not the = protocols.

 

There is no YANG rule that says config=3Dfalse means = read-only in every protocol.

It doesn't say that at all. config=3Dfalse also allows = I2RS to write constraints that

reference any node.

 

 

Andy

 

 

 

On Mon, = Jan 30, 2017 at 5:07 PM, Kent Watsen <kwatsen@juniper.net> wrote:


Thanks Hari,

That review was a while ago, = and there is no support for this approach from me of Andy there.  I = was hoping there was something more recent...

Searching = 'server-provided' in the I2RS mailing list, I see the "WG LC for = Topology (10/1 to 10/14)" discussion in October 2015 in which = Martin, Juergen, and Andy continually say that this is a misuse of = YANG.  I can't find any support for this approach there.  = [FWIW, that thread ends without a resolution that I can = see].

Strangely, the next time 'server-provided' is discussed is = nearly 14 months later, during the most-recent IESG balloting.  = Actually, just searching for the word 'provided' yields the same = result.  In either case, as we all know, the most recent discussion = didn't yield support for this approach either.

As I'm unable to = find any support and, in fact, find quite the opposite, I stand by my = concern that this is an illegal use of = YANG.

Kent



Reposting YANG Doctor review thread for = reference:
 https://www.ietf.org/mail-archive/web/yang-doctors/curr= ent/msg00032.html

- Hari

On 30/01/2017, 15:33, = "Kent Watsen" <kwatsen@juniper.net> = wrote:

    [update: now CC-ing the yang-doctor's = list!]

    [+yang-doctors]


    Hi = Xufeng,

    > I think that the issue raised by Kent = has been discussed multiple times between the
    > = authors, I2RS WG, and several Yang doctors (Martin, Andy, and = Lada?).

    My reading of the recent I2RS thread comes = to a different conclusion.  It seems that
    many = were struggling with basics such as if this is a standard YANG module or = something
    constrained to ephemeral/I2RS use only.  = There may have been discussions before, but
    given this = disconnect, I question their validity.  Still, in case I'm missing = something
    subtle, please point me to where a YANG = doctor blessed the 'server-provided' flag,
    knowing that = 1) this module is for general use, 2) it promotes non-config to = config,
    and 3) it breaks standard operations and = workflows (e.g., backup/restore).

    Alternatively, = since I just CC-ed the YANG-doctors list, can someone there = quickly
    tell me that this is really a sanctioned = solution?


    > The result of
    = > the discussions was to keep the current "server-provided" = as a compromise, because
    > there had been no ideal = solution available so far.

    Per 6087bis Section = 5.23, the current officially accepted approach for reporting
  =   operational state for system-generated values is to have a = separate config false
    /foo-state tree.   Why = was this not considered an acceptable solution?

    = Jumping ahead of the expected answer, I understand that controller apps = like ODL
    have config/intent service-level models that = essentially defined overlay networks
    that need to = reference real underlay networks.  While at first it may seem = like
    a case where a config true node would need to = point to a config false node, I don't
    believe it's that = way at all.  Rather I think that the controller app, would = import
    (and merge/de-duplicate) the network elements' = topo opstate into its database as
    config (not opstate), = which would result in config true pointing to config true.
  =   The only thing that may not be ideal is the controller app = wouldn't be able to
    differentiate which parts of the = topo model it imported versus created, and here
    is = where a 'server-provided' flag might make sense but, in this case, it = should
    be an augmentation added in at the = controller-level as opposed to being in the
    base model, = right?


    Thanks,
    = Kent








_________________________________= ______________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors<= o:p>

 

_______________________________________________
yang= -doctors mailing list
yang-doctors@ietf.org
https://www.i= etf.org/mailman/listinfo/yang-doctors

 

------=_NextPart_000_019A_01D27BD7.2298F3C0-- From nobody Tue Jan 31 13:01:52 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD0129AB3 for ; Tue, 31 Jan 2017 12:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 1woWeDudLmIC for ; Tue, 31 Jan 2017 12:50:40 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 368C2129A75 for ; Tue, 31 Jan 2017 12:50:40 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 11so177688762qkl.3 for ; Tue, 31 Jan 2017 12:50:40 -0800 (PST) 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=Rwp5gtqowUrQqCnN16O18CAZDJxrQFXWwNiUL3OXvs4=; b=oD+EedTfErpfTi6A6XsuMgLKMyCSP++kGpFhpSkSRyr+MwcLDdv6iKIj5K1gAtVoQD bsMjaZV6qS2p2WhNyfW1fqsaRzcu6lLw+1xiQEDUx6uPDvfNkuYoKYHZ078+XtqQpK8i QdbIHjn1Ji/eOL9TqfnqIywH44cBBrAA3AvUWepxutfHXKAxuwDLTCGK4S8wAB2jESee PJ6gqk59OnUbenDHllpFs0cLGwXfSBkBz3VxEvEk/qCscfH9ZaiZAvDR1+LG0i9k5+0a BC72FiXeThIqfE2+FeBMXYNQMNkMSS/5ASTqWuXsQbySgHWRaebN+/ckPbDHK94M6gfe TJaQ== 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=Rwp5gtqowUrQqCnN16O18CAZDJxrQFXWwNiUL3OXvs4=; b=P+tN8kBKIdlGCktBtt9dceMzCz7gXgKHM1SLEtygjxCbEZ0EW2TOC28ggsJ84nfAI0 e1rvFsJX7le7cMpQD3UsmIXfpDRLNFZYNby6wiONI1ksNnkwWW+qfiT188erudhlgZpN cRA+k1LP4jOt+xvB2naTwF6dfKEFlMghA8v55GlN8B64qTClgjF9jYpc3VORZrNSs7WS twlsbrvxC/wrICnh9lIJxstIwrXS8gj44j6GPpO14yslqtDiV8kVK02xAsXLIb8rkavb eZngaaJYbHxcNNpolEZSQmFurRhn3LilosNO+JYUqEJKADiIrgZwfFjO3ODlJIF+/uBU BnPg== X-Gm-Message-State: AIkVDXLLn8LcMEAGyF3ldDsHcedYCfZHqZ8g0klEctTIHk/JWRlIgAjdFMi2aJQm/QfZ1/HyfXPivdbQ7njZew== X-Received: by 10.55.210.135 with SMTP id f129mr28229536qkj.184.1485895839290; Tue, 31 Jan 2017 12:50:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 31 Jan 2017 12:50:38 -0800 (PST) In-Reply-To: <019901d27c01$0b6d7520$22485f60$@ndzh.com> References: <008a01d278a9$cd8cd250$68a676f0$@ndzh.com> <015f01d27acf$f42414f0$dc6c3ed0$@clemm.org> <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> <019901d27c01$0b6d7520$22485f60$@ndzh.com> From: Andy Bierman Date: Tue, 31 Jan 2017 12:50:38 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c04ec4cacb03105476a15cc Archived-At: X-Mailman-Approved-At: Tue, 31 Jan 2017 13:01:51 -0800 Cc: NetMod WG Chairs , Hariharan Ananthakrishnan , Xufeng Liu , draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, Vishnu Pavan Beeram , draft-ietf-i2rs-yang-l3-topology@ietf.org, YANG Doctors , Alexander Clemm , Alia Atlas Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:50:42 -0000 --94eb2c04ec4cacb03105476a15cc Content-Type: text/plain; charset=UTF-8 On Tue, Jan 31, 2017 at 12:31 PM, Susan Hares wrote: > Tom and Andy: > > > > How would you suggest indicating configuration and operational state in > ephemeral control plane data store? It is very useful to differentiate > between the two in ephemeral state. Do you have a suggestion? > > > I do not agree that the I2RS control plane datastore has any operational data in it. That data would be in the operational daatstore. The solution discussed many times was a YANG extension -- e.g., tagging a node as writable by I2RS extension writable { description "Argument indicates whether I2RS can write to the data node containing this statement. Also indicates I2RS conformance for the data node containing this statement. Default is false if this extension is not present."; } container some-node { i2rs:writable true; config false; description "I2RS can write to this container in its ephemeral datastore"; } container some-other-node { i2rs:writable false; config false; description "I2RS cannot write to this container in its ephemeral datastore"; } If config=true then node can also appear in the configuration datastores. Sue > Andy > > > *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] > *Sent:* Tuesday, January 31, 2017 2:43 PM > *To:* Andy Bierman > *Cc:* Kent Watsen; netmod-chairs@ietf.org; Hariharan Ananthakrishnan; > Xufeng Liu; draft-ietf-i2rs-yang-network-topo@ietf.org; > i2rs-chairs@ietf.org; Vishnu Pavan Beeram; draft-ietf-i2rs-yang-l3- > topology@ietf.org; yang-doctors@ietf.org; Alexander Clemm; Alia Atlas; > Susan Hares > *Subject:* Re: [yang-doctors] proposed text to clarify use of the > ietf-network-topology and ietf-network > > > > +1 > > > > On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman > wrote: > > > > Hi, > > > > > > I am concerned about different protocols deciding that the same YANG > statement > > means 1 thing in protocol A and another in protocol B. > > > > The config=true statement is very clear in YANG. > > It is not defined in terms of protocol, but rather abstract configuration > datastores. > > YANG says config=true means the node is part of configuration datastores. > > > > It is OK for protocol A to have access to datastores and protocol B to > hide them, > > or protocol B has access to different datastores than A. But the YANG > statements > > need to reflect the intent of the data model, not the protocols. > > > > There is no YANG rule that says config=false means read-only in every > protocol. > > It doesn't say that at all. config=false also allows I2RS to write > constraints that > > reference any node. > > > > > > Andy > > > > > > > > On Mon, Jan 30, 2017 at 5:07 PM, Kent Watsen wrote: > > > Thanks Hari, > > That review was a while ago, and there is no support for this approach > from me of Andy there. I was hoping there was something more recent... > > Searching 'server-provided' in the I2RS mailing list, I see the "WG LC for > Topology (10/1 to 10/14)" discussion in October 2015 in which Martin, > Juergen, and Andy continually say that this is a misuse of YANG. I can't > find any support for this approach there. [FWIW, that thread ends without > a resolution that I can see]. > > Strangely, the next time 'server-provided' is discussed is nearly 14 > months later, during the most-recent IESG balloting. Actually, just > searching for the word 'provided' yields the same result. In either case, > as we all know, the most recent discussion didn't yield support for this > approach either. > > As I'm unable to find any support and, in fact, find quite the opposite, I > stand by my concern that this is an illegal use of YANG. > > Kent > > > > Reposting YANG Doctor review thread for reference: > https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html > > - Hari > > On 30/01/2017, 15:33, "Kent Watsen" wrote: > > [update: now CC-ing the yang-doctor's list!] > > [+yang-doctors] > > > Hi Xufeng, > > > I think that the issue raised by Kent has been discussed multiple > times between the > > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?). > > My reading of the recent I2RS thread comes to a different conclusion. > It seems that > many were struggling with basics such as if this is a standard YANG > module or something > constrained to ephemeral/I2RS use only. There may have been > discussions before, but > given this disconnect, I question their validity. Still, in case I'm > missing something > subtle, please point me to where a YANG doctor blessed the > 'server-provided' flag, > knowing that 1) this module is for general use, 2) it promotes > non-config to config, > and 3) it breaks standard operations and workflows (e.g., > backup/restore). > > Alternatively, since I just CC-ed the YANG-doctors list, can someone > there quickly > tell me that this is really a sanctioned solution? > > > > The result of > > the discussions was to keep the current "server-provided" as a > compromise, because > > there had been no ideal solution available so far. > > Per 6087bis Section 5.23, the current officially accepted approach for > reporting > operational state for system-generated values is to have a separate > config false > /foo-state tree. Why was this not considered an acceptable solution? > > Jumping ahead of the expected answer, I understand that controller > apps like ODL > have config/intent service-level models that essentially defined > overlay networks > that need to reference real underlay networks. While at first it may > seem like > a case where a config true node would need to point to a config false > node, I don't > believe it's that way at all. Rather I think that the controller app, > would import > (and merge/de-duplicate) the network elements' topo opstate into its > database as > config (not opstate), which would result in config true pointing to > config true. > The only thing that may not be ideal is the controller app wouldn't be > able to > differentiate which parts of the topo model it imported versus > created, and here > is where a 'server-provided' flag might make sense but, in this case, > it should > be an augmentation added in at the controller-level as opposed to > being in the > base model, right? > > > Thanks, > Kent > > > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > --94eb2c04ec4cacb03105476a15cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 12:31 PM, Susan Hares <shares@ndzh.com> wrote:

Tom and And= y:

=C2=A0=

How would you suggest indicat= ing configuration and operational state in ephemeral control plane data sto= re?=C2=A0 It is very useful to differentiate between the two in ephemeral s= tate.=C2=A0 Do you have a suggestion? =C2=A0

=C2=A0

<= div>
I do not agree that the I2RS control plane datastore has= any operational data in it.
That data would be in the operationa= l daatstore.

The solution discussed many times was= a YANG extension -- e.g., tagging a node as writable by I2RS
=C2=A0 extension writable {
=C2=A0 =C2=A0 description=
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Argument indicates whether I2RS= can write to the data node containing this statement.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Also indicates I2RS conformance for the data node contain= ing this statement.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Default is false = if this extension is not present.";
=C2=A0 }

<= /div>
=C2=A0 container some-node {
=C2=A0 =C2=A0 =C2=A0i2rs:w= ritable true;
=C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 = =C2=A0 =C2=A0description "I2RS can write to this container in its ephe= meral datastore";
=C2=A0 }

=C2= =A0 container some-other-node {
=C2=A0 =C2=A0 =C2=A0i2rs:writable= false;
=C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0= =C2=A0description "I2RS cannot write to this container in its ephemer= al datastore";
=C2=A0 }

=C2= =A0
If config=3Dtrue then node can also appear in the configurati= on datastores.


Sue=


Andy
=C2= =A0

=C2=A0

=

From: Thom= as Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, January 31,= 2017 2:43 PM
To: Andy Bierman
Cc: Kent Watsen; netmod-chairs@ietf.org= ; Hariharan Ananthakrishnan; Xufeng Liu; draft-ietf-i2rs-yang-netw= ork-topo@ietf.org; i2rs-chairs@ietf.org; Vishnu Pavan Beeram; draft-ietf-i= 2rs-yang-l3-topology@ietf.org; yang-doctors@ietf.org; Alexander Clemm; Alia At= las; Susan Hares
Subject: Re: [yang-doctors] proposed text to cla= rify use of the ietf-network-topology and ietf-network=

=C2=A0

+1

=C2=A0=

On Jan 31, 2017:11:57 AM, at 11:57 AM, Andy Bierman &l= t;andy@yumaworks.co= m> wrote:

=C2= =A0

Hi,

=C2=A0

=C2=A0

I am concerne= d about different protocols deciding that the same YANG statement=

means 1 thing in protocol A and a= nother in protocol B.

=C2=A0

The config=3Dtrue s= tatement is very clear in YANG.

It is not defined in terms of protocol, but rather abstract configu= ration datastores.

YANG = says config=3Dtrue means the node is part of configuration datastores.

=C2=A0

It is OK for protocol A to have access to dat= astores and protocol B to hide them,

or protocol B has access to different datastores than A.=C2= =A0 But the YANG statements

need to reflect the intent of the data model, not the protocols.=

=C2=A0

=

There is no YANG rule that says config=3Dfalse = means read-only in every protocol.

It doesn't say that at all. config=3Dfalse also allows I2RS = to write constraints that

reference any node.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

= =C2=A0

On Mon, Jan 30, 2017 at 5:07 P= M, Kent Watsen <kwatsen@juniper.net> wrote:


Thanks Hari,

That review was a while ago, and there is no suppo= rt for this approach from me of Andy there.=C2=A0 I was hoping there was so= mething more recent...

Searching 'server-provided' in the I2= RS mailing list, I see the "WG LC for Topology (10/1 to 10/14)" d= iscussion in October 2015 in which Martin, Juergen, and Andy continually sa= y that this is a misuse of YANG.=C2=A0 I can't find any support for thi= s approach there.=C2=A0 [FWIW, that thread ends without a resolution that I= can see].

Strangely, the next time 'server-provided' is dis= cussed is nearly 14 months later, during the most-recent IESG balloting.=C2= =A0 Actually, just searching for the word 'provided' yields the sam= e result.=C2=A0 In either case, as we all know, the most recent discussion = didn't yield support for this approach either.

As I'm unable= to find any support and, in fact, find quite the opposite, I stand by my c= oncern that this is an illegal use of YANG.

Kent



Repo= sting YANG Doctor review thread for reference:
=C2=A0https://www.ietf.org/mail-archive/web/yang-doctors/curre= nt/msg00032.html

- Hari

On 30/01/2017, 15:33, "Kent = Watsen" <k= watsen@juniper.net> wrote:

=C2=A0 =C2=A0 [update: now CC-ing = the yang-doctor's list!]

=C2=A0 =C2=A0 [+yang-doctors]

=C2=A0 =C2=A0 Hi Xufeng,

=C2=A0 =C2=A0 > I think that the issue= raised by Kent has been discussed multiple times between the
=C2=A0 =C2= =A0 > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada= ?).

=C2=A0 =C2=A0 My reading of the recent I2RS thread comes to a di= fferent conclusion.=C2=A0 It seems that
=C2=A0 =C2=A0 many were struggli= ng with basics such as if this is a standard YANG module or something
= =C2=A0 =C2=A0 constrained to ephemeral/I2RS use only.=C2=A0 There may have = been discussions before, but
=C2=A0 =C2=A0 given this disconnect, I ques= tion their validity.=C2=A0 Still, in case I'm missing something
=C2= =A0 =C2=A0 subtle, please point me to where a YANG doctor blessed the '= server-provided' flag,
=C2=A0 =C2=A0 knowing that 1) this module is = for general use, 2) it promotes non-config to config,
=C2=A0 =C2=A0 and = 3) it breaks standard operations and workflows (e.g., backup/restore).
<= br>=C2=A0 =C2=A0 Alternatively, since I just CC-ed the YANG-doctors list, c= an someone there quickly
=C2=A0 =C2=A0 tell me that this is really a san= ctioned solution?


=C2=A0 =C2=A0 > The result of
=C2=A0 =C2= =A0 > the discussions was to keep the current "server-provided"= ; as a compromise, because
=C2=A0 =C2=A0 > there had been no ideal so= lution available so far.

=C2=A0 =C2=A0 Per 6087bis Section 5.23, the= current officially accepted approach for reporting
=C2=A0 =C2=A0 operat= ional state for system-generated values is to have a separate config false<= br>=C2=A0 =C2=A0 /foo-state tree.=C2=A0 =C2=A0Why was this not considered a= n acceptable solution?

=C2=A0 =C2=A0 Jumping ahead of the expected a= nswer, I understand that controller apps like ODL
=C2=A0 =C2=A0 have con= fig/intent service-level models that essentially defined overlay networks=C2=A0 =C2=A0 that need to reference real underlay networks.=C2=A0 While = at first it may seem like
=C2=A0 =C2=A0 a case where a config true node = would need to point to a config false node, I don't
=C2=A0 =C2=A0 be= lieve it's that way at all.=C2=A0 Rather I think that the controller ap= p, would import
=C2=A0 =C2=A0 (and merge/de-duplicate) the network eleme= nts' topo opstate into its database as
=C2=A0 =C2=A0 config (not ops= tate), which would result in config true pointing to config true.
=C2=A0= =C2=A0 The only thing that may not be ideal is the controller app wouldn&#= 39;t be able to
=C2=A0 =C2=A0 differentiate which parts of the topo mode= l it imported versus created, and here
=C2=A0 =C2=A0 is where a 'ser= ver-provided' flag might make sense but, in this case, it should
=C2= =A0 =C2=A0 be an augmentation added in at the controller-level as opposed t= o being in the
=C2=A0 =C2=A0 base model, right?


=C2=A0 =C2=A0= Thanks,
=C2=A0 =C2=A0 Kent








_________= ______________________________________
yang-doctors mailing listyang-doctors@ie= tf.org
https://www.ietf.org/mailman/listinfo/yang-doctors=

=C2=A0

=

_________________________________________= ______
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.= org/mailman/listinfo/yang-doctors

=C2=A0

=

--94eb2c04ec4cacb03105476a15cc-- From nobody Tue Jan 31 13:21:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6991295D8; Tue, 31 Jan 2017 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 c6aV5C5mqM-B; Tue, 31 Jan 2017 13:21:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C98171295BE; Tue, 31 Jan 2017 13:21:27 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 053E31AE012C; Tue, 31 Jan 2017 22:21:26 +0100 (CET) Date: Tue, 31 Jan 2017 22:21:25 +0100 (CET) Message-Id: <20170131.222125.1034220492840525689.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, vbeeram@juniper.net, yang-doctors@ietf.org, akatlas@gmail.com Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:21:29 -0000 Kent Watsen wrote: > [update: now CC-ing the yang-doctor's list!] > > [+yang-doctors] [trimming the Cc a bit to avoid the "Too many recipients" problem. I hope everyone still receives this reply] > > > Hi Xufeng, > > > I think that the issue raised by Kent has been discussed multiple > > times between the > > authors, I2RS WG, and several Yang doctors (Martin, Andy, and Lada?). > > My reading of the recent I2RS thread comes to a different conclusion. > It seems that > many were struggling with basics such as if this is a standard YANG > module or something > constrained to ephemeral/I2RS use only. There may have been > discussions before, but > given this disconnect, I question their validity. Still, in case I'm > missing something > subtle, please point me to where a YANG doctor blessed the > 'server-provided' flag, > knowing that 1) this module is for general use, 2) it promotes > non-config to config, > and 3) it breaks standard operations and workflows (e.g., > backup/restore). > > Alternatively, since I just CC-ed the YANG-doctors list, can someone > there quickly > tell me that this is really a sanctioned solution? I just re-read the old ML thread you referred to in another mail ("WG LC for Topology (10/1 to 10/14)", and I think it is pretty clear that from the YANG doctors point of view, this is not a "sanctioned solution". We pointed out the problems with the current design and suggested several alternative ways of handling this issue, including the traditional /foo and /foo-state solution that 6087bis recommends. This said, this problem was one of the reasons we now have draft-ietf-netmod-revised-datastores. Maybe one way to deal with this document is to use one of the traditional solutions for now, and then revisit this model once the work that has been started with draft-ietf-netmod-revised-datastores is finished. /martin From nobody Tue Jan 31 13:49:02 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592C6129545; Tue, 31 Jan 2017 13:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 CwWNJ0xsYpsh; Tue, 31 Jan 2017 13:49:00 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536591294A5; Tue, 31 Jan 2017 13:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/VFH5irRSdDUcC9GpClFovjmnibDrdBbj24tYk2c5DA=; b=hVIbE5z/QWDMocWFYrbpLNDf6zjo3wAdoS/otFuLj3VJGe8ZOkFxdaTvLAHkdUnCkoDf8KB+ce4ty5Q4hazT/swOX9/7n8mpffqe/P5iSynN04px9LD+6USGQl4NF1vY+UkVCqHvl3jRmZExSX6OcUD/2MqRY34CfOQFKJJVGOU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 31 Jan 2017 21:48:57 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 21:48:56 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network Thread-Index: AQHSeF003mrxpQG/YkWQXb+DOWQ2Z6FMYt4AgARMTQCAAHMegIAAYhGAgAATOYD//8SZAIAAAdSAgAHBOYD//7PfAA== Date: Tue, 31 Jan 2017 21:48:56 +0000 Message-ID: References: <6C3EE0E1-54E4-4DA3-8095-FC8F179F5005@juniper.net> <20170131.222125.1034220492840525689.mbj@tail-f.com> In-Reply-To: <20170131.222125.1034220492840525689.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR05MB2499; 7:6rOyUcsDbYe2Z2qEac5v0eh0PFy7vs82TMejJT1P8ULtIfEMXCgq0JUefM4JENzyvbSzZ85Qw7BbIkOk+z1I6cZcVbcjhHRZQs/B/sNKy2ZYaksXPHt2idhFx+cSQf0BYR/IDrw6oBkIDjM96SwdNJdrBOhI9br9AB6/SctErUg2nIK/UFRKA/riEWmI26/ijhz3W4sB+1B9HCOM+WZX3ocBLSQnEnqcmwsyLgPn+ys7SEe4WD1O/Pevc2KLB6W00wkGlL0KVFyQSPidJOfsbd+0s15oe9nHulNwMWZekKVvrUzpP2ldJFVn3tylOQFsFN9am0KJ0vjIOpFmdTPqyiwXtC35VhIMhJTIEJzHQ6Tc3YTNAmj8/J5N4iNNcXOZpVak7Dc7BB/GB4cXphYtkc3Jb16Sn7iT1hhKTdQRPK5gW0X82p5aGNJWULqUrZBsWt7O2MbQrzA8j5xJOainA9iw9NIF7lw3L2aG32q51Wsg38ogLOZ8S9jld7doD1oO3LHxW5hI2c4c+fKOl4Kesg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(199003)(189002)(2906002)(3280700002)(97736004)(4001350100001)(66066001)(83716003)(229853002)(5660300001)(33656002)(4326007)(39060400001)(8936002)(53936002)(3846002)(38730400001)(102836003)(36756003)(6116002)(110136003)(6512007)(54906002)(99286003)(83506001)(81166006)(7736002)(305945005)(77096006)(6486002)(189998001)(6436002)(122556002)(6916009)(6506006)(86362001)(8676002)(2950100002)(50986999)(230783001)(54356999)(3660700001)(76176999)(101416001)(68736007)(106356001)(93886004)(106116001)(25786008)(105586002)(92566002)(81156014)(82746002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: cd4aa152-310b-4c35-392e-08d44a22f527 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401079); SRVR:BN3PR05MB2499; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2499; x-forefront-prvs: 0204F0BDE2 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <722F34E4373B8542AB3BAE27CC0F6DBE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 21:48:56.6695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Cc: "netmod-chairs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" , "i2rs-chairs@ietf.org" , Vishnu Pavan Beeram , "yang-doctors@ietf.org" , "akatlas@gmail.com" Subject: Re: [yang-doctors] proposed text to clarify use of the ietf-network-topology and ietf-network X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:49:01 -0000 QWxsLA0KDQpUaGVyZSB3YXMgYSBtZWV0aW5nIHRvZGF5IGFtb25nc3QgYXV0aG9ycywgY2hhaXJz LCBhbmQgQURzLiAgSSBwYXJ0aWNpcGF0ZWQgbW9yZSBhcyBhIHRlY2huaWNhbCBleHBlcnQgdGhh biBhIGNvLWNoYWlyLiAgVGhlIG5ldC1uZXQgaXMgdGhhdCB0aGUgZHJhZnQgd2lsbCBiZSByZXR1 cm5lZCB0byB0aGUgV0cgYW5kIEkgc2lnbmVkIHVwIHRvIGZhY2lsaXRhdGUgYSBwcm9wZXIgc29s dXRpb24uICBJbW1lZGlhdGVseSBJJ20gZ29pbmcgdG8gbWVldCB3aXRoIHRoZSBhdXRob3JzIG9m ZmxpbmUgdG8gaGFtbWVyIG91dCBhIHdvcmthYmxlIHNvbHV0aW9uLCB3aGljaCB3aWxsIHRoZW4g YmUgYnJvdWdodCB0byB0aGUgSTJSUyBXRyBmb3IgcmF0aWZpY2F0aW9uLiAgVGhpcyBzaG91bGQg b2NjdXIgYmVmb3JlIHRoZSBlbmQgb2YgbmV4dCB3ZWVrLg0KDQpTdGF5IHR1bmVkIQ0KS2VudA0K DQoNCg==