From nobody Tue Aug 1 01:18:41 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 555DD132B8C; Tue, 1 Aug 2017 01:18:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jonathan Hardwick To: Cc: i2rs@ietf.org, ietf@ietf.org, draft-ietf-i2rs-rib-info-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150157551332.9546.17310175858783211646@ietfa.amsl.com> Date: Tue, 01 Aug 2017 01:18:33 -0700 Archived-At: Subject: [i2rs] Rtgdir early review of draft-ietf-i2rs-rib-info-model-11 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:18:33 -0000 Reviewer: Henning Rogge Review result: Has Nits Submitting on behalf of Henning Rogge: Hi, I was asked to do an early review of the i2rs-rib-info-model... I liked the comprehensive approach describing the RIB, including tunnels, multi-topology routing (by using multiple RIBs) and routing reactions (like drop/icmp-error). I found a few things in the draft that in my opinion need a bit more work... First it seems that Section 2.3 (Route) is a bit out of sync with the BNF later in the document, it should at least mention matching the source-IP address of the IP headers. Second (if I read the BNF in Section 6 correctly), the match for a route seems to be one of the list "ip address, MPLS label, MAC address, interface". I think it should be possible to combine "interface" or "mac address" with an IP address to restrict the focus of a route, e.g. "match fe80::1 from interface X". Last, I wonder if multicast routing needs more different types of matchers, e.g. a match on the TTL of the IP packet to limit the range of a multicast group. There is also problem of multicast routing in MANETs (see RFC 6621) which can use a hash-based duplicate detection to determine if it forwards or drops a multicast packet. Would this be out of scope for the draft? Henning Rogge From nobody Tue Aug 1 07:16:54 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336D41275F4; Tue, 1 Aug 2017 07:16:49 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcCR9OPDdo-0; Tue, 1 Aug 2017 07:16:48 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E1D12711B; Tue, 1 Aug 2017 07:16:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.10.26; From: "Susan Hares" To: "'Jonathan Hardwick'" , Cc: , , References: <150157551332.9546.17310175858783211646@ietfa.amsl.com> In-Reply-To: <150157551332.9546.17310175858783211646@ietfa.amsl.com> Date: Tue, 1 Aug 2017 10:10:31 -0400 Message-ID: <007801d30acf$f04d9280$d0e8b780$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7A5ElB5TCjRQ2QeiC25IY4N7z2KOfmK1A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Rtgdir early review of draft-ietf-i2rs-rib-info-model-11 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:16:49 -0000 Jonathan:=20 Please thank Henning for his review.=20 Sue Hares=20 -----Original Message----- From: Jonathan Hardwick [mailto:jonathan.hardwick@metaswitch.com]=20 Sent: Tuesday, August 1, 2017 4:19 AM To: rtg-dir@ietf.org Cc: i2rs@ietf.org; ietf@ietf.org; = draft-ietf-i2rs-rib-info-model.all@ietf.org Subject: Rtgdir early review of draft-ietf-i2rs-rib-info-model-11 Reviewer: Henning Rogge Review result: Has Nits Submitting on behalf of Henning Rogge: Hi, I was asked to do an early review of the i2rs-rib-info-model... I liked the comprehensive approach describing the RIB, including = tunnels, multi-topology routing (by using multiple RIBs) and routing = reactions (like drop/icmp-error). I found a few things in the draft that in my opinion need a bit more = work... First it seems that Section 2.3 (Route) is a bit out of sync with the = BNF later in the document, it should at least mention matching the = source-IP address of the IP headers. Second (if I read the BNF in Section 6 correctly), the match for a route = seems to be one of the list "ip address, MPLS label, MAC address, = interface". I think it should be possible to combine "interface" or "mac = address" with an IP address to restrict the focus of a route, e.g. = "match fe80::1 from interface X". Last, I wonder if multicast routing needs more different types of = matchers, e.g. a match on the TTL of the IP packet to limit the range of = a multicast group. There is also problem of multicast routing in MANETs (see RFC 6621) = which can use a hash-based duplicate detection to determine if it = forwards or drops a multicast packet. Would this be out of scope for the = draft? Henning Rogge From nobody Sun Aug 6 05:07:34 2017 Return-Path: <7riw77@gmail.com> X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ECB132024 for ; Sun, 6 Aug 2017 05:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtb3SnUC16Z8 for ; Sun, 6 Aug 2017 05:07:30 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC09131F21 for ; Sun, 6 Aug 2017 05:07:30 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id j32so18161647iod.0 for ; Sun, 06 Aug 2017 05:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=sEwvIfjrU3GEtROTZ8U6J6f+cNsyVkpHo17eswEFnrE=; b=Z7nv9s8/SHrrev7VaNugAf6zRIHg09FMnmq71HUFimdFVyWI9QygoyTFnEVBTi7W6y OYGPZ3gYu8uJihXNqc2HZkAGOm9aae38qhWzjVvhMfOqO3P6lW1RH7q9NOzem+LqBSbT af8youiAzhv3puxpVdsy2SUtU+3CrOdZoLyOTafh0HNy9JvI5PUPho8sasngzksnzKoK GL9h1W038+bi/nq4E+brUx/H7Ig4yKGOk4K7kj9gmhgaLRvSFewTW6QN1dskZqaSte+h ejuclYRP0uZdbiwSaWVZqyFPrGoZBhLhimcwsIHjIjvHH5L/knP00xn8I9zXm+OiOSSF 5UIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=sEwvIfjrU3GEtROTZ8U6J6f+cNsyVkpHo17eswEFnrE=; b=SN/5bnCOEwUgVUzkv3hw5DW12SDLHs6J9+t+5S+D3Z6frw+zaVbMGqGx0Yv2TSNvGK KIR0cBgY+IqgV9GnzeSk/0tnv71l3V174U6mCVN7yotJoKnuDMbLs5v6U4m1pg3wDi0+ Dq7Z09/h3XP/d0H2ypEBSv0fLdyNpTVc+5FN4j7/rwpD/ZR79pdrtjmcQrTKScvoCpGG V8YM7W3/4EmUodsLVFJzSGWNm4RpnGPuXtzJEGoyWwUiknUTWbN62jq6x6FhD/6cNBQP MzuWVsFNzIIuZzq+AFvHGQhqVUsd2/dvjIjUtqYGZ7/+00t7xD0J34f8ku09mZnd7wrn YQoA== X-Gm-Message-State: AIVw110E8eEv/2Az2bPL/f/Vho38S2dbJlQuqZUEsXSLOIn9wdY/c3to 56RiBofvf8ucbSBz X-Received: by 10.107.19.140 with SMTP id 12mr8072925iot.51.1502021249218; Sun, 06 Aug 2017 05:07:29 -0700 (PDT) Received: from Russ ([2602:30a:2e5b:44d0:b529:8d38:c8b0:3477]) by smtp.gmail.com with ESMTPSA id m13sm2764031iom.34.2017.08.06.05.07.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2017 05:07:28 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Sun, 6 Aug 2017 08:07:25 -0400 Message-ID: <010801d30eac$91b490d0$b51db270$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMOrHkfD8U/dBOYQEOYkH8OF2vS2Q== Content-Language: en-us Archived-At: Subject: [i2rs] End of Last Calls for draft-ietf-i2rs-rib-data-model and draft-ietf-i2rs-yang-l3-topology X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 12:07:32 -0000 Y'all -- The last call for publication for draft-ietf-i2rs-rib-data-model and draft-ietf-i2rs-yang-l3-topology started on 11 July; we have received support in the WG for these drafts from several folks. There were, however, comments on and changes to the draft, so we will initiate a short (one week) last call for these documents in the near future to allow for a short comment period before they move to publication. Thanks! Russ & Sue From nobody Sun Aug 6 17:41:33 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53601241F5 for ; Sun, 6 Aug 2017 17:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nv2vC4StgLA for ; Sun, 6 Aug 2017 17:41:31 -0700 (PDT) Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B94124B09 for ; Sun, 6 Aug 2017 17:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1502066490; bh=yIK8pcKiHQ6nkBEp74s4V20upUzrpPhjT1vZcAxCCKM=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=tKLKrbj28Bb7G2xx2az32kIPrxIAWXmE/GbNFNp5iQGLH7pQaKgbHLYZ+UmrcG5JKHqaxoYXOOyxbt+i+RLBHZ78shJO9iV4p+1ksa1KtRd9bxDQ9ccuy62cATS24iNj7hafpXzPTgpXfpS4EJHaYQ5xSrn/w+ABqgN5UgaCygwPoxqmGd7Pl2XEkBkiAFRqkbqeUnoFAo4ogEbN4PR64pXdZBPfZ7Dr1CnbyPFTpj/3cLRHgZ3x7n304zJv+uun/OkL1EINwx3YjN7FasjQE01l6aNRGwTzV1nP8PCydpiU5cVz5KYU47+HeEM24OSC6HCZHlffr84/DcrDgUmJcA== Received: from [98.138.100.102] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2017 00:41:30 -0000 Received: from [98.138.84.47] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2017 00:41:30 -0000 Received: from [127.0.0.1] by smtp115.mail.ne1.yahoo.com with NNFMP; 07 Aug 2017 00:41:30 -0000 X-Yahoo-Newman-Id: 10203.87657.bm@smtp115.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: T7_Q9joVM1mQYSGvNVzDdyhVm1zqtRgsLr4I5ZdmjqnCeBi 91gm6Q4pNwKdsG3GaR3z2lSQtR2i30r2dAJ1cl3JMK.QjV1Q8sb3R9Dr4Qhj _ZwF26MqVYYKVeacKMkVU9BhWDZBc9EixqJoea.3UBnyTZX8HJIto84CDJMe naPfVbwwGYYzcBzQSeDnZ4US82jC0m6F1zeYDmSJaxnZIZuGRKh7H5UKAZpW dEqdW7ZL5whffGOBORQb0i2h0EaxI8YlJFF9CNKJzvdhd63e5z4AdYXydiGE ULHPpWL8fV_lFPsmfLcIVwURwheRtiQldhxqrDP5RYAtykFRJs9EVhFnWf0a SuDeEu6E6OrwXwAs2kWMJchlMJL7P4dP1n6K_CxPfueZyaTOW.pclE0Izwh7 ArV58ZfhD5OcfcSILVoVlKPY75IDqQWZp9ie4ruGghxG_x8YqkZKVwWt5uBO 7KU_6ePcjOqAJwMYD81G7I7p7cY0YVaQDOBCDVWELegsGDzBLuTrKdPjZcLJ AdBv8RF.O.VVr X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Sun, 06 Aug 2017 17:41:15 -0700 From: Nitin Bahadur To: Henning Rogge , , Jonathan Hardwick , Susan Hares , Message-ID: <3C2B8B77-9A65-41E9-99D4-44C24F56D3F2@yahoo.com> Thread-Topic: rtgdir Early Review of draft-ietf-i2rs-rib-model References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [i2rs] rtgdir Early Review of draft-ietf-i2rs-rib-model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 00:41:32 -0000 Hi, Thanks for the review. Please see NB> below for comments. On 7/31/17, 6:43 AM, "Henning Rogge" wrote: I found a few things in the draft that in my opinion need a bit more wor= k... =20 First it seems that Section 2.3 (Route) is a bit out of sync with the BNF later in the document, it should at least mention matching the source-IP address of the IP headers. NB> Good point. I=E2=80=99ll add that. =20 Second (if I read the BNF in Section 6 correctly), the match for a route seems to be one of the list "ip address, MPLS label, MAC address, interface". I think it should be possible to combine "interface" or "mac address" with an IP address to restrict the focus of a route, e.g. "match fe80::1 from interface X". =20 NB> Yes it=E2=80=99s possible to do that, but that becomes a traditional firewall= filter. I think that is more for draft-ietf-i2rs-fb-rib-info-model. Last, I wonder if multicast routing needs more different types of matchers, e.g. a match on the TTL of the IP packet to limit the range of a multicast group. There is also problem of multicast routing in MANETs (see RFC 6621) which can use a hash-based duplicate detection to determine if it forwards or drops a multicast packet. Would this be out of scope for the draft? NB> The draft actually only touches on multicast and does not do justice to= it. Multicast by itself is a big beast. TTL is just one of the few things t= hat can be added. The authors had initially thought of leaving traditional m= ulticast to a need based extension. The high-level intent is to have some dr= aft extend or to added spe= cialized functionality. =20 Thanks Nitin From nobody Tue Aug 8 16:57:21 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A265A1320BE; Tue, 8 Aug 2017 16:57:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Kent Watsen To: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150223663961.3605.4696763251648960641@ietfa.amsl.com> Date: Tue, 08 Aug 2017 16:57:19 -0700 Archived-At: Subject: [i2rs] Yangdoctors last call review of draft-ietf-i2rs-yang-network-topo-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 23:57:20 -0000 Reviewer: Kent Watsen Review result: Almost Ready YANG Doctor review of draft-ietf-i2rs-yang-network-topo-14 (by Kent Watsen) 4 modules are defined in the draft: - ietf-network@2017-06-30.yang - ietf-network-topology@2017-06-30.yang - ietf-network-state@2017-06-30.yang - ietf-network-topology-state@2017-06-30.yang No validation errors from either `pyang` or `yanglint`. 0 examples are defined in the draft. The -state modules appear to have all the correct changes from their base modules. Regarding ietf-network@2017-06-30.yang: - prefix “nd”, should be “nw”? (in IANA Considerations also) - “import ietf-inet-types” should have a ‘reference’ to RFC 6991 - remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C. - s/Editor/Author/? (this is a preference choice) - defines ‘network-ref’ that is unused within module (it’s used by ietf-network-topology) - leafref paths don’t include prefix (rfc6087bis S4.2) Regarding ietf-network-topology@2017-06-30.yang: - prefix “lnk” should be “nt” or maybe “nwtp”? (in IANA Considerations also) - “import ietf-inet-types” should have a ‘reference’ to RFC 6991 - “import ietf-network” should have a ‘reference’ to RFC XXXX - remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C. - s/Editor/Author/? (this is a preference choice) - defines grouping link-ref and tp-ref that are unused within module - mandatory true for source/dest-node/tp? - replace “tp” with “term-pt”? (both in “-tp” and “tp-“ uses) Regarding ietf-networ-statek@2017-06-30.yang: - similar comments to ietf-network@2017-06-30.yang: Regarding ietf-network-topology-state@2017-06-30.yang: - similar comments to ietf-network-topology@2017-06-30.yang. Comments on draft: 1) The document still has references to “server-provided”. Not the YANG leaf of course, but in general text. For instance “The model does allow to layer a network that is configured on top of one that is server-provided.” I think that the statement is more about values being in than how it was learned. All uses of “server-provided” should be examined for correctness. 2) This sentence doesn’t make sense to me, how can a server-provided model (you mean data?) access any information in conventional datastores?: “An implementation's security policy MAY further restrict what information the server-provided model is allowed to access in standard configuration data-stores,” Either way, this text likely should be moved to the Security Considerations section. 3) Should the last paragraph in Section 1 be removed now? Is the module expected to continue to update? 4) S4.1, P3: the text here says new data nodes are augmented in, but the YANG module itself says that only presence containers are allowed. 5) are the mandatory statement values set appropriately everywhere? (e.g., source-node?, source-tp?) 6) network-type is a presence container, not an identity? No where in the draft is there an example showing it being used. 7) Section 4.4.8., why not use identities? 8) S4.4.9 is a duplicate of some text in S4.1 9) This statement is true, but I think misleading in context. “YANG requires data nodes to be designated as either configuration or operational data, but not both”. It seems that the solution depends entirely on config true nodes, and NMDA to present the operational value of those config true nodes. Right? 10) When using , you should have a note to the RFC Editor to change the date to the date of publication, both in the filename as well as in the module’s ’revision’ statement. 11) IANA Considerations has comments “(RFC form)” - are these supposed to be notes to RFC Editor to replace with final RFC designation? 12) Your Security Considerations section should follow the template here: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 13) create examples for the use-cases in Appendix A? Note, every draft should have examples of its YANG modules... Nits: - why reference RFC6991 in the Introduction? - replace “allows to define” with “enables the definition of” - in a few places, you refer to “network.yang”, but the file is called “ietf-network.yang”. - in a few places, you refer to “network-topology.yang”, but the file is called “ietf-network-topology.yang”. - replace “- X1 and X2 - mapping onto a single L3 network element” with “(X1 and X3) mapping onto a single L3 network element (Y2)” - replace “data-store” with “datastore” - replace “model” with “data model” where it’s not already. - replace “the datastore” with just “” - replace “the intended datastore” with just “” - update Section 2 to also include a reference to RFC 8174 (see RFC 8174) - pull the “datastore” term from the revised-datastores draft? - NETCONF and YANG don’t need to be terms/defined, since references to their RFCs are provided when they’re used. - s/the network.yang module/the “ietf-network” YANG module/ - your tree-diagram notation in S4.1 isn’t complete. And you duplicate it in S4.2. Create a top-level section called “tree diagram notation” that both sections reference? - s/allows to represent/allows representation of/ - s/another container/a presence container called/ - s/allows to define more/allows definition of more/ - s/allows also to represent/allows representation of/ - s/configuration and intended datastores/conventional datastores/ - s/and show up only/and thus only appear/ - /ietf-network:networks/network/network-id - being the list’s key, I was expecting this to the first element defined. - for the various leafrefs in both models, I see a lot of longish relative paths; suggest you change these to absolute paths if possible - /nd:networks/nd:network:/link/link-id is the list key but not the first leaf listed - incomplete sentence: “augmentations can in turn against augmenting modules” - s/need to specified/need to be specified/ - s/if the link-to-links mapping known/if the link-to-links mapping are known/ - s/each link known/each link are known/ - s/the operational datastore// - s/into the data model without relying/into without relying/ - s/in the following two companion modules/the following two companion modules/ - s/that represent a state model/to represent the operational state/ Thanks, Kent From nobody Tue Aug 8 23:56:27 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF896131EB2; Tue, 8 Aug 2017 23:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3ll2X1gjQFd; Tue, 8 Aug 2017 23:56:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EFA131DB6; Tue, 8 Aug 2017 23:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21798; q=dns/txt; s=iport; t=1502261781; x=1503471381; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=NfC1uJZna3u5K8vdOVwmQr1x/TXcGHZNuOAZwW70rMs=; b=Ri0Y1/lJOWuZySqszO2Dsc6TQgODfjFUTsJ1OGJ/XGt3wlDgY9v/Pdp7 WrIJ+6mjFmWc10AdtCvJw2Ht+iUhzS1/fsssHbctpMavutmNuBlttOH/A HzZ7DsRKFvQ+zBzR3GahJLdD1PmSd4jFOi/eWKH57uiuyBirL5w3sa4dn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQBgsYpZ/xbLJq1TCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQ+gRSOD3OhY4UzDoIEIQEMhDVkAoUyGAECAQEBAQEBAWsohRkCAQM?= =?us-ascii?q?BASFLCxAJAg4EMAICJyIOBgEMBgIBAReKFBCRDZ1kgiYniyoBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYMog06BYyuCfIQ9DBICgymCQh8FjAmUDYdTjGOCD4kzhw2?= =?us-ascii?q?JYYNBiGkfOIEKMiEIHBVJhUyBUD42h1MrghQBAQE?= X-IronPort-AV: E=Sophos;i="5.41,346,1498521600"; d="scan'208,217";a="653812902" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2017 06:56:16 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v796uAve020218; Wed, 9 Aug 2017 06:56:10 GMT To: Kent Watsen , yang-doctors@ietf.org Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo.all@ietf.org References: <150223663961.3605.4696763251648960641@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Wed, 9 Aug 2017 08:56:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150223663961.3605.4696763251648960641@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CBFDE9068FA1A6BAC74FC4F2" Content-Language: en-US Archived-At: Subject: Re: [i2rs] [yang-doctors] Yangdoctors last call review of draft-ietf-i2rs-yang-network-topo-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 06:56:26 -0000 This is a multi-part message in MIME format. --------------CBFDE9068FA1A6BAC74FC4F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Now implemented in the yangcatalog.org, we have the tree-type metadata. from https://github.com/xorrkaz/netmod-yang-catalog, to be published soon in https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/ leaf tree-type { type enumeration { enum split { description "This module uses a split config/operational state layout."; } enum nmda-compatible { description "This module is compatible with the Network Management Datastores Architecture (NMDA) and combines config and operational state nodes."; } enum transitional-extra { description "This module is derived as a '-state' module to allow for transitioning to a full NMDA-compliant tree structure."; } enum openconfig { description "This module uses the Openconfig data element layout."; } enum unclassified { description "This module does not have a data element tree, or it does not belong to any category."; } enum not-applicable { description "This module is submodule."; } } description "The type of data element tree used by the module as it relates to the Network Management Datastores Architecture."; reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors (NMDA) Happy to see that the two following I2RS modules are "nmda-compatible" https://yangcatalog.org:8443/search/modules/ietf-network,2017-06-30,ietf https://yangcatalog.org:8443/search/modules/ietf-network-topology,2017-06-30,ietf The following two are: transactional-extra https://yangcatalog.org:8443/search/modules/ietf-network-state,2017-06-30,ietf https://yangcatalog.org:8443/search/modules/ietf-network-state,2017-06-30,ietf We'll work on a nicer GUI later one. The key point for now: the tree-type metadata is populated. Regards, Benoit > Reviewer: Kent Watsen > Review result: Almost Ready > > > YANG Doctor review of draft-ietf-i2rs-yang-network-topo-14 (by Kent Watsen) > > > 4 modules are defined in the draft: > - ietf-network@2017-06-30.yang > - ietf-network-topology@2017-06-30.yang > - ietf-network-state@2017-06-30.yang > - ietf-network-topology-state@2017-06-30.yang > > No validation errors from either `pyang` or `yanglint`. > > 0 examples are defined in the draft. > > The -state modules appear to have all the correct changes > from their base modules. > > Regarding ietf-network@2017-06-30.yang: > - prefix “nd”, should be “nw”? (in IANA Considerations also) > - “import ietf-inet-types” should have a ‘reference’ to RFC 6991 > - remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C. > - s/Editor/Author/? (this is a preference choice) > - defines ‘network-ref’ that is unused within module (it’s used by > ietf-network-topology) > - leafref paths don’t include prefix (rfc6087bis S4.2) > > Regarding ietf-network-topology@2017-06-30.yang: > - prefix “lnk” should be “nt” or maybe “nwtp”? (in IANA Considerations also) > - “import ietf-inet-types” should have a ‘reference’ to RFC 6991 > - “import ietf-network” should have a ‘reference’ to RFC XXXX > - remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C. > - s/Editor/Author/? (this is a preference choice) > - defines grouping link-ref and tp-ref that are unused within module > - mandatory true for source/dest-node/tp? > - replace “tp” with “term-pt”? (both in “-tp” and “tp-“ uses) > > Regarding ietf-networ-statek@2017-06-30.yang: > - similar comments to ietf-network@2017-06-30.yang: > > Regarding ietf-network-topology-state@2017-06-30.yang: > - similar comments to ietf-network-topology@2017-06-30.yang. > > > Comments on draft: > > 1) The document still has references to “server-provided”. Not the YANG > leaf of course, but in general text. For instance “The model does allow > to layer a network that is configured on top of one that is server-provided.” > I think that the statement is more about values being in > than how it was learned. All uses of “server-provided” should be examined > for correctness. > > 2) This sentence doesn’t make sense to me, how can a server-provided model > (you mean data?) access any information in conventional datastores?: > “An implementation's security policy MAY further restrict what > information the server-provided model is allowed to access in > standard configuration data-stores,” > Either way, this text likely should be moved to the Security > Considerations section. > > 3) Should the last paragraph in Section 1 be removed now? Is the module > expected to continue to update? > > 4) S4.1, P3: the text here says new data nodes are augmented in, but > the YANG module itself says that only presence containers are allowed. > > 5) are the mandatory statement values set appropriately everywhere? > (e.g., source-node?, source-tp?) > > 6) network-type is a presence container, not an identity? No where in > the draft is there an example showing it being used. > > 7) Section 4.4.8., why not use identities? > > 8) S4.4.9 is a duplicate of some text in S4.1 > > 9) This statement is true, but I think misleading in context. “YANG > requires data nodes to be designated as either configuration or > operational data, but not both”. It seems that the solution depends > entirely on config true nodes, and NMDA to present the operational > value of those config true nodes. Right? > > 10) When using , you should have a note to the RFC > Editor to change the date to the date of publication, both in the > filename as well as in the module’s ’revision’ statement. > > 11) IANA Considerations has comments “(RFC form)” - are these supposed > to be notes to RFC Editor to replace with final RFC designation? > > 12) Your Security Considerations section should follow the template here: > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > 13) create examples for the use-cases in Appendix A? Note, every draft > should have examples of its YANG modules... > > > Nits: > > - why reference RFC6991 in the Introduction? > - replace “allows to define” with “enables the definition of” > - in a few places, you refer to “network.yang”, but the > file is called “ietf-network.yang”. > - in a few places, you refer to “network-topology.yang”, > but the file is called “ietf-network-topology.yang”. > - replace “- X1 and X2 - mapping onto a single L3 network element” > with “(X1 and X3) mapping onto a single L3 network element (Y2)” > - replace “data-store” with “datastore” > - replace “model” with “data model” where it’s not already. > - replace “the datastore” with just “” > - replace “the intended datastore” with just “” > - update Section 2 to also include a reference to RFC 8174 (see RFC 8174) > - pull the “datastore” term from the revised-datastores draft? > - NETCONF and YANG don’t need to be terms/defined, since references > to their RFCs are provided when they’re used. > - s/the network.yang module/the “ietf-network” YANG module/ > - your tree-diagram notation in S4.1 isn’t complete. And you duplicate > it in S4.2. Create a top-level section called “tree diagram notation” > that both sections reference? > - s/allows to represent/allows representation of/ > - s/another container/a presence container called/ > - s/allows to define more/allows definition of more/ > - s/allows also to represent/allows representation of/ > - s/configuration and intended datastores/conventional datastores/ > - s/and show up only/and thus only appear/ > - /ietf-network:networks/network/network-id - being the list’s key, > I was expecting this to the first element defined. > - for the various leafrefs in both models, I see a lot of longish > relative paths; suggest you change these to absolute paths if possible > - /nd:networks/nd:network:/link/link-id is the list key but not the > first leaf listed > - incomplete sentence: “augmentations can in turn against augmenting > modules” > - s/need to specified/need to be specified/ > - s/if the link-to-links mapping known/if the link-to-links mapping > are known/ > - s/each link known/each link are known/ > - s/the operational datastore// > - s/into the data model without relying/into without relying/ > - s/in the following two companion modules/the following two companion modules/ > - s/that represent a state model/to represent the operational state/ > > Thanks, > Kent > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --------------CBFDE9068FA1A6BAC74FC4F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

Now implemented in the yangcatalog.org, we have the tree-type metadata.
from https://github.com/xorrkaz/netmod-yang-catalog, to be published soon in https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/

 leaf tree-type {
     type enumeration {
       enum split {
         description
           "This module uses a split config/operational state layout.";
       }
       enum nmda-compatible {
         description
           "This module is compatible with the Network Management Datastores
            Architecture (NMDA) and combines config and operational state nodes.";
       }
       enum transitional-extra {
         description
           "This module is derived as a '-state' module to allow for transitioning
            to a full NMDA-compliant tree structure.";
       }
       enum openconfig {
         description
           "This module uses the Openconfig data element layout.";
       }
       enum unclassified {
        description
          "This module does not have a data element tree, or it does not belong to any category.";
       }
       enum not-applicable {
         description
           "This module is submodule.";
       }
     }
     description
       "The type of data element tree used by the module as it relates to the
        Network Management Datastores Architecture.";
     reference
       "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors (NMDA)

Happy to see that the two following I2RS modules are "nmda-compatible"
    https://yangcatalog.org:8443/search/modules/ietf-network,2017-06-30,ietf
    https://yangcatalog.org:8443/search/modules/ietf-network-topology,2017-06-30,ietf
The following two are: transactional-extra
    https://yangcatalog.org:8443/search/modules/ietf-network-state,2017-06-30,ietf
    https://yangcatalog.org:8443/search/modules/ietf-network-state,2017-06-30,ietf

We'll work on a nicer GUI later one. The key point for now: the tree-type metadata is populated.

Regards, Benoit
Reviewer: Kent Watsen
Review result: Almost Ready


YANG Doctor review of draft-ietf-i2rs-yang-network-topo-14 (by Kent Watsen)


4 modules are defined in the draft:
- ietf-network@2017-06-30.yang
- ietf-network-topology@2017-06-30.yang
- ietf-network-state@2017-06-30.yang
- ietf-network-topology-state@2017-06-30.yang

No validation errors from either `pyang` or `yanglint`.

0 examples are defined in the draft.

The -state modules appear to have all the correct changes
from their base modules.

Regarding ietf-network@2017-06-30.yang:
- prefix “nd”, should be “nw”?  (in IANA Considerations also)
- “import ietf-inet-types” should have a ‘reference’ to RFC 6991
- remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C.
- s/Editor/Author/? (this is a preference choice)
- defines ‘network-ref’ that is unused within module (it’s used by
  ietf-network-topology)
- leafref paths don’t include prefix (rfc6087bis S4.2)

Regarding ietf-network-topology@2017-06-30.yang:
- prefix “lnk” should be “nt” or maybe “nwtp”? (in IANA Considerations also)
- “import ietf-inet-types” should have a ‘reference’ to RFC 6991
- “import ietf-network” should have a ‘reference’ to RFC XXXX
- remove “WG Chairs”, per the template in rfc6087bis-13 Appendix C.
- s/Editor/Author/? (this is a preference choice)
- defines grouping link-ref and tp-ref that are unused within module
- mandatory true for source/dest-node/tp?
- replace “tp” with “term-pt”?  (both in “-tp” and “tp-“ uses)

Regarding ietf-networ-statek@2017-06-30.yang:
- similar comments to ietf-network@2017-06-30.yang:

Regarding ietf-network-topology-state@2017-06-30.yang:
- similar comments to ietf-network-topology@2017-06-30.yang.


Comments on draft:

1) The document still has references to “server-provided”.  Not the YANG
leaf of course, but in general text.  For instance “The model does allow 
to layer a network that is configured on top of one that is server-provided.”
I think that the statement is more about values being in <operational>
than how it was learned.  All uses of “server-provided” should be examined
for correctness.

2) This sentence doesn’t make sense to me, how can a server-provided model
(you mean data?) access any information in conventional datastores?:
   “An implementation's security policy MAY further restrict what
   information the server-provided model is allowed to access in
   standard configuration data-stores,”
Either way, this text likely should be moved to the Security 
Considerations section.

3) Should the last paragraph in Section 1 be removed now?  Is the module
expected to continue to update?

4) S4.1, P3: the text here says new data nodes are augmented in, but 
the YANG module itself says that only presence containers are allowed.

5) are the mandatory statement values set appropriately everywhere?
(e.g., source-node?, source-tp?)

6) network-type is a presence container, not an identity? No where in
the draft is there an example showing it being used.

7) Section 4.4.8., why not use identities?

8) S4.4.9 is a duplicate of some text in S4.1

9) This statement is true, but I think misleading in context. “YANG 
requires data nodes to be designated as either configuration or 
operational data, but not both”. It seems that the solution depends
entirely on config true nodes, and NMDA to present the operational 
value of those config true nodes.  Right?

10) When using <CODE BEGINS>, you should have a note to the RFC 
Editor to change the date to the date of publication, both in the 
filename as well as in the module’s ’revision’ statement.

11) IANA Considerations has comments “(RFC form)” - are these supposed
to be notes to RFC Editor to replace with final RFC designation?

12) Your Security Considerations section should follow the template here:
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

13) create examples for the use-cases in Appendix A?  Note, every draft
should have examples of its YANG modules...


Nits:

- why reference RFC6991 in the Introduction?
- replace “allows to define” with “enables the definition of”
- in a few places, you refer to “network.yang”, but the 
  file is called “ietf-network.yang”.
- in a few places, you refer to “network-topology.yang”, 
  but the file is called “ietf-network-topology.yang”.
- replace “- X1 and X2 - mapping onto a single L3 network element”
  with “(X1 and X3) mapping onto a single L3 network element (Y2)”
- replace “data-store” with “datastore”
- replace “model” with “data model” where it’s not already.
- replace “the <intended> datastore” with just “<intended>”
- replace “the intended datastore” with just “<intended>”
- update Section 2 to also include a reference to RFC 8174 (see RFC 8174)
- pull the “datastore” term from the revised-datastores draft?
- NETCONF and YANG don’t need to be terms/defined, since references
  to their RFCs are provided when they’re used.
- s/the network.yang module/the “ietf-network” YANG module/
- your tree-diagram notation in S4.1 isn’t complete.  And you duplicate
  it in S4.2.  Create a top-level section called “tree diagram notation”
  that both sections reference?
- s/allows to represent/allows representation of/
- s/another container/a presence container called/
- s/allows to define more/allows definition of more/
- s/allows also to represent/allows representation of/
- s/configuration and intended datastores/conventional datastores/
- s/and show up only/and thus only appear/
- /ietf-network:networks/network/network-id - being the list’s key, 
  I was expecting this to the first element defined.
- for the various leafrefs in both models, I see a lot of longish
  relative paths; suggest you change these to absolute paths if possible
- /nd:networks/nd:network:/link/link-id is the list key but not the
  first leaf listed
- incomplete sentence: “augmentations can in turn against augmenting
  modules”
- s/need to specified/need to be specified/
- s/if the link-to-links mapping known/if the link-to-links mapping
  are known/
- s/each link known/each link are known/
- s/the operational datastore/<operational>/
- s/into the data model without relying/into <operational> without relying/
- s/in the following two companion modules/the following two companion modules/
- s/that represent a state model/to represent the operational state/

Thanks,
Kent



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

--------------CBFDE9068FA1A6BAC74FC4F2-- From nobody Tue Aug 22 06:26:28 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D61321C4 for ; Tue, 22 Aug 2017 06:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSdOhQTPkQO4 for ; Tue, 22 Aug 2017 06:26:24 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976E6132358 for ; Tue, 22 Aug 2017 06:26:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: Cc: "'Russ White'" Date: Tue, 22 Aug 2017 09:19:42 -0400 Message-ID: <009f01d31b49$513c8680$f3b59380$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01D31B27.CA2AE680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMbR9mDuEgQshHeSv2SoRI2YsCSHg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] draft-zhuang-i2rs-yang-dc-fabric-network-topology X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 13:26:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A0_01D31B27.CA2AE680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG has reached consensus and draft-zhuang-i2rs-yang-dc-fabric-network-topology has been accepted. Will the authors please submit this as: draft-ietf-i2rs-yang-dc-fabric-network-topology. Sue Hares ------=_NextPart_000_00A0_01D31B27.CA2AE680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = WG has reached consensus and = draft-zhuang-i2rs-yang-dc-fabric-network-topology has been = accepted.  Will the authors please submit this as: =

draft-ietf-i2rs-yang-dc-fabric-network-topology.

 

 

Sue Hares =

------=_NextPart_000_00A0_01D31B27.CA2AE680-- From nobody Wed Aug 23 06:30:06 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7FA132C17; Wed, 23 Aug 2017 06:29:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150349499972.19434.1066255421182939884@ietfa.amsl.com> Date: Wed, 23 Aug 2017 06:29:59 -0700 Archived-At: Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 13:30:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System WG of the IETF. Title : A YANG Data Model for Fabric Topology in Data Center Network Authors : Yan Zhuang Danian Shi Rong Gu Hariharan Ananthakrishnan Filename : draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt Pages : 28 Date : 2017-08-23 Abstract: This document defines a YANG data model for fabric topology in Data Center Network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-dc-fabric-network-topology-00 https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-dc-fabric-network-topology-00 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/ From nobody Mon Aug 28 23:46:56 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C571B132386; Mon, 28 Aug 2017 23:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.6 X-Spam-Level: X-Spam-Status: No, score=-12.6 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1cJEtCm3yrg; Mon, 28 Aug 2017 23:46:52 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497EB1320BB; Mon, 28 Aug 2017 23:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2741; q=dns/txt; s=iport; t=1503989212; x=1505198812; h=to:cc:from:subject:message-id:date:mime-version; bh=5WlFfI3Sc9wWRoGDIsNwdlE/2YjqiJAkqiwIFcX4MIw=; b=CJoI5WVckzPJGih7VXGME3mWTP7a+iTUeRRxpnOnwkHBmegq4bmqMS2X YuSIcxGuhcAbNDLju3GL5mpPkxfS43vrqT7f0WRRuNYrxnt6Nzf4QI+qw /qv7W3IjcENxRbu7qt47KLXL/zSWn+u+yv3BGJYvXcafmlGbha+7ofdES c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAwB1DKVZ/xbLJq1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBhD6BFQGDdosRkHWRC4VMggQuhRmERhUBAgEBAQEBAQFrHQuFQlYfAT0CXw0?= =?us-ascii?q?GAgEBii0QsSyCJyeLPgEBAQEGAQEBAQEBIoMqg1CCDguHL4NLgmEFoGeHWYxyg?= =?us-ascii?q?myIZYcZjU2EMYRBNSKBDTIhCBwVh2Y+NosbAQEB?= X-IronPort-AV: E=Sophos;i="5.41,444,1498521600"; d="scan'208,217";a="655271982" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 06:46:50 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7T6knZ2031112; Tue, 29 Aug 2017 06:46:50 GMT To: "i2rs-chairs@ietf.org" Cc: "i2rs@ietf.org" From: Benoit Claise Message-ID: Date: Tue, 29 Aug 2017 08:46:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7FB3BE6E4CCBA023579D8A30" Content-Language: en-US Archived-At: Subject: [i2rs] I2RS and duplicate YANG module definitions X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 06:46:55 -0000 This is a multi-part message in MIME format. --------------7FB3BE6E4CCBA023579D8A30 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I see that ietf-fabric-types@2016-09-29.yang is extracted from draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt And that ietf-fabric-types@2016-10-13.yang is extracted from draft-zhuang-i2rs-dc-fabric-service-model-03.txt Should draft-zhuang-i2rs-dc-fabric-service-model-03.txt be updated by draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt , in the tracker? Similar issues with "ietf-fabric-topology@2017-03-10.yang" and "ietf-fabric-topology-state@2017-06-29.yang" between these two drafts. Regards, Benoit --------------7FB3BE6E4CCBA023579D8A30 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

I see that ietf-fabric-types@2016-09-29.yang is extracted from draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt
And that ietf-fabric-types@2016-10-13.yang is extracted from draft-zhuang-i2rs-dc-fabric-service-model-03.txt
Should draft-zhuang-i2rs-dc-fabric-service-model-03.txt be updated by draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt, in the tracker?

Similar issues with "ietf-fabric-topology@2017-03-10.yang" and "ietf-fabric-topology-state@2017-06-29.yang" between these two drafts.

Regards, Benoit
--------------7FB3BE6E4CCBA023579D8A30-- From nobody Tue Aug 29 02:20:21 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A813214D; Tue, 29 Aug 2017 02:20:20 -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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-3I-gZO3aVP; Tue, 29 Aug 2017 02:20:18 -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 0C3CD132025; Tue, 29 Aug 2017 02:20:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNN27125; Tue, 29 Aug 2017 09:20:14 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Aug 2017 10:20:10 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 29 Aug 2017 17:20:04 +0800 From: "Zhuangyan (Yan)" To: Benoit Claise , "i2rs-chairs@ietf.org" CC: "i2rs@ietf.org" Thread-Topic: [i2rs] I2RS and duplicate YANG module definitions Thread-Index: AdMgp/9aGmJcJMxnQZmfNdVJUaw5MA== Date: Tue, 29 Aug 2017 09:20:04 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67E@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67Enkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59A531CF.0066, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 61e71f23c7eb60f847931700a4c972c5 Archived-At: Subject: Re: [i2rs] I2RS and duplicate YANG module definitions X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 09:20:20 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67Enkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KDQpTdXJlLCB3ZSB3aWxsIHVwZGF0ZSB0aGUgc2VydmljZSBtb2R1bGUgZHJh ZnQgYWNjb3JkaW5nbHkuDQoNCkJlc3QgUmVnYXJkcywNCg0KWWFuDQoNCuWPkeS7tuS6ujogaTJy cyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEJlbm9pdCBDbGFpc2UNCuWP kemAgeaXtumXtDogMjAxN+W5tDjmnIgyOeaXpSAxNDo0Nw0K5pS25Lu25Lq6OiBpMnJzLWNoYWly c0BpZXRmLm9yZw0K5oqE6YCBOiBpMnJzQGlldGYub3JnDQrkuLvpopg6IFtpMnJzXSBJMlJTIGFu ZCBkdXBsaWNhdGUgWUFORyBtb2R1bGUgZGVmaW5pdGlvbnMNCg0KRGVhciBhbGwsDQoNCkkgc2Vl IHRoYXQgaWV0Zi1mYWJyaWMtdHlwZXNAMjAxNi0wOS0yOS55YW5nPG1haWx0bzppZXRmLWZhYnJp Yy10eXBlc0AyMDE2LTA5LTI5Lnlhbmc+IGlzIGV4dHJhY3RlZCBmcm9tIGRyYWZ0LWlldGYtaTJy cy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTAwLnR4dDxodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRv cG9sb2d5Pg0KQW5kIHRoYXQgaWV0Zi1mYWJyaWMtdHlwZXNAMjAxNi0xMC0xMy55YW5nPG1haWx0 bzppZXRmLWZhYnJpYy10eXBlc0AyMDE2LTEwLTEzLnlhbmc+IGlzIGV4dHJhY3RlZCBmcm9tIGRy YWZ0LXpodWFuZy1pMnJzLWRjLWZhYnJpYy1zZXJ2aWNlLW1vZGVsLTAzLnR4dDxodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodWFuZy1pMnJzLWRjLWZhYnJpYy1zZXJ2aWNl LW1vZGVsPg0KU2hvdWxkIGRyYWZ0LXpodWFuZy1pMnJzLWRjLWZhYnJpYy1zZXJ2aWNlLW1vZGVs LTAzLnR4dDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodWFuZy1pMnJz LWRjLWZhYnJpYy1zZXJ2aWNlLW1vZGVsPiBiZSB1cGRhdGVkIGJ5IGRyYWZ0LWlldGYtaTJycy15 YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTAwLnR4dDxodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9s b2d5PiwgaW4gdGhlIHRyYWNrZXI/DQoNClNpbWlsYXIgaXNzdWVzIHdpdGggImlldGYtZmFicmlj LXRvcG9sb2d5QDIwMTctMDMtMTAueWFuZyI8bWFpbHRvOmlldGYtZmFicmljLXRvcG9sb2d5QDIw MTctMDMtMTAueWFuZz4gYW5kICJpZXRmLWZhYnJpYy10b3BvbG9neS1zdGF0ZUAyMDE3LTA2LTI5 LnlhbmciPG1haWx0bzppZXRmLWZhYnJpYy10b3BvbG9neS1zdGF0ZUAyMDE3LTA2LTI5Lnlhbmc+ IGJldHdlZW4gdGhlc2UgdHdvIGRyYWZ0cy4NCg0KUmVnYXJkcywgQmVub2l0DQo= --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67Enkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBCZW5vaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5TdXJlLCB3ZSB3aWxsIHVwZGF0ZSB0aGUgc2VydmljZSBtb2R1bGUgZHJhZnQgYWNjb3JkaW5n bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPg0KIGkycnMgW21haWx0bzppMnJz LWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIGxhbmc9IlpILUNOIj7ku6PooaggPC9zcGFuPjwv Yj5CZW5vaXQgQ2xhaXNlPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwv c3Bhbj46PC9iPiAyMDE3PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj44PHNwYW4gbGFuZz0i WkgtQ04iPuaciDwvc3Bhbj4yOTxzcGFuIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+IDE0OjQ3PGJy Pg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46PC9iPiBpMnJzLWNoYWly c0BpZXRmLm9yZzxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7mioTpgIE8L3NwYW4+OjwvYj4g aTJyc0BpZXRmLm9yZzxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+Ojwv Yj4gW2kycnNdIEkyUlMgYW5kIGR1cGxpY2F0ZSBZQU5HIG1vZHVsZSBkZWZpbml0aW9uczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxicj4N Cjxicj4NCkkgc2VlIHRoYXQgPGEgaHJlZj0ibWFpbHRvOmlldGYtZmFicmljLXR5cGVzQDIwMTYt MDktMjkueWFuZyI+aWV0Zi1mYWJyaWMtdHlwZXNAMjAxNi0wOS0yOS55YW5nPC9hPiBpcyBleHRy YWN0ZWQgZnJvbQ0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neSI+DQpkcmFmdC1pZXRm LWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS0wMC50eHQ8L2E+PGJyPg0KQW5k IHRoYXQgPGEgaHJlZj0ibWFpbHRvOmlldGYtZmFicmljLXR5cGVzQDIwMTYtMTAtMTMueWFuZyI+ aWV0Zi1mYWJyaWMtdHlwZXNAMjAxNi0xMC0xMy55YW5nPC9hPiBpcyBleHRyYWN0ZWQgZnJvbQ0K PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHVhbmctaTJy cy1kYy1mYWJyaWMtc2VydmljZS1tb2RlbCI+DQpkcmFmdC16aHVhbmctaTJycy1kYy1mYWJyaWMt c2VydmljZS1tb2RlbC0wMy50eHQ8L2E+PGJyPg0KU2hvdWxkIDxhIGhyZWY9Imh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1YW5nLWkycnMtZGMtZmFicmljLXNlcnZpY2Ut bW9kZWwiPg0KZHJhZnQtemh1YW5nLWkycnMtZGMtZmFicmljLXNlcnZpY2UtbW9kZWwtMDMudHh0 PC9hPiBiZSB1cGRhdGVkIGJ5IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3kiPg0KZHJh ZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3ktMDAudHh0PC9hPiwg aW4gdGhlIHRyYWNrZXI/PGJyPg0KPGJyPg0KU2ltaWxhciBpc3N1ZXMgd2l0aCA8YSBocmVmPSJt YWlsdG86aWV0Zi1mYWJyaWMtdG9wb2xvZ3lAMjAxNy0wMy0xMC55YW5nIj4mcXVvdDtpZXRmLWZh YnJpYy10b3BvbG9neUAyMDE3LTAzLTEwLnlhbmcmcXVvdDs8L2E+IGFuZA0KPGEgaHJlZj0ibWFp bHRvOmlldGYtZmFicmljLXRvcG9sb2d5LXN0YXRlQDIwMTctMDYtMjkueWFuZyI+JnF1b3Q7aWV0 Zi1mYWJyaWMtdG9wb2xvZ3ktc3RhdGVAMjAxNy0wNi0yOS55YW5nJnF1b3Q7PC9hPiBiZXR3ZWVu IHRoZXNlIHR3byBkcmFmdHMuPGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67Enkgeml513mbxchi_-- From nobody Tue Aug 29 03:34:20 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741E3132339; Tue, 29 Aug 2017 03:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.489 X-Spam-Level: X-Spam-Status: No, score=-14.489 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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QIwGClbiCCv; Tue, 29 Aug 2017 03:34:16 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1406B1321B7; Tue, 29 Aug 2017 03:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8851; q=dns/txt; s=iport; t=1504002856; x=1505212456; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mJBt12PuW87vbkxeSJct9LbP5warFTh3GEH6thhd0Yg=; b=OCTkL73xLCbINflX8NuduwfJryNcf4lo5P5vAYYTw17ZXj/2QcglShfc TEzpHECABsQOdaYjVO9lztOImLapIUyI92g3f5GwA1Yv7N/xJe9PAspfe MGVmqF7bbpv2dwAhOkxpyKUegcoL23h1X1iGjdxhCXLE3s3dpL01ISU3i g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoBgBjQqVZ/xbLJq1eHAEBBAEBCgEBg?= =?us-ascii?q?m+BT4EVg3eLEaIBhUyCBC6FGQKETRUBAgEBAQEBAQFrKIUZBiMKTBAJAj8DAgJ?= =?us-ascii?q?GEQYBDAYCAQGKLRCSNp1mgicnizsBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyqDU?= =?us-ascii?q?IIOgn2EPW6CXYJhBaBoh1mMc4ISWohmhxmJd4NZhDGEQTUigQ0yIQgcFYdmPja?= =?us-ascii?q?LIQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,444,1498521600"; d="scan'208,217";a="657096797" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 10:34:14 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7TAYDKe013824; Tue, 29 Aug 2017 10:34:13 GMT To: "Zhuangyan (Yan)" , "i2rs-chairs@ietf.org" Cc: "i2rs@ietf.org" References: <9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67E@nkgeml513-mbx.china.huawei.com> From: Benoit Claise Message-ID: <7b55bd77-a747-2bc3-1f31-8b0d0b06c3f6@cisco.com> Date: Tue, 29 Aug 2017 12:34:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9B4BC45FDEDDD84F813E9E4A5BAF8785A95CD67E@nkgeml513-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------B7B55277F881A604C24538DC" Content-Language: en-US Archived-At: Subject: Re: [i2rs] I2RS and duplicate YANG module definitions X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 10:34:18 -0000 This is a multi-part message in MIME format. --------------B7B55277F881A604C24538DC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yan, The "update" has been introduced in https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/ That will simplify the YANG modules extraction. Regards, B. > > Hi Benoit, > > Sure, we will update the service module draft accordingly. > > Best Regards, > > Yan > > *发件人**:*i2rs [mailto:i2rs-bounces@ietf.org] *代表 *Benoit Claise > *发送时间:* 2017年8月29日 14:47 > *收件人:* i2rs-chairs@ietf.org > *抄送:* i2rs@ietf.org > *主题:* [i2rs] I2RS and duplicate YANG module definitions > > Dear all, > > I see that ietf-fabric-types@2016-09-29.yang > is extracted from > draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt > > And that ietf-fabric-types@2016-10-13.yang > is extracted from > draft-zhuang-i2rs-dc-fabric-service-model-03.txt > > Should draft-zhuang-i2rs-dc-fabric-service-model-03.txt > > be updated by draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt > , > in the tracker? > > Similar issues with "ietf-fabric-topology@2017-03-10.yang" > and > "ietf-fabric-topology-state@2017-06-29.yang" > between these two > drafts. > > Regards, Benoit > --------------B7B55277F881A604C24538DC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Yan,

The "update" has been introduced in https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/
That will simplify the YANG modules extraction.

Regards, B.

Hi Benoit,

 

Sure, we will update the service module draft accordingly.

 

Best Regards,

 

Yan

 

发件人: i2rs [mailto:i2rs-bounces@ietf.org] 代表 Benoit Claise
发送时间: 2017年8月29日 14:47
收件人: i2rs-chairs@ietf.org
抄送: i2rs@ietf.org
主题: [i2rs] I2RS and duplicate YANG module definitions

 

Dear all,

I see that ietf-fabric-types@2016-09-29.yang is extracted from draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt
And that ietf-fabric-types@2016-10-13.yang is extracted from draft-zhuang-i2rs-dc-fabric-service-model-03.txt
Should draft-zhuang-i2rs-dc-fabric-service-model-03.txt be updated by draft-ietf-i2rs-yang-dc-fabric-network-topology-00.txt, in the tracker?

Similar issues with "ietf-fabric-topology@2017-03-10.yang" and "ietf-fabric-topology-state@2017-06-29.yang" between these two drafts.

Regards, Benoit


--------------B7B55277F881A604C24538DC--