From nobody Mon Oct 6 16:19:14 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1A1A888F; Mon, 6 Oct 2014 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sta9lVBAYSTI; Mon, 6 Oct 2014 16:19:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFE81A9046; Mon, 6 Oct 2014 16:19:02 -0700 (PDT) Received: from [10.100.150.125] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id 08FC328B3FB4; Mon, 6 Oct 2014 19:18:59 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D086F602-2250-48FF-8C2A-A8CF8F833ECE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> Date: Mon, 6 Oct 2014 16:18:58 -0700 Message-Id: References: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/HwWxaoKVqGsifW8KmJgA4CN6O0o Cc: jhaas@juniper.net, rtg-yang-coord@ietf.org, jeff.tantsura@ericsson.com, IETF Announcement List Subject: Re: [Rtg-yang-coord] New Non-WG Mailing List: Rtg-yang-coord X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:19:07 -0000 --Apple-Mail=_D086F602-2250-48FF-8C2A-A8CF8F833ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What is the initial list admin password? On Oct 6, 2014:3:32 PM, at 3:32 PM, IETF Secretariat = wrote: > A new IETF non-working group email list has been created. >=20 > List address: rtg-yang-coord@ietf.org > Archive: http://www.ietf.org/mail-archive/web/rtg-yang-coord/ > To subscribe: https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > Purpose: >=20 > The rtg-yang-coord mailing list will provide a forum for coordination = of the development of YANG models being worked on for Routing, in order = to provide a consistent view to the NMS. The intended participants are = people active in Routing working groups and interested in the associated = YANG models, and YANG experts assisting with Routing YANG models. While = this list will help with the synchronization, WGs with responsibility = for core routing protocols are expected to also be responsible for the = development of YANG models for those=20 > protocols.=20 >=20 >=20 > For additional information, please contact the list administrators. >=20 --Apple-Mail=_D086F602-2250-48FF-8C2A-A8CF8F833ECE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUMyNiAAoJEPcO+I7eiUJZH8YP/37JtgBQAcdh/rCuUhhDKF41 eUTiIYOBs3nKqv1jyaZXTIPzlXPiRaMHdl82qrQ0NKOlbePwNG+R4z5tJdrOqnIs 9GouM5jLXBcpuOrH1yjaLSb8fyND/eaPT0yGd9WugnuPmf4NQr3A4TZYiCwfSmPf RJMbz4SHqsKpXRGc8utqL4APClwNOW6BrGU4w1SLUqycHNgYBXqa2hlzb0vT81Oe aiH7OH4YOj9XoS3Nn0iJFAupr6PqCd90ouw/9oGIb0DOJ3r1K6tUDaGssHlNNCdL uAEudx9TKdfZDOKTGFIz6AEGHOD7VvqwAQbOQjJuGerh2xkLd8Yyelln0K3TeCCn L6IXHkJ/aUhhq+Jr8GZVY0RL1AT7k539jSoVmB883w/lZEmi9AMq2kjGEwQbLdax 2ZH90eh0112j8RdaLue5ua0JaiWJ34fpDPlpMatLj2VlZFNVkVBha/ND1SuyeoHS w31KSYgEabCMrdxuoOUmI6cjHVYq4MWgwj2jwB5UtFLlPn8WB5GsWDd6ze/NCeVa daW+hSBNqa6V/MLAMMC2n5eJPFlk1QMCpgeRJa0vYmMcgSQMqEoXjoZmsg8kbStf aau8m19CYuOqBuy1AZHRdlEm4dY+MIwWKSOI0DOkjx8j3RAkgufr98BZVoCAvrTo sQV2F4xr5VJgtIajO4cR =a1en -----END PGP SIGNATURE----- --Apple-Mail=_D086F602-2250-48FF-8C2A-A8CF8F833ECE-- From nobody Mon Oct 6 16:46:39 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1951A8BB7; Mon, 6 Oct 2014 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HHOouA_Tf528; Mon, 6 Oct 2014 15:32:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFFC1A6FFA; Mon, 6 Oct 2014 15:32:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006223256.19159.32181.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 15:32:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/UejJcKIjSlisVbm3-cMYimY0gYs X-Mailman-Approved-At: Mon, 06 Oct 2014 16:46:37 -0700 Cc: jhaas@juniper.net, tnadeau@lucidvision.com, jeff.tantsura@ericsson.com, rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] New Non-WG Mailing List: Rtg-yang-coord X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:32:58 -0000 A new IETF non-working group email list has been created. List address: rtg-yang-coord@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-yang-coord/ To subscribe: https://www.ietf.org/mailman/listinfo/rtg-yang-coord Purpose: The rtg-yang-coord mailing list will provide a forum for coordination of the development of YANG models being worked on for Routing, in order to provide a consistent view to the NMS. The intended participants are people active in Routing working groups and interested in the associated YANG models, and YANG experts assisting with Routing YANG models. While this list will help with the synchronization, WGs with responsibility for core routing protocols are expected to also be responsible for the development of YANG models for those protocols. For additional information, please contact the list administrators. From nobody Sat Oct 11 08:38:45 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11031A6F47 for ; Sat, 11 Oct 2014 08:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 KOQkpWlFgjYI for ; Sat, 11 Oct 2014 08:38:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175E71A6F45 for ; Sat, 11 Oct 2014 08:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5616; q=dns/txt; s=iport; t=1413041921; x=1414251521; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=f2xmlvif0gQbzeYVC7K7L6QuvSZRMiX2JgNABks+Pqg=; b=NuYPH+sqqEIlIVkm+FMG++7h6r7QuPPHdZ708V2P9rHNPk0hBYTUQdtd lPfldqCoWY6JTDaJVkDgTx/2O2OKDHBUhDyuJA/7zr/ylACT3JAy5+2dZ a7O0ZK7yCc+5ouFXZjbYynQs9PT0pBN5gCzA9lJhyn5Q8WvWNWastfJga I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAKdOOVStJssW/2dsb2JhbABfAYNgWIhhwmeHTQKBGAF7hAMBAQEEeA0EHAMBAgoWCAcJAwIBAgE0BwIIEwYCAQEFiDUNvk8BAQEBAQEEAQEBAQEBAQEakDMXAQaERQWPX4kegXyCUoEuEYYnii2DfoN5Oy8BgkkBAQE X-IronPort-AV: E=Sophos;i="5.04,698,1406592000"; d="scan'208,217";a="206626153" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 11 Oct 2014 15:38:39 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9BFccTI023459 for ; Sat, 11 Oct 2014 15:38:39 GMT Message-ID: <54394EFE.2030904@cisco.com> Date: Sat, 11 Oct 2014 17:38:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Rtg-yang-coord@ietf.org References: <54394ECC.5080206@cisco.com> In-Reply-To: <54394ECC.5080206@cisco.com> X-Forwarded-Message-Id: <54394ECC.5080206@cisco.com> Content-Type: multipart/alternative; boundary="------------090207070404020803010304" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/t-wx6nSEFbUH9Nc7OtyYmc2vRt4 Subject: [Rtg-yang-coord] Fwd: YANG Advice and Editing Session at this coming IETF X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:38:44 -0000 This is a multi-part message in MIME format. --------------090207070404020803010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: YANG Advice and Editing Session at this coming IETF Date: Sat, 11 Oct 2014 17:37:48 +0200 From: Benoit Claise To: NETMOD Working Group Dear all, Like at the IETF 90 , we will be organizing a "YANG Advice and Editing Session" at this coming IETF meeting. *This is your chance *to get feedback from the YANG doctors in order to improve your YANG models. *Date and time*: Sunday, Nov9, 14:00-17:00 *Description*: At the IETF and in the industry in general, we observe a growing interest for configuration management with YANG modules. On Sunday afternoon, the YANG doctors will be available to provide advice on your YANG models. This session is not a tutorial on how to design YANG models and use NETCONF, but a place to get feedback on your data modeling questions, language usage questions, tools to use, etc... The afternoon will be dedicated to different time slots based on the number of requests and available YANG doctors. *Advanced participation notice* to bclaise@cisco.com and netmod-chairs@tools.ietf.org is welcomed. The details (basically this invite) will be posted soon under http://www.ietf.org/meeting/91/tutorials.html Tom Nadeau, NETMOD co-chair, might try to organize an extra ad-hoc session towards the end of the IETF week. Contact us (bclaise@cisco.com and netmod-chairs@tools.ietf.org ) if interested. Regards, Benoit --------------090207070404020803010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: YANG Advice and Editing Session at this coming IETF
Date: Sat, 11 Oct 2014 17:37:48 +0200
From: Benoit Claise <bclaise@cisco.com>
To: NETMOD Working Group <netmod@ietf.org>


Dear all,

Like at the IETF 90, we will be organizing a "YANG Advice and Editing Session" at this coming IETF meeting.

This is your chance to get feedback from the YANG doctors in order to improve your YANG models.

Date and time: Sunday, Nov9, 14:00-17:00

Description: At the IETF and in the industry in general, we observe a growing interest for configuration management with YANG modules. On Sunday afternoon, the YANG doctors will be available to provide advice on your YANG models. This session is not a tutorial on how to design YANG models and use NETCONF, but a place to get feedback on your data modeling questions, language usage questions, tools to use, etc...
The afternoon will be dedicated to different time slots based on the number of requests and available YANG doctors.

Advanced participation notice to bclaise@cisco.com and netmod-chairs@tools.ietf.org is welcomed.

The details (basically this invite) will be posted soon under http://www.ietf.org/meeting/91/tutorials.html

Tom Nadeau, NETMOD co-chair, might try to organize an extra ad-hoc session towards the end of the IETF week. Contact us (bclaise@cisco.com and netmod-chairs@tools.ietf.org) if interested.

Regards, Benoit


--------------090207070404020803010304-- From nobody Mon Oct 13 01:35:25 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778991A1B53; Mon, 13 Oct 2014 01:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 BoxULY_Glg1G; Mon, 13 Oct 2014 01:35:19 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2751A02A0; Mon, 13 Oct 2014 01:35:16 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id h18so9582329igc.6 for ; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=KaPvzmcmq9//1h6/BCQ/NfRE5nG8LKK5vC6Djzp+D9E=; b=nmxVqlJYCby2AWO8YOXwKdPhI8LIVp1cfHbQVLe8N4MpzWOOObenC+ZljojmJt4qAg 1sVTiotkud52c5UmVU8Og9CQg+/iTQnWA5t2ME2FA5YCyW79E1LKHsfue6j1BwOkXYCW kxIymsXmah2NoziwvXAkrpKf3V9ys/qfH0B38wskkXTUMbHPw1pfNRmhkPTeAIPNSKmd J0POmoR7FAXOWDXEUV46pnH5phegoOLsTGzAOGrGKtWuI+tMFBfar7hIQTjWUAF7E6kD rM26Hb/3qSKsYGhqMlSAzzxaQFvU3CmuGWvumAHAZftXtqvV++AmOEiXtxTuM/tZCpNy J57A== MIME-Version: 1.0 X-Received: by 10.42.90.80 with SMTP id j16mr33236303icm.27.1413189315666; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.90.105 with HTTP; Mon, 13 Oct 2014 01:35:15 -0700 (PDT) In-Reply-To: <20141010045652.15131.78592.idtracker@ietfa.amsl.com> References: <20141010045652.15131.78592.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 14:05:15 +0530 X-Google-Sender-Auth: rmrRP6Z2Xg57IioS_aTzV3cqf4U Message-ID: From: Dhruv Dhody To: "pce@ietf.org" , Rtg-yang-coord@ietf.org, draft-pkd-pce-pcep-yang@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/00NO1ewpw9p3HfWOFnmeTjg7rks Subject: [Rtg-yang-coord] Fwd: New Version Notification for draft-pkd-pce-pcep-yang-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 08:35:22 -0000 Hi All, We have submitted a new I.D. that defines a base YANG module for PCEP as per RFC5440. Please provide your feedback on the draft. Regards, Dhruv PS. Once we have initial consensus on the base we would like to work on augmenting the YANG module for PCEP extensions. If you are interested in this work do get in touch. ---------- Forwarded message ---------- From: Date: Fri, Oct 10, 2014 at 10:26 AM Subject: New Version Notification for draft-pkd-pce-pcep-yang-00.txt To: Rohit Pobbathi , Vinod KumarS , Jonathan Hardwick , Dhruv Dhody A new version of I-D, draft-pkd-pce-pcep-yang-00.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-pkd-pce-pcep-yang Revision: 00 Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Document date: 2014-10-09 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-pkd-pce-pcep-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Htmlized: http://tools.ietf.org/html/draft-pkd-pce-pcep-yang-00 Abstract: This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration data and state data (status information and counters for the collection of statistics). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Oct 16 15:56:55 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022731A8AFA; Thu, 16 Oct 2014 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZoDRnkMQjRQ9; Thu, 16 Oct 2014 15:56:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3101A8AFD; Thu, 16 Oct 2014 15:56:50 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 90ADF28C601B; Thu, 16 Oct 2014 18:56:49 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 16 Oct 2014 18:56:40 -0400 Message-Id: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hCLDI0mMHcL9ZWvR8G56NhgMKZE Cc: rtg-yang-coord@ietf.org, "rtg-bfd@ietf.org" Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:56:53 -0000 --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 Cross-posting to rtg-yang-coord list. --Tom On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) = wrote: > Dear BFD WG, >=20 > Since IETF90 in Toronto, many have expressed interest in BFD Yang = Models. >=20 > I'd like to use this email to notify the BFD WG that Jeff and I have = connected interested members to form a design group for defining BFD = Yang Models. >=20 > Members are: >=20 > Editors: > Vero Zheng (vero.zheng@huawei.com) > Reshad Rahman (rrahman@cisco.com) >=20 > Co-authors: > Mahesh Jethanandani (mjethanandani@gmail.com) > Santosh P K (santoshpk@juniper.net) >=20 > Contributors: > Sam Aldrin (aldrin.ietf@gmail.com) > Tissa Senevirathne (tsenevir@cisco.com) >=20 > The members have been virtually meeting up bi-weekly and working = through the designs at the moment. We expect a -00 document to be = published by them once they reach a certain point. >=20 > Thanks! >=20 > -Nobo & Jeff >=20 >=20 --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQE0oAAoJEPcO+I7eiUJZgiIQALiwdRG3lSDsVr71RWAb+W0c NAlSuJzbFe0kv+CGFtftT3yliynnIZaoODoDjD7h79iSr+s2EWT/QYwNtOgXWZXn fM4Z11s7v0gPLT0CAB4mG/vDV2Stb4+Lhwo1NmeXnqs/7tkaP/7GVj5+jWJShP7c XZa37PYfaMAyLMeSBKP3duoQtI5N9l53gbV0XCsyBqI5nT7hnkuOf7fSo0P3hqMs 1JnIcZfSU4r3VXASNChi1cnsAzECgYRslsCugzBfVNUFqLBUzOMwaxlpiurIDfCN klNM7nixG3vX0zok7NR3XcbpC/e6F1Cj34cmbBxO6EG/47MkY8eN0YPcMMYnZfo/ 1p5yc1/om+KmqaJ/XNhcO5zDJLlOMQBRqnrDCxGU8RITZVe6qIC9Sni+8xeJ77u8 kybEqhinDnJqKVULGAGdijrU9toFWIplXKhEoFwF5ZeLanB0qJNCjLHnklvWMxdu W0MSoF1JgmCIkX0svNmZi00hyQlDCJitktobewFJ94qyS+hku+z2gXfWWoSxhx6Q SrtJuUnN1CjYI4BaHTUH6NC2GclKf+aGbD0RHdeCMLT56Gqbh2oZvWmytNiUWXVW Rc0FpWhN0ei55QPdao985jCLTE1aSHcSBKt9yy3YfRWVF+1Bj8Gb+RMUysD/Ivxp HMpb+ODX6g4SEwnGJN8r =/Rwd -----END PGP SIGNATURE----- --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE-- From nobody Fri Oct 17 01:09:26 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7A1A9107; Fri, 17 Oct 2014 01:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ecw306xNAbPG; Fri, 17 Oct 2014 01:09:22 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862971A9103; Fri, 17 Oct 2014 01:09:22 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rd18so263183iec.8 for ; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=afxhb0Q22/6RwxFDLIe+y0Pqfj9TsBVc5jggNFes6+0=; b=mRR6wa21tkZWE5Bwy6M6Gf5UiunYHOFYgwbXzKxPhTQpUH0VPTodMVD2b9VU7vHq1Q ov3qmNedSTj12tMkoZM6GGsCzbi3j+9t6dbxKmCkg0wvgqRtP/hmUUxbfXa77ZWf5EPt mpvi0XElCE8WdQescjJwm+N0QOS8LwC71Gr+Em0zGRJ0zglFfZFHUJJ2VTEJVZ2PZJGc c/G9rLsjPKn1ZIN0Vm2j9ZplgrsOI/71dr/FCjngvBFvGc0BWFbzN/OG/ZqGX9PrUzJp 1gr1sbWbnip9VOskbl7S34XxjqEiwjdqKKgTFjJB2nXprlI2OgR5qsufBr7sI+X7Sk6M dLBA== MIME-Version: 1.0 X-Received: by 10.42.20.195 with SMTP id h3mr851242icb.59.1413533361858; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) In-Reply-To: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> Date: Fri, 17 Oct 2014 10:09:21 +0200 X-Google-Sender-Auth: weiNNL_fwdCqw9HA7xFx0jV6pvk Message-ID: From: Robert Raszuk To: "Thomas D. Nadeau" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/dsPl9slP5KZsdxyO6P3Yf3JYBQA Cc: rtg-yang-coord@ietf.org, "Nobo Akiya \(nobo\)" , "rtg-bfd@ietf.org" Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 08:09:24 -0000 Hi Tom, I assume this work will be under the general OAM YANG model correct ? http://tools.ietf.org/html/draft-tissa-netmod-oam-01 Thx, R. On Fri, Oct 17, 2014 at 12:56 AM, Thomas D. Nadeau wrote: > > Cross-posting to rtg-yang-coord list. > > --Tom > > > On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) wrote: > >> Dear BFD WG, >> >> Since IETF90 in Toronto, many have expressed interest in BFD Yang Models. >> >> I'd like to use this email to notify the BFD WG that Jeff and I have connected interested members to form a design group for defining BFD Yang Models. >> >> Members are: >> >> Editors: >> Vero Zheng (vero.zheng@huawei.com) >> Reshad Rahman (rrahman@cisco.com) >> >> Co-authors: >> Mahesh Jethanandani (mjethanandani@gmail.com) >> Santosh P K (santoshpk@juniper.net) >> >> Contributors: >> Sam Aldrin (aldrin.ietf@gmail.com) >> Tissa Senevirathne (tsenevir@cisco.com) >> >> The members have been virtually meeting up bi-weekly and working through the designs at the moment. We expect a -00 document to be published by them once they reach a certain point. >> >> Thanks! >> >> -Nobo & Jeff >> >> > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Fri Oct 17 05:48:09 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769E31ACD48; Fri, 17 Oct 2014 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wanssGdMnbNb; Fri, 17 Oct 2014 05:48:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE21ACD4F; Fri, 17 Oct 2014 05:48:02 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 3385E28C6E72; Fri, 17 Oct 2014 08:48:02 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 08:47:50 -0400 Message-Id: References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/JBwF7YKx-S__QmgtgfTjuBosVDY Cc: rtg-yang-coord@ietf.org, "Nobo Akiya \(nobo\)" , "rtg-bfd@ietf.org" Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:48:04 -0000 --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That depends on how this relates to real implementation. People = need to sit down and iterate on this, as well as implement these models = to ensure they actually work. --Tom > Hi Tom, >=20 > I assume this work will be under the general OAM YANG model correct ? >=20 > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 >=20 > Thx, > R. >=20 > On Fri, Oct 17, 2014 at 12:56 AM, Thomas D. Nadeau > wrote: >>=20 >> Cross-posting to rtg-yang-coord list. >>=20 >> --Tom >>=20 >>=20 >> On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) = wrote: >>=20 >>> Dear BFD WG, >>>=20 >>> Since IETF90 in Toronto, many have expressed interest in BFD Yang = Models. >>>=20 >>> I'd like to use this email to notify the BFD WG that Jeff and I have = connected interested members to form a design group for defining BFD = Yang Models. >>>=20 >>> Members are: >>>=20 >>> Editors: >>> Vero Zheng (vero.zheng@huawei.com) >>> Reshad Rahman (rrahman@cisco.com) >>>=20 >>> Co-authors: >>> Mahesh Jethanandani (mjethanandani@gmail.com) >>> Santosh P K (santoshpk@juniper.net) >>>=20 >>> Contributors: >>> Sam Aldrin (aldrin.ietf@gmail.com) >>> Tissa Senevirathne (tsenevir@cisco.com) >>>=20 >>> The members have been virtually meeting up bi-weekly and working = through the designs at the moment. We expect a -00 document to be = published by them once they reach a certain point. >>>=20 >>> Thanks! >>>=20 >>> -Nobo & Jeff >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQQ/2AAoJEPcO+I7eiUJZPEsP/1gflZ+pOSmD3IAkh8IvyK6B U6/w9NcUxZ69Bgpj6qhEz9tIGE/b0gkvhbj7PfTYrkyWiRxf6rBtzr30ipi8qRba 3duVz+FeBA7b+usD8EkKgFrFODyrEMD7b6Q2ex2poov0m7mszvUERfrkNA+s2xZb XnnaRZS0WaRQRHNikCi6hqdHiauz/M8LzmhP3zF+cvTkWgDpkkvgvgFdwQWZ28ld OUh8ZrpoByDXT8/YGeZYFLnVogAg/ju7zUh9POJftslDLfL18MzWsUchHpNgU/46 ICr3oPOz6Qx3WH5sj6oUKEYFY0DhhAyDVMGUNkOEWjTIaLM/3TWKaw5Vs4SOpm1w PFX0s3De8vTgoWQvw1XBeQVHYbCzSBmGhJI2dkFnaa4pIw7asNeBVc4R2EcomD3/ GN+PQhYkVJ/1/ME+nZGwGiYAURK1szaOS7FkQRQV9IFfA9SZ2MTfzo2DILyYedT1 eWKFg7V5prNcadGSulAoKa+immtKF8rGQQbaz3c+5LS5MpG2xYMIE3mketc7QIM+ zxJ2GUHMIvfu7KK5PIW9yEkZT0MwJiL2lpRoXp9cpaBB4zGbZ33eqDFhBTMvXAzR Er3FojwTXXvB8DBbuvrCt/qqp/D7pYsPhHvI5L9q9dKfaPZDFpD2FCDW1QtodOs1 b7RXuH4f1O4ZR4Aa8bY2 =ZsYR -----END PGP SIGNATURE----- --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3-- From nobody Tue Oct 21 14:55:45 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00491A87CC; Tue, 21 Oct 2014 14:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oMR4aLUjk14r; Tue, 21 Oct 2014 14:55:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 109421A86E7; Tue, 21 Oct 2014 14:55:40 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 79B0B28CF2E4; Tue, 21 Oct 2014 17:55:39 -0400 (EDT) From: Thomas D. Nadeau Content-Type: multipart/mixed; boundary="Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B" Message-Id: <51ACD11B-3A23-4907-9970-D437103380F5@lucidvision.com> Date: Tue, 21 Oct 2014 17:55:39 -0400 To: NETMOD Working Group , rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/JB8ZYCgSdtRFNlyE1mB6T60CovA Subject: [Rtg-yang-coord] interim meeting: yang model focus X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:55:42 -0000 --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [adding rtg-yang-coord] Tomorrow's meeting will use the same WebEx from last time (and = the same as was used last week at the Yang 1.1-focused meeting).=20 Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa = ; myeung@cisco.com =09 Are there any other models people wish to discuss? --Tom --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B Content-Disposition: attachment; filename=webex.txt Content-Type: text/plain; name="webex.txt" Content-Transfer-Encoding: quoted-printable Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, = October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmbbe9c321c8e9f472df4ce74c1987a0f0= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dme720293ef5473cc3bf963302b2f6a8f1= ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4f877f2e629b841380e2d593e4e39b87= WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 http://www.webex.com CCP:+16504793208x649102111#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B-- From nobody Wed Oct 22 06:16:28 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA381A911E; Wed, 22 Oct 2014 06:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pAMYSATCRzNC; Wed, 22 Oct 2014 06:16:24 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52421A910A; Wed, 22 Oct 2014 06:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=428; q=dns/txt; s=iport; t=1413983785; x=1415193385; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=u9wWo45R3JRwOH0P05iEfoAMP61Hm75EM/cSTdMBM48=; b=j0qdwsJdNg3NdJYtf+D0Eu13XfV0TySHRiVlxxf/FXgbiQx3gIQ2TpMR YzpyhP9zGIfeqg0sT7yKxB9qJlAlajPQdWkE+ubgFQDreiZHD3+VSUyNc bUe0XN9KQnPiWYg9rFOu8/4kgHalRY1NzugMB1LmT1Th/zd2t/0ecJLQq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACqtR1StJA2L/2dsb2JhbABcgw7VUAqBDhYBfYRBQAE8FhgDAgECAUsBDAEHAQGIPMYSAQEBAQEBAQEBAQEBAQEBAQEbkFeEUgEEi2OReodsjj6EGB2BNQSBQQEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208";a="89332636" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 22 Oct 2014 13:16:24 +0000 Received: from [10.21.92.197] (sjc-vpn5-1221.cisco.com [10.21.92.197]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9MDGN15015057; Wed, 22 Oct 2014 13:16:23 GMT Message-ID: <5447AE27.7060408@cisco.com> Date: Wed, 22 Oct 2014 06:16:23 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group , Rtg-yang-coord@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/sOj5giOFUxUNkjbhRvaP1YcPl90 Cc: "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:16:26 -0000 Dear all, Today NETMOD interim meeting is canceled. I received some pushbacks from the routing ADs, on the ground that: 1. This interim appears to be meeting to discuss a non-WG draft for which there is no milestone in the working group and for which there is an obvious home outside the working group. 2. The agenda was not announced a week in advance on the IETF announce list as is required Regards, Benoit From nobody Wed Oct 22 06:29:34 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F151A8AD7; Wed, 22 Oct 2014 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wp6Uxh4BV2Rh; Wed, 22 Oct 2014 06:29:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE51A90E3; Wed, 22 Oct 2014 06:29:28 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E6BA228D0736; Wed, 22 Oct 2014 09:29:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <5447AE27.7060408@cisco.com> Date: Wed, 22 Oct 2014 09:29:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> References: <5447AE27.7060408@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/I9JxYW7If6kek5xP6bxUAX4wxSo Cc: Rtg-yang-coord@ietf.org, "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:29:30 -0000 This is hugely disappointing. This is the kind of procedural = non-sense has and IS driving people away from the IETF to other places = where this work is going to get done. The simple effect of such = silliness will be a reduction in speed and quantity of model = development. If the goal of the IESG is to slow down the velocity of = model development and creation, then this approach is perfect. For the record, the interim NETMOD meeting cadence has one = meeting focused on Yang and the other on modeling; is not = NETMOD-specific per say, but to promote model creation because no other = bi-weekly forum exists to do so. It is also a place to bring in non-IETF = work such as the work done in ODL, other open source, or just the public = community that has explicitly wanted to avoid the IETF. We have found = it a convenient and fruitful place to discuss, and actually *build* = models - regardless of their ultimate WG home. The simple reason: its a = single place for many of the experts to gather. I think you will find it = very difficult to get those people onto a per-WG call every other week. =20= I hope the IESG considers this approach carefully because I do = not think it will have the affect the larger IETF community is = interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for = which there is no milestone in the working group and for which there is = an obvious home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce = list as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Wed Oct 22 06:49:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A733B1A9022; Wed, 22 Oct 2014 06:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 SWYW6QFDBxQz; Wed, 22 Oct 2014 06:49:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1471A9239; Wed, 22 Oct 2014 06:49:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MDmxwp030789; Wed, 22 Oct 2014 14:48:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MDmuBm030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 14:48:57 +0100 From: "Adrian Farrel" To: "'Thomas D. Nadeau'" , "'Benoit Claise'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Date: Wed, 22 Oct 2014 14:48:56 +0100 Message-ID: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+Vem6HEYOA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--21.041-10.0-31-10 X-imss-scan-details: No--21.041-10.0-31-10 X-TMASE-MatchedRID: nI1cAR4k0HZCl9DEsHnSbVCi/xDHcDzf1kqyrcMalqVtgXN8SPjcGGhd vY2T9l+XVlPFrbdk9/QPu5VZvLINUsEElERnDJHCCFaAixm5eU/a7t0rt6KkQIie9XwPLRloGuv VcHRvn/zgTGfgubR6iKn9Hj5RZR6NCGqH67UhpHvDr0AjBcmfRt78NWlYojkrDpCUEeEFm7AlHD ysIsZQz/XwMuTsz/9TJYuIh9de7fnmH394WLwaPR3EEAbn+GRbNRv92EahEcGae6AcsiK/zUZqp KN3I/kCK5+n7D4m+weVeaEgHjNmGNcUNjoF7YuV+8AO9OcJ/m/429XtOfGeyrV5fSMRD1zqTQGT kMztYqWf3LpnL91w/JV+NZ72RHta4VtgA8SfpXlHpZCc205uwvi4nVERfgwduRjdZTD8Hxe9E+y WHMdHvHhlnpztBZmn0mOrCP/UIvFgVCr5L5DCrvAjkTMkRNNUfjJOgArMOCbvHbNVSAW5oAi9cm FBBPB+wEzzkYmyTN6qvXEQxA2/V0yHw6z9MyJZz4XVyhFFZHKbKpAlY2y6ScnaL1ri/ilX2zUIf ORoaiIRW3Fo+hK3sB5hmP6OM/PJTX7PJ/OU3vL+xOhjarOnHrHlqZYrZqdI+gtHj7OwNO0CpgET eT0ynA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/UKT1CYGZ-2iuaiB1F1s0C9ZgBfQ Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:49:07 -0000 I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Wed Oct 22 06:51:03 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35451ABD3F; Wed, 22 Oct 2014 06:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6vrbNdEvzA0p; Wed, 22 Oct 2014 06:51:00 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEC41AC3A1; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so1445879ieb.4 for ; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9FmnZuYVw/AGhX7nJBFg4v74OSCpbXRUMMGNIO1e/ZA=; b=Jo6J0o66R0pcubX/+X1YFzGBc8yX6McBC0ENlehb0SRekIAUdo+Ir2BszwQXP03D2Q 9Rm+w41T40vTzasq4O/aL2OJRmns0n+sfnU5Sx0DcAOS6SUxyXIeXhvKRHHLvzTpawTf IRrUjIgE7bcnDoAD+astSsjX7fuJSmji8i3dpzS4TNKcsPu9pGcMUVr0vwycJFi1508L 4cQrnYRgJtxJ3w5GFqP5wEJ+qYxOhlfScKugQNCm3v2M4qgtJ6O1sScZXat0H1Muiiih Zh0pwmlWLWtjUvFiq0rZWnUhmZVY2Cxnm/TwbFz7g5dw8Ht1THLbWovceVT4mlZivrQM IQgA== MIME-Version: 1.0 X-Received: by 10.107.133.5 with SMTP id h5mr25665361iod.47.1413985859044; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 06:50:58 -0700 (PDT) In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Date: Wed, 22 Oct 2014 15:50:58 +0200 X-Google-Sender-Auth: O96-FcbPhhnhIZMbH7ayKPCo23w Message-ID: From: Robert Raszuk To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a113ea4f0d88b580506033c1d Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/WX1Psap7p95vaM8jF2v3Yi4NWz0 Cc: Benoit Claise , Rtg-yang-coord@ietf.org, "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:51:01 -0000 --001a113ea4f0d88b580506033c1d Content-Type: text/plain; charset=UTF-8 Hi Tom, I agree with you. Not longer then few days back I have received request from paying customers to add OSPF, BGP & BFD API to the product. All I could propose was few slowly moving drafts. I recommend you setup a meetup.com space for rtg-yang regular online discussions and turn those drafts which are in progress into OpenStack Neutron blueprints. I think the progress will be much faster and much wider in the community ;-) Cheers, R. On Wed, Oct 22, 2014 at 3:29 PM, Thomas D. Nadeau wrote: > > This is hugely disappointing. This is the kind of procedural > non-sense has and IS driving people away from the IETF to other places > where this work is going to get done. The simple effect of such silliness > will be a reduction in speed and quantity of model development. If the > goal of the IESG is to slow down the velocity of model development and > creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, > but to promote model creation because no other bi-weekly forum exists to do > so. It is also a place to bring in non-IETF work such as the work done in > ODL, other open source, or just the public community that has explicitly > wanted to avoid the IETF. We have found it a convenient and fruitful place > to discuss, and actually *build* models - regardless of their ultimate WG > home. The simple reason: its a single place for many of the experts to > gather. I think you will find it very difficult to get those people onto a > per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not > think it will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for > which there is no milestone in the working group and for which there is an > obvious home outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce > list as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a113ea4f0d88b580506033c1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

I agree with you.=C2=A0

N= ot longer then few days back I have received request from paying customers = to add OSPF, BGP & BFD API to the product.=C2=A0
All I could propose was few slowly moving drafts.=C2= =A0

I recommend you setup a meetup.com space for rtg-yang regular online = discussions and turn those drafts which are in progress into OpenStack Neut= ron blueprints.=C2=A0

I think th= e progress will be much faster and much wider in the community ;-)

Cheers,
R.




=

On Wed, Oct= 22, 2014 at 3:29 PM, Thomas D. Nadeau <tnadeau@lucidvision.com&= gt; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is hugely disappointing. This is the kind = of procedural non-sense has and IS driving people away from the IETF to oth= er places where this work is going to get done. The simple effect of such s= illiness will be a reduction in speed and quantity of model development.=C2= =A0 If the goal of the IESG is to slow down the velocity of model developme= nt and creation, then this approach is perfect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For the record, the interim NETMOD meeting cade= nce has one meeting focused on Yang and the other on modeling; is not NETMO= D-specific per say, but to promote model creation because no other bi-weekl= y forum exists to do so. It is also a place to bring in non-IETF work such = as the work done in ODL, other open source, or just the public community th= at has explicitly wanted to avoid the IETF.=C2=A0 We have found it a conven= ient and fruitful place to discuss, and actually *build* models - regardles= s of their ultimate WG home.=C2=A0 The simple reason: its a single place fo= r many of the experts to gather. I think you will find it very difficult to= get those people onto a per-WG call every other week.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I hope the IESG considers this approach careful= ly because I do not think it will have the affect the larger IETF community= is interested in.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom



> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
> Dear all,
>
> Today NETMOD interim meeting is canceled.
>
> I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for wh= ich there is no milestone in the working group and for which there is an ob= vious home outside the working group.
> 2. The agenda was not announced a week in advance on the IETF announce= list as is required
>
> Regards, Benoit
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--001a113ea4f0d88b580506033c1d-- From nobody Wed Oct 22 06:51:40 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC11AC3A7; Wed, 22 Oct 2014 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zNQj958joaEo; Wed, 22 Oct 2014 06:51:33 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF01ABD3C; Wed, 22 Oct 2014 06:51:33 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AF56B28D080C; Wed, 22 Oct 2014 09:51:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 09:51:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/qHlhxpWT-3MlAbVN4gxAZLnZNwo Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:51:35 -0000 Hide behind the rules all you like, but this is a simple example = of why people are going elsewhere to work on these things. --Tom > On Oct 22, 2014:9:48 AM, at 9:48 AM, Adrian Farrel = wrote: >=20 > I understand and appreciate your desire to get work done. >=20 > The rules for IETF virtual interims are neither hard to discover, nor = hard to > comply with. The rules exist to ensure that people are included in the = work, and > I am sure that inclusion is what you want. >=20 > I find it unfortunate that you scheduled a working group meeting to = discuss only > one of a pair of competing documents on the same topic, that you = didn't make the > information about the meeting available to the authors of the = competing document > or to the people who care about the protocol being modelled, and I = find it > upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a > document that belongs in the OSPF working group. >=20 > If, as it surely sounds, you wish that the Netmod working group had a = different > charter to enable it to take on models for protocols that already have = a home in > other working groups, then I suggest you need to recharter. But I = doubt that > your reasoning that [YANG] experts will not go to all the other = working groups > will carry much weight. Frankly, and without wanting to disrespect the = YANG > experts, it is easier to understand YANG than it is to understand = OSPF. If this > were not the case then the Netmod working group would have failed in = its design > of YANG!=20 >=20 > Conclusion:=20 > You want to work on a YANG model for OSPF. Go to the OSPF working = group and > discuss it (there are already some threads). Review and comment on the = competing > document. Try to get agreement between all of the authors of both = documents, or > try to identify the differences. Work with the chairs of the OSPF = working group > to advance the work. >=20 > Adrian >=20 >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: 22 October 2014 14:29 >> To: Benoit Claise >> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; >> rtg-ads@tools.ietf.org >> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >>=20 >>=20 >> This is hugely disappointing. This is the kind of procedural = non-sense > has >> and IS driving people away from the IETF to other places where this = work is > going >> to get done. The simple effect of such silliness will be a reduction = in speed > and >> quantity of model development. If the goal of the IESG is to slow = down the >> velocity of model development and creation, then this approach is = perfect. >>=20 >> For the record, the interim NETMOD meeting cadence has one = meeting >> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but >> to promote model creation because no other bi-weekly forum exists to = do so. It >> is also a place to bring in non-IETF work such as the work done in = ODL, other > open >> source, or just the public community that has explicitly wanted to = avoid the > IETF. >> We have found it a convenient and fruitful place to discuss, and = actually > *build* >> models - regardless of their ultimate WG home. The simple reason: = its a > single >> place for many of the experts to gather. I think you will find it = very > difficult to get >> those people onto a per-WG call every other week. >>=20 >> I hope the IESG considers this approach carefully because I do = not think > it >> will have the affect the larger IETF community is interested in. >>=20 >> --Tom >>=20 >>=20 >>=20 >>> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > wrote: >>>=20 >>> Dear all, >>>=20 >>> Today NETMOD interim meeting is canceled. >>>=20 >>> I received some pushbacks from the routing ADs, on the ground that: >>> 1. This interim appears to be meeting to discuss a non-WG draft for = which > there >> is no milestone in the working group and for which there is an = obvious home >> outside the working group. >>> 2. The agenda was not announced a week in advance on the IETF = announce list >> as is required >>>=20 >>> Regards, Benoit >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Wed Oct 22 07:02:06 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2DD1A8F44 for ; Wed, 22 Oct 2014 07:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VRPibLGXSVtq for ; Wed, 22 Oct 2014 07:02:01 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7F31AC3C0 for ; Wed, 22 Oct 2014 07:01:46 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so3497093iec.27 for ; Wed, 22 Oct 2014 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qmkB1Pypk6A/mUvaPectzytWl3kTz1Uo6ay5Hrgrkbc=; b=ygLxLKqY0aQsYmauqPYhbTP+ZCgYUqV6ytpmbT/TC5qkb+wPFdPebT0LzdGUnKHGiL iyye8pQhC/Fm4HfJGkyy3yOE9hfzZvWqhedWDjHwKVKoJ4SPvKsB0AukwpZPbmerBdCZ 71ej4bZAk+M2tvNQQ45jaABTcKvU5vsGs04VJSIUDKOWFgpCgetM3Fgp2M2EfMAOPnhb /lVGVJBvvA3C4k60ZnkaGzfgUnAy6RRPtHbXet/Xb4YPupgDPzr7eo8X5rNBDP1l7b9F S2tkYk/IO098T1+fK0HxQ0isvX8BDtaAoqfDGBJqLmqyELV+rHv+T35fI4tCyG6+nJHU 3CPA== MIME-Version: 1.0 X-Received: by 10.107.133.5 with SMTP id h5mr25733302iod.47.1413986503984; Wed, 22 Oct 2014 07:01:43 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 07:01:43 -0700 (PDT) In-Reply-To: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 16:01:43 +0200 X-Google-Sender-Auth: d-cmTm_QgtUG_WAQNjKkRUaeh20 Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113ea4f0498c480506036320 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hohdU4oG4MBQo7XLgqT2zB_MvnA Cc: Benoit Claise , "Thomas D. Nadeau" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:02:03 -0000 --001a113ea4f0498c480506036320 Content-Type: text/plain; charset=UTF-8 Hi Adrian, What other competing OSPF yang model are you referring to? Can you provide link to discussions about that other model on OSPF WG list taking place ? Thx, R. On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel wrote: > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a113ea4f0498c480506036320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

What other competing OSPF yang model are you referring to?=C2=A0<= /div>

Can you provide link to discussi= ons about that other model on OSPF WG list taking place ?=C2=A0

Thx,
R.


= On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk&= gt; wrote:
I understand and apprec= iate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.=C2=A0 If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.=C2=A0 The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0--Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

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

--001a113ea4f0498c480506036320-- From nobody Wed Oct 22 07:16:30 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48C1AC3E5 for ; Wed, 22 Oct 2014 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 O9aTJPTKVn4O for ; Wed, 22 Oct 2014 07:16:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6444F1AC3A7 for ; Wed, 22 Oct 2014 07:13:33 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MEDRTu016514; Wed, 22 Oct 2014 15:13:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MEDPuP016462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 15:13:26 +0100 From: "Adrian Farrel" To: "'Robert Raszuk'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 15:13:25 +0100 Message-ID: <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027E_01CFEE0A.BAD77600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL95uC7UKA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--18.364-10.0-31-10 X-imss-scan-details: No--18.364-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHhYHdRIVs+3xn0UD4GU5IqfiuvKi9huaYhvFjBsLEZNE90 0KYgJiJVFsFsBxZEz2ueflKc19WIn9UEA09P1mY/dnC5uaS6tb/2v20RxLDyN5MxNpDOG+h6EX4 5YqIU5dS6+E4LDxkgtNFHzHVGz8gv15XTSsyj5b2vnWBILruGlSIBy2vbJcli5DJ1FS+XdBPPQs qvYT5Cwfa+1VWhPfX7z7y4bOFv6W+eJDeXRpqc2nBRIrj8R47FguwtqyXlE6GYfLu5qIysvp3+d uY6/oy814gnLq0QZ8eAbn+e8MB84P3HWaFz5g1U020eWoALA9d9PDJLBn6rnG3D6f6IpbLIFyF2 sm/fFKdS5tCmvxvQCiQhHseAiB6oBPgJPejKIJjx5KZMlKYS/VHewY36PuY0Rq/Bt79tzN/3qNR T6fGzEfsL5LFa/Vhcl8V3FW3kGPNo4d3pab8rlLrbxxduc6FPIgQH9fS2CAbUxS9drct9t3YXjT xEWkwAD7vjH4MIXkfE4bTBp3X/flwyNnI+JiKpmlaAItiONP1TQ6yD6LF7xRsizOQuDf4xOXUFK +IJNsKSoINrfR0Nng+2zXldJG/GLOGyzQCUGKqdVNZaI2n6/0GV2YNiPCWmm5K/hJ/GErc5lEBN B9cFYjba6gSbbjl+gVo1o+4QhtKqDvek35mqXJ3bt4XlQMWjD+LwVja9M4EgOnjvjQ5gMSWdw9M yj4ex9dMkDbqNTiWX7nDC+4gKenNQXkvyemjfXTK4OtPUfQSjuF41aTJRXZ/paSZmLhGje5basi bx4KfyTo1GsSlyqhkigyII1PZ5MuPfXQm0MvCeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIYq/QJO AA07SIQ5mZ5SqHP99jiWJ7mFdQAdN1Liy4DfKT+quJLasT5I2nNB9EASE4lFyEW65UfPYNG4eU/ P7f5vBT1b080/sHpRbi8I+M36WnkQqNoJCaslExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/pjDUZIVDpZd4UVtXKdGOudphBkc Cc: 'Benoit Claise' , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:16:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_027E_01CFEE0A.BAD77600 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ =20 Yes, it is in the wrong WG as well. =20 No, I can't point to it being discussed on the OSPF list. Not sure that = fact proves anything. =20 Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Hi Adrian, =20 What other competing OSPF yang model are you referring to?=20 =20 Can you provide link to discussions about that other model on OSPF WG = list taking place ?=20 =20 Thx, R. =20 =20 On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel = wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor = hard to comply with. The rules exist to ensure that people are included in the = work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to = discuss only one of a pair of competing documents on the same topic, that you didn't = make the information about the meeting available to the authors of the competing = document or to the people who care about the protocol being modelled, and I find = it upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a = different charter to enable it to take on models for protocols that already have a = home in other working groups, then I suggest you need to recharter. But I doubt = that your reasoning that [YANG] experts will not go to all the other working = groups will carry much weight. Frankly, and without wanting to disrespect the = YANG experts, it is easier to understand YANG than it is to understand OSPF. = If this were not the case then the Netmod working group would have failed in its = design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group = and discuss it (there are already some threads). Review and comment on the = competing document. Try to get agreement between all of the authors of both = documents, or try to identify the differences. Work with the chairs of the OSPF = working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural = non-sense has > and IS driving people away from the IETF to other places where this = work is going > to get done. The simple effect of such silliness will be a reduction = in speed and > quantity of model development. If the goal of the IESG is to slow = down the > velocity of model development and creation, then this approach is = perfect. > > For the record, the interim NETMOD meeting cadence has one = meeting > focused on Yang and the other on modeling; is not NETMOD-specific per = say, but > to promote model creation because no other bi-weekly forum exists to = do so. It > is also a place to bring in non-IETF work such as the work done in = ODL, other open > source, or just the public community that has explicitly wanted to = avoid the IETF. > We have found it a convenient and fruitful place to discuss, and = actually *build* > models - regardless of their ultimate WG home. The simple reason: its = a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do = not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for = which there > is no milestone in the working group and for which there is an obvious = home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF = announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 ------=_NextPart_000_027E_01CFEE0A.BAD77600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Robert,

 

http://datatracker.ietf.org/doc/draft-wang-i2rs-osp= f-dm/

 

Yes, it is in the wrong WG as = well.

 

No, I can't point to it being = discussed on the OSPF list. Not sure that fact proves = anything.

 

Adrian

 

From: rraszuk@gmail.com = [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: 22 October 2014 15:02
To: Adrian = Farrel
Cc: Thomas D. Nadeau; Benoit Claise; = Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org
Subject: = Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Hi = Adrian,

 

What other competing OSPF yang model = are you referring to? 

 

Can you provide link to discussions = about that other model on OSPF WG list taking place = ? 

 

Thx,

R.

 

 

On Wed, = Oct 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian


> -----Original Message-----
> From: = Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
Rtg-yang-c= oord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 

------=_NextPart_000_027E_01CFEE0A.BAD77600-- From nobody Wed Oct 22 07:18:46 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840391AC3D7 for ; Wed, 22 Oct 2014 07:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 76ylr4drxEWj for ; Wed, 22 Oct 2014 07:18:30 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E4C1AC3DF for ; Wed, 22 Oct 2014 07:18:18 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id b13so2962116qcw.20 for ; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UY0VHpd+msgdFT8jBDnZq4x+yI4o134Ji4RPuiZAOhg=; b=ivZYZ1YBhkqQ+CChbimDNJBA9eY+bHpBYSsw5Mu2LKRCyMb9WiHVuJlhtbbWHJlfKt vNnaBtn1GBmCBVZdHpw6zWMC7Mw6YsJhvWqfqZ0SG6DGE8TxFucb4fEX51nDDC7bE3Al mMR1tKmrwTF1V6Mr7Jxyr2ySoBRHQfDIhcPNyqpU2S6ucrg9eGIxclwgjVfAilRPKSLa T3ViQtEFtzo8RiFIMZT5QGLL13OOkq0n/hUl6BDKWDo5gT1C/LyxSIO5yT3zqtzm2KO6 NpphTh8eG4phFZFzYeZWNplP7/DAiFTOHWKOMC1+UdkO1h5GlVFc2xUpcljZDzAbIwqM vECg== X-Gm-Message-State: ALoCoQla1BEgicOm1+toIVX98zL3iI7ysIhGxLf8hwPVfHqxI6tCBKPI7cCl1OozbWzXV1klnasy MIME-Version: 1.0 X-Received: by 10.224.130.198 with SMTP id u6mr30701761qas.99.1413987494486; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) In-Reply-To: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:18:14 -0700 Message-ID: From: Andy Bierman To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e0158b38c53c7150506039e53 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/eWwx9Mke7eTRINERg0lCZ-_DFV4 Cc: Rtg-yang-coord@ietf.org, "Thomas D. Nadeau" , NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:18:38 -0000 --089e0158b38c53c7150506039e53 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0158b38c53c7150506039e53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I agree with you. The OSPF W= G should be discussing OSPF data models,
not the NETMOD WG. The d= omain experts need to reach consensus
on a feature set (and maybe= info model) and then get 1 or 2 YANG experts to
help translate t= hat to a data model. (Not the other way around -- a room
full of = YANG experts and 1 or 2 OSPF experts).

I also pref= er that virtual interim meetings be used to discuss open issues
o= n chartered items, not as an additional forum to promote individual drafts.=


Andy


On Wed, Oct 22, = 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote= :
I understand and appreciate your desire= to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; R= tg-yang-coord@ietf.org; ops-a= ds@tools.ietf.org;
> rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>=A0 =A0 =A0 =A0This is hugely disappointing. This is the kind of proced= ural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.=A0 If the goal of the IESG is to slow d= own the
> velocity of model development and creation, then this approach is perf= ect.
>
>=A0 =A0 =A0 =A0For the record, the interim NETMOD meeting cadence has o= ne meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.=A0 The simple reason: i= ts a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>=A0 =A0 =A0 =A0I hope the IESG considers this approach carefully becaus= e I do not think
it
> will have the affect the larger IETF community is interested in.
>
>=A0 =A0 =A0 =A0--Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--089e0158b38c53c7150506039e53-- From nobody Wed Oct 22 07:19:05 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5941AC3DC for ; Wed, 22 Oct 2014 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 tbabcgYPadmZ for ; Wed, 22 Oct 2014 07:18:58 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041BA1AC3D6 for ; Wed, 22 Oct 2014 07:18:55 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so1526072ieb.18 for ; Wed, 22 Oct 2014 07:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UeMdMJEkYM8giUUEQotTneUAQyi1PLmDDGkPpegYDaw=; b=CW408v39UwIAh4r+A3xK1TOLl0O/LEgPzfMj3IVfzhHqycF0+yZLyZeTUrdeo+EkSO BQJTz9EnE713LzPKJ3faTrA0C6JbYr42+EA/UXNSQG07X78H75JzOTT2jjjzUYtVlBJ3 u7ZQwGhE57vx8fvXKpvkfwmOUMJfBUHcqCesHPzoc3FqvlnzsuUdf+CPzSfkXe/NdH+f J4qT4XToXmY8XekEjQ8dJCdJoNkacHoqfFT/VMu93cIh5mvc4EZgyEn+RbVTKfLZVr/O YbwCLrz2qGys1yr0GuGxBo1fcjdoU7qK5DhRfE9ZbZKeLOXMnLW6pyal6Ru+tA/Iy09q PdUQ== MIME-Version: 1.0 X-Received: by 10.50.25.169 with SMTP id d9mr3036469igg.17.1413987535440; Wed, 22 Oct 2014 07:18:55 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 07:18:55 -0700 (PDT) In-Reply-To: <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> Date: Wed, 22 Oct 2014 16:18:55 +0200 X-Google-Sender-Auth: MKpmHPzTbTrb3YSQq7Jxplvx1oc Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=047d7bdc1a68c47466050603a081 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/MiyvrVgZF40vYQ9rcuLzDmqNC40 Cc: Benoit Claise , "Thomas D. Nadeau" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:19:02 -0000 --047d7bdc1a68c47466050603a081 Content-Type: text/plain; charset=UTF-8 Adrian, Ah that document I know. But this is almost completely different topic. At least to me I2RS is not about configuring OSPF protocol. It is about collecting and possibly augmenting routing system with data. On the other hand Yang model takes care about instatiation and management of a given protocol. There can be some little overlap, but does not need to be at all. Best, R. On Wed, Oct 22, 2014 at 4:13 PM, Adrian Farrel wrote: > Hi Robert, > > > > http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ > > > > Yes, it is in the wrong WG as well. > > > > No, I can't point to it being discussed on the OSPF list. Not sure that > fact proves anything. > > > > Adrian > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* 22 October 2014 15:02 > *To:* Adrian Farrel > *Cc:* Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; > ospf-chairs@tools.ietf.org > > *Subject:* Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > Hi Adrian, > > > > What other competing OSPF yang model are you referring to? > > > > Can you provide link to discussions about that other model on OSPF WG list > taking place ? > > > > Thx, > > R. > > > > > > On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > --047d7bdc1a68c47466050603a081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

Ah that document I know. But this is almost completely different top= ic.=C2=A0

At least to me I2RS = is not about configuring OSPF protocol. It is about collecting and possibly= augmenting routing system with data.=C2=A0

On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but does = not need to be at all.

Best,
R.



On Wed, Oct 22= , 2014 at 4:13 PM, Adrian Farrel <adrian@olddog.co.uk> wro= te:

Hi Rob= ert,

=C2=A0

http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-= dm/

=C2=A0

Yes, it is in the wrong WG as well.

=C2=A0=

No, I can't point= to it being discussed on the OSPF list. Not sure that fact proves anything= .

=C2=A0

Adrian

=C2=A0

From: rraszu= k@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: 22 October 2014 15:02
To: Adrian Farrel
Cc: Thomas D.= Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org


Subject: Re: [Rtg-yang-coord] NETMOD interim = meeting canceled

=C2=A0

Hi Adria= n,

=C2=A0

=

What other competing OSPF yang model are you referring to?=C2=A0

=C2=A0

Can= you provide link to discussions about that other model on OSPF WG list tak= ing place ?=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Wed, = Oct 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get wor= k done.

The rules for IETF virtual interims are neither hard to disc= over, nor hard to
comply with. The rules exist to ensure that people are= included in the work, and
I am sure that inclusion is what you want.
I find it unfortunate that you scheduled a working group meeting to di= scuss only
one of a pair of competing documents on the same topic, that = you didn't make the
information about the meeting available to the a= uthors of the competing document
or to the people who care about the pro= tocol being modelled, and I find it
upsetting (yes, I am actually upset)= that you decided to discuss in Netmod a
document that belongs in the OS= PF working group.

If, as it surely sounds, you wish that the Netmod = working group had a different
charter to enable it to take on models for= protocols that already have a home in
other working groups, then I sugg= est you need to recharter. But I doubt that
your reasoning that [YANG] e= xperts will not go to all the other working groups
will carry much weigh= t. Frankly, and without wanting to disrespect the YANG
experts, it is ea= sier to understand YANG than it is to understand OSPF. If this
were not = the case then the Netmod working group would have failed in its design
o= f YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go= to the OSPF working group and
discuss it (there are already some thread= s). Review and comment on the competing
document. Try to get agreement b= etween all of the authors of both documents, or
try to identify the diff= erences. Work with the chairs of the OSPF working group
to advance the w= ork.

Adrian


> -----Original Message-----
> = From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014= 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.o= rg; ops-ads= @tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coo= rd] NETMOD interim meeting canceled
>
>
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0This is hugely disappointing. This is the kind of procedural n= on-sense
has
> and IS driving people away from the IETF to other p= laces where this work is
going
> to get done. The simple effect of= such silliness will be a reduction in speed
and
> quantity of mod= el development.=C2=A0 If the goal of the IESG is to slow down the
> v= elocity of model development and creation, then this approach is perfect.>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For the record, the interim NETMOD= meeting cadence has one meeting
> focused on Yang and the other on m= odeling; is not NETMOD-specific per say, but
> to promote model creat= ion because no other bi-weekly forum exists to do so. It
> is also a = place to bring in non-IETF work such as the work done in ODL, other
open=
> source, or just the public community that has explicitly wanted to= avoid the
IETF.
> We have found it a convenient and fruitful plac= e to discuss, and actually
*build*
> models - regardless of their = ultimate WG home.=C2=A0 The simple reason: its a
single
> place fo= r many of the experts to gather. I think you will find it very
difficult= to get
> those people onto a per-WG call every other week.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0I hope the IESG considers this approach ca= refully because I do not think
it
> will have the affect the large= r IETF community is interested in.
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0--Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9= :16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear al= l,
> >
> > Today NETMOD interim meeting is canceled.
&= gt; >
> > I received some pushbacks from the routing ADs, on th= e ground that:
> > 1. This interim appears to be meeting to discus= s a non-WG draft for which
there
> is no milestone in the working = group and for which there is an obvious home
> outside the working gr= oup.
> > 2. The agenda was not announced a week in advance on the = IETF announce list
> as is required
> >
> > Regards= , Benoit
> >
> > ________________________________________= _______
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org=
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= /a>
> >

_______________________________________________
= Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtg-yang-coord

=C2=A0

=

--047d7bdc1a68c47466050603a081-- From nobody Wed Oct 22 07:24:43 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28A21AC410 for ; Wed, 22 Oct 2014 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 hpfT1w7PNowZ for ; Wed, 22 Oct 2014 07:24:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A4B1AC3E4 for ; Wed, 22 Oct 2014 07:24:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MEOMgq003664; Wed, 22 Oct 2014 15:24:23 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MEOK1h003614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 15:24:21 +0100 From: "Adrian Farrel" To: "'Robert Raszuk'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 15:24:20 +0100 Message-ID: <02a301cfee03$dfa35690$9eea03b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A4_01CFEE0C.416C2B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAf8q9iybYImC8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--19.838-10.0-31-10 X-imss-scan-details: No--19.838-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtE/FLJq3yHG9fvADvTnCf5vGbJMFqqIm9xD4waA+EdQJtUK tDQSklYjIpJv43e/q1kdSpvnljEaV7c8WMOqfr2uSEQN/D/3cG7omPrNi98UBO8ds1VIBbmgyRS EpZz6DA+kEcw1j5evwFZjfl6BrKMKqmLWaEinQeFrmVUl6mlWFTTbofuc5kuvkzE2kM4b6HoRfj liohTl1Lr4TgsPGSC00UfMdUbPyC/XldNKzKPlva+dYEguu4aVIgHLa9slyWLkMnUVL5d0E89Cy q9hPkLB9r7VVaE99fvPvLhs4W/pb54kN5dGmpzaw69AIwXJn0be/DVpWKI5Kw6QlBHhBZuwJRw8 rCLGUM/18DLk7M//UyWLiIfXXu355h9/eFi8Gj0dxBAG5/hkWwhggJPN8raBYsz9F4FLBTA1e1O uuSZoHU1i8No7236clLaxhEY3pVmoQ2O1jKTe+DRcNsH5qGMH0w14HFJQjaOGdTBcokaRkxyXam jRNW2iTdn5Fl2oZybvu3mAnA6s2U8M9+aj5+3HF6z9HGHKwNudtHUoZpvleY1eRh5mhJr6rVEg5 dgXrIu9vpZu7svkoEy2aqFg+VDTKdt5o9/T+2p0ucZsFOYuzg2ZUxYPnl87zsQ8iRVyD44ONnCO tDoJBZ6Ss6O2bihGHDnwvr6B+jT1lGRVqRJJbe9VsdrlGzy3/bFfU5WtaotXG3yI9k2vbIAuOqc iU0p01eMp+in9a9PfCoL1Cy7eF/36sqVF/VZoS3OTftLNfg2U9XpVqqLhsPHFoBcOsKeziPsneP M42N0lrqsYlHhF+jC6IPNP8UWJUeL68LoXEvyeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIYq/QJO AA07SIQ5mZ5SqHP/UeAN3Eh4JCbEvG0vy65J48z2de5XjdjTLo0+sR3zFSwEH5vET77Qw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hnGZZ9WPZjp2Ojruh1liROKIBh4 Cc: 'Benoit Claise' , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:24:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02A4_01CFEE0C.416C2B60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Excellent. =20 This is exactly the discussion that should be happening. =20 Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 22 October 2014 15:19 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Adrian, =20 Ah that document I know. But this is almost completely different topic.=20 =20 At least to me I2RS is not about configuring OSPF protocol. It is about = collecting and possibly augmenting routing system with data.=20 =20 On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. =20 Best, R. =20 =20 =20 On Wed, Oct 22, 2014 at 4:13 PM, Adrian Farrel = wrote: Hi Robert, =20 http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ =20 Yes, it is in the wrong WG as well. =20 No, I can't point to it being discussed on the OSPF list. Not sure that = fact proves anything. =20 Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Hi Adrian, =20 What other competing OSPF yang model are you referring to?=20 =20 Can you provide link to discussions about that other model on OSPF WG = list taking place ?=20 =20 Thx, R. =20 =20 On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel = wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor = hard to comply with. The rules exist to ensure that people are included in the = work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to = discuss only one of a pair of competing documents on the same topic, that you didn't = make the information about the meeting available to the authors of the competing = document or to the people who care about the protocol being modelled, and I find = it upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a = different charter to enable it to take on models for protocols that already have a = home in other working groups, then I suggest you need to recharter. But I doubt = that your reasoning that [YANG] experts will not go to all the other working = groups will carry much weight. Frankly, and without wanting to disrespect the = YANG experts, it is easier to understand YANG than it is to understand OSPF. = If this were not the case then the Netmod working group would have failed in its = design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group = and discuss it (there are already some threads). Review and comment on the = competing document. Try to get agreement between all of the authors of both = documents, or try to identify the differences. Work with the chairs of the OSPF = working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural = non-sense has > and IS driving people away from the IETF to other places where this = work is going > to get done. The simple effect of such silliness will be a reduction = in speed and > quantity of model development. If the goal of the IESG is to slow = down the > velocity of model development and creation, then this approach is = perfect. > > For the record, the interim NETMOD meeting cadence has one = meeting > focused on Yang and the other on modeling; is not NETMOD-specific per = say, but > to promote model creation because no other bi-weekly forum exists to = do so. It > is also a place to bring in non-IETF work such as the work done in = ODL, other open > source, or just the public community that has explicitly wanted to = avoid the IETF. > We have found it a convenient and fruitful place to discuss, and = actually *build* > models - regardless of their ultimate WG home. The simple reason: its = a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do = not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for = which there > is no milestone in the working group and for which there is an obvious = home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF = announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 =20 ------=_NextPart_000_02A4_01CFEE0C.416C2B60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Excellent.

 

This is exactly the discussion = that should be happening.

 

Adrian

 

From: rraszuk@gmail.com = [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: 22 October 2014 15:19
To: Adrian = Farrel
Cc: Thomas D. Nadeau; Benoit Claise; = Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org
Subject: = Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Adrian,

 

Ah that document I know. But this is = almost completely different = topic. 

 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with = data. 

 

On the other hand Yang model takes = care about instatiation and management of a given protocol. There can be = some little overlap, but does not need to be at = all.

 

Best,

R.

 

 

 

On Wed, = Oct 22, 2014 at 4:13 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi Robert,

 

http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm= /

 

Yes, it is in the wrong WG as well.

 

No, I can't point to it being discussed on the OSPF list. Not sure = that fact proves anything.

 

Adrian

 

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: 22 October 2014 15:02
To: Adrian = Farrel
Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org


Subject: Re: [Rtg-yang-coord] = NETMOD interim meeting = canceled

 <= /o:p>

Hi = Adrian,

 

What other competing OSPF yang model = are you referring to? 

 

Can you provide link to discussions = about that other model on OSPF WG list taking place = ? 

 

Thx,

R.

 

 <= /o:p>

On Wed, Oct = 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I = understand and appreciate your desire to get work done.

The rules = for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in = the work, and
I am sure that inclusion is what you want.

I = find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, = that you didn't make the
information about the meeting available to = the authors of the competing document
or to the people who care about = the protocol being modelled, and I find it
upsetting (yes, I am = actually upset) that you decided to discuss in Netmod a
document that = belongs in the OSPF working group.

If, as it surely sounds, you = wish that the Netmod working group had a different
charter to enable = it to take on models for protocols that already have a home in
other = working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other = working groups
will carry much weight. Frankly, and without wanting = to disrespect the YANG
experts, it is easier to understand YANG than = it is to understand OSPF. If this
were not the case then the Netmod = working group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian


> = -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
Rtg-yang-c= oord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 <= /o:p>

 

------=_NextPart_000_02A4_01CFEE0C.416C2B60-- From nobody Wed Oct 22 07:35:22 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF61ACCF3; Wed, 22 Oct 2014 07:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OSRo_mBRQpNZ; Wed, 22 Oct 2014 07:35:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0E1ACCEB; Wed, 22 Oct 2014 07:35:11 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 31C3F28D09E0; Wed, 22 Oct 2014 10:35:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 10:35:10 -0400 Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Andy Bierman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/zxcO0X8GCnZoX5v6gQvC-jriRDQ Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:35:19 -0000 --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No one said that OSPF experts could not attend to provide input. = The issue is that OSPF was not doing this. If they want to take over = doing all OSPF models, then great, but to date no one was. The = agreement in NETMOD (and our charter) is to facilitate the creation of = models when WGs don=92t want to do them, have the expertise to do them, = etc=85 Also, getting the right Yang experts in one place is not going = to happen for every WG in the IETF; its just not realistic. I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right? And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work? The group that was = there to work on the OSPF model was indeed a bunch of folks from OSPF = (Acee Lindem for example was on the call). So now since we won=92t have = another interim meeting until after Hawaii, so the next time this group = can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii. So the net-net is a = slowing of progress in this area. Probably not the result the IETF = community wants. =97Tom > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = wrote: >=20 > Hi Adrian, >=20 > I agree with you. The OSPF WG should be discussing OSPF data models, > not the NETMOD WG. The domain experts need to reach consensus > on a feature set (and maybe info model) and then get 1 or 2 YANG = experts to > help translate that to a data model. (Not the other way around -- a = room > full of YANG experts and 1 or 2 OSPF experts). >=20 > I also prefer that virtual interim meetings be used to discuss open = issues > on chartered items, not as an additional forum to promote individual = drafts. >=20 >=20 > Andy >=20 >=20 > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > I understand and appreciate your desire to get work done. >=20 > The rules for IETF virtual interims are neither hard to discover, nor = hard to > comply with. The rules exist to ensure that people are included in the = work, and > I am sure that inclusion is what you want. >=20 > I find it unfortunate that you scheduled a working group meeting to = discuss only > one of a pair of competing documents on the same topic, that you = didn't make the > information about the meeting available to the authors of the = competing document > or to the people who care about the protocol being modelled, and I = find it > upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a > document that belongs in the OSPF working group. >=20 > If, as it surely sounds, you wish that the Netmod working group had a = different > charter to enable it to take on models for protocols that already have = a home in > other working groups, then I suggest you need to recharter. But I = doubt that > your reasoning that [YANG] experts will not go to all the other = working groups > will carry much weight. Frankly, and without wanting to disrespect the = YANG > experts, it is easier to understand YANG than it is to understand = OSPF. If this > were not the case then the Netmod working group would have failed in = its design > of YANG! >=20 > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working = group and > discuss it (there are already some threads). Review and comment on the = competing > document. Try to get agreement between all of the authors of both = documents, or > try to identify the differences. Work with the chairs of the OSPF = working group > to advance the work. >=20 > Adrian >=20 > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org = ; ops-ads@tools.ietf.org = ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural = non-sense > has > > and IS driving people away from the IETF to other places where this = work is > going > > to get done. The simple effect of such silliness will be a reduction = in speed > and > > quantity of model development. If the goal of the IESG is to slow = down the > > velocity of model development and creation, then this approach is = perfect. > > > > For the record, the interim NETMOD meeting cadence has one = meeting > > focused on Yang and the other on modeling; is not NETMOD-specific = per say, but > > to promote model creation because no other bi-weekly forum exists to = do so. It > > is also a place to bring in non-IETF work such as the work done in = ODL, other > open > > source, or just the public community that has explicitly wanted to = avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, and = actually > *build* > > models - regardless of their ultimate WG home. The simple reason: = its a > single > > place for many of the experts to gather. I think you will find it = very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do = not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground = that: > > > 1. This interim appears to be meeting to discuss a non-WG draft = for which > there > > is no milestone in the working group and for which there is an = obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF = announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord = > > > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don=92t want to do them, have the expertise to do them, etc=85 =  Also, getting the right Yang experts in one place is not going to = happen for every WG in the IETF; its just not realistic.  I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right?

= And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work?  The group = that was there to work on the OSPF model was indeed a bunch of folks = from OSPF (Acee Lindem for example was on the call).  So now since = we won=92t have another interim meeting until after Hawaii, so the next = time this group can get together is possibly in Hawaii, but that is = probably unlikely as a large number of people are not going to Hawaii. =  So the net-net is a slowing of progress in this area. =  Probably not the result the IETF community wants.

= =97Tom



On = Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi Adrian,

I agree with you. The OSPF WG should be discussing OSPF data = models,
not the NETMOD WG. The domain experts need = to reach consensus
on a feature set (and maybe info = model) and then get 1 or 2 YANG experts to
help = translate that to a data model. (Not the other way around -- a = room
full of YANG experts and 1 or 2 OSPF = experts).

I = also prefer that virtual interim meetings be used to discuss open = issues
on chartered items, not as an additional = forum to promote individual drafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:
I understand and = appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor = hard to
comply with. The rules exist to ensure that people are included in the = work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, that you didn't = make the
information about the meeting available to the authors of the competing = document
or to the people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a = different
charter to enable it to take on models for protocols that already have a = home in
other working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other working = groups
will carry much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to understand OSPF. = If this
were not the case then the Netmod working group would have failed in its = design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group = and
discuss it (there are already some threads). Review and comment on the = competing
document. Try to get agreement between all of the authors of both = documents, or
try to identify the differences. Work with the chairs of the OSPF = working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the = kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this = work is
going
> to get done. The simple effect of such silliness will be a = reduction in speed
and
> quantity of model development.  If the goal of the IESG is to = slow down the
> velocity of model development and creation, then this approach is = perfect.
>
>       For the record, the interim NETMOD = meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific = per say, but
> to promote model creation because no other bi-weekly forum exists = to do so. It
> is also a place to bring in non-IETF work such as the work done in = ODL, other
open
> source, or just the public community that has explicitly wanted to = avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and = actually
*build*
> models - regardless of their ultimate WG home.  The simple = reason: its a
single
> place for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach = carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground = that:
> > 1. This interim appears to be meeting to discuss a non-WG = draft for which
there
> is no milestone in the working group and for which there is an = obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF = announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


= --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD-- From nobody Wed Oct 22 07:44:17 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E071ACD01 for ; Wed, 22 Oct 2014 07:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Sgslgl5vJnJj for ; Wed, 22 Oct 2014 07:44:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950891ACC81 for ; Wed, 22 Oct 2014 07:44:04 -0700 (PDT) Received: from [172.29.33.235] (66.129.241.14) by BY2PR05MB158.namprd05.prod.outlook.com (10.242.39.152) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 14:43:59 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EF74503A-5F42-4744-B8A4-7FDF2EFFF5F0" From: Jeff Haas In-Reply-To: Date: Wed, 22 Oct 2014 10:43:37 -0400 Message-ID: <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> To: Robert Raszuk , "Thomas D. Nadeau" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CO1PR06CA040.namprd06.prod.outlook.com (10.242.160.30) To BY2PR05MB158.namprd05.prod.outlook.com (10.242.39.152) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB158; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(189002)(24454002)(199003)(377454003)(51704005)(50986999)(84326002)(230783001)(19580395003)(92566001)(101416001)(92726001)(19580405001)(21056001)(93886004)(85306004)(19617315012)(16601075003)(15202345003)(95666004)(82746002)(33656002)(102836001)(36756003)(15975445006)(40100003)(77156001)(122386002)(512954002)(66066001)(104166001)(57306001)(76482002)(62966002)(120916001)(105586002)(80022003)(83716003)(69556001)(71186001)(87976001)(76176999)(42186005)(93916002)(86362001)(97736003)(87286001)(64706001)(99396003)(106356001)(46102003)(16236675004)(31966008)(20776003)(89996001)(107046002)(85852003)(77096002)(50226001)(4396001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB158; H:[172.29.33.235]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/zZYrrsO_DLU99g3_bLFMk3NhDU4 Cc: Benoit Claise , Adrian Farrel , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:44:07 -0000 --Apple-Mail=_EF74503A-5F42-4744-B8A4-7FDF2EFFF5F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: > Adrian, >=20 > Ah that document I know. But this is almost completely different = topic.=20 >=20 > At least to me I2RS is not about configuring OSPF protocol. It is = about collecting and possibly augmenting routing system with data.=20 >=20 > On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. Just for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go. I2RS is not in the business of trying to do the modeling work of other = WG's protocols. =20 I2RS is definitely in the business of seeing standardized models advance = so we can hook into them. Figuring out the most productive way to have that discussion has = obviously been a bit bumpy. Hence, one of the reasons to have the = rtg-yang-coord list. FWIW, I agree with Adrian that the scope of the netmod interim design = sessions has crept a bit out of the expected charter. This isn't to say = that work shouldn't happen, but when it does: - There needs to be adequate notice (apparently Adrian's biggest = complaint) - Some mindfulness about group scope needs to be accommodated. The comment about taking your ball and going someplace else to play = (meetup.com) was not worthy of a chair, Tom. While there's certainly = precedent in other orgs of working faster, there's also similar precent = of fork and fracture. -- Jeff --Apple-Mail=_EF74503A-5F42-4744-B8A4-7FDF2EFFF5F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
On Oct 22, 2014, at 10:18 AM, Robert = Raszuk <robert@raszuk.net> = wrote:

Adrian,

Ah that = document I know. But this is almost completely different = topic. 

At least to = me I2RS is not about configuring OSPF protocol. It is about collecting = and possibly augmenting routing system with data. 

On the other = hand Yang model takes care about instatiation and management of a given = protocol. There can be some little overlap, but does not need to be at = all.

Just for clarity, the long = term goal of Sue's draft was *not* to be a competing ospf draft, it was = to provide enough of an example config base to demonstrate where I2RS = hooks would go.

I2RS is not in the business of = trying to do the modeling work of other WG's protocols. =  

I2RS is definitely in the business of = seeing standardized models advance so we can hook into = them.

Figuring out the most productive way to = have that discussion has obviously been a bit bumpy.  Hence, one of = the reasons to have the rtg-yang-coord = list.

FWIW, I agree with Adrian that the scope = of the netmod interim design sessions has crept a bit out of the = expected charter.  This isn't to say that work shouldn't happen, = but when it does:
- There needs to be adequate notice = (apparently Adrian's biggest complaint)
- Some mindfulness = about group scope needs to be accommodated.

The = comment about taking your ball and going someplace else to play (meetup.com) was not worthy of a chair, = Tom.  While there's certainly precedent in other orgs of working = faster, there's also similar precent of fork and = fracture.

-- = Jeff

= --Apple-Mail=_EF74503A-5F42-4744-B8A4-7FDF2EFFF5F0-- From nobody Wed Oct 22 07:45:55 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9541F1ACD0E for ; Wed, 22 Oct 2014 07:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 8ZQ7N-OcfeLB for ; Wed, 22 Oct 2014 07:45:37 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB321ACCF0 for ; Wed, 22 Oct 2014 07:45:29 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so2915606qcy.30 for ; Wed, 22 Oct 2014 07:45:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X4DLzO+QCcv4g2ZikCTtny3Thme2eThQUEZ5QaRUzic=; b=OJ3EWhxA7wAw5QW9lLzbPucBXlnmk50NFNGI1OKqG1kMA/kuki3rEEperakEop1Ut1 zPpmYGQAOyN3gu0sEwigRYqc5VcwU1a621/0sWcUg+k4QmkobVNjgT6t5aqCAt6E9xCu TqOWGx/ngPJi2lV5kbOq3VhNmDrtdyrSdpsTfBumn7UlVpWwzOGEe3j3pz0CQH1ozhf+ DrVOp0JT68moX4PUDoKL6h8cU4X+xAo4VOBTMnkAo66uNjcBvMOHHVaY//HImGg1E3q6 oC/gjsQMR4B0fUEyZUHjiVAyAoIcnSF5f9TL3YmjMs9gUD2e4hAyE1CPv1s6BBqK54rb ovzw== X-Gm-Message-State: ALoCoQm9Emiih3AITLfHof2oQU1ximEvn9BP/2yJrts1znI8nwc35eqCy8nu+/gTz/8AESFjsZGy MIME-Version: 1.0 X-Received: by 10.140.109.53 with SMTP id k50mr53981832qgf.83.1413989129005; Wed, 22 Oct 2014 07:45:29 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:45:28 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:45:28 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a113a6bf6c04804050603ffa4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Afp2XNBkLBtlCoMOdceqT4Rh7vU Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:45:46 -0000 --001a113a6bf6c04804050603ffa4 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: > > No one said that OSPF experts could not attend to provide input. The > issue is that OSPF was not doing this. If they want to take over doing all > OSPF models, then great, but to date no one was. The agreement in NETMOD > (and our charter) is to facilitate the creation of models when WGs don't > want to do them, have the expertise to do them, etc... Also, getting the > right Yang experts in one place is not going to happen for every WG in the > IETF; its just not realistic. I understand that ultimately the WG needs to > have consensus, but quick iteration to construct the model surely can > happen in a small "design team" fashion, right? > > And in terms of today's meeting being canceled, really what purpose was > that other than to stall/slow-down work? The group that was there to work > on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for > example was on the call). So now since we won't have another interim > meeting until after Hawaii, so the next time this group can get together is > possibly in Hawaii, but that is probably unlikely as a large number of > people are not going to Hawaii. So the net-net is a slowing of progress in > this area. Probably not the result the IETF community wants. > > --Tom > > > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data models, > not the NETMOD WG. The domain experts need to reach consensus > on a feature set (and maybe info model) and then get 1 or 2 YANG experts to > help translate that to a data model. (Not the other way around -- a room > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss open issues > on chartered items, not as an additional forum to promote individual > drafts. > > > Andy > > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > >> I understand and appreciate your desire to get work done. >> >> The rules for IETF virtual interims are neither hard to discover, nor >> hard to >> comply with. The rules exist to ensure that people are included in the >> work, and >> I am sure that inclusion is what you want. >> >> I find it unfortunate that you scheduled a working group meeting to >> discuss only >> one of a pair of competing documents on the same topic, that you didn't >> make the >> information about the meeting available to the authors of the competing >> document >> or to the people who care about the protocol being modelled, and I find it >> upsetting (yes, I am actually upset) that you decided to discuss in >> Netmod a >> document that belongs in the OSPF working group. >> >> If, as it surely sounds, you wish that the Netmod working group had a >> different >> charter to enable it to take on models for protocols that already have a >> home in >> other working groups, then I suggest you need to recharter. But I doubt >> that >> your reasoning that [YANG] experts will not go to all the other working >> groups >> will carry much weight. Frankly, and without wanting to disrespect the >> YANG >> experts, it is easier to understand YANG than it is to understand OSPF. >> If this >> were not the case then the Netmod working group would have failed in its >> design >> of YANG! >> >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working group >> and >> discuss it (there are already some threads). Review and comment on the >> competing >> document. Try to get agreement between all of the authors of both >> documents, or >> try to identify the differences. Work with the chairs of the OSPF working >> group >> to advance the work. >> >> Adrian >> >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; >> ops-ads@tools.ietf.org; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural >> non-sense >> has >> > and IS driving people away from the IETF to other places where this >> work is >> going >> > to get done. The simple effect of such silliness will be a reduction in >> speed >> and >> > quantity of model development. If the goal of the IESG is to slow down >> the >> > velocity of model development and creation, then this approach is >> perfect. >> > >> > For the record, the interim NETMOD meeting cadence has one meeting >> > focused on Yang and the other on modeling; is not NETMOD-specific per >> say, but >> > to promote model creation because no other bi-weekly forum exists to do >> so. It >> > is also a place to bring in non-IETF work such as the work done in ODL, >> other >> open >> > source, or just the public community that has explicitly wanted to >> avoid the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and >> actually >> *build* >> > models - regardless of their ultimate WG home. The simple reason: its a >> single >> > place for many of the experts to gather. I think you will find it very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I do >> not think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft for >> which >> there >> > is no milestone in the working group and for which there is an obvious >> home >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF >> announce list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > --001a113a6bf6c04804050603ffa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think the interim did not need to= be cancelled. There are ACL, SYSLOG,
and YANG Mount topics. I wa= s going to call in for those, not OSPF.
But I have been saying (f= or over a year now) that it is time to move
domain-specific data = models into the domain-specific WGs.
I think NETMOD WG should foc= us on the YANG language and
infrastructure modules.
Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <t= nadeau@lucidvision.com> wrote:

No one said that OSPF experts could not attend to = provide input.   The issue is that OSPF was not doing this. If they wa= nt to take over doing all OSPF models, then great, but to date no one was.&= nbsp; The agreement in NETMOD (and our charter) is to facilitate the creati= on of models when WGs don’t want to do them, have the expertise to do= them, etc…  Also, getting the right Yang experts in one place = is not going to happen for every WG in the IETF; its just not realistic.&nb= sp; I understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small “design= team” fashion, right?

And in terms of today’s meeting being canceled, rea= lly what purpose was that other than to stall/slow-down work?  The gro= up that was there to work on the OSPF model was indeed a bunch of folks fro= m OSPF (Acee Lindem for example was on the call).  So now since we won= ’t have another interim meeting until after Hawaii, so the next time = this group can get together is possibly in Hawaii, but that is probably unl= ikely as a large number of people are not going to Hawaii.  So the net= -net is a slowing of progress in this area.  Probably not the result t= he IETF community wants.

—Tom



On Oct 22, 2014:10:18 AM, at 10:18 AM, An= dy Bierman <andy= @yumaworks.com> wrote:

Hi Adrian,
I agree with you. The OSPF WG should be discussing OSPF dat= a models,
not the NETMOD WG. The domain experts need to reach con= sensus
on a feature set (and maybe info model) and then get 1 or = 2 YANG experts to
help translate that to a data model. (Not the o= ther way around -- a room
full of YANG experts and 1 or 2 OSPF ex= perts).

I also prefer that virtual interim meeting= s be used to discuss open issues
on chartered items, not as an ad= ditional forum to promote individual drafts.


<= /div>
Andy

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> wrote:
I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod



--001a113a6bf6c04804050603ffa4-- From nobody Wed Oct 22 07:48:13 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8731ACCD9 for ; Wed, 22 Oct 2014 07:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D7T1a5s4fgHu for ; Wed, 22 Oct 2014 07:48:07 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 513171ACC8B for ; Wed, 22 Oct 2014 07:48:07 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CAED828D0A67; Wed, 22 Oct 2014 10:48:06 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A7BF0C56-53E2-40CB-9777-E1097ACA7AB6" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Date: Wed, 22 Oct 2014 10:48:06 -0400 Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> To: Jeff Haas X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/QclGSLWv5QbiQIzVCs1U1H4U1RA Cc: Benoit Claise , Farrel Adrian , ospf-chairs@tools.ietf.org, Robert Raszuk , Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:48:10 -0000 --Apple-Mail=_A7BF0C56-53E2-40CB-9777-E1097ACA7AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 22, 2014:10:43 AM, at 10:43 AM, Jeff Haas = wrote: >=20 >=20 > On Oct 22, 2014, at 10:18 AM, Robert Raszuk > wrote: >=20 >> Adrian, >>=20 >> Ah that document I know. But this is almost completely different = topic.=20 >>=20 >> At least to me I2RS is not about configuring OSPF protocol. It is = about collecting and possibly augmenting routing system with data.=20 >>=20 >> On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. >=20 > Just for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go. >=20 > I2RS is not in the business of trying to do the modeling work of other = WG's protocols. =20 >=20 > I2RS is definitely in the business of seeing standardized models = advance so we can hook into them. >=20 > Figuring out the most productive way to have that discussion has = obviously been a bit bumpy. Hence, one of the reasons to have the = rtg-yang-coord list. >=20 > FWIW, I agree with Adrian that the scope of the netmod interim design = sessions has crept a bit out of the expected charter. This isn't to say = that work shouldn't happen, but when it does: > - There needs to be adequate notice (apparently Adrian's biggest = complaint) > - Some mindfulness about group scope needs to be accommodated. >=20 > The comment about taking your ball and going someplace else to play = (meetup.com ) was not worthy of a chair, Tom. While = there's certainly precedent in other orgs of working faster, there's = also similar precent of fork and fracture. For the record, I never suggested we go to meetup.com = anywhere; that was Robert that did. =E2=80=94Tom --Apple-Mail=_A7BF0C56-53E2-40CB-9777-E1097ACA7AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 22, 2014:10:43 AM, at 10:43 AM, Jeff Haas <jhaas@juniper.net> = wrote:


On Oct 22, 2014, at 10:18 AM, = Robert Raszuk <robert@raszuk.net> wrote:

Adrian,

Ah that document I know. But this is = almost completely different topic. 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with data. 

On the other hand Yang model takes care = about instatiation and management of a given protocol. There can be some = little overlap, but does not need to be at = all.

Just = for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go.

I2RS is not in the business of trying = to do the modeling work of other WG's protocols.  

I2RS is definitely in = the business of seeing standardized models advance so we can hook into = them.

Figuring = out the most productive way to have that discussion has obviously been a = bit bumpy.  Hence, one of the reasons to have the rtg-yang-coord = list.

FWIW, I = agree with Adrian that the scope of the netmod interim design sessions = has crept a bit out of the expected charter.  This isn't to say = that work shouldn't happen, but when it does:
- = There needs to be adequate notice (apparently Adrian's biggest = complaint)
- Some mindfulness about group scope = needs to be accommodated.

The comment about taking your ball and going someplace else = to play (meetup.com) was = not worthy of a chair, Tom.  While there's certainly precedent in = other orgs of working faster, there's also similar precent of fork and = fracture.

For the record, I never = suggested we go to meetup.com anywhere; that was Robert that = did.

=E2=80=94Tom


= --Apple-Mail=_A7BF0C56-53E2-40CB-9777-E1097ACA7AB6-- From nobody Wed Oct 22 07:51:15 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505151ACD14 for ; Wed, 22 Oct 2014 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PPdwy-lbglfr for ; Wed, 22 Oct 2014 07:51:10 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9015C1ACD12 for ; Wed, 22 Oct 2014 07:51:10 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so635881ieb.8 for ; Wed, 22 Oct 2014 07:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=92bTACc0Mu4YQoB8BQDiSG9SHJBnnFIgXtkjM1/0QXM=; b=Tff5bHq9rQzl1XJ3uy3Fuuxu3X3ziIF91kupZ6lCE/mYjNZR8f2kOJTAuJ7krbnhRv sH1ip87pfcDsV5d0DjvW71XqIcFf96DrmiaEvY99I/A20dBGYoq0q61jFsUQNsZ7iVYL VvIrM16c2mlGFWzu9Amy8g2RGLo88zG29MFSp/GyEvRjMGEwJhjPT3si+K1caEdffxdT kSkDZmVb4C0qE67Gwb+KsHzSGhgDAYrLLvdUkAVusJjQe2VB5QV81YCsbZv0snUMZDUu wg0iIBFMP7CUlMjAsyfsOyHAd5jBRsBaY7CCtQOrcls0e08QeQZkzw4o5CYd1PVsFOxG hazQ== MIME-Version: 1.0 X-Received: by 10.42.80.143 with SMTP id v15mr4994630ick.54.1413989469957; Wed, 22 Oct 2014 07:51:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 07:51:09 -0700 (PDT) In-Reply-To: <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Date: Wed, 22 Oct 2014 16:51:09 +0200 X-Google-Sender-Auth: _037YfkhJSuW__7GrNeRN-WVRIE Message-ID: From: Robert Raszuk To: Jeff Haas Content-Type: multipart/alternative; boundary=20cf301af5ff12b624050604140b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/3_MVnEZFS51zkdtxAf9tXT-S1kw Cc: Benoit Claise , "Thomas D. Nadeau" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org, Adrian Farrel Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:51:12 -0000 --20cf301af5ff12b624050604140b Content-Type: text/plain; charset=UTF-8 > The comment about taking your ball and going someplace else to > play (meetup.com) was not worthy of a chair, Tom. Jeff, I am not sure I am with you. My point was that whatever tools we have in place should be used. For me - I would highly appreciate if Derek alone would record a sessions and explain his draft. Then publish it on you tube. That's it. Maybe it should not be called interim meeting .. maybe IETF has no name for it, but just progressing work based on the 3 meetings a year + mailing lists seems not to be the most efficient choice these days. There are many ways to improve it. The only question is if IETF is ready for it or not. Cheers, R. On Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas wrote: > > On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: > > Adrian, > > Ah that document I know. But this is almost completely different topic. > > At least to me I2RS is not about configuring OSPF protocol. It is about > collecting and possibly augmenting routing system with data. > > On the other hand Yang model takes care about instatiation and management > of a given protocol. There can be some little overlap, but does not need to > be at all. > > > Just for clarity, the long term goal of Sue's draft was *not* to be a > competing ospf draft, it was to provide enough of an example config base to > demonstrate where I2RS hooks would go. > > I2RS is not in the business of trying to do the modeling work of other > WG's protocols. > > I2RS is definitely in the business of seeing standardized models advance > so we can hook into them. > > Figuring out the most productive way to have that discussion has obviously > been a bit bumpy. Hence, one of the reasons to have the rtg-yang-coord > list. > > FWIW, I agree with Adrian that the scope of the netmod interim design > sessions has crept a bit out of the expected charter. This isn't to say > that work shouldn't happen, but when it does: > - There needs to be adequate notice (apparently Adrian's biggest complaint) > - Some mindfulness about group scope needs to be accommodated. > > The comment about taking your ball and going someplace else to play ( > meetup.com) was not worthy of a chair, Tom. While there's certainly > precedent in other orgs of working faster, there's also similar precent of > fork and fracture. > > -- Jeff > > --20cf301af5ff12b624050604140b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> The comment about = taking your ball and going someplace else to=C2=A0
&= gt; play (meetup.com) was not worthy of a chair, To= m.

Jeff,

I am not sure I am with you. My point was t= hat whatever tools we have in place should be used.=C2=A0

For me - I would highly appreciate if Derek a= lone would record a sessions and explain his draft. Then publish it on you = tube.=C2=A0

<= span style=3D"font-family:arial,sans-serif;font-size:13px">That's it.= =C2=A0

Maybe it should not b= e called interim meeting .. maybe IETF has no name for it, but just progres= sing work based on the 3 meetings a year + mailing lists seems not to be th= e most efficient choice these days. There are many ways to improve it.=C2= =A0

The only question is if = IETF is ready for it or not.=C2=A0

Cheers,
R.

=C2=A0<= /span>


=








On Wed, Oct 22, 2014 at 4:43 PM, Jeff= Haas <jhaas@juniper.net> wrote:

O= n Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> wrote:

Adrian,

Ah that document I know. But this is almost com= pletely different topic.=C2=A0

A= t least to me I2RS is not about configuring OSPF protocol. It is about coll= ecting and possibly augmenting routing system with data.=C2=A0

On the other hand Yang model takes care abou= t instatiation and management of a given protocol. There can be some little= overlap, but does not need to be at all.

=
Just for clarity, the long term goal of Sue's draft was *n= ot* to be a competing ospf draft, it was to provide enough of an example co= nfig base to demonstrate where I2RS hooks would go.

I2RS is not in the business of trying to do the modeling work of other WG= 's protocols. =C2=A0

I2RS is definitely in the= business of seeing standardized models advance so we can hook into them.

Figuring out the most productive way to have that d= iscussion has obviously been a bit bumpy.=C2=A0 Hence, one of the reasons t= o have the rtg-yang-coord list.

FWIW, I agree with= Adrian that the scope of the netmod interim design sessions has crept a bi= t out of the expected charter.=C2=A0 This isn't to say that work should= n't happen, but when it does:
- There needs to be adequate no= tice (apparently Adrian's biggest complaint)
- Some mindfulne= ss about group scope needs to be accommodated.

The= comment about taking your ball and going someplace else to play (meetup.com) was not worthy of = a chair, Tom.=C2=A0 While there's certainly precedent in other orgs of = working faster, there's also similar precent of fork and fracture.

-- Jeff=


--20cf301af5ff12b624050604140b-- From nobody Wed Oct 22 07:52:23 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF301ACD12; Wed, 22 Oct 2014 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6RRXURlFACpR; Wed, 22 Oct 2014 07:52:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 292901ACD15; Wed, 22 Oct 2014 07:52:10 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9C87428D0AA9; Wed, 22 Oct 2014 10:52:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 10:52:09 -0400 Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Andy Bierman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/svH3WHpmRj0k6Ck-Tx_pwKH3gTc Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:52:17 -0000 --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We are trying. The thing is that you cannot just hoist that onto = WGs and say =93here you go.=94 if they don=92t want to do it. Again, = the Netmod charter was specifically modified to accommodate that case. = And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models. It is squarely within = the IETF community=92s interest to bring these back into the fold. Many = of these folks are skittish about coming to the IETF altogether so we=92ve= tried to encourage them to participate in this way. If we want to push = these folks away with procedural reasons, then we have made our bed... =97tom > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = wrote: >=20 > Hi, >=20 > I think the interim did not need to be cancelled. There are ACL, = SYSLOG, > and YANG Mount topics. I was going to call in for those, not OSPF. > But I have been saying (for over a year now) that it is time to move > domain-specific data models into the domain-specific WGs. > I think NETMOD WG should focus on the YANG language and > infrastructure modules. >=20 > Andy >=20 >=20 > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau = > wrote: >=20 > No one said that OSPF experts could not attend to provide input. = The issue is that OSPF was not doing this. If they want to take over = doing all OSPF models, then great, but to date no one was. The = agreement in NETMOD (and our charter) is to facilitate the creation of = models when WGs don=92t want to do them, have the expertise to do them, = etc=85 Also, getting the right Yang experts in one place is not going = to happen for every WG in the IETF; its just not realistic. I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right? >=20 > And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work? The group that was = there to work on the OSPF model was indeed a bunch of folks from OSPF = (Acee Lindem for example was on the call). So now since we won=92t have = another interim meeting until after Hawaii, so the next time this group = can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii. So the net-net is a = slowing of progress in this area. Probably not the result the IETF = community wants. >=20 > =97Tom >=20 >=20 >=20 >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = > wrote: >>=20 >> Hi Adrian, >>=20 >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG = experts to >> help translate that to a data model. (Not the other way around -- a = room >> full of YANG experts and 1 or 2 OSPF experts). >>=20 >> I also prefer that virtual interim meetings be used to discuss open = issues >> on chartered items, not as an additional forum to promote individual = drafts. >>=20 >>=20 >> Andy >>=20 >>=20 >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: >> I understand and appreciate your desire to get work done. >>=20 >> The rules for IETF virtual interims are neither hard to discover, nor = hard to >> comply with. The rules exist to ensure that people are included in = the work, and >> I am sure that inclusion is what you want. >>=20 >> I find it unfortunate that you scheduled a working group meeting to = discuss only >> one of a pair of competing documents on the same topic, that you = didn't make the >> information about the meeting available to the authors of the = competing document >> or to the people who care about the protocol being modelled, and I = find it >> upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a >> document that belongs in the OSPF working group. >>=20 >> If, as it surely sounds, you wish that the Netmod working group had a = different >> charter to enable it to take on models for protocols that already = have a home in >> other working groups, then I suggest you need to recharter. But I = doubt that >> your reasoning that [YANG] experts will not go to all the other = working groups >> will carry much weight. Frankly, and without wanting to disrespect = the YANG >> experts, it is easier to understand YANG than it is to understand = OSPF. If this >> were not the case then the Netmod working group would have failed in = its design >> of YANG! >>=20 >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working = group and >> discuss it (there are already some threads). Review and comment on = the competing >> document. Try to get agreement between all of the authors of both = documents, or >> try to identify the differences. Work with the chairs of the OSPF = working group >> to advance the work. >>=20 >> Adrian >>=20 >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org = ; ops-ads@tools.ietf.org = ; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural = non-sense >> has >> > and IS driving people away from the IETF to other places where this = work is >> going >> > to get done. The simple effect of such silliness will be a = reduction in speed >> and >> > quantity of model development. If the goal of the IESG is to slow = down the >> > velocity of model development and creation, then this approach is = perfect. >> > >> > For the record, the interim NETMOD meeting cadence has one = meeting >> > focused on Yang and the other on modeling; is not NETMOD-specific = per say, but >> > to promote model creation because no other bi-weekly forum exists = to do so. It >> > is also a place to bring in non-IETF work such as the work done in = ODL, other >> open >> > source, or just the public community that has explicitly wanted to = avoid the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and = actually >> *build* >> > models - regardless of their ultimate WG home. The simple reason: = its a >> single >> > place for many of the experts to gather. I think you will find it = very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I = do not think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground = that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft = for which >> there >> > is no milestone in the working group and for which there is an = obvious home >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF = announce list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord = >> > > >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >=20 >=20 --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

We are = trying. The thing is that you cannot just hoist that onto WGs and say = =93here you go.=94 if they don=92t want to do it.  Again, the = Netmod charter was specifically modified to accommodate that case. =   And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models.  It is squarely = within the IETF community=92s interest to bring these back into the = fold.  Many of these folks are skittish about coming to the IETF = altogether so we=92ve tried to encourage them to participate in this = way. If we want to push these folks away with procedural reasons, then = we have made our bed...

= =97tom



On Oct 22, 2014:10:45 AM, at = 10:45 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,
and YANG Mount topics. I was going to call = in for those, not OSPF.
But I have been saying (for = over a year now) that it is time to move
domain-specific data models into the domain-specific = WGs.
I think NETMOD WG should focus on the YANG = language and
infrastructure modules.

Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau = <tnadeau@lucidvision.com> wrote:

= No one said that OSPF experts could not attend to provide input. =   The issue is that OSPF was not doing this. If they want to take = over doing all OSPF models, then great, but to date no one was.  = The agreement in NETMOD (and our charter) is to facilitate the creation = of models when WGs don=92t want to do them, have the expertise to do = them, etc=85  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small =93design team=94 fashion, right?

And in terms of today=92s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won=92t have another interim meeting until after Hawaii, so the = next time this group can get together is possibly in Hawaii, but that is = probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community wants.

=97Tom



On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy = Bierman <andy@yumaworks.com> wrote:

Hi Adrian,

I agree with you. The OSPF WG should be = discussing OSPF data models,
not the NETMOD WG. The = domain experts need to reach consensus
on a feature = set (and maybe info model) and then get 1 or 2 YANG experts to
help translate that to a data model. (Not the other way = around -- a room
full of YANG experts and 1 or 2 = OSPF experts).

I= also prefer that virtual interim meetings be used to discuss open = issues
on chartered items, not as an additional = forum to promote individual drafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:
I understand and = appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor = hard to
comply with. The rules exist to ensure that people are included in the = work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, that you didn't = make the
information about the meeting available to the authors of the competing = document
or to the people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a = different
charter to enable it to take on models for protocols that already have a = home in
other working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other working = groups
will carry much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to understand OSPF. = If this
were not the case then the Netmod working group would have failed in its = design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group = and
discuss it (there are already some threads). Review and comment on the = competing
document. Try to get agreement between all of the authors of both = documents, or
try to identify the differences. Work with the chairs of the OSPF = working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the = kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this = work is
going
> to get done. The simple effect of such silliness will be a = reduction in speed
and
> quantity of model development.  If the goal of the IESG is to = slow down the
> velocity of model development and creation, then this approach is = perfect.
>
>       For the record, the interim NETMOD = meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific = per say, but
> to promote model creation because no other bi-weekly forum exists = to do so. It
> is also a place to bring in non-IETF work such as the work done in = ODL, other
open
> source, or just the public community that has explicitly wanted to = avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and = actually
*build*
> models - regardless of their ultimate WG home.  The simple = reason: its a
single
> place for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach = carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground = that:
> > 1. This interim appears to be meeting to discuss a non-WG = draft for which
there
> is no milestone in the working group and for which there is an = obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF = announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




= --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76-- From nobody Wed Oct 22 07:58:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ED71ACD3D for ; Wed, 22 Oct 2014 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pOff5IImNN4G for ; Wed, 22 Oct 2014 07:58:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D9D1ACD12 for ; Wed, 22 Oct 2014 07:58:03 -0700 (PDT) Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BN1PR05MB124.namprd05.prod.outlook.com (10.255.199.28) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 14:58:02 +0000 Received: from [172.29.33.235] (66.129.241.14) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 14:57:58 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D2EE7EB-BC65-43ED-860F-677B91977522" From: Jeff Haas In-Reply-To: Date: Wed, 22 Oct 2014 10:57:35 -0400 Message-ID: <78625625-D209-4C99-8BFD-ABF396521772@juniper.net> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM2PR07CA0030.namprd07.prod.outlook.com (10.141.52.158) To BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB156; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(377454003)(189002)(24454002)(199003)(76482002)(20776003)(69556001)(83716003)(89996001)(85852003)(15202345003)(4396001)(66066001)(71186001)(77156001)(512954002)(87286001)(15395725005)(105586002)(42186005)(92566001)(86362001)(33656002)(93916002)(104166001)(36756003)(106356001)(99396003)(120916001)(64706001)(95666004)(107046002)(19580395003)(77096002)(230783001)(93886004)(102836001)(101416001)(97736003)(19617315012)(110136001)(31966008)(50986999)(15975445006)(76176999)(40100003)(82746002)(21056001)(62966002)(92726001)(57306001)(50226001)(85306004)(122386002)(19580405001)(80022003)(46102003)(84326002)(87976001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB156; H:[172.29.33.235]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB124; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vx7S1i25WBjV3uML2EBDXi4qKzc Cc: Benoit Claise , Farrel Adrian , ospf-chairs@tools.ietf.org, Robert Raszuk , Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:58:05 -0000 --Apple-Mail=_0D2EE7EB-BC65-43ED-860F-677B91977522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Oct 22, 2014, at 10:48 AM, Thomas D. Nadeau = wrote: > For the record, I never suggested we go to meetup.com anywhere; that = was Robert that did. >=20 My apologies then. I'm replying to mail between too many other things = for proper attention apparently. -- Jeff --Apple-Mail=_0D2EE7EB-BC65-43ED-860F-677B91977522 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
On Oct 22, 2014, at 10:48 AM, Thomas = D. Nadeau <tnadeau@lucidvision.com> = wrote:

For = the record, I never suggested we go to meetup.com anywhere; = that was Robert that did.


My = apologies then.  I'm replying to mail between too many other things = for proper attention apparently.

-- = Jeff

= --Apple-Mail=_0D2EE7EB-BC65-43ED-860F-677B91977522-- From nobody Wed Oct 22 08:00:03 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B69E1ACD3D for ; Wed, 22 Oct 2014 07:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 IdWvuo_rqyCi for ; Wed, 22 Oct 2014 07:59:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB171ACD44 for ; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so2866504qcw.17 for ; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cj3iGMcMU1VSzipn6wkc6g/zNkij9oG3/SQEhvc1fZE=; b=laAgPD4VKeTk8j+T8oqjN866LNfUXYYDWVu37RI3x5jdJSwLm6Rgqvl9LlkXoakmRI n6OVi03dMK/X5zGy+UabCIx0b53lrbluiG+7uiQZG2RXONJNf5TlAH5IzqqkbPEWSKtC h+Bhu1gbxWZgb4LV2HGgvj3LIMmeqK3HPx6QRr/jW1hF00oefc7EDtet2cD/8nbEg4nQ g8DiDC+HcMasoOEdHr6AkAs8g81+CLkW0Kg6G3H3Ba1gznbNPLUs58tB3hfGAprP78ax C9IBu136NckKNuqY30ekWsJ0BhoFvm3CbNGqw5FTpoz2knxWV8b7dJdVt+3a5N4B7j0B q8vA== X-Gm-Message-State: ALoCoQkRDjhhgIxPMLtzO0n8b5KDn6VUF5wd/Dyu5qIIo0Y300gGARkJwDJa04vSum+j/b2T5hrO MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr45031595qgd.36.1413989967045; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:59:26 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:59:26 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c13e4ab3c26605060431fa Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hSMJ5uzJK5o0gprBtCE1Q6vbZP4 Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:59:58 -0000 --001a11c13e4ab3c26605060431fa Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 22, 2014 at 7:52 AM, Thomas D. Nadeau wrote: > > We are trying. The thing is that you cannot just hoist that onto WGs and > say "here you go." if they don't want to do it. Again, the Netmod charter > was specifically modified to accommodate that case. And while some WGs in > the routing area are not enthusiastic about building models, others aren't, > nor are other WGs at the IETF. So for those, what do you do? Ignore them? > The other point is that others outside of the IETF are working on these > models. It is squarely within the IETF community's interest to bring these > back into the fold. Many of these folks are skittish about coming to the > IETF altogether so we've tried to encourage them to participate in this > way. If we want to push these folks away with procedural reasons, then we > have made our bed... > > This "network management scope" discussion has been going on since the early days of SNMP. It's up to the people approving WG charters to ask for configuration, not just monitoring. It's up to the WG members to agree on a common subset of configuration parameters. NETMOD WG can help with the YANG details. --tom > > Andy > > > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: > > Hi, > > I think the interim did not need to be cancelled. There are ACL, SYSLOG, > and YANG Mount topics. I was going to call in for those, not OSPF. > But I have been saying (for over a year now) that it is time to move > domain-specific data models into the domain-specific WGs. > I think NETMOD WG should focus on the YANG language and > infrastructure modules. > > Andy > > > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: > >> >> No one said that OSPF experts could not attend to provide input. The >> issue is that OSPF was not doing this. If they want to take over doing all >> OSPF models, then great, but to date no one was. The agreement in NETMOD >> (and our charter) is to facilitate the creation of models when WGs don't >> want to do them, have the expertise to do them, etc... Also, getting the >> right Yang experts in one place is not going to happen for every WG in the >> IETF; its just not realistic. I understand that ultimately the WG needs to >> have consensus, but quick iteration to construct the model surely can >> happen in a small "design team" fashion, right? >> >> And in terms of today's meeting being canceled, really what purpose was >> that other than to stall/slow-down work? The group that was there to work >> on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for >> example was on the call). So now since we won't have another interim >> meeting until after Hawaii, so the next time this group can get together is >> possibly in Hawaii, but that is probably unlikely as a large number of >> people are not going to Hawaii. So the net-net is a slowing of progress in >> this area. Probably not the result the IETF community wants. >> >> --Tom >> >> >> >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman >> wrote: >> >> Hi Adrian, >> >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG experts >> to >> help translate that to a data model. (Not the other way around -- a room >> full of YANG experts and 1 or 2 OSPF experts). >> >> I also prefer that virtual interim meetings be used to discuss open issues >> on chartered items, not as an additional forum to promote individual >> drafts. >> >> >> Andy >> >> >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel >> wrote: >> >>> I understand and appreciate your desire to get work done. >>> >>> The rules for IETF virtual interims are neither hard to discover, nor >>> hard to >>> comply with. The rules exist to ensure that people are included in the >>> work, and >>> I am sure that inclusion is what you want. >>> >>> I find it unfortunate that you scheduled a working group meeting to >>> discuss only >>> one of a pair of competing documents on the same topic, that you didn't >>> make the >>> information about the meeting available to the authors of the competing >>> document >>> or to the people who care about the protocol being modelled, and I find >>> it >>> upsetting (yes, I am actually upset) that you decided to discuss in >>> Netmod a >>> document that belongs in the OSPF working group. >>> >>> If, as it surely sounds, you wish that the Netmod working group had a >>> different >>> charter to enable it to take on models for protocols that already have a >>> home in >>> other working groups, then I suggest you need to recharter. But I doubt >>> that >>> your reasoning that [YANG] experts will not go to all the other working >>> groups >>> will carry much weight. Frankly, and without wanting to disrespect the >>> YANG >>> experts, it is easier to understand YANG than it is to understand OSPF. >>> If this >>> were not the case then the Netmod working group would have failed in its >>> design >>> of YANG! >>> >>> Conclusion: >>> You want to work on a YANG model for OSPF. Go to the OSPF working group >>> and >>> discuss it (there are already some threads). Review and comment on the >>> competing >>> document. Try to get agreement between all of the authors of both >>> documents, or >>> try to identify the differences. Work with the chairs of the OSPF >>> working group >>> to advance the work. >>> >>> Adrian >>> >>> > -----Original Message----- >>> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >>> > Sent: 22 October 2014 14:29 >>> > To: Benoit Claise >>> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; >>> ops-ads@tools.ietf.org; >>> > rtg-ads@tools.ietf.org >>> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >>> > >>> > >>> > This is hugely disappointing. This is the kind of procedural >>> non-sense >>> has >>> > and IS driving people away from the IETF to other places where this >>> work is >>> going >>> > to get done. The simple effect of such silliness will be a reduction >>> in speed >>> and >>> > quantity of model development. If the goal of the IESG is to slow >>> down the >>> > velocity of model development and creation, then this approach is >>> perfect. >>> > >>> > For the record, the interim NETMOD meeting cadence has one >>> meeting >>> > focused on Yang and the other on modeling; is not NETMOD-specific per >>> say, but >>> > to promote model creation because no other bi-weekly forum exists to >>> do so. It >>> > is also a place to bring in non-IETF work such as the work done in >>> ODL, other >>> open >>> > source, or just the public community that has explicitly wanted to >>> avoid the >>> IETF. >>> > We have found it a convenient and fruitful place to discuss, and >>> actually >>> *build* >>> > models - regardless of their ultimate WG home. The simple reason: its >>> a >>> single >>> > place for many of the experts to gather. I think you will find it very >>> difficult to get >>> > those people onto a per-WG call every other week. >>> > >>> > I hope the IESG considers this approach carefully because I do >>> not think >>> it >>> > will have the affect the larger IETF community is interested in. >>> > >>> > --Tom >>> > >>> > >>> > >>> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise < >>> bclaise@cisco.com> >>> wrote: >>> > > >>> > > Dear all, >>> > > >>> > > Today NETMOD interim meeting is canceled. >>> > > >>> > > I received some pushbacks from the routing ADs, on the ground that: >>> > > 1. This interim appears to be meeting to discuss a non-WG draft for >>> which >>> there >>> > is no milestone in the working group and for which there is an obvious >>> home >>> > outside the working group. >>> > > 2. The agenda was not announced a week in advance on the IETF >>> announce list >>> > as is required >>> > > >>> > > Regards, Benoit >>> > > >>> > > _______________________________________________ >>> > > Rtg-yang-coord mailing list >>> > > Rtg-yang-coord@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> > > >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> > > --001a11c13e4ab3c26605060431fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 22, 2014 at 7:52 AM, Thomas D. Nadeau <= ;tnadeau@lucid= vision.com> wrote:

We are trying. The thing is that you cannot just hoist th= at onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to accommo= date that case.   And while some WGs in the routing area are not enthu= siastic about building models, others aren’t, nor are other WGs at th= e IETF. So for those, what do you do? Ignore them? The other point is that = others outside of the IETF are working on these models.  It is squarel= y within the IETF community’s interest to bring these back into the f= old.  Many of these folks are skittish about coming to the IETF altoge= ther so we’ve tried to encourage them to participate in this way. If = we want to push these folks away with procedural reasons, then we have made= our bed...


This= "network management scope" discussion has been going on since
the early days of SNMP.  It's up to the people approving W= G charters
to ask for configuration, not just monitoring. It'= s up to the WG members
to agree on a common subset of configurati= on parameters. NETMOD WG
can help with the YANG details.


—tom


= Andy
 


On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman <andy@yumaworks.com>= wrote:

Hi,

I think the i= nterim did not need to be cancelled. There are ACL, SYSLOG,
and Y= ANG Mount topics. I was going to call in for those, not OSPF.
But= I have been saying (for over a year now) that it is time to move
domain-specific data models into the domain-specific WGs.
I thin= k NETMOD WG should focus on the YANG language and
infrastructure = modules.

Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas= D. Nadeau <tnadeau@lucidvision.com> wrote:

= No one said that OSPF experts = could not attend to provide input.   The issue is that OSPF was not do= ing this. If they want to take over doing all OSPF models, then great, but = to date no one was.  The agreement in NETMOD (and our charter) is to f= acilitate the creation of models when WGs don’t want to do them, have= the expertise to do them, etc…  Also, getting the right Yang e= xperts in one place is not going to happen for every WG in the IETF; its ju= st not realistic.  I understand that ultimately the WG needs to have c= onsensus, but quick iteration to construct the model surely can happen in a= small “design team” fashion, right?

And in terms of today’s meeting= being canceled, really what purpose was that other than to stall/slow-down= work?  The group that was there to work on the OSPF model was indeed = a bunch of folks from OSPF (Acee Lindem for example was on the call). = So now since we won’t have another interim meeting until after Hawai= i, so the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to Hawa= ii.  So the net-net is a slowing of progress in this area.  Proba= bly not the result the IETF community wants.

—Tom

<= br>

On Oct 22, 2014:10:18= AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi Adrian,

I agree with you. The OSPF WG should be= discussing OSPF data models,
not the NETMOD WG. The domain exper= ts need to reach consensus
on a feature set (and maybe info model= ) and then get 1 or 2 YANG experts to
help translate that to a da= ta model. (Not the other way around -- a room
full of YANG expert= s and 1 or 2 OSPF experts).

I also prefer that vir= tual interim meetings be used to discuss open issues
on chartered= items, not as an additional forum to promote individual drafts.
=

Andy


On Wed, Oct 22, 2014 at 6:4= 8 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
I understand and appreciate your desire to get wor= k done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod





--001a11c13e4ab3c26605060431fa-- From nobody Wed Oct 22 08:01:09 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C01ACD38 for ; Wed, 22 Oct 2014 08:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1tvhE88D9ST8 for ; Wed, 22 Oct 2014 08:00:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA8F1ACD1E for ; Wed, 22 Oct 2014 08:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40383; q=dns/txt; s=iport; t=1413990046; x=1415199646; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LHk0Z9UFNGExdoRFPEBxVRjvVjLQOK2vlrwzVGsb1ZQ=; b=lmk2+QU2KrzDuFrauixBnapZBeU0Nd/WVUKdLk4KgHo+L8byVFWeUx3j VSXo5aBTOoBKaZCNypH7VwnBcSrJMasHkAabdx32+hH+EpLzeBgybCXU+ Tv4mM7tTUSjJDDPJD3Idf1A5obQbuVW9Xp2GTbsmMlGTb/VxMsfMbjkRu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAAHGR1StJV2S/2dsb2JhbABSCoJIIyNUWASFYrY9jk6BZgEJh00CgQwWAX2EAgEBAQQBAQEqPgMLDAQCAQgRAwEBAQEgAQYHIQUBCxQJCAIEAQ0EARSIGAMRAQy/RA2GOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReOIoFZMQcTDQQGAQIEhEUFkgSERoUCghGBMTyNYIJchAGDeGyBBgQ+gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365455660" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2014 15:00:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9MF0iFZ031642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:00:44 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:00:43 -0500 From: "Ken Gray (kegray)" To: "adrian@olddog.co.uk" , "'Robert Raszuk'" Thread-Topic: [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7fponBbCtazo1U+gGjlyl04uZJw8cESAgAAFcQCAAAOSgIAAA0WA///KJ4A= Date: Wed, 22 Oct 2014 15:00:42 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> In-Reply-To: <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.212] Content-Type: multipart/alternative; boundary="_000_D06D3EB95B45Fkegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/gBpW2s33LpytyVLCMBgF1dy1puw Cc: "Benoit Claise \(bclaise\)" , "'Thomas D. Nadeau'" , "ospf-chairs@tools.ietf.org" , "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:00:58 -0000 --_000_D06D3EB95B45Fkegrayciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is this also the competing draft you referred to? From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, October 22, 2014 10:13 AM To: 'Robert Raszuk' > Cc: "Benoit Claise (bclaise)" >= , "'Thomas D. Nadeau'" >, "ospf-chairs@tools.ietf.org" >, "Rtg-yang-coor= d@ietf.org" > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Robert, http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ Yes, it is in the wrong WG as well. No, I can't point to it being discussed on the OSPF list. Not sure that fac= t proves anything. Adrian From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Adrian, What other competing OSPF yang model are you referring to? Can you provide link to discussions about that other model on OSPF WG list = taking place ? Thx, R. On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord --_000_D06D3EB95B45Fkegrayciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <48C80BBD2E305943BD0923E1A7A18C10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Is this also the competing draft you referred to?

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, October 22, 2014 1= 0:13 AM
To: 'Robert Raszuk' <robert@raszuk.net>
Cc: "Benoit Claise (bclaise)&q= uot; <bclaise@cisco.com>, &q= uot;'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.o= rg>, "Rtg-yang-coord= @ietf.org" <Rtg-yang= -coord@ietf.org>
Subject: Re: [Rtg-yang-coord] NETMO= D interim meeting canceled

Hi Robert,

 

http://datatracker.ietf.org/doc/draft-wa= ng-i2rs-ospf-dm/

 

Yes, it is in the wrong WG as well= .

 

No, I can't point to it being disc= ussed on the OSPF list. Not sure that fact proves anything.

 

Adrian

 

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: 22 October 2014 15:02
To: Adrian Farrel
Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled

 

Hi Adri= an,

&n= bsp;

What ot= her competing OSPF yang model are you referring to? =

&n= bsp;

Can you= provide link to discussions about that other model on OSPF WG list taking = place ? 

&n= bsp;

Thx,

R.=

&n= bsp;

 

On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 --_000_D06D3EB95B45Fkegrayciscocom_-- From nobody Wed Oct 22 08:03:35 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC911ACD1E; Wed, 22 Oct 2014 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YRHDWUaWCG-n; Wed, 22 Oct 2014 08:03:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BE61ACD2A; Wed, 22 Oct 2014 08:03:09 -0700 (PDT) Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BN1PR05MB076.namprd05.prod.outlook.com (10.255.199.26) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:03:08 +0000 Received: from [172.29.33.235] (66.129.241.14) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:03:03 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset="windows-1252" From: Jeff Haas In-Reply-To: Date: Wed, 22 Oct 2014 11:02:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR00CA0040.namprd00.prod.outlook.com (25.160.142.178) To BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB156; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(51704005)(377454003)(189002)(24454002)(40100003)(76176999)(82746002)(21056001)(50466002)(102836001)(31966008)(50986999)(97736003)(101416001)(110136001)(46102003)(80022003)(87976001)(62966002)(50226001)(122386002)(85306004)(19580405001)(57306001)(92726001)(86362001)(92566001)(93916002)(33656002)(87286001)(42186005)(105586002)(104166001)(20776003)(76482002)(66066001)(77156001)(89996001)(83716003)(4396001)(47776003)(85852003)(23746002)(107046002)(19580395003)(230783001)(93886004)(77096002)(36756003)(99396003)(106356001)(120916001)(95666004)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB156; H:[172.29.33.235]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB076; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/sw7-Af59NUfnGhWaEhZvbc7SKf0 Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, Andy Bierman , rtg-ads@tools.ietf.org, Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:03:17 -0000 On Oct 22, 2014, at 10:52 AM, Thomas D. Nadeau = wrote: >=20 > We are trying. The thing is that you cannot just hoist that onto = WGs and say =93here you go.=94 if they don=92t want to do it. Again, = the Netmod charter was specifically modified to accommodate that case. = And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models. It is squarely within = the IETF community=92s interest to bring these back into the fold. Many = of these folks are skittish about coming to the IETF altogether so we=92ve= tried to encourage them to participate in this way. If we want to push = these folks away with procedural reasons, then we have made our bed... I've had part of this conversation with Alia recently and with many = others at the prior IETF, including Benoit. That was part of the = motivation to form the rtg-yang-coord list. Simply put, modeling work = needs to happen but the subset of people who actively care about it in = any particular WG is usually a fraction of the participants. = Additionally, the danger of doing it in netmod is overloading people who = are wanting to work on the language but don't necessarily want to = contribute to a given bit of modeling effort. I don't know that the "coord" efforts need a full WG, but the semantics = of managing that at an IETF process perspective are something the IESG = cares more about than I think I do. Basically, coord is likely to be a = bunch of dynamically spun design teams, hopefully reporting back their = lessons to someplace like this list. -- Jeff From nobody Wed Oct 22 08:04:43 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5F01A8821; Tue, 21 Oct 2014 16:32:07 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 hfIv5E0fqoD8; Tue, 21 Oct 2014 16:32:05 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FAA1A87DB; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so1862546oia.27 for ; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:reply-to:mime-version :content-type; bh=z5vj4qpFBRbUl7VyLVhCrvddWw5yZHTJKaaJ8zu4Vxw=; b=k/xqEZr8p6tuJFSRQ6/fDOkPBX6ZJofmegouqQfITuUsfvcCZzankOcKr8ZLZmXYIu 89vkIS0xktzwoKQt/IyKiySuYSuEVk277Uv+EieVvDbtFtD3GRvkuxMx0chRJflDjtP7 HGeU0UXt4uihhQH1mjZ23fUAMyM5YeRd3GHlCtTSPrYv3TwhHuSS+Ou4f0nFeqPHtVIA s94aL4rf4aNenoeSn0SF6ZxH1vCEAyBULB50jQhBT0u3n8E8EuyRRNymsfXSRAuSsKqY O1YXeGz5Lk6YtqQX0/BOFw1Zqf3iF9rBO6c0ynLEntXkIn17S+0Wth673EmkZYbL+OV6 qmeA== X-Received: by 10.182.165.36 with SMTP id yv4mr12107929obb.39.1413934324505; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) Received: from [10.182.83.224] ([32.144.61.15]) by mx.google.com with ESMTPSA id e1sm1879723obn.11.2014.10.21.16.32.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 16:32:03 -0700 (PDT) Date: Tue, 21 Oct 2014 16:31:56 -0700 Message-ID: Importance: normal From: rapenno To: tnadeau@lucidvision.com, netmod@ietf.org, rtg-yang-coord@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_499544408436670" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Yal6MQfFX5_RBWkN6VswMDS16m4 X-Mailman-Approved-At: Wed, 22 Oct 2014 08:04:38 -0700 Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rapenno List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:32:07 -0000 ----_com.android.email_499544408436670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgU0ZDIHlhbmcgbW9kZWxuaWYgdGltZSBwZXJtaXRzCgoK U2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tCkZyb206ICJUaG9tYXMgRC4gTmFkZWF1IiA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IApE YXRlOiAgClRvOiBORVRNT0QgV29ya2luZyBHcm91cCA8bmV0bW9kQGlldGYub3JnPixydGcteWFu Zy1jb29yZEBpZXRmLm9yZyAKU3ViamVjdDogW25ldG1vZF0gaW50ZXJpbSBtZWV0aW5nOiB5YW5n IG1vZGVsIGZvY3VzIAogClthZGRpbmfCoCBydGcteWFuZy1jb29yZF0KCgpUb21vcnJvdydzIG1l ZXRpbmcgd2lsbCB1c2UgdGhlIHNhbWUgV2ViRXggZnJvbSBsYXN0IHRpbWUgKGFuZCB0aGUgc2Ft ZSBhcyB3YXMgdXNlZCBsYXN0IHdlZWsgYXQgdGhlIFlhbmcgMS4xLWZvY3VzZWQgbWVldGluZyku IAoKVG9tb3Jyb3cncyBpbnRlcmltIG1lZXRpbmcgaGFzIHRoZSBmb2xsb3dpbmcgcHJlbGltaW5h cnkgYWdlbmRhOgoKMCkgUXVpY2tseSBob3cgdG8gdXNlIElSQy9zaWduLWluCjEpIE5vdGUgV2Vs bAoyKSBBZ2VuZGEgQmFzaGluZwozKSBPU1BGIE1vZGVsIC0gS2lyYW4gQWdyYWhhcmEgU3JlZW5p dmFzYSA8a2tvdXNoaWtAQnJvY2FkZS5jb20+OyBteWV1bmdAY2lzY28uY29tCgoKQXJlIHRoZXJl IGFueSBvdGhlciBtb2RlbHMgcGVvcGxlIHdpc2ggdG8gZGlzY3Vzcz8KCi0tVG9tCgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCg== ----_com.android.email_499544408436670 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48ZGl2PjwvZGl2PjxkaXY+ SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgU0ZDIHlhbmcgbW9kZWxuaWYgdGltZSBwZXJtaXRzPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2 PjwvZGl2PiA8YnI+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJy PkZyb206ICJUaG9tYXMgRC4gTmFkZWF1IiAmbHQ7dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20mZ3Q7 IDxicj5EYXRlOiAgPGJyPlRvOiBORVRNT0QgV29ya2luZyBHcm91cCAmbHQ7bmV0bW9kQGlldGYu b3JnJmd0OyxydGcteWFuZy1jb29yZEBpZXRmLm9yZyA8YnI+U3ViamVjdDogW25ldG1vZF0gaW50 ZXJpbSBtZWV0aW5nOiB5YW5nIG1vZGVsIGZvY3VzIDxicj4gPGJyPjxicj5bYWRkaW5nJm5ic3A7 IHJ0Zy15YW5nLWNvb3JkXTxicj48YnI+PGJyPglUb21vcnJvdydzIG1lZXRpbmcgd2lsbCB1c2Ug dGhlIHNhbWUgV2ViRXggZnJvbSBsYXN0IHRpbWUgKGFuZCB0aGUgc2FtZSBhcyB3YXMgdXNlZCBs YXN0IHdlZWsgYXQgdGhlIFlhbmcgMS4xLWZvY3VzZWQgbWVldGluZykuIDxicj48YnI+CVRvbW9y cm93J3MgaW50ZXJpbSBtZWV0aW5nIGhhcyB0aGUgZm9sbG93aW5nIHByZWxpbWluYXJ5IGFnZW5k YTo8YnI+PGJyPgkwKSBRdWlja2x5IGhvdyB0byB1c2UgSVJDL3NpZ24taW48YnI+CTEpIE5vdGUg V2VsbDxicj4JMikgQWdlbmRhIEJhc2hpbmc8YnI+CTMpIE9TUEYgTW9kZWwgLSBLaXJhbiBBZ3Jh aGFyYSBTcmVlbml2YXNhICZsdDtra291c2hpa0BCcm9jYWRlLmNvbSZndDs7IG15ZXVuZ0BjaXNj by5jb208YnI+CTxicj48YnI+CUFyZSB0aGVyZSBhbnkgb3RoZXIgbW9kZWxzIHBlb3BsZSB3aXNo IHRvIGRpc2N1c3M/PGJyPjxicj4JLS1Ub208YnI+PGJyPjxicj48YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bmV0bW9kIG1haWxpbmcgbGlzdDxi cj5uZXRtb2RAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2Q8YnI+PC9ib2R5Pg== ----_com.android.email_499544408436670-- From nobody Wed Oct 22 08:04:45 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB11A9039; Wed, 22 Oct 2014 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 uvkDDUT4mZsT; Wed, 22 Oct 2014 06:44:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374D81A8BC4; Wed, 22 Oct 2014 06:44:56 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 47D67264163; Wed, 22 Oct 2014 15:44:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2329527C080; Wed, 22 Oct 2014 15:44:54 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.32]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 15:44:53 +0200 From: To: Benoit Claise Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7fw5+PxAzPUz9k62C+BUuKxA2pw8HYRg Date: Wed, 22 Oct 2014 13:44:54 +0000 Message-ID: <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.22.123024 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/28x6QvYIxZws329UmeNvqwymdaQ X-Mailman-Approved-At: Wed, 22 Oct 2014 08:04:38 -0700 Cc: "Rtg-yang-coord@ietf.org" , "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:44:59 -0000 Hi, I also agree that this is a bad idea. I thought that IETF willing and espec= ially yours, Benoit, was to speed up availability of standard models. The p= rocess of having small teams working with weekly calls works almost good bu= t we still have some issue that are both technical (dedicated to the topic = addressed by the model) and also YANG writing, model consistencies ... that= requires discussion, and as often mailing list is not as good as meetings = (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim = meetings in Netmod to discuss proposed Yang models : this will ensure consi= stency between models and will help to solve global issues in modeling. It'= s just the starting of Yang modeling, leaving only Yang models within home = WG (ISIS for my point of view) would be, IMO, a very bad idea and will for = sure slow down the availability of standards ... and I also think that it m= ay discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has= and IS driving people away from the IETF to other places where this work i= s going to get done. The simple effect of such silliness will be a reductio= n in speed and quantity of model development. If the goal of the IESG is t= o slow down the velocity of model development and creation, then this appro= ach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused= on Yang and the other on modeling; is not NETMOD-specific per say, but to = promote model creation because no other bi-weekly forum exists to do so. It= is also a place to bring in non-IETF work such as the work done in ODL, ot= her open source, or just the public community that has explicitly wanted to= avoid the IETF. We have found it a convenient and fruitful place to discu= ss, and actually *build* models - regardless of their ultimate WG home. Th= e simple reason: its a single place for many of the experts to gather. I th= ink you will find it very difficult to get those people onto a per-WG call = every other week.=20=20 I hope the IESG considers this approach carefully because I do not think i= t will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wr= ote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for which= there is no milestone in the working group and for which there is an obvio= us home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce li= st as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 22 08:06:02 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300071ACD2B for ; Wed, 22 Oct 2014 08:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 tUXsjdcJUyJK for ; Wed, 22 Oct 2014 08:05:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A591ACD2A for ; Wed, 22 Oct 2014 08:05:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MF5lMX029487; Wed, 22 Oct 2014 16:05:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MF5gih029274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 16:05:43 +0100 From: "Adrian Farrel" To: "'Ken Gray \(kegray\)'" , "'Robert Raszuk'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 16:05:34 +0100 Message-ID: <02fa01cfee09$a6a98e80$f3fcab80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FB_01CFEE12.08743810" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAm29oMybXR/6YA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--18.644-10.0-31-10 X-imss-scan-details: No--18.644-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFoaLqU/h9ua5ClrosmS0SOAGSqdEmeD/nX9k2xa9Ahjg3F7 B2/x0GhM5/YU4rlo+3j+w331TsHWu6y3evgPNvKda5lVJeppVhVflOpBqBHTt23KWDl9esQFRGa WoQROZ8SWf9DAJ4uY0nMALj+Bc9Hv1QQDT0/WZj92cLm5pLq1v/a/bRHEsPI3kzE2kM4b6HoRfj liohTl1Lr4TgsPGSC0nYDoSt+wnM8sXJM82Uy2JhK6EFc0lvV0fkuZtv/FS5rUO0feag9puXwsT 5jF3WC+DnT4kQGtoOmAzubyz8pLMV2kuSHmn3uDaDCzqDR7DPaVq+okl1rYD3FXWqTyKq+olwWf 7/4SyDubpMJXRDeJWhJhbyRegSo7ScozMdeflm4dtDYAlaXrIClayzmQ9QV0ZJY6r7aDSHavl/2 a05OHdOjgx8gQXh327wAn1FLrNdBORqpsHSbewszWN98iBBeGF4q8hdmZvAgliEgA8kcviaoOsH Egyw+DyKsgLu7aMJ1gxImbR9V41S0huMCkGGV4EPf7TDUOGoq/yN2q8U674leilmPI7oJlcBdH+ AtoPBpOHnNn+XwQAi0vtezhzWhsbgb7V3z8nAmTEgTE0DYkgDB8vFkEGJpMJI+58l8cFjNh4Y/i 1VqWII9Zm8Ov7SprPDF4aOlLYwdKl5uDD6k69rU+IyHhkXf131asM/gsp2mpVUR0SvYtSv4ZAUs ty2ENewo8j91GeTG6RgENsA/90MsesOAiftrl9iItFUn3XkM7r2Gtb9iBYU8dFP+NPq6+2ugQZC K503LnS2T1VubAzXnccn/22kNHm9qITc9BfqSeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7ARE6GKKq2/yec3QM3secWbnXCB/J9VnxyaDVi0RZ+pXzzUKw60jFZuizX3x3vwlW+OBeSfE C+Bu6tPrcrWnbucQGhLJwsS0ptn4uSj5EsyzVybjBB9Yicx+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/ETeKTgemHlknDNdBtQI4EbL4cno Cc: "'Benoit Claise \(bclaise\)'" , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:06:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FB_01CFEE12.08743810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. And, as Jeff explains, it is not intended to compete. Perhaps "feed into" would be a good term. And as Robert notes, the overlap can be handled in discussion. It's great that we have venues to discuss this work. I hope we can advance it quickly. Doing so "in secret" will, however, not end well for anyone. Adrian From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Ken Gray (kegray) Sent: 22 October 2014 16:01 To: adrian@olddog.co.uk; 'Robert Raszuk' Cc: Benoit Claise (bclaise); 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Is this also the competing draft you referred to? From: Adrian Farrel Reply-To: "adrian@olddog.co.uk" Date: Wednesday, October 22, 2014 10:13 AM To: 'Robert Raszuk' Cc: "Benoit Claise (bclaise)" , "'Thomas D. Nadeau'" , "ospf-chairs@tools.ietf.org" , "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Robert, http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ Yes, it is in the wrong WG as well. No, I can't point to it being discussed on the OSPF list. Not sure that fact proves anything. Adrian From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Adrian, What other competing OSPF yang model are you referring to? Can you provide link to discussions about that other model on OSPF WG list taking place ? Thx, R. On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord ------=_NextPart_000_02FB_01CFEE12.08743810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes.

And, as Jeff explains, it is not intended to = compete. Perhaps "feed into" would be a good = term.

And as Robert notes, the overlap can be handled in = discussion.

 

It's great that we have venues to discuss this = work. I hope we can advance it quickly. Doing so "in secret" = will, however, not end well for anyone.

 

Adrian

 

From: Rtg-yang-coord = [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Ken Gray = (kegray)
Sent: 22 October 2014 16:01
To: = adrian@olddog.co.uk; 'Robert Raszuk'
Cc: Benoit Claise = (bclaise); 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD = interim meeting canceled

 

Is this also the competing = draft you referred to?

 

From: Adrian Farrel <adrian@olddog.co.uk>
Rep= ly-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Dat= e: Wednesday, October 22, 2014 10:13 AM
To: 'Robert = Raszuk' <robert@raszuk.net>
Cc: = "Benoit Claise (bclaise)" <bclaise@cisco.com>, = "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, = "ospf-chairs@tools.ietf.org= " <ospf-chairs@tools.ietf.org= >, "Rtg-yang-coord@ietf.org"= <Rtg-yang-coord@ietf.org>Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Hi Robert,

 

http://= datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/

 

Yes, it is in the wrong WG as well.

 

No, I can't point to it being discussed on the OSPF list. Not sure = that fact proves anything.

 

Adrian

 

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On = Behalf Of Robert Raszuk
Sent: 22 October 2014 = 15:02
To: Adrian Farrel
Cc: Thomas D. Nadeau; Benoit = Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org=
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Hi Adrian,

 

What other competing OSPF yang model are you referring = to? 

 

Can you provide link to discussions about that other = model on OSPF WG list taking place ? 

 

Thx,

R.

 

 

On Wed, Oct 22, 2014 at = 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

I understand and appreciate your desire to get = work done.

The rules for IETF virtual interims are neither hard = to discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian


> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
Rtg-yang-c= oord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 

------=_NextPart_000_02FB_01CFEE12.08743810-- From nobody Wed Oct 22 08:09:08 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B158F1ACD26; Wed, 22 Oct 2014 08:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4j_Eunw1Ry4c; Wed, 22 Oct 2014 08:09:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBAC1ACD41; Wed, 22 Oct 2014 08:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16397; q=dns/txt; s=iport; t=1413990532; x=1415200132; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8JaLiMzXeZSJIl6+mHVQ0Ix8R+ft/MNW4vUkzgEQNGM=; b=HRZkRwYVTySyJKflXNDzvZ1lTQ1bVSH1UXhkUbRqjoJSg/SJgPRAsh0w RDQpmDePoQ1/G3+SEmzWkM/Wmza+MEePv2rvbqO2t0ZTqsGtj3sd//w6B N9oh06boeR1vW6tWE57abj2LmpxexOSDePqLnplyHNrGZykgP7C3lvKFt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFABnIR1StJA2I/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQQBAQFoAwsMBAIBCBEDAQEBAScHJwsUCQgCBAENBRSILA3GDQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3sxGg0EBwIEhEUFkgSLWYExkHiEAYN4bIEGBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365687555" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2014 15:08:50 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9MF8osT006549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:08:50 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:08:50 -0500 From: "Acee Lindem (acee)" To: Andy Bierman , Adrian Farrel Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7f741i3foC0Vi02jGmQDSDEWupw8fdwA///LCoA= Date: Wed, 22 Oct 2014 15:08:43 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.202] Content-Type: multipart/alternative; boundary="_000_D06D40766103aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/xMVqSjD7KwviI8YzbUHWrPHzVkw Cc: "Rtg-yang-coord@ietf.org" , "Thomas D. Nadeau" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "Benoit Claise \(bclaise\)" Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:09:05 -0000 --_000_D06D40766103aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, The OSPF YANG model is on the agenda for IETF 91. We do plan to more = forward and poll for OSPF WG adoption as well. Thanks, Acee From: Andy Bierman > Date: Wednesday, October 22, 2014 at 10:18 AM To: Adrian Farrel > Cc: "Thomas D. Nadeau" >, "Benoit Claise (bclaise)" >, "Rtg-yang-coord@ietf.org" >, "ospf-chairs@tools.ietf.org<= mailto:ospf-chairs@tools.ietf.org>" >, "ops-ads@tools.ietf.org" >, NETMOD Work= ing Group >, Routing ADs > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Resent-From: > Resent-To: Acee Lindem >, > Resent-Date: Wednesday, October 22, 2014 at 10:18 AM Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D06D40766103aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F0FCEF5437440489CB5A66E95971934@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
FWIW, The OSPF YANG model is on the agenda for IETF 91. We do plan to = more forward and poll for OSPF WG adoption as well. 

Thanks,
Acee 

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 22, 2014 a= t 10:18 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "Thomas D. Nadeau" &l= t;tnadeau@lucidvision.com>= ;, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org= >, "ospf-chairs@tools= .ietf.org" <ospf-= chairs@tools.ietf.org>, "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org&g= t;, NETMOD Working Group <netmod@ietf= .org>, Routing ADs <rtg= -ads@tools.ietf.org>
Subject: Re: [netmod] [Rtg-yang-coo= rd] NETMOD interim meeting canceled
Resent-From: <wg-alias-bounces@tools.ietf.org> Resent-To: Acee Lindem <acee@cisco.com>, <akr@cisco.com>
Resent-Date: Wednesday, October 22,= 2014 at 10:18 AM

Hi Adrian,

I agree with you. The OSPF WG should be discussing OSPF data models,
not the NETMOD WG. The domain experts need to reach consensus
on a feature set (and maybe info model) and then get 1 or 2 YANG exper= ts to
help translate that to a data model. (Not the other way around -- a ro= om
full of YANG experts and 1 or 2 OSPF experts).

I also prefer that virtual interim meetings be used to discuss open is= sues
on chartered items, not as an additional forum to promote individual d= rafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <= span dir=3D"ltr"> <adrian@olddog.= co.uk> wrote:
I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; R= tg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--_000_D06D40766103aceeciscocom_-- From nobody Wed Oct 22 08:22:12 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7889A1ACD4E; Wed, 22 Oct 2014 08:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 l-kjSorJUC-d; Wed, 22 Oct 2014 08:20:18 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13C01ACD5D; Wed, 22 Oct 2014 08:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26159; q=dns/txt; s=iport; t=1413991217; x=1415200817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/7fCZJ3P5Qv1a4X7kECSHMXQ4CQgQKjreQx8brnhbvs=; b=VWXjwyVNSo9HTrf7Jk71ldv8Oj/McV1sbMWAUG8Og+/ENY2Bnbt0gfiQ mzVVur79qctyao5a8lNwRWPmmZPiGLDvKIoCntKYIVXY07N6NuA5m+sk9 OOZyNFhbGrN7f9mKAyC2/6Uw6daFhG/+qAREzkWQ164phoVq1vNI2K5CO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADzKR1StJA2F/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQQBAQEqPgMLDAQCAQgRBAEBAQoWBwcnCxQJCAIEAQ0FCAwLiCENxhABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpWhSUrLQQGAQaDJ4EeBY9mgh6NCpB4hAGDeGyBBgQ+gQMBAQE X-IronPort-AV: E=Sophos; i="5.04,769,1406592000"; d="scan'208,217"; a="89367887" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 22 Oct 2014 15:20:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9MFKE5M006119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:20:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:20:14 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , Andy Bierman Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7gfB9u4QKYuEX+hUMOEGGRuotpw8OMTQ Date: Wed, 22 Oct 2014 15:20:13 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/rBTkt3sAULkaI5D7uHGefly4HqI X-Mailman-Approved-At: Wed, 22 Oct 2014 08:21:59 -0700 Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:20:25 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From: Thomas D= . Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_-- From nobody Wed Oct 22 08:22:25 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34741ACD43; Wed, 22 Oct 2014 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fyppdtmT_B7o; Wed, 22 Oct 2014 08:14:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBE41ACD41; Wed, 22 Oct 2014 08:14:46 -0700 (PDT) Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BN1PR05MB375.namprd05.prod.outlook.com (10.141.61.20) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 15:14:44 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:14:42 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 15:14:42 +0000 From: Dean Bogdanovic To: Jeff Haas Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7gVrfUczFMowvkyLdK/qmvzsppw8MZkAgAAB3oCAAALwAIAAA1mA Date: Wed, 22 Oct 2014 15:14:41 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB156;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(377454003)(189002)(51444003)(24454002)(40100003)(15975445006)(76176999)(82746002)(21056001)(561944003)(31966008)(50986999)(97736003)(101416001)(110136001)(46102003)(87936001)(80022003)(62966002)(50226001)(85306004)(19580405001)(57306001)(92726001)(1941001)(86362001)(92566001)(93916002)(33656002)(87286001)(105586002)(104166001)(2656002)(20776003)(76482002)(99286002)(66066001)(106116001)(77156001)(89996001)(83716003)(4396001)(85852003)(107046002)(19580395003)(230783001)(93886004)(122556002)(77096002)(36756003)(99396003)(106356001)(120916001)(95666004)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB156; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <6BDEB33396187D4CA9AB41DCE6BCEBA6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB375; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/uhsnb-MmlBkwzfAPUyn-oZ8IuQU X-Mailman-Approved-At: Wed, 22 Oct 2014 08:22:14 -0700 Cc: "Rtg-yang-coord@ietf.org" , "Thomas D. Nadeau" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , Andy Bierman , "rtg-ads@tools.ietf.org" , Benoit Claise , Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:14:49 -0000 On Oct 22, 2014, at 11:02 AM, Jeff Haas wrote: >=20 > On Oct 22, 2014, at 10:52 AM, Thomas D. Nadeau = wrote: >=20 >>=20 >> We are trying. The thing is that you cannot just hoist that onto WGs an= d say =93here you go.=94 if they don=92t want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren=92t, nor are other WGs at the IETF. So for those, what do you do? Ig= nore them? The other point is that others outside of the IETF are working o= n these models. It is squarely within the IETF community=92s interest to b= ring these back into the fold. Many of these folks are skittish about comi= ng to the IETF altogether so we=92ve tried to encourage them to participate= in this way. If we want to push these folks away with procedural reasons, = then we have made our bed... >=20 > I've had part of this conversation with Alia recently and with many other= s at the prior IETF, including Benoit. That was part of the motivation to = form the rtg-yang-coord list. Simply put, modeling work needs to happen bu= t the subset of people who actively care about it in any particular WG is u= sually a fraction of the participants. Additionally, the danger of doing i= t in netmod is overloading people who are wanting to work on the language b= ut don't necessarily want to contribute to a given bit of modeling effort. >=20 > I don't know that the "coord" efforts need a full WG, but the semantics o= f managing that at an IETF process perspective are something the IESG cares= more about than I think I do. Basically, coord is likely to be a bunch of= dynamically spun design teams, hopefully reporting back their lessons to s= omeplace like this list. This is a good proposal. We need to be more dynamic with model creations an= d need people who are experts in the area. But absolutely have to be better= coordinated. I think that rtg-yang-coord is a good start, but we need such= a alias for other areas too. Since I was part of a (call it experiment/try= ) for ACL and OSPF models, I think it was a good way to create vendor neutr= al models. It might be not the fastest way, but it was very productive. Cou= ld have we been faster with the models? Yes, but then our paying day job wo= uld suffer, so we are running into same problems as all other volunteering = based projects. It is obvious that we need a more flexibility within IETF, = but also the efforts have to be better coordinated. Dean >=20 > -- Jeff >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Oct 22 08:25:30 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8B1ACD62 for ; Wed, 22 Oct 2014 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pnfvJN_c6nqL for ; Wed, 22 Oct 2014 08:25:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48901ACD9F for ; Wed, 22 Oct 2014 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50703; q=dns/txt; s=iport; t=1413991444; x=1415201044; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TafzqMWHsEnpzZqirVlLb7PUJzfrRV9448c5Mj+FJVk=; b=JcBmkzUIwbKkJtA116ZfjLwTDd8wqBIfVgCiFVdsEzv2APw17E2E3SMe JUPP5CC+uNJMe1jlsQ5uFxx5afqvjZLvYO4L1WRGJvrrw7TI7JA8wANzL I5POSnXQ2IMLf08rqdH7iGk0mjuXrph6bt4QYIlHhRAM8yHS0w2aWhjPe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAGzLR1StJA2K/2dsb2JhbABSCoJIIyNUWASFYrY9jk6BZgEJh00CgQwWAX2EAgEBAQQBAQEqPgMLDAQCAQgRAwEBAQEgAQYHIQUBCxQJCAIEAQ0EARSIGAMRAQy/Tw2GOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKVoNMgVkxBxMNBAYBAgSERQWSBIRGhQKCEYExPI1gglyEAYN4bIEGBD6BAwEBAQ X-IronPort-AV: E=Sophos; i="5.04,769,1406592000"; d="scan'208,217"; a="89370618" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 22 Oct 2014 15:24:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9MFO2uG032242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:24:02 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:24:02 -0500 From: "Ken Gray (kegray)" To: "adrian@olddog.co.uk" , "'Robert Raszuk'" Thread-Topic: [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7fponBbCtazo1U+gGjlyl04uZJw8cESAgAAFcQCAAAOSgIAAA0WA///KJ4CAAERrAP//whYA Date: Wed, 22 Oct 2014 15:24:01 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <02fa01cfee09$a6a98e80$f3fcab80$@olddog.co.uk> In-Reply-To: <02fa01cfee09$a6a98e80$f3fcab80$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.212] Content-Type: multipart/alternative; boundary="_000_D06D40B65B46Dkegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/7fTcCPOtn4bPuIyz7yFRUzK2zA8 Cc: "Benoit Claise \(bclaise\)" , "'Thomas D. Nadeau'" , "ospf-chairs@tools.ietf.org" , "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:25:22 -0000 --_000_D06D40B65B46Dkegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Seems to me that a certain amount of omniscience would be required to know = that there's a competing draft in another WG (I know a lot of us list-troll= multiple WG, but it might be an assumption we all do). Which I think is the gist of some of the dialogue in the thread. Is there = a requirement that all yang related drafts notify this group (straight up q= uestion, I don't know if the tooling has been done to make that happen =85 = requirement for "yang" in draft name to trigger such an event =85anything? = =85did I miss that)? Personally, the scatter-gather approach to modeling hasn't yielded outstand= ing results to date (okay, that's opinion) =85 and it makes it harder to kn= ow system-wide, where the heck we (the IETF community) are in completion of= the task many of us are now hearing from customers =96 that the thing we c= all "router" or "switch" have a complete model set from which we could driv= e an API (the day of the CLI causing brand loyalty probably passed us by wh= ile we were sleeping). Would this list be tracking something like that =85= do we even understand that that is the effort afoot? To me, "coordinator" or "coordination" would imply that macro level respons= ibility. Can a list own that, or should we delegate it to a group? And, i= f so, what group would that be? From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, October 22, 2014 11:05 AM To: Ken Gray >, 'Robert Raszuk' <= robert@raszuk.net> Cc: "Benoit Claise (bclaise)" >= , "'Thomas D. Nadeau'" >, "ospf-chairs@tools.ietf.org" >, "Rtg-yang-coor= d@ietf.org" > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Yes. And, as Jeff explains, it is not intended to compete. Perhaps "feed into" w= ould be a good term. And as Robert notes, the overlap can be handled in discussion. It's great that we have venues to discuss this work. I hope we can advance = it quickly. Doing so "in secret" will, however, not end well for anyone. Adrian From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Ken Gray (kegray) Sent: 22 October 2014 16:01 To: adrian@olddog.co.uk; 'Robert Raszuk' Cc: Benoit Claise (bclaise); 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org= ; Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Is this also the competing draft you referred to? From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, October 22, 2014 10:13 AM To: 'Robert Raszuk' > Cc: "Benoit Claise (bclaise)" >= , "'Thomas D. Nadeau'" >, "ospf-chairs@tools.ietf.org" >, "Rtg-yang-coor= d@ietf.org" > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Robert, http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ Yes, it is in the wrong WG as well. No, I can't point to it being discussed on the OSPF list. Not sure that fac= t proves anything. Adrian From:rraszuk@gmail.com [mailto:rraszuk@gmail.com]= On Behalf Of Robert Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Adrian, What other competing OSPF yang model are you referring to? Can you provide link to discussions about that other model on OSPF WG list = taking place ? Thx, R. On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord --_000_D06D40B65B46Dkegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4564EFCC7F7FE540BCEB84000D33CD27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Seems to me that a certain amount of omniscience would be required to = know that there's a competing draft in another WG (I know a lot of us list-= troll multiple WG, but it might be an assumption we all do).  

Which I think is the gist of some of the dialogue in the thread.  = ;Is there a requirement that all yang related drafts notify this group (str= aight up question, I don't know if the tooling has been done to make that h= appen =85 requirement for "yang" in draft name to trigger such an event =85anything? =85did I miss that)?

Personally, the scatter-gather approach to modeling hasn't yielded out= standing results to date (okay, that's opinion) =85 and it makes it harder = to know system-wide, where the heck we (the IETF community) are in completi= on of the task many of us are now hearing from customers =96 that the thing we call "router" or &q= uot;switch" have a complete model set from which we could drive an API= (the day of the CLI causing brand loyalty probably passed us by while we w= ere sleeping).  Would this list be tracking something like that =85 do we even understand that that is the effort afoot?  <= /div>

To me, "coordinator" or "coordination" would imply= that macro level responsibility.  Can a list own that, or should we d= elegate it to a group?  And, if so, what group would that be?

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, October 22, 2014 1= 1:05 AM
To: Ken Gray <kegray@cisco.com>, 'Robert Raszuk' <robert@raszuk.net>
Cc: "Benoit Claise (bclaise)&q= uot; <bclaise@cisco.com>, &q= uot;'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.o= rg>, "Rtg-yang-coord= @ietf.org" <Rtg-yang= -coord@ietf.org>
Subject: Re: [Rtg-yang-coord] NETMO= D interim meeting canceled

Yes.

And, as Jeff explains, it is not i= ntended to compete. Perhaps "feed into" would be a good term.

And as Robert notes, the overlap c= an be handled in discussion.

 

It's great that we have venues to = discuss this work. I hope we can advance it quickly. Doing so "in secr= et" will, however, not end well for anyone.

 

Adrian

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-boun= ces@ietf.org] On Behalf Of Ken Gray (kegray)
Sent: 22 October 2014 16:01
To: adrian@olddog.co.uk; = 'Robert Raszuk'
Cc: Benoit Claise (bclaise); 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled

 

Is this also the competing draft you referr= ed to?

 

From: Adrian Farrel <= adrian@olddog.co.uk>
Reply-To: "adrian@olddog= .co.uk" <adrian@olddog.c= o.uk>
Date: Wednesday, October 22, 2014 10:13 AM
To: 'Robert Raszuk' <robert@= raszuk.net>
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, "'Thomas D. Nadeau'" <= tnadeau@lucidvision.com>,= "ospf-chairs@tools.ietf= .org" <ospf-chairs@tools.ietf.o= rg>, "Rtg-yang-coord= @ietf.org" <Rtg-yang= -coord@ietf.org>
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled

 

Hi Robert,

 

http://datatracker.ietf.org/doc/draft-wa= ng-i2rs-ospf-dm/

 

Yes, it is in the wrong WG as well= .

 

No, I can't point to it being disc= ussed on the OSPF list. Not sure that fact proves anything.

 

Adrian

 

From:rraszuk@gmail.com [mailto:rraszuk@gmail.com] On = Behalf Of Robert Raszuk
Sent: 22 October 2014 15:02
To: Adrian Farrel
Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled=

 =

Hi Adrian,

 

What other competing OSPF yang model are you referring to? 

 

Can you provide link to discussions about that other model on OSPF W= G list taking place ? 

 

Thx,

R.

 

 =

On Wed, Oct 22, 2014 at = 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreci= ate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 =

--_000_D06D40B65B46Dkegrayciscocom_-- From nobody Wed Oct 22 08:31:40 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEDF1ACD7E; Wed, 22 Oct 2014 08:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 T1PNurjK22Ag; Wed, 22 Oct 2014 08:31:29 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDD51ACD5C; Wed, 22 Oct 2014 08:31:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MFVKw9018389; Wed, 22 Oct 2014 16:31:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MFVGDF018364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 16:31:16 +0100 From: "Adrian Farrel" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 16:31:15 +0100 Message-ID: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0331_01CFEE15.9BBD92D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9Swm0u/KfA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--22.087-10.0-31-10 X-imss-scan-details: No--22.087-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFoZ7jQwc54lYnS5xmwU5i7OVBDQSDMig9GqvcIF1TcLYCSO mrPBOTFp4xJtic9fIFDbZy9r8jP7KQcSBA/LYDiht1AhvyEKdj6D30L3uxcHwH3hz57t9YhwCL1 yYUEE8H569CHTEoBTSOAfgNq2Dmd+7K35r0y1/56uJZEHbH9COkpFpc3bJiMeHF5gWd5iOUkQde WzncsvdsNNU5+etg4IxgZLkcFnBTi6pWIxX/wmnJJEUO2qIzlLkTwrUbGAkwsAIXlMppp3X0mtg rB9FRL4E5k0SQVbD8C9v2NH67oMPsvpn96tHcQm4pdq9sdj8LXv6kiVCTIVSnp8t2HNMtxXAYKi oM2eCbXZ/QsAS8dPpVBfggEXkT8rSJvHZYIIxMjAzkaoCiomKtFqG4/BpDVaV6KWY8jugmVoM2t bPC4VOF0X5Tuj0fDnW/LiKbIDyB0tSlTGuzyOlhes/RxhysDbh8Ytn75ClDMJmdXzOhEMdki1wh buw4TinqyoyJhbUB54inx+MCALBgzLAh0XmJaQhrs6JAEL1u4F15s6prCIu2LM/ReBSwUwidXgU qJvtIsQodlG8zH2T6xKY/YhJ7+KKGCbvjyH7UVn+WBSNyyzIcmSB8xSIlHVVfOB6z8Qn2wYAGI3 BL87IDBYuLCOM+B33qfXafL74u+s/r1De3um7kg5Iem1vm3HX5TqQagR07ciuBun2kJCuhOYxNl db2puYHEXFWMmW7/LUUKzD12wiEBhLuZbkW2NUKL/EMdwPN/WSrKtwxqWpRub2KZpME0Zkl0fPY WeWR0KAL6wjvnzMWYyyBKbvyUxgNVHXM3C8e6eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7DDmMp5UGBhvIAcCikR3vq98BjoDgPVWLqYmnuDEvXMO4qV+pM01IKYEplsyW5C2ipJQyOLS ake4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/nPrKJG9eTRuGRuopkzYWY_2OSLU Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:31:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0331_01CFEE15.9BBD92D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, I cannot speak to why the meeting was cancelled. My disquiet was simply that an item on the agenda was out of scope and not properly announced to achieve the correct participation. The text I sent to Benoit read... > In summary: if this meeting does not have material to discuss under > the agenda for which the meeting was called, then it must be cancelled. You appear to be saying that there was work to be done that was in scope for the WG and was part of the agenda that was published. So I'm a bit puzzled. Adrian From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: 22 October 2014 16:20 To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0331_01CFEE15.9BBD92D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

I cannot speak to why the = meeting was cancelled.

My disquiet was simply that an = item on the agenda was out of scope and not properly announced to = achieve the correct participation.

 

The text I sent to Benoit = read...

 

> In summary: if this = meeting does not have material to discuss under

> the agenda for which the = meeting was called, then it must be cancelled.

 

You appear to be saying that = there was work to be done that was in scope for the WG and was part of = the agenda that was published.

 

So I'm a bit puzzled. =

 

Adrian

 

 

From: Eric Voit (evoit) = [mailto:evoit@cisco.com]
Sent: 22 October 2014 = 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: = Rtg-yang-coord@ietf.org; NETMOD Working Group; = ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] = [Rtg-yang-coord] NETMOD interim meeting = canceled

 

As Tom and others note, = today’s Netmod interim was to have topics beyond OSPF.  These = included OpenDaylight related work.   The IETF should be = encouraging venues for Open Source developer audiences.  Cancelling = full meetings via IETF procedural mechanisms signals the opposite.  =

 

I *like* the idea of each WG being the = owner for their domain models.  This scales well for the reasons =  pointed out below.  And I do have sympathy for a WG wanting = to close on a definitive answer for a YANG model before implications are = discussed elsewhere.   But I am worried that we are enforcing = an overly serial process.  Or of constraining communication.  = The market will work around this.  

 

In the controller space, YANG = technology is not static.  Some degree of parallelism is needed = across IETF WGs.  Clueful Open Source/YANG developers cannot extend = themselves across all WG where YANG modeling might occur. =

 

Eric

 

 

From: Thomas D. Nadeau, October 22, 2014 10:52 AM

      &nb= sp;   We are trying. The thing is that you = cannot just hoist that onto WGs and say “here you go.” if = they don’t want to do it.  Again, the Netmod charter was = specifically modified to accommodate that case.   And while some = WGs in the routing area are not enthusiastic about building models, = others aren’t, nor are other WGs at the IETF. So for those, what = do you do? Ignore them? The other point is that others outside of the = IETF are working on these models.  It is squarely within the IETF = community’s interest to bring these back into the fold.  Many = of these folks are skittish about coming to the IETF altogether so = we’ve tried to encourage them to participate in this way. If we = want to push these folks away with procedural reasons, then we have made = our bed...

 

=

      &nb= sp;   —tom

<= div>

 

=

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, = Andy Bierman <andy@yumaworks.com> = wrote:

 

<= p class=3DMsoNormal>Hi,

 

=

I think the interim did not need to be = cancelled. There are ACL, SYSLOG,

and YANG Mount topics. I was going to = call in for those, not OSPF.

But I have been saying (for over a = year now) that it is time to move

domain-specific data models into the = domain-specific WGs.

I = think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

=

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, = Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one said that OSPF experts could = not attend to provide input.   The issue is that OSPF was not doing = this. If they want to take over doing all OSPF models, then great, but = to date no one was.  The agreement in NETMOD (and our charter) is = to facilitate the creation of models when WGs don’t want to do = them, have the expertise to do them, etc…  Also, getting the = right Yang experts in one place is not going to happen for every WG in = the IETF; its just not realistic.  I understand that ultimately the = WG needs to have consensus, but quick iteration to construct the model = surely can happen in a small “design team” fashion, = right?

 

=

And in terms of today’s meeting = being canceled, really what purpose was that other than to = stall/slow-down work?  The group that was there to work on the OSPF = model was indeed a bunch of folks from OSPF (Acee Lindem for example was = on the call).  So now since we won’t have another interim = meeting until after Hawaii, so the next time this group can get together = is possibly in Hawaii, but that is probably unlikely as a large number = of people are not going to Hawaii.  So the net-net is a slowing of = progress in this area.  Probably not the result the IETF community = wants.

 

=

—Tom

<= div>

 

=

 

=

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, = Andy Bierman <andy@yumaworks.com> = wrote:

 

<= p class=3DMsoNormal>Hi = Adrian,

 

=

I agree with you. The OSPF WG should = be discussing OSPF data models,

not the NETMOD WG. The domain experts = need to reach consensus

on a feature set (and maybe info = model) and then get 1 or 2 YANG experts = to

help translate that to a = data model. (Not the other way around -- a = room

full of YANG experts and = 1 or 2 OSPF experts).

 

=

I also prefer that virtual interim = meetings be used to discuss open = issues

on chartered items, not = as an additional forum to promote individual = drafts.

 

=

 

=

Andy

 

=

 

On Wed, Oct 22, 2014 at 6:48 AM, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

I understand and appreciate your = desire to get work done.

The rules for IETF virtual interims are = neither hard to discover, nor hard to
comply with. The rules exist to = ensure that people are included in the work, and
I am sure that = inclusion is what you want.

I find it unfortunate that you = scheduled a working group meeting to discuss only
one of a pair of = competing documents on the same topic, that you didn't make = the
information about the meeting available to the authors of the = competing document
or to the people who care about the protocol being = modelled, and I find it
upsetting (yes, I am actually upset) that you = decided to discuss in Netmod a
document that belongs in the OSPF = working group.

If, as it surely sounds, you wish that the Netmod = working group had a different
charter to enable it to take on models = for protocols that already have a home in
other working groups, then = I suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

------=_NextPart_000_0331_01CFEE15.9BBD92D0-- From nobody Wed Oct 22 09:19:56 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732681ACDDA for ; Wed, 22 Oct 2014 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zC0qe6wOHX-h for ; Wed, 22 Oct 2014 09:19:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5422F1ACDEE for ; Wed, 22 Oct 2014 09:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8221; q=dns/txt; s=iport; t=1413994745; x=1415204345; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sylIn0uZp/YUx1p35cogz1I27PbF0ve55HZb/MAPrP0=; b=TXrcjIlqUBSRvzLaEAo20QKqACCjolfJWu0NGwmWQF9oNVC7RWTGcv+e Hkt7gMHQ0fKrHMwAfQ2NX8JJ7nzLuPjmeozMwIqtGCygBpOvqfTd/XDsy G6TeQZKPzysMxr7KLKtE9JrQ4l4IVPyGh2WeXtG6jDjw7LOkIkbMYG803 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAIfYR1StJV2T/2dsb2JhbABcgkhGVFgEym2BaIdVAoEMFgF9hAIBAQEEeRACAQgOAwMBAigHMhQJCAIEAQ0FiEDGFwEBAQEBAQEBAgEBAQEBAQEBAQEBF5BGEQcJhEIFkgSERoRBglKBMRErjWKCWoQBg3hsgQYEPoEDAQEB X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365488506" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2014 16:19:04 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9MGJ4RS021410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 16:19:04 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 11:19:04 -0500 From: "Acee Lindem (acee)" To: Jeff Haas , Robert Raszuk , "Thomas D. Nadeau" Thread-Topic: [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7f741i3foC0Vi02jGmQDSDEWupw8eT6AgAADRYCAAAGKgIAABuaA///XmwA= Date: Wed, 22 Oct 2014 16:19:03 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> In-Reply-To: <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.202] Content-Type: multipart/alternative; boundary="_000_D06D50AE611Baceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/beQ2ZI7DbwqCXNGHRlAV8qRTlvc Cc: "Benoit Claise \(bclaise\)" , Adrian Farrel , "ospf-chairs@tools.ietf.org" , "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:19:52 -0000 --_000_D06D50AE611Baceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To summarize, then it Is not a competing draft. As I stated previously, the= OSPF YANG model which started last year in netmod WG will be presented at = IETF 91 and we will work towards OSPF WG adoption. Thanks, Acee From: Jeff Haas > Date: Wednesday, October 22, 2014 at 10:43 AM To: Robert Raszuk >, "Thomas D.= Nadeau" > Cc: "Benoit Claise (bclaise)" >= , Adrian Farrel >, "ospf-ch= airs@tools.ietf.org" >, "Rtg-yang-coord@ietf.org" > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled On Oct 22, 2014, at 10:18 AM, Robert Raszuk > wrote: Adrian, Ah that document I know. But this is almost completely different topic. At least to me I2RS is not about configuring OSPF protocol. It is about col= lecting and possibly augmenting routing system with data. On the other hand Yang model takes care about instatiation and management o= f a given protocol. There can be some little overlap, but does not need to = be at all. Just for clarity, the long term goal of Sue's draft was *not* to be a compe= ting ospf draft, it was to provide enough of an example config base to demo= nstrate where I2RS hooks would go. I2RS is not in the business of trying to do the modeling work of other WG's= protocols. I2RS is definitely in the business of seeing standardized models advance so= we can hook into them. Figuring out the most productive way to have that discussion has obviously = been a bit bumpy. Hence, one of the reasons to have the rtg-yang-coord lis= t. FWIW, I agree with Adrian that the scope of the netmod interim design sessi= ons has crept a bit out of the expected charter. This isn't to say that wo= rk shouldn't happen, but when it does: - There needs to be adequate notice (apparently Adrian's biggest complaint) - Some mindfulness about group scope needs to be accommodated. The comment about taking your ball and going someplace else to play (meetup= .com) was not worthy of a chair, Tom. While there's cer= tainly precedent in other orgs of working faster, there's also similar prec= ent of fork and fracture. -- Jeff --_000_D06D50AE611Baceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <11568C25DE2B7140B63A0605AD067E34@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
To summarize, then it Is not a competing draft. As I stated previously= , the OSPF YANG model which started last year in netmod WG will be presente= d at IETF 91 and we will work towards OSPF WG adoption. 

Thanks,
Acee

From: Jeff Haas <jhaas@juniper.net>
Date: Wednesday, October 22, 2014 a= t 10:43 AM
To: Robert Raszuk <robert@raszuk.net>, "Thomas D. Nadeau&q= uot; <tnadeau@lucidvision.com= >
Cc: "Benoit Claise (bclaise)&q= uot; <bclaise@cisco.com>, Ad= rian Farrel <adrian@olddog.co.uk<= /a>>, "ospf-chairs@to= ols.ietf.org" <ospf-chairs@tools.ietf.o= rg>, "Rtg-yang-coord= @ietf.org" <Rtg-yang= -coord@ietf.org>
Subject: Re: [Rtg-yang-coord] NETMO= D interim meeting canceled


On Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> wrote:

Adrian,

Ah that document I know. But this is almost completely different topic.&nbs= p;

At least to me I2RS is not about configuring OSPF protocol. It is about col= lecting and possibly augmenting routing system with data. 

On the other hand Yang model takes care about instatiation and management o= f a given protocol. There can be some little overlap, but does not need to = be at all.

Just for clarity, the long term goal of Sue's draft was *not* to be a compe= ting ospf draft, it was to provide enough of an example config base to demo= nstrate where I2RS hooks would go.

I2RS is not in the business of trying to do the modeling work of other= WG's protocols.  

I2RS is definitely in the business of seeing standardized models advan= ce so we can hook into them.

Figuring out the most productive way to have that discussion has obvio= usly been a bit bumpy.  Hence, one of the reasons to have the rtg-yang= -coord list.

FWIW, I agree with Adrian that the scope of the netmod interim design = sessions has crept a bit out of the expected charter.  This isn't to s= ay that work shouldn't happen, but when it does:
- There needs to be adequate notice (apparently Adrian's biggest compl= aint)
- Some mindfulness about group scope needs to be accommodated.

The comment about taking your ball and going someplace else to play (<= a href=3D"http://meetup.com">meetup.com) was not worthy of a chair, Tom= .  While there's certainly precedent in other orgs of working faster, = there's also similar precent of fork and fracture.

-- Jeff

 --_000_D06D50AE611Baceeciscocom_-- From nobody Wed Oct 22 10:05:28 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17851ACE75; Wed, 22 Oct 2014 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eU6joU-g8z5q; Wed, 22 Oct 2014 10:04:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6931ACE56; Wed, 22 Oct 2014 10:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42674; q=dns/txt; s=iport; t=1413997497; x=1415207097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kv/QXqnr2NeGqQ94TCMXjINvGuB/+h5MOyz6PqeEPlM=; b=kGq3FCNq/aLEERdn2m2UGPWX5iifE3BAjOkuP63NxnzjNZ7hQqxwxCtJ vFBp+jPeQz6VLHpx5kGN332qK+o1AirWOqVgjCl+O7FQIJJN2NECRGURM JWHpEU3Nv9GoVAqRIDyOQp2ueSODXFqFXzef+uS0rVQx/keizhHDT/F5Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFABPjR1StJV2c/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQMBAQEBFxM+AwsFBwQCAQgRBAEBAQoWAQYHJwsUCQgCBAENBQgMBwSIGQgNxgoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpWhSUrLQQGAQaDJ4EeBY9mgh6NCoZ2igKEAYN4bIEGBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365509101" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2014 17:04:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9MH4sbD029061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 17:04:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:04:53 -0500 From: "Eric Voit (evoit)" To: "adrian@olddog.co.uk" , "'Thomas D. Nadeau'" , "'Andy Bierman'" Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7gfB9u4QKYuEX+hUMOEGGRuotpw8OMTQgABZbYD//7OAoA== Date: Wed, 22 Oct 2014 17:04:52 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> In-Reply-To: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/0L7F9CHVYDI2aP3b3qtnHQD9Yf4 Cc: "Rtg-yang-coord@ietf.org" , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , 'NETMOD Working Group' , "rtg-ads@tools.ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:05:12 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is true I wish the meeting had run today to address other things. Putti= ng that aside I had a larger point. OpenDaylight is seeing new YANG technologies which are being implemented fo= r a set of new topics. I have listed a few below to provide context. Many= of these topics have implications to multiple IETF Working Groups. Awaiti= ng charter changes before having discussions in or between WG slows these d= iscussions. Enforcing a process so that YANG modeling discussions must go = through distributed WGs serially slows these discussions. I am not offeri= ng a solution here. I am just observing that the industry is moving faster= than the IETF. Some YANG OpenDaylight Topics which I would love to see the IETF take on: (1) Multi-device YANG Abstractions YANG syntax is used for multi-device abstractions in OpenDaylight MD-SAL. = This conflicts with RFC 6244 which defines a single-box boundaries. Should= the IETF consider architectures where YANG models span devices? What abou= t for multi-box protocols like VRRP? What about Anycast interfaces into cl= usters of devices acting as one? How about cloud abstraction into a Design= ated Router? (2) Generic Pub/Sub Mechanisms RFC 5277 on Netconf notifications doesn't include information on how to han= dle Pub/Sub so that one device is immediately informed about object changes= in another. I believe there is some demand for Pub/Sub which is tied to Y= ANG and with no required linkage to a transport protocol. There are also n= eeds for Pub/Sub beyond YANG. How should we approach this area? (3) Maintaining Consistency in a Multi-Controller world There will not be one controller for a network. There will be many. How d= o you determine precedence when conflicting config information is being sen= t from multiple sources? How does this change the information encoded in t= he model? In summary I would assert that handling solutions to the problems above ind= ependently across all WGs is not viable. Eric From: Adrian Farrel, October 22, 2014 11:31 AM Eric, I cannot speak to why the meeting was cancelled. My disquiet was simply that an item on the agenda was out of scope and not = properly announced to achieve the correct participation. The text I sent to Benoit read... > In summary: if this meeting does not have material to discuss under > the agenda for which the meeting was called, then it must be cancelled. You appear to be saying that there was work to be done that was in scope fo= r the WG and was part of the agenda that was published. So I'm a bit puzzled. Adrian From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: 22 October 2014 16:20 To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working= Group; ospf-chairs@tools.ietf.org; ops-= ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is true I wish the mee= ting had run today to address other things.  Putting that aside I had = a larger point.

 <= /p>

OpenDaylight is seeing ne= w YANG technologies which are being implemented for a set of new topics.&nb= sp; I have listed a few below to provide context.  Many of these topics have implications to multiple IETF Working Groups.  Awaiting c= harter changes before having discussions in or between WG slows these discu= ssions.  Enforcing a process so that YANG modeling discussions must go= through distributed WGs serially slows these discussions.   I am not offering a solution here.  I am jus= t observing that the industry is moving faster than the IETF. 

 <= /p>

Some YANG OpenDaylight To= pics which I would love to see the IETF take on:

 <= /p>

(1) Multi-device YANG Abs= tractions 

YANG syntax is used for m= ulti-device abstractions in OpenDaylight MD-SAL.  This conflicts with RFC 6244 which defines a single-box bound= aries.  Should the IETF consider architectures where YANG models span = devices?  What about for multi-box protocols like VRRP?  What about Anycast interfaces into clusters of devices acting as one?  How= about cloud abstraction into a Designated Router?

 <= /p>

(2) Generic Pub/Sub Mecha= nisms

RFC 5277 on Netconf notif= ications doesn’t include information on how to handle Pub/Sub so that= one device is immediately informed about object changes in another.  I believe there is some demand for Pub/Sub which is tied to YANG and with = no required linkage to a transport protocol.  There are also needs for= Pub/Sub beyond YANG.  How should we approach this area?  

 <= /p>

(3) Maintaining Consisten= cy in a Multi-Controller world

There will not be one con= troller for a network.  There will be many.  How do you determine= precedence when conflicting config information is being sent from multiple sources?  How does this change the information encoded in th= e model?

 <= /p>

In summary I would assert= that handling solutions to the problems above independently across all WGs= is not viable.


Eric

 <= /p>

From: Adrian F= arrel, October 22, 2014 11:31 AM

 

Eric,=

 = ;

I cannot s= peak to why the meeting was cancelled.

My disquie= t was simply that an item on the agenda was out of scope and not properly a= nnounced to achieve the correct participation.

 = ;

The text I= sent to Benoit read...

 = ;

> In su= mmary: if this meeting does not have material to discuss under

> the a= genda for which the meeting was called, then it must be cancelled.

 = ;

You appear= to be saying that there was work to be done that was in scope for the WG a= nd was part of the agenda that was published.

 = ;

So I'm a b= it puzzled.

 = ;

Adrian

 = ;

 = ;

From: Eric Voi= t (evoit) [mailto:evoit@cisco.com]
Sent: 22 October 2014 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.o= rg; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-a= ds@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting cancel= ed

 

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From:<= /span> Thomas D. Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_-- From nobody Wed Oct 22 11:08:11 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597DC1ACC86 for ; Wed, 22 Oct 2014 11:08:05 -0700 (PDT) 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 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 qI00iZXtCPSH for ; Wed, 22 Oct 2014 11:08:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EDC6D1ACCDE for ; Wed, 22 Oct 2014 11:08:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "'Robert Raszuk'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> In-Reply-To: <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> Date: Wed, 22 Oct 2014 14:07:53 -0400 Message-ID: <051601cfee23$1a248220$4e6d8660$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0517_01CFEE01.9319E700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYm3ClukA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/EQj3qm_JkzTmXIcJlItL8LeDnL8 Cc: 'Benoit Claise' , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:08:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0517_01CFEE01.9319E700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, Robert, and Thomas: =20 =20 These two drafts interact due to the netmod suggestion to I2RS that the = configuration datastore and the I2rs ephemeral datastore can be part of = the same data store. I2rs has not agreed to combined datastore on the = list or in a meeting. The details of the interactions are being worked = out. However, to push this state I am preparing a comparison draft = between:=20 =20 = http://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ = http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ =20 Acee encouraged me on the I2RS mailing list to keep 1 OSPF yang draft = (draft-yeung-netmod-ospf) and suggest changes to support I2RS = requirements. To provide this comparison, I am writing a = draft-hares-i2rs-ospf-yeung-adds-00 to suggest these changes based on = the requirements listed in = = draft-hares-i2rs-usecase-reqs-summary-00 for IGPs. These changes should = inform the thinking of the draft-yeung-netmod-ospf authors, but should = not hold up progress on this draft. Please note that even though the = I2RS chairs directed the creation of the = draft-hares-i2rs-usecase-reqs-summary list of all potential I2rs = requirements =E2=80=93 this draft has been adopted as a WG draft. =20 =20 Finally, to give a technical moment to an otherwise banal bashing of = Adrian=E2=80=99s support for Acee=E2=80=99s earlier declaration to hold = this review in OSPF, I offer the =E2=80=9Csound byte=E2=80=9D level of = comparison below (see draft-hares-i2rs-ospf-yeung-adds-00 for full = details). =20 =20 Sue=20 =20 Comparison:=20 =20 draft-yeung-netmod-ospf-01 (2/14/2014) - configuration, but lacked the = definitions to support real-time status of ospf-mt, ospf-rib, = ospf-neighbor, ospf-lsa-database, ospf-state, and ospf-status.=20 =20 draft-wang-i2rs-ospf-dm-00 (9/26/2014) - not focused on configuration, = but added definitions to support real-time status of ospf-mt, ospf-rib, = ospf-neighbor, ospf-lsa-data, ospf-state, and ospf-status.=20 =20 draft-yeung-netmod-ospf-02 (10/14/2014) =E2=80=93 added definitions for = ospf-mt, ospf lsa database, ospf-TE, and ospf status and state = information which was included in draft-i2rs-wang-ospf-dm-00 draft. The = draft-yeung-netmod-ospf-02 now has the form. =20 =20 =C2=B7 The configuration with the muti-topology view = (write/read)=20 =C2=B7 protocol state and ospf-lsa-database (read only)=20 =C2=B7 notification on events (read-only) =20 draft-hares-i2rs-ospf-yeung-adds=E2=80=94(upcoming) summarizes these = differences and suggests changes to be made to the = draft-yeung-netmod-ospf-02 in order to fulfill I2RS requirements (mostly = in changes to state found in protocol, ospf-lsa-database, and events = plus an addition of ospf-rib module), and some additions to = configuration.=20 =20 =20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Adrian Farrel Sent: Wednesday, October 22, 2014 10:13 AM To: 'Robert Raszuk' Cc: 'Benoit Claise'; 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Hi Robert, =20 http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ =20 Yes, it is in the wrong WG as well. =20 No, I can't point to it being discussed on the OSPF list. Not sure that = fact proves anything. =20 Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Hi Adrian, =20 What other competing OSPF yang model are you referring to?=20 =20 Can you provide link to discussions about that other model on OSPF WG = list taking place ?=20 =20 Thx, R. =20 =20 On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel = wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor = hard to comply with. The rules exist to ensure that people are included in the = work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to = discuss only one of a pair of competing documents on the same topic, that you didn't = make the information about the meeting available to the authors of the competing = document or to the people who care about the protocol being modelled, and I find = it upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a = different charter to enable it to take on models for protocols that already have a = home in other working groups, then I suggest you need to recharter. But I doubt = that your reasoning that [YANG] experts will not go to all the other working = groups will carry much weight. Frankly, and without wanting to disrespect the = YANG experts, it is easier to understand YANG than it is to understand OSPF. = If this were not the case then the Netmod working group would have failed in its = design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group = and discuss it (there are already some threads). Review and comment on the = competing document. Try to get agreement between all of the authors of both = documents, or try to identify the differences. Work with the chairs of the OSPF = working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural = non-sense has > and IS driving people away from the IETF to other places where this = work is going > to get done. The simple effect of such silliness will be a reduction = in speed and > quantity of model development. If the goal of the IESG is to slow = down the > velocity of model development and creation, then this approach is = perfect. > > For the record, the interim NETMOD meeting cadence has one = meeting > focused on Yang and the other on modeling; is not NETMOD-specific per = say, but > to promote model creation because no other bi-weekly forum exists to = do so. It > is also a place to bring in non-IETF work such as the work done in = ODL, other open > source, or just the public community that has explicitly wanted to = avoid the IETF. > We have found it a convenient and fruitful place to discuss, and = actually *build* > models - regardless of their ultimate WG home. The simple reason: its = a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do = not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for = which there > is no milestone in the working group and for which there is an obvious = home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF = announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 ------=_NextPart_000_0517_01CFEE01.9319E700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Adrian, Robert, and Thomas: =C2=A0

 

These two drafts interact due to the netmod suggestion to I2RS that the = configuration datastore and the I2rs ephemeral datastore can be part of = the same data store.=C2=A0 I2rs has not agreed to combined datastore on = the list or in a meeting.=C2=A0 The details of the interactions are = being worked out. =C2=A0However, to push this state I am preparing a = comparison draft between:

 

http://datatracker.ietf.org/doc/draft-yeung-netmod-= ospf/

http://datatracker.ietf.org/doc/draft-wang-i2rs-osp= f-dm/

 

Acee encouraged me on the I2RS mailing list to keep 1 OSPF yang draft = (draft-yeung-netmod-ospf) and suggest changes to support I2RS = requirements.=C2=A0 To provide this comparison, I am writing a = draft-hares-i2rs-ospf-yeung-adds-00 to suggest these changes based on = the requirements listed in draft-hares-i2rs-usecase-reqs-su= mmary-00 for IGPs.=C2=A0 These changes should inform the = thinking of the draft-yeung-netmod-ospf authors, but should not hold up = progress on this draft. Please note that even though the I2RS chairs = directed the creation of the draft-hares-i2rs-usecase-reqs-summary list = of all potential I2rs requirements =E2=80=93 this draft has been adopted = as a WG draft.=C2=A0

 

Finally, to give a technical moment to an otherwise banal bashing of = Adrian=E2=80=99s support for Acee=E2=80=99s earlier declaration to hold = this review in OSPF, I offer the =E2=80=9Csound byte=E2=80=9D level of = comparison below (see draft-hares-i2rs-ospf-yeung-adds-00 for full = details). =C2=A0

 

Sue

 

Comparison:

 

draft-yeung-netmod-ospf-01 (2/14/2014) =C2=A0- configuration, but = lacked the definitions to support real-time status of ospf-mt, ospf-rib, = ospf-neighbor, ospf-lsa-database, ospf-state, and ospf-status. =

 

draft-wang-i2rs-ospf-dm-00 (9/26/2014) =C2=A0- not focused on = configuration, but added definitions to support real-time status of = ospf-mt, ospf-rib, ospf-neighbor, ospf-lsa-data, ospf-state, and = ospf-status.

 

draft-yeung-netmod-ospf-02 (10/14/2014) =E2=80=93 added definitions = for ospf-mt, ospf lsa database, ospf-TE, and ospf status and state = information which was included in draft-i2rs-wang-ospf-dm-00 draft. = =C2=A0The draft-yeung-netmod-ospf-02 now has the form. = =C2=A0

 

=C2=B7         = The configuration with the muti-topology view (write/read) =

=C2=B7         = protocol state and ospf-lsa-database (read only) =

=C2=B7         = notification on events (read-only)

 

draft-hares-i2rs-ospf-yeung-adds=E2=80=94(upcoming) summarizes these = differences and suggests changes to be made to the = draft-yeung-netmod-ospf-02 in order to fulfill I2RS requirements (mostly = in changes to state found in protocol, ospf-lsa-database, and events = plus an addition of ospf-rib module), and some additions to = configuration.

 

 

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Adrian Farrel
Sent: Wednesday, October 22, 2014 10:13 = AM
To: 'Robert Raszuk'
Cc: 'Benoit Claise'; 'Thomas = D. Nadeau'; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD = interim meeting canceled

 

Hi Robert,

 

http://= datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/

 

Yes, it is in the wrong WG as well.

 

No, I can't point to it being discussed on the OSPF list. Not sure = that fact proves anything.

 

Adrian

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On = Behalf Of Robert Raszuk
Sent: 22 October 2014 = 15:02
To: Adrian Farrel
Cc: Thomas D. Nadeau; Benoit = Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org=
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Hi Adrian,

 

What other competing = OSPF yang model are you referring = to? 

 

Can you provide link to = discussions about that other model on OSPF WG list taking place = ? 

 

Thx,

R.

 

 

On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

I = understand and appreciate your desire to get work done.

The rules = for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in = the work, and
I am sure that inclusion is what you want.

I = find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, = that you didn't make the
information about the meeting available to = the authors of the competing document
or to the people who care about = the protocol being modelled, and I find it
upsetting (yes, I am = actually upset) that you decided to discuss in Netmod a
document that = belongs in the OSPF working group.

If, as it surely sounds, you = wish that the Netmod working group had a different
charter to enable = it to take on models for protocols that already have a home in
other = working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other = working groups
will carry much weight. Frankly, and without wanting = to disrespect the YANG
experts, it is easier to understand YANG than = it is to understand OSPF. If this
were not the case then the Netmod = working group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

=


> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
Rtg-yang-c= oord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 

<= /html> ------=_NextPart_000_0517_01CFEE01.9319E700-- From nobody Wed Oct 22 11:13:43 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4421ACF18 for ; Wed, 22 Oct 2014 11:13:37 -0700 (PDT) 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 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 F1nnC-JNk_xu for ; Wed, 22 Oct 2014 11:13:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3661ACCE9 for ; Wed, 22 Oct 2014 11:13:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Robert Raszuk'" , "'Adrian Farrel'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 14:13:26 -0400 Message-ID: <054f01cfee23$e0a24270$a1e6c750$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0550_01CFEE02.5995D290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAf8q9iybYMg7kA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/jrEUVX1DTuFLTrHIQYwuWIRkFSU Cc: 'Benoit Claise' , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:13:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0550_01CFEE02.5995D290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 I2RS requirements have been setting ephemeral state that may change the = OSPF protocol actions. This augmenting function may interact with how = configuration causes the protocol to interaction.=20 =20 I encourage you to post to Alia Atlas thread: [i2rs] Why do we need a = datastore? =20 http://www.ietf.org/mail-archive/web/i2rs/current/threads.html#02078 =20 or Joel Halpern=E2=80=99s thread [i2rs] Running and I2RS Ephemeral = Config Interaction =20 http://www.ietf.org/mail-archive/web/i2rs/current/msg02034.html =20 Help I2RS determine exactly what the ephemeral datastore really means.=20 =20 Sue Hares=20 =20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Robert Raszuk Sent: Wednesday, October 22, 2014 10:19 AM To: Adrian Farrel Cc: Benoit Claise; Thomas D. Nadeau; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Adrian, =20 Ah that document I know. But this is almost completely different topic.=20 =20 At least to me I2RS is not about configuring OSPF protocol. It is about = collecting and possibly augmenting routing system with data.=20 =20 On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. =20 Best, R. =20 =20 =20 On Wed, Oct 22, 2014 at 4:13 PM, Adrian Farrel = wrote: Hi Robert, =20 http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ =20 Yes, it is in the wrong WG as well. =20 No, I can't point to it being discussed on the OSPF list. Not sure that = fact proves anything. =20 Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; = ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Hi Adrian, =20 What other competing OSPF yang model are you referring to?=20 =20 Can you provide link to discussions about that other model on OSPF WG = list taking place ?=20 =20 Thx, R. =20 =20 On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel = wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor = hard to comply with. The rules exist to ensure that people are included in the = work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to = discuss only one of a pair of competing documents on the same topic, that you didn't = make the information about the meeting available to the authors of the competing = document or to the people who care about the protocol being modelled, and I find = it upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a = different charter to enable it to take on models for protocols that already have a = home in other working groups, then I suggest you need to recharter. But I doubt = that your reasoning that [YANG] experts will not go to all the other working = groups will carry much weight. Frankly, and without wanting to disrespect the = YANG experts, it is easier to understand YANG than it is to understand OSPF. = If this were not the case then the Netmod working group would have failed in its = design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group = and discuss it (there are already some threads). Review and comment on the = competing document. Try to get agreement between all of the authors of both = documents, or try to identify the differences. Work with the chairs of the OSPF = working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural = non-sense has > and IS driving people away from the IETF to other places where this = work is going > to get done. The simple effect of such silliness will be a reduction = in speed and > quantity of model development. If the goal of the IESG is to slow = down the > velocity of model development and creation, then this approach is = perfect. > > For the record, the interim NETMOD meeting cadence has one = meeting > focused on Yang and the other on modeling; is not NETMOD-specific per = say, but > to promote model creation because no other bi-weekly forum exists to = do so. It > is also a place to bring in non-IETF work such as the work done in = ODL, other open > source, or just the public community that has explicitly wanted to = avoid the IETF. > We have found it a convenient and fruitful place to discuss, and = actually *build* > models - regardless of their ultimate WG home. The simple reason: its = a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do = not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for = which there > is no milestone in the working group and for which there is an obvious = home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF = announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 =20 ------=_NextPart_000_0550_01CFEE02.5995D290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

I2RS requirements have been setting ephemeral state that may change = the OSPF protocol actions.=C2=A0 This augmenting function may interact = with how configuration causes the protocol to interaction. =

 

I encourage you to post to Alia Atlas thread: [i2rs] Why do we need a = datastore?

 

http://www.ietf.org/mail-archive/web/i2rs/current/threads.html#02078=

 

or Joel Halpern=E2=80=99s thread [i2rs] Running and I2RS Ephemeral = Config Interaction

 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg02034.html<= /o:p>

 

Help I2RS determine exactly what the ephemeral datastore really = means.

 

Sue Hares

 

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Robert Raszuk
Sent: Wednesday, October 22, 2014 10:19 = AM
To: Adrian Farrel
Cc: Benoit Claise; Thomas D. = Nadeau; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD = interim meeting canceled

 

Adrian,

 

Ah that document I know. But this is = almost completely different = topic. 

 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with = data. 

 

On the other hand Yang model takes = care about instatiation and management of a given protocol. There can be = some little overlap, but does not need to be at = all.

 

Best,

R.

 

 

 

On Wed, = Oct 22, 2014 at 4:13 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi Robert,

 

http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm= /

 

Yes, it is in the wrong WG as well.

 

No, I can't point to it being discussed on the OSPF list. Not sure = that fact proves anything.

 

Adrian

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: 22 October 2014 15:02
To: Adrian = Farrel
Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org


Subject: Re: [Rtg-yang-coord] NETMOD interim = meeting = canceled

 

Hi Adrian,

 

What other competing = OSPF yang model are you referring to? 

 

Can you provide link to = discussions about that other model on OSPF WG list taking place = ? 

 

Thx,

R.

 

 

On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

=


> -----Original Message-----
> From: Thomas D. = Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
Rtg-yang-c= oord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 

 

------=_NextPart_000_0550_01CFEE02.5995D290-- From nobody Wed Oct 22 11:32:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561BB1ACF01; Wed, 22 Oct 2014 11:32:09 -0700 (PDT) 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 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 NyqvQw2Uj_ID; Wed, 22 Oct 2014 11:32:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5801A8721; Wed, 22 Oct 2014 11:32:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 14:31:54 -0400 Message-ID: <057901cfee26$754ecc20$5fec6460$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057A_01CFEE04.EE423530" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3m2weNfA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/7TzMArtjPrV_uXfF8Bwd4IUGw1Y Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Benoit Claise' , 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:32:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057A_01CFEE04.EE423530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom: Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF. I'm glad we've got the rtg-yang-coord list to sort out these issues. IDR will pick up all BGP related yang modules. A charter addition has been made. IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements. IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs. If you could suggest a few netmod people to help this effort it would help. My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 10:35 AM To: Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_057A_01CFEE04.EE423530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that = the OSPF yang model was going to be standardized in OSPF.  = I’m glad we’ve got the rtg-yang-coord list to sort out these = issues.

 

IDR will pick up all BGP related yang modules.  A charter = addition has been made.  IDR will gladly accept input from the = netmod WG or hold joint interim session to make this effort go fast. =  The configuration drafts for bgp = (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp = (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I = will be releasing a draft that compares these two drafts, and looks at = how these drafts fulfill the I2RS BGP use case requirements. =

 

IDR will sponsor a design team in IDR to push the rapid development = of bgp configuration or bgp i2rs.  If you could suggest a few = netmod people to help this effort it would help. =  

 

My understanding of IETF best practices indicate that joint interims = need 2 weeks announcement of topics.

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 = AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; = NETMOD Working Group; ospf-chairs@tools.ietf.org; = ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel = Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim = meeting canceled

 

 

        &n= bsp;   No one said that OSPF experts could not attend = to provide input.   The issue is that OSPF was not doing this. If = they want to take over doing all OSPF models, then great, but to date no = one was.  The agreement in NETMOD (and our charter) is to = facilitate the creation of models when WGs don’t want to do them, = have the expertise to do them, etc…  Also, getting the right = Yang experts in one place is not going to happen for every WG in the = IETF; its just not realistic.  I understand that ultimately the WG = needs to have consensus, but quick iteration to construct the model = surely can happen in a small “design team” fashion, = right?

 

        &n= bsp;   And in terms of today’s meeting being = canceled, really what purpose was that other than to stall/slow-down = work?  The group that was there to work on the OSPF model was = indeed a bunch of folks from OSPF (Acee Lindem for example was on the = call).  So now since we won’t have another interim meeting = until after Hawaii, so the next time this group can get together is = possibly in Hawaii, but that is probably unlikely as a large number of = people are not going to Hawaii.  So the net-net is a slowing of = progress in this area.  Probably not the result the IETF community = wants.

 

        &n= bsp;   —Tom

 

 

 

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
&= gt; Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: = NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
>= ; rtg-ads@tools.ietf.org
>= Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
= > >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
&g= t; > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

------=_NextPart_000_057A_01CFEE04.EE423530-- From nobody Wed Oct 22 11:41:45 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A61ACFC1 for ; Wed, 22 Oct 2014 11:41:31 -0700 (PDT) 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 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 fn6ndH0a8zMh for ; Wed, 22 Oct 2014 11:41:29 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EB9EA1A8721 for ; Wed, 22 Oct 2014 11:41:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Haas'" , "'Robert Raszuk'" , "'Thomas D. Nadeau'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> In-Reply-To: <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Date: Wed, 22 Oct 2014 14:41:23 -0400 Message-ID: <059101cfee27$c813a6a0$583af3e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0592_01CFEE06.4103B450" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAf8q9iwCT61kDJtOUaDQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/FGuN5dn6rc0thEFuuhlxfIOBqaU Cc: 'Benoit Claise' , 'Adrian Farrel' , ospf-chairs@tools.ietf.org, Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:41:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0592_01CFEE06.4103B450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Thanks for mentioning this fact. All of the I2rs drafts for OSPF, ISIS, and BGP did not want to be competing drafts - but only places for I2RS hooks to go into. The comparison show only 5-10% overlap in these hooks. I will post the comparison to this list. People have suggested the I2rs RIB-info needs to be an ephemeral copy unique to I2RS. I'd love input on whether this groups things this is true. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Jeff Haas Sent: Wednesday, October 22, 2014 10:44 AM To: Robert Raszuk; Thomas D. Nadeau Cc: Benoit Claise; Adrian Farrel; ospf-chairs@tools.ietf.org; Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: Adrian, Ah that document I know. But this is almost completely different topic. At least to me I2RS is not about configuring OSPF protocol. It is about collecting and possibly augmenting routing system with data. On the other hand Yang model takes care about instatiation and management of a given protocol. There can be some little overlap, but does not need to be at all. Just for clarity, the long term goal of Sue's draft was *not* to be a competing ospf draft, it was to provide enough of an example config base to demonstrate where I2RS hooks would go. I2RS is not in the business of trying to do the modeling work of other WG's protocols. I2RS is definitely in the business of seeing standardized models advance so we can hook into them. Figuring out the most productive way to have that discussion has obviously been a bit bumpy. Hence, one of the reasons to have the rtg-yang-coord list. FWIW, I agree with Adrian that the scope of the netmod interim design sessions has crept a bit out of the expected charter. This isn't to say that work shouldn't happen, but when it does: - There needs to be adequate notice (apparently Adrian's biggest complaint) - Some mindfulness about group scope needs to be accommodated. The comment about taking your ball and going someplace else to play (meetup.com) was not worthy of a chair, Tom. While there's certainly precedent in other orgs of working faster, there's also similar precent of fork and fracture. -- Jeff ------=_NextPart_000_0592_01CFEE06.4103B450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Thanks for mentioning this fact.  All of the I2rs drafts for = OSPF, ISIS, and BGP did not want to be competing drafts – but only = places for I2RS hooks to go into.   The comparison show only = 5-10% overlap in these hooks. I will post the comparison to this list. =   

 

People have suggested the I2rs RIB-info needs to be an ephemeral copy = unique to I2RS.   I’d love input on whether this groups = things this is true.

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Jeff Haas
Sent: Wednesday, October 22, 2014 10:44 = AM
To: Robert Raszuk; Thomas D. Nadeau
Cc: Benoit = Claise; Adrian Farrel; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD = interim meeting canceled

 

 

On = Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> = wrote:



Adrian,

 

Ah that document I know. But this is = almost completely different = topic. 

 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with = data. 

 

On the other hand Yang model takes = care about instatiation and management of a given protocol. There can be = some little overlap, but does not need to be at = all.

 

Just = for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go.

 

I2RS is not in the business of trying to do the = modeling work of other WG's protocols. =  

 

I2RS is definitely in the business of seeing = standardized models advance so we can hook into = them.

 

Figuring out the most productive way to have that = discussion has obviously been a bit bumpy.  Hence, one of the = reasons to have the rtg-yang-coord list.

 

FWIW, I agree with Adrian that the scope of the netmod = interim design sessions has crept a bit out of the expected charter. =  This isn't to say that work shouldn't happen, but when it = does:

- There needs to be = adequate notice (apparently Adrian's biggest = complaint)

- Some = mindfulness about group scope needs to be = accommodated.

 

The comment about taking your ball and going someplace = else to play (meetup.com) was not = worthy of a chair, Tom.  While there's certainly precedent in other = orgs of working faster, there's also similar precent of fork and = fracture.

 

-- Jeff

 

------=_NextPart_000_0592_01CFEE06.4103B450-- From nobody Wed Oct 22 11:45:44 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851D01ACFC4 for ; Wed, 22 Oct 2014 11:45:41 -0700 (PDT) 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 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 6vZPakTDWgwb for ; Wed, 22 Oct 2014 11:45:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 85ECD1ACFBC for ; Wed, 22 Oct 2014 11:45:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Robert Raszuk'" , "'Jeff Haas'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> In-Reply-To: Date: Wed, 22 Oct 2014 14:45:33 -0400 Message-ID: <05a901cfee28$5d1cba20$17562e60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05AA_01CFEE06.D60DD940" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAf8q9iwCT61kDAHUcyBzmz+ws8A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/YBJet1xYOLPx4se_ScKUY73LKZw Cc: 'Benoit Claise' , "'Thomas D. Nadeau'" , ospf-chairs@tools.ietf.org, 'Adrian Farrel' , Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:45:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05AA_01CFEE06.D60DD940 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 I think the IETF is ready for the rapid response time in interims. I = think joint topics should get a 2 week=E2=80=99s notice if it involves = other WGs topics. That=E2=80=99s simple planning by the co-chairs who = can put the topic on the agenda 2 weeks in advance. =20 =20 Sue=20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Robert Raszuk Sent: Wednesday, October 22, 2014 10:51 AM To: Jeff Haas Cc: Benoit Claise; Thomas D. Nadeau; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org; Adrian Farrel Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 =20 > The comment about taking your ball and going someplace else to=20 > play ( meetup.com) was not worthy of a chair, = Tom. =20 Jeff, =20 I am not sure I am with you. My point was that whatever tools we have in = place should be used.=20 =20 For me - I would highly appreciate if Derek alone would record a = sessions and explain his draft. Then publish it on you tube.=20 =20 That's it.=20 =20 Maybe it should not be called interim meeting .. maybe IETF has no name = for it, but just progressing work based on the 3 meetings a year + = mailing lists seems not to be the most efficient choice these days. = There are many ways to improve it.=20 =20 The only question is if IETF is ready for it or not.=20 =20 Cheers, R. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 On Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas wrote: =20 On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: Adrian, =20 Ah that document I know. But this is almost completely different topic.=20 =20 At least to me I2RS is not about configuring OSPF protocol. It is about = collecting and possibly augmenting routing system with data.=20 =20 On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. =20 Just for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go. =20 I2RS is not in the business of trying to do the modeling work of other = WG's protocols. =20 =20 I2RS is definitely in the business of seeing standardized models advance = so we can hook into them. =20 Figuring out the most productive way to have that discussion has = obviously been a bit bumpy. Hence, one of the reasons to have the = rtg-yang-coord list. =20 FWIW, I agree with Adrian that the scope of the netmod interim design = sessions has crept a bit out of the expected charter. This isn't to say = that work shouldn't happen, but when it does: - There needs to be adequate notice (apparently Adrian's biggest = complaint) - Some mindfulness about group scope needs to be accommodated. =20 The comment about taking your ball and going someplace else to play = (meetup.com) was not worthy of a chair, Tom. While there's certainly = precedent in other orgs of working faster, there's also similar precent = of fork and fracture. =20 -- Jeff =20 =20 ------=_NextPart_000_05AA_01CFEE06.D60DD940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

I think the IETF is ready for the rapid response time in interims. I = think joint topics should get a 2 week=E2=80=99s notice if it involves = other WGs topics.=C2=A0 That=E2=80=99s simple planning by the co-chairs = who can put the topic on the agenda 2 weeks in advance.=C2=A0 =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Robert Raszuk
Sent: Wednesday, October 22, 2014 10:51 = AM
To: Jeff Haas
Cc: Benoit Claise; Thomas D. = Nadeau; ospf-chairs@tools.ietf.org; Rtg-yang-coord@ietf.org; Adrian = Farrel
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

 

> The = comment about taking your ball and going someplace else = to 

> play = (meetup.com) was not = worthy of a chair, Tom.

 

Jeff,<= span style=3D'font-family:"Courier = New"'>

 

I am not = sure I am with you. My point was that whatever tools we have in place = should be used. 

 

For me - I = would highly appreciate if Derek alone would record a sessions and = explain his draft. Then publish it on you tube. 

 

That's = it. 

 

Maybe it = should not be called interim meeting .. maybe IETF has no name for it, = but just progressing work based on the 3 meetings a year + mailing lists = seems not to be the most efficient choice these days. There are many = ways to improve it. 

 

The only = question is if IETF is ready for it or not. 

 

Cheers,
R.=

 

 =

 

 

 

 

 

 

 

 

 

 

 

On Wed, = Oct 22, 2014 at 4:43 PM, Jeff Haas <jhaas@juniper.net> wrote:

 

On = Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> = wrote:



Adrian,

 

Ah that document I know. But this is = almost completely different = topic. 

 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with = data. 

 

On the other hand Yang model takes = care about instatiation and management of a given protocol. There can be = some little overlap, but does not need to be at = all.

 

Just = for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go.

 

I2RS is not in the business of trying to do the = modeling work of other WG's protocols. =  

 

I2RS is definitely in the business of seeing = standardized models advance so we can hook into = them.

 

Figuring out the most productive way to have that = discussion has obviously been a bit bumpy.  Hence, one of the = reasons to have the rtg-yang-coord list.

 

FWIW, I agree with Adrian that the scope of the netmod = interim design sessions has crept a bit out of the expected = charter.  This isn't to say that work shouldn't happen, but when it = does:

- There needs to be = adequate notice (apparently Adrian's biggest = complaint)

- Some = mindfulness about group scope needs to be = accommodated.

 

The comment about taking your ball and going someplace = else to play (meetup.com) was not worthy of a chair, Tom.  = While there's certainly precedent in other orgs of working faster, = there's also similar precent of fork and = fracture.

 

-- = Jeff

 

 

------=_NextPart_000_05AA_01CFEE06.D60DD940-- From nobody Wed Oct 22 11:47:35 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF91ACFDE for ; Wed, 22 Oct 2014 11:47:29 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 aa-f1HGhm08w for ; Wed, 22 Oct 2014 11:47:22 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0425C1ACFD3 for ; Wed, 22 Oct 2014 11:47:21 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so3975523yho.24 for ; Wed, 22 Oct 2014 11:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AJ5ObMG6LSHdPnT7PW0p+DLQEGUKEup2umxeSQosNtI=; b=0z9aEy0+D1JL2PCDAV0koaxqO0dbXEMP8UegkQj+BQ0ASKsk4jLgnMg7Zlk0gbg4cK lLexnjr3ovJmttx2EWBcIdxp93a0iOmjtNXkwcIXcy2UgGtzWSJysQ+nTgC/Ff1bgDYZ FaI+254V1k+AqIcoP4MgiEu3s5JyEe9bU6txVLMrktgx2tzDtXC3TU0McAXaXTsG5a12 QjGHpQDW04NcLv+wuoL1eZOdAc9it+j7iY/5nsqfaRiYS4oiZzu0AMXhpvrJdaO2j4Hl uC0UCv+2rqmUtpMh21ZQmyKxkGkH71YUJvBCBlOX7MVz26FCu9hRrtHGdsyY6hLXNHxo 9Ndg== MIME-Version: 1.0 X-Received: by 10.236.23.231 with SMTP id v67mr19079yhv.48.1414003641129; Wed, 22 Oct 2014 11:47:21 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Wed, 22 Oct 2014 11:47:20 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Date: Wed, 22 Oct 2014 14:47:20 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=089e0122a6cabd9ff1050607608c Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/1rqkcaV8EIT0UTQEX_wDQaVTPCM Cc: Rtg-yang-coord@ietf.org, "Thomas D. Nadeau" , Jeff Haas , Ospf Chairs , Benoit Claise , Adrian Farrel Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:47:29 -0000 --089e0122a6cabd9ff1050607608c Content-Type: text/plain; charset=UTF-8 Robert, The IETF is absolutely ready for progressing work beyond 3 meetings a year + mailing lists. For instance, NVO3 has had 3 virtual interims between last IETF and now and plans to continue doing so after this IETF. A meeting without the right and interested participants is not so useful. That's why sending out the agenda a week ahead of time is important. The sky isn't falling here. Alia On Wed, Oct 22, 2014 at 10:51 AM, Robert Raszuk wrote: > > > The comment about taking your ball and going someplace else to > > play (meetup.com) was not worthy of a chair, Tom. > > Jeff, > > I am not sure I am with you. My point was that whatever tools we have in > place should be used. > > For me - I would highly appreciate if Derek alone would record a sessions > and explain his draft. Then publish it on you tube. > > That's it. > > Maybe it should not be called interim meeting .. maybe IETF has no name > for it, but just progressing work based on the 3 meetings a year + mailing > lists seems not to be the most efficient choice these days. There are many > ways to improve it. > > The only question is if IETF is ready for it or not. > > Cheers, > R. > > > > > > > > > > > > > > On Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas wrote: > >> >> On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: >> >> Adrian, >> >> Ah that document I know. But this is almost completely different topic. >> >> At least to me I2RS is not about configuring OSPF protocol. It is about >> collecting and possibly augmenting routing system with data. >> >> On the other hand Yang model takes care about instatiation and management >> of a given protocol. There can be some little overlap, but does not need to >> be at all. >> >> >> Just for clarity, the long term goal of Sue's draft was *not* to be a >> competing ospf draft, it was to provide enough of an example config base to >> demonstrate where I2RS hooks would go. >> >> I2RS is not in the business of trying to do the modeling work of other >> WG's protocols. >> >> I2RS is definitely in the business of seeing standardized models advance >> so we can hook into them. >> >> Figuring out the most productive way to have that discussion has >> obviously been a bit bumpy. Hence, one of the reasons to have the >> rtg-yang-coord list. >> >> FWIW, I agree with Adrian that the scope of the netmod interim design >> sessions has crept a bit out of the expected charter. This isn't to say >> that work shouldn't happen, but when it does: >> - There needs to be adequate notice (apparently Adrian's biggest >> complaint) >> - Some mindfulness about group scope needs to be accommodated. >> >> The comment about taking your ball and going someplace else to play ( >> meetup.com) was not worthy of a chair, Tom. While there's certainly >> precedent in other orgs of working faster, there's also similar precent of >> fork and fracture. >> >> -- Jeff >> >> > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > --089e0122a6cabd9ff1050607608c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

The IETF is absolutely ready fo= r progressing work beyond 3 meetings a year + mailing lists.=C2=A0 For inst= ance, NVO3 has had 3 virtual interims between last IETF and now and plans t= o continue doing so after this IETF.

A meeting wit= hout the right and interested participants is not so useful.=C2=A0 That'= ;s why sending out the agenda a week ahead of time is important.
=
The sky isn't falling here.

Ali= a

On W= ed, Oct 22, 2014 at 10:51 AM, Robert Raszuk <robert@raszuk.net> wrote:

> The comment about taking your= ball and going someplace else to=C2=A0
> play (meetup.com) was not worthy of a chair, Tom.
=

Jeff,

I am not sure I am with you. My point was that = whatever tools we have in place should be used.=C2=A0
=
For me - I would highly appreciate if Derek alone= would record a sessions and explain his draft. Then publish it on you tube= .=C2=A0

That's it.=C2=A0=

Maybe it should not be ca= lled interim meeting .. maybe IETF has no name for it, but just progressing= work based on the 3 meetings a year + mailing lists seems not to be the mo= st efficient choice these days. There are many ways to improve it.=C2=A0

The only question is if IETF i= s ready for it or not.=C2=A0

Cheers,
R.

=C2=A0=






<= /span>


=


On = Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas <jhaas@juniper.net> = wrote:

On Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net>= wrote:

A= drian,

Ah that document I know. = But this is almost completely different topic.=C2=A0
At least to me I2RS is not about configuring OSPF prot= ocol. It is about collecting and possibly augmenting routing system with da= ta.=C2=A0

On the other hand Ya= ng model takes care about instatiation and management of a given protocol. = There can be some little overlap, but does not need to be at all.

Just for clarity, the long term goal o= f Sue's draft was *not* to be a competing ospf draft, it was to provide= enough of an example config base to demonstrate where I2RS hooks would go.=

I2RS is not in the business of trying to do the m= odeling work of other WG's protocols. =C2=A0

I= 2RS is definitely in the business of seeing standardized models advance so = we can hook into them.

Figuring out the most produ= ctive way to have that discussion has obviously been a bit bumpy.=C2=A0 Hen= ce, one of the reasons to have the rtg-yang-coord list.

FWIW, I agree with Adrian that the scope of the netmod interim design= sessions has crept a bit out of the expected charter.=C2=A0 This isn't= to say that work shouldn't happen, but when it does:
- There= needs to be adequate notice (apparently Adrian's biggest complaint)
- Some mindfulness about group scope needs to be accommodated.


--= Jeff



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--089e0122a6cabd9ff1050607608c-- From nobody Wed Oct 22 11:49:14 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543901A90FB; Wed, 22 Oct 2014 11:49:13 -0700 (PDT) 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 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 3v8QEgsAC3YL; Wed, 22 Oct 2014 11:49:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA491ACF08; Wed, 22 Oct 2014 11:48:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'rapenno'" , , , References: In-Reply-To: Date: Wed, 22 Oct 2014 14:48:39 -0400 Message-ID: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05DA_01CFEE07.44991AA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlznl6EaXzdWJBjKvNLlfL9/Ql/JsQtETA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/BR3Ddik1aRvz3BQH3sfMv4b8MKc Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:49:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05DA_01CFEE07.44991AA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tom:=20 =20 I have an I2RS related SFC yang model (state and policy) to discuss as = well. May this get added to the next interim if time allows.=20 =20 Sue=20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of rapenno Sent: Tuesday, October 21, 2014 7:32 PM To: tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus =20 I would like to discuss SFC yang modelnif time permits =20 =20 Sent from Samsung Mobile -------- Original message -------- From: "Thomas D. Nadeau" =20 Date:=20 To: NETMOD Working Group ,rtg-yang-coord@ietf.org=20 Subject: [netmod] interim meeting: yang model focus=20 [adding rtg-yang-coord] Tomorrow's meeting will use the same WebEx from last time (and the same = as was used last week at the Yang 1.1-focused meeting).=20 Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa ; = myeung@cisco.com Are there any other models people wish to discuss? --Tom _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_05DA_01CFEE07.44991AA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Tom:

 

I have an I2RS related SFC yang model (state and policy) to discuss = as well.=C2=A0 May this get added to the next interim if time allows. =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = rapenno
Sent: Tuesday, October 21, 2014 7:32 = PM
To: tnadeau@lucidvision.com; netmod@ietf.org; = rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] [netmod] = interim meeting: yang model focus

 

I = would like to discuss SFC yang modelnif time = permits

 

 

Sent = from Samsung Mobile




-------- Original message = --------
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com> =
Date:
To: NETMOD Working Group <netmod@ietf.org>,rtg-yang-coord@ie= tf.org
Subject: [netmod] interim meeting: yang model focus =


[adding  rtg-yang-coord]


Tomorrow's meeting = will use the same WebEx from last time (and the same as was used last = week at the Yang 1.1-focused meeting).

Tomorrow's interim = meeting has the following preliminary agenda:

0) Quickly how to = use IRC/sign-in
1) Note Well
2) Agenda Bashing
3) OSPF Model - = Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>; myeung@cisco.com


Are = there any other models people wish to = discuss?

--Tom



____________________________________= ___________
netmod mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

------=_NextPart_000_05DA_01CFEE07.44991AA0-- From nobody Wed Oct 22 11:51:02 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80541ACF9F; Wed, 22 Oct 2014 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=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 RNeaWAZPF-4Q; Wed, 22 Oct 2014 11:50:59 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F39441A87BB; Wed, 22 Oct 2014 11:50:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "'Benoit Claise'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Wed, 22 Oct 2014 14:50:52 -0400 Message-ID: <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAiRwUfGbkPfe0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/8q5LTCYLsFfuXx2n0gqCHce2KB4 Cc: Rtg-yang-coord@ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:51:00 -0000 Stephane: I think it is important to receive both the wisdom from the netmod WG and the protocol WG. I find that there are yang model consistencies and limitations that require aid in the yang models I've worked on. This is especially true for the state and ephemeral state. Sue -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Wednesday, October 22, 2014 9:45 AM To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Hi, I also agree that this is a bad idea. I thought that IETF willing and especially yours, Benoit, was to speed up availability of standard models. The process of having small teams working with weekly calls works almost good but we still have some issue that are both technical (dedicated to the topic addressed by the model) and also YANG writing, model consistencies ... that requires discussion, and as often mailing list is not as good as meetings (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim meetings in Netmod to discuss proposed Yang models : this will ensure consistency between models and will help to solve global issues in modeling. It's just the starting of Yang modeling, leaving only Yang models within home WG (ISIS for my point of view) would be, IMO, a very bad idea and will for sure slow down the availability of standards ... and I also think that it may discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has and IS driving people away from the IETF to other places where this work is going to get done. The simple effect of such silliness will be a reduction in speed and quantity of model development. If the goal of the IESG is to slow down the velocity of model development and creation, then this approach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused on Yang and the other on modeling; is not NETMOD-specific per say, but to promote model creation because no other bi-weekly forum exists to do so. It is also a place to bring in non-IETF work such as the work done in ODL, other open source, or just the public community that has explicitly wanted to avoid the IETF. We have found it a convenient and fruitful place to discuss, and actually *build* models - regardless of their ultimate WG home. The simple reason: its a single place for many of the experts to gather. I think you will find it very difficult to get those people onto a per-WG call every other week. I hope the IESG considers this approach carefully because I do not think it will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > Dear all, > > Today NETMOD interim meeting is canceled. > > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for which there is no milestone in the working group and for which there is an obvious home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce > list as is required > > Regards, Benoit > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Oct 22 11:55:59 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD41ACFA6 for ; Wed, 22 Oct 2014 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 l_9FOLs4xIYk for ; Wed, 22 Oct 2014 11:55:55 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11C71ACFE5 for ; Wed, 22 Oct 2014 11:55:54 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id l13so47279iga.2 for ; Wed, 22 Oct 2014 11:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=y4ft7aeXPXhPhA8eB5zlzoocIakWNu3PG45or/sz+8Q=; b=mp4zcK5LFDHeM1sEHapCUchsGLzk9Bxsb1cKzX3BIp2rSsKPrJhVQOk+zunYWuYk6/ L9T58D2mbC8v9LkxTuwrOOjhAZ5uozvIVWcM1T2eEETm49OWiRgVCOWFmhcluEtqnf5p HqiQbraQHQUd9a6sEx86fOJVjCxOt1SUMN80l/E6Z6V2ypkrzLX/IjmVeSwrBHzMoKS6 iHs0ZLhmkbpRsTq22JLYvY77kbAue1Y2tzIgkD7mRQAd8OLXrt++Uo4H1hTKaL3vcycL KLUR+zr6eEnYQUuvU24mVbU2zpyVW2VqRVgsz+y99pk7s/yUhHBjDkqICTHGZUAlnL43 Bxng== MIME-Version: 1.0 X-Received: by 10.50.25.169 with SMTP id d9mr4775161igg.17.1414004154265; Wed, 22 Oct 2014 11:55:54 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 11:55:54 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> Date: Wed, 22 Oct 2014 20:55:54 +0200 X-Google-Sender-Auth: Y74zy-alHNcyyBZbvZtaoew9YFY Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7bdc1a685378fb0506077fc7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vH1IX5NA-7ioHYL6Jy8ahnmKWNM Cc: Rtg-yang-coord@ietf.org, "Thomas D. Nadeau" , Jeff Haas , Ospf Chairs , Benoit Claise , Adrian Farrel Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:55:57 -0000 --047d7bdc1a685378fb0506077fc7 Content-Type: text/plain; charset=UTF-8 Alia & Sue, Apparently my intentions were not received as intended. I am not complaining on the way interim meetings are setup. It is good to have an agenda and even better to have it week or two in advance. For physical presence interims maybe even month or two. My point is much broader. Having been involved in different SDOs and in general open source community work I see that interims + 3 physical meetings + mailing lists and txt formatted drafts is not enough any more. A lot of good comments are received on a regular say weekly or bi-weekly live discussions, watching recording presentations without waiting for next physical meeting, building feature xyz from github, contributing to it, testing etc ... None of the latter happens in IETF. IETF seems like documents shepards in ITU :) World has moved and I really do not think IETF is catching up with those new trends in new projects handling. Moreover with most of IETF vendors not really (with some exceptions) involved in any serious open source products I see that current way IETF operates is unlikely to change any time soon. Cheers, R. On Wed, Oct 22, 2014 at 8:47 PM, Alia Atlas wrote: > Robert, > > The IETF is absolutely ready for progressing work beyond 3 meetings a year > + mailing lists. For instance, NVO3 has had 3 virtual interims between > last IETF and now and plans to continue doing so after this IETF. > > A meeting without the right and interested participants is not so useful. > That's why sending out the agenda a week ahead of time is important. > > The sky isn't falling here. > > Alia > > On Wed, Oct 22, 2014 at 10:51 AM, Robert Raszuk wrote: > >> >> > The comment about taking your ball and going someplace else to >> > play (meetup.com) was not worthy of a chair, Tom. >> >> Jeff, >> >> I am not sure I am with you. My point was that whatever tools we have in >> place should be used. >> >> For me - I would highly appreciate if Derek alone would record a sessions >> and explain his draft. Then publish it on you tube. >> >> That's it. >> >> Maybe it should not be called interim meeting .. maybe IETF has no name >> for it, but just progressing work based on the 3 meetings a year + mailing >> lists seems not to be the most efficient choice these days. There are many >> ways to improve it. >> >> The only question is if IETF is ready for it or not. >> >> Cheers, >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas wrote: >> >>> >>> On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: >>> >>> Adrian, >>> >>> Ah that document I know. But this is almost completely different topic. >>> >>> At least to me I2RS is not about configuring OSPF protocol. It is about >>> collecting and possibly augmenting routing system with data. >>> >>> On the other hand Yang model takes care about instatiation and >>> management of a given protocol. There can be some little overlap, but does >>> not need to be at all. >>> >>> >>> Just for clarity, the long term goal of Sue's draft was *not* to be a >>> competing ospf draft, it was to provide enough of an example config base to >>> demonstrate where I2RS hooks would go. >>> >>> I2RS is not in the business of trying to do the modeling work of other >>> WG's protocols. >>> >>> I2RS is definitely in the business of seeing standardized models advance >>> so we can hook into them. >>> >>> Figuring out the most productive way to have that discussion has >>> obviously been a bit bumpy. Hence, one of the reasons to have the >>> rtg-yang-coord list. >>> >>> FWIW, I agree with Adrian that the scope of the netmod interim design >>> sessions has crept a bit out of the expected charter. This isn't to say >>> that work shouldn't happen, but when it does: >>> - There needs to be adequate notice (apparently Adrian's biggest >>> complaint) >>> - Some mindfulness about group scope needs to be accommodated. >>> >>> The comment about taking your ball and going someplace else to play ( >>> meetup.com) was not worthy of a chair, Tom. While there's certainly >>> precedent in other orgs of working faster, there's also similar precent of >>> fork and fracture. >>> >>> -- Jeff >>> >>> >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> > --047d7bdc1a685378fb0506077fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alia & Sue,

Apparently my intentions were not received as intended.=C2= =A0

I am not complaining on the = way interim meetings are setup. It is good to have an agenda and even bette= r to have it week or two in advance. For physical presence interims maybe e= ven month or two.=C2=A0

My point= is much broader. Having been involved in different SDOs and in general ope= n source community work I see that interims + 3 physical meetings + mailing= lists and txt formatted drafts is not enough any more.=C2=A0

A lot of good comments are received on a regu= lar say weekly or bi-weekly live discussions, watching recording presentati= ons without waiting for next physical meeting, building feature xyz from gi= thub, contributing to it, testing etc ...=C2=A0

None of the latter happens in IETF. IETF seems like documen= ts shepards in ITU :) World has moved and I really do not think IETF is cat= ching up with those new trends in new projects handling.=C2=A0

Moreover with most of IETF vendors not reall= y (with some exceptions) involved in any serious open source products I see= that current way IETF operates is unlikely to change any time soon.
<= div class=3D"gmail_default" style=3D"font-family:courier new,monospace;font= -size:small">
Cheers,
R.











On Wed, Oct 22, 2014 at 8:47 PM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
Robert,
The IETF is absolutely ready for progressing work beyond 3= meetings a year + mailing lists.=C2=A0 For instance, NVO3 has had 3 virtua= l interims between last IETF and now and plans to continue doing so after t= his IETF.

A meeting without the right and interest= ed participants is not so useful.=C2=A0 That's why sending out the agen= da a week ahead of time is important.

The sky isn&= #39;t falling here.

Alia
<= br>
On Wed, Oct 22, 2014 a= t 10:51 AM, Robert Raszuk <robert@raszuk.net> wrote:

> The comment about taking = your ball and going someplace else to=C2=A0
> play = (meetup.com) was not worthy of a chair, Tom.=

Jeff,

I am not sure I am with you. My point was tha= t whatever tools we have in place should be used.=C2=A0

For me - I would highly appreciate if Derek alo= ne would record a sessions and explain his draft. Then publish it on you tu= be.=C2=A0

That's it.=C2= =A0

Maybe it should not be c= alled interim meeting .. maybe IETF has no name for it, but just progressin= g work based on the 3 meetings a year + mailing lists seems not to be the m= ost efficient choice these days. There are many ways to improve it.=C2=A0

The only question is if IETF = is ready for it or not.=C2=A0

Cheers,
R.

=C2=A0






=





On Wed, Oct 22, 2014 at 4:43 PM,= Jeff Haas <jhaas@juniper.net> wrote:

On Oc= t 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> wrote:

Adrian,
<= br>
Ah that document I know. But this is almost complete= ly different topic.=C2=A0

At lea= st to me I2RS is not about configuring OSPF protocol. It is about collectin= g and possibly augmenting routing system with data.=C2=A0

On the other hand Yang model takes care about i= nstatiation and management of a given protocol. There can be some little ov= erlap, but does not need to be at all.

Just for clarity, the long term goal of Sue's draft was *not*= to be a competing ospf draft, it was to provide enough of an example confi= g base to demonstrate where I2RS hooks would go.

I= 2RS is not in the business of trying to do the modeling work of other WG= 9;s protocols. =C2=A0

I2RS is definitely in the bu= siness of seeing standardized models advance so we can hook into them.

Figuring out the most productive way to have that disc= ussion has obviously been a bit bumpy.=C2=A0 Hence, one of the reasons to h= ave the rtg-yang-coord list.

FWIW, I agree with Ad= rian that the scope of the netmod interim design sessions has crept a bit o= ut of the expected charter.=C2=A0 This isn't to say that work shouldn&#= 39;t happen, but when it does:
- There needs to be adequate notic= e (apparently Adrian's biggest complaint)
- Some mindfulness = about group scope needs to be accommodated.

The co= mment about taking your ball and going someplace else to play (meetup.com) was not worthy of a cha= ir, Tom.=C2=A0 While there's certainly precedent in other orgs of worki= ng faster, there's also similar precent of fork and fracture.

-- Jeff

<= /font>


______________________________= _________________
Rtg-yang-coord mailing list
Rtg-yang-coord= @ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord



--047d7bdc1a685378fb0506077fc7-- From nobody Wed Oct 22 11:56:27 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14D1ACFEB; Wed, 22 Oct 2014 11:56:22 -0700 (PDT) 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 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 UuZFCn0YhB20; Wed, 22 Oct 2014 11:56:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6101D1ACFF1; Wed, 22 Oct 2014 11:56:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 14:56:09 -0400 Message-ID: <061201cfee29$d87b9000$8972b000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0613_01CFEE08.516F4730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9Swm0v53gA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/80qTVoZqTfot13CL58a-mjxwzyM Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:56:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0613_01CFEE08.516F4730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0613_01CFEE08.516F4730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric:

 

What were the OpenDaylight topics for the call?  =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Eric Voit (evoit)
Sent: Wednesday, October 22, 2014 11:20 = AM
To: Thomas D. Nadeau; Andy Bierman
Cc: = Rtg-yang-coord@ietf.org; NETMOD Working Group; = ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; Farrel Adrian
Subject: Re: = [Rtg-yang-coord] [netmod] NETMOD interim meeting = canceled

 

As Tom = and others note, today’s Netmod interim was to have topics beyond = OSPF.  These included OpenDaylight related work.   The = IETF should be encouraging venues for Open Source developer = audiences.  Cancelling full meetings via IETF procedural mechanisms = signals the opposite. 

 

I = *like* the idea of each WG being the owner for their domain = models.  This scales well for the reasons  pointed out = below.  And I do have sympathy for a WG wanting to close on a = definitive answer for a YANG model before implications are discussed = elsewhere.   But I am worried that we are enforcing an overly = serial process.  Or of constraining communication.  The market = will work around this.  

 

In the = controller space, YANG technology is not static.  Some degree of = parallelism is needed across IETF WGs.  Clueful Open Source/YANG = developers cannot extend themselves across all WG where YANG modeling = might occur.

 

Eric

 

 

From:= = Thomas D. Nadeau, October 22, 2014 10:52 AM

        &n= bsp; We are trying. The thing is that you cannot just hoist that = onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to = accommodate that case.   And while some WGs in the routing area are = not enthusiastic about building models, others aren’t, nor are = other WGs at the IETF. So for those, what do you do? Ignore them? The = other point is that others outside of the IETF are working on these = models.  It is squarely within the IETF community’s interest = to bring these back into the fold.  Many of these folks are = skittish about coming to the IETF altogether so we’ve tried to = encourage them to participate in this way. If we want to push these = folks away with procedural reasons, then we have made our = bed...

 

        &n= bsp; —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi,

 

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,

and YANG Mount = topics. I was going to call in for those, not = OSPF.

But I have been = saying (for over a year now) that it is time to = move

domain-specific data = models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

Andy

 

 

On Wed, = Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don’t want to do them, have the expertise to do them, = etc…  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small “design team” fashion, = right?

 

And in terms of today’s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won’t have another interim meeting until after Hawaii, so = the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community = wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

------=_NextPart_000_0613_01CFEE08.516F4730-- From nobody Wed Oct 22 12:13:40 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D631ACFEA; Wed, 22 Oct 2014 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Dcvgae9OlgaK; Wed, 22 Oct 2014 12:13:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A04D1ACF8B; Wed, 22 Oct 2014 12:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33071; q=dns/txt; s=iport; t=1414005195; x=1415214795; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Odlc9ScreNuzCTuo07KVItUZCWbjWBn+BxXEXqY1B5o=; b=Mu/LDebut9pjEVoXNqRVQ+W715s0jc0xTI2o4qnRV/n2pxhXDpXgezg1 RMBiw1Inzdyfr3eKwmD/5VHxhrGVTT+MGe5bNaihQHiK61XJ39bkKw5Vy DoOu1JgqDuV7gZXfMYSkLgoCqOG6B35mUXfeuZ0xDpS1Z7v/jb4+TPJAG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAGgASFStJA2N/2dsb2JhbABSCoJIRlRYBLwfjk6BZgELhndUAoEOFgF9hAIBAQECAgEBASo+AwsMBAIBCA4DBAEBAQoWAQYHJwsUCQgCBAENBQgBCwuIIQ3FfQEBAQEBAQEBAQEBAQEBAQEBAQEBAReKVoUlKy0EBgEGgyeBHgWPZoIehEaIRDyQPIQBg3hsAYEFBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,770,1406592000"; d="scan'208,217";a="365546372" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2014 19:13:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9MJDB16025467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 19:13:11 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 14:13:11 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7ingTtZBL8o2rEqTZTZCzObUr5w8eSrA Date: Wed, 22 Oct 2014 19:13:10 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <061201cfee29$d87b9000$8972b000$@ndzh.com> In-Reply-To: <061201cfee29$d87b9000$8972b000$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/6fytg0H2142KWdOQKTJmOOyHq7I Cc: "Rtg-yang-coord@ietf.org" , 'NETMOD Working Group' , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:13:27 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two weeks ago at the Netmod Interim, we discussed: http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements= / http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ We used these slides= to introduce the topics. On the Netmod interim agenda today was to be a recap/summary of the resulti= ng mailing list discussions, as well the teeing up of exactly what could be= on the plate for Hawaii Netmod face-to-face. Thanks, Eric From: Susan Hares, October 22, 2014 2:56 PM Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working= Group; ospf-chairs@tools.ietf.org; ops-= ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two weeks ago at the Netm= od Interim, we discussed:

  http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

  http://datatracker.ietf.org/doc/draft-clemm-ne= tmod-mount/

We used these sli= des to introduce the topics.  

 <= /p>

On the Netmod interim age= nda today was to be a recap/summary of the resulting mailing list discussio= ns, as well the teeing up of exactly what could be on the plate for Hawaii Netmod face-to-face.

 <= /p>

Thanks,=

Eric

 <= /p>

 <= /p>

From: Susan Ha= res, October 22, 2014 2:56 PM

Eric:

 <= /p>

What were the OpenDayligh= t topics for the call? 

 <= /p>

Sue

 <= /p>

From: Rtg-yang= -coord [mailto:rtg-yang-= coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, October 22, 2014 11:20 AM
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.o= rg; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-a= ds@tools.ietf.org; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting cancel= ed

 

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From:<= /span> Thomas D. Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_-- From nobody Wed Oct 22 12:23:00 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290B1AD2DF for ; Wed, 22 Oct 2014 12:22:58 -0700 (PDT) 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 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 ZhnuFGnTug26 for ; Wed, 22 Oct 2014 12:22:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B4BC31AD001 for ; Wed, 22 Oct 2014 12:22:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Robert Raszuk'" , "'Alia Atlas'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <9E50D1E0-F13A-4D1A-A49C-89F4768583E2@juniper.net> In-Reply-To: Date: Wed, 22 Oct 2014 15:22:48 -0400 Message-ID: <069501cfee2d$915e2940$b41a7bc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0696_01CFEE0C.0A520780" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB5/SL9wJNt2mYAf8q9iwCT61kDAHUcyBzAWhwiWgC9M6Wqpsczd4g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/gOrXZ2DzUBuonSun0Im7Hq3GhUQ Cc: Rtg-yang-coord@ietf.org, "'Thomas D. Nadeau'" , 'Jeff Haas' , 'Ospf Chairs' , 'Benoit Claise' , 'Adrian Farrel' Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:22:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0696_01CFEE0C.0A520780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 I think IETF is in the process of changing. I think this = morning=E2=80=99s problem was just a clear indication of the = agenda=E2=80=99s scope, and advance cross-group warning. The weekly = interims are awesome. IETF=E2=80=99s changing - so perhaps in an = offline memo you can suggest ways you can help I2rs and IDR yang work go = quicker.=20 =20 I looked into the OpenDaylight work as prototyping place, but = OpenDaylight has an Eclipse license. Does this create an IETF IPR = problem? I rather like the OpenDaylight BGP module.=20 =20 Sue=20 =20 PS =E2=80=93 I hope to get my I2rs yang modules in github before IETF = 91. =20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Robert Raszuk Sent: Wednesday, October 22, 2014 2:56 PM To: Alia Atlas Cc: Rtg-yang-coord@ietf.org; Thomas D. Nadeau; Jeff Haas; Ospf Chairs; = Benoit Claise; Adrian Farrel Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled =20 Alia & Sue, =20 Apparently my intentions were not received as intended.=20 =20 I am not complaining on the way interim meetings are setup. It is good = to have an agenda and even better to have it week or two in advance. For = physical presence interims maybe even month or two.=20 =20 My point is much broader. Having been involved in different SDOs and in = general open source community work I see that interims + 3 physical = meetings + mailing lists and txt formatted drafts is not enough any = more.=20 =20 A lot of good comments are received on a regular say weekly or bi-weekly = live discussions, watching recording presentations without waiting for = next physical meeting, building feature xyz from github, contributing to = it, testing etc ...=20 =20 None of the latter happens in IETF. IETF seems like documents shepards = in ITU :) World has moved and I really do not think IETF is catching up = with those new trends in new projects handling.=20 =20 Moreover with most of IETF vendors not really (with some exceptions) = involved in any serious open source products I see that current way IETF = operates is unlikely to change any time soon. =20 Cheers, R. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 On Wed, Oct 22, 2014 at 8:47 PM, Alia Atlas wrote: Robert, =20 The IETF is absolutely ready for progressing work beyond 3 meetings a = year + mailing lists. For instance, NVO3 has had 3 virtual interims = between last IETF and now and plans to continue doing so after this = IETF. =20 A meeting without the right and interested participants is not so = useful. That's why sending out the agenda a week ahead of time is = important. =20 The sky isn't falling here. =20 Alia =20 On Wed, Oct 22, 2014 at 10:51 AM, Robert Raszuk = wrote: =20 > The comment about taking your ball and going someplace else to=20 > play ( meetup.com) was not worthy of a chair, = Tom. =20 Jeff, =20 I am not sure I am with you. My point was that whatever tools we have in = place should be used.=20 =20 For me - I would highly appreciate if Derek alone would record a = sessions and explain his draft. Then publish it on you tube.=20 =20 That's it.=20 =20 Maybe it should not be called interim meeting .. maybe IETF has no name = for it, but just progressing work based on the 3 meetings a year + = mailing lists seems not to be the most efficient choice these days. = There are many ways to improve it.=20 =20 The only question is if IETF is ready for it or not.=20 =20 Cheers, R. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 On Wed, Oct 22, 2014 at 4:43 PM, Jeff Haas wrote: =20 On Oct 22, 2014, at 10:18 AM, Robert Raszuk wrote: Adrian, =20 Ah that document I know. But this is almost completely different topic.=20 =20 At least to me I2RS is not about configuring OSPF protocol. It is about = collecting and possibly augmenting routing system with data.=20 =20 On the other hand Yang model takes care about instatiation and = management of a given protocol. There can be some little overlap, but = does not need to be at all. =20 Just for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go. =20 I2RS is not in the business of trying to do the modeling work of other = WG's protocols. =20 =20 I2RS is definitely in the business of seeing standardized models advance = so we can hook into them. =20 Figuring out the most productive way to have that discussion has = obviously been a bit bumpy. Hence, one of the reasons to have the = rtg-yang-coord list. =20 FWIW, I agree with Adrian that the scope of the netmod interim design = sessions has crept a bit out of the expected charter. This isn't to say = that work shouldn't happen, but when it does: - There needs to be adequate notice (apparently Adrian's biggest = complaint) - Some mindfulness about group scope needs to be accommodated. =20 The comment about taking your ball and going someplace else to play = (meetup.com) was not worthy of a chair, Tom. While there's certainly = precedent in other orgs of working faster, there's also similar precent = of fork and fracture. =20 -- Jeff =20 =20 =20 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 =20 ------=_NextPart_000_0696_01CFEE0C.0A520780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

I think IETF is in the process of changing.=C2=A0 I think this = morning=E2=80=99s problem was just a clear indication of the = agenda=E2=80=99s scope, and advance cross-group warning.=C2=A0 The = weekly interims are awesome. =C2=A0IETF=E2=80=99s changing=C2=A0 - so = perhaps in an offline memo you can suggest ways you can help I2rs and = IDR yang work go quicker.

 

I looked into the OpenDaylight work as prototyping place, but = OpenDaylight has an Eclipse license.=C2=A0 Does this create an IETF IPR = problem? =C2=A0I rather like the OpenDaylight BGP module. =

 

Sue

 

PS =E2=80=93 I hope to get my I2rs yang modules in github before IETF = 91. =C2=A0=C2=A0

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Robert Raszuk
Sent: Wednesday, October 22, 2014 2:56 = PM
To: Alia Atlas
Cc: Rtg-yang-coord@ietf.org; = Thomas D. Nadeau; Jeff Haas; Ospf Chairs; Benoit Claise; Adrian = Farrel
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled

 

Alia & = Sue,

 

Apparently my intentions were not = received as intended. 

 

I am not complaining on the way = interim meetings are setup. It is good to have an agenda and even better = to have it week or two in advance. For physical presence interims maybe = even month or two. 

 

My point is much broader. Having = been involved in different SDOs and in general open source community = work I see that interims + 3 physical meetings + mailing lists and txt = formatted drafts is not enough any = more. 

 

A lot of good comments are received = on a regular say weekly or bi-weekly live discussions, watching = recording presentations without waiting for next physical meeting, = building feature xyz from github, contributing to it, testing etc = ... 

 

None of the latter happens in IETF. = IETF seems like documents shepards in ITU :) World has moved and I = really do not think IETF is catching up with those new trends in new = projects handling. 

 

Moreover with most of IETF vendors = not really (with some exceptions) involved in any serious open source = products I see that current way IETF operates is unlikely to change any = time soon.

 

Cheers,

R.

 

 

 

 

 

 

 

 

 

 

 

On Wed, = Oct 22, 2014 at 8:47 PM, Alia Atlas <akatlas@gmail.com> wrote:

Robert,

 

The IETF is absolutely ready for progressing work = beyond 3 meetings a year + mailing lists.  For instance, NVO3 has = had 3 virtual interims between last IETF and now and plans to continue = doing so after this IETF.

 

A = meeting without the right and interested participants is not so = useful.  That's why sending out the agenda a week ahead of time is = important.

 

The sky isn't falling = here.

 

Alia

 

On Wed, Oct 22, 2014 at 10:51 AM, Robert Raszuk <robert@raszuk.net> = wrote:

 

> The = comment about taking your ball and going someplace else = to 

> play = (meetup.com) was not = worthy of a chair, Tom.

 

Jeff,<= span style=3D'font-family:"Courier = New"'>

 

I am not = sure I am with you. My point was that whatever tools we have in place = should be used. 

 

For me - I = would highly appreciate if Derek alone would record a sessions and = explain his draft. Then publish it on you tube. 

 

That's = it. 

 

Maybe it = should not be called interim meeting .. maybe IETF has no name for it, = but just progressing work based on the 3 meetings a year + mailing lists = seems not to be the most efficient choice these days. There are many = ways to improve it. 

 

The only = question is if IETF is ready for it or not. 

 

Cheers,
R.=

 

 =

 

 

 

 

 

 

 

 

 

 

 

On Wed, = Oct 22, 2014 at 4:43 PM, Jeff Haas <jhaas@juniper.net> wrote:

 

On = Oct 22, 2014, at 10:18 AM, Robert Raszuk <robert@raszuk.net> = wrote:



Adrian,

 

Ah that document I know. But this is = almost completely different = topic. 

 

At least to me I2RS is not about = configuring OSPF protocol. It is about collecting and possibly = augmenting routing system with = data. 

 

On the other hand Yang model takes = care about instatiation and management of a given protocol. There can be = some little overlap, but does not need to be at = all.

 

Just = for clarity, the long term goal of Sue's draft was *not* to be a = competing ospf draft, it was to provide enough of an example config base = to demonstrate where I2RS hooks would go.

 

I2RS is not in the business of trying to do the = modeling work of other WG's protocols. =  

 

I2RS is definitely in the business of seeing = standardized models advance so we can hook into = them.

 

Figuring out the most productive way to have that = discussion has obviously been a bit bumpy.  Hence, one of the = reasons to have the rtg-yang-coord list.

 

FWIW, I agree with Adrian that the scope of the netmod = interim design sessions has crept a bit out of the expected = charter.  This isn't to say that work shouldn't happen, but when it = does:

- There needs to be = adequate notice (apparently Adrian's biggest = complaint)

- Some = mindfulness about group scope needs to be = accommodated.

 

The comment about taking your ball and going someplace = else to play (meetup.com) was not worthy of a chair, Tom.  = While there's certainly precedent in other orgs of working faster, = there's also similar precent of fork and = fracture.

 

-- = Jeff

 

 

 

__________________________________________= _____
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

 

 

------=_NextPart_000_0696_01CFEE0C.0A520780-- From nobody Wed Oct 22 12:24:02 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A51AD2DF; Wed, 22 Oct 2014 12:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yk0D5ysyDVcB; Wed, 22 Oct 2014 12:23:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 406A81AD361; Wed, 22 Oct 2014 12:23:52 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5D05028D13DF; Wed, 22 Oct 2014 15:23:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> Date: Wed, 22 Oct 2014 15:23:50 -0400 Message-Id: References: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/dKk0fm6H5c63EPoD7vZwAwpPj48 Cc: rtg-yang-coord@ietf.org, netmod@ietf.org, rapenno Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:23:56 -0000 --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That depends on whether or not it offends the Routing Area ADs. =E2=80=94Tom > On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares = wrote: >=20 > Tom:=20 > =20 > I have an I2RS related SFC yang model (state and policy) to discuss as = well. May this get added to the next interim if time allows.=20 > =20 > Sue=20 > =20 > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org = ] On Behalf Of rapenno > Sent: Tuesday, October 21, 2014 7:32 PM > To: tnadeau@lucidvision.com ; = netmod@ietf.org ; rtg-yang-coord@ietf.org = > Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model = focus > =20 > I would like to discuss SFC yang modelnif time permits > =20 > =20 > Sent from Samsung Mobile >=20 >=20 >=20 > -------- Original message -------- > From: "Thomas D. Nadeau" >=20 > Date:=20 > To: NETMOD Working Group >,rtg-yang-coord@ietf.org = =20 > Subject: [netmod] interim meeting: yang model focus=20 >=20 >=20 > [adding rtg-yang-coord] >=20 >=20 > Tomorrow's meeting will use the same WebEx from last time (and the = same as was used last week at the Yang 1.1-focused meeting).=20 >=20 > Tomorrow's interim meeting has the following preliminary agenda: >=20 > 0) Quickly how to use IRC/sign-in > 1) Note Well > 2) Agenda Bashing > 3) OSPF Model - Kiran Agrahara Sreenivasa >; myeung@cisco.com = >=20 >=20 > Are there any other models people wish to discuss? >=20 > --Tom >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

That = depends on whether or not it offends the Routing Area ADs.

= =E2=80=94Tom


On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares <shares@ndzh.com> = wrote:

Tom: 
 
I have an I2RS related = SFC yang model (state and policy) to discuss as well.  May this get = added to the next interim if time allows. 
 
Sue 
 
From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of rapenno
Sent: Tuesday, October 21, 2014 = 7:32 PM
To: tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] = [netmod] interim meeting: yang model focus
 
I would like to = discuss SFC yang modelnif time permits
 
 
Sent from Samsung Mobile



-------- = Original message --------
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com> 
Date: 
To: NETMOD = Working Group <netmod@ietf.org>,rtg-yang-coord@ietf.org 
Subject: = [netmod] interim meeting: yang model focus 


[adding  rtg-yang-coord]


Tomorrow's meeting will use the same WebEx = from last time (and the same as was used last week at the Yang = 1.1-focused meeting). 

Tomorrow's interim meeting has the following preliminary = agenda:

0) Quickly how to use = IRC/sign-in
1) Note Well
2) Agenda = Bashing
3) OSPF Model - Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>; myeung@cisco.com


Are there any other models = people wish to discuss?

--Tom



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC-- From nobody Wed Oct 22 12:25:31 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3161AD376; Wed, 22 Oct 2014 12:25:08 -0700 (PDT) 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 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 9oS-NLwgUvEn; Wed, 22 Oct 2014 12:25:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 605AE1AD2DF; Wed, 22 Oct 2014 12:25:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <061201cfee29$d87b9000$8972b000$@ndzh.com> In-Reply-To: Date: Wed, 22 Oct 2014 15:24:55 -0400 Message-ID: <06c301cfee2d$dd3e9980$97bbcc80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06C4_01CFEE0C.56347390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9SwAhiAM4ICGsuFupsqZ37Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/isbe2lYNBgfkSsm6kjLRhQQAlOI Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:25:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06C4_01CFEE0C.56347390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very helpful slides. Will this be reschedule to November 5th? Sue From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Wednesday, October 22, 2014 3:13 PM To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman' Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian' Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Two weeks ago at the Netmod Interim, we discussed: http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/ http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ We used these slides to introduce the topics. On the Netmod interim agenda today was to be a recap/summary of the resulting mailing list discussions, as well the teeing up of exactly what could be on the plate for Hawaii Netmod face-to-face. Thanks, Eric From: Susan Hares, October 22, 2014 2:56 PM Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_06C4_01CFEE0C.56347390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very helpful slides.  Will this be reschedule to November = 5th?

 

Sue

 

From:= = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Wednesday, = October 22, 2014 3:13 PM
To: Susan Hares; 'Thomas D. Nadeau'; = 'Andy Bierman'
Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working = Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; 'Farrel Adrian'
Subject: RE: = [Rtg-yang-coord] [netmod] NETMOD interim meeting = canceled

 

Two weeks ago at the Netmod Interim, we = discussed:

  http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-r= equirements/

  http:/= /datatracker.ietf.org/doc/draft-clemm-netmod-mount/ =

We used these = slides to introduce the topics.  

 

On the Netmod interim agenda today was to be a recap/summary of the = resulting mailing list discussions, as well the teeing up of exactly = what could be on the plate for Hawaii Netmod = face-to-face.

 

Thanks,

Eric

 

 

From:= = Susan Hares, October 22, 2014 2:56 PM

Eric:

 

What were the OpenDaylight topics for the call?  =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bou= nces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: = Wednesday, October 22, 2014 11:20 AM
To: Thomas D. Nadeau; = Andy Bierman
Cc: Rtg-yang-coord@ietf.org; = NETMOD Working Group; ospf-chairs@tools.ietf.org= ; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; = Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD = interim meeting canceled

 

As Tom = and others note, today’s Netmod interim was to have topics beyond = OSPF.  These included OpenDaylight related work.   The = IETF should be encouraging venues for Open Source developer = audiences.  Cancelling full meetings via IETF procedural mechanisms = signals the opposite. 

 

I = *like* the idea of each WG being the owner for their domain = models.  This scales well for the reasons  pointed out = below.  And I do have sympathy for a WG wanting to close on a = definitive answer for a YANG model before implications are discussed = elsewhere.   But I am worried that we are enforcing an overly = serial process.  Or of constraining communication.  The market = will work around this.  

 

In the = controller space, YANG technology is not static.  Some degree of = parallelism is needed across IETF WGs.  Clueful Open Source/YANG = developers cannot extend themselves across all WG where YANG modeling = might occur.

 

Eric

 

 

From:= = Thomas D. Nadeau, October 22, 2014 10:52 AM

        &n= bsp; We are trying. The thing is that you cannot just hoist that = onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to = accommodate that case.   And while some WGs in the routing area are = not enthusiastic about building models, others aren’t, nor are = other WGs at the IETF. So for those, what do you do? Ignore them? The = other point is that others outside of the IETF are working on these = models.  It is squarely within the IETF community’s interest = to bring these back into the fold.  Many of these folks are = skittish about coming to the IETF altogether so we’ve tried to = encourage them to participate in this way. If we want to push these = folks away with procedural reasons, then we have made our = bed...

 

        &n= bsp; —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi,

 

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,

and YANG Mount = topics. I was going to call in for those, not = OSPF.

But I have been = saying (for over a year now) that it is time to = move

domain-specific data = models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

Andy

 

 

On Wed, = Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don’t want to do them, have the expertise to do them, = etc…  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small “design team” fashion, = right?

 

And in terms of today’s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won’t have another interim meeting until after Hawaii, so = the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community = wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 

------=_NextPart_000_06C4_01CFEE0C.56347390-- From nobody Wed Oct 22 12:28:16 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA61AD391; Wed, 22 Oct 2014 12:28:14 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 9_7kOSYc9j_U; Wed, 22 Oct 2014 12:28:11 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1C91AD372; Wed, 22 Oct 2014 12:28:10 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id i57so4073210yha.17 for ; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TVwdd0Mq5W+tn5I4qgvlbYmrlHbGlHgsg1gmGvN9dwY=; b=XlQR7KW2ixy0/3MoEYxcPIcIb6sB/CQaC+ysf5aD4rQQoFwNJbr0KV9p7aVHSL/Cj+ mnPDz54K8t1qoKGXE8M2/ervfgASe2aaN5UUVd2A4XsKeZPvW4NBUVwbIx71nFZL5OqX yTzZvdgrjjbd5qQe5V/SCe6DJGzUqFo2LM4XTGg8Rqwoy91iudXA9q7Qx2pbvXpadZo4 gzTfyW2XIEenaIAPDwPBVtB+nm99QLH9I7bz8PgUJ52UUKI0P6+AXwgNvSx7BnlQY/aB qQdCLghNn7QL6vWo1rRYkpCobKnAMFF/HyLBVZJAoQHwH0rw7VVfAGwKnymX+TWYq0G6 oW3w== MIME-Version: 1.0 X-Received: by 10.236.223.198 with SMTP id v66mr347436yhp.38.1414006089692; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) In-Reply-To: References: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> Date: Wed, 22 Oct 2014 15:28:09 -0400 Message-ID: From: Alia Atlas To: "Thomas D. Nadeau" , "sfc-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e9eeafbb7a050607f2fa Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/pyh7WYHYs9sl0MqThaWTETeYuZk Cc: rtg-yang-coord@ietf.org, "netmod@ietf.org" , Susan Hares , rapenno Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:28:14 -0000 --001a11c1e9eeafbb7a050607f2fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tom, Coordinate with the SFC chairs so that they know it is happening. Have a clear agenda sent out a week ahead of time so that SFC participants can call in. Have fun, Alia On Wed, Oct 22, 2014 at 3:23 PM, Thomas D. Nadeau wrote: > > That depends on whether or not it offends the Routing Area ADs. > > =E2=80=94Tom > > > On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares wrote: > > Tom: > > I have an I2RS related SFC yang model (state and policy) to discuss as > well. May this get added to the next interim if time allows. > > Sue > > *From:* Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org > ] *On Behalf Of *rapenno > *Sent:* Tuesday, October 21, 2014 7:32 PM > *To:* tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org > *Subject:* Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focu= s > > I would like to discuss SFC yang modelnif time permits > > > Sent from Samsung Mobile > > > > -------- Original message -------- > From: "Thomas D. Nadeau" > Date: > To: NETMOD Working Group ,rtg-yang-coord@ietf.org > Subject: [netmod] interim meeting: yang model focus > > > [adding rtg-yang-coord] > > > Tomorrow's meeting will use the same WebEx from last time (and the same a= s > was used last week at the Yang 1.1-focused meeting). > > Tomorrow's interim meeting has the following preliminary agenda: > > 0) Quickly how to use IRC/sign-in > 1) Note Well > 2) Agenda Bashing > 3) OSPF Model - Kiran Agrahara Sreenivasa ; > myeung@cisco.com > > > Are there any other models people wish to discuss? > > --Tom > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > --001a11c1e9eeafbb7a050607f2fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tom,

Coordinate with the SFC chairs so = that they know it is happening.
Have a clear agenda sent out a we= ek ahead of time so that SFC participants
can call in.
=
Have fun,
Alia

On Wed, Oct 22, 2014 at 3:23 PM, Thomas D= . Nadeau <tnadeau@lucidvision.com> wrote:

That depends on whether or not i= t offends the Routing Area ADs.

=E2=80=94Tom


On Oct 22, 2014:2:48 PM, at = 2:48 PM, Susan Hares <shares@ndzh.com> wrote:

Tom:=C2=A0
=C2=A0
I= have an I2RS related SFC yang model (state and policy) to discuss as well.= =C2=A0 May this get added to the next interim if time allows.=C2=A0
=C2=A0
Sue=C2=A0<= /span>
=C2=A0
From:=C2=A0Rtg-= yang-coord [mailto:rtg-yang-coor= d-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0rapenno
Sent:=C2=A0Tuesday, October 21, 2014 7:= 32 PM
To:=C2=A0tn= adeau@lucidvision.com;=C2=A0net= mod@ietf.org;=C2=A0rtg-= yang-coord@ietf.org
Subject:=C2=A0Re: [Rtg-yang-= coord] [netmod] interim meeting: yang model focus
=C2=A0
I would like to discuss SFC yang modelnif time permits<= u>
=C2=A0
=C2=A0
=
Sent from Samsung Mobile



-------- Original message --------
From:= "Thomas D. Nadeau" <tnadea= u@lucidvision.com>=C2=A0
Date:=C2=A0To: NETMOD Working Group <netmod@ietf.org>,rtg-yang-coord@ietf.org= =C2=A0
Subject: [netmod] interim meeting: yang model focus= =C2=A0


[adding=C2=A0 rtg-yang-coord]


Tomorrow&= #39;s meeting will use the same WebEx from last time (and the same as was u= sed last week at the Yang 1.1-focused meeting).=C2=A0

T= omorrow's interim meeting has the following preliminary agenda:

= 0) Quickly how to use IRC/sign-in
1) Note Well
2) Agenda Bashing
3= ) OSPF Model - Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>;=C2=A0myeung@cisco.com


Are there any other models people wish t= o discuss?

--Tom



____________________________________= ___________
netmod mailing list
netmod@iet= f.org
https://www.i= etf.org/mailman/listinfo/netmod

______________________________________________= _
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--001a11c1e9eeafbb7a050607f2fa-- From nobody Wed Oct 22 14:09:27 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E641A1B3B; Wed, 22 Oct 2014 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 w7XEZaACv7RT; Wed, 22 Oct 2014 14:09:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0672C1A1B38; Wed, 22 Oct 2014 14:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34199; q=dns/txt; s=iport; t=1414012141; x=1415221741; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NR5Dvy614Y3X+PcegquSss4srCSPpd4byj//NGTlNvY=; b=B26KQcPKk8VoVWs8+YPHb5L6yKZBJ93Y2k6ngIVW/ZXa9QTu2Yp7pWfx jP9KrU5/evRewk42aFf61QnPnNG3iVPlhh5gE0JW5RKSkJfkVf0P7b0vb bDuh7xioE8yzJRPg9YCaXTv3+FRnVuY1YTZsEZEIbqpDSNjd8iqu3TaJh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHkcSFStJA2K/2dsb2JhbABSCoJIRlRYzFYBCYZ5VAKBDxYBfYQCAQEBAwEBAQEqPgMLBQcECw4DBAEBAQkXAQYHDwIWHwkIBgEMAQUCAQEQC4gZCA3FbwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEilaFJVwGAQaERQWLY5F6gTGGO4o9hAGEGB0vgQYEgUEBAQE X-IronPort-AV: E=Sophos; i="5.04,771,1406592000"; d="scan'208,217"; a="89458637" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 22 Oct 2014 21:08:58 +0000 Received: from [10.154.182.28] ([10.154.182.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9ML8uAU018908; Wed, 22 Oct 2014 21:08:56 GMT Message-ID: <54481CE8.808@cisco.com> Date: Wed, 22 Oct 2014 14:08:56 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> In-Reply-To: <057901cfee26$754ecc20$5fec6460$@ndzh.com> Content-Type: multipart/alternative; boundary="------------080204070205080802080900" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/_CMoZEpYDklpFYgYFmQififvgOw Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:09:07 -0000 This is a multi-part message in MIME format. --------------080204070205080802080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, > > Tom: > > Acee indicated earlier on the i2rs list (September discussion) that > the OSPF yang model was going to be standardized in OSPF. I'm glad > we've got the rtg-yang-coord list to sort out these issues. > > IDR will pick up all BGP related yang modules. A charter addition has > been made. IDR will gladly accept input from the netmod WG or hold > joint interim session to make this effort go fast. > Exactly. The YANG modules should be standardized in the respective WGs. To have good YANG modules, you need: 1. the technology experts, i.e. the respective WG 2. YANG review I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG". We want to do what's right by providing YANG review of the documents, nothing else. I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal. Regards, Benoit > The configuration drafts for bgp > (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp > (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I > will be releasing a draft that compares these two drafts, and looks at > how these drafts fulfill the I2RS BGP use case requirements. > > IDR will sponsor a design team in IDR to push the rapid development of > bgp configuration or bgp i2rs. If you could suggest a few netmod > people to help this effort it would help. > > My understanding of IETF best practices indicate that joint interims > need 2 weeks announcement of topics. > > Sue > > *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On > Behalf Of *Thomas D. Nadeau > *Sent:* Wednesday, October 22, 2014 10:35 AM > *To:* Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian > *Subject:* Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled > > No one said that OSPF experts could not attend to provide input. The > issue is that OSPF was not doing this. If they want to take over doing > all OSPF models, then great, but to date no one was. The agreement in > NETMOD (and our charter) is to facilitate the creation of models when > WGs don't want to do them, have the expertise to do them, etc... > Also, getting the right Yang experts in one place is not going to > happen for every WG in the IETF; its just not realistic. I understand > that ultimately the WG needs to have consensus, but quick iteration to > construct the model surely can happen in a small "design team" > fashion, right? > > And in terms of today's meeting being canceled, really what purpose > was that other than to stall/slow-down work? The group that was there > to work on the OSPF model was indeed a bunch of folks from OSPF (Acee > Lindem for example was on the call). So now since we won't have > another interim meeting until after Hawaii, so the next time this > group can get together is possibly in Hawaii, but that is probably > unlikely as a large number of people are not going to Hawaii. So the > net-net is a slowing of progress in this area. Probably not the > result the IETF community wants. > > ---Tom > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 YANG > experts to > > help translate that to a data model. (Not the other way around -- > a room > > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss > open issues > > on chartered items, not as an additional forum to promote > individual drafts. > > Andy > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, > nor hard to > comply with. The rules exist to ensure that people are included in > the work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting > to discuss only > one of a pair of competing documents on the same topic, that you > didn't make the > information about the meeting available to the authors of the > competing document > or to the people who care about the protocol being modelled, and I > find it > upsetting (yes, I am actually upset) that you decided to discuss > in Netmod a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group > had a different > charter to enable it to take on models for protocols that already > have a home in > other working groups, then I suggest you need to recharter. But I > doubt that > your reasoning that [YANG] experts will not go to all the other > working groups > will carry much weight. Frankly, and without wanting to disrespect > the YANG > experts, it is easier to understand YANG than it is to understand > OSPF. If this > were not the case then the Netmod working group would have failed > in its design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working > group and > discuss it (there are already some threads). Review and comment on > the competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF > working group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com > ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org > ; ops-ads@tools.ietf.org > ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of > procedural non-sense > has > > and IS driving people away from the IETF to other places where > this work is > going > > to get done. The simple effect of such silliness will be a > reduction in speed > and > > quantity of model development. If the goal of the IESG is to > slow down the > > velocity of model development and creation, then this approach > is perfect. > > > > For the record, the interim NETMOD meeting cadence has one > meeting > > focused on Yang and the other on modeling; is not > NETMOD-specific per say, but > > to promote model creation because no other bi-weekly forum > exists to do so. It > > is also a place to bring in non-IETF work such as the work done > in ODL, other > open > > source, or just the public community that has explicitly wanted > to avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, and > actually > *build* > > models - regardless of their ultimate WG home. The simple > reason: its a > single > > place for many of the experts to gather. I think you will find > it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because > I do not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground > that: > > > 1. This interim appears to be meeting to discuss a non-WG > draft for which > there > > is no milestone in the working group and for which there is an > obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF > announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------080204070205080802080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I’m glad we’ve got the rtg-yang-coord list to sort out these issues.

 

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones".
People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you could suggest a few netmod people to help this effort it would help.  

 

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics.

 

Sue

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

            No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

            And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community wants.

 

            —Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record, the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 


--------------080204070205080802080900-- From nobody Wed Oct 22 14:13:05 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13641A1B39; Wed, 22 Oct 2014 14:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 s3a6Io6jvI05; Wed, 22 Oct 2014 14:12:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F901A01F9; Wed, 22 Oct 2014 14:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84502; q=dns/txt; s=iport; t=1414012358; x=1415221958; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7NUXipr5hnKVh6MR95fCw+KLnXzXAswDGf0KNg58OqU=; b=a6t/JYBNacgbYhtmI/muM5v2fjTGUThItQtF/KlZlKgIZTSz/7Hzu7Sf WalPEZxPW60xqqT8vU0LixJPKX1pFVbim2CVbnEMxKWgND+J0dvRDKgvp fPCgwDiSbhkNy6MypnF59mjpAn59/7XbCIhpYnAp/fdBp0yY5Z+xnIO1f c=; X-IronPort-AV: E=Sophos; i="5.04,771,1406592000"; d="scan'208,217"; a="89470135" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 22 Oct 2014 21:12:37 +0000 Received: from [10.154.182.28] ([10.154.182.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9MLCagO026533; Wed, 22 Oct 2014 21:12:36 GMT Message-ID: <54481DC4.70800@cisco.com> Date: Wed, 22 Oct 2014 14:12:36 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Eric Voit (evoit)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> In-Reply-To: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------090409060209050203010309" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/FpcXQ3leASRL7msEAViXeraysJA Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:12:54 -0000 This is a multi-part message in MIME format. --------------090409060209050203010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian, > > Eric, > > I cannot speak to why the meeting was cancelled. > > My disquiet was simply that an item on the agenda was out of scope and > not properly announced to achieve the correct participation. > > The text I sent to Benoit read... > > > In summary: if this meeting does not have material to discuss under > > > the agenda for which the meeting was called, then it must be cancelled. > > You appear to be saying that there was work to be done that was in > scope for the WG and was part of the agenda that was published. > > So I'm a bit puzzled. > You raised the "violation of IETF" process flag + the issue that we should not be discussing non NETMOD documents in NETMOD, and now, you're puzzled... Really? Regards, Benoit > Adrian > > *From:*Eric Voit (evoit) [mailto:evoit@cisco.com] > *Sent:* 22 October 2014 16:20 > *To:* Thomas D. Nadeau; Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org; Farrel Adrian > *Subject:* RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled > > As Tom and others note, today's Netmod interim was to have topics > beyond OSPF. These included OpenDaylight related work. The IETF > should be encouraging venues for Open Source developer audiences. > Cancelling full meetings via IETF procedural mechanisms signals the > opposite. > > I *like* the idea of each WG being the owner for their domain models. > This scales well for the reasons pointed out below. And I do have > sympathy for a WG wanting to close on a definitive answer for a YANG > model before implications are discussed elsewhere. But I am worried > that we are enforcing an overly serial process. Or of constraining > communication. The market will work around this. > > In the controller space, YANG technology is not static. Some degree > of parallelism is needed across IETF WGs. Clueful Open Source/YANG > developers cannot extend themselves across all WG where YANG modeling > might occur. > > Eric > > *From:*Thomas D. Nadeau, October 22, 2014 10:52 AM > > We are trying. The thing is that you cannot just hoist that onto WGs > and say "here you go." if they don't want to do it. Again, the Netmod > charter was specifically modified to accommodate that case. And > while some WGs in the routing area are not enthusiastic about building > models, others aren't, nor are other WGs at the IETF. So for those, > what do you do? Ignore them? The other point is that others outside of > the IETF are working on these models. It is squarely within the IETF > community's interest to bring these back into the fold. Many of these > folks are skittish about coming to the IETF altogether so we've tried > to encourage them to participate in this way. If we want to push these > folks away with procedural reasons, then we have made our bed... > > ---tom > > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > > wrote: > > Hi, > > I think the interim did not need to be cancelled. There are ACL, > SYSLOG, > > and YANG Mount topics. I was going to call in for those, not OSPF. > > But I have been saying (for over a year now) that it is time to move > > domain-specific data models into the domain-specific WGs. > > I think NETMOD WG should focus on the YANG language and > > infrastructure modules. > > Andy > > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > > wrote: > > No one said that OSPF experts could not attend to provide input. > The issue is that OSPF was not doing this. If they want to take > over doing all OSPF models, then great, but to date no one was. > The agreement in NETMOD (and our charter) is to facilitate the > creation of models when WGs don't want to do them, have the > expertise to do them, etc... Also, getting the right Yang experts > in one place is not going to happen for every WG in the IETF; its > just not realistic. I understand that ultimately the WG needs to > have consensus, but quick iteration to construct the model surely > can happen in a small "design team" fashion, right? > > And in terms of today's meeting being canceled, really what > purpose was that other than to stall/slow-down work? The group > that was there to work on the OSPF model was indeed a bunch of > folks from OSPF (Acee Lindem for example was on the call). So now > since we won't have another interim meeting until after Hawaii, so > the next time this group can get together is possibly in Hawaii, > but that is probably unlikely as a large number of people are not > going to Hawaii. So the net-net is a slowing of progress in this > area. Probably not the result the IETF community wants. > > ---Tom > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data > models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 > YANG experts to > > help translate that to a data model. (Not the other way around > -- a room > > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss > open issues > > on chartered items, not as an additional forum to promote > individual drafts. > > Andy > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to > discover, nor hard to > comply with. The rules exist to ensure that people are > included in the work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group > meeting to discuss only > one of a pair of competing documents on the same topic, that > you didn't make the > information about the meeting available to the authors of the > competing document > or to the people who care about the protocol being modelled, > and I find it > upsetting (yes, I am actually upset) that you decided to > discuss in Netmod a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working > group had a different > charter to enable it to take on models for protocols that > already have a home in > other working groups, then I suggest you need to recharter. > But I doubt that > your reasoning that [YANG] experts will not go to all the > other working groups > will carry much weight. Frankly, and without wanting to > disrespect the YANG > experts, it is easier to understand YANG than it is to > understand OSPF. If this > were not the case then the Netmod working group would have > failed in its design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF > working group and > discuss it (there are already some threads). Review and > comment on the competing > document. Try to get agreement between all of the authors of > both documents, or > try to identify the differences. Work with the chairs of the > OSPF working group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com > ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org > ; ops-ads@tools.ietf.org > ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of > procedural non-sense > has > > and IS driving people away from the IETF to other places > where this work is > going > > to get done. The simple effect of such silliness will be a > reduction in speed > and > > quantity of model development. If the goal of the IESG is to > slow down the > > velocity of model development and creation, then this > approach is perfect. > > > > For the record, the interim NETMOD meeting cadence has > one meeting > > focused on Yang and the other on modeling; is not > NETMOD-specific per say, but > > to promote model creation because no other bi-weekly forum > exists to do so. It > > is also a place to bring in non-IETF work such as the work > done in ODL, other > open > > source, or just the public community that has explicitly > wanted to avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, > and actually > *build* > > models - regardless of their ultimate WG home. The simple > reason: its a > single > > place for many of the experts to gather. I think you will > find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully > because I do not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the > ground that: > > > 1. This interim appears to be meeting to discuss a non-WG > draft for which > there > > is no milestone in the working group and for which there is > an obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the > IETF announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord --------------090409060209050203010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Adrian,

Eric,

 

I cannot speak to why the meeting was cancelled.

My disquiet was simply that an item on the agenda was out of scope and not properly announced to achieve the correct participation.

 

The text I sent to Benoit read...

 

> In summary: if this meeting does not have material to discuss under

> the agenda for which the meeting was called, then it must be cancelled.

 

You appear to be saying that there was work to be done that was in scope for the WG and was part of the agenda that was published.

 

So I'm a bit puzzled.

You raised the "violation of IETF" process flag + the issue that we should not be discussing non NETMOD documents in NETMOD, and now, you're puzzled... Really?

Regards, Benoit

 

Adrian

 

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: 22 October 2014 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled

 

As Tom and others note, today’s Netmod interim was to have topics beyond OSPF.  These included OpenDaylight related work.   The IETF should be encouraging venues for Open Source developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for their domain models.  This scales well for the reasons  pointed out below.  And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcing an overly serial process.  Or of constraining communication.  The market will work around this.  

 

In the controller space, YANG technology is not static.  Some degree of parallelism is needed across IETF WGs.  Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur.

 

Eric

 

 

From: Thomas D. Nadeau, October 22, 2014 10:52 AM

          We are trying. The thing is that you cannot just hoist that onto WGs and say “here you go.” if they don’t want to do it.  Again, the Netmod charter was specifically modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic about building models, others aren’t, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring these back into the fold.  Many of these folks are skittish about coming to the IETF altogether so we’ve tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

          —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi,

 

I think the interim did not need to be cancelled. There are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for those, not OSPF.

But I have been saying (for over a year now) that it is time to move

domain-specific data models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

 

No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record, the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

 

 



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--------------090409060209050203010309-- From nobody Wed Oct 22 14:33:07 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1051A6EEC; Wed, 22 Oct 2014 14:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HYNhOLYlv8za; Wed, 22 Oct 2014 14:32:52 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 579841A6EFF; Wed, 22 Oct 2014 14:32:41 -0700 (PDT) Received: from [10.254.210.149] (23-25-240-189-static.hfc.comcastbusiness.net [23.25.240.189]) by lucidvision.com (Postfix) with ESMTP id 1A9A328D17DF; Wed, 22 Oct 2014 17:32:40 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12B411) In-Reply-To: <54481CE8.808@cisco.com> Date: Wed, 22 Oct 2014 17:32:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8990373F-3F69-4560-B863-C1248FD65B03@lucidvision.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/jtIHAKZc_SmeTkuBWww7_X7ME3I Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , Andy Bierman , "rtg-ads@tools.ietf.org" , Farrel Adrian , Susan Hares Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:33:00 -0000 --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 > On Oct 22, 2014, at 5:08 PM, Benoit Claise wrote: >=20 > Dear all, >> Tom: >> =20 >> Acee indicated earlier on the i2rs list (September discussion) that the O= SPF yang model was going to be standardized in OSPF. I=E2=80=99m glad we=E2= =80=99ve got the rtg-yang-coord list to sort out these issues. >> =20 >> IDR will pick up all BGP related yang modules. A charter addition has be= en made. IDR will gladly accept input from the netmod WG or hold joint inte= rim session to make this effort go fast.=20 > Exactly. The YANG modules should be standardized in the respective WGs. > To have good YANG modules, you need: > 1. the technology experts, i.e. the respective WG > 2. YANG review >=20 > I don't understand all this fuss about: "oh, but you can't speak about an O= SPF module in a NETMOD WG". > We want to do what's right by providing YANG review of the documents, noth= ing else. >=20 > I don't understand all this fuss about: "oh, but if you speak about one OS= PF YANG model, then you must include all the other ones". > People who want feedback on their YANG modules are welcome to join. This w= as the goal. >=20 > Regards, Benoit >=20 >> The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) a= nd the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% funct= ional overlap. I will be releasing a draft that compares these two drafts, a= nd looks at how these drafts fulfill the I2RS BGP use case requirements. >> =20 >> IDR will sponsor a design team in IDR to push the rapid development of bg= p configuration or bgp i2rs. If you could suggest a few netmod people to he= lp this effort it would help. =20 >> =20 >> My understanding of IETF best practices indicate that joint interims need= 2 weeks announcement of topics.=20 >> =20 >> Sue >> =20 >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf O= f Thomas D. Nadeau >> Sent: Wednesday, October 22, 2014 10:35 AM >> To: Andy Bierman >> Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf= .org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel A= drian >> Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >> =20 >> =20 >> No one said that OSPF experts could not attend to provide inp= ut. The issue is that OSPF was not doing this. If they want to take over d= oing all OSPF models, then great, but to date no one was. The agreement in N= ETMOD (and our charter) is to facilitate the creation of models when WGs don= =E2=80=99t want to do them, have the expertise to do them, etc=E2=80=A6 Als= o, getting the right Yang experts in one place is not going to happen for ev= ery WG in the IETF; its just not realistic. I understand that ultimately th= e WG needs to have consensus, but quick iteration to construct the model sur= ely can happen in a small =E2=80=9Cdesign team=E2=80=9D fashion, right? >> =20 >> And in terms of today=E2=80=99s meeting being canceled, reall= y what purpose was that other than to stall/slow-down work? The group that w= as there to work on the OSPF model was indeed a bunch of folks from OSPF (Ac= ee Lindem for example was on the call). So now since we won=E2=80=99t have a= nother interim meeting until after Hawaii, so the next time this group can g= et together is possibly in Hawaii, but that is probably unlikely as a large n= umber of people are not going to Hawaii. So the net-net is a slowing of pro= gress in this area. Probably not the result the IETF community wants. >> =20 >> =E2=80=94Tom >> =20 >> =20 >> =20 >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman w= rote: >> =20 >> Hi Adrian, >> =20 >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG experts t= o >> help translate that to a data model. (Not the other way around -- a room >> full of YANG experts and 1 or 2 OSPF experts). >> =20 >> I also prefer that virtual interim meetings be used to discuss open issue= s >> on chartered items, not as an additional forum to promote individual draf= ts. >> =20 >> =20 >> Andy >> =20 >> =20 >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrot= e: >> I understand and appreciate your desire to get work done. >>=20 >> The rules for IETF virtual interims are neither hard to discover, nor har= d to >> comply with. The rules exist to ensure that people are included in the wo= rk, and >> I am sure that inclusion is what you want. >>=20 >> I find it unfortunate that you scheduled a working group meeting to discu= ss only >> one of a pair of competing documents on the same topic, that you didn't m= ake the >> information about the meeting available to the authors of the competing d= ocument >> or to the people who care about the protocol being modelled, and I find i= t >> upsetting (yes, I am actually upset) that y= ou decided to discuss in Netmod a >> document that belongs in the OSPF working group. >>=20 >> If, as it surely sounds, you wish that the Netmod working group had a dif= ferent >> charter to enable it to take on models for protocols that already have a h= ome in >> other working groups, then I suggest you need to recharter. But I doubt t= hat >> your reasoning that [YANG] experts will not go to all the other working g= roups >> will carry much weight. Frankly, and without wanting to disrespect the YA= NG >> experts, it is easier to understand YANG than it is to understand OSPF. I= f this >> were not the case then the Netmod working group would have failed in its d= esign >> of YANG! >>=20 >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working group a= nd >> discuss it (there are already some threads). Review and comment on the co= mpeting >> document. Try to get agreement between all of the authors of both documen= ts, or >> try to identify the differences. Work with the chairs of the OSPF working= group >> to advance the work. >>=20 >> Adrian >>=20 >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.o= rg; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural non-= sense >> has >> > and IS driving people away from the IETF to other places where this wor= k is >> going >> > to get done. The simple effect of such silliness will be a reduction in= speed >> and >> > quantity of model development. If the goal of the IESG is to slow down= the >> > velocity of model development and creation, then this approach is perfe= ct. >> > >> > For the record, the interim NETMOD meeting cadence has one meetin= g >> > focused on Yang and the other on modeling; is not NETMOD-specific per s= ay, but >> > to promote model creation because no other bi-weekly forum exists to do= so. It >> > is also a place to bring in non-IETF work such as the work done in ODL,= other >> open >> > source, or just the public community that has explicitly wanted to avoi= d the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and actual= ly >> *build* >> > models - regardless of their ultimate WG home. The simple reason: its a= >> single >> > place for many of the experts to gather. I think you will find it very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I do no= t think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft for w= hich >> there >> > is no milestone in the working group and for which there is an obvious h= ome >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF announc= e list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > > >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1



On Oct 22= , 2014, at 5:08 PM, Benoit Claise <b= claise@cisco.com> wrote:

= =20 =20 =20
Dear all,

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I=E2=80=99m glad we=E2=80=99ve got the rtg-yang-coor= d list to sort out these issues.

 

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones".
People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you could= suggest a few netmod people to help this effort it would help.  

 

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. =

 

Sue

 

From:= Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.or= g] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Be= noit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

  &n= bsp;         No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don=E2=80=99t want to d= o them, have the expertise to do them, etc=E2=80=A6  Also, gett= ing the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small =E2=80=9Cdesign team=E2=80=9D fashion, right?

 

  =           And in terms of today=E2=80=99s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won=E2=80=99t ha= ve another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress i= n this area.  Probably not the result the IETF community wants.

 

 &nbs= p;          =E2=80=94Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to=

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues=

on chartered items, not as an additional forum to promote individual drafts.<= /o:p>

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.c= o.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.
=
I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvisio= n.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org= ; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely d= isappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record,= the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG= considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > ______________________________________________= _
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > http= s://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/m= ailman/listinfo/netmod

 

 


=20
= --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829-- From nobody Wed Oct 22 14:42:06 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB841A6F28 for ; Wed, 22 Oct 2014 14:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5eMUY-LvYK1o for ; Wed, 22 Oct 2014 14:41:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AC81A6FA8 for ; Wed, 22 Oct 2014 14:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50402; q=dns/txt; s=iport; t=1414014075; x=1415223675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jwhNvwZ5UoMN9+b5gtBMuBd7rgx/d/aKJYJAHgdpqBM=; b=ma3xhnFPsV2Oxslc0ZpbHPELNAiGVwkFVxq3huFDVAbHGIA7x99+Quj8 2dYOPYElCtHmj4BjiA3ni4lCrgurf+uLAHDEHR2dcJRxmwWhu6F0MmqOi GZVnxZ/HiaSPIFEcYYr8lMlKvoZaGcFpKPhHnIhsROUlamjfV7wZ6ARdM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAJQjSFStJV2T/2dsb2JhbABSCoJIRlRYBLwejk6BZgEJh00CgQ8WAX2EAgEBAQQBAQEqPgMLDAQCAQgOAwMBAQEBIAEGByEGCxQJCAIEAQ0FFIgYAxENvyoNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjiKBWTEHEw0EBgECBIRFBZIEhEZWgW6CPoIRgTE8gw2DLYcmglyEAYFdghtsgQYEPoEDAQEB X-IronPort-AV: E=Sophos; i="5.04,771,1406592000"; d="scan'208,217"; a="89428823" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 22 Oct 2014 21:41:13 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9MLfDWd016281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 21:41:13 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.162]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:41:12 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Susan Hares , "adrian@olddog.co.uk" , "'Robert Raszuk'" Thread-Topic: [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7f74HEXTDYiO5ESbS2EDYGniWZw8eT6AgAADRYCAAEGDgP//xj2A Date: Wed, 22 Oct 2014 21:41:12 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <027d01cfee02$590ec840$0b2c58c0$@olddog.co.uk> <051601cfee23$1a248220$4e6d8660$@ndzh.com> In-Reply-To: <051601cfee23$1a248220$4e6d8660$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.154.209.83] Content-Type: multipart/alternative; boundary="_000_D06D7047362BDmyeungciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/R_PO5O3hUSuM7hf1Zk4bejPsBeM Cc: "Benoit Claise \(bclaise\)" , "'Thomas D. Nadeau'" , "ospf-chairs@tools.ietf.org" , "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:42:02 -0000 --_000_D06D7047362BDmyeungciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sue, Looking forwards to the comparison doc. That should help to make the OSPF m= odel more comprehensive. Thanks, - Derek From: Susan Hares > Date: Wednesday, October 22, 2014 11:07 AM To: "adrian@olddog.co.uk" >, 'Robert Raszuk' > Cc: "Benoit Claise (bclaise)" >= , "'Thomas D. Nadeau'" >, "ospf-chairs@tools.ietf.org" >, "Rtg-yang-coor= d@ietf.org" > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Adrian, Robert, and Thomas: These two drafts interact due to the netmod suggestion to I2RS that the con= figuration datastore and the I2rs ephemeral datastore can be part of the sa= me data store. I2rs has not agreed to combined datastore on the list or in= a meeting. The details of the interactions are being worked out. However= , to push this state I am preparing a comparison draft between: http://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ Acee encouraged me on the I2RS mailing list to keep 1 OSPF yang draft (draf= t-yeung-netmod-ospf) and suggest changes to support I2RS requirements. To = provide this comparison, I am writing a draft-hares-i2rs-ospf-yeung-adds-00= to suggest these changes based on the requirements listed in draft-hares-i= 2rs-usecase-reqs-summary-00 for IGPs. These changes should inform the thinkin= g of the draft-yeung-netmod-ospf authors, but should not hold up progress o= n this draft. Please note that even though the I2RS chairs directed the cre= ation of the draft-hares-i2rs-usecase-reqs-summary list of all potential I2= rs requirements =96 this draft has been adopted as a WG draft. Finally, to give a technical moment to an otherwise banal bashing of Adrian= =92s support for Acee=92s earlier declaration to hold this review in OSPF, = I offer the =93sound byte=94 level of comparison below (see draft-hares-i2r= s-ospf-yeung-adds-00 for full details). Sue Comparison: draft-yeung-netmod-ospf-01 (2/14/2014) - configuration, but lacked the def= initions to support real-time status of ospf-mt, ospf-rib, ospf-neighbor, o= spf-lsa-database, ospf-state, and ospf-status. draft-wang-i2rs-ospf-dm-00 (9/26/2014) - not focused on configuration, but= added definitions to support real-time status of ospf-mt, ospf-rib, ospf-n= eighbor, ospf-lsa-data, ospf-state, and ospf-status. draft-yeung-netmod-ospf-02 (10/14/2014) =96 added definitions for ospf-mt, = ospf lsa database, ospf-TE, and ospf status and state information which was= included in draft-i2rs-wang-ospf-dm-00 draft. The draft-yeung-netmod-ospf= -02 now has the form. =B7 The configuration with the muti-topology view (write/read) =B7 protocol state and ospf-lsa-database (read only) =B7 notification on events (read-only) draft-hares-i2rs-ospf-yeung-adds=97(upcoming) summarizes these differences = and suggests changes to be made to the draft-yeung-netmod-ospf-02 in order = to fulfill I2RS requirements (mostly in changes to state found in protocol,= ospf-lsa-database, and events plus an addition of ospf-rib module), and so= me additions to configuration. From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Adrian Farrel Sent: Wednesday, October 22, 2014 10:13 AM To: 'Robert Raszuk' Cc: 'Benoit Claise'; 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Robert, http://datatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/ Yes, it is in the wrong WG as well. No, I can't point to it being discussed on the OSPF list. Not sure that fac= t proves anything. Adrian From:rraszuk@gmail.com [mailto:rraszuk@gmail.com]= On Behalf Of Robert Raszuk Sent: 22 October 2014 15:02 To: Adrian Farrel Cc: Thomas D. Nadeau; Benoit Claise; Rtg-yang-coord@ietf.org; ospf-chairs@tools.ietf.org Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled Hi Adrian, What other competing OSPF yang model are you referring to? Can you provide link to discussions about that other model on OSPF WG list = taking place ? Thx, R. On Wed, Oct 22, 2014 at 3:48 PM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord --_000_D06D7047362BDmyeungciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B5CE6044EAA6F46AE86DE1C2712782A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Sue,

Looking forwards to the comparison doc. That should help to make the O= SPF model more comprehensive.

Thanks,
- Derek

From: Susan Hares <shares@ndzh.com>
Date: Wednesday, October 22, 2014 1= 1:07 AM
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Robert Raszuk' <robert@raszuk.net>
Cc: "Benoit Claise (bclaise)&q= uot; <bclaise@cisco.com>, &q= uot;'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.o= rg>, "Rtg-yang-coord= @ietf.org" <Rtg-yang= -coord@ietf.org>
Subject: Re: [Rtg-yang-coord] NETMO= D interim meeting canceled

Adrian, Robert, and Thomas:  =

 

These two drafts interact due to the netmod s= uggestion to I2RS that the configuration datastore and the I2rs ephemeral d= atastore can be part of the same data store.  I2rs has not agreed to combined datastore on the list or in a= meeting.  The details of the interactions are being worked out.  = ;However, to push this state I am preparing a comparison draft between:

 

http://datatracker.ietf= .org/doc/draft-yeung-netmod-ospf/

http://d= atatracker.ietf.org/doc/draft-wang-i2rs-ospf-dm/

 

Acee encouraged me on the I2RS mailing list t= o keep 1 OSPF yang draft (draft-yeung-netmod-ospf) and suggest changes to s= upport I2RS requirements.  To provide this comparison, I am writing a draft-hares-i2rs-ospf-yeung-adds-00 to sug= gest these changes based on the requirements listed in draft-= hares-i2rs-usecase-reqs-summary-00 for IGPs.  These changes should inform the thinking of the draft-yeun= g-netmod-ospf authors, but should not hold up progress on this draft. Pleas= e note that even though the I2RS chairs directed the creation of the draft-= hares-i2rs-usecase-reqs-summary list of all potential I2rs requirements =96 this draft has been adopted as a WG= draft. 

 

Finally, to give a technical moment to an oth= erwise banal bashing of Adrian=92s support for Acee=92s earlier declaration= to hold this review in OSPF, I offer the =93sound byte=94 level of comparison below (see draft-hares-i2rs-ospf-yeun= g-adds-00 for full details).  

 

Sue

 

Comparison:

 

draft-yeung-netmod-ospf-01 (2/14/2= 014)  - configuration, but lacked the definitions to support real-time= status of ospf-mt, ospf-rib, ospf-neighbor, ospf-lsa-database, ospf-state, and ospf-status.

 

draft-wang-i2rs-ospf-dm-00 (9/26/2= 014)  - not focused on configuration, but added definitions to support= real-time status of ospf-mt, ospf-rib, ospf-neighbor, ospf-lsa-data, ospf-state, and ospf-status.

 

draft-yeung-netmod-ospf-02 (10/14/= 2014) =96 added definitions for ospf-mt, ospf lsa database, ospf-TE, and os= pf status and state information which was included in draft-i2rs-wang-ospf-dm-00 draft.  The draft-yeung-ne= tmod-ospf-02 now has the form.  

 

=B7    =      The configuration with= the muti-topology view (write/read)

=B7    =      protocol state and osp= f-lsa-database (read only)

=B7    =      notification on events= (read-only)

 

draft-hares-i2rs-ospf-yeung-adds= =97(upcoming) summarizes these differences and suggests changes to be made = to the draft-yeung-netmod-ospf-02 in order to fulfill I2RS requirements (mostly in changes to state found in protocol= , ospf-lsa-database, and events plus an addition of ospf-rib module), and s= ome additions to configuration.

 

 

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, October 22, 2014 10:13 AM
To: 'Robert Raszuk'
Cc: 'Benoit Claise'; 'Thomas D. Nadeau'; ospf-chairs@tools.ietf.org; = Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled

 

Hi Robert,

 

http://datatracker.ietf.o= rg/doc/draft-wang-i2rs-ospf-dm/

 

Yes, it is in the w= rong WG as well.

 

No, I can't point t= o it being discussed on the OSPF list. Not sure that fact proves anything.<= o:p>

 

Adrian

 

 

Hi Adrian,

 

What other competing OSPF yang model are you referring to? 

 

Can you provide link to discussions about that other model on OSPF = WG list taking place ? 

 

Thx,

R.

 

 

On Wed, Oct 22, 2014 at 3:48 PM= , Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate you= r desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 --_000_D06D7047362BDmyeungciscocom_-- From nobody Wed Oct 22 16:28:00 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AB1A8787 for ; Wed, 22 Oct 2014 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 BoWwIsm3Qkgv for ; Wed, 22 Oct 2014 16:27:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC181A8781 for ; Wed, 22 Oct 2014 16:27:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 287E3C20E; Wed, 22 Oct 2014 19:27:58 -0400 (EDT) Date: Wed, 22 Oct 2014 19:27:58 -0400 From: Jeffrey Haas To: rtg-yang-coord@ietf.org Message-ID: <20141022232758.GB18782@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/pKkB1AvpxataAs8Y5G1PZ-R2Wog Subject: [Rtg-yang-coord] Coordination Wiki X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:27:59 -0000 I've hijacked a bit of the rtg area wiki to give this list a home. http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord If you are involved in any sort of protocol modeling work, you are encourage to edit this. :-) I've seeded some possible example layout using BFD and to a lesser extent I2RS. -- Jeff From nobody Wed Oct 22 16:49:50 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC921A8820; Wed, 22 Oct 2014 16:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Rs3emynBjpJl; Wed, 22 Oct 2014 16:49:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 894CC1A87E8; Wed, 22 Oct 2014 16:49:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 28B5FC20E; Wed, 22 Oct 2014 19:49:46 -0400 (EDT) Date: Wed, 22 Oct 2014 19:49:45 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20141022234945.GF18782@pfrc> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/KTmSm5sYp27--xcMAAHUW1obWag Cc: rtg-yang-coord@ietf.org, "Thomas D. Nadeau" , "Nobo Akiya \(nobo\)" , "rtg-bfd@ietf.org" Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:49:47 -0000 Robert, On Fri, Oct 17, 2014 at 10:09:21AM +0200, Robert Raszuk wrote: > Hi Tom, > > I assume this work will be under the general OAM YANG model correct ? > > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 I'm interested to see opinions on this topic as well. One interesting input is that a strong motivator for people asking for BFD rather than CFM-like mechanisms is the complete lack of the IEEE management domain model. Many operators seem to strongly dislike it. Seeing how BFD would fit into this draft given the above will be interesting. -- Jeff From nobody Thu Oct 23 00:44:17 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E877D1A8907; Thu, 23 Oct 2014 00:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 xSpzfIODn1-a; Thu, 23 Oct 2014 00:44:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D031A88FE; Thu, 23 Oct 2014 00:44:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0764C3243D1; Thu, 23 Oct 2014 09:44:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ACDE3238048; Thu, 23 Oct 2014 09:44:07 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.230]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 09:44:03 +0200 From: To: Susan Hares , 'Benoit Claise' Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7ikeXWdPBW/eoUydZkWpY8T+I5w9TSww Date: Thu, 23 Oct 2014 07:44:03 +0000 Message-ID: <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> In-Reply-To: <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.8.100919 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/51gl-ecN1VVVWQYEtHfkSdYQBZY Cc: "Rtg-yang-coord@ietf.org" , "ops-ads@tools.ietf.org" , 'NETMOD Working Group' , "rtg-ads@tools.ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 07:44:13 -0000 Susan, I completely agree that bits and bytes in the model should be discussed in = the protocol WG but for modeling, limitations, and all stuffs related to Ya= ng, it's still good to discuss it in Netmod. Best Regards, Stephane -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, October 22, 2014 20:51 To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working Group'= ; rtg-ads@tools.ietf.org Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Stephane:=20 I think it is important to receive both the wisdom from the netmod WG and t= he protocol WG. I find that there are yang model consistencies and limitat= ions that require aid in the yang models I've worked on. This is especiall= y true for the state and ephemeral state.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Wednesday, October 22, 2014 9:45 AM To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Hi, I also agree that this is a bad idea. I thought that IETF willing and espec= ially yours, Benoit, was to speed up availability of standard models. The process of having small teams working with weekly calls works almost go= od but we still have some issue that are both technical (dedicated to the t= opic addressed by the model) and also YANG writing, model consistencies ... that requires discussion, and as often mailing list is not as good as meeti= ngs (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim = meetings in Netmod to discuss proposed Yang models : this will ensure consi= stency between models and will help to solve global issues in modeling. It's just the starting of Yang modeling, leaving only Yang models within ho= me WG (ISIS for my point of view) would be, IMO, a very bad idea and will f= or sure slow down the availability of standards ... and I also think that i= t may discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has= and IS driving people away from the IETF to other places where this work i= s going to get done. The simple effect of such silliness will be a reductio= n in speed and quantity of model development. If the goal of the IESG is t= o slow down the velocity of model development and creation, then this appro= ach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused= on Yang and the other on modeling; is not NETMOD-specific per say, but to = promote model creation because no other bi-weekly forum exists to do so. It= is also a place to bring in non-IETF work such as the work done in ODL, ot= her open source, or just the public community that has explicitly wanted to= avoid the IETF. We have found it a convenient and fruitful place to discu= ss, and actually *build* models - regardless of their ultimate WG home. Th= e simple reason: its a single place for many of the experts to gather. I th= ink you will find it very difficult to get those people onto a per-WG call = every other week.=20=20 I hope the IESG considers this approach carefully because I do not think i= t will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for=20 > which there is no milestone in the working group and for which there is an obviou= s home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce=20 > list as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 23 01:32:38 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D6F1A1A3D; Thu, 23 Oct 2014 01:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KYg7WfeJny7w; Thu, 23 Oct 2014 01:32:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACACF1A6F4C; Thu, 23 Oct 2014 01:32:33 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 7B83313F8BA; Thu, 23 Oct 2014 10:32:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414053150; bh=UdxxlTJ6/QOUevUTne/40FsYteZSqu1L7knCI6oMJy4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SyZliQXTr6SxzjG8nouFuytnaIertivp/ImUGQaHmuhSdLNX3dlZxhNPX27cSBULh 5/Lt45bu8iFAaaJ8C/sZ6NYedU6e/gXlqPU1Bttlb4AuxdXEA83EL8X2to0oTydl12 SbNcu4+vzFN7i0998WESUkWOLYXQAeP7OzQL5N+s= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 23 Oct 2014 10:32:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/fVcE4rbokmFVXC9fZ3pO4b7G_BM Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Benoit Claise , Susan Hares Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:32:36 -0000 On 23 Oct 2014, at 09:44, = wrote: > Susan, >=20 > I completely agree that bits and bytes in the model should be = discussed in the protocol WG but for modeling, limitations, and all = stuffs related to Yang, it's still good to discuss it in Netmod. >=20 Actually, there is also the group of =93YANG Doctors=94, and it might be = more appropriate to discuss the YANG parts with them and not in the = NETMOD group. At any rate, I think we should clarify (and document) the = workflow for the development of YANG modules whose primary home is = outside the NETMOD working group. This email thread proves it is needed. Lada > Best Regards, >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com]=20 > Sent: Wednesday, October 22, 2014 20:51 > To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working = Group'; rtg-ads@tools.ietf.org > Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Stephane:=20 >=20 > I think it is important to receive both the wisdom from the netmod WG = and the protocol WG. I find that there are yang model consistencies and = limitations that require aid in the yang models I've worked on. This is = especially true for the state and ephemeral state.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of stephane.litkowski@orange.com > Sent: Wednesday, October 22, 2014 9:45 AM > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working = Group; rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Hi, >=20 > I also agree that this is a bad idea. I thought that IETF willing and = especially yours, Benoit, was to speed up availability of standard = models. > The process of having small teams working with weekly calls works = almost good but we still have some issue that are both technical = (dedicated to the topic addressed by the model) and also YANG writing, = model consistencies ... > that requires discussion, and as often mailing list is not as good as = meetings (that's why the proposal of small teams was done). >=20 > At the present time, I personally support the initiative of having = interim meetings in Netmod to discuss proposed Yang models : this will = ensure consistency between models and will help to solve global issues = in modeling. > It's just the starting of Yang modeling, leaving only Yang models = within home WG (ISIS for my point of view) would be, IMO, a very bad = idea and will for sure slow down the availability of standards ... and I = also think that it may discourage people to work on because of the added = overhead. >=20 > It was just my opinion ... >=20 > Best Regards, >=20 > Stephane >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. = Nadeau > Sent: Wednesday, October 22, 2014 15:29 > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working = Group; rtg-ads@tools.ietf.org > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled >=20 >=20 > This is hugely disappointing. This is the kind of procedural = non-sense has and IS driving people away from the IETF to other places = where this work is going to get done. The simple effect of such = silliness will be a reduction in speed and quantity of model = development. If the goal of the IESG is to slow down the velocity of = model development and creation, then this approach is perfect. >=20 > For the record, the interim NETMOD meeting cadence has one = meeting focused on Yang and the other on modeling; is not = NETMOD-specific per say, but to promote model creation because no other = bi-weekly forum exists to do so. It is also a place to bring in non-IETF = work such as the work done in ODL, other open source, or just the public = community that has explicitly wanted to avoid the IETF. We have found = it a convenient and fruitful place to discuss, and actually *build* = models - regardless of their ultimate WG home. The simple reason: its a = single place for many of the experts to gather. I think you will find it = very difficult to get those people onto a per-WG call every other week. =20= >=20 > I hope the IESG considers this approach carefully because I do = not think it will have the affect the larger IETF community is = interested in. >=20 > --Tom >=20 >=20 >=20 >> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > wrote: >>=20 >> Dear all, >>=20 >> Today NETMOD interim meeting is canceled. >>=20 >> I received some pushbacks from the routing ADs, on the ground that: >> 1. This interim appears to be meeting to discuss a non-WG draft for=20= >> which > there is no milestone in the working group and for which there is an = obvious home outside the working group. >> 2. The agenda was not announced a week in advance on the IETF = announce=20 >> list as is required >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > = __________________________________________________________________________= __ > _____________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 23 02:20:19 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DF1A8968; Thu, 23 Oct 2014 02:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 qtZLSHrRcf3t; Thu, 23 Oct 2014 02:20:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D71A8969; Thu, 23 Oct 2014 02:20:11 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6B1B51B82B2; Thu, 23 Oct 2014 11:20:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 38AFC1580A1; Thu, 23 Oct 2014 11:20:09 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.230]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 11:20:08 +0200 From: To: Ladislav Lhotka Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7pvkyJwDL5Pz9kCYeFdlN0MGIJw9Z0eg Date: Thu, 23 Oct 2014 09:20:08 +0000 Message-ID: <21811_1414056009_5448C849_21811_1363_1_9E32478DFA9976438E7A22F69B08FF921465E4@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> In-Reply-To: <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/aUfKVxXBC7e2PPFdffifMpF-nHc Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Benoit Claise , Susan Hares Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:20:15 -0000 > At any rate, I think we should clarify (and document) the workflow for th= e development of YANG modules Right, currently, as modeling is just starting, there is a lack of guidelin= es that's why more babysitting is needed at this time. But it's hard to def= ine guidelines now, without gathering experiences from Yang writing people. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Thursday, October 23, 2014 10:33 To: LITKOWSKI Stephane SCE/IBNF Cc: Susan Hares; Benoit Claise; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf= .org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled On 23 Oct 2014, at 09:44, wrote: > Susan, >=20 > I completely agree that bits and bytes in the model should be discussed i= n the protocol WG but for modeling, limitations, and all stuffs related to = Yang, it's still good to discuss it in Netmod. >=20 Actually, there is also the group of "YANG Doctors", and it might be more a= ppropriate to discuss the YANG parts with them and not in the NETMOD group.= At any rate, I think we should clarify (and document) the workflow for the= development of YANG modules whose primary home is outside the NETMOD worki= ng group. This email thread proves it is needed. Lada > Best Regards, >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, October 22, 2014 20:51 > To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working=20 > Group'; rtg-ads@tools.ietf.org > Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Stephane:=20 >=20 > I think it is important to receive both the wisdom from the netmod WG and= the protocol WG. I find that there are yang model consistencies and limit= ations that require aid in the yang models I've worked on. This is especia= lly true for the state and ephemeral state.=20 >=20 > Sue >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > Behalf Of stephane.litkowski@orange.com > Sent: Wednesday, October 22, 2014 9:45 AM > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working=20 > Group; rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Hi, >=20 > I also agree that this is a bad idea. I thought that IETF willing and esp= ecially yours, Benoit, was to speed up availability of standard models. > The process of having small teams working with weekly calls works almost = good but we still have some issue that are both technical (dedicated to the= topic addressed by the model) and also YANG writing, model consistencies .= .. > that requires discussion, and as often mailing list is not as good as mee= tings (that's why the proposal of small teams was done). >=20 > At the present time, I personally support the initiative of having interi= m meetings in Netmod to discuss proposed Yang models : this will ensure con= sistency between models and will help to solve global issues in modeling. > It's just the starting of Yang modeling, leaving only Yang models within = home WG (ISIS for my point of view) would be, IMO, a very bad idea and will= for sure slow down the availability of standards ... and I also think that= it may discourage people to work on because of the added overhead. >=20 > It was just my opinion ... >=20 > Best Regards, >=20 > Stephane >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.=20 > Nadeau > Sent: Wednesday, October 22, 2014 15:29 > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working=20 > Group; rtg-ads@tools.ietf.org > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled >=20 >=20 > This is hugely disappointing. This is the kind of procedural non-sense h= as and IS driving people away from the IETF to other places where this work= is going to get done. The simple effect of such silliness will be a reduct= ion in speed and quantity of model development. If the goal of the IESG is= to slow down the velocity of model development and creation, then this app= roach is perfect. >=20 > For the record, the interim NETMOD meeting cadence has one meeting focus= ed on Yang and the other on modeling; is not NETMOD-specific per say, but t= o promote model creation because no other bi-weekly forum exists to do so. = It is also a place to bring in non-IETF work such as the work done in ODL, = other open source, or just the public community that has explicitly wanted = to avoid the IETF. We have found it a convenient and fruitful place to dis= cuss, and actually *build* models - regardless of their ultimate WG home. = The simple reason: its a single place for many of the experts to gather. I = think you will find it very difficult to get those people onto a per-WG cal= l every other week.=20=20 >=20 > I hope the IESG considers this approach carefully because I do not think= it will have the affect the larger IETF community is interested in. >=20 > --Tom >=20 >=20 >=20 >> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise=20 >> > wrote: >>=20 >> Dear all, >>=20 >> Today NETMOD interim meeting is canceled. >>=20 >> I received some pushbacks from the routing ADs, on the ground that: >> 1. This interim appears to be meeting to discuss a non-WG draft for=20 >> which > there is no milestone in the working group and for which there is an obvi= ous home outside the working group. >> 2. The agenda was not announced a week in advance on the IETF=20 >> announce list as is required >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > ______________________________________________________________________ > ______ _____________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 23 08:22:35 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057B11AC420 for ; Thu, 23 Oct 2014 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 e4iA0fwNu_QT for ; Thu, 23 Oct 2014 08:22:25 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832341AC40A for ; Thu, 23 Oct 2014 08:21:48 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so932433qcy.29 for ; Thu, 23 Oct 2014 08:21:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=82eCh+Hl9buOysJTV32YxrH1/fXYkaB7/bgqucSZSzg=; b=D32uB/7QiJKmM6FkiOqF0sviLv0AhKvIjU/7iCFgRYcQ8PcMg9G+136qEgbvlKYGmo cjCwG2vIAtoTFTDVzniHwxnrcf8A0A6lR+PHN9PD0xpgR/aCWc3zz11yq0S8tOlqrbEW 1R4SFFzWH4TW/+p6LgksjM+WcpdIkMCx2Sqz57876/a7Z1QweovM/nm1eFrmxRM0MW/R 1k0LgfqAL2E4uUmQ4ODz9DhjFGZOIBf24ZMDRMK7eNtSKOOEIr78DNWwbhWGLvZhKY0d o4oX/2m3glwqvPJyTNGkP5i1aEecX0gKk/1sbkSMlXA3bLKf2980XxoCFqF+/N5wn9sM 5D+Q== X-Gm-Message-State: ALoCoQkOfrDxlHFyo9SuPpVtX5lGX001+slAdHc1qUGtghqlN0w0cWOTnMWUVbAZucr9Nogx/+M2 MIME-Version: 1.0 X-Received: by 10.140.34.102 with SMTP id k93mr7880765qgk.21.1414077707608; Thu, 23 Oct 2014 08:21:47 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 08:21:47 -0700 (PDT) In-Reply-To: <54481CE8.808@cisco.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> Date: Thu, 23 Oct 2014 08:21:47 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c0d2d4729cd50506189f1f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/MfSTcI5cFkrSEXhqfgOfdMZ_FfM Cc: Rtg-yang-coord@ietf.org, "Thomas D. Nadeau" , NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian , Susan Hares Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 15:22:30 -0000 --001a11c0d2d4729cd50506189f1f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 22, 2014 at 2:08 PM, Benoit Claise wrote: > Dear all, > > Tom: > > > > Acee indicated earlier on the i2rs list (September discussion) that the > OSPF yang model was going to be standardized in OSPF. I'm glad we've got > the rtg-yang-coord list to sort out these issues. > > > > IDR will pick up all BGP related yang modules. A charter addition has > been made. IDR will gladly accept input from the netmod WG or hold joint > interim session to make this effort go fast. > > Exactly. The YANG modules should be standardized in the respective WGs. > To have good YANG modules, you need: > 1. the technology experts, i.e. the respective WG > 2. YANG review > > I don't understand all this fuss about: "oh, but you can't speak about an > OSPF module in a NETMOD WG". > We want to do what's right by providing YANG review of the documents, > nothing else. > There is a difference between discussing a YANG module wrt/ its usage of YANG language constructs, and discussing a module wrt/ the proper set of knobs for a particular protocol (or feature). My objections are to the latter discussion. We saw with the ietf-routing module that wide review from routing experts happened rather late in the process. IMO if that module was done in a routing WG instead of netmod, the process would have been faster. > I don't understand all this fuss about: "oh, but if you speak about one > OSPF YANG model, then you must include all the other ones". > People who want feedback on their YANG modules are welcome to join. This > was the goal. > > Regards, Benoit > > Andy > The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) > and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% > functional overlap. I will be releasing a draft that compares these two > drafts, and looks at how these drafts fulfill the I2RS BGP use case > requirements. > > > > IDR will sponsor a design team in IDR to push the rapid development of bgp > configuration or bgp i2rs. If you could suggest a few netmod people to > help this effort it would help. > > > > My understanding of IETF best practices indicate that joint interims need > 2 weeks announcement of topics. > > > > Sue > > > > *From:* Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org > ] *On Behalf Of *Thomas D. Nadeau > *Sent:* Wednesday, October 22, 2014 10:35 AM > *To:* Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; > Benoit Claise; Farrel Adrian > *Subject:* Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled > > > > > > No one said that OSPF experts could not attend to provide > input. The issue is that OSPF was not doing this. If they want to take > over doing all OSPF models, then great, but to date no one was. The > agreement in NETMOD (and our charter) is to facilitate the creation of > models when WGs don't want to do them, have the expertise to do them, etc... > Also, getting the right Yang experts in one place is not going to happen > for every WG in the IETF; its just not realistic. I understand that > ultimately the WG needs to have consensus, but quick iteration to construct > the model surely can happen in a small "design team" fashion, right? > > > > And in terms of today's meeting being canceled, really what > purpose was that other than to stall/slow-down work? The group that was > there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee > Lindem for example was on the call). So now since we won't have another > interim meeting until after Hawaii, so the next time this group can get > together is possibly in Hawaii, but that is probably unlikely as a large > number of people are not going to Hawaii. So the net-net is a slowing of > progress in this area. Probably not the result the IETF community wants. > > > > --Tom > > > > > > > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: > > > > Hi Adrian, > > > > I agree with you. The OSPF WG should be discussing OSPF data models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 YANG experts to > > help translate that to a data model. (Not the other way around -- a room > > full of YANG experts and 1 or 2 OSPF experts). > > > > I also prefer that virtual interim meetings be used to discuss open issues > > on chartered items, not as an additional forum to promote individual > drafts. > > > > > > Andy > > > > > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > --001a11c0d2d4729cd50506189f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 22, 2014 at 2:08 PM, Benoit Claise <bclaise@cisco.com&= gt; wrote:
=20 =20 =20
Dear all,
=20 =20 =20

Tom:

 <= /u>

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I’m glad we’ve got the rtg-yang-coord l= ist to sort out these issues.

 <= /u>

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't= speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

Ther= e is a difference between discussing a YANG module wrt/ its usage of YANG
language constructs, and discussing a module wrt/ the proper set o= f knobs for
a particular protocol (or feature).

My objections are to the latter discussion.
We saw with t= he ietf-routing module that wide review
from routing experts happ= ened rather late in the process.
IMO if that module was done in a= routing WG instead of netmod,
the process would have been faster= .


I don't understand all this fuss about: "oh, but if you speak = about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit


Andy
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 <= /u>

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you coul= d suggest a few netmod people to help this effort it would help.  

 <= /u>

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics.

 <= /u>

Sue

 <= /u>

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

      &n= bsp;     No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, gett= ing the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

      =       And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t hav= e another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress = in this area.  Probably not the result the IETF community wants.

 

     &nbs= p;      —Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to<= /u>

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues<= /u>

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.
I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the<= br> information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.c= om]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely= disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record= , the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IES= G considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _____________________________________________= __
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailma= n/listinfo/rtg-yang-coord
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod<= /a>

 

 



--001a11c0d2d4729cd50506189f1f-- From nobody Thu Oct 23 11:45:51 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6C1A90E0; Thu, 23 Oct 2014 11:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 UfXOcBDHAbxG; Thu, 23 Oct 2014 11:45:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A621A8ACC; Thu, 23 Oct 2014 11:45:45 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-c1-5448f2bbd328 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.FB.25146.BB2F8445; Thu, 23 Oct 2014 14:21:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 14:45:43 -0400 From: Gregory Mirsky To: Jeffrey Haas , Robert Raszuk Thread-Topic: [Rtg-yang-coord] Design Team for defining BFD Yang Models Thread-Index: Ac/pkmoEX9Bwvz5jQiuPa/jIMBaxbQAI49oAABNNX4ABHEzZgAAfD1Vg Date: Thu, 23 Oct 2014 18:45:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B865166@eusaamb103.ericsson.se> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> <20141022234945.GF18782@pfrc> In-Reply-To: <20141022234945.GF18782@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQXf3J48Qg293BC32H3zLajG7I96i aWETs8XnP9sYLX4/v81s8XDyJXYHNo8pvzeyeixZ8pPJY+uTJewel3u3snrs3riAKYA1issm JTUnsyy1SN8ugSvjzL8mtoIzXBXr9vaxNzA+5+hi5OSQEDCR6Om5xQphi0lcuLeerYuRi0NI 4CijxMcF7ewQznJGiQWfJ7KAVLEJGEm82NjDDmKLCLhI/Nq+CyzOLLCNUeLo8zwQW1jATWLO mmlANRxANe4SP5tkIMrdJC5v3M8IYrMIqEqcbd0LNoZXwFfiRNNpZohdbxglFs95ywSS4BTQ krj1ZjobiM0IdN33U2uYIHaJS9x6Mp8J4moBiSV7zjND2KISLx//g/pGUWJf/3R2iHodiQW7 P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIy1 YxJsjjsYF3yyPMQowMGoxMP7QMMjRIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjKxtEX/jdfKL4nq4q/LSLNetrlt7YGokc45h8tw9SvuX13Bs2qxg9vj/ 4uNbtC3OXDibaaLJ73rh7c6OgE+Pdx/gMjXgiFus+O7tmY6y9qwDzTymPw5fLFEXTUi79mCe F8exDtv987OUudWaGxoWGF04e/bf+yd51jMdX1ytvs3C/dn4aH0GlxJLcUaioRZzUXEiADdc QwqWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/WPuubRPLUbJ6av5o5eqE-tEDc-4 Cc: "rtg-yang-coord@ietf.org" , "Thomas D. Nadeau" , "Nobo Akiya \(nobo\)" , "rtg-bfd@ietf.org" Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:45:47 -0000 Hi Robert, et. al, I've commented on the draft you've referenced http://www.ietf.org/mail-arch= ive/web/netmod/current/msg10528.html. The document been just updated and I'm looking forward to continue discussi= on with authors. Regards, Greg -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Jeffrey Haas Sent: Wednesday, October 22, 2014 4:50 PM To: Robert Raszuk Cc: rtg-yang-coord@ietf.org; Thomas D. Nadeau; Nobo Akiya (nobo); rtg-bfd@i= etf.org Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models Robert, On Fri, Oct 17, 2014 at 10:09:21AM +0200, Robert Raszuk wrote: > Hi Tom, >=20 > I assume this work will be under the general OAM YANG model correct ? >=20 > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 I'm interested to see opinions on this topic as well. One interesting input is that a strong motivator for people asking for BFD = rather than CFM-like mechanisms is the complete lack of the IEEE management= domain model. Many operators seem to strongly dislike it. Seeing how BFD would fit into this draft given the above will be interestin= g. -- Jeff _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Thu Oct 23 15:05:25 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7471A1A1C05 for ; Thu, 23 Oct 2014 15:05:23 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 GGqdz6Nt1L9K for ; Thu, 23 Oct 2014 15:05:17 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D821A1C03 for ; Thu, 23 Oct 2014 15:05:17 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id b13so1442637qcw.37 for ; Thu, 23 Oct 2014 15:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fh17FF88Z6FT4Jp7lsXXF86mhsm4LYPfqw1TayrfnLw=; b=N0S1z79beQXrT9nQuMUW2vsf5fM0XQcrROd3h7+O3J6P/49xMZzzJV0QFQHt/8oT1V 74IaNtrps1qvqB/jK/uAii7R5sV0N0ypyku+tdgZYZ2OG1Al6ntJnP5PrmD0Alx5QVqE 4cGchFssfDejPJQZ8oCNd1O0U/JAn9ja4zxCiIjWA6dHl+NUeureVIQ/jLxLuQbepg+M 7ztgvTtLtGDc4i1fb6Yx79eo9PKFYLOtQ+hkj1zotGKifRatD3YqDOi7uMVIRxMMCqD5 GZNwcBZuvIQ9g1793jlc4lrR0nxJLQDQb9qB2LmXAupwrjK4Pe/J6/ba/K3qal5J5weo EF6Q== MIME-Version: 1.0 X-Received: by 10.170.202.196 with SMTP id t187mr386463yke.36.1414101916493; Thu, 23 Oct 2014 15:05:16 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Thu, 23 Oct 2014 15:05:16 -0700 (PDT) Date: Thu, 23 Oct 2014 18:05:16 -0400 Message-ID: From: Alia Atlas To: Rtg-yang-coord@ietf.org Content-Type: multipart/alternative; boundary=001a1139d06a68afbe05061e42f2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/nZKGWNijNdwPvmO8CRCPnkErMvQ Cc: Benoit Claise Subject: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:05:23 -0000 --001a1139d06a68afbe05061e42f2 Content-Type: text/plain; charset=UTF-8 First, I am absolutely delighted to discover that this coordination list has 139 subscribers! I am quite encouraged that we will be able to use this mailing list for meaningful discussion and coordination. Welcome and please start talking! Towards that purpose... With a few WG drafts and over 20 individual drafts that may overlap and should share some common abstractions and groupings, we really need to start coordinating. This is a significant explosion of drafts and interest in the last 9 months - and we are interacting, at least in part, with a community that NEEDS standardization to happen much more quickly. Adrian, Benoit, and I are planning on writing up a job description for a secretary to help with this mailing list and the coordination and communication necessary. Needless to say, if you would already like to volunteer, please email me with details. To aid in finding the various YANG models that relate to routing in some way, I've included a list below. This list was generated by looking through a search of drafts based on the keyword YANG plus a couple I2RS drafts I was already familiar with. I apologize if I missed any (and encourage consistent naming ). draft-ietf-netmod-routing-cfg-15 draft-ietf-isis-yang-isis-cfg-00 draft-ietf-i2rs-rib-info-model-03 (YANG model coming very soon) draft-bogdanovic-netmod-acl-model-02 (more general than routing, so currently progressing in NETMOD) draft-chen-mpls-ldp-yang-cfg-00 draft-chen-mpls-te-yang-cfg-00 draft-clemm-i2rs-yang-network-topo-01 draft-contreras-supa-yang-network-topo-00 (targeted at an unapproved BoF, overlap with I2RS) draft-dong-i2rs-l2-network-topology-00 draft-gandhi-mpls-te-yang-model-00 draft-hao-trill-yang-01 (may be interesting to consider from the ISIS overlap) draft-hares-i2rs-bgp-dm-00 draft-liu-netmod-yang-abstract-topo-00 (another topology model) draft-liu-pim-igmp-mld-yang-00 draft-liu-pim-yang-00 draft-penno-sfc-yang-08 draft-pkd-pce-pcep-yang-00 draft-tissa-nvo3-yang-oam-00 draft-wang-i2rs-isis-dm-00 draft-wang-i2rs-ospf-dm-00 draft-yang-trill-parent-seletion-03 draft-yeung-netmod-ospf-02 draft-zhang-mpls-tp-yang-oam-00 draft-zhang-nvo3-yang-cfg-00 draft-zhdankin-netmod-bgp-cfg-01 draft-zhuang-l2vpn-evpn-yang-cfg-00 draft-zhuang-l2vpn-yang-cfg-00 draft-zhuang-l3vpn-yang-cfg-00 I hope that reading some of the above (at least draft-ietf-netmod-routing-cfg-15 ) will start to inspire ideas and concrete discussion about what coordination between models and drafts is needed. Thanks, Alia --001a1139d06a68afbe05061e42f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, I am absolutely delighted to discover that this coo= rdination list has 139 subscribers!=C2=A0 I am quite encouraged that we wil= l be able to use this mailing list for meaningful discussion and coordinati= on.=C2=A0 Welcome and please start talking!

Towards = that purpose...

With a few WG drafts and = over 20 individual drafts that may overlap and should share some common abs= tractions and groupings, we really need to start coordinating. =C2=A0 This = is a significant explosion of drafts and interest in the last 9 months - an= d we are interacting, at least in part, with a community that NEEDS standar= dization to happen much more quickly.

Adrian= , Benoit, and I are planning on writing up a job description for a secretar= y to help with this mailing list and the coordination and communication nec= essary.=C2=A0 Needless to say, if you would already like to volunteer, plea= se email me with details.

To aid in finding t= he various YANG models that relate to routing in some way, I've include= d a list below.=C2=A0 This list was generated by looking through a search o= f drafts based on the keyword YANG plus a couple I2RS drafts I was already = familiar with.=C2=A0 I apologize if I missed any (and encourage consistent = naming ).

draft-ietf-i2rs-rib-info-model-03=C2=A0(YANG model= coming very soon)

draft-contreras-supa-yang-network-topo-00=C2=A0(ta= rgeted at an unapproved BoF, overlap with I2RS)
draft-gan= dhi-mpls-te-yang-model-00
draft-hao-tri= ll-yang-01=C2=A0(may be interesting to consider from the ISIS overlap)<= br>
=
draft-liu-netmod-yang-abstract-topo-0= 0=C2=A0(another topology model)
draft-liu-pim-igmp-mld-yang-00
<= a href=3D"https://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/" styl= e=3D"font-family:arial,helvetica,clean,sans-serif;font-size:13px;line-heigh= t:16.0029983520508px">draft-tissa-nvo3-yang-oam-00

<= /div>
I hope that reading some of the above (at least=C2=A0draft-ietf-netmod-routing-= cfg-15) will start to inspire ideas and concrete discussion about what = coordination between models and drafts is needed.

= Thanks,
Alia


--001a1139d06a68afbe05061e42f2-- From nobody Thu Oct 23 15:08:19 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09E1A1BB3 for ; Thu, 23 Oct 2014 15:08:17 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 wI0i_CXzvFSr for ; Thu, 23 Oct 2014 15:08:15 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A31D1A1B78 for ; Thu, 23 Oct 2014 15:08:14 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id k14so2120397wgh.7 for ; Thu, 23 Oct 2014 15:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bd09j6EJni3+tWmnZo2lY8Qumje6SETwuz3qUaO/RhU=; b=hbUWEowvEy5i6wjj/ljRIlVmuxCi0Nj4q3DQxUbB87y42VB0NxoOpDLQOeyu3fGdKB HLL1P+Uywe3g1lKrPmnIRQOG2LQFB2RxbSYid0jC67NAZJKd0qKJbC4+/PZaAkLyXxQe fp7rjE74S5j2BjZhskpzAf8TAAybCw8QRqlSqELLEEzhWe8Tua4crDOvsEVBhHuAlg+H U2xk0vUb/hiw6DucD+Jp/K5f44j7gK8P/59olrEu6Fp5bGMkgj+WURBgfkWWOoXE+cNg SuKmI0cq6apfsupOC78VtkIVrtWC4VyloiMDdG1eVsT8JDdRHWLmbHhATs/ntokIiroA 5XWQ== MIME-Version: 1.0 X-Received: by 10.180.100.136 with SMTP id ey8mr313962wib.83.1414102093302; Thu, 23 Oct 2014 15:08:13 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Thu, 23 Oct 2014 15:08:13 -0700 (PDT) Date: Thu, 23 Oct 2014 18:08:13 -0400 Message-ID: From: Alia Atlas To: Rtg-yang-coord@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ec99f2933e05061e4c5b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/2lZv7hAuXRd83gJ4ksD2Xc5w82A Subject: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:08:17 -0000 --f46d0444ec99f2933e05061e4c5b Content-Type: text/plain; charset=UTF-8 To make rapid progress on routing models, it is really important to have a solid base routing model. Before the Routing Area started working on YANG models, NETMOD adopted and has been working on draft-ietf-netmod-routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ). I would very strongly encourage you to read (or reread) and comment on this draft BEFORE the upcoming IETF. Please send your thoughts and concerns to both this mailing list and netmod. This is intended to be the basis for our routing models. The author and shepherd are quite understandably fatigued and frustrated by last minute reviews so I'd really really like to get them as much concrete feedback as soon as possible this time since NETMOD is progressing this draft. I know it is not a short draft, but this is important. Thanks very much, Alia P.S. I could supply chocolate rewards in Hawaii for anyone who does a review - although probably not molded into fun Halloween shapes. --f46d0444ec99f2933e05061e4c5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To make rapid progress on routing models, it is reall= y important to have a solid base routing model. =C2=A0 Before the Routing A= rea started working on YANG models, NETMOD adopted and has been working on = draft-ietf-netmod-routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-= ietf-netmod-routing-cfg/ ).

I would very s= trongly encourage you to read (or reread) and comment on this draft BEFORE = the upcoming IETF.=C2=A0 Please send your thoughts and concerns to both thi= s mailing list and netmod.

This is intended to be = the basis for our routing models.

The author and s= hepherd are quite understandably fatigued and frustrated by last minute rev= iews so I'd really really like to get them as much concrete feedback as= soon as possible this time since NETMOD is progressing this draft.

I know it is not a short draft, but this is important.

Thanks very much,
Alia

P.S.=C2=A0 I could supply chocolate rewards in Hawaii for anyone who = does a review - although probably not molded into fun Halloween shapes.

--f46d0444ec99f2933e05061e4c5b-- From nobody Thu Oct 23 15:13:09 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5C1AD530 for ; Thu, 23 Oct 2014 15:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 JEpzygIDxMQj for ; Thu, 23 Oct 2014 15:13:05 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130781AD534 for ; Thu, 23 Oct 2014 15:12:25 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id r2so3610382igi.5 for ; Thu, 23 Oct 2014 15:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jUtAY6zK8IM2FNYJi4VWi0hzWBNxcr+P40UReH9PNtc=; b=DO6ipHPKXsenBZa0J3I/ZQwGBfKmJxu6Jv9nHG1FwtWswIH0ysN8sI8y8z29hKNGeH fFq8d8nILy0oelhvZEhmR8ZYtj9IDvZxAe6vIhb+U5Ub3trct4x1Y33BRSGSQJ3FQYwe x1oK7dKsFvpu3iYqkorNCPLL0hrOnW80sU8Q5KOdubdHILlxLIqTJGOxog7IwcNLd3pM 8EjX9HCqGyP9UvV3oWKIryNp28oDHVvqfzo9GTF8Owv+q52BlQ9D4PZ1hxVEV7FzeePs xHJ5MzcCAQiz0lSMEnDoAlrtlyOG2DSD2QbGncPf2HhGdTcIEprJJ+CrV4VlOTE0eyhz KOVA== MIME-Version: 1.0 X-Received: by 10.43.168.8 with SMTP id ng8mr319035icc.67.1414102344511; Thu, 23 Oct 2014 15:12:24 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Thu, 23 Oct 2014 15:12:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 00:12:24 +0200 X-Google-Sender-Auth: nYHYohFjtEEASBE4oOgsWWGEN2k Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c2f15cebba5005061e5bc4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/jga4AfbfnpVmTmaf-BncDqWfaqw Cc: Rtg-yang-coord@ietf.org, Benoit Claise Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:13:08 -0000 --001a11c2f15cebba5005061e5bc4 Content-Type: text/plain; charset=UTF-8 Hello Alia, Wonderful summary ! One question ... is all/any work of Howard Yang from Cisco automatically classified as YANG model as well ;) draft-yang-trill-parent-seletion-03 Cheers, R. On Fri, Oct 24, 2014 at 12:05 AM, Alia Atlas wrote: > First, I am absolutely delighted to discover that this coordination list > has 139 subscribers! I am quite encouraged that we will be able to use > this mailing list for meaningful discussion and coordination. Welcome and > please start talking! > > Towards that purpose... > > With a few WG drafts and over 20 individual drafts that may overlap and > should share some common abstractions and groupings, we really need to > start coordinating. This is a significant explosion of drafts and > interest in the last 9 months - and we are interacting, at least in part, > with a community that NEEDS standardization to happen much more quickly. > > Adrian, Benoit, and I are planning on writing up a job description for a > secretary to help with this mailing list and the coordination and > communication necessary. Needless to say, if you would already like to > volunteer, please email me with details. > > To aid in finding the various YANG models that relate to routing in some > way, I've included a list below. This list was generated by looking > through a search of drafts based on the keyword YANG plus a couple I2RS > drafts I was already familiar with. I apologize if I missed any (and > encourage consistent naming ). > > draft-ietf-netmod-routing-cfg-15 > > draft-ietf-isis-yang-isis-cfg-00 > > draft-ietf-i2rs-rib-info-model-03 > (YANG > model coming very soon) > > draft-bogdanovic-netmod-acl-model-02 > (more > general than routing, so currently progressing in NETMOD) > draft-chen-mpls-ldp-yang-cfg-00 > > draft-chen-mpls-te-yang-cfg-00 > > draft-clemm-i2rs-yang-network-topo-01 > > draft-contreras-supa-yang-network-topo-00 > (targeted > at an unapproved BoF, overlap with I2RS) > draft-dong-i2rs-l2-network-topology-00 > > draft-gandhi-mpls-te-yang-model-00 > > draft-hao-trill-yang-01 > (may be > interesting to consider from the ISIS overlap) > draft-hares-i2rs-bgp-dm-00 > > draft-liu-netmod-yang-abstract-topo-00 > (another > topology model) > draft-liu-pim-igmp-mld-yang-00 > > draft-liu-pim-yang-00 > > draft-penno-sfc-yang-08 > > draft-pkd-pce-pcep-yang-00 > > draft-tissa-nvo3-yang-oam-00 > > draft-wang-i2rs-isis-dm-00 > > draft-wang-i2rs-ospf-dm-00 > > draft-yang-trill-parent-seletion-03 > > draft-yeung-netmod-ospf-02 > > draft-zhang-mpls-tp-yang-oam-00 > > draft-zhang-nvo3-yang-cfg-00 > > draft-zhdankin-netmod-bgp-cfg-01 > > draft-zhuang-l2vpn-evpn-yang-cfg-00 > > draft-zhuang-l2vpn-yang-cfg-00 > > draft-zhuang-l3vpn-yang-cfg-00 > > > I hope that reading some of the above (at least > draft-ietf-netmod-routing-cfg-15 > ) will > start to inspire ideas and concrete discussion about what coordination > between models and drafts is needed. > > Thanks, > Alia > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > --001a11c2f15cebba5005061e5bc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Alia,

Wonderful summary !=C2=A0

One question ... is = all/any work of Howard Yang from Cisco automatically classified as YANG mod= el as well ;)

draft-yang-trill-parent-seletion-03

Cheers,
R.



On Fri, Oct 24, 2014 at 12:05 AM, Alia Atlas <akatlas@gmail.com> wrote:
First, I am= absolutely delighted to discover that this coordination list has 139 subsc= ribers!=C2=A0 I am quite encouraged that we will be able to use this mailin= g list for meaningful discussion and coordination.=C2=A0 Welcome and please= start talking!

Towards that purpose...

With a few WG drafts and over 20 individual drafts th= at may overlap and should share some common abstractions and groupings, we = really need to start coordinating. =C2=A0 This is a significant explosion o= f drafts and interest in the last 9 months - and we are interacting, at lea= st in part, with a community that NEEDS standardization to happen much more= quickly.

Adrian, Benoit, and I are planning= on writing up a job description for a secretary to help with this mailing = list and the coordination and communication necessary.=C2=A0 Needless to sa= y, if you would already like to volunteer, please email me with details.

To aid in finding the various YANG models that = relate to routing in some way, I've included a list below.=C2=A0 This l= ist was generated by looking through a search of drafts based on the keywor= d YANG plus a couple I2RS drafts I was already familiar with.=C2=A0 I apolo= gize if I missed any (and encourage consistent naming ).
draft-clemm-i2rs-yang-network-topo-01
draft-contrer= as-supa-yang-network-topo-00=C2=A0(targeted at an unapproved BoF, overl= ap with I2RS)
draft-hao-trill-yang-01=C2=A0(may be interesting to consider from= the ISIS overlap)
draft-liu-netmod-yang-abstract-topo-00=C2=A0(another = topology model)

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--001a11c2f15cebba5005061e5bc4-- From nobody Thu Oct 23 15:14:29 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE9A1A6EF1 for ; Thu, 23 Oct 2014 15:14:28 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 iZ0kEzYIdDxs for ; Thu, 23 Oct 2014 15:14:20 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565A51A6EF0 for ; Thu, 23 Oct 2014 15:14:20 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id q5so264383wiv.4 for ; Thu, 23 Oct 2014 15:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=saLQboaaI0dAJVTNVrnMxlPw0nGEl95CZeEz4JBQ/LU=; b=TsjIsgYWo76GkGmvnovy/mQhok4ju52ISMYLAa4QRg33rUxaD+XLCgPu8L7Oij5Zvx S4+pSjcUP245UyHx25gEz3LQyM4mkY+nji+E4+lVf4SiBkLsS1jrLrauv+psKIX4NfUy ShEfPe9AuhwynbwUWIJjnjQ0C30/1tZWId9F6fkyxTBgGG+v0DiB0mmEPmtK0K4ZBbcx 2K+gItaq5Tt1hhQn7QvM7h1igcKi3pCrkBHrjC1EmRA77/huhZM86p8wcVeoDK7BInj4 +YyYoCpRikUyH4LExwOOL7qruvvXUxsZ1p8uVyW17ZqsugJM+BUBJZIUKdv6okIS2Qdz J4YA== MIME-Version: 1.0 X-Received: by 10.180.39.106 with SMTP id o10mr458145wik.54.1414102458982; Thu, 23 Oct 2014 15:14:18 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Thu, 23 Oct 2014 15:14:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 18:14:18 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=001a1135ed8ebe671205061e62fc Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/MhNvN71DGYIPoIyxcYb39AI1d78 Cc: Rtg-yang-coord@ietf.org, Benoit Claise Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:14:28 -0000 --001a1135ed8ebe671205061e62fc Content-Type: text/plain; charset=UTF-8 Hi Robert, On Thu, Oct 23, 2014 at 6:12 PM, Robert Raszuk wrote: > Hello Alia, > > Wonderful summary ! > Thanks! > One question ... is all/any work of Howard Yang from Cisco automatically > classified as YANG model as well ;) > > draft-yang-trill-parent-seletion-03 > > I skipped over that because it didn't seem related to routing (ISIS) but draft-hao-trill-yang-01 made it in. Sadly, I totally failed to notice that it was on the list because of the author's last name! Absurdly yours, Alia > Cheers, > R. > > > > > On Fri, Oct 24, 2014 at 12:05 AM, Alia Atlas wrote: > >> First, I am absolutely delighted to discover that this coordination list >> has 139 subscribers! I am quite encouraged that we will be able to use >> this mailing list for meaningful discussion and coordination. Welcome and >> please start talking! >> >> Towards that purpose... >> >> With a few WG drafts and over 20 individual drafts that may overlap and >> should share some common abstractions and groupings, we really need to >> start coordinating. This is a significant explosion of drafts and >> interest in the last 9 months - and we are interacting, at least in part, >> with a community that NEEDS standardization to happen much more quickly. >> >> Adrian, Benoit, and I are planning on writing up a job description for a >> secretary to help with this mailing list and the coordination and >> communication necessary. Needless to say, if you would already like to >> volunteer, please email me with details. >> >> To aid in finding the various YANG models that relate to routing in some >> way, I've included a list below. This list was generated by looking >> through a search of drafts based on the keyword YANG plus a couple I2RS >> drafts I was already familiar with. I apologize if I missed any (and >> encourage consistent naming ). >> >> draft-ietf-netmod-routing-cfg-15 >> >> draft-ietf-isis-yang-isis-cfg-00 >> >> draft-ietf-i2rs-rib-info-model-03 >> (YANG >> model coming very soon) >> >> draft-bogdanovic-netmod-acl-model-02 >> (more >> general than routing, so currently progressing in NETMOD) >> draft-chen-mpls-ldp-yang-cfg-00 >> >> draft-chen-mpls-te-yang-cfg-00 >> >> draft-clemm-i2rs-yang-network-topo-01 >> >> draft-contreras-supa-yang-network-topo-00 >> (targeted >> at an unapproved BoF, overlap with I2RS) >> draft-dong-i2rs-l2-network-topology-00 >> >> draft-gandhi-mpls-te-yang-model-00 >> >> draft-hao-trill-yang-01 >> (may be >> interesting to consider from the ISIS overlap) >> draft-hares-i2rs-bgp-dm-00 >> >> draft-liu-netmod-yang-abstract-topo-00 >> (another >> topology model) >> draft-liu-pim-igmp-mld-yang-00 >> >> draft-liu-pim-yang-00 >> >> draft-penno-sfc-yang-08 >> >> draft-pkd-pce-pcep-yang-00 >> >> draft-tissa-nvo3-yang-oam-00 >> >> draft-wang-i2rs-isis-dm-00 >> >> draft-wang-i2rs-ospf-dm-00 >> >> draft-yang-trill-parent-seletion-03 >> >> draft-yeung-netmod-ospf-02 >> >> draft-zhang-mpls-tp-yang-oam-00 >> >> draft-zhang-nvo3-yang-cfg-00 >> >> draft-zhdankin-netmod-bgp-cfg-01 >> >> draft-zhuang-l2vpn-evpn-yang-cfg-00 >> >> draft-zhuang-l2vpn-yang-cfg-00 >> >> draft-zhuang-l3vpn-yang-cfg-00 >> >> >> I hope that reading some of the above (at least >> draft-ietf-netmod-routing-cfg-15 >> ) will >> start to inspire ideas and concrete discussion about what coordination >> between models and drafts is needed. >> >> Thanks, >> Alia >> >> >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> > --001a1135ed8ebe671205061e62fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

On Thu, Oct 23, 2014 at 6:12 PM, Robert Raszuk <robert@raszu= k.net> wrote:
Hello Alia= ,

Wonderful summary !=C2=A0
Thanks!=C2=A0
=C2=A0
One question ... is all/any work of Howard Yang from Cisco= automatically classified as YANG model as well ;)


I skipped over that because it didn't seem related to routing = (ISIS) but=C2=A0draft-hao-trill-yang-01=
made it in.

Sadly, I totally failed= to notice that it was on the list because of the author's last name!

Absurdly yours,
Alia
=C2=A0
Cheers,
R.


=


On Fri, Oct 24, 2014 at 12:05 AM, Alia Atlas <= akatlas@gmail.com> wrote:
First, I am absolutely delighted to di= scover that this coordination list has 139 subscribers!=C2=A0 I am quite en= couraged that we will be able to use this mailing list for meaningful discu= ssion and coordination.=C2=A0 Welcome and please start talking!
Towards that purpose...

With = a few WG drafts and over 20 individual drafts that may overlap and should s= hare some common abstractions and groupings, we really need to start coordi= nating. =C2=A0 This is a significant explosion of drafts and interest in th= e last 9 months - and we are interacting, at least in part, with a communit= y that NEEDS standardization to happen much more quickly.
<= br>
Adrian, Benoit, and I are planning on writing up a job descri= ption for a secretary to help with this mailing list and the coordination a= nd communication necessary.=C2=A0 Needless to say, if you would already lik= e to volunteer, please email me with details.

To aid in finding the various YANG models that relate to routing in some w= ay, I've included a list below.=C2=A0 This list was generated by lookin= g through a search of drafts based on the keyword YANG plus a couple I2RS d= rafts I was already familiar with.=C2=A0 I apologize if I missed any (and e= ncourage consistent naming ).

draft-ietf-i2rs-rib-info-model-03=C2=A0(YANG model = coming very soon)

draft-bogdanovic-net= mod-acl-model-02=C2=A0(more general than routing, so currently progress= ing in NETMOD)
draft-contreras-supa-yang-network-topo-00= =C2=A0(targeted at an unapproved BoF, overlap with I2RS)
draft-hao-trill-yang-0= 1=C2=A0(may be interesting to consider from the ISIS overlap)
=
draft-liu-= netmod-yang-abstract-topo-00=C2=A0(another topology model)
draft-liu-pim-igmp-mld-yang-00
<= div>draft-wang-i2rs-ospf-dm-00
<= a href=3D"https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/" style= =3D"font-family:arial,helvetica,clean,sans-serif;font-size:13px;line-height= :16.0029983520508px;background-color:rgb(237,245,255)" target=3D"_blank">dr= aft-yeung-netmod-ospf-02

I hope that reading some of the above (at least=C2=A0draft-ietf= -netmod-routing-cfg-15) will start to inspire ideas and concrete discus= sion about what coordination between models and drafts is needed.

Thanks,
Alia


<= /div>

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



--001a1135ed8ebe671205061e62fc-- From nobody Thu Oct 23 15:46:09 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849971A7D84 for ; Thu, 23 Oct 2014 15:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xYCmOTCYxpUJ for ; Thu, 23 Oct 2014 15:46:03 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA811A700B for ; Thu, 23 Oct 2014 15:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5488; q=dns/txt; s=iport; t=1414104363; x=1415313963; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=NrmSmDwHM7dcyonYEMBzGFI7LulLmAvVI7m/pR5b2c4=; b=P1OWrv5l/ZyHkJiWAblf94ijzd7VMQJQgtzqcDuz/7npJy0LI3o7lUZs mXtCh81ZXDIjq/LftBINIUeljNv1LjgupfnI6PYOd+7i1m99RsXFltpN2 LwLP/AiSSlsQSlwHTh85qR6hCUwIudQwFrnbdNPaAAWm/pdzgjgeZgZxu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFALuESVStJV2Z/2dsb2JhbABcgw5UiTnEGAEJh00CgREWAX2EAwEBAwEBAQFoAwoGCwsOExYPCQMCAQIBFTAGAQwGAgEBiDUIDcg3AQEBAQEBAQEBAQEBAQEBAQEBARUEkF+ESwWLY4pohxKBMYNJgnI7hHOFEoQBhBgdL4JLAQEB X-IronPort-AV: E=Sophos; i="5.04,777,1406592000"; d="scan'208,217"; a="89831377" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 23 Oct 2014 22:46:01 +0000 Received: from [10.155.33.146] ([10.155.33.146]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9NMk0Ej022015; Thu, 23 Oct 2014 22:46:00 GMT Message-ID: <54498528.7010200@cisco.com> Date: Thu, 23 Oct 2014 15:46:00 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alia Atlas , Rtg-yang-coord@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000509050309080501060303" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/YV1sY41VlexSgE_5pdNj47oUssc Subject: Re: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:46:05 -0000 This is a multi-part message in MIME format. --------------000509050309080501060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publication state since 2014-05-25. So the fact that this draft is untouched since that date is not a bug, but a feature in this case. With the work done on the OSPF, ISIS, and BGP YANG models, this draft received some more expert reviews. Now, it's time to give actionable feedback on this document if it's unclear, broken, or unusable. I will not artificially hold this document forever. Alia and I are in line in terms of deadline: BEFORE the IETF please. Regards, Benoit > To make rapid progress on routing models, it is really important to > have a solid base routing model. Before the Routing Area started > working on YANG models, NETMOD adopted and has been working on > draft-ietf-netmod-routing-cfg-15 ( > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ). > > I would very strongly encourage you to read (or reread) and comment on > this draft BEFORE the upcoming IETF. Please send your thoughts and > concerns to both this mailing list and netmod. > > This is intended to be the basis for our routing models. > > The author and shepherd are quite understandably fatigued and > frustrated by last minute reviews so I'd really really like to get > them as much concrete feedback as soon as possible this time since > NETMOD is progressing this draft. > > I know it is not a short draft, but this is important. > > Thanks very much, > Alia > > P.S. I could supply chocolate rewards in Hawaii for anyone who does a > review - although probably not molded into fun Halloween shapes. > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord --------------000509050309080501060303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publication state since 2014-05-25.
So the fact that this draft is untouched since that date is not a bug, but a feature in this case.
With the work done on the OSPF, ISIS, and BGP YANG models, this draft received some more expert reviews.
Now, it's time to give actionable feedback on this document if it's unclear, broken, or unusable.
I will not artificially hold this document forever. Alia and I are in line in terms of deadline: BEFORE the IETF please.

Regards, Benoit


To make rapid progress on routing models, it is really important to have a solid base routing model.   Before the Routing Area started working on YANG models, NETMOD adopted and has been working on draft-ietf-netmod-routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ).

I would very strongly encourage you to read (or reread) and comment on this draft BEFORE the upcoming IETF.  Please send your thoughts and concerns to both this mailing list and netmod.

This is intended to be the basis for our routing models.

The author and shepherd are quite understandably fatigued and frustrated by last minute reviews so I'd really really like to get them as much concrete feedback as soon as possible this time since NETMOD is progressing this draft.

I know it is not a short draft, but this is important.

Thanks very much,
Alia

P.S.  I could supply chocolate rewards in Hawaii for anyone who does a review - although probably not molded into fun Halloween shapes.



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--------------000509050309080501060303-- From nobody Thu Oct 23 18:29:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4C61AD5AF for ; Thu, 23 Oct 2014 18:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2bmZ6LjYggOe for ; Thu, 23 Oct 2014 18:29:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBF61ACCDE for ; Thu, 23 Oct 2014 18:29:48 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 24 Oct 2014 01:29:47 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) with mapi id 15.00.1049.012; Fri, 24 Oct 2014 01:29:46 +0000 From: Dean Bogdanovic To: Benoit Claise , Ladislav Lhotka Thread-Topic: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 Thread-Index: AQHP7xMmZo1RaLlx2026Dplb5uebiJw+ddWA Date: Fri, 24 Oct 2014 01:29:46 +0000 Message-ID: <40D163CB-4F3D-468B-B045-180291A5FF68@juniper.net> References: <54498528.7010200@cisco.com> In-Reply-To: <54498528.7010200@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(24454002)(50226001)(93916002)(16236675004)(19617315012)(92726001)(80022003)(40100003)(19580395003)(50986999)(4396001)(104166001)(89996001)(64706001)(76176999)(62966002)(92566001)(87286001)(86362001)(120916001)(85852003)(122556002)(31966008)(57306001)(66066001)(107046002)(46102003)(2656002)(21056001)(87936001)(82746002)(77156001)(85306004)(15975445006)(76482002)(88136002)(230783001)(36756003)(95666004)(99396003)(77096002)(19580405001)(106356001)(83716003)(20776003)(99286002)(106116001)(105586002)(101416001)(33656002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_40D163CB4F3D468BB045180291A5FF68junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/MYjC30pG115oHxUDTsSXloJMVEA Cc: "Rtg-yang-coord@ietf.org" , Alia Atlas Subject: Re: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 01:29:50 -0000 --_000_40D163CB4F3D468BB045180291A5FF68junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benoit, Alia, There has been lot of discussion on and off the mailing list about routing-= cfg-15 draft. Lada should be posting v16 very, very soon. Dean On Oct 23, 2014, at 6:46 PM, Benoit Claise > wrote: Dear all, Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publicati= on state since 2014-05-25. So the fact that this draft is untouched since that date is not a bug, but = a feature in this case. With the work done on the OSPF, ISIS, and BGP YANG models, this draft recei= ved some more expert reviews. Now, it's time to give actionable feedback on this document if it's unclear= , broken, or unusable. I will not artificially hold this document forever. Alia and I are in line = in terms of deadline: BEFORE the IETF please. Regards, Benoit To make rapid progress on routing models, it is really important to have a = solid base routing model. Before the Routing Area started working on YANG= models, NETMOD adopted and has been working on draft-ietf-netmod-routing-c= fg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ). I would very strongly encourage you to read (or reread) and comment on this= draft BEFORE the upcoming IETF. Please send your thoughts and concerns to= both this mailing list and netmod. This is intended to be the basis for our routing models. The author and shepherd are quite understandably fatigued and frustrated by= last minute reviews so I'd really really like to get them as much concrete= feedback as soon as possible this time since NETMOD is progressing this dr= aft. I know it is not a short draft, but this is important. Thanks very much, Alia P.S. I could supply chocolate rewards in Hawaii for anyone who does a revi= ew - although probably not molded into fun Halloween shapes. _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord --_000_40D163CB4F3D468BB045180291A5FF68junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5454538FD2CF7F458C96719788CB071C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Benoit, Alia,

There has been lot of discussion on and off the mailing list about rou= ting-cfg-15 draft. Lada should be posting v16 very, very soon.

Dean

On Oct 23, 2014, at 6:46 PM, Benoit Claise <bclaise@cisco.com>
 wrote:

Dear all,

Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publicati= on state since 2014-05-25.
So the fact that this draft is untouched since that date is not a bug, but = a feature in this case.
With the work done on the OSPF, ISIS, and BGP YANG models, this draft recei= ved some more expert reviews.
Now, it's time to give actionable feedback on this document if it's unclear= , broken, or unusable.
I will not artificially hold this document forever. Alia and I are in line = in terms of deadline: BEFORE the IETF please.

Regards, Benoit


To make rapid progress on routing models, it is really important to ha= ve a solid base routing model.   Before the Routing Area started worki= ng on YANG models, NETMOD adopted and has been working on draft-ietf-netmod= -routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ).

I would very strongly encourage you to read (or reread) and comment on= this draft BEFORE the upcoming IETF.  Please send your thoughts and c= oncerns to both this mailing list and netmod.

This is intended to be the basis for our routing models.

The author and shepherd are quite understandably fatigued and frustrat= ed by last minute reviews so I'd really really like to get them as much con= crete feedback as soon as possible this time since NETMOD is progressing th= is draft.

I know it is not a short draft, but this is important.

Thanks very much,
Alia

P.S.  I could supply chocolate rewards in Hawaii for anyone who d= oes a review - although probably not molded into fun Halloween shapes. 



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord<=
/a>

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--_000_40D163CB4F3D468BB045180291A5FF68junipernet_-- From nobody Thu Oct 23 19:04:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA741AD8ED for ; Thu, 23 Oct 2014 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 AuvzpT2BsuNq for ; Thu, 23 Oct 2014 19:04:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44F41AD845 for ; Thu, 23 Oct 2014 19:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24690; q=dns/txt; s=iport; t=1414116283; x=1415325883; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iW397rSpj3Zl4/FveFt0trwqdztWhnDsFMMMrWtTCTI=; b=bVBP8q3BNu2qodY4ylLdJwoWrDkMGA/o8/bxxbTEmyn8xPW42ziGXwBw cnQQSQYX9Kbh3YvkS1TnWzrsssl3Dco3RoXGlcgH/IWaX4Z3p5AbPaEMX sWn4AnlOP2pByq1gKJUFe45BVja6xjk8txS3LTBN0BGXr4Fea/0dHsH2b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAHqySVStJA2E/2dsb2JhbABcgkhGVFyDAsoCh0sCG3MWAX2EAwEBBCMKQQsQAgEIDhQgAgICMCUCBAENDQyILQ21NZRuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPdhEBHy0EB4J3NoEeBZIFhEaIQ4NJkTKCNIFEgXs5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,778,1406592000"; d="scan'208,217";a="366200521" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2014 02:04:42 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9O24fsB024120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 02:04:41 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.227]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 21:04:41 -0500 From: "Matt Hartley (mhartley)" To: Alia Atlas , "Rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed Thread-Index: AQHP7w150sQXcmy0qUenAVfIbAJv3Jw+fqjw Date: Fri, 24 Oct 2014 02:04:41 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.185] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4xmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Dgw87jFDBkTPO6uWEGyHO4rZD0o Cc: "Benoit Claise \(bclaise\)" , "Matt Hartley \(mhartley\)" Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:04:49 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4xmbrcdx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCg0KZHJhZnQtZGhhcmluaS1uZXRtb2QtZy02OTgtMi15YW5nLTAwIHNob3VsZCBwcm9i YWJseSBnbyBvbiB0aGUgbGlzdC4NCg0KQ2hlZXJzDQoNCk1hdHQNCg0KDQpGaXJzdCwgSSBhbSBh YnNvbHV0ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3ZlciB0aGF0IHRoaXMgY29vcmRpbmF0aW9uIGxp c3QgaGFzIDEzOSBzdWJzY3JpYmVycyEgIEkgYW0gcXVpdGUgZW5jb3VyYWdlZCB0aGF0IHdlIHdp bGwgYmUgYWJsZSB0byB1c2UgdGhpcyBtYWlsaW5nIGxpc3QgZm9yIG1lYW5pbmdmdWwgZGlzY3Vz c2lvbiBhbmQgY29vcmRpbmF0aW9uLiAgV2VsY29tZSBhbmQgcGxlYXNlIHN0YXJ0IHRhbGtpbmch DQoNClRvd2FyZHMgdGhhdCBwdXJwb3NlLi4uDQoNCldpdGggYSBmZXcgV0cgZHJhZnRzIGFuZCBv dmVyIDIwIGluZGl2aWR1YWwgZHJhZnRzIHRoYXQgbWF5IG92ZXJsYXAgYW5kIHNob3VsZCBzaGFy ZSBzb21lIGNvbW1vbiBhYnN0cmFjdGlvbnMgYW5kIGdyb3VwaW5ncywgd2UgcmVhbGx5IG5lZWQg dG8gc3RhcnQgY29vcmRpbmF0aW5nLiAgIFRoaXMgaXMgYSBzaWduaWZpY2FudCBleHBsb3Npb24g b2YgZHJhZnRzIGFuZCBpbnRlcmVzdCBpbiB0aGUgbGFzdCA5IG1vbnRocyAtIGFuZCB3ZSBhcmUg aW50ZXJhY3RpbmcsIGF0IGxlYXN0IGluIHBhcnQsIHdpdGggYSBjb21tdW5pdHkgdGhhdCBORUVE UyBzdGFuZGFyZGl6YXRpb24gdG8gaGFwcGVuIG11Y2ggbW9yZSBxdWlja2x5Lg0KDQpBZHJpYW4s IEJlbm9pdCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRpbmcgdXAgYSBqb2IgZGVzY3JpcHRp b24gZm9yIGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlzIG1haWxpbmcgbGlzdCBhbmQgdGhl IGNvb3JkaW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNlc3NhcnkuICBOZWVkbGVzcyB0byBz YXksIGlmIHlvdSB3b3VsZCBhbHJlYWR5IGxpa2UgdG8gdm9sdW50ZWVyLCBwbGVhc2UgZW1haWwg bWUgd2l0aCBkZXRhaWxzLg0KDQpUbyBhaWQgaW4gZmluZGluZyB0aGUgdmFyaW91cyBZQU5HIG1v ZGVscyB0aGF0IHJlbGF0ZSB0byByb3V0aW5nIGluIHNvbWUgd2F5LCBJJ3ZlIGluY2x1ZGVkIGEg bGlzdCBiZWxvdy4gIFRoaXMgbGlzdCB3YXMgZ2VuZXJhdGVkIGJ5IGxvb2tpbmcgdGhyb3VnaCBh IHNlYXJjaCBvZiBkcmFmdHMgYmFzZWQgb24gdGhlIGtleXdvcmQgWUFORyBwbHVzIGEgY291cGxl IEkyUlMgZHJhZnRzIEkgd2FzIGFscmVhZHkgZmFtaWxpYXIgd2l0aC4gIEkgYXBvbG9naXplIGlm IEkgbWlzc2VkIGFueSAoYW5kIGVuY291cmFnZSBjb25zaXN0ZW50IG5hbWluZyApLg0KDQpkcmFm dC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+DQpkcmFmdC1pZXRmLWlzaXMteWFu Zy1pc2lzLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWlzaXMteWFuZy1pc2lzLWNmZy8+DQpkcmFmdC1pZXRmLWkycnMtcmliLWluZm8tbW9kZWwtMDM8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1pbmZv LW1vZGVsLz4gKFlBTkcgbW9kZWwgY29taW5nIHZlcnkgc29vbikNCg0KZHJhZnQtYm9nZGFub3Zp Yy1uZXRtb2QtYWNsLW1vZGVsLTAyPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8+IChtb3JlIGdlbmVyYWwgdGhhbiByb3V0 aW5nLCBzbyBjdXJyZW50bHkgcHJvZ3Jlc3NpbmcgaW4gTkVUTU9EKQ0KZHJhZnQtY2hlbi1tcGxz LWxkcC15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1j aGVuLW1wbHMtbGRwLXlhbmctY2ZnLz4NCmRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMDxo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1j ZmcvPg0KZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmstdG9wby0wMTxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jbGVtbS1pMnJzLXlhbmctbmV0d29yay10b3BvLz4N CmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLTAwPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3Bv Lz4gKHRhcmdldGVkIGF0IGFuIHVuYXBwcm92ZWQgQm9GLCBvdmVybGFwIHdpdGggSTJSUykNCmRy YWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5Lz4NCmRyYWZ0 LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC8+DQpkcmFmdC1oYW8tdHJpbGwt eWFuZy0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8tdHJpbGwt eWFuZy8+IChtYXkgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lkZXIgZnJvbSB0aGUgSVNJUyBvdmVy bGFwKQ0KZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0vPg0KZHJhZnQtbGl1LW5ldG1vZC15YW5n LWFic3RyYWN0LXRvcG8tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8vPiAoYW5vdGhlciB0b3BvbG9neSBtb2RlbCkN CmRyYWZ0LWxpdS1waW0taWdtcC1tbGQteWFuZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmcvPg0KZHJhZnQtbGl1LXBpbS15YW5n LTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1waW0teWFuZy8+ DQpkcmFmdC1wZW5uby1zZmMteWFuZy0wODxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1wZW5uby1zZmMteWFuZy8+DQpkcmFmdC1wa2QtcGNlLXBjZXAteWFuZy0wMDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wa2QtcGNlLXBjZXAteWFuZy8+DQpk cmFmdC10aXNzYS1udm8zLXlhbmctb2FtLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vPg0KZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0t MDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLWlzaXMt ZG0vPg0KZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vPg0KZHJhZnQteWFuZy10cmlsbC1wYXJl bnQtc2VsZXRpb24tMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWFu Zy10cmlsbC1wYXJlbnQtc2VsZXRpb24vPg0KZHJhZnQteWV1bmctbmV0bW9kLW9zcGYtMDI8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWV1bmctbmV0bW9kLW9zcGYvPg0K ZHJhZnQtemhhbmctbXBscy10cC15YW5nLW9hbS0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLz4NCmRyYWZ0LXpoYW5nLW52bzMt eWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmct bnZvMy15YW5nLWNmZy8+DQpkcmFmdC16aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy0wMTxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy8+ DQpkcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy8+DQpkcmFmdC16 aHVhbmctbDJ2cG4teWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLz4NCmRyYWZ0LXpodWFuZy1sM3Zwbi15YW5nLWNm Zy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctbDN2cG4t eWFuZy1jZmcvPg0KDQpJIGhvcGUgdGhhdCByZWFkaW5nIHNvbWUgb2YgdGhlIGFib3ZlIChhdCBs ZWFzdCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+KSB3aWxsIHN0YXJ0 IHRvIGluc3BpcmUgaWRlYXMgYW5kIGNvbmNyZXRlIGRpc2N1c3Npb24gYWJvdXQgd2hhdCBjb29y ZGluYXRpb24gYmV0d2VlbiBtb2RlbHMgYW5kIGRyYWZ0cyBpcyBuZWVkZWQuDQoNClRoYW5rcywN CkFsaWENCg0KDQo= --_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4xmbrcdx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUg NSAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkJv b2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5BbGlhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2tt YW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPmRyYWZ0 LWRoYXJpbmktbmV0bW9kLWctNjk4LTIteWFuZy0wMCBzaG91bGQgcHJvYmFibHkgZ28gb24gdGhl IGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5 bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9v a21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+TWF0 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJzdCwg SSBhbSBhYnNvbHV0ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3ZlciB0aGF0IHRoaXMgY29vcmRpbmF0 aW9uIGxpc3QgaGFzIDEzOSBzdWJzY3JpYmVycyEmbmJzcDsgSSBhbSBxdWl0ZSBlbmNvdXJhZ2Vk IHRoYXQgd2Ugd2lsbCBiZSBhYmxlIHRvIHVzZSB0aGlzIG1haWxpbmcgbGlzdCBmb3IgbWVhbmlu Z2Z1bCBkaXNjdXNzaW9uIGFuZCBjb29yZGluYXRpb24uJm5ic3A7IFdlbGNvbWUgYW5kIHBsZWFz ZSBzdGFydCB0YWxraW5nITxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VG93YXJkcyB0aGF0IHB1cnBvc2UuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggYSBmZXcgV0cgZHJhZnRzIGFu ZCBvdmVyIDIwIGluZGl2aWR1YWwgZHJhZnRzIHRoYXQgbWF5IG92ZXJsYXAgYW5kIHNob3VsZCBz aGFyZSBzb21lIGNvbW1vbiBhYnN0cmFjdGlvbnMgYW5kIGdyb3VwaW5ncywgd2UgcmVhbGx5IG5l ZWQgdG8gc3RhcnQgY29vcmRpbmF0aW5nLiAmbmJzcDsgVGhpcyBpcyBhIHNpZ25pZmljYW50IGV4 cGxvc2lvbiBvZiBkcmFmdHMgYW5kIGludGVyZXN0IGluIHRoZSBsYXN0IDkgbW9udGhzDQogLSBh bmQgd2UgYXJlIGludGVyYWN0aW5nLCBhdCBsZWFzdCBpbiBwYXJ0LCB3aXRoIGEgY29tbXVuaXR5 IHRoYXQgTkVFRFMgc3RhbmRhcmRpemF0aW9uIHRvIGhhcHBlbiBtdWNoIG1vcmUgcXVpY2tseS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BZHJpYW4sIEJlbm9pdCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRpbmcgdXAgYSBq b2IgZGVzY3JpcHRpb24gZm9yIGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlzIG1haWxpbmcg bGlzdCBhbmQgdGhlIGNvb3JkaW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNlc3NhcnkuJm5i c3A7IE5lZWRsZXNzIHRvIHNheSwgaWYgeW91IHdvdWxkIGFscmVhZHkgbGlrZSB0byB2b2x1bnRl ZXIsIHBsZWFzZSBlbWFpbCBtZQ0KIHdpdGggZGV0YWlscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFpZCBpbiBmaW5kaW5n IHRoZSB2YXJpb3VzIFlBTkcgbW9kZWxzIHRoYXQgcmVsYXRlIHRvIHJvdXRpbmcgaW4gc29tZSB3 YXksIEkndmUgaW5jbHVkZWQgYSBsaXN0IGJlbG93LiZuYnNwOyBUaGlzIGxpc3Qgd2FzIGdlbmVy YXRlZCBieSBsb29raW5nIHRocm91Z2ggYSBzZWFyY2ggb2YgZHJhZnRzIGJhc2VkIG9uIHRoZSBr ZXl3b3JkIFlBTkcgcGx1cyBhIGNvdXBsZSBJMlJTIGRyYWZ0cyBJIHdhcyBhbHJlYWR5IGZhbWls aWFyDQogd2l0aC4mbmJzcDsgSSBhcG9sb2dpemUgaWYgSSBtaXNzZWQgYW55IChhbmQgZW5jb3Vy YWdlIGNvbnNpc3RlbnQgbmFtaW5nICkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2Zn LTE1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaXNpcy15YW5nLWlzaXMtY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNr Z3JvdW5kOiNFREY1RkYiPmRyYWZ0LWlldGYtaXNpcy15YW5nLWlzaXMtY2ZnLTAwPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1y aWItaW5mby1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURG NUZGIj5kcmFmdC1pZXRmLWkycnMtcmliLWluZm8tbW9kZWwtMDM8L3NwYW4+PC9hPiZuYnNwOyhZ QU5HIG1vZGVsIGNvbWluZyB2ZXJ5IHNvb24pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1ib2dkYW5vdmljLW5ldG1v ZC1hY2wtbW9kZWwtMDI8L3NwYW4+PC9hPiZuYnNwOyhtb3JlIGdlbmVyYWwgdGhhbiByb3V0aW5n LA0KIHNvIGN1cnJlbnRseSBwcm9ncmVzc2luZyBpbiBORVRNT0QpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtbGRwLXlhbmctY2ZnLyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtY2hlbi1tcGxzLWxkcC15YW5nLWNmZy0wMDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1w bHMtdGUteWFuZy1jZmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VE RjVGRiI+ZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNsZW1tLWkycnMteWFuZy1uZXR3b3Jr LXRvcG8vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1jbGVtbS1pMnJzLXlhbmct bmV0d29yay10b3BvLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8t MDA8L3NwYW4+PC9hPiZuYnNwOyh0YXJnZXRlZCBhdCBhbiB1bmFwcHJvdmVkIEJvRiwgb3Zlcmxh cA0KIHdpdGggSTJSUyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+ZHJhZnQtZG9uZy1pMnJzLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFu Zy1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5k cmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby10cmlsbC15YW5nLyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaGFvLXRyaWxsLXlhbmctMDE8L3NwYW4+PC9hPiZuYnNw OyhtYXkgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lkZXIgZnJvbSB0aGUgSVNJUyBvdmVybGFwKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZXMtaTJycy1iZ3At ZG0vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1oYXJlcy1pMnJzLWJncC1kbS0w MDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s aXUtbmV0bW9kLXlhbmctYWJzdHJhY3QtdG9wby8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PmRyYWZ0LWxpdS1uZXRtb2QteWFuZy1hYnN0cmFjdC10b3BvLTAwPC9zcGFuPjwvYT4mbmJzcDso YW5vdGhlciB0b3BvbG9neSBtb2RlbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxpdS1waW0taWdtcC1tbGQteWFuZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmctMDA8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXBp bS15YW5nLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtbGl1LXBpbS15YW5nLTAw PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBl bm5vLXNmYy15YW5nLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtcGVubm8tc2Zj LXlhbmctMDg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcGtkLXBjZS1wY2VwLXlhbmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tn cm91bmQ6I0VERjVGRiI+ZHJhZnQtcGtkLXBjZS1wY2VwLXlhbmctMDA8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtbnZvMy15YW5nLW9h bS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0t MDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt d2FuZy1pMnJzLWlzaXMtZG0vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6 I0VERjVGRiI+ZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC13YW5nLWkycnMtb3NwZi1kbS0wMDwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW5nLXRyaWxs LXBhcmVudC1zZWxldGlvbi8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDoj RURGNUZGIj5kcmFmdC15YW5nLXRyaWxsLXBhcmVudC1zZWxldGlvbi0wMzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15ZXVuZy1uZXRtb2Qtb3Nw Zi8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC15 ZXVuZy1uZXRtb2Qtb3NwZi0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1v YW0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtemhhbmctbnZvMy15YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0 LXpoYW5nLW52bzMteWFuZy1jZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtemhkYW5raW4tbmV0bW9kLWJncC1jZmcvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtemhkYW5raW4tbmV0bW9k LWJncC1jZmctMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtemh1YW5nLWwydnBuLWV2cG4teWFuZy1jZmcvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtemh1YW5nLWwydnBuLWV2cG4teWFuZy1j ZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJh ZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodWFuZy1sM3Zwbi15YW5nLWNmZy8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC16aHVhbmctbDN2cG4t eWFuZy1jZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvcGUgdGhhdCByZWFkaW5nIHNvbWUgb2YgdGhlIGFib3Zl IChhdCBsZWFzdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTE1PC9z cGFuPjwvYT4pDQogd2lsbCBzdGFydCB0byBpbnNwaXJlIGlkZWFzIGFuZCBjb25jcmV0ZSBkaXNj dXNzaW9uIGFib3V0IHdoYXQgY29vcmRpbmF0aW9uIGJldHdlZW4gbW9kZWxzIGFuZCBkcmFmdHMg aXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4xmbrcdx03ciscoc_-- From nobody Thu Oct 23 19:22:26 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC5E1A700A for ; Thu, 23 Oct 2014 19:22:23 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 IuXgmir-i1Fm for ; Thu, 23 Oct 2014 19:22:17 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC061A87A4 for ; Thu, 23 Oct 2014 19:22:17 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id c41so2002350yho.20 for ; Thu, 23 Oct 2014 19:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cFdG2ab6KcgheF68mbWt8dNOUZYXGx+j4Ky42tS6vug=; b=DZOrFmdPnRN/1vNx3+jHIZhOF553HkTyBc9avzXkqz+VOOFCk75LfGHrcCR3dUB6Jn 5M9ratSmUDffDD8AV0gH1qbbNWAZbewcjtwjIEDZv+Fb2725jcP5kkmmDp1SPk/COpAc aC0t9zZKnXHAokKOnW1pN9zCzTevFe6BUXlQezp1Pkf7PtjGLaZMVRZ2oLie/mIqEVds 8TypAJFoqrD6T9/DbgEvZOS5MkkLS2ZaqC1DdsK2wkllZT4AaqoUq+MKl4jQNG40d1HQ Sk4cGl8dg6wWJ2t3YwMN29URdOafcvaoTGshmR4PVWjTalumD1FlgaBm7+LQokhqLxrZ rrxQ== MIME-Version: 1.0 X-Received: by 10.170.197.150 with SMTP id o144mr1501257yke.103.1414117336596; Thu, 23 Oct 2014 19:22:16 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Thu, 23 Oct 2014 19:22:16 -0700 (PDT) In-Reply-To: <40D163CB-4F3D-468B-B045-180291A5FF68@juniper.net> References: <54498528.7010200@cisco.com> <40D163CB-4F3D-468B-B045-180291A5FF68@juniper.net> Date: Thu, 23 Oct 2014 22:22:16 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a1139cc8084c862050621d9db Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/6OO0G-kcusB5PSpWPJ7S6OTPXuI Cc: Benoit Claise , "Rtg-yang-coord@ietf.org" , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:22:23 -0000 --001a1139cc8084c862050621d9db Content-Type: text/plain; charset=UTF-8 Dean, Thanks for the info. After I sent this email, I learned that the last round of comments still hadn't made it into a draft. Lada, I hope the delay is only a day or two... Alia On Thu, Oct 23, 2014 at 9:29 PM, Dean Bogdanovic wrote: > Benoit, Alia, > > There has been lot of discussion on and off the mailing list about > routing-cfg-15 draft. Lada should be posting v16 very, very soon. > > Dean > > On Oct 23, 2014, at 6:46 PM, Benoit Claise > wrote: > > Dear all, > > Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG > publication state since 2014-05-25. > So the fact that this draft is untouched since that date is not a bug, but > a feature in this case. > With the work done on the OSPF, ISIS, and BGP YANG models, this draft > received some more expert reviews. > Now, it's time to give actionable feedback on this document if it's > unclear, broken, or unusable. > I will not artificially hold this document forever. Alia and I are in line > in terms of deadline: BEFORE the IETF please. > > Regards, Benoit > > > To make rapid progress on routing models, it is really important to > have a solid base routing model. Before the Routing Area started working > on YANG models, NETMOD adopted and has been working on > draft-ietf-netmod-routing-cfg-15 ( > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ). > > I would very strongly encourage you to read (or reread) and comment on > this draft BEFORE the upcoming IETF. Please send your thoughts and > concerns to both this mailing list and netmod. > > This is intended to be the basis for our routing models. > > The author and shepherd are quite understandably fatigued and frustrated > by last minute reviews so I'd really really like to get them as much > concrete feedback as soon as possible this time since NETMOD is progressing > this draft. > > I know it is not a short draft, but this is important. > > Thanks very much, > Alia > > P.S. I could supply chocolate rewards in Hawaii for anyone who does a > review - although probably not molded into fun Halloween shapes. > > > > _______________________________________________ > Rtg-yang-coord mailing listRtg-yang-coord@ietf.orghttps://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > --001a1139cc8084c862050621d9db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dean,

Thanks for the info.=C2=A0 After = I sent this email, I learned that the last round of
comments stil= l hadn't made it into a draft.

Lada, I hope th= e delay is only a day or two...

Alia

On Thu, Oct 23, 201= 4 at 9:29 PM, Dean Bogdanovic <deanb@juniper.net> wrote:
=
Benoit, Alia,

There has been lot of discussion on and off the mailing list about rou= ting-cfg-15 draft. Lada should be posting v16 very, very soon.

Dean

On Oct 23, 2014, at 6:46 PM, Benoit Claise <bclaise@cisco.com>
=C2=A0wrote:

Dear all,

Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publicati= on state since 2014-05-25.
So the fact that this draft is untouched since that date is not a bug, but = a feature in this case.
With the work done on the OSPF, ISIS, and BGP YANG models, this draft recei= ved some more expert reviews.
Now, it's time to give actionable feedback on this document if it's= unclear, broken, or unusable.
I will not artificially hold this document forever. Alia and I are in line = in terms of deadline: BEFORE the IETF please.

Regards, Benoit


To make rapid progress on routing models, it is really important to ha= ve a solid base routing model. =C2=A0 Before the Routing Area started worki= ng on YANG models, NETMOD adopted and has been working on draft-ietf-netmod= -routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ).

I would very strongly encourage you to read (or reread) and comment on= this draft BEFORE the upcoming IETF.=C2=A0 Please send your thoughts and c= oncerns to both this mailing list and netmod.

This is intended to be the basis for our routing models.

The author and shepherd are quite understandably fatigued and frustrat= ed by last minute reviews so I'd really really like to get them as much= concrete feedback as soon as possible this time since NETMOD is progressin= g this draft.

I know it is not a short draft, but this is important.

Thanks very much,
Alia

P.S.=C2=A0 I could supply chocolate rewards in Hawaii for anyone who d= oes a review - although probably not molded into fun Halloween shapes. 



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

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


--001a1139cc8084c862050621d9db-- From nobody Thu Oct 23 19:45:00 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1DD1A8858 for ; Thu, 23 Oct 2014 19:44:56 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 idg_-H4DHnqg for ; Thu, 23 Oct 2014 19:44:50 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE05C1A885A for ; Thu, 23 Oct 2014 19:44:45 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f10so2032544yha.39 for ; Thu, 23 Oct 2014 19:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CsgfXhgKZ6nztBcIocfCp0I8fzdmfm6GWSGnHT3ARTY=; b=dklUkGP2e/XsY0VWmYG1/NhYgYEq4nouFvRRq5ajEc+4SlYKxMqRl83iuFXgSwREjW +HDKBFDBk/XzgQwHNLbZMGOSeBOeH7/OCxOzfJPuMkeS3bGc+vwOan9Zs3QcTEm6yTyP 8Dsfogf4+JJN3hweOZynZ3O8Am7Ji9nAkL0aPFMOSe+ewzZtOUnZL5jn8Sz9nwDFVR9/ vhLhE6i499NOP1eRPL1fk2Jw03vwm/viQZxVDkztIu3EEaMn+nUSgWuaQGKuCRCyXuJt HiAw1khc34AFUMq2NK4FVu3c02Ani80fFHjjyCbNGCxYv+QOk9RZ6rjf8rrcIJKuICMQ KxOA== MIME-Version: 1.0 X-Received: by 10.170.197.150 with SMTP id o144mr1631546yke.103.1414118685238; Thu, 23 Oct 2014 19:44:45 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Thu, 23 Oct 2014 19:44:45 -0700 (PDT) In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4@xmb-rcd-x03.cisco.com> Date: Thu, 23 Oct 2014 22:44:45 -0400 Message-ID: From: Alia Atlas To: "Matt Hartley (mhartley)" Content-Type: multipart/alternative; boundary=001a1139cc80e76c2605062229b4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/c075jMmrY-V6BGlu3QbtFWDk7fY Cc: "Rtg-yang-coord@ietf.org" , "Benoit Claise \(bclaise\)" Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:44:56 -0000 --001a1139cc80e76c2605062229b4 Content-Type: text/plain; charset=UTF-8 Hi Matt, Thanks. I guess that might fall under CCAMP. Not closely following CCAMP, I wasn't sure if it was well connected. Alia On Thu, Oct 23, 2014 at 10:04 PM, Matt Hartley (mhartley) < mhartley@cisco.com> wrote: > Alia, > > > > draft-dharini-netmod-g-698-2-yang-00 should probably go on the list. > > > > Cheers > > > > Matt > > > > > > First, I am absolutely delighted to discover that this coordination list > has 139 subscribers! I am quite encouraged that we will be able to use > this mailing list for meaningful discussion and coordination. Welcome and > please start talking! > > > > Towards that purpose... > > > > With a few WG drafts and over 20 individual drafts that may overlap and > should share some common abstractions and groupings, we really need to > start coordinating. This is a significant explosion of drafts and > interest in the last 9 months - and we are interacting, at least in part, > with a community that NEEDS standardization to happen much more quickly. > > > > Adrian, Benoit, and I are planning on writing up a job description for a > secretary to help with this mailing list and the coordination and > communication necessary. Needless to say, if you would already like to > volunteer, please email me with details. > > > > To aid in finding the various YANG models that relate to routing in some > way, I've included a list below. This list was generated by looking > through a search of drafts based on the keyword YANG plus a couple I2RS > drafts I was already familiar with. I apologize if I missed any (and > encourage consistent naming ). > > > > draft-ietf-netmod-routing-cfg-15 > > > draft-ietf-isis-yang-isis-cfg-00 > > > draft-ietf-i2rs-rib-info-model-03 > (YANG > model coming very soon) > > > > draft-bogdanovic-netmod-acl-model-02 > (more > general than routing, so currently progressing in NETMOD) > > draft-chen-mpls-ldp-yang-cfg-00 > > > draft-chen-mpls-te-yang-cfg-00 > > > draft-clemm-i2rs-yang-network-topo-01 > > > draft-contreras-supa-yang-network-topo-00 > (targeted > at an unapproved BoF, overlap with I2RS) > > draft-dong-i2rs-l2-network-topology-00 > > > draft-gandhi-mpls-te-yang-model-00 > > > draft-hao-trill-yang-01 > (may be > interesting to consider from the ISIS overlap) > > draft-hares-i2rs-bgp-dm-00 > > > draft-liu-netmod-yang-abstract-topo-00 > (another > topology model) > > draft-liu-pim-igmp-mld-yang-00 > > > draft-liu-pim-yang-00 > > > draft-penno-sfc-yang-08 > > > draft-pkd-pce-pcep-yang-00 > > > draft-tissa-nvo3-yang-oam-00 > > > draft-wang-i2rs-isis-dm-00 > > > draft-wang-i2rs-ospf-dm-00 > > > draft-yang-trill-parent-seletion-03 > > > draft-yeung-netmod-ospf-02 > > > draft-zhang-mpls-tp-yang-oam-00 > > > draft-zhang-nvo3-yang-cfg-00 > > > draft-zhdankin-netmod-bgp-cfg-01 > > > draft-zhuang-l2vpn-evpn-yang-cfg-00 > > > draft-zhuang-l2vpn-yang-cfg-00 > > > draft-zhuang-l3vpn-yang-cfg-00 > > > > > I hope that reading some of the above (at least > draft-ietf-netmod-routing-cfg-15 > ) will > start to inspire ideas and concrete discussion about what coordination > between models and drafts is needed. > > > > Thanks, > > Alia > > > > > --001a1139cc80e76c2605062229b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matt,

Thanks.=C2=A0 I guess that mig= ht fall under CCAMP. =C2=A0 Not closely following CCAMP, I wasn't sure = if it was well connected.

Alia

On Thu, Oct 23, 2014 at 1= 0:04 PM, Matt Hartley (mhartley) <mhartley@cisco.com> wrote= :

Alia,<= /span>

=C2=A0=

draft-dharini-netmod= -g-698-2-yang-00 should probably go on the list.

=C2=A0=

Cheers

=C2=A0=

Matt

=C2=A0=

=C2=A0

First, I am absolutely delighted to discover that th= is coordination list has 139 subscribers!=C2=A0 I am quite encouraged that = we will be able to use this mailing list for meaningful discussion and coor= dination.=C2=A0 Welcome and please start talking!

=C2=A0

Towards that purpose...

=C2=A0

With a few WG drafts and over 20 individual drafts t= hat may overlap and should share some common abstractions and groupings, we= really need to start coordinating. =C2=A0 This is a significant explosion = of drafts and interest in the last 9 months - and we are interacting, at least in part, with a community that NEEDS st= andardization to happen much more quickly.

=C2=A0

Adrian, Benoit, and I are planning on writing up a j= ob description for a secretary to help with this mailing list and the coord= ination and communication necessary.=C2=A0 Needless to say, if you would al= ready like to volunteer, please email me with details.

=C2=A0

To aid in finding the various YANG models that relat= e to routing in some way, I've included a list below.=C2=A0 This list w= as generated by looking through a search of drafts based on the keyword YAN= G plus a couple I2RS drafts I was already familiar with.=C2=A0 I apologize if I missed any (and encourage consistent naming )= .

=C2=A0

dr= aft-ietf-i2rs-rib-info-model-03=C2=A0(YANG model coming very soo= n)

=C2=A0

draft-bogdanovic-netmod-acl-model-02=C2=A0(more general than ro= uting, so currently progressing in NETMOD)

draft-contrer= as-supa-yang-network-topo-00=C2=A0(targeted at an unapproved BoF= , overlap with I2RS)

draft-liu-netmod= -yang-abstract-topo-00=C2=A0(another topology model)

=C2=A0

I hope that reading some of the above (at least=C2= =A0draft-ietf-netmod-routi= ng-cfg-15) will start to inspire ideas and concrete discussion about what coordinatio= n between models and drafts is needed.

=C2=A0

Thanks,

Alia

=C2=A0

=C2=A0


--001a1139cc80e76c2605062229b4-- From nobody Fri Oct 24 05:07:21 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C81A8AA8 for ; Fri, 24 Oct 2014 05:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 s5JJS48I__oS for ; Fri, 24 Oct 2014 05:07:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0571A8A82 for ; Fri, 24 Oct 2014 05:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11454; q=dns/txt; s=iport; t=1414152433; x=1415362033; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=p6SVOXQ3XmPE/tB9gLr/FYJxKJEvVNI6yJP3gv7IWzM=; b=SmA2Z8rKhD32diPiDBelcYJH2aDCeTX4Xgqpnt3g5e15z/JgVjswmy3P ZzjHz/Z5kpDZ7lvdTYhrp0SzugS4AE2JuhzvfctIIgYN/WLwJlF5wu+j7 nDiOxDAkMmrl8K275J4Tujy23rE9Mw/VIaSmxEWRxyPdhv0KnbZj38qTi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAF9ASlStJV2R/2dsb2JhbABcgw5UWIMGyhkBCYdNAoELFgF9hAIBAQEDAQEBASBIAwoBBQsLDgoJFggDAgIJAwIBAgEVHxEGAQwBBQIBAYg0CQ20HJUAAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPdhEBUAeCd4FUBYtjimiHEoExg0mCcjuEc4UShACEGB0vgQ+BPAEBAQ X-IronPort-AV: E=Sophos; i="5.04,779,1406592000"; d="scan'208,217"; a="89972238" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 24 Oct 2014 12:07:12 +0000 Received: from [10.21.65.165] (sjc-vpn3-421.cisco.com [10.21.65.165]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9OC7BUR024535; Fri, 24 Oct 2014 12:07:11 GMT Message-ID: <544A40EF.8020709@cisco.com> Date: Fri, 24 Oct 2014 05:07:11 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alia Atlas , Dean Bogdanovic References: <54498528.7010200@cisco.com> <40D163CB-4F3D-468B-B045-180291A5FF68@juniper.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060401080406050002040708" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/7UyLFzHPXyMhe2KRQ8wsURjovfQ Cc: "Rtg-yang-coord@ietf.org" , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] opinions and reviews of draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:07:17 -0000 This is a multi-part message in MIME format. --------------060401080406050002040708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dean, Alia, Thanks for this. I have to admit that I lost track that v16 was required to address the routing directorate feedback. Sorry. Regards, Benoit > Dean, > > Thanks for the info. After I sent this email, I learned that the last > round of > comments still hadn't made it into a draft. > > Lada, I hope the delay is only a day or two... > > Alia > > On Thu, Oct 23, 2014 at 9:29 PM, Dean Bogdanovic > wrote: > > Benoit, Alia, > > There has been lot of discussion on and off the mailing list about > routing-cfg-15 draft. Lada should be posting v16 very, very soon. > > Dean > > On Oct 23, 2014, at 6:46 PM, Benoit Claise > > wrote: > >> Dear all, >> >> Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG >> publication state since 2014-05-25. >> So the fact that this draft is untouched since that date is not a >> bug, but a feature in this case. >> With the work done on the OSPF, ISIS, and BGP YANG models, this >> draft received some more expert reviews. >> Now, it's time to give actionable feedback on this document if >> it's unclear, broken, or unusable. >> I will not artificially hold this document forever. Alia and I >> are in line in terms of deadline: BEFORE the IETF please. >> >> Regards, Benoit >> >> >>> To make rapid progress on routing models, it is really important >>> to have a solid base routing model. Before the Routing Area >>> started working on YANG models, NETMOD adopted and has been >>> working on draft-ietf-netmod-routing-cfg-15 ( >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ). >>> >>> I would very strongly encourage you to read (or reread) and >>> comment on this draft BEFORE the upcoming IETF. Please send >>> your thoughts and concerns to both this mailing list and netmod. >>> >>> This is intended to be the basis for our routing models. >>> >>> The author and shepherd are quite understandably fatigued and >>> frustrated by last minute reviews so I'd really really like to >>> get them as much concrete feedback as soon as possible this time >>> since NETMOD is progressing this draft. >>> >>> I know it is not a short draft, but this is important. >>> >>> Thanks very much, >>> Alia >>> >>> P.S. I could supply chocolate rewards in Hawaii for anyone who >>> does a review - although probably not molded into fun Halloween >>> shapes. >>> >>> >>> >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > --------------060401080406050002040708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dean, Alia,

Thanks for this. I have to admit that I lost track that v16 was required to address the routing directorate feedback. Sorry.

Regards, Benoit

Dean,

Thanks for the info.  After I sent this email, I learned that the last round of
comments still hadn't made it into a draft.

Lada, I hope the delay is only a day or two...

Alia

On Thu, Oct 23, 2014 at 9:29 PM, Dean Bogdanovic <deanb@juniper.net> wrote:
Benoit, Alia,

There has been lot of discussion on and off the mailing list about routing-cfg-15 draft. Lada should be posting v16 very, very soon.

Dean

On Oct 23, 2014, at 6:46 PM, Benoit Claise <bclaise@cisco.com>
 wrote:

Dear all,

Let me stress that draft-ietf-netmod-routing-cfg-15 is in an IESG publication state since 2014-05-25.
So the fact that this draft is untouched since that date is not a bug, but a feature in this case.
With the work done on the OSPF, ISIS, and BGP YANG models, this draft received some more expert reviews.
Now, it's time to give actionable feedback on this document if it's unclear, broken, or unusable.
I will not artificially hold this document forever. Alia and I are in line in terms of deadline: BEFORE the IETF please.

Regards, Benoit


To make rapid progress on routing models, it is really important to have a solid base routing model.   Before the Routing Area started working on YANG models, NETMOD adopted and has been working on draft-ietf-netmod-routing-cfg-15 ( https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ ).

I would very strongly encourage you to read (or reread) and comment on this draft BEFORE the upcoming IETF.  Please send your thoughts and concerns to both this mailing list and netmod.

This is intended to be the basis for our routing models.

The author and shepherd are quite understandably fatigued and frustrated by last minute reviews so I'd really really like to get them as much concrete feedback as soon as possible this time since NETMOD is progressing this draft.

I know it is not a short draft, but this is important.

Thanks very much,
Alia

P.S.  I could supply chocolate rewards in Hawaii for anyone who does a review - although probably not molded into fun Halloween shapes.



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord



--------------060401080406050002040708-- From nobody Fri Oct 24 07:34:37 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BDA1A0070 for ; Fri, 24 Oct 2014 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5D3CcCftUoL1 for ; Fri, 24 Oct 2014 07:34:32 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ED81A0084 for ; Fri, 24 Oct 2014 07:34:32 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 8736a445.2b0e9ea30940.945840.00-2478.2662441.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 24 Oct 2014 14:34:32 +0000 (UTC) X-MXL-Hash: 544a637819f5f8e8-647a71bcc287fffcaf2562c41e413a3d3d0b5446 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e636a445.0.945727.00-2270.2662126.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 24 Oct 2014 14:34:22 +0000 (UTC) X-MXL-Hash: 544a636e601603f3-c32ea2ede62e9f789dc7830b3c53b3ec87fc281d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9OEYLAb011004; Fri, 24 Oct 2014 10:34:21 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9OEYF7G010930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Oct 2014 10:34:18 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 24 Oct 2014 14:33:59 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.237]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 10:33:58 -0400 From: "BRUNGARD, DEBORAH A" To: Alia Atlas , "Matt Hartley (mhartley)" Thread-Topic: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed Thread-Index: AQHP7zSFPTXoTJZzSEagn3nvG9jyxZw/UFjw Date: Fri, 24 Oct 2014 14:33:58 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC14AE9DE4@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.240] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8166D4A71MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=be/cppzB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=3T6DJ_suu6wA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=2tgTY_QcJpf] X-AnalysisOut: [UlIW0GP0A:9 a=QEXdDO2ut3YA:10 a=Q-S3ZxpXFpjEAviB:21 a=_FI7] X-AnalysisOut: [An3DvAnLPbUE:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=aLe8J9] X-AnalysisOut: [aEQQ9dHCYAGWkA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=iPL4quwxriOfyfSA:21 a=Zq3] X-AnalysisOut: [cZ1C6JCil0Jki:21 a=-gzsJ7ezRXVs5mCJ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/itCggNevaouBuls_kf0aaxI-xfU Cc: "Rtg-yang-coord@ietf.org" , "Benoit Claise \(bclaise\)" Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:34:35 -0000 --_000_F64C10EAA68C8044B33656FA214632C8166D4A71MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hdHQtDQpZZXMsIHRoaXMgc2hvdWxkIGZhbGwgdW5kZXIgY2NhbXAtDQoNCkRlYm9y YWgNCihDby1jaGFpciBDQ0FNUCkNCg0KDQpGcm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0 Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMywgMjAxNCAxMDo0NSBQTQ0KVG86IE1hdHQgSGFydGxl eSAobWhhcnRsZXkpDQpDYzogUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2Ug KGJjbGFpc2UpDQpTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBWZXJ5IGFjdGl2ZSBkaXNj dXNzaW9uIGFuZCBjb29yZGluYXRpb24gb2YgWUFORyBtb2RlbHMgaXMgbmVlZGVkDQoNCkhpIE1h dHQsDQoNClRoYW5rcy4gIEkgZ3Vlc3MgdGhhdCBtaWdodCBmYWxsIHVuZGVyIENDQU1QLiAgIE5v dCBjbG9zZWx5IGZvbGxvd2luZyBDQ0FNUCwgSSB3YXNuJ3Qgc3VyZSBpZiBpdCB3YXMgd2VsbCBj b25uZWN0ZWQuDQoNCkFsaWENCg0KT24gVGh1LCBPY3QgMjMsIDIwMTQgYXQgMTA6MDQgUE0sIE1h dHQgSGFydGxleSAobWhhcnRsZXkpIDxtaGFydGxleUBjaXNjby5jb208bWFpbHRvOm1oYXJ0bGV5 QGNpc2NvLmNvbT4+IHdyb3RlOg0KQWxpYSwNCg0KZHJhZnQtZGhhcmluaS1uZXRtb2QtZy02OTgt Mi15YW5nLTAwIHNob3VsZCBwcm9iYWJseSBnbyBvbiB0aGUgbGlzdC4NCg0KQ2hlZXJzDQoNCk1h dHQNCg0KDQpGaXJzdCwgSSBhbSBhYnNvbHV0ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3ZlciB0aGF0 IHRoaXMgY29vcmRpbmF0aW9uIGxpc3QgaGFzIDEzOSBzdWJzY3JpYmVycyEgIEkgYW0gcXVpdGUg ZW5jb3VyYWdlZCB0aGF0IHdlIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhpcyBtYWlsaW5nIGxpc3Qg Zm9yIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiBhbmQgY29vcmRpbmF0aW9uLiAgV2VsY29tZSBhbmQg cGxlYXNlIHN0YXJ0IHRhbGtpbmchDQoNClRvd2FyZHMgdGhhdCBwdXJwb3NlLi4uDQoNCldpdGgg YSBmZXcgV0cgZHJhZnRzIGFuZCBvdmVyIDIwIGluZGl2aWR1YWwgZHJhZnRzIHRoYXQgbWF5IG92 ZXJsYXAgYW5kIHNob3VsZCBzaGFyZSBzb21lIGNvbW1vbiBhYnN0cmFjdGlvbnMgYW5kIGdyb3Vw aW5ncywgd2UgcmVhbGx5IG5lZWQgdG8gc3RhcnQgY29vcmRpbmF0aW5nLiAgIFRoaXMgaXMgYSBz aWduaWZpY2FudCBleHBsb3Npb24gb2YgZHJhZnRzIGFuZCBpbnRlcmVzdCBpbiB0aGUgbGFzdCA5 IG1vbnRocyAtIGFuZCB3ZSBhcmUgaW50ZXJhY3RpbmcsIGF0IGxlYXN0IGluIHBhcnQsIHdpdGgg YSBjb21tdW5pdHkgdGhhdCBORUVEUyBzdGFuZGFyZGl6YXRpb24gdG8gaGFwcGVuIG11Y2ggbW9y ZSBxdWlja2x5Lg0KDQpBZHJpYW4sIEJlbm9pdCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRp bmcgdXAgYSBqb2IgZGVzY3JpcHRpb24gZm9yIGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlz IG1haWxpbmcgbGlzdCBhbmQgdGhlIGNvb3JkaW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNl c3NhcnkuICBOZWVkbGVzcyB0byBzYXksIGlmIHlvdSB3b3VsZCBhbHJlYWR5IGxpa2UgdG8gdm9s dW50ZWVyLCBwbGVhc2UgZW1haWwgbWUgd2l0aCBkZXRhaWxzLg0KDQpUbyBhaWQgaW4gZmluZGlu ZyB0aGUgdmFyaW91cyBZQU5HIG1vZGVscyB0aGF0IHJlbGF0ZSB0byByb3V0aW5nIGluIHNvbWUg d2F5LCBJJ3ZlIGluY2x1ZGVkIGEgbGlzdCBiZWxvdy4gIFRoaXMgbGlzdCB3YXMgZ2VuZXJhdGVk IGJ5IGxvb2tpbmcgdGhyb3VnaCBhIHNlYXJjaCBvZiBkcmFmdHMgYmFzZWQgb24gdGhlIGtleXdv cmQgWUFORyBwbHVzIGEgY291cGxlIEkyUlMgZHJhZnRzIEkgd2FzIGFscmVhZHkgZmFtaWxpYXIg d2l0aC4gIEkgYXBvbG9naXplIGlmIEkgbWlzc2VkIGFueSAoYW5kIGVuY291cmFnZSBjb25zaXN0 ZW50IG5hbWluZyApLg0KDQpkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+ DQpkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy8+DQpkcmFmdC1pZXRmLWky cnMtcmliLWluZm8tbW9kZWwtMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVsLz4gKFlBTkcgbW9kZWwgY29taW5nIHZlcnkgc29v bikNCg0KZHJhZnQtYm9nZGFub3ZpYy1uZXRtb2QtYWNsLW1vZGVsLTAyPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8+ICht b3JlIGdlbmVyYWwgdGhhbiByb3V0aW5nLCBzbyBjdXJyZW50bHkgcHJvZ3Jlc3NpbmcgaW4gTkVU TU9EKQ0KZHJhZnQtY2hlbi1tcGxzLWxkcC15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtbGRwLXlhbmctY2ZnLz4NCmRyYWZ0LWNoZW4t bXBscy10ZS15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1jaGVuLW1wbHMtdGUteWFuZy1jZmcvPg0KZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmst dG9wby0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jbGVtbS1pMnJz LXlhbmctbmV0d29yay10b3BvLz4NCmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10 b3BvLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1z dXBhLXlhbmctbmV0d29yay10b3BvLz4gKHRhcmdldGVkIGF0IGFuIHVuYXBwcm92ZWQgQm9GLCBv dmVybGFwIHdpdGggSTJSUykNCmRyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAw PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaTJycy1sMi1uZXR3 b3JrLXRvcG9sb2d5Lz4NCmRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDA8aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2Rl bC8+DQpkcmFmdC1oYW8tdHJpbGwteWFuZy0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oYW8tdHJpbGwteWFuZy8+IChtYXkgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lk ZXIgZnJvbSB0aGUgSVNJUyBvdmVybGFwKQ0KZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0tMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0vPg0K ZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8tMDA8aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8vPiAoYW5v dGhlciB0b3BvbG9neSBtb2RlbCkNCmRyYWZ0LWxpdS1waW0taWdtcC1tbGQteWFuZy0wMDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmcv Pg0KZHJhZnQtbGl1LXBpbS15YW5nLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxpdS1waW0teWFuZy8+DQpkcmFmdC1wZW5uby1zZmMteWFuZy0wODxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1zZmMteWFuZy8+DQpkcmFmdC1wa2Qt cGNlLXBjZXAteWFuZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1w a2QtcGNlLXBjZXAteWFuZy8+DQpkcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLTAwPGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vPg0KZHJh ZnQtd2FuZy1pMnJzLWlzaXMtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0vPg0KZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0tMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vPg0K ZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2VsZXRpb24tMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2VsZXRpb24vPg0KZHJhZnQteWV1 bmctbmV0bW9kLW9zcGYtMDI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt eWV1bmctbmV0bW9kLW9zcGYvPg0KZHJhZnQtemhhbmctbXBscy10cC15YW5nLW9hbS0wMDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2Ft Lz4NCmRyYWZ0LXpoYW5nLW52bzMteWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtemhhbmctbnZvMy15YW5nLWNmZy8+DQpkcmFmdC16aGRhbmtpbi1uZXRt b2QtYmdwLWNmZy0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGRh bmtpbi1uZXRtb2QtYmdwLWNmZy8+DQpkcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy0w MDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctbDJ2cG4tZXZw bi15YW5nLWNmZy8+DQpkcmFmdC16aHVhbmctbDJ2cG4teWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLz4NCmRyYWZ0 LXpodWFuZy1sM3Zwbi15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC16aHVhbmctbDN2cG4teWFuZy1jZmcvPg0KDQpJIGhvcGUgdGhhdCByZWFkaW5nIHNv bWUgb2YgdGhlIGFib3ZlIChhdCBsZWFzdCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0x NTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0 aW5nLWNmZy8+KSB3aWxsIHN0YXJ0IHRvIGluc3BpcmUgaWRlYXMgYW5kIGNvbmNyZXRlIGRpc2N1 c3Npb24gYWJvdXQgd2hhdCBjb29yZGluYXRpb24gYmV0d2VlbiBtb2RlbHMgYW5kIGRyYWZ0cyBp cyBuZWVkZWQuDQoNClRoYW5rcywNCkFsaWENCg0KDQoNCg== --_000_F64C10EAA68C8044B33656FA214632C8166D4A71MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6 MiA1IDYgNCA1IDUgNSAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBN YXR0LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoaXMgc2hvdWxkIGZhbGwg dW5kZXIgY2NhbXAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWJvcmFoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPihDby1jaGFpciBDQ0FNUCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSdGcteWFuZy1jb29y ZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFsaWEgQXRsYXM8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMjMs IDIwMTQgMTA6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hdHQgSGFydGxleSAobWhhcnRsZXkpPGJy Pg0KPGI+Q2M6PC9iPiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZzsgQmVub2l0IENsYWlzZSAoYmNs YWlzZSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdGcteWFuZy1jb29yZF0gVmVyeSBhY3Rp dmUgZGlzY3Vzc2lvbiBhbmQgY29vcmRpbmF0aW9uIG9mIFlBTkcgbW9kZWxzIGlzIG5lZWRlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1hdHQsPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuJm5ic3A7IEkgZ3Vlc3Mg dGhhdCBtaWdodCBmYWxsIHVuZGVyIENDQU1QLiAmbmJzcDsgTm90IGNsb3NlbHkgZm9sbG93aW5n IENDQU1QLCBJIHdhc24ndCBzdXJlIGlmIGl0IHdhcyB3ZWxsIGNvbm5lY3RlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9j dCAyMywgMjAxNCBhdCAxMDowNCBQTSwgTWF0dCBIYXJ0bGV5IChtaGFydGxleSkgJmx0OzxhIGhy ZWY9Im1haWx0bzptaGFydGxleUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5taGFydGxleUBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojNjMyNDIzIj5BbGlhLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9v a21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHls ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5kcmFmdC1kaGFyaW5pLW5l dG1vZC1nLTY5OC0yLXlhbmctMDAgc2hvdWxkIHByb2JhYmx5IGdvIG9uIHRoZSBsaXN0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjojNjMyNDIzIj5DaGVlcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2 MzI0MjMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5NYXR0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYz MjQyMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5GaXJzdCwgSSBhbSBhYnNvbHV0ZWx5IGRlbGlnaHRlZCB0 byBkaXNjb3ZlciB0aGF0IHRoaXMgY29vcmRpbmF0aW9uIGxpc3QgaGFzIDEzOSBzdWJzY3JpYmVy cyEmbmJzcDsgSSBhbSBxdWl0ZSBlbmNvdXJhZ2VkIHRoYXQgd2Ugd2lsbCBiZSBhYmxlIHRvIHVz ZSB0aGlzIG1haWxpbmcgbGlzdCBmb3IgbWVhbmluZ2Z1bA0KIGRpc2N1c3Npb24gYW5kIGNvb3Jk aW5hdGlvbi4mbmJzcDsgV2VsY29tZSBhbmQgcGxlYXNlIHN0YXJ0IHRhbGtpbmchPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG93YXJkcyB0aGF0IHB1 cnBvc2UuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5XaXRoIGEgZmV3IFdHIGRyYWZ0cyBhbmQgb3ZlciAyMCBpbmRpdmlk dWFsIGRyYWZ0cyB0aGF0IG1heSBvdmVybGFwIGFuZCBzaG91bGQgc2hhcmUgc29tZSBjb21tb24g YWJzdHJhY3Rpb25zIGFuZCBncm91cGluZ3MsIHdlIHJlYWxseSBuZWVkIHRvIHN0YXJ0IGNvb3Jk aW5hdGluZy4gJm5ic3A7IFRoaXMgaXMgYSBzaWduaWZpY2FudA0KIGV4cGxvc2lvbiBvZiBkcmFm dHMgYW5kIGludGVyZXN0IGluIHRoZSBsYXN0IDkgbW9udGhzIC0gYW5kIHdlIGFyZSBpbnRlcmFj dGluZywgYXQgbGVhc3QgaW4gcGFydCwgd2l0aCBhIGNvbW11bml0eSB0aGF0IE5FRURTIHN0YW5k YXJkaXphdGlvbiB0byBoYXBwZW4gbXVjaCBtb3JlIHF1aWNrbHkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFkcmlhbiwg QmVub2l0LCBhbmQgSSBhcmUgcGxhbm5pbmcgb24gd3JpdGluZyB1cCBhIGpvYiBkZXNjcmlwdGlv biBmb3IgYSBzZWNyZXRhcnkgdG8gaGVscCB3aXRoIHRoaXMgbWFpbGluZyBsaXN0IGFuZCB0aGUg Y29vcmRpbmF0aW9uIGFuZCBjb21tdW5pY2F0aW9uIG5lY2Vzc2FyeS4mbmJzcDsgTmVlZGxlc3Mg dG8NCiBzYXksIGlmIHlvdSB3b3VsZCBhbHJlYWR5IGxpa2UgdG8gdm9sdW50ZWVyLCBwbGVhc2Ug ZW1haWwgbWUgd2l0aCBkZXRhaWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGFpZCBpbiBmaW5kaW5nIHRoZSB2YXJp b3VzIFlBTkcgbW9kZWxzIHRoYXQgcmVsYXRlIHRvIHJvdXRpbmcgaW4gc29tZSB3YXksIEkndmUg aW5jbHVkZWQgYSBsaXN0IGJlbG93LiZuYnNwOyBUaGlzIGxpc3Qgd2FzIGdlbmVyYXRlZCBieSBs b29raW5nIHRocm91Z2ggYSBzZWFyY2ggb2YgZHJhZnRzIGJhc2VkIG9uDQogdGhlIGtleXdvcmQg WUFORyBwbHVzIGEgY291cGxlIEkyUlMgZHJhZnRzIEkgd2FzIGFscmVhZHkgZmFtaWxpYXIgd2l0 aC4mbmJzcDsgSSBhcG9sb2dpemUgaWYgSSBtaXNzZWQgYW55IChhbmQgZW5jb3VyYWdlIGNvbnNp c3RlbnQgbmFtaW5nICkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtaWV0Zi1uZXRtb2Qt cm91dGluZy1jZmctMTU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy8iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtaWV0Zi1p c2lzLXlhbmctaXNpcy1jZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcmliLWluZm8tbW9kZWwvIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0 LWlldGYtaTJycy1yaWItaW5mby1tb2RlbC0wMzwvc3Bhbj48L2E+Jm5ic3A7KFlBTkcNCiBtb2Rl bCBjb21pbmcgdmVyeSBzb29uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtYm9nZGFub3ZpYy1uZXRtb2QtYWNsLW1vZGVsLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1ib2dk YW5vdmljLW5ldG1vZC1hY2wtbW9kZWwtMDI8L3NwYW4+PC9hPiZuYnNwOyhtb3JlDQogZ2VuZXJh bCB0aGFuIHJvdXRpbmcsIHNvIGN1cnJlbnRseSBwcm9ncmVzc2luZyBpbiBORVRNT0QpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tbXBscy1sZHAteWFu Zy1jZmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQt Y2hlbi1tcGxzLWxkcC15YW5nLWNmZy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJh ZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmstdG9wby8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1jbGVtbS1p MnJzLXlhbmctbmV0d29yay10b3BvLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8v IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtY29udHJl cmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8tMDA8L3NwYW4+PC9hPiZuYnNwOyh0YXJnZXRlZA0K IGF0IGFuIHVuYXBwcm92ZWQgQm9GLCBvdmVybGFwIHdpdGggSTJSUyk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9uZy1pMnJzLWwyLW5ldHdvcmstdG9wb2xv Z3kvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtZG9u Zy1pMnJzLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURG NUZGIj5kcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFvLXRyaWxsLXlhbmcvIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaGFvLXRyaWxs LXlhbmctMDE8L3NwYW4+PC9hPiZuYnNwOyhtYXkNCiBiZSBpbnRlcmVzdGluZyB0byBjb25zaWRl ciBmcm9tIHRoZSBJU0lTIG92ZXJsYXApPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWhhcmVzLWkycnMtYmdwLWRtLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWhhcmVzLWkycnMtYmdwLWRtLTAwPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldG1vZC15 YW5nLWFic3RyYWN0LXRvcG8vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+ZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8tMDA8L3NwYW4+PC9hPiZu YnNwOyhhbm90aGVyDQogdG9wb2xvZ3kgbW9kZWwpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1waW0taWdtcC1tbGQteWFuZy8iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtbGl1 LXBpbS1pZ21wLW1sZC15YW5nLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXBpbS15YW5nLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWxpdS1waW0teWFuZy0wMDwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbm5vLXNmYy15YW5n LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXBlbm5v LXNmYy15YW5nLTA4PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcGtkLXBjZS1wY2VwLXlhbmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXBrZC1wY2UtcGNlcC15 YW5nLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdGlzc2EtbnZvMy15YW5nLW9hbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLTAwPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLWlzaXMt ZG0vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5k OiNFREY1RkYiPmRyYWZ0LXdhbmctaTJycy1pc2lzLWRtLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtd2FuZy1pMnJz LW9zcGYtZG0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC15YW5nLXRyaWxsLXBhcmVudC1zZWxldGlvbi8iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQteWFuZy10 cmlsbC1wYXJlbnQtc2VsZXRpb24tMDM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC15ZXVuZy1uZXRtb2Qtb3NwZi8iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQteWV1 bmctbmV0bW9kLW9zcGYtMDI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC16aGFu Zy1tcGxzLXRwLXlhbmctb2FtLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctbnZvMy15YW5nLWNmZy8iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC16aGFuZy1udm8zLXlhbmctY2ZnLTAw PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emhkYW5raW4tbmV0bW9kLWJncC1jZmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXpoZGFua2luLW5ldG1vZC1iZ3At Y2ZnLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtemh1YW5nLWwydnBuLWV2cG4teWFuZy1jZmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXpodWFuZy1sMnZw bi1ldnBuLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXpodWFuZy1sMnZwbi15YW5nLWNmZy0w MDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXpodWFuZy1sM3Zwbi15YW5nLWNmZy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtemh1YW5nLWwzdnBuLXlhbmctY2Zn LTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgaG9wZSB0aGF0IHJlYWRpbmcgc29tZSBvZiB0aGUgYWJvdmUgKGF0 IGxlYXN0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWlldGYtbmV0bW9kLXJvdXRp bmctY2ZnLTE1PC9zcGFuPjwvYT4pDQogd2lsbCBzdGFydCB0byBpbnNwaXJlIGlkZWFzIGFuZCBj b25jcmV0ZSBkaXNjdXNzaW9uIGFib3V0IHdoYXQgY29vcmRpbmF0aW9uIGJldHdlZW4gbW9kZWxz IGFuZCBkcmFmdHMgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F64C10EAA68C8044B33656FA214632C8166D4A71MISOUT7MSGUSRDE_-- From nobody Fri Oct 24 07:46:11 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF91A6F04; Wed, 22 Oct 2014 14:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 j0gRNAxPSehS; Wed, 22 Oct 2014 14:34:23 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367621A6F11; Wed, 22 Oct 2014 14:34:21 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s9ML2g0r030102; Wed, 22 Oct 2014 14:34:17 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1q5v85kcj2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Oct 2014 14:34:17 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.49) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 22 Oct 2014 15:34:04 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.49]) by brm-excashub-2.corp.brocade.com ([172.16.187.74]) with mapi; Wed, 22 Oct 2014 15:34:01 -0600 From: Kiran Agrahara Sreenivasa To: Benoit Claise , Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" Date: Wed, 22 Oct 2014 15:34:00 -0600 Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: Ac/uPHDV6VmzCUSZRhi/QwwN5ARvRwAAyEXA Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> In-Reply-To: <54481CE8.808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-22_07:2014-10-22,2014-10-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410220190 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/VGVWm1bNVDMUL189IVLAbVQYSPQ X-Mailman-Approved-At: Fri, 24 Oct 2014 07:46:09 -0700 Cc: "Rtg-yang-coord@ietf.org" , 'NETMOD Working Group' , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , 'Farrel Adrian' Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:34:29 -0000 --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" +1 -OSPF + ISIS + TE YANG model authors were waiting for this opportunity to discuss the open issues and present an update. Many of those even logged in to the meeting before I had to begrudgingly announce cancelation :( From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, October 22, 2014 4:09 PM To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman' Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Dear all, Tom: Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF. I'm glad we've got the rtg-yang-coord list to sort out these issues. IDR will pick up all BGP related yang modules. A charter addition has been made. IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. Exactly. The YANG modules should be standardized in the respective WGs. To have good YANG modules, you need: 1. the technology experts, i.e. the respective WG 2. YANG review I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG". We want to do what's right by providing YANG review of the documents, nothing else. I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal. Regards, Benoit The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements. IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs. If you could suggest a few netmod people to help this effort it would help. My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 10:35 AM To: Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc... Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_-- From nobody Fri Oct 24 12:34:40 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D31A1AEE; Fri, 24 Oct 2014 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pPwVRS4JjxaI; Fri, 24 Oct 2014 12:34:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBC01A03C7; Fri, 24 Oct 2014 12:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4644; q=dns/txt; s=iport; t=1414179276; x=1415388876; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C5aIYC9F23WW7Q+BrtqUyYBnKUxR7KYsWghgbFDOzgA=; b=Q8AyufDWN37sRA/QWiYT60gR1L/EmDPUaEJVKkLZwGj4wM/Po42dNjh0 wcF24BTSRqUU68pXMonAPXa/x2G901ClB8Fklyu5pi5XvEj0MTUfS7Rwz zIpJxIpnyW3KXUJKq8a9GMc+rLpWBOy/GCF1ZX+fqXWsx9j66jRBFbjdm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIMAMqoSlStJV2P/2dsb2JhbABcgw5UUwUEgwLKLYdLAhttFgF9BIN+AQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQBDQUIARKIJggFthSVCgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI57DyIHBoJxNoEeBZIFhEaIQzyDDZEygjSBRGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,781,1406592000"; d="scan'208";a="366450867" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2014 19:34:35 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9OJYZYD002351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 19:34:35 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 14:34:35 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-voit-netmod-peer-mount-requirements-01.txt Thread-Index: AQHP775gVnjO1X3jmkOoWhWQAQ2mfJw/nilQ Date: Fri, 24 Oct 2014 19:34:34 +0000 Message-ID: References: <20141024191151.7453.42820.idtracker@ietfa.amsl.com> In-Reply-To: <20141024191151.7453.42820.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hO4PtMjW0CfmlK68StuMt6uQuNc Cc: Spiros Motsenigos , Angelo Corsaro , "Sander Mertens \(sander.mertens8@gmail.com\)" Subject: [Rtg-yang-coord] FW: New Version Notification for draft-voit-netmod-peer-mount-requirements-01.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:34:38 -0000 QSBuZXcgdmVyc2lvbiBvZiAiUGVlciBNb3VudCBSZXF1aXJlbWVudHMiIGhhcyBiZWVuIHVwbG9h ZGVkLiAgDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5l dG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMS50eHQgDQoNCktleSBjaGFuZ2VzIGluY2x1 ZGU6DQoNCkFkZGl0aW9uYWwgQXV0aG9yOiANCiAgICAgU2FuZGVyIE1lcnRlbnMgZnJvbSBQcmlz bXRlY2gNCg0KTmV3IENvbnRlbnQ6DQogICAgIDUuNC4gIE1vdW50IEZpbHRlciANCiAgICAgNS41 LiAgQXV0by1OZWdvdGlhdGlvbiBvZiBQZWVyIE1vdW50IENsaWVudCBRb1MgDQogICAgIDUuNi4g IERhdGFzdG9yZSBRdWFsaWZpY2F0aW9uDQogICAgIDUuNy4gIExvY2FsIE1vdW50aW5nDQogICAg IDUuOC4gIE1vdW50IENhc2NhZGVzIA0KICAgICA1LjExLiBIaWdoIEF2YWlsYWJpbGl0eSANCiAg ICAgICA1LjExLjEuICBSZWxpYWJpbGl0eSAgDQogICAgICAgNS4xMS4yLiAgQWxpZ25tZW50IHRv IGxhdGUgam9pbmluZyBwZWVycyAgDQogICAgICAgNS4xMS4zLiAgTGl2ZWxpbmVzcyANCiAgICAg ICA1LjExLjQuICBNZXJnaW5nIG9mIGRhdGFzZXRzICANCiAgICAgICA1LjExLjUuICBEaXN0cmli dXRlZCBNb3VudCBTZXJ2ZXJzIA0KDQpFeHBlY3QgdHdvIGFkZGl0aW9uYWwgZHJhZnRzIGluIHRo aXMgYXJlYSB0byBiZSBzdWJtaXR0ZWQgYmVmb3JlIGNsb3NlIG9mIGJ1c2luZXNzIE1vbmRheToN CiAgKDEpICBDbG91ZCBTTEEgWUFORyBNb2RlbCBpbmNvcnBvcmF0aW5nIFBlZXIgTW91bnQgU2Vt YW50aWNzIChBLiBUcmlwYXRoeSBldCBhbC4pDQogICgyKSAgU3Vic2NyaWJpbmcgdG8gWUFORyBk YXRhc3RvcmUgcHVzaCB1cGRhdGVzIChBLiBDbGVtbSBldCBhbC4pDQoNClRoYW5rcyENCkVyaWMN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9j dG9iZXIgMjQsIDIwMTQgMzoxMiBQTQ0KVG86IFNhbmRlciBNZXJ0ZW5zOyBBbGV4YW5kZXIgQ2xl bW0gKGFsZXgpOyBFcmljIFZvaXQgKGV2b2l0KTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJp YyBWb2l0IChldm9pdCk7IFNhbmRlciBNZXJ0ZW5zDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAx LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v dW50LXJlcXVpcmVtZW50cy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgRXJpYyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzDQpSZXZpc2lvbjoJMDEN ClRpdGxlOgkJUmVxdWlyZW1lbnRzIGZvciBQZWVyIE1vdW50aW5nIG9mIFlBTkcgc3VidHJlZXMg ZnJvbSBSZW1vdGUgRGF0YXN0b3Jlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0xMC0yNA0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjQNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v dW50LXJlcXVpcmVtZW50cy0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50 cy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12b2l0 LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQt cmVxdWlyZW1lbnRzLTAxDQoNCkFic3RyYWN0Og0KICAgTmV0d29yayBpbnRlZ3JhdGVkIGFwcGxp Y2F0aW9ucyB3YW50IHNpbXBsZSB3YXlzIHRvIGFjY2VzcyBZQU5HDQogICBvYmplY3RzIGFuZCBz dWJ0cmVlcyB3aGljaCBtaWdodCBiZSBkaXN0cmlidXRlZCBhY3Jvc3MgbmV0d29yay4NCiAgIFBl cmZvcm1hbmNlIHJlcXVpcmVtZW50cyBtYXkgZGljdGF0ZSB0aGF0IGl0IGlzIHVuYWZmb3JkYWJs ZSBmb3IgYQ0KICAgc3Vic2V0IG9mIHRoZXNlIGFwcGxpY2F0aW9ucyB0byBnbyB0aHJvdWdoIGV4 aXN0aW5nIGNlbnRyYWxpemVkDQogICBtYW5hZ2VtZW50IGJyb2tlcnMuICBGb3Igc3VjaCBhcHBs aWNhdGlvbnMsIGRldmVsb3BtZW50IGNvbXBsZXhpdHkNCiAgIG11c3QgYmUgbWluaW1pemVkLiAg U3BlY2lmaWMgYXNwZWN0cyBvZiBjb21wbGV4aXR5IGRldmVsb3BlcnMgd2FudCB0bw0KICAgaWdu b3JlIGluY2x1ZGU6DQoNCiAgIG8gIHdoZXRoZXIgYXV0aG9yaXRhdGl2ZSBpbmZvcm1hdGlvbiBp cyBhY3R1YWxseSBzb3VyY2VkIGZyb20gcmVtb3RlDQogICAgICBkYXRhc3RvcmVzIChhcyB3ZWxs IGFzIGhvdyB0byBnZXQgdG8gdGhvc2UgZGF0YXN0b3JlcyksDQoNCiAgIG8gIHdoZXRoZXIgc3Vj aCBpbmZvcm1hdGlvbiBoYXMgYmVlbiBsb2NhbGx5IGNhY2hlZCBvciBub3QsDQoNCiAgIG8gIHdo ZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3IgbW9yZSBjb250cm9sbGVycyBhc3NlcnRpbmcN CiAgICAgIG93bmVyc2hpcCBvZiBpbmZvcm1hdGlvbiwgYW5kDQoNCiAgIG8gIHdoZXRoZXIgdGhl cmUgYXJlIGludGVyYWN0aW9ucyB3aXRoIG90aGVyIGFwcGxpY2F0aW9ucw0KICAgICAgY29uY3Vy cmVudGx5IHJ1bm5pbmcgZWxzZXdoZXJlDQoNCiAgIFRoZSBzb2x1dGlvbiByZXF1aXJlbWVudHMg ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgZGV0YWlsIHdoYXQgaXMNCiAgIG5lZWRlZCB0byBz dXBwb3J0IGFwcGxpY2F0aW9uIGFjY2VzcyB0byBhdXRob3JpdGF0aXZlIG5ldHdvcmsgWUFORw0K ICAgb2JqZWN0cyBmcm9tIGNvbnRyb2xsZXJzIChzdGFyKSBvciBwZWVyaW5nIG5ldHdvcmsgZGV2 aWNlcyAobWVzaCkgaW4NCiAgIHN1Y2ggYSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Oct 26 03:14:38 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8F61A7028; Sun, 26 Oct 2014 03:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 x0DrP5LAZx3q; Sun, 26 Oct 2014 03:14:30 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0991A7021; Sun, 26 Oct 2014 03:14:30 -0700 (PDT) Received: from [192.168.0.129] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BC383180131A; Sun, 26 Oct 2014 11:14:28 +0100 (CET) Message-ID: <544CC985.9060808@pi.nu> Date: Sun, 26 Oct 2014 11:14:29 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lime@ietf.org, Rtg-yang-coord@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/_l66HUbtPiQV_9vtR-8iAkXbA0o Subject: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 10:14:33 -0000 Folks, I have what I hope is a simple question, and that it will only reveal that I'm not up to speed on yang. I trying to figure out the relationship between the generic yang models in e.g. draft-tissa-lime-yang-oam-model and the specific models we do for different variants of e.g. mpls oam. I guess we have a structure more or less like this mpls | |- ldp | |-ldp oam | |- rsvp-te | | | |- rsvp-te oam | |- lsp ping | | | |- lsp ping oam | |- etc Where does the generic work fit in? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Oct 26 11:50:41 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC681A0393; Sun, 26 Oct 2014 11:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 yRwgmXtNvCQk; Sun, 26 Oct 2014 11:50:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F60B1A0395; Sun, 26 Oct 2014 11:50:34 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-5b-544cea9cad5e Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.7F.05330.C9AEC445; Sun, 26 Oct 2014 13:35:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Sun, 26 Oct 2014 14:50:32 -0400 From: Gregory Mirsky To: Loa Andersson , "lime@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8QWoq6L8YEpRpUWvu3QGOKSPx5xCtlHQ Date: Sun, 26 Oct 2014 18:50:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> References: <544CC985.9060808@pi.nu> In-Reply-To: <544CC985.9060808@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPuO7cVz4hBq/uc1p0bNvOZPFv7hxm i1tLV7Ja/H5+m9mBxWPJkp9MHrOmt7EFMEVx2aSk5mSWpRbp2yVwZdxb0ctUcIqn4lz3ddYG xsOcXYycHBICJhLHTy9jgrDFJC7cW8/WxcjFISRwhFHi0IX37BDOckaJHw+vMYJUsQkYSbzY 2MMOYosIlErsm70MKM7BwSygLHHqrgxIWFjAUqLjxS2oEiuJJz9+sYGUiAC1zmsMAgmzCKhK POw6CbaXV8BX4nvXVrDpQgIqEtvOTGEFsTmBahatucMCYjMC3fb91BqwemYBcYlbT+ZD3Swg sWTPeWYIW1Ti5eN/rBC2ksTH3/PZIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyipGjtDi1LDfdyGATIzBujkmw6e5g3PPS8hCjAAejEg/vglCfECHWxLLi ytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPQqWexjOH2egdjx/3Je axjOHLWtnt7r+/Xkkrcf3Y5UZmuoW8okbpt39vfPrTd0fARUlVSjV+hXKE57t7Ux7IxH5cpJ Nawui7bOr5gb+JHvxsGMMFaGZ5fSOLJut6qtWJrLOtOzVJeN61HJSSdFqQkbtm6SONDmdEZ2 hvXerN1hQXPzdTu/zlBiKc5INNRiLipOBAChqlCkfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/_imci2z2AynfesOj5M1cQuXn610 Cc: "mpls@ietf.org" Subject: Re: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 18:50:38 -0000 Hi Loa, I think that your question is not simple at all and it would be a great to = discuss how Generic OAM proposal is related to MPLS OAM at the meeting. Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment = Routing (as far as transport layer for the latter two) OAMs but one MPLS OA= M with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing ne= tworks. Regards, Greg -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Loa Andersson Sent: Sunday, October 26, 2014 3:14 AM To: lime@ietf.org; Rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] hopefully a simple question Folks, I have what I hope is a simple question, and that it will only reveal that = I'm not up to speed on yang. I trying to figure out the relationship between the generic yang models in = e.g. draft-tissa-lime-yang-oam-model and the specific models we do for diff= erent variants of e.g. mpls oam. I guess we have a structure more or less like this mpls | |- ldp | |-ldp oam | |- rsvp-te | | | |- rsvp-te oam | |- lsp ping | | | |- lsp ping oam | |- etc Where does the generic work fit in? /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Oct 26 17:03:33 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E781A1B58 for ; Sun, 26 Oct 2014 17:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 zhcnOmuuEXDr for ; Sun, 26 Oct 2014 17:03:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACB11A1B5C for ; Sun, 26 Oct 2014 17:03:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03R16001990 for ; Mon, 27 Oct 2014 00:03:27 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03OgP001928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Oct 2014 00:03:26 GMT From: "Adrian Farrel" To: Date: Mon, 27 Oct 2014 00:03:20 -0000 Message-ID: <000101cff179$6d206490$47612db0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/xeQvZKxlU/WSIRVyYIB7MBMYM8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21056.003 X-TM-AS-Result: No--5.695-10.0-31-10 X-imss-scan-details: No--5.695-10.0-31-10 X-TMASE-MatchedRID: AOy2RPAu084Qb791g8/jtWjZ8q/Oc1nAH181YDtIVaoa1EOwPTK5hnFD 0I0jlEDdYPXdrx70Pm8k5h2xCdJzXW5LiqhZETo65gCHftmwEMK3dp6DuD+6wC62hjZS0WoYS9U 7sRxCp1smYuoq7bKp2SFyczyoJ0Rq94K/U9yoT94Is18ZTh19+BkqnRJng/5155TSoW/nwH5fFG 0p9UU3wwtk089GL6lLHC+f4y2ZHKuCr6IW6BjKiw6uUGRBr2oWVCOR9lsD5g8R34ro7k23nREXW gyXQw/xnK6NH0kJeVpPgpGv/PbptzB7AhAesYcjqUSkXJTN1/N1k+gP1XamtK8Jn6QfJT48pwp7 1wW2N27i8zVgXoAltlwtzewu2M63VkVZa47CjvDdB/CxWTRRu+rAZ8KTspSz9msyYixXdR4OTku Dh5R1zZUhooaI1vpGDPtttEx0jcKdkMEKMp5RA6jrJnOkfaSIVmrKCdkbbH16VoXd8lTvJqRHQI MmEw8Ekc8vZYcPwmShurVaY1hyX4xdVwkeE3a3UyOqrFz2uoh+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/AOHpaOxHyKfuuP8Gy-HGPHgdtIg Subject: [Rtg-yang-coord] New version of draft-ietf-netmod-routing-cfg X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:03:32 -0000 Hi, The author has updated this draft with comments received in various reviews and discussion. Since this is the cornerstone for all other RTG YANG modules, and since the document is "mature", now would be a very good time to do a review. Your comments should be sent to the netmod mailing list to ensure that they are properly captured and actions. Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 26 October 2014 15:29 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: I-D Action: draft-ietf-netmod-routing-cfg-16.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working > Group of the IETF. > > Title : A YANG Data Model for Routing Management > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-16.txt > Pages : 88 > Date : 2014-10-26 > > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for routing protocols and other > functions. The core routing data model provides common building > blocks for such extensions - routing instances, routes, routing > information bases (RIB), routing protocols and route filters. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Oct 26 17:03:42 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC941A1B5A; Sun, 26 Oct 2014 17:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 enWJQctSstET; Sun, 26 Oct 2014 17:03:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFDB1A1B6A; Sun, 26 Oct 2014 17:03:35 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03XCb002032; Mon, 27 Oct 2014 00:03:33 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03OgR001928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 00:03:27 GMT From: "Adrian Farrel" To: "'Gregory Mirsky'" , "'Loa Andersson'" , , References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> Date: Mon, 27 Oct 2014 00:03:20 -0000 Message-ID: <000601cff179$707a8c10$516fa430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuTtmLR0JtP8jl1thBqlYiJvncbQIIekC6nHYNOxA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21056.003 X-TM-AS-Result: No--11.648-10.0-31-10 X-imss-scan-details: No--11.648-10.0-31-10 X-TMASE-MatchedRID: +f/wAVSGjujuqBuVmgcCWiZm6wdY+F8KQKuv8uQBDjobQ3XP/Jy4srQn Y6ZuVLghlJXBvk7vV78btzXOkWU9Db0Xs0pxYyWVkE7MrqaPYs0ZKp0SZ4P+dU/N5GQtssoCM+p +NpswZmrPVbpsm8zN9R6i22jnAC+aTkaqbB0m3sLM1jffIgQXhvDfYikgJILntXl9IxEPXOqKLb gZyq471ydN4fsjEEgTzZpvrLjwrYswJ6xbTjBa5nPrqnZdfJhvB4Ntzrj5dXT1gF7PCEF9bpXPK 5yaPhuRRnUgijdt6WSjT363D9PEXmFqPXSLpNdAQr2qXCJMSV91k+gP1XamtJsoi2XrUn/JyeMt MD9QOgCk8oKXKhRLPI2j49Ftap9EOwBXM346/+yTvgMUZZgtmd2rQEdDtjeyiYqTJWk6yfwxGYz ha73cl5yTUb231vQ3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/7pl2egmdkjM6JfooNDZSfVWqpTc Cc: mpls@ietf.org Subject: Re: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:03:38 -0000 The intention of LIME (who knows whether it is achievable?) is to produce a single YANG module that provides a generic way in to OAM across all IETF technologies. There are certainly a number of core concepts, configurable items, and reportable things that can be stated in a technology independent way. LIME has as a deliverable a set of applicability statements showing how the generic module is applied to different IETF OAM technologies. I should not be surprised if technology-specific modules are also required. I think LIME hopes that these will build on the generic module and not reinvent. I assume this will be through augmentation. And I assume the work will be done by the WGs that own the technologies (where those WGs exist). I don't think I understand your tree. Why would "RSVP-TE OAM" live under rsvp-te under mpls? The OAM is going to be standard mpls oam, but the concepts (MIPs, MEPs, on/off, failure found, etc.) are general. Adrian > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > Gregory Mirsky > Sent: 26 October 2014 18:51 > To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question > > Hi Loa, > I think that your question is not simple at all and it would be a great to discuss > how Generic OAM proposal is related to MPLS OAM at the meeting. > Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment > Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM > with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing > networks. > > Regards, > Greg > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Sunday, October 26, 2014 3:14 AM > To: lime@ietf.org; Rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] hopefully a simple question > > Folks, > > I have what I hope is a simple question, and that it will only reveal that I'm not up > to speed on yang. > > I trying to figure out the relationship between the generic yang models in e.g. > draft-tissa-lime-yang-oam-model and the specific models we do for different > variants of e.g. mpls oam. > > I guess we have a structure more or less like this > > mpls > | > |- ldp > | |-ldp oam > | > |- rsvp-te > | | > | |- rsvp-te oam > | > |- lsp ping > | | > | |- lsp ping oam > | > |- etc > > > Where does the generic work fit in? > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Oct 26 17:15:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6801A1AE6; Sun, 26 Oct 2014 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 yFwHClBePifY; Sun, 26 Oct 2014 17:15:45 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9B11A1B2A; Sun, 26 Oct 2014 17:15:45 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id h18so2125340igc.4 for ; Sun, 26 Oct 2014 17:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y5Ao9ZHaFWzDWnvs9LsKY/ZsPZ1molypQLxvSv67vtk=; b=hUY/VUHbuuiQWxsaDXmQKjt/kAU+SO+ufJRtkRTMGpROYuR4lSjAq02h1n0CYmwkCB 3DgRirHVjP5OBGiIVDJBIIqtxmDC5S2KKrLNaeCfLH5q/oCt2bw7EWYYatNXEI9/amCL 50uXhWVbxXW+gMumj3iw32AWlXYtODKZmV0iqy936yfBvY5+/QnJAyiQicDor4TNvSaY pAEGMAQzA7Ii4NpLpTSB9XlBqW0X2OgZsMaCUZbVbvX50WcCVFsdw0H8Afz4l4tmR1/B W6Vb+OIAAvg294bA9S1ad1YKo8ozAgTngUqd4vmOvVAsagSwKewFiQu5I5CP+I/gI/e6 mUYA== X-Received: by 10.50.114.97 with SMTP id jf1mr18185293igb.29.1414368944657; Sun, 26 Oct 2014 17:15:44 -0700 (PDT) Received: from [192.168.0.102] ([216.254.166.33]) by mx.google.com with ESMTPSA id ro6sm4224439igb.3.2014.10.26.17.15.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 17:15:44 -0700 (PDT) Message-ID: <544D8EAA.9090909@gmail.com> Date: Sun, 26 Oct 2014 20:15:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Gregory Mirsky' , 'Loa Andersson' , lime@ietf.org, Rtg-yang-coord@ietf.org References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> In-Reply-To: <000601cff179$707a8c10$516fa430$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/heAbh2rcwSlgUqDSAJaIhp67drA Cc: mpls@ietf.org Subject: Re: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:15:48 -0000 This might be a good time to remind/alert people about the liaison statement received from the MEF regarding draft-tissa-lime-yang-oam-model. It can be found at https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef-netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf Tom Taylor On 26/10/2014 8:03 PM, Adrian Farrel wrote: > The intention of LIME (who knows whether it is achievable?) is to produce a > single YANG module that provides a generic way in to OAM across all IETF > technologies. > > There are certainly a number of core concepts, configurable items, and > reportable things that can be stated in a technology independent way. > > LIME has as a deliverable a set of applicability statements showing how the > generic module is applied to different IETF OAM technologies. > > I should not be surprised if technology-specific modules are also required. I > think LIME hopes that these will build on the generic module and not reinvent. I > assume this will be through augmentation. And I assume the work will be done by > the WGs that own the technologies (where those WGs exist). > > I don't think I understand your tree. Why would "RSVP-TE OAM" live under rsvp-te > under mpls? The OAM is going to be standard mpls oam, but the concepts (MIPs, > MEPs, on/off, failure found, etc.) are general. > > Adrian > >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of >> Gregory Mirsky >> Sent: 26 October 2014 18:51 >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org >> Cc: mpls@ietf.org >> Subject: Re: [Rtg-yang-coord] hopefully a simple question >> >> Hi Loa, >> I think that your question is not simple at all and it would be a great to > discuss >> how Generic OAM proposal is related to MPLS OAM at the meeting. >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment >> Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing >> networks. >> >> Regards, >> Greg >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Sunday, October 26, 2014 3:14 AM >> To: lime@ietf.org; Rtg-yang-coord@ietf.org >> Subject: [Rtg-yang-coord] hopefully a simple question >> >> Folks, >> >> I have what I hope is a simple question, and that it will only reveal that I'm > not up >> to speed on yang. >> >> I trying to figure out the relationship between the generic yang models in > e.g. >> draft-tissa-lime-yang-oam-model and the specific models we do for different >> variants of e.g. mpls oam. >> >> I guess we have a structure more or less like this >> >> mpls >> | >> |- ldp >> | |-ldp oam >> | >> |- rsvp-te >> | | >> | |- rsvp-te oam >> | >> |- lsp ping >> | | >> | |- lsp ping oam >> | >> |- etc >> >> >> Where does the generic work fit in? >> >> /Loa >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Sun Oct 26 17:34:31 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD61A1B2A; Sun, 26 Oct 2014 17:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 8yIesRPyB_pV; Sun, 26 Oct 2014 17:34:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7081A1AE6; Sun, 26 Oct 2014 17:34:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R0YJUs023855; Mon, 27 Oct 2014 00:34:19 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R0YI1r023839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 00:34:18 GMT From: "Adrian Farrel" To: "'Tom Taylor'" References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> In-Reply-To: <544D8EAA.9090909@gmail.com> Date: Mon, 27 Oct 2014 00:34:15 -0000 Message-ID: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuTtmLR0JtP8jl1thBqlYiJvncbQIIekC6Ajjl9XEBAQsSKpxcR6yg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21056.003 X-TM-AS-Result: No--30.210-10.0-31-10 X-imss-scan-details: No--30.210-10.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTm31G6CKdUG1cnUTf2MoOKYEtdrY/Wb3fMNht78/JfyBMKA qDfnmQ42htCDYfkeWUJo3hk6V6hjRT75vUIBy/bgU+OjsPhIWDhbUMPBWMyEThtDdc/8nLiysIz dcvB968pNYvDaO9t+nDYdkK1ORHHU9R7dwXny/bdhHpATwph+yOHQ21j8RtplCjPgYJbiyuAIZJ R7eWK/XCloEzX3fCKax+Qz1C8nOE6k0F4/j+0gRppWgCLYjjT9IpFOMUBYG+7HkH7uosEn7K0Ro mhWPJaQB153D9DJzyUNAALOfBOeCgmUwwEM0RbQ6/xAZojbl7c7ikpJrsu/6E/N5GQtssoCM+p+ NpswZmrPVbpsm8zN9R6i22jnAC+aCBmrdSPkjFwOrlBkQa9qFp20dShmm+V5feHPnu31iHAuaJN NszYALx05bc4Zz97z5pxeinsKVObGkynrj1kccqm4PbloS2C3QZXZg2I8JabnU40jhQv76qPFjJ EFr+olfeZdJ1XsorhYoPZAqTBHwi/tubwHkCSX+gD2vYtOFhgqtq5d3cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/TuJTESVnI3ZsM99bjvDIAaSfNjA Cc: Rtg-yang-coord@ietf.org, lime@ietf.org, netmod@ietf.org, david.sinicrope@ericsson.com Subject: Re: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:34:25 -0000 [Adding Netmod, but removing MPLS] A good pointer, Tom, thanks. The liaison seems to request review and feedback, but I don't see a response from Netmod and it looks like the MEF Technical Committee is meeting today and in the next few days. I think that if LIME had existed at the time the liaison arrived, it is probable that it would also have been a recipient. We should certainly strive to work with MEF and build on existing work. Adrian > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 27 October 2014 00:16 > To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson'; lime@ietf.org; Rtg- > yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question > > This might be a good time to remind/alert people about the liaison > statement received from the MEF regarding > draft-tissa-lime-yang-oam-model. It can be found at > > https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- > netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf > > Tom Taylor > > On 26/10/2014 8:03 PM, Adrian Farrel wrote: > > The intention of LIME (who knows whether it is achievable?) is to produce a > > single YANG module that provides a generic way in to OAM across all IETF > > technologies. > > > > There are certainly a number of core concepts, configurable items, and > > reportable things that can be stated in a technology independent way. > > > > LIME has as a deliverable a set of applicability statements showing how the > > generic module is applied to different IETF OAM technologies. > > > > I should not be surprised if technology-specific modules are also required. I > > think LIME hopes that these will build on the generic module and not reinvent. I > > assume this will be through augmentation. And I assume the work will be done > by > > the WGs that own the technologies (where those WGs exist). > > > > I don't think I understand your tree. Why would "RSVP-TE OAM" live under > rsvp-te > > under mpls? The OAM is going to be standard mpls oam, but the concepts > (MIPs, > > MEPs, on/off, failure found, etc.) are general. > > > > Adrian > > > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > >> Gregory Mirsky > >> Sent: 26 October 2014 18:51 > >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > >> Cc: mpls@ietf.org > >> Subject: Re: [Rtg-yang-coord] hopefully a simple question > >> > >> Hi Loa, > >> I think that your question is not simple at all and it would be a great to > > discuss > >> how Generic OAM proposal is related to MPLS OAM at the meeting. > >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment > >> Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM > >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing > >> networks. > >> > >> Regards, > >> Greg > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > >> Loa Andersson > >> Sent: Sunday, October 26, 2014 3:14 AM > >> To: lime@ietf.org; Rtg-yang-coord@ietf.org > >> Subject: [Rtg-yang-coord] hopefully a simple question > >> > >> Folks, > >> > >> I have what I hope is a simple question, and that it will only reveal that I'm > > not up > >> to speed on yang. > >> > >> I trying to figure out the relationship between the generic yang models in > > e.g. > >> draft-tissa-lime-yang-oam-model and the specific models we do for different > >> variants of e.g. mpls oam. > >> > >> I guess we have a structure more or less like this > >> > >> mpls > >> | > >> |- ldp > >> | |-ldp oam > >> | > >> |- rsvp-te > >> | | > >> | |- rsvp-te oam > >> | > >> |- lsp ping > >> | | > >> | |- lsp ping oam > >> | > >> |- etc > >> > >> > >> Where does the generic work fit in? > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Sun Oct 26 18:52:37 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE41A1BD9; Sun, 26 Oct 2014 18:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zy8zkpxrTlkw; Sun, 26 Oct 2014 18:52:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6932E1A1BEE; Sun, 26 Oct 2014 18:52:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY64115; Mon, 27 Oct 2014 01:52:30 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 01:52:29 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 09:52:22 +0800 From: Qin Wu To: Loa Andersson , "lime@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: [Lime] hopefully a simple question Thread-Index: AQHP8QWoZTMWKABt7Eae+8O2wKz9yZxDJedg Date: Mon, 27 Oct 2014 01:52:21 +0000 Message-ID: References: <544CC985.9060808@pi.nu> In-Reply-To: <544CC985.9060808@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/LLE_kBk44x5UkKyB5gl1g6Siu1k Subject: Re: [Rtg-yang-coord] [Lime] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 01:52:36 -0000 SXQgaXMgc3RyYW5nZSB0byBzdWJzdW1lIExEUCBPQU0gYW5kIFJTVlAtdGUgT0FNIHVuZGVyIE1Q TFMgT0FNLg0KTERQIE9BTSBhbmQgUlNWUC10ZSBPQU0gYXJlIG5vdCBkYXRhIHBsYW5lIE9BTSB0 b29scywgcmF0aGVyIHRoYW4gdGhleSBhcmUgY29udHJvbCBwbGFuZSBtYWludGVuYW5jZSB0b29s cy4NCldoZW4gd2UgdGFsayBhYm91dCBNUExTIE9BTSAsIGl0IGlzIHVzdWFsbHkgcmVmZXJyZWQg dG8gZGF0YSBwbGFuZSB0b29scywgaS5lLiwgTFNQIFBpbmcgT0FNLg0KUkZDNzI3NiBwcm92aWRl cyBhIGdvb2Qgc3VtbWFyaXphdGlvbiBmb3IgdmFyaW91cyBPQU0gdG9vbHMuDQoNClNlY29uZGx5 LCBJIHRoaW5rIGlmIHRoZXJlIGFyZSBzb21lIHN1Yi10ZWNobm9sb2dpZXMgdGhhdCBhcmUgdW5k ZXIgTVBMUyBPQU0sIHRlY2hub2xvZ3kgc3ViLXR5cGVzIGNhbiBhdWdtZW50DQp0aGUgYmFzZSBt b2RlbCB3aXRoIGJvdGggdGVjaG5vbG9neSB0eXBlIHNwZWNpZmljcyBhbmQgdGVjaG5vbG9neSBz dWItdHlwZSBzcGVjaWZpY3MsDQppLmUuLCB1c2UgaWRlbnRpdHkgdGVjaG5vbG9neS10eXBlcyBk ZWZpbmVkIGluIHRoZSBiYXNlIG1vZGVsIGFuZCB0ZWNobm9sb2d5IHN1YiB0eXBlIGRlZmluZWQg aW4gdGhlIHRlY2hub2xvZ3kgc3BlY2lmaWMgbW9kZWwNCnRvIGlkZW50aWZ5IHNwZWNpZmljIHN1 Yi0gdGVjaG5vbG9neSB0eXBlIHdpdGhpbiBzcGVjaWZpYyB0ZWNobm9sb2d5IHR5cGUuDQoNClJl Z2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTGltZSBbbWFpbHRvOmxp bWUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29uDQq3osvNyrG85DogMjAxNMTq MTDUwjI2yNUgMTg6MTQNCsrVvP7IyzogbGltZUBpZXRmLm9yZzsgUnRnLXlhbmctY29vcmRAaWV0 Zi5vcmcNCtb3zOI6IFtMaW1lXSBob3BlZnVsbHkgYSBzaW1wbGUgcXVlc3Rpb24NCg0KRm9sa3Ms DQoNCkkgaGF2ZSB3aGF0IEkgaG9wZSBpcyBhIHNpbXBsZSBxdWVzdGlvbiwgYW5kIHRoYXQgaXQg d2lsbCBvbmx5IHJldmVhbCB0aGF0IEknbSBub3QgdXAgdG8gc3BlZWQgb24geWFuZy4NCg0KSSB0 cnlpbmcgdG8gZmlndXJlIG91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGdlbmVyaWMg eWFuZyBtb2RlbHMgaW4gZS5nLiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsIGFuZCB0 aGUgc3BlY2lmaWMgbW9kZWxzIHdlIGRvIGZvciBkaWZmZXJlbnQgdmFyaWFudHMgb2YgZS5nLiBt cGxzIG9hbS4NCg0KSSBndWVzcyB3ZSBoYXZlIGEgc3RydWN0dXJlIG1vcmUgb3IgbGVzcyBsaWtl IHRoaXMNCg0KbXBscw0KICB8DQogIHwtIGxkcA0KICB8ICAgfC1sZHAgb2FtDQogIHwNCiAgfC0g cnN2cC10ZQ0KICB8ICAgfA0KICB8ICAgfC0gcnN2cC10ZSBvYW0NCiAgfA0KICB8LSBsc3AgcGlu Zw0KICB8ICAgfA0KICB8ICAgfC0gbHNwIHBpbmcgb2FtDQogIHwNCiAgfC0gZXRjDQoNCg0KV2hl cmUgZG9lcyB0aGUgZ2VuZXJpYyB3b3JrIGZpdCBpbj8NCg0KL0xvYQ0KLS0gDQoNCg0KTG9hIEFu ZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5j b20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51 DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEg MjEgNjQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkxpbWUgbWFpbGluZyBsaXN0DQpMaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xpbWUNCg== From nobody Sun Oct 26 19:13:57 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099D1A3B9E; Sun, 26 Oct 2014 19:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 T_jDggbrAU3u; Sun, 26 Oct 2014 19:13:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947C81A6EDB; Sun, 26 Oct 2014 19:13:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY65246; Mon, 27 Oct 2014 02:13:38 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 02:13:37 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 10:13:31 +0800 From: Qin Wu To: "adrian@olddog.co.uk" , "'Tom Taylor'" Thread-Topic: [Lime] [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8Xst52xKZrqdBUqVuDTnIZNWM5xCkmaAgACeQDA= Date: Mon, 27 Oct 2014 02:13:31 +0000 Message-ID: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/tXNBldgr8lE9PC-cNbZM-DssuVA Cc: "Rtg-yang-coord@ietf.org" , "lime@ietf.org" , "netmod@ietf.org" , "david.sinicrope@ericsson.com" Subject: Re: [Rtg-yang-coord] [Lime] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 02:13:47 -0000 QW5vdGhlciBsaWFpc29uIHN0YXRlbWVudCBzZW50IHRvIElFVEYgT1BTYXJlYSBvbiBBcHJpbCAy MDE0IGJlZm9yZSBMSU1FIGlzIGZvcm1lZA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTQtMDQtMjMtaXR1LXQtc2ctMTUtb3BzLWxzLW9u LW5ldy13b3JrLWl0ZW0tb24tZ2VuZXJpYy1pbmZvcm1hdGlvbi1tb2RlbC1mb3ItbWFuYWdlbWVu dC1vZi10cmFuc3BvcnQtbmUtYXR0YWNobWVudC0xLnBkZg0KSXQgaXMgcmVsYXRlZCB0byBJVFUt VCBHLmdpbTogZ2VuZXJpYyBwcm90b2NvbC1uZXV0cmFsIGluZm9ybWF0aW9uIG1vZGVsIGZvciB0 cmFuc3BvcnQgbmV0d29yayBtYW5hZ2VtZW50Lg0KQWx0aG91Z2ggaXQgaXMgbm90IGRpcmVjdGx5 IHJlbGF0ZWQgdG8gWUFORyBkYXRhIG1vZGVsIHdvcmsgd2UgYXJlIGZvY3VzaW5nIG9uLCBJIHRo aW5rIHdlIGFsc28gbmVlZCB0byBjb25zaWRlciB0aGlzIGV4aXN0aW5nIHdvcmsuDQoNClJlZ2Fy ZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTGltZSBbbWFpbHRvOmxpbWUt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4gRmFycmVsDQq3osvNyrG85DogMjAxNMTqMTDU wjI3yNUgODozNA0KytW8/sjLOiAnVG9tIFRheWxvcicNCrOty806IFJ0Zy15YW5nLWNvb3JkQGll dGYub3JnOyBsaW1lQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmc7IGRhdmlkLnNpbmljcm9wZUBl cmljc3Nvbi5jb20NCtb3zOI6IFJlOiBbTGltZV0gW1J0Zy15YW5nLWNvb3JkXSBob3BlZnVsbHkg YSBzaW1wbGUgcXVlc3Rpb24NCg0KW0FkZGluZyBOZXRtb2QsIGJ1dCByZW1vdmluZyBNUExTXQ0K DQpBIGdvb2QgcG9pbnRlciwgVG9tLCB0aGFua3MuDQoNClRoZSBsaWFpc29uIHNlZW1zIHRvIHJl cXVlc3QgcmV2aWV3IGFuZCBmZWVkYmFjaywgYnV0IEkgZG9uJ3Qgc2VlIGEgcmVzcG9uc2UgZnJv bSBOZXRtb2QgYW5kIGl0IGxvb2tzIGxpa2UgdGhlIE1FRiBUZWNobmljYWwgQ29tbWl0dGVlIGlz IG1lZXRpbmcgdG9kYXkgYW5kIGluIHRoZSBuZXh0IGZldyBkYXlzLiANCg0KSSB0aGluayB0aGF0 IGlmIExJTUUgaGFkIGV4aXN0ZWQgYXQgdGhlIHRpbWUgdGhlIGxpYWlzb24gYXJyaXZlZCwgaXQg aXMgcHJvYmFibGUgdGhhdCBpdCB3b3VsZCBhbHNvIGhhdmUgYmVlbiBhIHJlY2lwaWVudC4gDQoN CldlIHNob3VsZCBjZXJ0YWlubHkgc3RyaXZlIHRvIHdvcmsgd2l0aCBNRUYgYW5kIGJ1aWxkIG9u IGV4aXN0aW5nIHdvcmsuDQoNCkFkcmlhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFRvbSBUYXlsb3IgW21haWx0bzp0b20udGF5bG9yLnN0ZHNAZ21haWwuY29tXQ0K PiBTZW50OiAyNyBPY3RvYmVyIDIwMTQgMDA6MTYNCj4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs7 ICdHcmVnb3J5IE1pcnNreSc7ICdMb2EgQW5kZXJzc29uJzsgDQo+IGxpbWVAaWV0Zi5vcmc7DQpS dGctDQo+IHlhbmctY29vcmRAaWV0Zi5vcmcNCj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtSdGcteWFuZy1jb29yZF0gaG9wZWZ1bGx5IGEgc2ltcGxlIHF1ZXN0aW9uDQo+IA0K PiBUaGlzIG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHJlbWluZC9hbGVydCBwZW9wbGUgYWJvdXQg dGhlIGxpYWlzb24gDQo+IHN0YXRlbWVudCByZWNlaXZlZCBmcm9tIHRoZSBNRUYgcmVnYXJkaW5n IA0KPiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsLiAgSXQgY2FuIGJlIGZvdW5kIGF0 DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2xp YWlzb24tMjAxNC0wNy0zMS1tZWYtDQo+IG5ldG1vZC1saWFpc29uLXRvLWlldGYtb24teWFuZy1z ZXJ2aWNlLW9hbS1tb2RlbHMtYXR0YWNobWVudC0xLnBkZg0KPiANCj4gICBUb20gVGF5bG9yDQo+ IA0KPiBPbiAyNi8xMC8yMDE0IDg6MDMgUE0sIEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ID4gVGhl IGludGVudGlvbiBvZiBMSU1FICh3aG8ga25vd3Mgd2hldGhlciBpdCBpcyBhY2hpZXZhYmxlPykg aXMgdG8gDQo+ID4gcHJvZHVjZSBhIHNpbmdsZSBZQU5HIG1vZHVsZSB0aGF0IHByb3ZpZGVzIGEg Z2VuZXJpYyB3YXkgaW4gdG8gT0FNIA0KPiA+IGFjcm9zcyBhbGwgSUVURiB0ZWNobm9sb2dpZXMu DQo+ID4NCj4gPiBUaGVyZSBhcmUgY2VydGFpbmx5IGEgbnVtYmVyIG9mIGNvcmUgY29uY2VwdHMs IGNvbmZpZ3VyYWJsZSBpdGVtcywgDQo+ID4gYW5kIHJlcG9ydGFibGUgdGhpbmdzIHRoYXQgY2Fu IGJlIHN0YXRlZCBpbiBhIHRlY2hub2xvZ3kgaW5kZXBlbmRlbnQgd2F5Lg0KPiA+DQo+ID4gTElN RSBoYXMgYXMgYSBkZWxpdmVyYWJsZSBhIHNldCBvZiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMg c2hvd2luZyANCj4gPiBob3cgdGhlIGdlbmVyaWMgbW9kdWxlIGlzIGFwcGxpZWQgdG8gZGlmZmVy ZW50IElFVEYgT0FNIHRlY2hub2xvZ2llcy4NCj4gPg0KPiA+IEkgc2hvdWxkIG5vdCBiZSBzdXJw cmlzZWQgaWYgdGVjaG5vbG9neS1zcGVjaWZpYyBtb2R1bGVzIGFyZSBhbHNvIHJlcXVpcmVkLg0K SQ0KPiA+IHRoaW5rIExJTUUgaG9wZXMgdGhhdCB0aGVzZSB3aWxsIGJ1aWxkIG9uIHRoZSBnZW5l cmljIG1vZHVsZSBhbmQgbm90DQpyZWludmVudC4gSQ0KPiA+IGFzc3VtZSB0aGlzIHdpbGwgYmUg dGhyb3VnaCBhdWdtZW50YXRpb24uIEFuZCBJIGFzc3VtZSB0aGUgd29yayB3aWxsIA0KPiA+IGJl IGRvbmUNCj4gYnkNCj4gPiB0aGUgV0dzIHRoYXQgb3duIHRoZSB0ZWNobm9sb2dpZXMgKHdoZXJl IHRob3NlIFdHcyBleGlzdCkuDQo+ID4NCj4gPiBJIGRvbid0IHRoaW5rIEkgdW5kZXJzdGFuZCB5 b3VyIHRyZWUuIFdoeSB3b3VsZCAiUlNWUC1URSBPQU0iIGxpdmUgDQo+ID4gdW5kZXINCj4gcnN2 cC10ZQ0KPiA+IHVuZGVyIG1wbHM/IFRoZSBPQU0gaXMgZ29pbmcgdG8gYmUgc3RhbmRhcmQgbXBs cyBvYW0sIGJ1dCB0aGUgDQo+ID4gY29uY2VwdHMNCj4gKE1JUHMsDQo+ID4gTUVQcywgb24vb2Zm LCBmYWlsdXJlIGZvdW5kLCBldGMuKSBhcmUgZ2VuZXJhbC4NCj4gPg0KPiA+IEFkcmlhbg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFJ0Zy15YW5nLWNv b3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+ID4+IEJl aGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KPiA+PiBTZW50OiAyNiBPY3RvYmVyIDIwMTQgMTg6NTEN Cj4gPj4gVG86IExvYSBBbmRlcnNzb247IGxpbWVAaWV0Zi5vcmc7IFJ0Zy15YW5nLWNvb3JkQGll dGYub3JnDQo+ID4+IENjOiBtcGxzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUnRnLXlh bmctY29vcmRdIGhvcGVmdWxseSBhIHNpbXBsZSBxdWVzdGlvbg0KPiA+Pg0KPiA+PiBIaSBMb2Es DQo+ID4+IEkgdGhpbmsgdGhhdCB5b3VyIHF1ZXN0aW9uIGlzIG5vdCBzaW1wbGUgYXQgYWxsIGFu ZCBpdCB3b3VsZCBiZSBhIA0KPiA+PiBncmVhdCB0bw0KPiA+IGRpc2N1c3MNCj4gPj4gaG93IEdl bmVyaWMgT0FNIHByb3Bvc2FsIGlzIHJlbGF0ZWQgdG8gTVBMUyBPQU0gYXQgdGhlIG1lZXRpbmcu DQo+ID4+IFBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCB0aGVyZSdzIG5vIHNlcGFyYXRlIExEUCwg UlNWUC1URSBvciBFVlBOLCANCj4gPj4gU2VnbWVudCBSb3V0aW5nIChhcyBmYXIgYXMgdHJhbnNw b3J0IGxheWVyIGZvciB0aGUgbGF0dGVyIHR3bykgT0FNcyANCj4gPj4gYnV0IG9uZSBNUExTDQpP QU0NCj4gPj4gd2l0aCBleHRlbnNpb25zL3NwZWNpYWwgY2FzZXMgZm9yIElQL01QTFMsIE1QTFMt VFAgYW5kIFNlZ21lbnQgDQo+ID4+IFJvdXRpbmcgbmV0d29ya3MuDQo+ID4+DQo+ID4+IAlSZWdh cmRzLA0KPiA+PiAJCUdyZWcNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYu b3JnXSBPbiANCj4gPj4gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCj4gPj4gU2VudDogU3VuZGF5 LCBPY3RvYmVyIDI2LCAyMDE0IDM6MTQgQU0NCj4gPj4gVG86IGxpbWVAaWV0Zi5vcmc7IFJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFtSdGcteWFuZy1jb29yZF0gaG9wZWZ1 bGx5IGEgc2ltcGxlIHF1ZXN0aW9uDQo+ID4+DQo+ID4+IEZvbGtzLA0KPiA+Pg0KPiA+PiBJIGhh dmUgd2hhdCBJIGhvcGUgaXMgYSBzaW1wbGUgcXVlc3Rpb24sIGFuZCB0aGF0IGl0IHdpbGwgb25s eSANCj4gPj4gcmV2ZWFsIHRoYXQNCkknbQ0KPiA+IG5vdCB1cA0KPiA+PiB0byBzcGVlZCBvbiB5 YW5nLg0KPiA+Pg0KPiA+PiBJIHRyeWluZyB0byBmaWd1cmUgb3V0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGUgZ2VuZXJpYyB5YW5nIA0KPiA+PiBtb2RlbHMgaW4NCj4gPiBlLmcuDQo+ID4+ IGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwgYW5kIHRoZSBzcGVjaWZpYyBtb2RlbHMg d2UgZG8gZm9yIA0KPiA+PiBkaWZmZXJlbnQgdmFyaWFudHMgb2YgZS5nLiBtcGxzIG9hbS4NCj4g Pj4NCj4gPj4gSSBndWVzcyB3ZSBoYXZlIGEgc3RydWN0dXJlIG1vcmUgb3IgbGVzcyBsaWtlIHRo aXMNCj4gPj4NCj4gPj4gbXBscw0KPiA+PiAgICB8DQo+ID4+ICAgIHwtIGxkcA0KPiA+PiAgICB8 ICAgfC1sZHAgb2FtDQo+ID4+ICAgIHwNCj4gPj4gICAgfC0gcnN2cC10ZQ0KPiA+PiAgICB8ICAg fA0KPiA+PiAgICB8ICAgfC0gcnN2cC10ZSBvYW0NCj4gPj4gICAgfA0KPiA+PiAgICB8LSBsc3Ag cGluZw0KPiA+PiAgICB8ICAgfA0KPiA+PiAgICB8ICAgfC0gbHNwIHBpbmcgb2FtDQo+ID4+ICAg IHwNCj4gPj4gICAgfC0gZXRjDQo+ID4+DQo+ID4+DQo+ID4+IFdoZXJlIGRvZXMgdGhlIGdlbmVy aWMgd29yayBmaXQgaW4/DQo+ID4+DQo+ID4+IC9Mb2ENCj4gPj4gLS0NCj4gPj4NCj4gPj4NCj4g Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAx Lmh1YXdlaS5jb20NCj4gPj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAg ICAgICBsb2FAcGkubnUNCj4gPj4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAg IHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcg bGlzdA0KPiA+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+ID4+DQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFJ0Zy15YW5nLWNv b3JkIG1haWxpbmcgbGlzdA0KPiA+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFJ0 Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPiA+IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0K PiA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpM aW1lIG1haWxpbmcgbGlzdA0KTGltZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saW1lDQo= From nobody Sun Oct 26 20:41:39 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755BB1A6FBB; Sun, 26 Oct 2014 20:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bN4KKTfC12Kn; Sun, 26 Oct 2014 20:41:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674CE1A6FA3; Sun, 26 Oct 2014 20:41:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOB51895; Mon, 27 Oct 2014 03:41:32 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 03:41:31 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 11:41:24 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , Loa Andersson , "lime@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: [Lime] hopefully a simple question Thread-Index: AQHP8QWoZTMWKABt7Eae+8O2wKz9yZxDJedg//+WXACAAIxjsA== Date: Mon, 27 Oct 2014 03:41:22 +0000 Message-ID: References: <544CC985.9060808@pi.nu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/HC1cxV-t55y5jIwRSODvXD-tfQM Subject: Re: [Rtg-yang-coord] [Lime] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 03:41:36 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIp IFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXSANCreiy83KsbzkOiAyMDE0xOoxMNTCMjfI1SAx MTowMQ0KytW8/sjLOiBRaW4gV3U7IExvYSBBbmRlcnNzb247IGxpbWVAaWV0Zi5vcmc7IFJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnDQrW98ziOiBSRTogW0xpbWVdIGhvcGVmdWxseSBhIHNpbXBsZSBx dWVzdGlvbg0KDQpUaGFua3MgUWluIGZvciB0aGUgc3BvdCBvbiBkZXRhaWwgcmVwbHksIA0KDQpM b2EgZXQuYWwgDQoNCkxldCBtZSBhZGQgb24gdG8gd2hhdCBRaW4gc3RhdGVkLiBXZSBuZWVkIHRv IGFwcHJvYWNoIHRoaXMgaW4gdG9wIGRvd24gbWFubmVyLiBBdCB0aGUgdG9wIG9mIHRoZSBsYXll ciBpcyB0aGUgYmFzZSBZQU5HIG1vZGVsIChha2EgR2VuIFlBTkcpDQoNCldoYXQgaXMgcHJlc2Vu dGVkIGluIFRpc3NhLXlhbmcgaXMgdGhlIGZhdWx0IG1hbmFnZW1lbnQgbW9kZWwsIHRoYXQgaXMg aW5kZXBlbmRlbnQgb2YgdGhlIHVuZGVybHlpbmcgT0FNIHByb3RvY29scy4gSW4gZGVzaWduaW5n IHRoZSBtb2RlbCB3ZSBoYXZlIHVzZWQgcG93ZXIgb2YgWUFORyBzbyB0aGF0IGV2ZXJ5IGVsZW1l bnQgaXMgYXVnbWVudGFibGUuIA0KDQpbUWluXTogSnVzdCB3YW50IHRvIHN0cmVzcyB0aGUgZWxl bWVudCBpcyByZWZlcnJlZCB0byBldmVyeSBlbGVtZW50IGluc2VydGVkIGluIHRoZSBtb2R1bGUg aGllcmFyY2h5IGRlZmluZWQgaW4gUkZDNjAyMCxub3QgZWxlbWVudCBvciBub2RlIGluIHRoZSB0 cmVlIG1lbnRpb25lZCBiZWxvdy4NClRoZSB0cmVlIG1lbnRpb25lZCBiZWxvdyBjb21wcmlzZXMg YSBsb3Qgb2Ygbm9kZXMgaW5jbHVkaW5nIHJvb3Qgbm9kZSwgYnJhbmNoIG5vZGUsIGxlYWYgbm9k ZS4gRWFjaCBub2RlIGluIHRoaXMgdHJlZSBpcyBkYXRhIG1vZGVsLCBpcnJlc3BlY3RpdmUgb2Yg d2hldGhlciBpdCBpcw0KdGVjaG5vbG9neSBzcGVjaWZpYyBhbmQgdGVjaG5vbG9neSBpbmRlcGVu ZGVudC4NCg0KRS5nLiBpbnN0ZWFkIG9mIGVudW1zIHdlIHVzZSBpZGVudGl5cmVmcywgaW5zdGVh ZCBvZiB0eXBlZGVmcyB3aGVyZSBhcHBsaWNhYmxlIHdlIHVzZSBjb21iaW5hdGlvbiBvZiBjaG9p Y2UvY2FzZSBzdGF0ZW1lbnQuIA0KDQpUaGUgaWRlYSBpcyBldmVyeSBicmFuY2ggaW4gdGhlIGRh dGEgbW9kZWwgaXMgZXh0ZW5zaWJsZS4NCg0KW1Fpbl06IEV4YWN0bHksIGluIGEgdHJlZSB3aXRo IHJvb3Qgbm9kZSwgYnJhbmNoIG5vZGVzIGFuZCBsZWFmIG5vZGVzLCBhbGwgdGhlIGJyYW5jaCBu b2RlcyBzaG91bGQgb25seSBoYXZlIG9uZSByb290IG5vZGUsIGlmIG9uZSBub2RlIGluIHRoZSB0 cmVlIGlzIGV4dGVuc2libGUsIHRoaXMgbm9kZSBNVVNUIGJlIGEgcm9vdCBub2RlIG9yIGEgYnJh bmNoIG5vZGUuIElmIHRoZSBvbmUgbm9kZSBpcyBub3QgZXh0ZW5zaWJsZSwgdGhpcyBub2RlIE1V U1QgYmUgYSBsZWFmIG5vZGUuDQpUaGVyZWZvcmUgdGVjaG5vbG9neSBzcGVjaWZpYyBkYXRhIG1v ZGVsIGNhbiBhbHNvIGJlIGV4dGVuc2libGUgYXMgbG9uZyBhcyBpdCBpcyBicmFuY2ggbm9kZSBp biB0aGUgdHJlZS4NCg== From nobody Mon Oct 27 03:19:20 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574241A8BB6 for ; Mon, 27 Oct 2014 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UeZf6Cz6gj42 for ; Mon, 27 Oct 2014 03:19:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE8E1A8AEB for ; Mon, 27 Oct 2014 03:19:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOB89608; Mon, 27 Oct 2014 10:19:13 +0000 (GMT) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 10:19:12 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.231]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 18:19:09 +0800 From: wangzitao To: "Rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed Thread-Index: AQHP7w13vd0nkBrwhkWKpwwuyK9dD5xDvg+QgAAANpA= Date: Mon, 27 Oct 2014 10:19:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: multipart/mixed; boundary="_004_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/5ZMAmb-hnI8jqe4FaXBGnUOXanA Cc: "akatlas@gmail.com" Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:19:18 -0000 --_004_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_ Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_" --_000_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLg0KDQpIZXJlIGlzIGEgbmV3IGRyYWZ0IHRvIGRpc2N1c3MgQkZEIFlBTkcgbW9kZWwuDQoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmcteWFuZy1iZmQtb2Ft Lw0KDQotTWljaGFlbA0K5Y+R5Lu25Lq6OiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5n LWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBBbGlhIEF0bGFzDQrlj5HpgIHml7bpl7Q6 IDIwMTTlubQxMOaciDI05pelIDY6MDUNCuaUtuS7tuS6ujogUnRnLXlhbmctY29vcmRAaWV0Zi5v cmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPg0K5oqE6YCBOiBCZW5vaXQgQ2xhaXNl DQrkuLvpopg6IFtSdGcteWFuZy1jb29yZF0gVmVyeSBhY3RpdmUgZGlzY3Vzc2lvbiBhbmQgY29v cmRpbmF0aW9uIG9mIFlBTkcgbW9kZWxzIGlzIG5lZWRlZA0KDQpGaXJzdCwgSSBhbSBhYnNvbHV0 ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3ZlciB0aGF0IHRoaXMgY29vcmRpbmF0aW9uIGxpc3QgaGFz IDEzOSBzdWJzY3JpYmVycyEgIEkgYW0gcXVpdGUgZW5jb3VyYWdlZCB0aGF0IHdlIHdpbGwgYmUg YWJsZSB0byB1c2UgdGhpcyBtYWlsaW5nIGxpc3QgZm9yIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiBh bmQgY29vcmRpbmF0aW9uLiAgV2VsY29tZSBhbmQgcGxlYXNlIHN0YXJ0IHRhbGtpbmchDQoNClRv d2FyZHMgdGhhdCBwdXJwb3NlLi4uDQoNCldpdGggYSBmZXcgV0cgZHJhZnRzIGFuZCBvdmVyIDIw IGluZGl2aWR1YWwgZHJhZnRzIHRoYXQgbWF5IG92ZXJsYXAgYW5kIHNob3VsZCBzaGFyZSBzb21l IGNvbW1vbiBhYnN0cmFjdGlvbnMgYW5kIGdyb3VwaW5ncywgd2UgcmVhbGx5IG5lZWQgdG8gc3Rh cnQgY29vcmRpbmF0aW5nLiAgIFRoaXMgaXMgYSBzaWduaWZpY2FudCBleHBsb3Npb24gb2YgZHJh ZnRzIGFuZCBpbnRlcmVzdCBpbiB0aGUgbGFzdCA5IG1vbnRocyAtIGFuZCB3ZSBhcmUgaW50ZXJh Y3RpbmcsIGF0IGxlYXN0IGluIHBhcnQsIHdpdGggYSBjb21tdW5pdHkgdGhhdCBORUVEUyBzdGFu ZGFyZGl6YXRpb24gdG8gaGFwcGVuIG11Y2ggbW9yZSBxdWlja2x5Lg0KDQpBZHJpYW4sIEJlbm9p dCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRpbmcgdXAgYSBqb2IgZGVzY3JpcHRpb24gZm9y IGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlzIG1haWxpbmcgbGlzdCBhbmQgdGhlIGNvb3Jk aW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNlc3NhcnkuICBOZWVkbGVzcyB0byBzYXksIGlm IHlvdSB3b3VsZCBhbHJlYWR5IGxpa2UgdG8gdm9sdW50ZWVyLCBwbGVhc2UgZW1haWwgbWUgd2l0 aCBkZXRhaWxzLg0KDQpUbyBhaWQgaW4gZmluZGluZyB0aGUgdmFyaW91cyBZQU5HIG1vZGVscyB0 aGF0IHJlbGF0ZSB0byByb3V0aW5nIGluIHNvbWUgd2F5LCBJJ3ZlIGluY2x1ZGVkIGEgbGlzdCBi ZWxvdy4gIFRoaXMgbGlzdCB3YXMgZ2VuZXJhdGVkIGJ5IGxvb2tpbmcgdGhyb3VnaCBhIHNlYXJj aCBvZiBkcmFmdHMgYmFzZWQgb24gdGhlIGtleXdvcmQgWUFORyBwbHVzIGEgY291cGxlIEkyUlMg ZHJhZnRzIEkgd2FzIGFscmVhZHkgZmFtaWxpYXIgd2l0aC4gIEkgYXBvbG9naXplIGlmIEkgbWlz c2VkIGFueSAoYW5kIGVuY291cmFnZSBjb25zaXN0ZW50IG5hbWluZyApLg0KDQpkcmFmdC1pZXRm LW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+DQpkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lz LWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMt eWFuZy1pc2lzLWNmZy8+DQpkcmFmdC1pZXRmLWkycnMtcmliLWluZm8tbW9kZWwtMDM8aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVs Lz4gKFlBTkcgbW9kZWwgY29taW5nIHZlcnkgc29vbikNCg0KZHJhZnQtYm9nZGFub3ZpYy1uZXRt b2QtYWNsLW1vZGVsLTAyPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJv Z2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8+IChtb3JlIGdlbmVyYWwgdGhhbiByb3V0aW5nLCBz byBjdXJyZW50bHkgcHJvZ3Jlc3NpbmcgaW4gTkVUTU9EKQ0KZHJhZnQtY2hlbi1tcGxzLWxkcC15 YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1w bHMtbGRwLXlhbmctY2ZnLz4NCmRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMDxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmcvPg0K ZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmstdG9wby0wMTxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1jbGVtbS1pMnJzLXlhbmctbmV0d29yay10b3BvLz4NCmRyYWZ0 LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLz4gKHRh cmdldGVkIGF0IGFuIHVuYXBwcm92ZWQgQm9GLCBvdmVybGFwIHdpdGggSTJSUykNCmRyYWZ0LWRv bmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5Lz4NCmRyYWZ0LWdhbmRo aS1tcGxzLXRlLXlhbmctbW9kZWwtMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC8+DQpkcmFmdC1oYW8tdHJpbGwteWFuZy0w MTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8tdHJpbGwteWFuZy8+ IChtYXkgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lkZXIgZnJvbSB0aGUgSVNJUyBvdmVybGFwKQ0K ZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0vPg0KZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3Ry YWN0LXRvcG8tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5l dG1vZC15YW5nLWFic3RyYWN0LXRvcG8vPiAoYW5vdGhlciB0b3BvbG9neSBtb2RlbCkNCmRyYWZ0 LWxpdS1waW0taWdtcC1tbGQteWFuZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmcvPg0KZHJhZnQtbGl1LXBpbS15YW5nLTAwPGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1waW0teWFuZy8+DQpkcmFm dC1wZW5uby1zZmMteWFuZy0wODxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1wZW5uby1zZmMteWFuZy8+DQpkcmFmdC1wa2QtcGNlLXBjZXAteWFuZy0wMDxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wa2QtcGNlLXBjZXAteWFuZy8+DQpkcmFmdC10 aXNzYS1udm8zLXlhbmctb2FtLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vPg0KZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0tMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0vPg0K ZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vPg0KZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2Vs ZXRpb24tMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWFuZy10cmls bC1wYXJlbnQtc2VsZXRpb24vPg0KZHJhZnQteWV1bmctbmV0bW9kLW9zcGYtMDI8aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWV1bmctbmV0bW9kLW9zcGYvPg0KZHJhZnQt emhhbmctbXBscy10cC15YW5nLW9hbS0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLz4NCmRyYWZ0LXpoYW5nLW52bzMteWFuZy1j ZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctbnZvMy15 YW5nLWNmZy8+DQpkcmFmdC16aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy0wMTxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy8+DQpkcmFm dC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy8+DQpkcmFmdC16aHVhbmct bDJ2cG4teWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emh1YW5nLWwydnBuLXlhbmctY2ZnLz4NCmRyYWZ0LXpodWFuZy1sM3Zwbi15YW5nLWNmZy0wMDxo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctbDN2cG4teWFuZy1j ZmcvPg0KDQpJIGhvcGUgdGhhdCByZWFkaW5nIHNvbWUgb2YgdGhlIGFib3ZlIChhdCBsZWFzdCBk cmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+KSB3aWxsIHN0YXJ0IHRvIGlu c3BpcmUgaWRlYXMgYW5kIGNvbmNyZXRlIGRpc2N1c3Npb24gYWJvdXQgd2hhdCBjb29yZGluYXRp b24gYmV0d2VlbiBtb2RlbHMgYW5kIGRyYWZ0cyBpcyBuZWVkZWQuDQoNClRoYW5rcywNCkFsaWEN Cg0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5GWUkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0Ij5IZXJlIGlzIGEgbmV3IGRyYWZ0IHRvIGRpc2N1c3MgQkZEIFlBTkcgbW9k ZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLXlhbmctYmZkLW9hbS88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPi1NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gUnRnLXlh bmctY29vcmQgWzxhIGhyZWY9Im1haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QWxpYSBBdGxhczxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI0 PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gNjowNTxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBo cmVmPSJtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmciPg0KUnRnLXlhbmctY29vcmRAaWV0 Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEJlbm9pdCBDbGFpc2U8YnI+DQo8L3NwYW4+PGI+5Li7 6aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gW1J0 Zy15YW5nLWNvb3JkXSBWZXJ5IGFjdGl2ZSBkaXNjdXNzaW9uIGFuZCBjb29yZGluYXRpb24gb2Yg WUFORyBtb2RlbHMgaXMgbmVlZGVkPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Rmlyc3QsIEkgYW0gYWJzb2x1dGVseSBkZWxpZ2h0ZWQgdG8gZGlzY292ZXIgdGhhdCB0 aGlzIGNvb3JkaW5hdGlvbiBsaXN0IGhhcyAxMzkgc3Vic2NyaWJlcnMhJm5ic3A7IEkgYW0gcXVp dGUgZW5jb3VyYWdlZCB0aGF0IHdlIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhpcyBtYWlsaW5nIGxp c3QgZm9yIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiBhbmQgY29vcmRpbmF0aW9uLiZuYnNwOyBXZWxj b21lIGFuZA0KIHBsZWFzZSBzdGFydCB0YWxraW5nITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRvd2FyZHMgdGhhdCBwdXJwb3NlLi4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2l0aCBhIGZldyBXRyBkcmFm dHMgYW5kIG92ZXIgMjAgaW5kaXZpZHVhbCBkcmFmdHMgdGhhdCBtYXkgb3ZlcmxhcCBhbmQgc2hv dWxkIHNoYXJlIHNvbWUgY29tbW9uIGFic3RyYWN0aW9ucyBhbmQgZ3JvdXBpbmdzLCB3ZSByZWFs bHkgbmVlZCB0byBzdGFydCBjb29yZGluYXRpbmcuICZuYnNwOyBUaGlzIGlzIGEgc2lnbmlmaWNh bnQgZXhwbG9zaW9uIG9mIGRyYWZ0cyBhbmQgaW50ZXJlc3QNCiBpbiB0aGUgbGFzdCA5IG1vbnRo cyAtIGFuZCB3ZSBhcmUgaW50ZXJhY3RpbmcsIGF0IGxlYXN0IGluIHBhcnQsIHdpdGggYSBjb21t dW5pdHkgdGhhdCBORUVEUyBzdGFuZGFyZGl6YXRpb24gdG8gaGFwcGVuIG11Y2ggbW9yZSBxdWlj a2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5BZHJpYW4sIEJlbm9pdCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRpbmcgdXAgYSBq b2IgZGVzY3JpcHRpb24gZm9yIGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlzIG1haWxpbmcg bGlzdCBhbmQgdGhlIGNvb3JkaW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNlc3NhcnkuJm5i c3A7IE5lZWRsZXNzIHRvIHNheSwgaWYgeW91IHdvdWxkIGFscmVhZHkgbGlrZSB0byB2b2x1bnRl ZXIsDQogcGxlYXNlIGVtYWlsIG1lIHdpdGggZGV0YWlscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbyBhaWQgaW4gZmluZGluZyB0aGUg dmFyaW91cyBZQU5HIG1vZGVscyB0aGF0IHJlbGF0ZSB0byByb3V0aW5nIGluIHNvbWUgd2F5LCBJ J3ZlIGluY2x1ZGVkIGEgbGlzdCBiZWxvdy4mbmJzcDsgVGhpcyBsaXN0IHdhcyBnZW5lcmF0ZWQg YnkgbG9va2luZyB0aHJvdWdoIGEgc2VhcmNoIG9mIGRyYWZ0cyBiYXNlZCBvbiB0aGUga2V5d29y ZCBZQU5HIHBsdXMgYSBjb3VwbGUgSTJSUyBkcmFmdHMNCiBJIHdhcyBhbHJlYWR5IGZhbWlsaWFy IHdpdGguJm5ic3A7IEkgYXBvbG9naXplIGlmIEkgbWlzc2VkIGFueSAoYW5kIGVuY291cmFnZSBj b25zaXN0ZW50IG5hbWluZyApLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Jh Y2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMTU8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lz LWNmZy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItaW5mby1tb2RlbC8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1pZXRm LWkycnMtcmliLWluZm8tbW9kZWwtMDM8L3NwYW4+PC9hPiZuYnNwOyhZQU5HIG1vZGVsIGNvbWlu Zw0KIHZlcnkgc29vbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJv Z2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFj a2dyb3VuZDojRURGNUZGIj5kcmFmdC1ib2dkYW5vdmljLW5ldG1vZC1hY2wtbW9kZWwtMDI8L3Nw YW4+PC9hPiZuYnNwOyhtb3JlIGdlbmVyYWwNCiB0aGFuIHJvdXRpbmcsIHNvIGN1cnJlbnRseSBw cm9ncmVzc2luZyBpbiBORVRNT0QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tbXBscy1sZHAteWFuZy1jZmcv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1jaGVuLW1wbHMtbGRwLXlhbmctY2Zn LTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWNoZW4tbXBscy10 ZS15YW5nLWNmZy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNsZW1tLWkycnMteWFuZy1uZXR3 b3JrLXRvcG8vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1jbGVtbS1pMnJzLXlh bmctbmV0d29yay10b3BvLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY29udHJlcmFzLXN1cGEt eWFuZy1uZXR3b3JrLXRvcG8vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1jb250 cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby0wMDwvc3Bhbj48L2E+Jm5ic3A7KHRhcmdldGVk IGF0IGFuIHVuYXBwcm92ZWQNCiBCb0YsIG92ZXJsYXAgd2l0aCBJMlJTKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1k b25nLWkycnMtbDItbmV0d29yay10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PmRyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAw PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFvLXRyaWxsLXlhbmcvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5kcmFmdC1oYW8tdHJpbGwteWFuZy0wMTwvc3Bhbj48L2E+Jm5ic3A7KG1heSBi ZSBpbnRlcmVzdGluZyB0byBjb25zaWRlciBmcm9tIHRoZSBJU0lTIG92ZXJsYXApPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWhhcmVzLWkycnMtYmdwLWRtLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQt aGFyZXMtaTJycy1iZ3AtZG0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtbmV0bW9kLXlh bmctYWJzdHJhY3QtdG9wby8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWxpdS1u ZXRtb2QteWFuZy1hYnN0cmFjdC10b3BvLTAwPC9zcGFuPjwvYT4mbmJzcDsoYW5vdGhlciB0b3Bv bG9neSBtb2RlbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXBpbS1pZ21wLW1sZC15YW5nLyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWxpdS1waW0taWdtcC1t bGQteWFuZy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1waW0teWFuZy8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWxpdS1waW0teWFuZy0wMDwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXBlbm5vLXNmYy15YW5nLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQt cGVubm8tc2ZjLXlhbmctMDg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wa2QtcGNlLXBjZXAteWFu Zy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1w a2QtcGNlLXBjZXAteWFuZy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFu Zy1vYW0vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC10aXNzYS1udm8zLXlhbmct b2FtLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0vIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtd2FuZy1pMnJzLWlz aXMtZG0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLWkycnMtb3NwZi1kbS8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXdhbmctaTJycy1vc3BmLWRtLTAwPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2VsZXRpb24vIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQteWFuZy10cmlsbC1wYXJlbnQt c2VsZXRpb24tMDM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15ZXVuZy1uZXRtb2Qtb3NwZi8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC15ZXVuZy1u ZXRtb2Qtb3NwZi0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1v YW0vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQt emhhbmctbXBscy10cC15YW5nLW9hbS0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLW52 bzMteWFuZy1jZmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC16aGFuZy1udm8z LXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhkYW5raW4tbmV0bW9kLWJncC1j ZmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQt emhkYW5raW4tbmV0bW9kLWJncC1jZmctMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmct bDJ2cG4tZXZwbi15YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3Vu ZDojRURGNUZGIj5kcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy0wMDwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXpodWFuZy1sMnZwbi15YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmRyYWZ0LXpodWFuZy1sMnZwbi15YW5nLWNmZy0wMDwvc3Bhbj48L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXpodWFuZy1sM3Zwbi15YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFj a2dyb3VuZDojRURGNUZGIj5kcmFmdC16aHVhbmctbDN2cG4teWFuZy1jZmctMDA8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBob3Bl IHRoYXQgcmVhZGluZyBzb21lIG9mIHRoZSBhYm92ZSAoYXQgbGVhc3QmbmJzcDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5n LWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFm dC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTwvc3Bhbj48L2E+KQ0KIHdpbGwgc3RhcnQgdG8g aW5zcGlyZSBpZGVhcyBhbmQgY29uY3JldGUgZGlzY3Vzc2lvbiBhYm91dCB3aGF0IGNvb3JkaW5h dGlvbiBiZXR3ZWVuIG1vZGVscyBhbmQgZHJhZnRzIGlzIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QWxpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_-- --_004_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=157; creation-date="Thu, 23 Oct 2014 22:05:34 GMT"; modification-date="Thu, 23 Oct 2014 22:05:34 GMT" Content-ID: <4B2332C4B94BE442817902EDCA9ED224@huawei.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJ0Zy15YW5n LWNvb3JkIG1haWxpbmcgbGlzdA0KUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg== --_004_E6BC9BBCBCACC246846FC685F9FF41EABA0E68szxeml501mbxchina_-- From nobody Mon Oct 27 03:58:50 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418F1A9041 for ; Mon, 27 Oct 2014 03:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UDZRfBns_mdQ for ; Mon, 27 Oct 2014 03:58:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9690E1A8F4C for ; Mon, 27 Oct 2014 03:58:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ10396; Mon, 27 Oct 2014 10:58:43 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 10:58:42 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 18:58:28 +0800 From: Qin Wu To: wangzitao , "Rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed Thread-Index: AQHP7w13svyzp+/nN0CF5JKgNPrxI5xDvg+QgAAANpCAAAzmIA== Date: Mon, 27 Oct 2014 10:58:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84601607nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/xhovPdavTK3TF9o37OrUfKXqZcU Cc: "akatlas@gmail.com" Subject: Re: [Rtg-yang-coord] Very active discussion and coordination of YANG models is needed X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:58:48 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84601607nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljaGFlbDoNCkJGRCBjaGFpcnMgaGF2ZSBjYWxsZWQgZm9yIGEgZGVzaWduIHRlYW0gdG8gZGVm aW5lIEJGRCBZQU5HIG1vZGVsLg0KSXQgbWlnaHQgYmUgZ29vZCBmb3IgeW91IHRvIHRhbGsgd2l0 aCBCRkQgY2hhaXJzIGFuZCBjb29yZGluYXRlIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgZGVzaWdu IHRlYW0uDQoNClJlZ2FyZHMhDQotUWluDQrlj5Hku7bkuro6IFJ0Zy15YW5nLWNvb3JkIFttYWls dG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIHdhbmd6aXRhbw0K5Y+R 6YCB5pe26Ze0OiAyMDE05bm0MTDmnIgyN+aXpSAxODoxOQ0K5pS25Lu25Lq6OiBSdGcteWFuZy1j b29yZEBpZXRmLm9yZw0K5oqE6YCBOiBha2F0bGFzQGdtYWlsLmNvbQ0K5Li76aKYOiBSZTogW1J0 Zy15YW5nLWNvb3JkXSBWZXJ5IGFjdGl2ZSBkaXNjdXNzaW9uIGFuZCBjb29yZGluYXRpb24gb2Yg WUFORyBtb2RlbHMgaXMgbmVlZGVkDQoNCg0KRllJLg0KDQpIZXJlIGlzIGEgbmV3IGRyYWZ0IHRv IGRpc2N1c3MgQkZEIFlBTkcgbW9kZWwuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXdhbmcteWFuZy1iZmQtb2FtLw0KDQotTWljaGFlbA0K5Y+R5Lu25Lq6OiBSdGct eWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ih qCBBbGlhIEF0bGFzDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQxMOaciDI05pelIDY6MDUNCuaUtuS7 tuS6ujogUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYu b3JnPg0K5oqE6YCBOiBCZW5vaXQgQ2xhaXNlDQrkuLvpopg6IFtSdGcteWFuZy1jb29yZF0gVmVy eSBhY3RpdmUgZGlzY3Vzc2lvbiBhbmQgY29vcmRpbmF0aW9uIG9mIFlBTkcgbW9kZWxzIGlzIG5l ZWRlZA0KDQpGaXJzdCwgSSBhbSBhYnNvbHV0ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3ZlciB0aGF0 IHRoaXMgY29vcmRpbmF0aW9uIGxpc3QgaGFzIDEzOSBzdWJzY3JpYmVycyEgIEkgYW0gcXVpdGUg ZW5jb3VyYWdlZCB0aGF0IHdlIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhpcyBtYWlsaW5nIGxpc3Qg Zm9yIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiBhbmQgY29vcmRpbmF0aW9uLiAgV2VsY29tZSBhbmQg cGxlYXNlIHN0YXJ0IHRhbGtpbmchDQoNClRvd2FyZHMgdGhhdCBwdXJwb3NlLi4uDQoNCldpdGgg YSBmZXcgV0cgZHJhZnRzIGFuZCBvdmVyIDIwIGluZGl2aWR1YWwgZHJhZnRzIHRoYXQgbWF5IG92 ZXJsYXAgYW5kIHNob3VsZCBzaGFyZSBzb21lIGNvbW1vbiBhYnN0cmFjdGlvbnMgYW5kIGdyb3Vw aW5ncywgd2UgcmVhbGx5IG5lZWQgdG8gc3RhcnQgY29vcmRpbmF0aW5nLiAgIFRoaXMgaXMgYSBz aWduaWZpY2FudCBleHBsb3Npb24gb2YgZHJhZnRzIGFuZCBpbnRlcmVzdCBpbiB0aGUgbGFzdCA5 IG1vbnRocyAtIGFuZCB3ZSBhcmUgaW50ZXJhY3RpbmcsIGF0IGxlYXN0IGluIHBhcnQsIHdpdGgg YSBjb21tdW5pdHkgdGhhdCBORUVEUyBzdGFuZGFyZGl6YXRpb24gdG8gaGFwcGVuIG11Y2ggbW9y ZSBxdWlja2x5Lg0KDQpBZHJpYW4sIEJlbm9pdCwgYW5kIEkgYXJlIHBsYW5uaW5nIG9uIHdyaXRp bmcgdXAgYSBqb2IgZGVzY3JpcHRpb24gZm9yIGEgc2VjcmV0YXJ5IHRvIGhlbHAgd2l0aCB0aGlz IG1haWxpbmcgbGlzdCBhbmQgdGhlIGNvb3JkaW5hdGlvbiBhbmQgY29tbXVuaWNhdGlvbiBuZWNl c3NhcnkuICBOZWVkbGVzcyB0byBzYXksIGlmIHlvdSB3b3VsZCBhbHJlYWR5IGxpa2UgdG8gdm9s dW50ZWVyLCBwbGVhc2UgZW1haWwgbWUgd2l0aCBkZXRhaWxzLg0KDQpUbyBhaWQgaW4gZmluZGlu ZyB0aGUgdmFyaW91cyBZQU5HIG1vZGVscyB0aGF0IHJlbGF0ZSB0byByb3V0aW5nIGluIHNvbWUg d2F5LCBJJ3ZlIGluY2x1ZGVkIGEgbGlzdCBiZWxvdy4gIFRoaXMgbGlzdCB3YXMgZ2VuZXJhdGVk IGJ5IGxvb2tpbmcgdGhyb3VnaCBhIHNlYXJjaCBvZiBkcmFmdHMgYmFzZWQgb24gdGhlIGtleXdv cmQgWUFORyBwbHVzIGEgY291cGxlIEkyUlMgZHJhZnRzIEkgd2FzIGFscmVhZHkgZmFtaWxpYXIg d2l0aC4gIEkgYXBvbG9naXplIGlmIEkgbWlzc2VkIGFueSAoYW5kIGVuY291cmFnZSBjb25zaXN0 ZW50IG5hbWluZyApLg0KDQpkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNTxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8+ DQpkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZy8+DQpkcmFmdC1pZXRmLWky cnMtcmliLWluZm8tbW9kZWwtMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVsLz4gKFlBTkcgbW9kZWwgY29taW5nIHZlcnkgc29v bikNCg0KZHJhZnQtYm9nZGFub3ZpYy1uZXRtb2QtYWNsLW1vZGVsLTAyPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLWFjbC1tb2RlbC8+ICht b3JlIGdlbmVyYWwgdGhhbiByb3V0aW5nLCBzbyBjdXJyZW50bHkgcHJvZ3Jlc3NpbmcgaW4gTkVU TU9EKQ0KZHJhZnQtY2hlbi1tcGxzLWxkcC15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtbGRwLXlhbmctY2ZnLz4NCmRyYWZ0LWNoZW4t bXBscy10ZS15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1jaGVuLW1wbHMtdGUteWFuZy1jZmcvPg0KZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmst dG9wby0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jbGVtbS1pMnJz LXlhbmctbmV0d29yay10b3BvLz4NCmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10 b3BvLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1z dXBhLXlhbmctbmV0d29yay10b3BvLz4gKHRhcmdldGVkIGF0IGFuIHVuYXBwcm92ZWQgQm9GLCBv dmVybGFwIHdpdGggSTJSUykNCmRyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAw PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaTJycy1sMi1uZXR3 b3JrLXRvcG9sb2d5Lz4NCmRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDA8aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2Rl bC8+DQpkcmFmdC1oYW8tdHJpbGwteWFuZy0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oYW8tdHJpbGwteWFuZy8+IChtYXkgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lk ZXIgZnJvbSB0aGUgSVNJUyBvdmVybGFwKQ0KZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0tMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0vPg0K ZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8tMDA8aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8vPiAoYW5v dGhlciB0b3BvbG9neSBtb2RlbCkNCmRyYWZ0LWxpdS1waW0taWdtcC1tbGQteWFuZy0wMDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmcv Pg0KZHJhZnQtbGl1LXBpbS15YW5nLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxpdS1waW0teWFuZy8+DQpkcmFmdC1wZW5uby1zZmMteWFuZy0wODxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1zZmMteWFuZy8+DQpkcmFmdC1wa2Qt cGNlLXBjZXAteWFuZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1w a2QtcGNlLXBjZXAteWFuZy8+DQpkcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLTAwPGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vPg0KZHJh ZnQtd2FuZy1pMnJzLWlzaXMtZG0tMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd2FuZy1pMnJzLWlzaXMtZG0vPg0KZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0tMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0vPg0K ZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2VsZXRpb24tMDM8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteWFuZy10cmlsbC1wYXJlbnQtc2VsZXRpb24vPg0KZHJhZnQteWV1 bmctbmV0bW9kLW9zcGYtMDI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt eWV1bmctbmV0bW9kLW9zcGYvPg0KZHJhZnQtemhhbmctbXBscy10cC15YW5nLW9hbS0wMDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2Ft Lz4NCmRyYWZ0LXpoYW5nLW52bzMteWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtemhhbmctbnZvMy15YW5nLWNmZy8+DQpkcmFmdC16aGRhbmtpbi1uZXRt b2QtYmdwLWNmZy0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGRh bmtpbi1uZXRtb2QtYmdwLWNmZy8+DQpkcmFmdC16aHVhbmctbDJ2cG4tZXZwbi15YW5nLWNmZy0w MDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctbDJ2cG4tZXZw bi15YW5nLWNmZy8+DQpkcmFmdC16aHVhbmctbDJ2cG4teWFuZy1jZmctMDA8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLz4NCmRyYWZ0 LXpodWFuZy1sM3Zwbi15YW5nLWNmZy0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC16aHVhbmctbDN2cG4teWFuZy1jZmcvPg0KDQpJIGhvcGUgdGhhdCByZWFkaW5nIHNv bWUgb2YgdGhlIGFib3ZlIChhdCBsZWFzdCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0x NTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0 aW5nLWNmZy8+KSB3aWxsIHN0YXJ0IHRvIGluc3BpcmUgaWRlYXMgYW5kIGNvbmNyZXRlIGRpc2N1 c3Npb24gYWJvdXQgd2hhdCBjb29yZGluYXRpb24gYmV0d2VlbiBtb2RlbHMgYW5kIGRyYWZ0cyBp cyBuZWVkZWQuDQoNClRoYW5rcywNCkFsaWENCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA84601607nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5D aGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJGRCBjaGFpcnMgaGF2ZSBjYWxsZWQgZm9yIGEgZGVz aWduIHRlYW0gdG8gZGVmaW5lIEJGRCBZQU5HIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgbWlnaHQgYmUgZ29vZCBmb3IgeW91IHRvIHRhbGsgd2l0 aCBCRkQgY2hhaXJzIGFuZCBjb29yZGluYXRlIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgZGVzaWdu IHRlYW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQt Ym91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij53YW5neml0YW88YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9z cGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yNzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+ IDE4OjE5PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPGJyPg0KPC9z cGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IGFrYXRsYXNAZ21haWwuY29tPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbUnRnLXlhbmctY29v cmRdIFZlcnkgYWN0aXZlIGRpc2N1c3Npb24gYW5kIGNvb3JkaW5hdGlvbiBvZiBZQU5HIG1vZGVs cyBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkZZSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQiPkhlcmUgaXMgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyBCRkQgWUFORyBtb2RlbC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmcteWFuZy1iZmQtb2FtLyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy15YW5nLWJmZC1vYW0vPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LU1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiBSdGcteWFuZy1jb29yZCBbPGEgaHJlZj0ibWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbGlhIEF0bGFzPGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJF Ti1VUyI+MjQ8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiA2OjA1PGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IDxhIGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+DQpSdGcteWFuZy1j b29yZEBpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQmVub2l0IENsYWlzZTxicj4NCjwvc3Bh bj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBbUnRnLXlhbmctY29vcmRdIFZlcnkgYWN0aXZlIGRpc2N1c3Npb24gYW5kIGNvb3JkaW5h dGlvbiBvZiBZQU5HIG1vZGVscyBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5GaXJzdCwgSSBhbSBhYnNvbHV0ZWx5IGRlbGlnaHRlZCB0byBkaXNjb3Zl ciB0aGF0IHRoaXMgY29vcmRpbmF0aW9uIGxpc3QgaGFzIDEzOSBzdWJzY3JpYmVycyEmbmJzcDsg SSBhbSBxdWl0ZSBlbmNvdXJhZ2VkIHRoYXQgd2Ugd2lsbCBiZSBhYmxlIHRvIHVzZSB0aGlzIG1h aWxpbmcgbGlzdCBmb3IgbWVhbmluZ2Z1bCBkaXNjdXNzaW9uIGFuZCBjb29yZGluYXRpb24uJm5i c3A7IFdlbGNvbWUgYW5kDQogcGxlYXNlIHN0YXJ0IHRhbGtpbmchPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VG93YXJkcyB0aGF0IHB1cnBvc2UuLi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaXRoIGEgZmV3 IFdHIGRyYWZ0cyBhbmQgb3ZlciAyMCBpbmRpdmlkdWFsIGRyYWZ0cyB0aGF0IG1heSBvdmVybGFw IGFuZCBzaG91bGQgc2hhcmUgc29tZSBjb21tb24gYWJzdHJhY3Rpb25zIGFuZCBncm91cGluZ3Ms IHdlIHJlYWxseSBuZWVkIHRvIHN0YXJ0IGNvb3JkaW5hdGluZy4gJm5ic3A7IFRoaXMgaXMgYSBz aWduaWZpY2FudCBleHBsb3Npb24gb2YgZHJhZnRzIGFuZCBpbnRlcmVzdA0KIGluIHRoZSBsYXN0 IDkgbW9udGhzIC0gYW5kIHdlIGFyZSBpbnRlcmFjdGluZywgYXQgbGVhc3QgaW4gcGFydCwgd2l0 aCBhIGNvbW11bml0eSB0aGF0IE5FRURTIHN0YW5kYXJkaXphdGlvbiB0byBoYXBwZW4gbXVjaCBt b3JlIHF1aWNrbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkFkcmlhbiwgQmVub2l0LCBhbmQgSSBhcmUgcGxhbm5pbmcgb24gd3JpdGlu ZyB1cCBhIGpvYiBkZXNjcmlwdGlvbiBmb3IgYSBzZWNyZXRhcnkgdG8gaGVscCB3aXRoIHRoaXMg bWFpbGluZyBsaXN0IGFuZCB0aGUgY29vcmRpbmF0aW9uIGFuZCBjb21tdW5pY2F0aW9uIG5lY2Vz c2FyeS4mbmJzcDsgTmVlZGxlc3MgdG8gc2F5LCBpZiB5b3Ugd291bGQgYWxyZWFkeSBsaWtlIHRv IHZvbHVudGVlciwNCiBwbGVhc2UgZW1haWwgbWUgd2l0aCBkZXRhaWxzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGFpZCBpbiBmaW5k aW5nIHRoZSB2YXJpb3VzIFlBTkcgbW9kZWxzIHRoYXQgcmVsYXRlIHRvIHJvdXRpbmcgaW4gc29t ZSB3YXksIEkndmUgaW5jbHVkZWQgYSBsaXN0IGJlbG93LiZuYnNwOyBUaGlzIGxpc3Qgd2FzIGdl bmVyYXRlZCBieSBsb29raW5nIHRocm91Z2ggYSBzZWFyY2ggb2YgZHJhZnRzIGJhc2VkIG9uIHRo ZSBrZXl3b3JkIFlBTkcgcGx1cyBhIGNvdXBsZSBJMlJTIGRyYWZ0cw0KIEkgd2FzIGFscmVhZHkg ZmFtaWxpYXIgd2l0aC4mbmJzcDsgSSBhcG9sb2dpemUgaWYgSSBtaXNzZWQgYW55IChhbmQgZW5j b3VyYWdlIGNvbnNpc3RlbnQgbmFtaW5nICkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0x NTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy15YW5nLWlzaXMtY2ZnLyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWlldGYtaXNpcy15 YW5nLWlzaXMtY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1pbmZv LW1vZGVsLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRy YWZ0LWlldGYtaTJycy1yaWItaW5mby1tb2RlbC0wMzwvc3Bhbj48L2E+Jm5ic3A7KFlBTkcgbW9k ZWwgY29taW5nDQogdmVyeSBzb29uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYm9nZGFub3ZpYy1uZXRtb2QtYWNsLW1vZGVsLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLWFjbC1tb2Rl bC0wMjwvc3Bhbj48L2E+Jm5ic3A7KG1vcmUgZ2VuZXJhbA0KIHRoYW4gcm91dGluZywgc28gY3Vy cmVudGx5IHByb2dyZXNzaW5nIGluIE5FVE1PRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1tcGxzLWxkcC15 YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWNoZW4tbXBscy1sZHAt eWFuZy1jZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmcv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtY2hl bi1tcGxzLXRlLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2xlbW0taTJycy15 YW5nLW5ldHdvcmstdG9wby8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWNsZW1t LWkycnMteWFuZy1uZXR3b3JrLXRvcG8tMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jb250cmVy YXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRy YWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLTAwPC9zcGFuPjwvYT4mbmJzcDso dGFyZ2V0ZWQgYXQgYW4gdW5hcHByb3ZlZA0KIEJvRiwgb3ZlcmxhcCB3aXRoIEkyUlMpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWRvbmctaTJycy1sMi1uZXR3b3JrLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+ZHJhZnQtZG9uZy1pMnJzLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmct bW9kZWwtMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8tdHJpbGwteWFuZy8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LWhhby10cmlsbC15YW5nLTAxPC9zcGFuPjwvYT4mbmJz cDsobWF5IGJlIGludGVyZXN0aW5nIHRvIGNvbnNpZGVyIGZyb20gdGhlIElTSVMgb3ZlcmxhcCk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaGFyZXMtaTJycy1iZ3AtZG0vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5kcmFmdC1oYXJlcy1pMnJzLWJncC1kbS0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1u ZXRtb2QteWFuZy1hYnN0cmFjdC10b3BvLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJh ZnQtbGl1LW5ldG1vZC15YW5nLWFic3RyYWN0LXRvcG8tMDA8L3NwYW4+PC9hPiZuYnNwOyhhbm90 aGVyIHRvcG9sb2d5IG1vZGVsKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtcGltLWlnbXAtbWxkLXlhbmcvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ZHJhZnQtbGl1LXBp bS1pZ21wLW1sZC15YW5nLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXBpbS15YW5nLyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtbGl1LXBpbS15YW5nLTAwPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcGVubm8tc2ZjLXlhbmcvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5kcmFmdC1wZW5uby1zZmMteWFuZy0wODwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBrZC1wY2Ut cGNlcC15YW5nLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYi PmRyYWZ0LXBrZC1wY2UtcGNlcC15YW5nLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et bnZvMy15YW5nLW9hbS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXRpc3NhLW52 bzMteWFuZy1vYW0tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLWkycnMtaXNpcy1kbS8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC13YW5n LWkycnMtaXNpcy1kbS0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctaTJycy1vc3BmLWRt LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtd2FuZy1pMnJzLW9zcGYtZG0tMDA8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW5nLXRyaWxsLXBhcmVudC1zZWxldGlvbi8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC15YW5nLXRyaWxs LXBhcmVudC1zZWxldGlvbi0wMzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlldW5nLW5ldG1vZC1v c3BmLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0 LXlldW5nLW5ldG1vZC1vc3BmLTAyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctbXBscy10 cC15YW5nLW9hbS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZG Ij5kcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emhhbmctbnZvMy15YW5nLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXpo YW5nLW52bzMteWFuZy1jZmctMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGRhbmtpbi1uZXRt b2QtYmdwLWNmZy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDojRURGNUZG Ij5kcmFmdC16aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy0wMTwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXpodWFuZy1sMnZwbi1ldnBuLXlhbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozti YWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXpodWFuZy1sMnZwbi1ldnBuLXlhbmctY2ZnLTAwPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+ZHJhZnQtemh1YW5nLWwydnBuLXlhbmctY2ZnLTAwPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemh1YW5nLWwzdnBuLXlhbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OztiYWNrZ3JvdW5kOiNFREY1RkYiPmRyYWZ0LXpodWFuZy1sM3Zwbi15YW5nLWNmZy0wMDwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGhvcGUgdGhhdCByZWFkaW5nIHNvbWUgb2YgdGhlIGFib3ZlIChhdCBsZWFzdCZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9k LXJvdXRpbmctY2ZnLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOiNFREY1 RkYiPmRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTE1PC9zcGFuPjwvYT4pDQogd2lsbCBz dGFydCB0byBpbnNwaXJlIGlkZWFzIGFuZCBjb25jcmV0ZSBkaXNjdXNzaW9uIGFib3V0IHdoYXQg Y29vcmRpbmF0aW9uIGJldHdlZW4gbW9kZWxzIGFuZCBkcmFmdHMgaXMgbmVlZGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5BbGlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA84601607nkgeml501mbschi_-- From nobody Mon Oct 27 05:43:46 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5861A906D; Mon, 27 Oct 2014 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nOxGmwOtLL2C; Mon, 27 Oct 2014 05:43:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F21A8AD9; Mon, 27 Oct 2014 05:43:32 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CD9C928DB4DC; Mon, 27 Oct 2014 08:43:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> Date: Mon, 27 Oct 2014 08:43:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/TxjBnqdvJLZy5iAyjHuyr21-sUk Cc: Rtg-yang-coord@ietf.org, david.sinicrope@ericsson.com, lime@ietf.org, netmod@ietf.org, Tom Taylor Subject: Re: [Rtg-yang-coord] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 12:43:35 -0000 > On Oct 26, 2014:8:34 PM, at 8:34 PM, Adrian Farrel = wrote: >=20 > [Adding Netmod, but removing MPLS] >=20 > A good pointer, Tom, thanks. >=20 > The liaison seems to request review and feedback, but I don't see a = response > from Netmod and it looks like the MEF Technical Committee is meeting = today and > in the next few days.=20 We have a draft response that we crafted and posted to the = mailing list, but it seems never was sent out. I will post now to the = list to see if there are any more comments. > I think that if LIME had existed at the time the liaison arrived, it = is probable > that it would also have been a recipient.=20 Should NETMOD respond since it was addressed to us or will LIME = respond? --Tom >=20 > We should certainly strive to work with MEF and build on existing = work. >=20 > Adrian >=20 >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >> Sent: 27 October 2014 00:16 >> To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson'; = lime@ietf.org; > Rtg- >> yang-coord@ietf.org >> Cc: mpls@ietf.org >> Subject: Re: [Rtg-yang-coord] hopefully a simple question >>=20 >> This might be a good time to remind/alert people about the liaison >> statement received from the MEF regarding >> draft-tissa-lime-yang-oam-model. It can be found at >>=20 >> = https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- >> netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf >>=20 >> Tom Taylor >>=20 >> On 26/10/2014 8:03 PM, Adrian Farrel wrote: >>> The intention of LIME (who knows whether it is achievable?) is to = produce a >>> single YANG module that provides a generic way in to OAM across all = IETF >>> technologies. >>>=20 >>> There are certainly a number of core concepts, configurable items, = and >>> reportable things that can be stated in a technology independent = way. >>>=20 >>> LIME has as a deliverable a set of applicability statements showing = how the >>> generic module is applied to different IETF OAM technologies. >>>=20 >>> I should not be surprised if technology-specific modules are also = required. > I >>> think LIME hopes that these will build on the generic module and not > reinvent. I >>> assume this will be through augmentation. And I assume the work will = be done >> by >>> the WGs that own the technologies (where those WGs exist). >>>=20 >>> I don't think I understand your tree. Why would "RSVP-TE OAM" live = under >> rsvp-te >>> under mpls? The OAM is going to be standard mpls oam, but the = concepts >> (MIPs, >>> MEPs, on/off, failure found, etc.) are general. >>>=20 >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of >>>> Gregory Mirsky >>>> Sent: 26 October 2014 18:51 >>>> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org >>>> Cc: mpls@ietf.org >>>> Subject: Re: [Rtg-yang-coord] hopefully a simple question >>>>=20 >>>> Hi Loa, >>>> I think that your question is not simple at all and it would be a = great to >>> discuss >>>> how Generic OAM proposal is related to MPLS OAM at the meeting. >>>> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, = Segment >>>> Routing (as far as transport layer for the latter two) OAMs but one = MPLS > OAM >>>> with extensions/special cases for IP/MPLS, MPLS-TP and Segment = Routing >>>> networks. >>>>=20 >>>> Regards, >>>> Greg >>>> -----Original Message----- >>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of >>>> Loa Andersson >>>> Sent: Sunday, October 26, 2014 3:14 AM >>>> To: lime@ietf.org; Rtg-yang-coord@ietf.org >>>> Subject: [Rtg-yang-coord] hopefully a simple question >>>>=20 >>>> Folks, >>>>=20 >>>> I have what I hope is a simple question, and that it will only = reveal that > I'm >>> not up >>>> to speed on yang. >>>>=20 >>>> I trying to figure out the relationship between the generic yang = models in >>> e.g. >>>> draft-tissa-lime-yang-oam-model and the specific models we do for = different >>>> variants of e.g. mpls oam. >>>>=20 >>>> I guess we have a structure more or less like this >>>>=20 >>>> mpls >>>> | >>>> |- ldp >>>> | |-ldp oam >>>> | >>>> |- rsvp-te >>>> | | >>>> | |- rsvp-te oam >>>> | >>>> |- lsp ping >>>> | | >>>> | |- lsp ping oam >>>> | >>>> |- etc >>>>=20 >>>>=20 >>>> Where does the generic work fit in? >>>>=20 >>>> /Loa >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Mon Oct 27 06:23:51 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E241A6F9C; Sun, 26 Oct 2014 20:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.122 X-Spam-Level: X-Spam-Status: No, score=-11.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 omh626CCYTza; Sun, 26 Oct 2014 20:00:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B701A1A7E; Sun, 26 Oct 2014 20:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5030; q=dns/txt; s=iport; t=1414378851; x=1415588451; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+OOhY2yJCiK0KPdOB3j73w1YRQ71JnQzT7uSnMnjY3A=; b=HLSjIvATbSCodDKuG3mO32wPrc1lbdyKUddP+NienKe/JP1ZOSytdr8z zgKBGVtjTCjgTdsXRcTzPYA7026zdYmFU9bgFdJJJFZarbzENJfURhpQ2 Oar95SxihdAAYrNbqICodu2sPLOGQG5BAR2oMv/iiNz5e5SlWq28Dbu82 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcGAL+0TVStJA2D/2dsb2JhbABSAQmDDlRYBIMCyXAKh00CG3IWAX2EAgEBAQQBAQExNwMEEwICAgEGAg4DBAEBBQYdBQICGQwLFAkIAgQBEAIIiDkNl0KcWQiUGAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEgSSOfgYBCgECHRYiBoJtOoEeAQSSB4RInUCDeEErgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,792,1406592000"; d="scan'208";a="90477453" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP; 27 Oct 2014 03:00:50 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9R30of6029257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 03:00:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.180]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 22:00:49 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , Loa Andersson , "lime@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: [Lime] hopefully a simple question Thread-Index: AQHP8QWrzrV1e78a/kqkqOGqT6cpUJxDgxGA//+6fuA= Date: Mon, 27 Oct 2014 03:00:48 +0000 Message-ID: References: <544CC985.9060808@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.179] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/CooqbyJPdFwdInEZDzA5PcWYfZ8 X-Mailman-Approved-At: Mon, 27 Oct 2014 06:23:37 -0700 Subject: Re: [Rtg-yang-coord] [Lime] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 03:00:59 -0000 VGhhbmtzIFFpbiBmb3IgdGhlIHNwb3Qgb24gZGV0YWlsIHJlcGx5LCANCg0KTG9hIGV0LmFsIA0K DQpMZXQgbWUgYWRkIG9uIHRvIHdoYXQgUWluIHN0YXRlZC4gV2UgbmVlZCB0byBhcHByb2FjaCB0 aGlzIGluIHRvcCBkb3duIG1hbm5lci4gQXQgdGhlIHRvcCBvZiB0aGUgbGF5ZXIgaXMgdGhlIGJh c2UgWUFORyBtb2RlbCAoYWthIEdlbiBZQU5HKQ0KDQpXaGF0IGlzIHByZXNlbnRlZCBpbiBUaXNz YS15YW5nIGlzIHRoZSBmYXVsdCBtYW5hZ2VtZW50IG1vZGVsLCB0aGF0IGlzIGluZGVwZW5kZW50 IG9mIHRoZSB1bmRlcmx5aW5nIE9BTSBwcm90b2NvbHMuIEluIGRlc2lnbmluZyB0aGUgbW9kZWwg d2UgaGF2ZSB1c2VkIHBvd2VyIG9mIFlBTkcgc28gdGhhdCBldmVyeSBlbGVtZW50IGlzIGF1Z21l bnRhYmxlLiBFLmcuIGluc3RlYWQgb2YgZW51bXMgd2UgdXNlIGlkZW50aXlyZWZzLCBpbnN0ZWFk IG9mIHR5cGVkZWZzIHdoZXJlIGFwcGxpY2FibGUgd2UgdXNlIGNvbWJpbmF0aW9uIG9mIGNob2lj ZS9jYXNlIHN0YXRlbWVudC4gVGhlIGlkZWEgaXMgZXZlcnkgYnJhbmNoIGluIHRoZSBkYXRhIG1v ZGVsIGlzIGV4dGVuc2libGUuDQoNClNlY29uZCBsYXllciBpcyBob3cgdGhpcyBjYW4gYmUgZXh0 ZW5kZWQgdG8gb3RoZXIgdGVjaG5vbG9naWVzLiBFeC4gQXJlIA0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtICAgDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGlzc2EtbnZvMy15YW5nLW9hbS0wMC0wMA0KDQoNClRoZSBtb2Rl bCBwcm9wb3NlZCBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8gUkZDIDQzNzkgIkRldGVjdGluZyBN dWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hlZCAoTVBMUykgRGF0YSBQbGFuZSBGYWlsdXJlcyIN Cg0KDQpZb3UgaGF2ZSByZWZlcnJlZCB0byBNUExTIExEUCBPQU0sIHJzdnAtdGUtb2FtIGFuZCBz byBvbi4gVGhlc2Ugc291bmQgbW9yZSBvZiBjb250cm9sIHBsYW5lIGFzcGVjdHMuIEFyZSB0aGVy ZSBhbnkgcHVibGljYXRpb25zIHRoYXQgcHJlc2VudCBNUExTIExEUCBPQU0sIHJzdnAtdGUgT0FN LCB3b3VsZCBsaWtlIHRvIHRha2UgYSBsb29rIGJlZm9yZSBjb21tZW50Lg0KDQpPdXIgb2JqZWN0 aXZlIGhlcmUgaW4gVGlzc2EteWFuZzsgaXMgdG8gY3JlYXRlIGEgWUFORyBtb2RlbCB0aGF0IHRo YXQgY292ZXJzIGV4aXN0aW5nIE9BTSwgYW5kIGRhdGEgbW9kZWwgdG8gYmUgZXh0ZW5zaWJsZSBm b3IgZnV0dXJlIGV4dGVuc2lvbnMuDQoNCk9uZSBvZiB0aGUga2V5IGNoYXJ0ZXIgZWxlbWVudHMg b2YgTElNRSBpcyB0byBjb21lIHVwIHdpdGggR3VpZGVsaW5lcyBmb3IgT0FNIGRlc2lnbmVycy4g IFRoaXMgaXMgdG8gZ3VpZGUgZnV0dXJlIE9BTSBkZXNpZ25lcnMgdG8gY29uc2lkZXIvY29tcGxp YW50IHdpdGggdGhlIHVtYnJlbGxhIFlBTkcgbW9kZWwuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTGltZSBbbWFpbHRvOmxpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFFpbiBXdQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDI2LCAyMDE0IDY6NTIgUE0NClRv OiBMb2EgQW5kZXJzc29uOyBsaW1lQGlldGYub3JnOyBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtMaW1lXSBob3BlZnVsbHkgYSBzaW1wbGUgcXVlc3Rpb24NCg0KSXQgaXMg c3RyYW5nZSB0byBzdWJzdW1lIExEUCBPQU0gYW5kIFJTVlAtdGUgT0FNIHVuZGVyIE1QTFMgT0FN Lg0KTERQIE9BTSBhbmQgUlNWUC10ZSBPQU0gYXJlIG5vdCBkYXRhIHBsYW5lIE9BTSB0b29scywg cmF0aGVyIHRoYW4gdGhleSBhcmUgY29udHJvbCBwbGFuZSBtYWludGVuYW5jZSB0b29scy4NCldo ZW4gd2UgdGFsayBhYm91dCBNUExTIE9BTSAsIGl0IGlzIHVzdWFsbHkgcmVmZXJyZWQgdG8gZGF0 YSBwbGFuZSB0b29scywgaS5lLiwgTFNQIFBpbmcgT0FNLg0KUkZDNzI3NiBwcm92aWRlcyBhIGdv b2Qgc3VtbWFyaXphdGlvbiBmb3IgdmFyaW91cyBPQU0gdG9vbHMuDQoNClNlY29uZGx5LCBJIHRo aW5rIGlmIHRoZXJlIGFyZSBzb21lIHN1Yi10ZWNobm9sb2dpZXMgdGhhdCBhcmUgdW5kZXIgTVBM UyBPQU0sIHRlY2hub2xvZ3kgc3ViLXR5cGVzIGNhbiBhdWdtZW50IHRoZSBiYXNlIG1vZGVsIHdp dGggYm90aCB0ZWNobm9sb2d5IHR5cGUgc3BlY2lmaWNzIGFuZCB0ZWNobm9sb2d5IHN1Yi10eXBl IHNwZWNpZmljcywgaS5lLiwgdXNlIGlkZW50aXR5IHRlY2hub2xvZ3ktdHlwZXMgZGVmaW5lZCBp biB0aGUgYmFzZSBtb2RlbCBhbmQgdGVjaG5vbG9neSBzdWIgdHlwZSBkZWZpbmVkIGluIHRoZSB0 ZWNobm9sb2d5IHNwZWNpZmljIG1vZGVsIHRvIGlkZW50aWZ5IHNwZWNpZmljIHN1Yi0gdGVjaG5v bG9neSB0eXBlIHdpdGhpbiBzcGVjaWZpYyB0ZWNobm9sb2d5IHR5cGUuDQoNClJlZ2FyZHMhDQot UWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTGltZSBbbWFpbHRvOmxpbWUtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29uDQq3osvNyrG85DogMjAxNMTqMTDUwjI2yNUg MTg6MTQNCsrVvP7IyzogbGltZUBpZXRmLm9yZzsgUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCtb3 zOI6IFtMaW1lXSBob3BlZnVsbHkgYSBzaW1wbGUgcXVlc3Rpb24NCg0KRm9sa3MsDQoNCkkgaGF2 ZSB3aGF0IEkgaG9wZSBpcyBhIHNpbXBsZSBxdWVzdGlvbiwgYW5kIHRoYXQgaXQgd2lsbCBvbmx5 IHJldmVhbCB0aGF0IEknbSBub3QgdXAgdG8gc3BlZWQgb24geWFuZy4NCg0KSSB0cnlpbmcgdG8g ZmlndXJlIG91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGdlbmVyaWMgeWFuZyBtb2Rl bHMgaW4gZS5nLiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsIGFuZCB0aGUgc3BlY2lm aWMgbW9kZWxzIHdlIGRvIGZvciBkaWZmZXJlbnQgdmFyaWFudHMgb2YgZS5nLiBtcGxzIG9hbS4N Cg0KSSBndWVzcyB3ZSBoYXZlIGEgc3RydWN0dXJlIG1vcmUgb3IgbGVzcyBsaWtlIHRoaXMNCg0K bXBscw0KICB8DQogIHwtIGxkcA0KICB8ICAgfC1sZHAgb2FtDQogIHwNCiAgfC0gcnN2cC10ZQ0K ICB8ICAgfA0KICB8ICAgfC0gcnN2cC10ZSBvYW0NCiAgfA0KICB8LSBsc3AgcGluZw0KICB8ICAg fA0KICB8ICAgfC0gbHNwIHBpbmcgb2FtDQogIHwNCiAgfC0gZXRjDQoNCg0KV2hlcmUgZG9lcyB0 aGUgZ2VuZXJpYyB3b3JrIGZpdCBpbj8NCg0KL0xvYQ0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAg ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlv ciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQpIdWF3ZWkg VGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxpbWUgbWFp bGluZyBsaXN0DQpMaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpMaW1lIG1haWxpbmcgbGlzdA0KTGltZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9saW1lDQo= From nobody Mon Oct 27 06:23:54 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B421A1A93; Sun, 26 Oct 2014 21:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jfZTNRK7Rh2e; Sun, 26 Oct 2014 21:13:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEB61A038C; Sun, 26 Oct 2014 21:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5933; q=dns/txt; s=iport; t=1414383197; x=1415592797; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xo6D1SC2L0WcejSVSiDVjnyXs7pxhYcZ6YVEJn1I1wQ=; b=PHpsdbUQppFQ7uhLC4F71YsqvkJU1bpZCm2JT+jPnuSXkNg1qmWpDO0x Ge/ybmbXi+HRp+8joz1o/5fdokrk74TJTWbsqL9fWf+DmYRZSpwcdkYbV 4h0eBKPadboqdyr7AytlKlAWwI1iFzJ9QhVoOw31xaW0V4W6KLABwk7RS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGbFTVStJA2F/2dsb2JhbABcgw5UWATMeAqGeVQCgQ0WAX2EAgEBAQMBAQEBNzEDBAcMAgICAQgRBAEBAQoUCQcbBgYLFAkIAgQBDQUIiCQDCQkNwXYNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASOSoFYEQEfMQcGgyeBHgWPaYIehEiFAYNCjiCCXYQAg3hsAYEOOYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,792,1406592000"; d="scan'208";a="90526441" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 27 Oct 2014 04:13:16 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9R4DF5Y006827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 04:13:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.180]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 23:13:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: "adrian@olddog.co.uk" , "'Tom Taylor'" Thread-Topic: [Lime] [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8XszPy1WMZvrkEeOuB7qmsPVxpxDbFOA///nrxA= Date: Mon, 27 Oct 2014 04:13:14 +0000 Message-ID: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/W8hakfgQSQNxuNEhEQ7UBiQaD-Q X-Mailman-Approved-At: Mon, 27 Oct 2014 06:23:35 -0700 Cc: "Rtg-yang-coord@ietf.org" , "lime@ietf.org" , "netmod@ietf.org" , "david.sinicrope@ericsson.com" Subject: Re: [Rtg-yang-coord] [Lime] hopefully a simple question X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:13:19 -0000 Thanks Adrian. It is good to see MEF is interested, both MEF and what is presented are us= ing the same root model. However, what is presented in Tissa-yang differs in, 1. It is not tied to Ethernet 2. All of the YANG structures have been revised to be augmentable So, two YANG models are no longer identical, except they share the same roo= t model. When doing TRILL OAM we did a Liaison with IEEE 8021 committee and it was e= xtremely productive and I am sure it will be like that with Liaison with t= he MEF. -----Original Message----- From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, October 26, 2014 5:34 PM To: 'Tom Taylor' Cc: Rtg-yang-coord@ietf.org; lime@ietf.org; netmod@ietf.org; david.sinicrop= e@ericsson.com Subject: Re: [Lime] [Rtg-yang-coord] hopefully a simple question [Adding Netmod, but removing MPLS] A good pointer, Tom, thanks. The liaison seems to request review and feedback, but I don't see a respons= e from Netmod and it looks like the MEF Technical Committee is meeting toda= y and in the next few days.=20 I think that if LIME had existed at the time the liaison arrived, it is pro= bable that it would also have been a recipient.=20 We should certainly strive to work with MEF and build on existing work. Adrian > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 27 October 2014 00:16 > To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson';=20 > lime@ietf.org; Rtg- > yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question >=20 > This might be a good time to remind/alert people about the liaison=20 > statement received from the MEF regarding=20 > draft-tissa-lime-yang-oam-model. It can be found at >=20 > https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- > netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf >=20 > Tom Taylor >=20 > On 26/10/2014 8:03 PM, Adrian Farrel wrote: > > The intention of LIME (who knows whether it is achievable?) is to=20 > > produce a single YANG module that provides a generic way in to OAM=20 > > across all IETF technologies. > > > > There are certainly a number of core concepts, configurable items,=20 > > and reportable things that can be stated in a technology independent wa= y. > > > > LIME has as a deliverable a set of applicability statements showing=20 > > how the generic module is applied to different IETF OAM technologies. > > > > I should not be surprised if technology-specific modules are also requi= red. I > > think LIME hopes that these will build on the generic module and not reinvent. I > > assume this will be through augmentation. And I assume the work will=20 > > be done > by > > the WGs that own the technologies (where those WGs exist). > > > > I don't think I understand your tree. Why would "RSVP-TE OAM" live=20 > > under > rsvp-te > > under mpls? The OAM is going to be standard mpls oam, but the=20 > > concepts > (MIPs, > > MEPs, on/off, failure found, etc.) are general. > > > > Adrian > > > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > >> Behalf Of Gregory Mirsky > >> Sent: 26 October 2014 18:51 > >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > >> Cc: mpls@ietf.org > >> Subject: Re: [Rtg-yang-coord] hopefully a simple question > >> > >> Hi Loa, > >> I think that your question is not simple at all and it would be a=20 > >> great to > > discuss > >> how Generic OAM proposal is related to MPLS OAM at the meeting. > >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN,=20 > >> Segment Routing (as far as transport layer for the latter two) OAMs=20 > >> but one MPLS OAM > >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment=20 > >> Routing networks. > >> > >> Regards, > >> Greg > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > >> Behalf Of Loa Andersson > >> Sent: Sunday, October 26, 2014 3:14 AM > >> To: lime@ietf.org; Rtg-yang-coord@ietf.org > >> Subject: [Rtg-yang-coord] hopefully a simple question > >> > >> Folks, > >> > >> I have what I hope is a simple question, and that it will only=20 > >> reveal that I'm > > not up > >> to speed on yang. > >> > >> I trying to figure out the relationship between the generic yang=20 > >> models in > > e.g. > >> draft-tissa-lime-yang-oam-model and the specific models we do for=20 > >> different variants of e.g. mpls oam. > >> > >> I guess we have a structure more or less like this > >> > >> mpls > >> | > >> |- ldp > >> | |-ldp oam > >> | > >> |- rsvp-te > >> | | > >> | |- rsvp-te oam > >> | > >> |- lsp ping > >> | | > >> | |- lsp ping oam > >> | > >> |- etc > >> > >> > >> Where does the generic work fit in? > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime From nobody Mon Oct 27 07:26:18 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3ED1AC418 for ; Mon, 27 Oct 2014 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 6ni-VlWZ9BgQ for ; Mon, 27 Oct 2014 07:25:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 741D71A9174 for ; Mon, 27 Oct 2014 07:25:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EEA69C221; Mon, 27 Oct 2014 10:25:30 -0400 (EDT) Date: Mon, 27 Oct 2014 10:25:30 -0400 From: Jeffrey Haas To: rtg-yang-coord@ietf.org Message-ID: <20141027142530.GC8111@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/WKgkJhlkURDr0fbsSLY45P40XTw Subject: [Rtg-yang-coord] Multiple drafts for yang models, design teams and IETF collaboration X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:25:32 -0000 I'd like to make a brief post about a topic that has generated some unexpected heat in a few working groups I am involved in: Multiple groups submitting yang models against IETF protocols. Currently, many working groups have either formal or informal design teams created to work on protocol specific yang modules. We have also seen similar drafts covering modeling for those same protocols appear as individual contributions. Those individual contributions have either been as actual proposals or sometimes used as references upon which to base other work where some proposal was needed. We were already aware that there has been some lack of visibility on the ongoing work. That was a strong motivator for creating this mailing list and seeding the wiki with some initial content. While there is often a sense of "ownership" of work, supported by the charters of working groups. the IETF isn't in the business of asking people to not publish drafts. If someone has a proposal to make, that is the form we ask them to make it in. After that, it is the business of the working group to consider additional proposals and whether to supplant existing work or whether to integrate it. Minimally, what we should do is realize that additional people are interested in working on a topic (yay!) and make sure that all of the involved parties are aware of each other. Contributors are reminded that once a draft has been adopted by a working group, it "belongs" to the group. While there is a strong tradition of having the original submitters continue work on it, the fate of the contributions goes to WG consensus. (See RFC 7221, for example.) Therefore the sense of "ownership" of the contribution really should be seen as "do good work for the IETF" rather than "my draft". In conclusion, don't let your first feels on seeing a "competing" draft be concern that things are motivated by politics. Instead, treat them as the gift they are - additional opinions from people motivated to Do The Work. -- Jeff (speaking as an individual contributor) From nobody Mon Oct 27 09:15:08 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E091A0027; Mon, 27 Oct 2014 09:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Szy2y9ZqHCEu; Mon, 27 Oct 2014 09:15:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920F41A00B0; Mon, 27 Oct 2014 09:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=571; q=dns/txt; s=iport; t=1414426479; x=1415636079; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AlEZ5DLEL+EFbo6hjmfOPZo+R/cPmnC78PC0ZuqjfxM=; b=FcZnNmTR+S4v5rQ69/u6ByB/MgeJizfCxUc9gSMmWkLJqrs2D+RC/sgj KdBCfixwe6EHFQeIPLEWS4Z58u22EL94RfQgcDHkGTLqY/5m6QxtNuAek D5RMDujsJhUlnbUo4ar2OVvsebHTrJfgsDKhkaFz+2sPIdXHYByec5zmh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJ1uTlStJA2D/2dsb2JhbABcgw5UWATNPodLAoEdFgF9hAQBBCcTUQEqFEImAQQBGgGIOA3LUgEBAQEGAQEBAR6QV4NlgR4FkgeHC5p9g3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,796,1406592000"; d="scan'208";a="366773741" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 27 Oct 2014 16:14:38 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9RGEcmd025043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 16:14:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 11:14:38 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: Cloud SLA YANG Model -> incorporating Peer Mount Semantics Thread-Index: Ac/yARgOU8G3L44cRoude7ZtRrZKuQ== Date: Mon, 27 Oct 2014 16:14:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/jUsL7Za3wCueIJ0XpFzqHlKOMCo Subject: [Rtg-yang-coord] Cloud SLA YANG Model -> incorporating Peer Mount Semantics X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:15:02 -0000 As promised, here is a link to a YANG model which incorporates Mount Semant= ics discussed in previous threads. =20 http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.= txt=20 The goal of this YANG model is to expose both Global and Device config in o= rder to simplify application design for a new class of service offerings. Also of interest in this model is that it shows how to append centrally cal= culated objects to remotely interface objects. (In this case, the remote i= nfo are YANG object from RFC 7223.) Thanks, Eric From nobody Wed Oct 29 04:50:00 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AE41A000E; Wed, 29 Oct 2014 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 qhi6Su5SZn7H; Wed, 29 Oct 2014 04:49:44 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C8D891A0019; Wed, 29 Oct 2014 04:49:44 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 432CC28E4175; Wed, 29 Oct 2014 07:49:44 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Oct 2014 07:49:43 -0400 Message-Id: <88F56A4D-804E-44CB-A2EF-28892985EC50@lucidvision.com> To: NETMOD Working Group , rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/tMkpz8276w_tRO1IaLqaBKUsiWU Cc: "Mehmet >> Ersue, Mehmet \(NSN - DE/Munich\)" , Dan Romascanu , "ext Bert Wijnen \(IETF\)" Subject: [Rtg-yang-coord] open config pushes open routing model X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 11:49:48 -0000 FYI. = https://www.sdncentral.com/news/google-openconfig-pushes-open-routing-mode= l/2014/10/ =E2=80=94Tom From nobody Wed Oct 29 06:57:45 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8621A00F9; Wed, 29 Oct 2014 06:57:33 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 TLF1Imw1hg1J; Wed, 29 Oct 2014 06:57:29 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932891A00C5; Wed, 29 Oct 2014 06:57:29 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so620250yhl.41 for ; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BwnTZECvvNx90SFa8DAr6GYoKbKePaGi2Tljee1FNSE=; b=ejPcU02K3h6nXB75q5f0yt4+l9WuY24COqQpk/HxuH4LcBHCSVPQjD+Nhzo8/1eR2G lMy4cbMZGcdtU1HPv2txhW/i+T8Qrk5WgjOSLD8AUtdOWbuv6FyRStSjW26LNMxY1IbL BrVSrrQQpelvyDgZsjeDg2i7cjBNbW+/7uMOcREY+vPmLQ1tln6OQSKtSijodumUgqm8 72X897EvA00A5AdWqsJW3uFx5XEx1gRkefJTVHmSXMmrGO5MnPwQ/VmG86kWNepTwuLp YDJpicN/ytw+RUX6hbuaKT0RhckTWhqqfOi6PODgcXhnauvPQb4QVwl564tXEmQQJdmS qyDA== MIME-Version: 1.0 X-Received: by 10.236.23.231 with SMTP id v67mr1925171yhv.48.1414591048880; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) Received: by 10.170.113.10 with HTTP; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) Date: Wed, 29 Oct 2014 09:57:28 -0400 Message-ID: From: Alia Atlas To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" , "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=089e0122a6caf8966a05069024f8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/f7XLc9U3q32QLcat9p3OLhJrkSg Subject: [Rtg-yang-coord] AD statement on development of IETF-standard routing-related YANG models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:57:33 -0000 --089e0122a6caf8966a05069024f8 Content-Type: text/plain; charset=UTF-8 Development of standardized YANG models has seriously increased this year. Of course, this is a good problem to have. There are close to 30 different drafts related to YANG models for routing; coordination between these drafts is necessary. NETMOD is also hard at work on a backwards-compatible YANG 1.1. From the IETF's experience with developing MIBs, it was critical to have the domain-area experts involved in writing and reviewing MIBs and we believe that it is similarly critical to situate the work on YANG models in the working groups where the appropriate domain-experts can be easily found. Actively encouraging and cultivating the review of those with the expertise in modeling with YANG and deep understanding of its features is also critical to the success of standardized YANG models. This expertise is found in the NETMOD working group and among the YANG doctors ( https://www.ietf.org/iesg/directorate/yang-doctors.html). We, as the Routing and Ops and Management Area Directors, would like to see work proceed as follows. 1) The mailing list, rtg-yang-coord@ietf.org, has been created to coordinate among the different routing YANG models and drafts. For instance, there may be common groupings to be defined, interactions between models to be determined, and so on. To facilitate this coordination work, we are developing a job description for a secretary for the mailing list and hope to appoint someone to that role. 2) Routing-related YANG models must be targeted for adoption at the appropriate WGs in the Routing Area. If the appropriate WG is unclear, please bring the question to the RTGWG and the rtg-yang-coord@ietf.org mailing list. RTGWG can either direct where the work goes or, if there is no appropriate other WG, make a decision about adopting the draft. 3) The NETMOD charter has been open to accept work item that don't fall under the responsibility of an existing WGs: The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. In case of routing-related YANG models, even if there are no responsible existing WG, it's expected that the standardization happens in the RTGWG. 4) It is common and expected that sometimes work needs to be discussed in multiple WGs, even though it is only adopted in one. Examples would include NETMOD discussing a model for OSPF to consider how it relates to draft-ietf-netmod-routing-cfg, RTGWG discussing draft-ietf-netmod-routing-cfg to encourage review and discussion about its use as a base for routing-related models, etc. 5) We have heard a strong desire from the community to rapidly encourage development of standardized YANG models. Towards that end, we expect and encourage more and frequent virtual interims (some probably joint between WGs). To have such a pace work well, we need authors, reviewers, and contributors to expect to spend time on this work on an on-going basis. 6) Since many YANG doctors also participate in NETMOD and since NETMOD is having weekly virtual interims, it may prove convenient to provide feedback on YANG models in this forum. When done so, to ensure the interested parties are aware of the relevant models to be discussed and can arrange their schedules to call in, the agenda should be forwarded with at least a week's to the rtg-yang-coord@ietf.org and to the relevant WGs. When the virtual interim is used to provide YANG doctor feedback, preference should be given to drafts already adopted by a WG; discussing one model does not imply partiality or a request to the WG appropriate to consider adopting the draft. 7) To provide a common location to find proposed YANG models and be able to verify their accuracy, Tom Nadeau, one of the NETMOD chairs, has set up a GitHub repository at: https://github.com/YangModels/yang. All work contributed to it is subject to the IETF Contributions policy, as summarized via the very very familiar IETF Note Well. 8) For the second IETF meeting in a row, a "YANG Advice and Editing Session" (http://www.ietf.org/meeting/91/tutorials/yang-session.html) is organized on the Sunday before the IETF meeting. This is your chance to sit down with a YANG doctor and to get feedback on your YANG module. If you have any questions, please let us know. Regards, Alia, Benoit, Adrian, & Joel --089e0122a6caf8966a05069024f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Development of standardized YANG models has seriou= sly increased this year.=C2=A0 Of course, this is a good problem to have. T= here are close to 30 different drafts related to YANG models for routing; c= oordination between these drafts is necessary.=C2=A0 NETMOD is also hard at= work on a backwards-compatible YANG 1.1.=C2=A0 From the IETF's experie= nce with developing MIBs, it was critical to have the domain-area experts i= nvolved in writing and reviewing MIBs and we believe that it is similarly c= ritical to situate the work on YANG models in the working groups where the = appropriate domain-experts can be easily found.=C2=A0 Actively encouraging = and cultivating the review of those with the expertise in modeling with YAN= G and deep understanding of its features is also critical to the success of= standardized YANG models.=C2=A0 This expertise is found in the NETMOD work= ing group and among the YANG doctors (https://www.ietf.org/iesg/= directorate/yang-doctors.html).

<= div class=3D"gmail_quote" style=3D"font-size:13px">We, as the Routing and Op= s and Management Area Directors, would like to see work proceed as follows.=

1) The mailing list,=C2=A0rtg-yang-coord@ietf.org, has been cre= ated to coordinate among the different routing YANG models and drafts.=C2= =A0 For instance, there may be common groupings to be defined, interactions= between models to be determined, and so on.=C2=A0 To facilitate this coord= ination work, we are developing a job description for a secretary for the m= ailing list and hope to appoint someone to that role.

2) Routing-rel= ated YANG models must be targeted for adoption at the appropriate WGs in th= e Routing Area.=C2=A0 If the appropriate WG is unclear, please bring the qu= estion to the RTGWG and the=C2=A0rtg-yang-coord@ietf.org=C2=A0mailing list.=C2=A0 RTG= WG can either direct where the work goes or, if there is no appropriate oth= er WG, make a decision about adopting the draft.

3)=C2= =A0The NETMOD charter has been open to accept work item that don't fall= under the responsibility of an existing WGs:
The NETMOD WG may also develop any additional = data models written in YANG that the WG considers core building blocks and = that do not fall under the charters of other active IETF working groups. Th= e NETMOD WG may simply add such milestones as it sees fit, with the advice = and consent of the responsible AD.
In case of routing-related YANG models, even if there are no respons= ible existing WG, it's expected that the standardization happens in the= RTGWG.

4) It is common and expected that somet= imes work needs to be discussed in multiple WGs, even though it is only ado= pted in one.=C2=A0 Examples would include NETMOD discussing a model for OSP= F to consider how it relates to draft-ietf-netmod-routing-cfg, RTGWG discus= sing draft-ietf-netmod-routing-cfg to encourage review and discussion about= its use as a base for routing-related models, etc. =C2=A0

5) We hav= e heard a strong desire from the community to rapidly encourage development= of standardized YANG models.=C2=A0 Towards that end, we expect and encoura= ge more and frequent virtual interims (some probably joint between WGs).=C2= =A0 To have such a pace work well, we need authors, reviewers, and contribu= tors to expect to spend time on this work on an on-going basis.

6) Since many YANG doctors also participate in NETMOD and sinc= e NETMOD is having weekly virtual interims, it may prove convenient to prov= ide feedback on YANG models in this forum.=C2=A0 When done so, to ensure th= e interested parties are aware of the relevant models to be discussed and c= an arrange their schedules to call in, the agenda should be forwarded with = at least a week's to the=C2=A0rtg-yang-coord@ietf.org=C2=A0and to the relevant WG= s. When the virtual interim is used to provide YANG doctor feedback, prefer= ence should be given to drafts already adopted by a WG; discussing one mode= l does not imply partiality or a request to the WG appropriate to consider = adopting the draft.

7) To provide a common location= to find proposed YANG models and be able to verify their accuracy, Tom Nad= eau, one of the NETMOD chairs, has set up a GitHub repository at:=C2=A0https://github= .com/YangModels/yang.=C2=A0 All work contributed to it is subject to th= e IETF Contributions policy, as summarized via the very very familiar IETF = Note Well.
8) For the second IETF meeting in a row, a "YANG Advice and Editing S= ession" (http://www.ietf.org/meeting/91/tutorials= /yang-session.html) is organized on the Sunday = before the IETF meeting. This is your chance to sit down with a YANG doctor= and to get feedback on your YANG module.

If you have any questions, please let us kn= ow.

Regards,
Alia, Benoit, Adrian, & Joel
--089e0122a6caf8966a05069024f8--

= +1 –OSPF + ISIS + TE YANG model authors were waiting for this = opportunity to discuss the open issues and present an update.

 

Many of those even logged in to the meeting before I had t= o begrudgingly announce cancelation L

<= p class=3DMsoNormal>

 

From: netmod [mailto:netmod-bounces@ietf.org] O= n Behalf Of Benoit Claise
Sent: Wednesday, October 22, 2014 4= :09 PM
To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman'
= Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.= ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian'Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canc= eled

 

Dear all,

To= m:

 

Acee indicated earlier on the i2rs list (= September discussion) that the OSPF yang model was going to be standardized= in OSPF.  I’m glad we’ve got the rtg-yang-coord list to s= ort out these issues.

&nb= sp;

IDR will pick up all B= GP related yang modules.  A charter addition has been made.  IDR = will gladly accept input from the netmod WG or hold joint interim session t= o make this effort go fast. 

Exactly. The YANG modules should be standardized in the resp= ective WGs.
To have good YANG modules, you need:
1. the technology ex= perts, i.e. the respective WG
2. YANG review

I don't understand a= ll this fuss about: "oh, but you can't speak about an OSPF module in a= NETMOD WG".
We want to do what's right by providing YANG review of= the documents, nothing else.

I don't understand all this fuss about= : "oh, but if you speak about one OSPF YANG model, then you must inclu= de all the other ones".
People who want feedback on their YANG modu= les are welcome to join. This was the goal.

Regards, Benoit

<= br>

The configuration drafts for bgp (draft-zhdan= kin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bg= p-dm-00) have only a 5% functional overlap.  I will be releasing a dra= ft that compares these two drafts, and looks at how these drafts fulfill th= e I2RS BGP use case requirements.

 

IDR will s= ponsor a design team in IDR to push the rapid development of bgp configurat= ion or bgp i2rs.  If you could suggest a few netmod people to help thi= s effort it would help.  

 

My understandi= ng of IETF best practices indicate that joint interims need 2 weeks announc= ement of topics.

 

Sue

<= p class=3DMsoNormal> 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adria= n
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting c= anceled

 

 

      &nb= sp;     No one said that OSPF experts could not = attend to provide input.   The issue is that OSPF was not doing this. = If they want to take over doing all OSPF models, then great, but to date no= one was.  The agreement in NETMOD (and our charter) is to facilitate = the creation of models when WGs don’t want to do them, have the exper= tise to do them, etc…  Also, getting the right Yang experts in o= ne place is not going to happen for every WG in the IETF; its just not real= istic.  I understand that ultimately the WG needs to have consensus, b= ut quick iteration to construct the model surely can happen in a small R= 20;design team” fashion, right?

 

           = ; And in terms of today’s meeting being canceled, really what = purpose was that other than to stall/slow-down work?  The group that w= as there to work on the OSPF model was indeed a bunch of folks from OSPF (A= cee Lindem for example was on the call).  So now since we won’t = have another interim meeting until after Hawaii, so the next time this grou= p can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii.  So the net-net is a= slowing of progress in this area.  Probably not the result the IETF c= ommunity wants.

 

  =           —Tom

 

 

=  

On Oct 22, 2014:10:18 AM, at 10:18 AM, = Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

=

not the NETMOD WG. The domain experts need to rea= ch consensus

on a feature set= (and maybe info model) and then get 1 or 2 YANG experts to

<= /div>

help translate that to a data model. (Not th= e other way around -- a room

= full of YANG experts and 1 or 2 OSPF experts).

 

I al= so prefer that virtual interim meetings be used to discuss open issues=

on chartered items, not as an add= itional forum to promote individual drafts.

 

 <= o:p>

Andy

 

 

On Wed, Oct 22, 20= 14 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

= The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in th= e work, and
I am sure that inclusion is what you want.

I find it = unfortunate that you scheduled a working group meeting to discuss only
o= ne of a pair of competing documents on the same topic, that you didn't make= the
information about the meeting available to the authors of the compe= ting document
or to the people who care about the protocol being modelle= d, and I find it
upsetting (yes, I am actually upset) that you decided t= o discuss in Netmod a
document that belongs in the OSPF working group.
If, as it surely sounds, you wish that the Netmod working group had a= different
charter to enable it to take on models for protocols that alr= eady have a home in
other working groups, then I suggest you need to rec= harter. But I doubt that
your reasoning that [YANG] experts will not go = to all the other working groups
will carry much weight. Frankly, and wit= hout wanting to disrespect the YANG
experts, it is easier to understand = YANG than it is to understand OSPF. If this
were not the case then the N= etmod working group would have failed in its design
of YANG!

Conc= lusion:
You want to work on a YANG model for OSPF. Go to the OSPF workin= g group and
discuss it (there are already some threads). Review and comm= ent on the competing
document. Try to get agreement between all of the a= uthors of both documents, or
try to identify the differences. Work with = the chairs of the OSPF working group
to advance the work.

Adrian<= br>
> -----Original Message-----
> From: Thomas D. Nadeau [mail= to:tnadeau@lucidvision.com]<= br>> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: N= ETMOD Working Group; Rtg-yang-co= ord@ietf.org; ops-ads@tools.i= etf.org;
> rtg-ads@tool= s.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting= canceled
>
>
>       This is hugely = disappointing. This is the kind of procedural non-sense
has
> and = IS driving people away from the IETF to other places where this work is
= going
> to get done. The simple effect of such silliness will be a re= duction in speed
and
> quantity of model development.  If the= goal of the IESG is to slow down the
> velocity of model development= and creation, then this approach is perfect.
>
>    =    For the record, the interim NETMOD meeting cadence has one mee= ting
> focused on Yang and the other on modeling; is not NETMOD-speci= fic per say, but
> to promote model creation because no other bi-week= ly forum exists to do so. It
> is also a place to bring in non-IETF w= ork such as the work done in ODL, other
open
> source, or just the= public community that has explicitly wanted to avoid the
IETF.
> = We have found it a convenient and fruitful place to discuss, and actually*build*
> models - regardless of their ultimate WG home.  The = simple reason: its a
single
> place for many of the experts to gat= her. I think you will find it very
difficult to get
> those people= onto a per-WG call every other week.
>
>      &= nbsp;I hope the IESG considers this approach carefully because I do not thi= nk
it
> will have the affect the larger IETF community is interest= ed in.
>
>       --Tom
>
>
&= gt;
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
&g= t; >
> > Dear all,
> >
> > Today NETMOD inter= im meeting is canceled.
> >
> > I received some pushbacks= from the routing ADs, on the ground that:
> > 1. This interim app= ears to be meeting to discuss a non-WG draft for which
there
> is = no milestone in the working group and for which there is an obvious home> outside the working group.
> > 2. The agenda was not announc= ed a week in advance on the IETF announce list
> as is required
&g= t; >
> > Regards, Benoit
> >
> > ____________= ___________________________________
> > Rtg-yang-coord mailing lis= t
> > Rtg-yang-coord@ie= tf.org
> > https://www.ietf.org/mailman/listinfo/rtg-y= ang-coord
> >

_________________________________________= ______
netmod mailing list
netmod@= ietf.org
https://www.ietf.org/mailman/listinfo/netmod=

 

 

<= /div>