From nobody Tue Jan 3 00:28:10 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 06050129423; Tue, 3 Jan 2017 00:28:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148343208902.28006.6133302934029793298.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 00:28:09 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:28:09 -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 of the IETF. Title : A Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Nitin Bahadur Hariharan Ananthakrishnan Xufeng Liu Filename : draft-ietf-i2rs-yang-network-topo-10.txt Pages : 32 Date : 2017-01-03 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-10 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 Tue Jan 3 03:18:31 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 CB06E129450; Tue, 3 Jan 2017 03:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148344230482.28002.9571022242768358870.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 03:18:24 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-07.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:18:25 -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 of the IETF. Title : A YANG Data Model for Layer 3 Topologies Authors : Alexander Clemm Jan Medved Robert Varga Xufeng Liu Hariharan Ananthakrishnan Nitin Bahadur Filename : draft-ietf-i2rs-yang-l3-topology-07.txt Pages : 32 Date : 2017-01-03 Abstract: This document defines a YANG data model for layer 3 network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l3-topology-07 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 Tue Jan 3 13:45:57 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 491301296C0; Tue, 3 Jan 2017 13:45:56 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148347995625.28036.8205740995822142756.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 13:45:56 -0800 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, akatlas@gmail.com Subject: [i2rs] Last Call: (A YANG Data Model for Layer 3 Topologies) to Proposed Standard X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:45:56 -0000 The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'A YANG Data Model for Layer 3 Topologies' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model for layer 3 network topologies. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 4 00:50:33 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 D26A5129C49; Wed, 4 Jan 2017 00:50:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148351982985.13026.17238612680134045961.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 00:50:29 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-07.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:50:30 -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 of the IETF. Title : A YANG Data Model for Routing Information Base (RIB) Authors : Lixing Wang Hariharan Ananthakrishnan Mach(Guoyi) Chen Amit Dass Sriganesh Kini Nitin Bahadur Filename : draft-ietf-i2rs-rib-data-model-07.txt Pages : 67 Date : 2017-01-04 Abstract: This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-07 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 Wed Jan 4 13:33:51 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 4F4F61296D7; Wed, 4 Jan 2017 13:33:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:33:45 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:33:45 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. I have a couple of things I'd like to discuss that may require some additional text, but should be easy to resolve. 1. Privacy considerations - I don't see any listed and the YANG module include a few identifiers as well as ways to group devices. I think privacy considerations need to be added for use of this module. 2. Security - the network topology and inventory created by this module reveals information about systems and services. This could be very helpful information to an attacker and should also be called out as a security consideration. The access and transport of this information is covered though in the considerations, just listing this threat would be helpful. Thank you. From nobody Wed Jan 4 13:36:03 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 7CB361296B4; Wed, 4 Jan 2017 13:35:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356575850.12990.2753748871442297726.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:35:58 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-08.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:35:58 -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 of the IETF. Title : A YANG Data Model for Layer 3 Topologies Authors : Alexander Clemm Jan Medved Robert Varga Xufeng Liu Hariharan Ananthakrishnan Nitin Bahadur Filename : draft-ietf-i2rs-yang-l3-topology-08.txt Pages : 32 Date : 2017-01-04 Abstract: This document defines a YANG data model for layer 3 network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l3-topology-08 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 Wed Jan 4 14:18:59 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 6F3AD129AC0; Wed, 4 Jan 2017 14:18:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 14:18:55 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:18:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with both of Kathleen's DISCUSS points. From nobody Wed Jan 4 15:56:12 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 8452F12945B; Wed, 4 Jan 2017 15:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 uqQGqo0YhhyH; Wed, 4 Jan 2017 15:56:05 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BFB129449; Wed, 4 Jan 2017 15:56:04 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'The IESG'" References: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> In-Reply-To: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 18:52:13 -0500 Message-ID: <014701d266e5$92b90a70$b82b1f50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0148_01D266BB.A9E65DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa+UB1ttLXKBCWbwCrhOA6DNRFuqCXzsaA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jan 2017 23:56:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0148_01D266BB.A9E65DD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kathleen: =20 I'm confused by your request. I thought = draft-ietf-i2rs-protocol-security-requirements-17.txt was written to = answer this questions for all I2RS modules. We knew this new style of = interface with Yang modules had these privacy and security constraints. = This data module SHOULD only run under the protocol security constraints = listed in the draft-ietf-i2rs-protocol-security-requirements-17.txt = module. This document left out of this yang module because I thought we = covered in the global document. Each of the I2RS global modules = provides information will have these concerns. Let me review these = concerns:=20 =20 =C2=B7 Topology modules - you correctly note that the draft = -i2rs-yang-network-topology model has privacy concerns regarding the = identifiers and grouping of devices. You also correctly note that = network topology and network inventory can be used to attack the = modules.=20 =20 =C2=B7 RIB modules - You should understand the I2RS RIB has = grouping and names that could be used to identify groups of routes. In = addition, RIB information quickly inserted/pulled from nodes is an = attack vector.=20 =20 =C2=B7 FB RIB module - The filter based RIBS indicates the = filters that control forwarding of data on selected interfaces. It uses = group names to group these filters for companies or to group filters by = function. You can expand the topology concerns to the filters as well. = =20 =C2=B7 The I2NSF data modules build upon these concepts. =20 =20 Do you wish threat sections in each module? Could you provide a = template for these threat comments. If you wish to limit group = identifiers in all of these modules, it would be good to provide = write-up on what is good/bad group identifiers so the authors provide = the=20 =20 In future SEC-DIR reviews, it would be good for your reviewers to = specifically examine the document to see if these issues have been = addressed.=20 =20 Sue Hares (shepherd)=20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 1. Privacy considerations - I don't see any listed and the YANG module = include a few identifiers as well as ways to group devices. I think = privacy considerations need to be added for use of this module. =20 2. Security - the network topology and inventory created by this module = reveals information about systems and services. This could be very = helpful information to an attacker and should also be called out as a = security consideration. The access and transport of this information is = covered though in the considerations, just listing this threat would be = helpful. =20 =20 -----Original Message----- From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]=20 Sent: Wednesday, January 4, 2017 4:34 PM To: The IESG Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Kathleen Moriarty's Discuss on = draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) =20 Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: Discuss =20 When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) =20 =20 Please refer to = = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 Thanks for your work on this draft. =20 I have a couple of things I'd like to discuss that may require some = additional text, but should be easy to resolve. =20 1. Privacy considerations - I don't see any listed and the YANG module = include a few identifiers as well as ways to group devices. I think = privacy considerations need to be added for use of this module. =20 2. Security - the network topology and inventory created by this module = reveals information about systems and services. This could be very = helpful information to an attacker and should also be called out as a = security consideration. The access and transport of this information is = covered though in the considerations, just listing this threat would be = helpful. =20 Thank you. =20 =20 =20 =20 ------=_NextPart_000_0148_01D266BB.A9E65DD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Kathleen:

 

I'm = confused by your request. I thought = draft-ietf-i2rs-protocol-security-requirements-17.txt was written to = answer this questions for all I2RS modules. =C2=A0We knew this new style = of interface with Yang modules had these privacy and security = constraints. =C2=A0This data module SHOULD only run under the protocol = security constraints listed in the = draft-ietf-i2rs-protocol-security-requirements-17.txt module.=C2=A0 This = document left out of this yang module because I thought we covered in = the global document. =C2=A0=C2=A0Each of the I2RS global modules = provides information will have these concerns.=C2=A0 Let me review these = concerns:

 

=C2=B7         = Topology modules - you correctly note = that the draft -i2rs-yang-network-topology model has privacy concerns = regarding the identifiers and grouping of devices.=C2=A0 You also = correctly note that network topology and network inventory can be used = to attack the modules.

 

=C2=B7         = RIB modules - You should understand the = I2RS RIB has grouping and names that could be used to identify groups of = routes. =C2=A0In addition, RIB information quickly inserted/pulled from = nodes is an attack vector.

 

=C2=B7         = FB RIB module - The filter based RIBS = indicates the filters that control forwarding of data on selected = interfaces.=C2=A0 It uses group names to group these filters for = companies or to group filters by function.=C2=A0=C2=A0 You can expand = the topology concerns to the filters as well.

 

=C2=B7         = The I2NSF data modules build upon these = concepts.=C2=A0 =C2=A0

 

Do you = wish threat sections in each module?=C2=A0 Could you provide a template = for these threat comments. =C2=A0If you wish to limit group identifiers = in all of these modules, it would be good to provide write-up on what is = good/bad group identifiers so the authors provide the

 

In = future SEC-DIR reviews, it would be good for your reviewers to = specifically examine the document to see if these issues have been = addressed.

 

Sue = Hares (shepherd)

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

1. Privacy considerations - I don't see any listed = and the YANG module include a few identifiers as well as ways to group = devices.=C2=A0 I think privacy considerations need to be added for use = of this module.

 

2. = Security - the network topology and inventory created by this module = reveals information about systems and services.=C2=A0 This could be very = helpful information to an attacker and should also be called out as a = security consideration. The access and transport of this information is = covered though in the considerations, just listing this threat would be = helpful.

 

 

-----Original Message-----
From: Kathleen = Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
Sent: Wednesday, = January 4, 2017 4:34 PM
To: The IESG
Cc: = draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
Subject: = Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: = (with DISCUSS)

 

Kathleen Moriarty has entered the following ballot = position for

draft-ietf-i2rs-yang-network-topo-10: = Discuss

 

When responding, please keep the subject line = intact and reply to all email addresses included in the To and CC lines. = (Feel free to cut this introductory paragraph, = however.)

 

 

Please = refer to https://www.ietf.org/iesg= /statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT = positions.

 

 

The = document, along with other ballot positions, can be found = here:

https://datatracker.ietf.= org/doc/draft-ietf-i2rs-yang-network-topo/

 

 

 

----------------------------------------------------= ------------------

DISCUSS:

----------------------------------------------------= ------------------

 

Thanks = for your work on this draft.

 

I have = a couple of things I'd like to discuss that may require some additional = text, but should be easy to resolve.

 

1. = Privacy considerations - I don't see any listed and the YANG module = include a few identifiers as well as ways to group devices.=C2=A0 I = think privacy considerations need to be added for use of this = module.

 

2. Security - the network topology and inventory = created by this module reveals information about systems and = services.=C2=A0 This could be very helpful information to an attacker = and should also be called out as a security consideration. The access = and transport of this information is covered though in the = considerations, just listing this threat would be = helpful.

 

Thank you.

 

 

 

 

------=_NextPart_000_0148_01D266BB.A9E65DD0-- From nobody Wed Jan 4 16:31: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 03E4B129470; Wed, 4 Jan 2017 16:31:27 -0800 (PST) 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 iXosGsGM7hnr; Wed, 4 Jan 2017 16:31:26 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83BE12946D; Wed, 4 Jan 2017 16:31:25 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: "'Ben Campbell'" , "'The IESG'" References: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> In-Reply-To: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 19:27:20 -0500 Message-ID: <016001d266ea$83e837a0$8bb8a6e0$@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: AQExe0vDeG0NwR6KCwLlthiLk2jzIqJq1Jbw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 00:31:27 -0000 Ben:=20 I have responded to Kathleen's comment with a lengthy set of questions. = Would you engage in the conversation on that thread?=20 Summary of the issue: These modules and any module that refers to these = must utilize the privacy and security concerns in the = draft-ietf-i2rs-protocol-security-requirements-17.txt. I see the = authors referred to the ephemeral state, but left out a reference to = draft-ietf-i2rs-protocol-security-requirements. I would suggest that = the authors add this reference at the very least.=20 Sue=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, January 4, 2017 5:19 PM To: The IESG Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Ben Campbell's No Objection on = draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with both of Kathleen's DISCUSS points. From nobody Wed Jan 4 16:45:12 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 DA20F129470; Wed, 4 Jan 2017 16:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 Actmk0svg_sj; Wed, 4 Jan 2017 16:45:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2DAB1129453; Wed, 4 Jan 2017 16:45:09 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v050j8YR007681 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 18:45:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Susan Hares" Date: Wed, 04 Jan 2017 18:45:07 -0600 Message-ID: In-Reply-To: <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> References: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 00:45:11 -0000 On 4 Jan 2017, at 18:27, Susan Hares wrote: > Ben: > > I have responded to Kathleen's comment with a lengthy set of > questions. Would you engage in the conversation on that thread? I saw your response to Kathleen. I will watch the conversation there, and respond if I think I have something further to add. Thanks! Ben. > > Summary of the issue: These modules and any module that refers to > these must utilize the privacy and security concerns in the > draft-ietf-i2rs-protocol-security-requirements-17.txt. I see the > authors referred to the ephemeral state, but left out a reference to > draft-ietf-i2rs-protocol-security-requirements. I would suggest that > the authors add this reference at the very least. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, January 4, 2017 5:19 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ben Campbell's No Objection on > draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with both of Kathleen's DISCUSS points. From nobody Wed Jan 4 18:03:50 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 0EA4E1294F5; Wed, 4 Jan 2017 18:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 1ke9hbhAUvqp; Wed, 4 Jan 2017 18:03:43 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 18BF21294E3; Wed, 4 Jan 2017 18:03:43 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id u25so414561620qki.2; Wed, 04 Jan 2017 18:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X5Z/WCMz/1MGVRN0YJ3eoFHbiBgtj49jcMqpTdSIRPc=; b=JQ/RMvaqZoGgLDnEOeqGtKauABXvEwbUGdxDsAxQphP6S+xtG7bHScPghrPR2ulW++ hanYGBCKK0/zQpIKRDxjilmSXZj8BMZJPrW9Emh7SFa7Gk3jyc32al3hBmbbFh1wzVhi NpsUw6knFWcEwPITFnNgMdDp/dJPH3r3IU992Q91OqPqJoct1EoraOjMeCqHTam7grQa ufqSLkq7YA8nyoBp0+/QB/YmtAxFJ7kLaSNmJdbsEBHOVmuDfFfYbZnjbyLIBMUjjlsF qEU6rMRgFEff1NZ+Nmg4M0T4ZEblopa9anJkl+6Mz7ljy6Af7g8/vRMQp3QvhVd6jHs8 tHOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X5Z/WCMz/1MGVRN0YJ3eoFHbiBgtj49jcMqpTdSIRPc=; b=Uc3kc0UQhCBUpIebHj+NB9oBtXMWYfEGN4BLCim2+r/Ofc6cn6rWZUGdwREBCNyoNi wQQe0Y3qMJai+OjtAD6hBImHMKKaUeFkH6Nk7QUAamEOfMuvDeYMFZ/Q462xsyFecf2N NGwTEBEPrC0Qz2wr4PU3ZOCVV5uKen2yvDBeEOAHIBaLjKXfzSbda4b8L56BFcN8+e8Z BtjOTU2efnqPVE8YF2hzMDvUDQQfi7LW59L6r2L4k2KQMrEEqhRHCVyqYKWzwJgud3XA hRy/y2v5rtx7XtGPpBsS/1mm0VqpmI2j5ABGTjhChgk3qoE9Cq5oikUvGOjPF6N+TIYF 8m7Q== X-Gm-Message-State: AIkVDXKFQHTH1WoRl1PFopRbMGKWou+Df8EE/7XDWW8Fyw0zIjSqNKwkKV8/waHwtEEqO5lH7AX0TZ37g2c/Xw== X-Received: by 10.55.215.202 with SMTP id t71mr4891353qkt.114.1483581822212; Wed, 04 Jan 2017 18:03:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Wed, 4 Jan 2017 18:03:41 -0800 (PST) In-Reply-To: <014701d266e5$92b90a70$b82b1f50$@ndzh.com> References: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> <014701d266e5$92b90a70$b82b1f50$@ndzh.com> From: Kathleen Moriarty Date: Wed, 4 Jan 2017 21:03:41 -0500 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1149971e8224e705454f4f51 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 02:03:45 -0000 --001a1149971e8224e705454f4f51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sue, Thanks for your quick and detailed response. inline On Wed, Jan 4, 2017 at 6:52 PM, Susan Hares wrote: > Kathleen: > > > > I'm confused by your request. I thought draft-ietf-i2rs-protocol-security= -requirements-17.txt > was written to answer this questions for all I2RS modules. We knew this > new style of interface with Yang modules had these privacy and security > constraints. This data module SHOULD only run under the protocol securit= y > constraints listed in the draft-ietf-i2rs-protocol-security-requirements-= 17.txt > module. This document left out of this yang module because I thought we > covered in the global document. Each of the I2RS global modules provide= s > information will have these concerns. > I just looked again and there is no reference to the requirements document in the security considerations section that says, look here for the additional security and privacy considerations. That's why it didn't occur to me when reading the draft. > Let me review these concerns: > > > > =C2=B7 Topology modules - you correctly note that the draft > -i2rs-yang-network-topology model has privacy concerns regarding the > identifiers and grouping of devices. You also correctly note that networ= k > topology and network inventory can be used to attack the modules. > > You may want to call out the specific identifiers (in a list) in the security considerations section when you reference the security requirements draft. It's helpful to have specifics about a draft called out that go beyond the general requirements document. > > > =C2=B7 RIB modules - You should understand the I2RS RIB has group= ing > and names that could be used to identify groups of routes. In addition, > RIB information quickly inserted/pulled from nodes is an attack vector. > > > > =C2=B7 FB RIB module - The filter based RIBS indicates the filter= s > that control forwarding of data on selected interfaces. It uses group > names to group these filters for companies or to group filters by > function. You can expand the topology concerns to the filters as well. > Please do call out these concerns explicitly. It may help developers and implementers. > > > =C2=B7 The I2NSF data modules build upon these concepts. > > > > Do you wish threat sections in each module? Could you provide a template > for these threat comments. If you wish to limit group identifiers in all > of these modules, it would be good to provide write-up on what is good/ba= d > group identifiers so the authors provide the > I called out identifiers specifically as this document had a few and that is something to watch for per RFC6973. Your other comments are helpful and would aid a reader. > > > In future SEC-DIR reviews, it would be good for your reviewers to > specifically examine the document to see if these issues have been > addressed. > Yes, if you'd like to add the concerns that have come up in the recent document reviews to the discussion on the SAAG list for 3552, that would be very helpful. That document needs revision, but really needs input from cross area contributors as they are the intended audience. Please help us get that draft to a state that it assists editors from other areas. Thank you, Kathleen > > > Sue Hares (shepherd) > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1. Privacy considerations - I don't see any listed and the YANG module > include a few identifiers as well as ways to group devices. I think > privacy considerations need to be added for use of this module. > > > > 2. Security - the network topology and inventory created by this module > reveals information about systems and services. This could be very helpf= ul > information to an attacker and should also be called out as a security > consideration. The access and transport of this information is covered > though in the considerations, just listing this threat would be helpful. > > > > > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 4, 2017 4:34 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo= -10: > (with DISCUSS) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-network-topo-10: Discuss > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for your work on this draft. > > > > I have a couple of things I'd like to discuss that may require some > additional text, but should be easy to resolve. > > > > 1. Privacy considerations - I don't see any listed and the YANG module > include a few identifiers as well as ways to group devices. I think > privacy considerations need to be added for use of this module. > > > > 2. Security - the network topology and inventory created by this module > reveals information about systems and services. This could be very helpf= ul > information to an attacker and should also be called out as a security > consideration. The access and transport of this information is covered > though in the considerations, just listing this threat would be helpful. > > > > Thank you. > > > > > > > > > --=20 Best regards, Kathleen --001a1149971e8224e705454f4f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sue,

Thanks for your quick and detai= led response. =C2=A0inline

On Wed, Jan 4, 2017 at 6:52 PM, Susan Hares <shares@ndzh.co= m> wrote:

Kathleen:

=C2=A0

I'm confused by y= our request. I thought draft-ietf-i2rs-protocol-security-requirements-= 17.txt was written to answer this questions for all I2RS modules.=C2=A0 We = knew this new style of interface with Yang modules had these privacy and se= curity constraints.=C2=A0 This data module SHOULD only run under the protoc= ol security constraints listed in the draft-ietf-i2rs-protocol-securit= y-requirements-17.txt module.=C2=A0 This document left out of this yang mod= ule because I thought we covered in the global document. =C2=A0=C2=A0Each o= f the I2RS global modules provides information will have these concerns.


I just looked again and there= is no reference to the requirements document in the security consideration= s section that says, look here for the additional security and privacy cons= iderations.=C2=A0 That's why it didn't occur to me when reading the= draft.

=C2=A0 Let me review these conce= rns:

<= /u>=C2=A0

=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Topology modu= les - you correctly note that the draft -i2rs-yang-network-topology model h= as privacy concerns regarding the identifiers and grouping of devices.=C2= =A0 You also correctly note that network topology and network inventory can= be used to attack the modules.

You may wan= t to call out the specific identifiers (in a list) in the security consider= ations section when you reference the security requirements draft.=C2=A0 It= 's helpful to have specifics about a draft called out that go beyond th= e general requirements document.

=C2=A0<= u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 RIB modules - You should und= erstand the I2RS RIB has grouping and names that could be used to identify = groups of routes.=C2=A0 In addition, RIB information quickly inserted/pulle= d from nodes is an attack vector.

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB RIB module - The filter based RIBS indicates the filters that = control forwarding of data on selected interfaces.=C2=A0 It uses group name= s to group these filters for companies or to group filters by function.=C2= =A0=C2=A0 You can expand the topology concerns to the filters as well.

<= /div>

Please do call out these concer= ns explicitly.=C2=A0 It may help developers and implementers. =C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=

=C2=A0

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The I2NSF data modules build upon these = concepts.=C2=A0 =C2=A0

=C2=A0

Do you wish threat sections in each module?=C2=A0 Could you provi= de a template for these threat comments.=C2=A0 If you wish to limit group i= dentifiers in all of these modules, it would be good to provide write-up on= what is good/bad group identifiers so the authors provide the


I called out identifiers specifically a= s this document had a few and that is something to watch for per RFC6973.= =C2=A0 Your other comments are helpful and would aid a reader.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

In future SEC-DIR reviews, it would be good for your revi= ewers to specifically examine the document to see if these issues have been= addressed.


Yes, if you'= ;d like to add the concerns that have come up in the recent document review= s to the discussion on the SAAG list for 3552, that would be very helpful.= =C2=A0 That document needs revision, but really needs input from cross area= contributors as they are the intended audience.=C2=A0 Please help us get t= hat draft to a state that it assists editors from other areas.=C2=A0
<= div>
Thank you,
Kathleen

=C2=A0

Su= e Hares (shepherd)

=C2=A0

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0<= /p>

1. Privacy consideration= s - I don't see any listed and the YANG module include a few identifier= s as well as ways to group devices.=C2=A0 I think privacy considerations ne= ed to be added for use of this module.

=C2=A0

2. Security - the network topology and inventory = created by this module reveals information about systems and services.=C2= =A0 This could be very helpful information to an attacker and should also b= e called out as a security consideration. The access and transport of this = information is covered though in the considerations, just listing this thre= at would be helpful.

=C2=A0

=C2=A0

-----Original Message-----
From: Kath= leen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
Sent: Wedne= sday, January 4, 2017 4:34 PM
To: The IESG
Cc: draft-ietf-i2rs-y= ang-network-topo@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
Subject: Kathleen Mor= iarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DIS= CUSS)

=C2=A0

Kathleen Moriarty has= entered the following ballot position for

draft-ietf-i2rs-yang-network-topo-10:= Discuss

<= u>=C2=A0

When= responding, please keep the subject line intact and reply to all email add= resses included in the To and CC lines. (Feel free to cut this introductory= paragraph, however.)

=C2=A0

=C2=A0

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.

=C2=A0<= u>

=C2=A0<= /u>

The document, along = with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/

<= p class=3D"m_-2480241818447443516MsoPlainText">=C2=A0

=C2=A0

=C2=A0

------------------------------= ----------------------------------------

DISCUSS:

-----------------------------------= -----------------------------------

=C2=A0

Thanks for your work on this draft.

=C2=A0<= /p>

I have a couple of thing= s I'd like to discuss that may require some additional text, but should= be easy to resolve.

=C2=A0

1. Privacy considerations - I don't see any listed and the YANG= module include a few identifiers as well as ways to group devices.=C2=A0 I= think privacy considerations need to be added for use of this module.

=C2=A0<= u>

2. Security - the= network topology and inventory created by this module reveals information = about systems and services.=C2=A0 This could be very helpful information to= an attacker and should also be called out as a security consideration. The= access and transport of this information is covered though in the consider= ations, just listing this threat would be helpful.

=C2=A0

Thank you.

=C2=A0

=C2=A0

=C2=A0

=C2=A0




--

Best regards,
Kathleen
--001a1149971e8224e705454f4f51-- From nobody Thu Jan 5 01:24:32 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 70E23129AF0; Thu, 5 Jan 2017 01:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 UqetE1OdEZ49; Thu, 5 Jan 2017 01:24:29 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60A7129AE9; Thu, 5 Jan 2017 01:24:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DE8A473B; Thu, 5 Jan 2017 10:24:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id J6_vsp_BYc-C; Thu, 5 Jan 2017 10:24:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jan 2017 10:24:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D58820086; Thu, 5 Jan 2017 10:24:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pxArBww4fnwP; Thu, 5 Jan 2017 10:24:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF5CF20085; Thu, 5 Jan 2017 10:24:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E332B3E01947; Thu, 5 Jan 2017 10:24:26 +0100 (CET) Date: Thu, 5 Jan 2017 10:24:26 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170105092425.GA9639@elstar.local> Mail-Followup-To: Susan Hares , 'Ben Campbell' , 'The IESG' , i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org References: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Ben Campbell' , draft-ietf-i2rs-yang-network-topo@ietf.org, 'The IESG' , i2rs-chairs@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:24:31 -0000 I think we need security solution text not security requirements text. Anyway, for YANG modules, there is a security considerations template (RFC 6087 section 6 and kept updated at [1]) that I think applies here as well. [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines /js On Wed, Jan 04, 2017 at 07:27:20PM -0500, Susan Hares wrote: > Ben: > > I have responded to Kathleen's comment with a lengthy set of questions. Would you engage in the conversation on that thread? > > Summary of the issue: These modules and any module that refers to these must utilize the privacy and security concerns in the draft-ietf-i2rs-protocol-security-requirements-17.txt. I see the authors referred to the ephemeral state, but left out a reference to draft-ietf-i2rs-protocol-security-requirements. I would suggest that the authors add this reference at the very least. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, January 4, 2017 5:19 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with both of Kathleen's DISCUSS points. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 5 03:45:57 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 DC25812996B; Thu, 5 Jan 2017 03:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlk4VaHDyNjW; Thu, 5 Jan 2017 03:45:50 -0800 (PST) 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 EB03F12943F; Thu, 5 Jan 2017 03:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8053; q=dns/txt; s=iport; t=1483616749; x=1484826349; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=c/PPLsR4rWYo5hOjd3Xc/HBZbgvwJV3DU9qQeS4HHXg=; b=lHE6G6iHgnejzeQx4NU4qROoXMLJrXN00xgRO7RmUP+LRQn1tdXfIDMO ln8iP7pp5SgYbmHOzedY9LV+V+oC+dRNu8qsNjCRD+tHN9aoWg7TPB0uc 64JHvQ2dB8rY75PiB2BKP6L84k0DJIZi/Ig5EkVZBQj5vSs4MIhdi9u8+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAQCTMW5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAX6BDINPighyk1WPfYMbgg+CCSqFeAKCFxQBAgEBAQE?= =?us-ascii?q?BAQFjKIRoAQEBAwEjVhALGCoCAlcGAQwIAQGIZAgOrzOCJSuJewEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhkWCAgiCV4QYEQGDJIJeBYhxkh+GVoptgXaFCIMnhjW?= =?us-ascii?q?KT4d3HzhtIhIHExUzhFyBSD01AYY3gi4BAQE?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208,217";a="648521520" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 11:45:44 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v05BjhdO032724; Thu, 5 Jan 2017 11:45:43 GMT To: Kathleen Moriarty , The IESG References: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Thu, 5 Jan 2017 12:45:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------1E11985B2BD998E2B01C9B48" Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 11:45:52 -0000 This is a multi-part message in MIME format. --------------1E11985B2BD998E2B01C9B48 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/4/2017 10:33 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. > > I have a couple of things I'd like to discuss that may require some > additional text, but should be easy to resolve. > > 1. Privacy considerations - I don't see any listed and the YANG module > include a few identifiers as well as ways to group devices. I think > privacy considerations need to be added for use of this module. > > 2. Security - the network topology and inventory created by this module > reveals information about systems and services. This could be very > helpful information to an attacker and should also be called out as a > security consideration. The access and transport of this information is > covered though in the considerations, just listing this threat would be > helpful. https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines template should be applied (I mentioned that in a previous review). The first paragraph of the Security Considerations is right, but the rest of the section doesn't quite follow the template (which is something that the RFC editor will check). For example, the following should be copied verbatim: There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: And should be populated, based on the second paragraph of the current Security Considerations. Regarding your point "the network topology and inventory created by this module reveals information about systems and services. This could be very helpful information to an attacker and should also be called out as a security consideration.", I believe that this is covered by the previous paragraph. as most nodes are config-true. Regarding the "listing this threat would be helpful.", I'm not convinced that this is necessary to change the security guidelines YANG template. As a comparison on how we've been documenting security considerations for MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security Regards, Benoit > > Thank you. > > > > > . > --------------1E11985B2BD998E2B01C9B48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/4/2017 10:33 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft.

I have a couple of things I'd like to discuss that may require some
additional text, but should be easy to resolve.

1. Privacy considerations - I don't see any listed and the YANG module
include a few identifiers as well as ways to group devices.  I think
privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module
reveals information about systems and services.  This could be very
helpful information to an attacker and should also be called out as a
security consideration. The access and transport of this information is
covered though in the considerations, just listing this threat would be
helpful.
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines template should be applied (I mentioned that in a previous review).
The first paragraph of the Security Considerations is right, but the rest of the section doesn't quite follow the template (which is something that the RFC editor will check).
For example, the following should be copied verbatim:
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
And <list subtrees and data nodes and state why they are sensitive> should be populated, based on the second paragraph of the current Security Considerations.
Regarding your point "the network topology and inventory created by this module reveals information about systems and services. This could be very helpful information to an attacker and should also be called out as a security consideration.", I believe that this is covered by the previous paragraph. as most nodes are config-true.

Regarding the "listing this threat would be helpful.", I'm not convinced that this is necessary to change the security guidelines YANG template.
As a comparison on how we've been documenting security considerations for MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security

Regards, Benoit



Thank you.




.

--------------1E11985B2BD998E2B01C9B48-- From nobody Thu Jan 5 03:50:34 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 F21F012943F; Thu, 5 Jan 2017 03:50:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148361702998.20665.17386642680680031937.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 03:50:29 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:50:30 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Reading this document one more time, some more editorial comment - OLD: At the same time, where data specific to a network type does comes into play NEW: At the same time, where data specific to a network type does come into play - The figure shows two Service Functions - X1 and X2 - mapping onto a single L3 network element; this could happen, for example, if two service functions reside in the same VM (or server) and share the same set of network interfaces. You meant X1 and X3, mapping to the same Y2 L3 network element, right? - please expand ROADM - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - OLD: The abstract (base) network model is defined in the network.yang module. Its structure is shown in the following figure. Brackets enclose list keys, "rw" means configuration data, "ro" means operational state data, and "?" designates optional nodes. A "+" indicates a line break. NEW (cut/paste from RFC8022 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), "ro" state data (read-only), "-x" RPC operations or actions, and "-n" notifications. o Symbols after data node names: "?" means an optional node, "!" a container with presence, and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. Note that you have two instances of this. - Final comment: the security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as replied to Kathleen's DISCUSS. From nobody Thu Jan 5 03:57:02 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 E042C129442; Thu, 5 Jan 2017 03:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 w5Z_H6e1E5ty; Thu, 5 Jan 2017 03:57:00 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 78171129418; Thu, 5 Jan 2017 03:57:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C70AA2D291; Thu, 5 Jan 2017 13:56:59 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh1GnaueM05W; Thu, 5 Jan 2017 13:56:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2F9B52D290; Thu, 5 Jan 2017 13:56:59 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E7D39F5C-09B9-4A66-A03F-C76249456EC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> Date: Thu, 5 Jan 2017 13:56:58 +0200 Message-Id: <22E401B5-ECF9-4F5D-A748-B474064397B0@piuha.net> References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: i2rs@ietf.org, General Area Review Team , IETF Discussion , draft-ietf-i2rs-yang-network-topo.all@ietf.org Subject: Re: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 11:57:02 -0000 --Apple-Mail=_E7D39F5C-09B9-4A66-A03F-C76249456EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks for your detailed review, Stewart! Authors, did you take a note of Stewart's editorial comments? The = editorial control is in your hands, but I=92d like to know that you saw = the comments. Jari --Apple-Mail=_E7D39F5C-09B9-4A66-A03F-C76249456EC6 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 iQIcBAEBCgAGBQJYbjSKAAoJEM80gCTQU46qTdIP/0zGAVITrbNxQH84kCQzdoK5 rZhgbhBwENcKLnm38HcUbDZHaCkK0ox88uAw6BnsKy0rkEnkB2IwZJOfH7Pk9N7Y tpD7UMbpahQ8QUjyD20dMLdbpLL6oTLLv6SAoXvh5bl7sMqlhbMRKczqYzTTE+nX l5pFrQKfKfp3fO1+wSmANB0EzQwGuOQ+PnfyfmLm8Ng4iZXHjVujF/IUmW7e7ajg VyvacS2iRcPhtLci4icxB5m6lkkef1ZT0pA8/S7p+SSN3l7BNtNo6LoDNaWxRZaO fMBHHl/kLuGj5UXz6dXB034WYdstTXA34JRh7cBDUn0Pmy3EzK+lE07kQEjxDceh qSabb3cx5sH7ceA++9mWvrmEW/t0ck3qpjSIwZkZCU4fxyaAfSL+3sFePolL5IV3 hMnzRH/TQhyOwDZBcoiNFKYFRGnBuxV1l5u/eUhMqOPLAx6K+BKodb6nlMQLVcaz HQeBtkXf5288sRmTCrIhrnhDVVNeLlbp1UrbQIuTxB0NoWgttnevlq2yoedNwtSW flv1V3LpOH7m78M6y32dLp+4VV4rV/trO2w1GoYnzjznOdQcrnEdsGnVxs9yViO1 BnDY+hSjFe3hLRvuHYnJvLC2pySOLxSjE7VfgDly/AmYwDB3cV64bqjlxwcZLq5R 2+qfy52FzXrQmxLaECLB =QQ5s -----END PGP SIGNATURE----- --Apple-Mail=_E7D39F5C-09B9-4A66-A03F-C76249456EC6-- From nobody Thu Jan 5 04:20:44 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 09F0B129B09; Thu, 5 Jan 2017 04:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK1pJHgvTQDp; Thu, 5 Jan 2017 04:20:40 -0800 (PST) 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 C6D18128AB0; Thu, 5 Jan 2017 04:20:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDW69371; Thu, 05 Jan 2017 12:20:37 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Jan 2017 12:20:24 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 04:19:32 -0800 From: Alexander Clemm To: Jari Arkko , Stewart Bryant Thread-Topic: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 Thread-Index: AQHSZ0r+7QEc397uU0KE8qMDLS9KoaEpzFnw Date: Thu, 5 Jan 2017 12:19:32 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E3C35E4@dfweml501-mbb> References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> <22E401B5-ECF9-4F5D-A748-B474064397B0@piuha.net> In-Reply-To: <22E401B5-ECF9-4F5D-A748-B474064397B0@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.98.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.586E3A15.00B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dcde345a6b2975915f9b742cf7a5e6db Archived-At: Cc: Alexander Clemm , "i2rs@ietf.org" , General Area Review Team , IETF Discussion , "draft-ietf-i2rs-yang-network-topo.all@ietf.org" Subject: Re: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:20:43 -0000 Hello Jari, No, I did not see Stewart's comments and checking my email, I don't think I= received them. (I saw other comments, e.g. Kathleen's and Benoit's.) Ste= wart, could you please resend? =20 Thank you! --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, January 05, 2017 12:57 PM To: Stewart Bryant Cc: i2rs@ietf.org; General Area Review Team ; IETF Discus= sion ; draft-ietf-i2rs-yang-network-topo.all@ietf.org Subject: Re: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 Many thanks for your detailed review, Stewart! Authors, did you take a note of Stewart's editorial comments? The editorial= control is in your hands, but I'd like to know that you saw the comments. Jari From nobody Thu Jan 5 04:29:13 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 60214128AB0; Thu, 5 Jan 2017 04:29:11 -0800 (PST) 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 rri6MkJUH8hD; Thu, 5 Jan 2017 04:29:09 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEF01288B8; Thu, 5 Jan 2017 04:29:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> In-Reply-To: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> Date: Thu, 5 Jan 2017 07:25:11 -0500 Message-ID: <010001d2674e$c339a290$49ace7b0$@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: AQF0AXfoQT/TcxtbuDMyfc8n6Au/UqHmmhfA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Jari Arkko' , 'The IESG' Subject: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:29:11 -0000 Alex: We talked about the 6 authors. Stewart's note was on the I2RS list. Please see if you can address it soon. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, December 14, 2016 5:41 AM To: General Area Review Team; draft-ietf-i2rs-yang-network-topo.all@ietf.org; i2rs@ietf.org; IETF Discussion Subject: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-i2rs-yang-network-topo-09 Reviewer: Stewart Bryant Review Date: 12 Dec 2016 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: Ready with issues This is a well written document and is basically ready for publication and the issues are minor. There are a number of minor issues that the responsible AD needs to look into, and a systematic English problem (missing pronouns) that the authors ought fix to avoid the RFC Editor having to ask. There are six authors which I assume is acceptable. I am not a YANG expert and have therefore not checked the YANG syntax or logic. Detail: ========= 1. Introduction This document introduces an abstract (base) YANG [RFC7950] [RFC6991] data model to represent networks and topologies. The data model is divided into two parts. The first part of the model defines a network model that allows to define network hierarchies (i.e. network SB> minor English problem : "allows to define" perhaps "allows the SB> definition of" or "allows an operator to define". stacks) and to maintain an inventory of nodes contained in a network. SB> same problem as above. SB> Also I am a little worried that the term "network stack" is going to SB> to confuse a lot of people. Many will confuse network stack with SB> protocol stack. There probably needs to be some text explaining the SB> difference. ======== While it would be possible to combine both parts into a single model, the separation facilitates integration of network topology and network inventory models, by allowing to augment network inventory information separately and without concern for topology into the network model. SB> same English problem - "by allowing to augment" The model can be augmented to describe specifics of particular types SB> describe THE specifics of networks and topologies. For example, an augmenting model can SB> Not sure is that should be augmenting or augmented (same further SB> down the para). ============= The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The models allow applications to operate on an inventory or topology of any network at a generic level, where specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type does comes into play and the model is augmented, the instantiated data still adheres to the same structure and is represented in consistent SB> nit: in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types. The abstract (base) network YANG module introduced in this document, entitled "network.yang", contains a list of abstract network nodes and defines the concept of network hierarchy (network stack). The abstract network node can be augmented in inventory and topology SB> nit possibly "augmented in both the inventory" SB> either way I think at least a "the" is missing models with inventory and topology specific attributes. Network ========================== A network can contain multiple topologies, for example topologies at different layers and overlay topologies. The model therefore allows to capture SB> English: "allows to capture" - who does it allow to make a capture? relationships between topologies, as well as dependencies between nodes and termination points across topologies. An example of a topology stack is shown in the following figure. =========================== 3. Definitions and Acronyms HTTP: Hyper-Text Transfer Protocol SB> HTTP is stared in the "well known" list and so does not need SB> expanding also it is only used once in the text =========================== When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of empty type. This allows to represent SB> missing word "This allows who or what to represent" =========================== This (physical) network, respectively the (entities) nodes in that network, can then be referred to as underlay network and nodes from the other (logical) networks and nodes, respectively. Note that the model allows to SB> allows who to define? define more than one underlay network (and node), allowing for simultaneous representation of layered network- and service SB> Spurious "-" topologies and physical instantiation. Similar to a network, a node can be supported by other nodes, and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes allows also to represent device stacks, where a node at one SB> Allows who to also? level is supported by a set of nodes at an underlying level. For example, a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules, a virtual router might be supported or hosted on a physical device represented by a separate node, and so on. Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that SB> s/annother/another/ can be discovered. SB> I don't understand the end of the previous para. I think you are SB> covering the case of SDN and classic self-learning networks where SB> information is discovered from neighbours. If that is the case it is SB> not clear from the text above. If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be SB> s/be/being/ reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. ========================== A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. SB> When I read this I immediately wondered about multi-point links You SB> clear up later that your model does not support them. It would be SB> kind to the reader to pre-empt the question here. =========================== 4.4.4. Use of groupings The model makes use of groupings, instead of simply defining data nodes "in-line". This allows to more easily include the SB> this allows who? ============================= 4.4.7. Mapping redundancy In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the link-to-links mapping known, and the termination points of each link SB> link-to-links mapping IS known ============================ In the case of a physical network, nodes represent physical devices and termination points physical ports. It should be noted that it is also conceivable to augment the model for a physical network-type, SB> do you mean conceivable or possible? ==================== That said, it is conceivable that certain types of topology need to also be SB> again I think you mean "it is possible" configurable by an application. The model needs to support both cases. ===================== Another alternative would make use of a YANG extension to tag specific network instances as "server-provided" instead of defining a leaf object, or rely on the concept of YANG metadata [RFC7952] for SB> perhaps "or relying on" the same effect. The tag would be automatically applied to any topology data that comes into being (respectively is configured) by an embedded application on the network, as opposed to e.g. a controller application. ======================== 4.4.11. Identifiers of string or URI type The current model defines identifiers of nodes, networks, links, and termination points as URIs. An alternative would define them as string. SB> given "them" (plural) I think that should be "strings" The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology/node/tp exists in a larger context, hence it is useful to be able to correlate identifiers across systems. While strings, being the universal data type, are easier for human beings (a string is a string is a string), SB> Well maybe, it could be an ASCII string or an EBCDIC string etc _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 5 04:37:08 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 DEAD7129B12; Thu, 5 Jan 2017 04:36:50 -0800 (PST) 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 3fULeZBewIGc; Thu, 5 Jan 2017 04:36:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564BE129500; Thu, 5 Jan 2017 04:36:46 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> <20170105092425.GA9639@elstar.local> In-Reply-To: <20170105092425.GA9639@elstar.local> Date: Thu, 5 Jan 2017 07:32:48 -0500 Message-ID: <010201d2674f$d3b0c3a0$7b124ae0$@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: AQExe0vDeG0NwR6KCwLlthiLk2jzIgG3UVnYAq9gNXCiSHHX4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Ben Campbell' , draft-ietf-i2rs-yang-network-topo@ietf.org, 'The IESG' , i2rs-chairs@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:36:51 -0000 Juergen: Where does this security solution cover the privacy issues or the ephemeral state concepts I2RS protocol security suggests? I think this solution is a good start, but if we are using this solution in this context I think this needs to be upgraded. How do go about expanding this section to include these issues? Which WG or set of people do we discuss this with? Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, January 5, 2017 4:24 AM To: Susan Hares Cc: 'Ben Campbell'; 'The IESG'; i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) I think we need security solution text not security requirements text. Anyway, for YANG modules, there is a security considerations template (RFC 6087 section 6 and kept updated at [1]) that I think applies here as well. [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines /js On Wed, Jan 04, 2017 at 07:27:20PM -0500, Susan Hares wrote: > Ben: > > I have responded to Kathleen's comment with a lengthy set of questions. Would you engage in the conversation on that thread? > > Summary of the issue: These modules and any module that refers to these must utilize the privacy and security concerns in the draft-ietf-i2rs-protocol-security-requirements-17.txt. I see the authors referred to the ephemeral state, but left out a reference to draft-ietf-i2rs-protocol-security-requirements. I would suggest that the authors add this reference at the very least. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, January 4, 2017 5:19 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ben Campbell's No Objection on > draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with both of Kathleen's DISCUSS points. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 5 04:39: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 EBDDE1294FB; Thu, 5 Jan 2017 04:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyhuORWr6d3r; Thu, 5 Jan 2017 04:39:15 -0800 (PST) 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 E1E8412948E; Thu, 5 Jan 2017 04:39:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYH22574; Thu, 05 Jan 2017 12:39:12 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Jan 2017 12:39:11 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 04:39:04 -0800 From: Alexander Clemm To: Susan Hares , "alex@clemm.org" Thread-Topic: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 Thread-Index: AQHSZ09nXkFWAbnWIkCmons2iPTClaEp0omA Date: Thu, 5 Jan 2017 12:39:04 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E3C361A@dfweml501-mbb> References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> <010001d2674e$c339a290$49ace7b0$@ndzh.com> In-Reply-To: <010001d2674e$c339a290$49ace7b0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.98.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.586E3E71.017D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4b09399d96122990e8b3d85dfcb4f3e8 Archived-At: Cc: "i2rs@ietf.org" , 'Jari Arkko' , 'The IESG' Subject: Re: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:39:19 -0000 Thank you, Sue - got it --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 05, 2017 1:25 PM To: alex@clemm.org Cc: i2rs@ietf.org; 'Jari Arkko' ; 'The IESG' Subject: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 Alex: We talked about the 6 authors. Stewart's note was on the I2RS list. Pleas= e see if you can address it soon.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, December 14, 2016 5:41 AM To: General Area Review Team; draft-ietf-i2rs-yang-network-topo.all@ietf.org; i2rs@ietf.org; IETF Discuss= ion Subject: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at . Document: draft-ietf-i2rs-yang-network-topo-09 Reviewer: Stewart Bryant Review Date: 12 Dec 2016 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: Ready with issues This is a well written document and is basically ready for publication and= the issues are minor. There are a number of minor issues that the responsible AD needs to look i= nto, and a systematic English problem (missing pronouns) that the authors o= ught fix to avoid the RFC Editor having to ask. There are six authors which I assume is acceptable. I am not a YANG expert and have therefore not checked the YANG syntax or lo= gic. Detail: =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Introduction This document introduces an abstract (base) YANG [RFC7950] [RFC6991] data model to represent networks and topologies. The data model is divided into two parts. The first part of the model defines a network model that allows to define network hierarchies (i.e. network SB> minor English problem : "allows to define" perhaps "allows the=20 SB> definition of" or "allows an operator to define". stacks) and to maintain an inventory of nodes contained in a network. SB> same problem as above. SB> Also I am a little worried that the term "network stack" is going to=20 SB> to confuse a lot of people. Many will confuse network stack with=20 SB> protocol stack. There probably needs to be some text explaining the=20 SB> difference. =3D=3D=3D=3D=3D=3D=3D=3D While it would be possible to combine both parts into a single model, the separation facilitates integration of network topology and network inventory models, by allowing to augment network inventory information separately and without concern for topology into the network model. SB> same English problem - "by allowing to augment" The model can be augmented to describe specifics of particular types SB> describe THE specifics of networks and topologies. For example, an augmenting model can SB> Not sure is that should be augmenting or augmented (same further=20 SB> down the para). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The models allow applications to operate on an inventory or topology of any network at a generic level, where specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type does comes into play and the model is augmented, the instantiated data still adheres to the same structure and is represented in consistent SB> nit: in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types. The abstract (base) network YANG module introduced in this document, entitled "network.yang", contains a list of abstract network nodes and defines the concept of network hierarchy (network stack). The abstract network node can be augmented in inventory and topology SB> nit possibly "augmented in both the inventory" SB> either way I think at least a "the" is missing models with inventory and topology specific attributes. Network =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D A network can contain multiple topologies, for example topologies at different layers and overlay topologies. The model therefore allows to capture SB> English: "allows to capture" - who does it allow to make a capture? relationships between topologies, as well as dependencies between nodes and termination points across topologies. An example of a topology stack is shown in the following figure. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 3. Definitions and Acronyms HTTP: Hyper-Text Transfer Protocol SB> HTTP is stared in the "well known" list and so does not need=20 SB> expanding also it is only used once in the text =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of empty type. This allows to represent SB> missing word "This allows who or what to represent" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D This (physical) network, respectively the (entities) nodes in that network, can then be referred to as underlay network and nodes from the other (logical) networks and nodes, respectively. Note that the model allows to SB> allows who to define? define more than one underlay network (and node), allowing for simultaneous representation of layered network- and service SB> Spurious "-" topologies and physical instantiation. Similar to a network, a node can be supported by other nodes, and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes allows also to represent device stacks, where a node at one SB> Allows who to also? level is supported by a set of nodes at an underlying level. For example, a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules, a virtual router might be supported or hosted on a physical device represented by a separate node, and so on. Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that SB> s/annother/another/ can be discovered. SB> I don't understand the end of the previous para. I think you are=20 SB> covering the case of SDN and classic self-learning networks where=20 SB> information is discovered from neighbours. If that is the case it is=20 SB> not clear from the text above. If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be SB> s/be/being/ reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. SB> When I read this I immediately wondered about multi-point links You=20 SB> clear up later that your model does not support them. It would be=20 SB> kind to the reader to pre-empt the question here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 4.4.4. Use of groupings The model makes use of groupings, instead of simply defining data nodes "in-line". This allows to more easily include the SB> this allows who? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 4.4.7. Mapping redundancy In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the link-to-links mapping known, and the termination points of each link SB> link-to-links mapping IS known =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D In the case of a physical network, nodes represent physical devices and termination points physical ports. It should be noted that it is also conceivable to augment the model for a physical network-type, SB> do you mean conceivable or possible? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D That said, it is conceivable that certain types of topology need to also be SB> again I think you mean "it is possible" configurable by an application. The model needs to support both cases. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Another alternative would make use of a YANG extension to tag specific network instances as "server-provided" instead of defining a leaf object, or rely on the concept of YANG metadata [RFC7952] for SB> perhaps "or relying on" the same effect. The tag would be automatically applied to any topology data that comes into being (respectively is configured) by an embedded application on the network, as opposed to e.g. a controller application. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.4.11. Identifiers of string or URI type The current model defines identifiers of nodes, networks, links, and termination points as URIs. An alternative would define them as string. SB> given "them" (plural) I think that should be "strings" The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology/node/tp exists in a larger context, hence it is useful to be able to correlate identifiers across systems. While strings, being the universal data type, are easier for human beings (a string is a string is a string), SB> Well maybe, it could be an ASCII string or an EBCDIC string etc _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 5 04:52:23 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 8CF4D1293EC; Thu, 5 Jan 2017 04:52:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 04:52:19 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:52:19 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Kathleen's discuss points and have one more aspect to offer that I hope you include in that discussion: This model I think will lead designers to only think about the nodes that are supposed to have access to traffic. (See also below about broadcast media.) The model will generally not capture the reality that some other nodes can also actually see or influence traffic and I think that will lead to vulnerabilities not being recognised. I don't have a good suggestion for how to fix that problem but I do think you ought mention it as a security consideration, e.g. something like: "For models such as these - the real world network may allow additional communications or links that are not represented in the model and such links may enable vulnerabilities that are liable to be missed when considering only the model. These models don't really capture the security or privacy aspects of the network." - 4.2 and generally: It is not clear to me how to represent broadcast media (e.g. radio) nor how IP multicast would be reflected in this model. I assume those can be done but as a bit of a hack. - nit: 6 authors and 4 contributors. I wish people (esp chairs) would just enforce the 5 author guideline and say why that's inappropriate in the few instances in which that is the case. From nobody Thu Jan 5 04:53:02 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 76F3C1293EC; Thu, 5 Jan 2017 04:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 c79-An671WZV; Thu, 5 Jan 2017 04:53:00 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5B1128B44; Thu, 5 Jan 2017 04:53:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7B1672D291; Thu, 5 Jan 2017 14:52:59 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHUffXraXzgQ; Thu, 5 Jan 2017 14:52:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1ED602D290; Thu, 5 Jan 2017 14:52:59 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_86614716-51F1-4295-9C35-5D678E84B751"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E3C361A@dfweml501-mbb> Date: Thu, 5 Jan 2017 14:52:58 +0200 Message-Id: References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> <010001d2674e$c339a290$49ace7b0$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C361A@dfweml501-mbb> To: Alexander Clemm X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "i2rs@ietf.org" , "alex@clemm.org" , The IESG , Susan Hares Subject: Re: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:53:01 -0000 --Apple-Mail=_86614716-51F1-4295-9C35-5D678E84B751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Seems like you got it now. I don=92t think we should worry about the 6 = authors at the moment. But do look at the rest. Jari --Apple-Mail=_86614716-51F1-4295-9C35-5D678E84B751 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 iQIcBAEBCgAGBQJYbkGqAAoJEM80gCTQU46qzFAP/0TRn1G6M0mtKW25EDfYeEJr 1LIjKa0n9AuPxn00EmV4Noso2+/Dryd4b9YFZ3u+rboC4TfkRhfeironRuLkA+ad rDQPPm5A7+VZrVscuCBxUC5ZxFzY0OFxVfMCH7P7dOQWtGq3ATogZvJJDbRq351o NqeL00ZqNBUN0G2pcNNP0OcJkGOZqM2i2fe+Yx34qsviVD/0N33aoeKHQ9yIIU6M vyb3Hrr7rGfVhXS7YHl9yRtXLVbbz9otMA0a888pHimEIPsvPiSXU5QfqRiYs/pV cFUI202SNd1j7+m9T/62oeRapYi6MR2HNIBVKcIpmuz6PJ0xm2y+AEu3tjOftUYO sGmQSGhsQPqLJikSK1lvLIM0w2bmFO5RNTsRUZ95qWHYJNrq97U6smrfektZovYc S3oHSa9TH6XRw3ZoyoHcSMCMmt1hheRadEuhvkMNpiKMNQVF2tBBUbiKQ1AU94qP fCLebK+gVBjfk/Q4ypgzLwNEYnIqL3rp8WyP4lVoGC7NWtMJVLSL61yEsuJOrM2p WcLjbkwcWcn1bpXpMt1fUEQe6oaJ72FMRW5AoZz18jqajSU12hdFyB91GDFrvIIu 09rbVD612po5JM3VCmIyUShseKOAPEVoXZek7B4g4nRyHtHlewhvq0PX7FZ43unZ XJDffar8dJPOe7qyNjUt =d6BN -----END PGP SIGNATURE----- --Apple-Mail=_86614716-51F1-4295-9C35-5D678E84B751-- From nobody Thu Jan 5 04:56:11 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 515FE129B15; Thu, 5 Jan 2017 04:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Pgoe6NU7rl5E; Thu, 5 Jan 2017 04:56:05 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A632129500; Thu, 5 Jan 2017 04:56:05 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id r204so341654139ywb.0; Thu, 05 Jan 2017 04:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pyGGXJ52gFJ0PrmytzGLrvav0O4bC0cldG3DKlRVvB8=; b=HDGk1CAU7KEk5tdwv9qBaRU9lMB1ASkaDVczFpC0sm9EBxNSnl1msMTLKFnBxeTyu+ Ue7iQ4gLdaJrkcJAATrwImrikIheMmFgZKWbcMMt8ce42nDtNXWVHN7wQftV9sZfaxwj ihx/Ip32nGiYUFWhHWODwFjXnaNLUrVTF1hjih0XnsFDSMksKrtoJ9DuR7wSCenjIdvG o3MxwX+DLPCN8ADV69rEfsO7qvjHz9yuRGJQkLTdmTBVvewcyn/5xbO4TJWxoZdR1rrk vRsi6SJLllSPYNq6Cl6WYL4CNtNIi51LySD6mJyRat4vMT0Al9jidvNR1OJPq90ZsoiA d65g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pyGGXJ52gFJ0PrmytzGLrvav0O4bC0cldG3DKlRVvB8=; b=KiYquY0Mpb31i/QeS0WJifuWN7KJMT09k2Uw7hM7axshR5bvXna//ja8neTm55ZjNw 0D8OPW1brJ2FWlGr2JuNAaTHlx0dc4Bs3f6ZodjVFoTSQciSBloaDaf6/eWZ2LpheVPq CI3WzqFxQBjmncBCAKwpOpTH3CMM3deeTlUNBbt+H5FuNYMC98B+5C/U0Y+eHSUPS5ws 2JptB31MC0viZCvoimVcFq/KjCXbExug+wrt6VIiZlBvOWyVz6t4v2mbY2HVc+TQgGCu u7QvvltBYvLQ6vYMc//Z8kDQ+VMDu8gA3yq6mnqaI1evSpoSySbz2KBU0bh2o+XqArjU gL3w== X-Gm-Message-State: AIkVDXJ2pCwSSkv01WEf0QqMMn8Pyimv/HG7ixb8wyVkzs3KB2K38PmvskpX38f3h/wmDKRd9tpZ8zoRHjMRpg== X-Received: by 10.129.181.81 with SMTP id c17mr1493346ywk.148.1483620964426; Thu, 05 Jan 2017 04:56:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.177.65 with HTTP; Thu, 5 Jan 2017 04:56:03 -0800 (PST) In-Reply-To: References: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> <010001d2674e$c339a290$49ace7b0$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C361A@dfweml501-mbb> From: Alia Atlas Date: Thu, 5 Jan 2017 07:56:03 -0500 Message-ID: To: Jari Arkko Content-Type: multipart/alternative; boundary=f403045eab4c90ef3e0545586cac Archived-At: Cc: "i2rs@ietf.org" , "alex@clemm.org" , Alexander Clemm , The IESG , Susan Hares Subject: Re: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 12:56:06 -0000 --f403045eab4c90ef3e0545586cac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 5, 2017 at 7:52 AM, Jari Arkko wrote: > Seems like you got it now. I don=E2=80=99t think we should worry about th= e 6 > authors at the moment. But do look at the rest. I did, of course, verify that all the authors are and have been actively involved and contributed significantly. Regards, Alia > Jari > > --f403045eab4c90ef3e0545586cac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 5, 2017 at 7:52 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
Seems like you got it now. I = don=E2=80=99t think we should worry about the 6 authors at the moment. But = do look at the rest.

I did, of course, veri= fy that all the authors are and have been actively involved and contributed= significantly.

Regards,
Alia=C2=A0

=C2=A0
Jari


--f403045eab4c90ef3e0545586cac-- From nobody Thu Jan 5 05:08:57 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 670321294EB; Thu, 5 Jan 2017 05:08:54 -0800 (PST) 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 JrQSxKPqYy2z; Thu, 5 Jan 2017 05:08:48 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831351288B8; Thu, 5 Jan 2017 05:08:48 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: "'Stephen Farrell'" , "'The IESG'" References: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> In-Reply-To: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> Date: Thu, 5 Jan 2017 08:04:52 -0500 Message-ID: <015401d26754$4e55df10$eb019d30$@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: AQLj2y/CxcmIqU1xsrF8A4XtLFbbfZ8G8QxA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 13:08:54 -0000 Stephen:=20 Thank you for letting the authors know about your security concerns. I = think we have some discussion that needs to take place with the authors, = Alia, and Benoit on whether the yang security guidelines are sufficient = or if these need to be expanded based on the I2RS protocol security = requirements. =20 I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and = security issues. It will help us make sure the next I2RS documents = submitted to the IESG have the appropriate security considerations and = threat analysis.=20 On the 6 authors, we really did investigate each authors active = contribution. =20 Sue Hares Document shepherd.=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, January 5, 2017 7:52 AM To: The IESG Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Stephen Farrell's No Objection on = draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Kathleen's discuss points and have one more aspect to offer = that I hope you include in that discussion: This model I think will lead designers to only think about the nodes = that are supposed to have access to traffic. (See also below about = broadcast media.) The model will generally not capture the reality that = some other nodes can also actually see or influence traffic and I think = that will lead to vulnerabilities not being recognised. I don't have a = good suggestion for how to fix that problem but I do think you ought = mention it as a security consideration, e.g. something like: "For models such as these - the real world network may allow = additional communications or links that are not represented in the model = and such links may enable vulnerabilities that are liable to be missed = when considering only the model. These models don't really capture the = security or privacy aspects of the network."=20 - 4.2 and generally: It is not clear to me how to represent broadcast = media (e.g. radio) nor how IP multicast would be reflected in this = model. I assume those can be done but as a bit of a hack. =20 - nit: 6 authors and 4 contributors. I wish people (esp chairs) would = just enforce the 5 author guideline and say why that's inappropriate in = the few instances in which that is the case. From nobody Thu Jan 5 05:49:35 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 9D389129543; Thu, 5 Jan 2017 05:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 BPX4JdHsBVND; Thu, 5 Jan 2017 05:49:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E333129515; Thu, 5 Jan 2017 05:49:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E8FD2793; Thu, 5 Jan 2017 14:49:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P1iFKC6DFtRc; Thu, 5 Jan 2017 14:49:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jan 2017 14:49:26 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56D9D20190; Thu, 5 Jan 2017 14:49:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DKKTlsYpcFFL; Thu, 5 Jan 2017 14:49:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68D1C2018B; Thu, 5 Jan 2017 14:49:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7003A3E0204B; Thu, 5 Jan 2017 14:49:27 +0100 (CET) Date: Thu, 5 Jan 2017 14:49:26 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170105134926.GA9962@elstar.local> Mail-Followup-To: Susan Hares , 'Ben Campbell' , draft-ietf-i2rs-yang-network-topo@ietf.org, 'The IESG' , i2rs-chairs@ietf.org, i2rs@ietf.org References: <148356833544.13064.6457225744421054636.idtracker@ietfa.amsl.com> <016001d266ea$83e837a0$8bb8a6e0$@ndzh.com> <20170105092425.GA9639@elstar.local> <010201d2674f$d3b0c3a0$7b124ae0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010201d2674f$d3b0c3a0$7b124ae0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Ben Campbell' , draft-ietf-i2rs-yang-network-topo@ietf.org, 'The IESG' , i2rs@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:49:30 -0000 Sue, there are places to fill in concrete text. There is even some advice how to do this. /js On Thu, Jan 05, 2017 at 07:32:48AM -0500, Susan Hares wrote: > Juergen: > > Where does this security solution cover the privacy issues or the ephemeral > state concepts I2RS protocol security suggests? I think this solution is a > good start, but if we are using this solution in this context I think this > needs to be upgraded. How do go about expanding this section to include > these issues? > > Which WG or set of people do we discuss this with? > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 5, 2017 4:24 AM > To: Susan Hares > Cc: 'Ben Campbell'; 'The IESG'; i2rs@ietf.org; > draft-ietf-i2rs-yang-network-topo@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ben Campbell's No Objection on > draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > I think we need security solution text not security requirements text. > Anyway, for YANG modules, there is a security considerations template (RFC > 6087 section 6 and kept updated at [1]) that I think applies here as well. > > [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > /js > > On Wed, Jan 04, 2017 at 07:27:20PM -0500, Susan Hares wrote: > > Ben: > > > > I have responded to Kathleen's comment with a lengthy set of questions. > Would you engage in the conversation on that thread? > > > > Summary of the issue: These modules and any module that refers to these > must utilize the privacy and security concerns in the > draft-ietf-i2rs-protocol-security-requirements-17.txt. I see the authors > referred to the ephemeral state, but left out a reference to > draft-ietf-i2rs-protocol-security-requirements. I would suggest that the > authors add this reference at the very least. > > > > Sue > > > > -----Original Message----- > > From: Ben Campbell [mailto:ben@nostrum.com] > > Sent: Wednesday, January 4, 2017 5:19 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Ben Campbell's No Objection on > > draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-i2rs-yang-network-topo-10: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with both of Kathleen's DISCUSS points. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 5 05:50:53 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 0E0A8129543; Thu, 5 Jan 2017 05:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mCPMVzzZ0u3; Thu, 5 Jan 2017 05:50:45 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 F336F1294FF; Thu, 5 Jan 2017 05:50:44 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id u144so96565109wmu.0; Thu, 05 Jan 2017 05:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vE+sA6Sjrbqj9zKfx9XOgl2H3QpNga7IgNdD1Z9NwU=; b=AZIjDwcKmGXOgj0tkIhwh7c3pQx76MBnNbQ6Q33RnstiP9UeRL9TmBPUeFy4NeM655 BFZud/98HbHEEVih/cctj8efQjGRb8y20HakOAIleipF60D4lZv0f/guhSax4DOCMHNy km0yNvJoMhB9uWl2hxn1iVV7RlREnl/2REcLlhV1E4pUzqTMGrSbXpLwMCbQVxhNPIX1 z98kPmJllR3MFQjAarQDGmgY64uHA+xm1AWGf8xTRV1aZVfArIOJHUvcKjlvQGkvMb1N OsKs27sRSWPXrAtdZqbhBxzJ1uKtJDy2Sv8f2utW7Kfc3qTUvQ4c/xGnUc5oLUjUzfkO cMaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vE+sA6Sjrbqj9zKfx9XOgl2H3QpNga7IgNdD1Z9NwU=; b=U+ITdajyatnfhD5Ei18KT00y5RgYswRvl1y5fYR17H7LEhb5o5q6UaCFUhwayv1d3j f8/qCM/BDbaKTDWoa0HzhfOQ3bqafb1b7U5SY8e7BXtqcfGk+kR3EBGbtNEEgzGGuiro vpqadR4OdHyHHh0ijyjC8N6NU0swlUIqz2rogzQg6UnFXGLbJm2ibKtypF6H2e9Rasgb 4VkCG0R0yCWIZNU225SChghUhpefLmXyVOwWfE6C4+U43RJtRh9wqxWS/HEeL/iLJDov bPzP58DivSCSsdVP1ApRM4SqhKWYcx5Kv/45adjmJCVfjdRK7kSWTDzgcrbmReBCpa5M GTtA== X-Gm-Message-State: AIkVDXKT/2XqZUCxgig4nyQuJWfwuhuTeQ0dIY1sRbKrT3xZNg83OIupTA9ixZUpbpfIxg== X-Received: by 10.28.182.70 with SMTP id g67mr67914498wmf.90.1483624243354; Thu, 05 Jan 2017 05:50:43 -0800 (PST) Received: from [10.230.78.20] ([173.38.220.46]) by smtp.gmail.com with ESMTPSA id d10sm103623051wja.20.2017.01.05.05.50.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 05:50:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: <015401d26754$4e55df10$eb019d30$@ndzh.com> Date: Thu, 5 Jan 2017 13:50:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <49200081-A326-4D0C-B989-43289DEF8678@gmail.com> References: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> <015401d26754$4e55df10$eb019d30$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3259) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, The IESG , i2rs-chairs@ietf.org, Stephen Farrell Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 13:50:47 -0000 Re broadcast media those are typically represented (in time-honoured = fashion) as pseudonodes. So while it=E2=80=99s a hack it=E2=80=99s a = well-understood one. For IP multicast you could model the tree for any given multicast group = I suppose? the security note comment makes sense at least to me as a non-author = (but regular user) of the topology model. In general the model only = models what you have access to - you can=E2=80=99t guarantee it=E2=80=99s = a full picture of the network (e.g. if you get L3 topology from BGP-LS = then you=E2=80=99ll only see OSPF or ISIS nodes). Giles > On 5 Jan 2017, at 13:04, Susan Hares wrote: >=20 > Stephen:=20 >=20 > Thank you for letting the authors know about your security concerns. = I think we have some discussion that needs to take place with the = authors, Alia, and Benoit on whether the yang security guidelines are = sufficient or if these need to be expanded based on the I2RS protocol = security requirements. =20 >=20 > I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and = security issues. It will help us make sure the next I2RS documents = submitted to the IESG have the appropriate security considerations and = threat analysis.=20 >=20 > On the 6 authors, we really did investigate each authors active = contribution. =20 >=20 > Sue Hares > Document shepherd.=20 >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 > Sent: Thursday, January 5, 2017 7:52 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Stephen Farrell's No Objection on = draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > I agree with Kathleen's discuss points and have one more aspect to = offer that I hope you include in that > discussion: >=20 > This model I think will lead designers to only think about the nodes = that are supposed to have access to traffic. (See also below about = broadcast media.) The model will generally not capture the reality that = some other nodes can also actually see or influence traffic and I think = that will lead to vulnerabilities not being recognised. I don't have a = good suggestion for how to fix that problem but I do think you ought = mention it as a security consideration, e.g. something > like: "For models such as these - the real world network may allow = additional communications or links that are not represented in the model = and such links may enable vulnerabilities that are liable to be missed = when considering only the model. These models don't really capture the = security or privacy aspects of the network." >=20 > - 4.2 and generally: It is not clear to me how to represent broadcast = media (e.g. radio) nor how IP multicast would be reflected in this = model. I assume those can be done but as a bit of a hack. =20 >=20 > - nit: 6 authors and 4 contributors. I wish people (esp chairs) would = just enforce the 5 author guideline and say why that's inappropriate in = the few instances in which that is the case. >=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 5 05:55:18 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 8BB671294B2; Thu, 5 Jan 2017 05:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTmTckvemQ17; Thu, 5 Jan 2017 05:55:12 -0800 (PST) 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 3A6F0129543; Thu, 5 Jan 2017 05:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3667; q=dns/txt; s=iport; t=1483624511; x=1484834111; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/N4DiMwwliyFpzssalaweKFU71fFQ2siodgzpbFwGlM=; b=QGbQZUzbpW1KP9Cc6hVvjtmNI3qVPz+9huARTv43GA+gyEAHAFbfm5c2 PNZv4s7UeDIFPPa4R45/AO+kWWnp5bZCrlzbAh2WS/+P5GNwZ2vLz+Lqm 1q3TK3qnVRTOIzyQZ2AVbt3pPO4FqXJZQR63Vjj24B8rkspiBekdBAPV1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQDkTm5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoOAQEBAQF+gQyDT4oIcpNWkxiCD4IJKoV4AoIYFAECAQEBAQE?= =?us-ascii?q?BAWMohGgBAQEEIxVBDAQLDgMEAQEDAiMDAgJGCQgGAQwGAgEBiGwOrz2CJYokA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4U6ggKCX4QYEQGDJIJeBYhxkh+GVop?= =?us-ascii?q?tgXaFCIMnhjWKT4d3HzhtIhIHExWEWxwYgUg9NQGGN4IuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="648524844" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 13:55:06 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v05Dt5Ff001656; Thu, 5 Jan 2017 13:55:06 GMT To: Susan Hares , "'Stephen Farrell'" , "'The IESG'" References: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> <015401d26754$4e55df10$eb019d30$@ndzh.com> From: Benoit Claise Message-ID: <40a6e896-c611-ba4d-2f38-cb71b210ef7d@cisco.com> Date: Thu, 5 Jan 2017 14:55:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <015401d26754$4e55df10$eb019d30$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 13:55:17 -0000 Dear all, > Stephen: > > Thank you for letting the authors know about your security concerns. I think we have some discussion that needs to take place with the authors, Alia, and Benoit on whether the yang security guidelines are sufficient or if these need to be expanded based on the I2RS protocol security requirements. This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. Regards, Benoit > > I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and security issues. It will help us make sure the next I2RS documents submitted to the IESG have the appropriate security considerations and threat analysis. > > On the 6 authors, we really did investigate each authors active contribution. > > Sue Hares > Document shepherd. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, January 5, 2017 7:52 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) > > Stephen Farrell has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I agree with Kathleen's discuss points and have one more aspect to offer that I hope you include in that > discussion: > > This model I think will lead designers to only think about the nodes that are supposed to have access to traffic. (See also below about broadcast media.) The model will generally not capture the reality that some other nodes can also actually see or influence traffic and I think that will lead to vulnerabilities not being recognised. I don't have a good suggestion for how to fix that problem but I do think you ought mention it as a security consideration, e.g. something > like: "For models such as these - the real world network may allow additional communications or links that are not represented in the model and such links may enable vulnerabilities that are liable to be missed when considering only the model. These models don't really capture the security or privacy aspects of the network." > > - 4.2 and generally: It is not clear to me how to represent broadcast media (e.g. radio) nor how IP multicast would be reflected in this model. I assume those can be done but as a bit of a hack. > > - nit: 6 authors and 4 contributors. I wish people (esp chairs) would just enforce the 5 author guideline and say why that's inappropriate in the few instances in which that is the case. > > > > . > From nobody Thu Jan 5 05:57:46 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 3844D1294B2; Thu, 5 Jan 2017 05:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 IYow20qqpcbx; Thu, 5 Jan 2017 05:57:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFA4129515; Thu, 5 Jan 2017 05:57:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00A1CBE55; Thu, 5 Jan 2017 13:57:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKktE3LtI4Vi; Thu, 5 Jan 2017 13:57:37 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D673BE50; Thu, 5 Jan 2017 13:57:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483624657; bh=tAv8naijYjRyL4UdjEKGD1toz0tNO77miMP4sO/iZa0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=C7B4IUVxoDnXT/SLlPSpzmDYLMqTj1ENtbupQoTqzg7iX6fIKjRI06084wByKcb3T ukRt+c0NE/Y+04eGpvGm/cbF4cte00z0hSRtyEGtnHoMnbkhL7JbterWVjH4SFzU6j NU4vzug9u05pbvKb1nR2l0RUfMFizFiA6cm0aB7o= To: Benoit Claise , Susan Hares , 'The IESG' References: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> <015401d26754$4e55df10$eb019d30$@ndzh.com> <40a6e896-c611-ba4d-2f38-cb71b210ef7d@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2abb12d5-6012-f46f-0516-9ec8e49ac47c@cs.tcd.ie> Date: Thu, 5 Jan 2017 13:57:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <40a6e896-c611-ba4d-2f38-cb71b210ef7d@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030803080505080806090008" Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 13:57:45 -0000 This is a cryptographically signed message in MIME format. --------------ms030803080505080806090008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/01/17 13:55, Benoit Claise wrote: > Dear all, >> Stephen: >> >> Thank you for letting the authors know about your security concerns.=20 >> I think we have some discussion that needs to take place with the >> authors, Alia, and Benoit on whether the yang security guidelines are >> sufficient or if these need to be expanded based on the I2RS protocol >> security requirements. > This document contains a YANG model, a generic YANG model that could be= > accessed by NETCONF, RESTCONF, or the future I2RS protocol. > This document doesn't say (and that would be a mistake IMO if it would)= > that this YANG model can only be accessed by the I2RS protocol. > Hence I'm advocating that the security considerations diligently follow= > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that > they don't go in the I2RS protocol specific details. Just to note that my comment is about the generic model and nothing to do with i2rs nor any other protocol specific stuff. I'll leave Sue and Benoit to discuss i2rs:-) Cheers, S. >=20 > Regards, Benoit >> >> I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and= >> security issues. It will help us make sure the next I2RS documents >> submitted to the IESG have the appropriate security considerations and= >> threat analysis. >> >> On the 6 authors, we really did investigate each authors active >> contribution. >> >> Sue Hares >> Document shepherd. >> >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, January 5, 2017 7:52 AM >> To: The IESG >> Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; >> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >> Subject: Stephen Farrell's No Objection on >> draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-i2rs-yang-network-topo-10: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ >> >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> I agree with Kathleen's discuss points and have one more aspect to >> offer that I hope you include in that >> discussion: >> >> This model I think will lead designers to only think about the nodes >> that are supposed to have access to traffic. (See also below about >> broadcast media.) The model will generally not capture the reality >> that some other nodes can also actually see or influence traffic and I= >> think that will lead to vulnerabilities not being recognised. I don't >> have a good suggestion for how to fix that problem but I do think you >> ought mention it as a security consideration, e.g. something >> like: "For models such as these - the real world network may allow >> additional communications or links that are not represented in the >> model and such links may enable vulnerabilities that are liable to be >> missed when considering only the model. These models don't really >> capture the security or privacy aspects of the network." >> >> - 4.2 and generally: It is not clear to me how to represent broadcast >> media (e.g. radio) nor how IP multicast would be reflected in this >> model. I assume those can be done but as a bit of a hack. >> >> - nit: 6 authors and 4 contributors. I wish people (esp chairs) would >> just enforce the 5 author guideline and say why that's inappropriate >> in the few instances in which that is the case. >> >> >> >> . >> >=20 --------------ms030803080505080806090008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDUx MzU3MzZaMC8GCSqGSIb3DQEJBDEiBCAdDiYnGKcloJ0IAPLXKypA9yO+NfioE7w/BFK+UWr6 JDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBAjUDeIjyt721OCKGzyVOD5xPGRpY5R4hJySpcXFF2B9gx+mtU7YPc p8SaDEfiC1aU08y85MQfDVie/tULPbFRpuNpDmgCgdvTPWkwH9wr6tjRhNWgBbLloFOanpNp mGm9mGYP8MfkoVg0vCwI3CUkqNpoRvLr6efyb7p2JlfZqWMH0oPmIVKr071YsJrFutY+LMaA 13NGjN8wnAqGPZy3bNVKQGkbBmFsup+DpmRCHp310dJ1yyhDSvWkksmvfEMldlPjr/r3wLbr TMNLaLQHWXoYAvGaSxBnz4j/5kY8MSSoULtuyMTPFHZ4XJ+x/07Bz28X/ch4xucNY3CCsFsK AAAAAAAA --------------ms030803080505080806090008-- From nobody Thu Jan 5 06:13: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 38320129407; Thu, 5 Jan 2017 06:13:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362559622.20689.501194559570535441.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 06:13:16 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:13:16 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Kathleen's comments and always find it helpful when the security considerations templates are used in YANG documents as Juergen and Benoit suggested. = Section 3 = HTTP and ReST are defined, but they aren't used anywhere else in the document in a way that requires definition. = Section 6.1 = "leaf server-provided { type boolean; config false; description "Indicates whether the information concerning this particular network is populated by the server (server-provided true, the general case for network information discovered from the server), or whether it is configured by a client (server-provided true, possible e.g. for service overlays managed through a controller)." I think the second instance of "server-provided true" is actually supposed to say "server-provided false," right? From nobody Thu Jan 5 06:16: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 E9D0612954C; Thu, 5 Jan 2017 06:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 U378dhPWlONa; Thu, 5 Jan 2017 06:16:52 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 BD99212954B; Thu, 5 Jan 2017 06:16:52 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id s140so20926047qke.0; Thu, 05 Jan 2017 06:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h0RC/Y5DbCovaV0rElORiHa/LlpDY5YKIGvfBeHf/Ag=; b=vOOaWntxNgdy3h2tFOJvRd+hoyHHPZ5y8ML4UqeJVIQ1I/4VFdEd48daOiu5uvU912 GDusOShQo/pjFdvJNfyhqDbrzwyRYf0I7h/mOaW+MoYIMDNS/ZV6AVFDKNPaN9xFidu/ p0DSA8Vz+2foJ/F1J0SfDQXj9ogZ3iwmQ/I3ooacu+bBE0P3h/TYCW2z1Y6K/qJZZ33P zDU32jN9nqfZEHKvfHMC8+NPbzqqW9pwWGXyNoAZvfMi2K+JNNR3kero94e4HrMV8ltQ 7meTppgtstwHVgObNgiQq1+OUAgKcSvmIXwqjrQtQec+WYTNvyKpvEYqpexw8/cfhJxf qJ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0RC/Y5DbCovaV0rElORiHa/LlpDY5YKIGvfBeHf/Ag=; b=LhSqMafMAsyR+WZ3JOZxVmgosX5s/YuejK1Ym0CPgJrtU6CAsCvVJQnaEpCJp03yqT ooXcdAUdIwH9Qs3DsnJFQLv+XPi0wtjc1n5sSuOaSO8iYpvln5GLzf19NqHf20xNdvA4 sJqaBfe+H9qcoJEj/eXJ7xJgdvRewDAoQ2AnjNl58P5+xbBKdjnII49TIRu4bM9KpsAn dN721YAr5+qitdAYSSkM8f+KRVGLt+Oj16p3WEGbGDhfiNE6YQeAl3blERmN7ByM6css uVGd+j9jawnVGdZ5Ub6f+ExqRwraZrnJYoJPHZxTMB+vQiF7KN2m6r+xh8n2Ch6kVmUW F3SQ== X-Gm-Message-State: AIkVDXJmtJWkV6YadhAEbUkY/FGibboyIELi2pjeVyXuIQnXldtP5bE0Diiemmm9yQkxdQlIxVDC1EUtoWWLSA== X-Received: by 10.55.132.67 with SMTP id g64mr50236552qkd.153.1483625811899; Thu, 05 Jan 2017 06:16:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Thu, 5 Jan 2017 06:16:51 -0800 (PST) In-Reply-To: References: <148356562531.12930.6796156004394268048.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 5 Jan 2017 09:16:51 -0500 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=94eb2c07481c7f7ae10545598d5c Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, The IESG , Susan Hares , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 14:16:55 -0000 --94eb2c07481c7f7ae10545598d5c Content-Type: text/plain; charset=UTF-8 Hi Benoit, On Thu, Jan 5, 2017 at 6:45 AM, Benoit Claise wrote: > On 1/4/2017 10:33 PM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. > > I have a couple of things I'd like to discuss that may require some > additional text, but should be easy to resolve. > > 1. Privacy considerations - I don't see any listed and the YANG module > include a few identifiers as well as ways to group devices. I think > privacy considerations need to be added for use of this module. > > 2. Security - the network topology and inventory created by this module > reveals information about systems and services. This could be very > helpful information to an attacker and should also be called out as a > security consideration. The access and transport of this information is > covered though in the considerations, just listing this threat would be > helpful. > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines template > should be applied (I mentioned that in a previous review). > The first paragraph of the Security Considerations is right, but the rest > of the section doesn't quite follow the template (which is something that > the RFC editor will check). > For example, the following should be copied verbatim: > > There are a number of data nodes defined in this YANG module that are > writable/creatable/deletable (i.e., config true, which is the default). > These data nodes may be considered sensitive or vulnerable in some network > environments. Write operations (e.g., edit-config) to these data nodes > without proper protection can have a negative effect on network operations. > These are the subtrees and data nodes and their sensitivity/vulnerability: > > And should > be populated, based on the second paragraph of the current Security > Considerations. > > Regarding your point "the network topology and inventory created by this > module reveals information about systems and services. This could be very > helpful information to an attacker and should also be called out as a > security consideration.", I believe that this is covered by the previous > paragraph. as most nodes are config-true. > Sure, the template does help since stating they are sensitive is similar enough to stating revealing information is possible. We wouldn't care if it wasn't sensitive or could help an attacker. > > Regarding the "listing this threat would be helpful.", I'm not convinced > that this is necessary to change the security guidelines YANG template. > Yes, please do use the template. I think because aSue asked about a specific template to I2RS, I was thrown a bit. The YANG template would be appropriate and they should also include links to any I2RS documents that contain relevant security considerations. Thank you, Kathleen > As a comparison on how we've been documenting security considerations for > MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security > > Regards, Benoit > > > Thank you. > > > > > . > > > > -- Best regards, Kathleen --94eb2c07481c7f7ae10545598d5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

On Thu, Jan 5, 2017 at 6:45 AM, Benoit Claise &= lt;bclaise@cisco.com= > wrote:
=20 =20 =20
On 1/4/2017 10:33 P= M, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<=
/a>
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-to=
po/



-----------------------------------------------------------------=
-----
DISCUSS:
-----------------------------------------------------------------=
-----

Thanks for your work on this draft.

I have a couple of things I'd like to discuss that may require some
additional text, but should be easy to resolve.

1. Privacy considerations - I don't see any listed and the YANG module
include a few identifiers as well as ways to group devices.  I think
privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module
reveals information about systems and services.  This could be very
helpful information to an attacker and should also be called out as a
security consideration. The access and transport of this information is
covered though in the considerations, just listing this threat would be
helpful.
https://trac.ietf.org/trac/ops/wiki/yang-security-gui= delines template should be applied (I mentioned that in a previous review).
The first paragraph of the Security Considerations is right, but the rest of the section doesn't quite follow the template (which is something that the RFC editor will check).
For example, the following should be copied verbatim:
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
And <list subtrees and data nodes and state why they are sensitive> should be populated, based on the second paragraph of the current Security Considerations.
Regarding your point "the network topology and inventory created b= y this module reveals information about systems and services. This could be very helpful information to an attacker and should also be called out as a security consideration.", I believe that this is covered by the previous paragraph. as most nodes are config-true.
<= /div>

Sure, the template does help since st= ating they are sensitive is similar enough to stating revealing information= is possible.=C2=A0 We wouldn't care if it wasn't sensitive or coul= d help an attacker.
=C2=A0

Regarding the "listing this threat would be helpful.", I'= m not convinced that this is necessary to change the security guidelines YANG template.

Yes, please do= use the template.=C2=A0 I think because aSue asked about a specific templa= te to I2RS, I was thrown a bit.=C2=A0 The YANG template would be appropriat= e and they should also include links to any I2RS documents that contain rel= evant security considerations.

Thank you,
Kathleen
=C2=A0
As a comparison on how we've been documenting security considerations for MIB modules, see https://trac.i= etf.org/trac/ops/wiki/mib-security

Regards, Benoit


Thank you.




.




--
Best regards,
Kathleen
--94eb2c07481c7f7ae10545598d5c-- From nobody Thu Jan 5 06:28:13 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 2B32C12956C; Thu, 5 Jan 2017 06:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayG0xy8C5HJW; Thu, 5 Jan 2017 06:28:11 -0800 (PST) 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 1587C129568; Thu, 5 Jan 2017 06:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1948; q=dns/txt; s=iport; t=1483626490; x=1484836090; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=n5cMVaXJI9JdlgKzf9cuYh9Bm890MeOX5buOtzzzRfE=; b=f/wprvgeWTawlM4Kk3AVN2sYzAQ4HxascYAc8sZHkk15XMtxwDJfmID5 veuL8dycojoFhkSaVUuODn27tkOuqrvpmlfmP+PmL3+LcKUCnq9zhAGiG 0B6FCl0i3NcBnnXF3OKNM6FMHwS0iHZqy685uZBHGaco4NRe6DWYd6NnY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQAXV25Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAX6BDINPighyk1aTGIIPggkqhXgCggUUAQIBAQEBAQE?= =?us-ascii?q?BYyiEaQEFIxVBEAsYAgImAgJXBgEMCAEBiGwOr0eCJYokAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEZBYELhTqCAoJfhBgRAQYWgwiCXgEEiHGSH4ZWim2BdoUIgyeGNYp?= =?us-ascii?q?Ph3cfOG0iEgcTFYUPgUg9NQGGN4IuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="648525544" 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; 05 Jan 2017 14:28:06 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v05ES5Tx014527; Thu, 5 Jan 2017 14:28:05 GMT To: Alissa Cooper , The IESG References: <148362559622.20689.501194559570535441.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <7d6cc60c-b10a-339c-c495-bbfdb80a1b5b@cisco.com> Date: Thu, 5 Jan 2017 15:28:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148362559622.20689.501194559570535441.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 14:28:12 -0000 On 1/5/2017 3:13 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Kathleen's comments and always find it helpful when the > security considerations templates are used in YANG documents as Juergen > and Benoit suggested. > > = Section 3 = > > HTTP and ReST are defined, but they aren't used anywhere else in the > document in a way that requires definition. > > = Section 6.1 = > > "leaf server-provided { > type boolean; > config false; > description > "Indicates whether the information concerning this > particular network is populated by the server > (server-provided true, the general case for network > information discovered from the server), > or whether it is configured by a client > (server-provided true, possible e.g. for > service overlays managed through a controller)." > > I think the second instance of "server-provided true" is actually > supposed to say "server-provided false," right? Good catch. Updating a YANG module once published is a little bit of a pain. Regards, Benoit > > > . > From nobody Thu Jan 5 06:34:38 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 519F2129561; Thu, 5 Jan 2017 06:34:33 -0800 (PST) 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 EaJr-m_cQFLh; Thu, 5 Jan 2017 06:34:32 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EDD129451; Thu, 5 Jan 2017 06:34:31 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.105.81.61; From: "Susan Hares" To: "'Benoit Claise'" , "'Alissa Cooper'" , "'The IESG'" References: <148362559622.20689.501194559570535441.idtracker@ietfa.amsl.com> <7d6cc60c-b10a-339c-c495-bbfdb80a1b5b@cisco.com> In-Reply-To: <7d6cc60c-b10a-339c-c495-bbfdb80a1b5b@cisco.com> Date: Thu, 5 Jan 2017 09:30:40 -0500 Message-ID: <01b901d26760$4a9e37d0$dfdaa770$@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: AQJIZKUyPMfl1exTfIzBpjj3SSzXlwFtBqH3oDKO94A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 14:34:33 -0000 +1 to Benoit's comments. Good catch - thank you Alissa! Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, January 5, 2017 9:28 AM To: Alissa Cooper; The IESG Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) On 1/5/2017 3:13 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-i2rs-yang-network-topo-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Kathleen's comments and always find it helpful when the > security considerations templates are used in YANG documents as > Juergen and Benoit suggested. > > = Section 3 = > > HTTP and ReST are defined, but they aren't used anywhere else in the > document in a way that requires definition. > > = Section 6.1 = > > "leaf server-provided { > type boolean; > config false; > description > "Indicates whether the information concerning this > particular network is populated by the server > (server-provided true, the general case for network > information discovered from the server), > or whether it is configured by a client > (server-provided true, possible e.g. for > service overlays managed through a controller)." > > I think the second instance of "server-provided true" is actually > supposed to say "server-provided false," right? Good catch. Updating a YANG module once published is a little bit of a pain. Regards, Benoit > > > . > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 5 06:53:19 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 DD8E0129B21; Thu, 5 Jan 2017 06:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmliuRgiFuP7; Thu, 5 Jan 2017 06:53:17 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAEF129580; Thu, 5 Jan 2017 06:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1483627945; bh=bIvJNCKNGQ7ngEISzOt+g0TKA2IRFsKg1f2KQFvXVEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bktBOoX2aYVB/xCer3ctXezCWRMn+PMTO+Uro+EwfrIclzPDgmBkE1Ze8/ImfMEQU ijGIBUFdbl5rPxcqYuuAvwu23AN+PmslXHnnFBXhH9FVPwOPNLRmo591UyokyohsQA B3BiD8nVl1KSBfSqMoxg4BOEru4wkHRks9j+XHGw= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <40a6e896-c611-ba4d-2f38-cb71b210ef7d@cisco.com> Date: Thu, 5 Jan 2017 09:52:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148362073957.20592.219649262793410513.idtracker@ietfa.amsl.com> <015401d26754$4e55df10$eb019d30$@ndzh.com> <40a6e896-c611-ba4d-2f38-cb71b210ef7d@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 601, in=4632, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, The IESG , Susan Hares , Stephen Farrell Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 05 Jan 2017 14:53:19 -0000 I agree. The statement you refer to is sufficient.=20 We really need to get away from having to be more specific than that in Yang models. =E2=80=94Tom > On Jan 5, 2017:8:55 AM, at 8:55 AM, Benoit Claise = wrote: >=20 > Dear all, >> Stephen: >>=20 >> Thank you for letting the authors know about your security concerns. = I think we have some discussion that needs to take place with the = authors, Alia, and Benoit on whether the yang security guidelines are = sufficient or if these need to be expanded based on the I2RS protocol = security requirements. > This document contains a YANG model, a generic YANG model that could = be accessed by NETCONF, RESTCONF, or the future I2RS protocol. > This document doesn't say (and that would be a mistake IMO if it = would) that this YANG model can only be accessed by the I2RS protocol. > Hence I'm advocating that the security considerations diligently = follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and = that they don't go in the I2RS protocol specific details. >=20 > Regards, Benoit >>=20 >> I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy = and security issues. It will help us make sure the next I2RS documents = submitted to the IESG have the appropriate security considerations and = threat analysis. >>=20 >> On the 6 authors, we really did investigate each authors active = contribution. >>=20 >> Sue Hares >> Document shepherd. >>=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, January 5, 2017 7:52 AM >> To: The IESG >> Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >> Subject: Stephen Farrell's No Objection on = draft-ietf-i2rs-yang-network-topo-10: (with COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for >> draft-ietf-i2rs-yang-network-topo-10: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> I agree with Kathleen's discuss points and have one more aspect to = offer that I hope you include in that >> discussion: >>=20 >> This model I think will lead designers to only think about the nodes = that are supposed to have access to traffic. (See also below about = broadcast media.) The model will generally not capture the reality that = some other nodes can also actually see or influence traffic and I think = that will lead to vulnerabilities not being recognised. I don't have a = good suggestion for how to fix that problem but I do think you ought = mention it as a security consideration, e.g. something >> like: "For models such as these - the real world network may allow = additional communications or links that are not represented in the model = and such links may enable vulnerabilities that are liable to be missed = when considering only the model. These models don't really capture the = security or privacy aspects of the network." >>=20 >> - 4.2 and generally: It is not clear to me how to represent broadcast = media (e.g. radio) nor how IP multicast would be reflected in this = model. I assume those can be done but as a bit of a hack. >>=20 >> - nit: 6 authors and 4 contributors. I wish people (esp chairs) would = just enforce the 5 author guideline and say why that's inappropriate in = the few instances in which that is the case. >>=20 >>=20 >>=20 >> . >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 17 05:27:44 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 49AA2128E18; Tue, 17 Jan 2017 05:27:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148465965929.32034.6450951751070798581.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 05:27:39 -0800 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-yang-l3-topology-08=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 13:27:39 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two high level comments (please note that I’m not a yang expert and if this model is considered right by the vendor community that want to use it, I’m fine with it): 1) I’m not sure about the usefulness of the flag attribute, given that’s a very general reference to some kind of unspecified information (and it’s also not used in the examples as far as I can see) 2) Why are the is-is and ospf models only given as examples instead of also specifying them completely in this draft. These parts atually seem to me to be the more interesting bits of work… From nobody Wed Jan 18 08:01:39 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 522EA129409; Wed, 18 Jan 2017 08:01:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148475529732.2033.2804033282469672192.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 08:01:37 -0800 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 16:01:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 2 = HTTP and ReST are defined, but they aren't used anywhere else in the document in a way that requires definition. = Section 5 = "case interface-name { leaf interface-name { type string; description "A name of the interface. The name can (but does not have to) correspond to an interface reference of a containing node's interface, i.e. the path name of a corresponding interface data node on the containing node reminiscent of data type if-ref defined in RFC 7223. It should be noted that data type if-ref of RFC 7223 cannot be used directly, as this data type is used to reference an interface in a datastore of a single node in the network, not to uniquely reference interfaces across a network."; } }" In RFC 7223 the data type appears to be called interface-ref, not if-ref. Would an example of this in this document be, say, a MAC address? = Section 6.1.1 and 6.2.1 = While notational explanations are given for "?," "*," etc., none is given for "!". = Section 9 = This section is missing a discussion of the potential sensitivity of the data this module exposes even in a read-only use case. Filling in the template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and adding the text to this section should get that covered. From nobody Wed Jan 18 11:08:51 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 5E67B129543; Wed, 18 Jan 2017 11:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZHTc5U-9FzJ; Wed, 18 Jan 2017 11:08:44 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FE2129551; Wed, 18 Jan 2017 11:08:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 84A116C1; Wed, 18 Jan 2017 20:08:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 958WjPfQXeGz; Wed, 18 Jan 2017 20:08:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Jan 2017 20:08:41 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21745200A3; Wed, 18 Jan 2017 20:08:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pnTEVqf9VOxP; Wed, 18 Jan 2017 20:08:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95C23200A5; Wed, 18 Jan 2017 20:08:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 696923E2984B; Wed, 18 Jan 2017 20:08:44 +0100 (CET) Date: Wed, 18 Jan 2017 20:08:43 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170118190843.GA5811@elstar.local> Mail-Followup-To: Alissa Cooper , The IESG , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com References: <148475529732.2033.2804033282469672192.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148475529732.2033.2804033282469672192.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, The IESG , shares@ndzh.com, i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:08:46 -0000 On Wed, Jan 18, 2017 at 08:01:37AM -0800, Alissa Cooper wrote: > > "case interface-name { > leaf interface-name { > type string; > description > "A name of the interface. The name can (but does not > have to) correspond to an interface reference of a > containing node's interface, i.e. the path name of a > corresponding interface data node on the containing > node reminiscent of data type if-ref defined in > RFC 7223. It should be noted that data type if-ref of > RFC 7223 cannot be used directly, as this data type > is used to reference an interface in a datastore of > a single node in the network, not to uniquely > reference interfaces across a network."; > } > }" > > In RFC 7223 the data type appears to be called interface-ref, not if-ref. > Would an example of this in this document be, say, a MAC address? > Now that I read this, I must say that I do not understand the description at all. What does 'i.e. the path name of a corresponding interface data node on the containing node reminiscent of data type if-ref defined in RFC 7223.' tell me? If the intention here is that it is unique across a network I think this should be stated more clearly, that is, not as a sub-thought in a sentence trying to explain why if-ref can't be used. And then, what is a 'network'? And looking at the whole choice, the other options are not unique either. For unnumbered-id, the description says "will correspond to the ifIndex value of the interface" which very likely will clash for different nodes. Also IP adresses may not always be unique 'across a network'. So why do we have this "unique across a network" requirement for the interface-name case? That is, we can't we use /js PS: Why is interface-name marked 'ro' in the tree diagram? It looks like a config true node. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 18 18:43:43 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 E460F1293F0; Wed, 18 Jan 2017 18:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 18:43:41 -0800 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 02:43:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected. I'm told it will be, thanks. From nobody Wed Jan 18 19:16:14 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 0E068127071; Wed, 18 Jan 2017 19:16:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148479577204.2020.2794444297680490505.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 19:16:12 -0800 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:16:12 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples. What is the actual intent? Is this draft supposed to be the canonical definition of ospf-topology and isis-topology? Please clarify. * Section 4 Is there a reason that router-id is defined as capable of having multiple instances? From nobody Thu Jan 19 03:23:54 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 E6D5112943A; Thu, 19 Jan 2017 03:23:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 03:23:48 -0800 Archived-At: Cc: i2rs@ietf.org, mbj@tail-f.com, draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, camoberg@cisco.com, shares@ndzh.com Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 11:23:49 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. The examples. In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago. Look at this: module example-ietf-ospf-topology { ... namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; ... description "This module defines a model for OSPF network topologies. Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. They are using the IANA-controlled namespace w/o registering it. This module *really* looks like a proper normative module, rather than an example. They went to far in trying to mimic a real module. It is clear that we need more guidelines in 6087 for how to write example modules. I was going to ask if this module passed YANG doctor review - then I checked and saw that version -02 was reviewed, which didn't include this example. How should we (the YANG doctors) handle such a case? In this case they should: 1. change the name to example-ospf-topology 2. change the namespace to urn:example:ospf-topology 3. remove the top-level statements: organization, contact, revision 4. change the top-level description to what the text in the draft says: description "This module is intended as an example for how the Layer 3 Unicast topology model can be extended to cover OSFP topologies."; (same for the other example module) As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html This will hopefully resolve fast. Once settled, the examples should be updated. 2. The security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as mentioned by others. 3. Carl Moberg, as YANG doctor, reviewed v1 of the draft. https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html I'm waiting for final blessing on v8 any time soon. Hence this late DISCUSS. 4. leaf-list router-id { type inet:ip-address; description "Router-id for the node"; } We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why this is aligned with its definition? typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; } ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - Instead of: Brackets enclose list keys, "rw" means configuration, "ro" operational state data, "?" designates optional nodes, "*" designates nodes that can have multiple instances. Parantheses enclose choice and case nodes. Use the cut/paste from RFC8022 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), "ro" state data (read-only), "-x" RPC operations or actions, and "-n" notifications. o Symbols after data node names: "?" means an optional node, "!" a container with presence, and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. Btw, no need to repeat this convention in section 6.1.1 and 6.2.1 - I agree with Suresh: "OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples" Either modify figure 1, or even better, stress in section 3 that ospf-topology and isis-topology are examples, and defined as such in this document - section 7 OLD: The moodel defines NEW: The model defines From nobody Thu Jan 19 05:21:59 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 68A27129467; Thu, 19 Jan 2017 05:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAx2mX9aRdOI; Thu, 19 Jan 2017 05:21:55 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0097B1294E1; Thu, 19 Jan 2017 05:21:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CBD57785; Thu, 19 Jan 2017 14:21:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JcbVyr6Ogc86; Thu, 19 Jan 2017 14:21:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 19 Jan 2017 14:21:52 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 804B2200A5; Thu, 19 Jan 2017 14:21:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 91d8vUVZRAre; Thu, 19 Jan 2017 14:21:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8E97200A3; Thu, 19 Jan 2017 14:21:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BFD9B3E2B012; Thu, 19 Jan 2017 14:21:55 +0100 (CET) Date: Thu, 19 Jan 2017 14:21:55 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20170119132155.GB7666@elstar.local> Mail-Followup-To: Benoit Claise , The IESG , i2rs@ietf.org, mbj@tail-f.com, draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, camoberg@cisco.com, shares@ndzh.com References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, mbj@tail-f.com, draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, The IESG , camoberg@cisco.com, shares@ndzh.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:21:58 -0000 On Thu, Jan 19, 2017 at 03:23:48AM -0800, Benoit Claise wrote: > 4. > > leaf-list router-id { > type inet:ip-address; > description > "Router-id for the node"; > } > > We don't want to wait for > https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we > should expedite this publication), but any good reason why > this is aligned with its definition? > typedef router-id { > type yang:dotted-quad; > description > "A 32-bit number in the dotted quad format assigned to each > router. This number uniquely identifies the router within an > Autonomous System."; > } For the sake of completeness, RFC 8022 has: leaf router-id { type yang:dotted-quad; description "A 32-bit number in the form of a dotted quad that is used by some routing protocols identifying a router."; reference "RFC 2328: OSPF Version 2."; } Using yang:dotted-quad seems appropriate here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 19 06:28:00 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 85C12129602; Thu, 19 Jan 2017 06:27:55 -0800 (PST) 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 r576YwcxkHzZ; Thu, 19 Jan 2017 06:27:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B011270B4; Thu, 19 Jan 2017 06:27:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> In-Reply-To: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 09:23:26 -0500 Message-ID: <026d01d2725f$9c1dbd60$d4593820$@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: AQHdENFUFYAkrytHh+wzPqnQK0P7bqEqmzZg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mbj@tail-f.com, draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, camoberg@cisco.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 14:27:55 -0000 Benoit: I would agree that you need a discuss regarding the security considerations in the draft. However, I disagree that the security considerations should align with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as mentioned by others. I believe that the security considerations should have additional fields. I have written the draft-hares-i2rs-yang-sec-consider-00.txt in order to start a conversation regarding this point. I would appreciate you holding the DISCUSS until we reach agreement on this point. You can reference the draft at: https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, January 19, 2017 6:24 AM To: The IESG Cc: i2rs@ietf.org; mbj@tail-f.com; draft-ietf-i2rs-yang-l3-topology@ietf.org; rbonica@juniper.net; i2rs-chairs@ietf.org; camoberg@cisco.com; shares@ndzh.com Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. The examples. In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago. Look at this: module example-ietf-ospf-topology { ... namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; ... description "This module defines a model for OSPF network topologies. Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. They are using the IANA-controlled namespace w/o registering it. This module *really* looks like a proper normative module, rather than an example. They went to far in trying to mimic a real module. It is clear that we need more guidelines in 6087 for how to write example modules. I was going to ask if this module passed YANG doctor review - then I checked and saw that version -02 was reviewed, which didn't include this example. How should we (the YANG doctors) handle such a case? In this case they should: 1. change the name to example-ospf-topology 2. change the namespace to urn:example:ospf-topology 3. remove the top-level statements: organization, contact, revision 4. change the top-level description to what the text in the draft says: description "This module is intended as an example for how the Layer 3 Unicast topology model can be extended to cover OSFP topologies."; (same for the other example module) As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html This will hopefully resolve fast. Once settled, the examples should be updated. 2. The security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as mentioned by others. 3. Carl Moberg, as YANG doctor, reviewed v1 of the draft. https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html I'm waiting for final blessing on v8 any time soon. Hence this late DISCUSS. 4. leaf-list router-id { type inet:ip-address; description "Router-id for the node"; } We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why this is aligned with its definition? typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; } ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - Instead of: Brackets enclose list keys, "rw" means configuration, "ro" operational state data, "?" designates optional nodes, "*" designates nodes that can have multiple instances. Parantheses enclose choice and case nodes. Use the cut/paste from RFC8022 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), "ro" state data (read-only), "-x" RPC operations or actions, and "-n" notifications. o Symbols after data node names: "?" means an optional node, "!" a container with presence, and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. Btw, no need to repeat this convention in section 6.1.1 and 6.2.1 - I agree with Suresh: "OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples" Either modify figure 1, or even better, stress in section 3 that ospf-topology and isis-topology are examples, and defined as such in this document - section 7 OLD: The moodel defines NEW: The model defines _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 19 06:32: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 B2A3312952C; Thu, 19 Jan 2017 06:32:24 -0800 (PST) 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 pGhg8KzY8sZn; Thu, 19 Jan 2017 06:32:23 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E271295D0; Thu, 19 Jan 2017 06:32:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'The IESG'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> In-Reply-To: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 09:28:14 -0500 Message-ID: <026f01d27260$45554a10$cfffde30$@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: AQH+ufYYBtIA0WoGRREYM1y0KVh6/qDnS4og Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 14:32:25 -0000 Kathleen:=20 I have written a draft suggesting a template for the I2RS YANG modules = which are designed to exist in the I2RS Ephemeral Control Plane data = store (configuration and operational state). =20 Draft location:=20 https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ I would appreciate an email discussion with the security ADs, OPS/NM = ADs, and Routing AD (Alia Atlas). I agree that this I2RS YANG data = model (L3) and the base I2RS topology model should both provide updated = YANG Security Considerations sections. I would appreciate if Benoit or = you hold a discuss until we sort out these issues.=20 Thank you,=20 Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]=20 Sent: Wednesday, January 18, 2017 9:44 PM To: The IESG Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comment that the YANG module security = consideration section guidelines need to be followed and this shouldn't = go forward until that is corrected. I'm told it will be, thanks. From nobody Thu Jan 19 07:13:01 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 2EDB512961B; Thu, 19 Jan 2017 07:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLBU2Bt7EJYe; Thu, 19 Jan 2017 07:12:53 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 8C6A1129614; Thu, 19 Jan 2017 07:12:53 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id w194so22269925ybe.0; Thu, 19 Jan 2017 07:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qxn4iBdsp9bQHT4on6QBoE+fkIQdzfJA+TX3dwmVmMA=; b=j62DdB+lKEeDdzg1Go+swjhVEstoJPTcAq/FqJhVPtvDyM4fiJRlQ6BiuXLPqBR1UM nfc/WeiCphJ41nt1PkubzGBWWLgnEOZKoBUKw9cJgie0UzhwdMXZUdYoDIU18WtdVA4o I3WFa6lBysZAJSUXIlfYlyxiacs79KBVrwpMYdqNvsB0XRoJo6KvHaZ/LseUg34ZcvyL VsgoeGpewUpFguW8hkcvNbmeEPlUQpsgT5O3IEBDrIAtzfb2vo3vSVgcTVzTjqfBLxS7 dSmnxsBwvWhowWjlrXB4QwFxV1v/biZcbq7tmnLRDY8JheYyJykUZ2pFKUrQLOyDL5XI Fdjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qxn4iBdsp9bQHT4on6QBoE+fkIQdzfJA+TX3dwmVmMA=; b=aZFvXgVPgHa0WqwEG8QL77gxRxJG3MGbnzCmBkZ3pfpiJ2QUD/5v68SMtZoO8N1rrD u4j/xtFk2s77dR7bcpe4mFZMhndQMiJmKPX25d0GtXD/IiO4CkQB4326TKGS1qDsYuhV yO0KK3QilJCvyQ1eWLYLGPIpE0QnOLqRKKjmRaBDFVHJdnLhs4IexsPsxhzvjHuH/N/e wNTbnr7ppnV0wgzgh1LLJzFa7XIPYNgAhq7V4nSJzUNoUntyKOB1B17Jq2UzUV7OmUAN LyIvmQEuMjeBMn7Z42NBXP8Id40HXtIWGFzMK4QaMU/7TyjSTumaqd68yXKl5IdDOPzm IZPQ== X-Gm-Message-State: AIkVDXJ06QxZVvDwUbzuFQfZpd2FR2uIvogkOR54awASu03W/dv06bewGAJI6gAXNMQVmWvtihfyhG+jaF68bA== X-Received: by 10.55.162.65 with SMTP id l62mr8193706qke.17.1484838772770; Thu, 19 Jan 2017 07:12:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Thu, 19 Jan 2017 07:12:52 -0800 (PST) In-Reply-To: <026f01d27260$45554a10$cfffde30$@ndzh.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> From: Kathleen Moriarty Date: Thu, 19 Jan 2017 10:12:52 -0500 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114d83ce998f50054673f7c0 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 15:12:59 -0000 --001a114d83ce998f50054673f7c0 Content-Type: text/plain; charset=UTF-8 Thank you, Susan. It looks like Benoit has included this in a discuss comment. We can discuss and make sure we reach a good result. Best regards, Kathleen On Thu, Jan 19, 2017 at 9:28 AM, Susan Hares wrote: > Kathleen: > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data store > (configuration and operational state). > > Draft location: > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Security > Considerations sections. I would appreciate if Benoit or you hold a discuss > until we sort out these issues. > > Thank you, > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 18, 2017 9:44 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: > (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa's comment that the YANG module security consideration > section guidelines need to be followed and this shouldn't go forward until > that is corrected. I'm told it will be, thanks. > > > > -- Best regards, Kathleen --001a114d83ce998f50054673f7c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Susan.

It looks like Benoit = has included this in a discuss comment.=C2=A0 We can discuss and make sure = we reach a good result.

Best regards,
Ka= thleen

On Thu, Jan 19, 2017 at 9:28 AM, Susan Hares <shares@ndzh.com> wrote:
Kathleen:

I have written a draft suggesting a template for the I2RS YANG modules whic= h are designed to exist in the I2RS Ephemeral Control Plane data store (con= figuration and operational state).

Draft location:
https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/

I would appreciate an email discussion with the security ADs, OPS/NM ADs, a= nd Routing AD (Alia Atlas).=C2=A0 I agree that this I2RS YANG data model (L= 3) and the base I2RS topology model should both provide updated YANG Securi= ty Considerations sections. I would appreciate if Benoit or you hold a disc= uss until we sort out these issues.

Thank you,

Sue

-----Original Message-----
From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
Sent: Wednesday, January 18, 2017 9:44 PM
To: The IESG
Cc: draft-ietf= -i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; i2rs-chairs@= ietf.org; shares@ndzh.com; i2rs@ietf.org
Subject: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-l3-topology-08: No Objection

When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/= doc/draft-ietf-i2rs-yang-l3-topology/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I agree with Alissa's comment that the YANG module security considerati= on section guidelines need to be followed and this shouldn't go forward= until that is corrected.=C2=A0 I'm told it will be, thanks.






--
=

Best regards,
Kathleen
--001a114d83ce998f50054673f7c0-- From nobody Thu Jan 19 07:34:12 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 DEF4812961B; Thu, 19 Jan 2017 07:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG_8TC9YySQS; Thu, 19 Jan 2017 07:34:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2D912896F; Thu, 19 Jan 2017 07:34:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 219ED71A; Thu, 19 Jan 2017 16:34:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ywiqOOk1BeHK; Thu, 19 Jan 2017 16:33:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 19 Jan 2017 16:34:00 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84284200A3; Thu, 19 Jan 2017 16:34:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QfvUo0Neo2uD; Thu, 19 Jan 2017 16:34:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3ECA200A5; Thu, 19 Jan 2017 16:33:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C68303E2B467; Thu, 19 Jan 2017 16:34:02 +0100 (CET) Date: Thu, 19 Jan 2017 16:34:02 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170119153400.GA8004@elstar.local> Mail-Followup-To: Susan Hares , 'Kathleen Moriarty' , 'The IESG' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <026f01d27260$45554a10$cfffde30$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:34:07 -0000 For what it is worth, I find the notion that data models may be written for a specific non-secure transport plain broken. There is hardly any content of a data model I can think of which is generally suitable for insecure transports. Can we please kill this idea of _standardizing_ information that is suitable to send over non-secure transports? I really do not see how the IETF can make a claim that a given piece of information is never worth protecting (= suitable for non-secure transports). Note that I am fine if in a certain trusted tightly-coupled deployment information is shipped in whatever way but this is then a property of the _deployment_ and not a property of the _information_. /js On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > Kathleen: > > I have written a draft suggesting a template for the I2RS YANG modules which are designed to exist in the I2RS Ephemeral Control Plane data store (configuration and operational state). > > Draft location: > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) and the base I2RS topology model should both provide updated YANG Security Considerations sections. I would appreciate if Benoit or you hold a discuss until we sort out these issues. > > Thank you, > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 18, 2017 9:44 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected. I'm told it will be, thanks. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 19 08:46:42 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 95C431293DB; Thu, 19 Jan 2017 08:46:36 -0800 (PST) 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 V-QoroR5V_M7; Thu, 19 Jan 2017 08:46:35 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FAC127076; Thu, 19 Jan 2017 08:46:32 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Mirja Kuehlewind'" , "'The IESG'" References: <148465965929.32034.6450951751070798581.idtracker@ietfa.amsl.com> In-Reply-To: <148465965929.32034.6450951751070798581.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 11:42:21 -0500 Message-ID: <02f801d27273$01ac72d0$05055870$@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: AQKLe5o136IBPpOFmPgnNUnhS9CXMZ/N7q0g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-yang-l3-topology-08=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 16:46:36 -0000 Mirja:=20 Did moving these examples to an appendix work for you?=20 Sue Hares=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewind Sent: Tuesday, January 17, 2017 8:28 AM To: The IESG Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = i2rs-chairs@ietf.org; shares@ndzh.com Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two high level comments (please note that I=E2=80=99m not a yang expert = and if this model is considered right by the vendor community that want = to use it, I=E2=80=99m fine with it): 1) I=E2=80=99m not sure about the usefulness of the flag attribute, = given that=E2=80=99s a very general reference to some kind of = unspecified information (and it=E2=80=99s also not used in the examples = as far as I can see) 2) Why are the is-is and ospf models only given as examples instead of = also specifying them completely in this draft. These parts atually seem = to me to be the more interesting bits of work=E2=80=A6 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 19 08:55: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 5377D12949B for ; Thu, 19 Jan 2017 08:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 P1k63zVRkpFX for ; Thu, 19 Jan 2017 08:55:24 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6123129498 for ; Thu, 19 Jan 2017 08:55:23 -0800 (PST) Received: (qmail 21931 invoked from network); 19 Jan 2017 17:48:41 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Jan 2017 17:48:41 +0100 To: Susan Hares , 'The IESG' References: <148465965929.32034.6450951751070798581.idtracker@ietfa.amsl.com> <02f801d27273$01ac72d0$05055870$@ndzh.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <86e2829d-6801-dfc8-ad08-bcce471eeaa9@kuehlewind.net> Date: Thu, 19 Jan 2017 17:48:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <02f801d27273$01ac72d0$05055870$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-yang-l3-topology-08=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 16:55:25 -0000 It's better. On 19.01.2017 17:42, Susan Hares wrote: > Mirja: > > Did moving these examples to an appendix work for you? > > Sue Hares > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewind > Sent: Tuesday, January 17, 2017 8:28 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com > Subject: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Two high level comments (please note that I’m not a yang expert and if this model is considered right by the vendor community that want to use it, I’m fine with it): > 1) I’m not sure about the usefulness of the flag attribute, given that’s a very general reference to some kind of unspecified information (and it’s also not used in the examples as far as I can see) > 2) Why are the is-is and ospf models only given as examples instead of also specifying them completely in this draft. These parts atually seem to me to be the more interesting bits of work… > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Jan 19 10:19:39 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 8989A12947D; Thu, 19 Jan 2017 10:19:34 -0800 (PST) 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 MvWVjI_5JLnD; Thu, 19 Jan 2017 10:19:33 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6CF1293DB; Thu, 19 Jan 2017 10:19:32 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> In-Reply-To: <20170119153400.GA8004@elstar.local> Date: Thu, 19 Jan 2017 13:15:15 -0500 Message-ID: <036401d2727f$fc114910$f433db30$@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: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnWgy9qPcA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:19:34 -0000 Juergen: I recognize that dislike insecure communication. You made a similar comment during the WG LC and IETF review of draft-ietf-i2rs-protocol-security-requirements. However, the draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG and approved by the IESG for RFC publication and it contains the non-secure communication. The mandate from the I2RS WG for this shepherd/co-chair is clear. As the shepherd for the topology drafts, I try to write-up something that might address Kathleen's Moriarty's concerns about the topology draft's security issues about privacy and the I2RS ephemeral control plane data store. I welcome an open discussion on my ideas (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). The yang doctor's YANG security consideration template (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the privacy related RFCs (RFC6973) note that some information is sensitive. Hopefully, this document extends these guidelines to a new data store. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, January 19, 2017 10:34 AM To: Susan Hares Cc: 'Kathleen Moriarty'; 'The IESG'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) For what it is worth, I find the notion that data models may be written for a specific non-secure transport plain broken. There is hardly any content of a data model I can think of which is generally suitable for insecure transports. Can we please kill this idea of _standardizing_ information that is suitable to send over non-secure transports? I really do not see how the IETF can make a claim that a given piece of information is never worth protecting (= suitable for non-secure transports). Note that I am fine if in a certain trusted tightly-coupled deployment information is shipped in whatever way but this is then a property of the _deployment_ and not a property of the _information_. /js On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > Kathleen: > > I have written a draft suggesting a template for the I2RS YANG modules which are designed to exist in the I2RS Ephemeral Control Plane data store (configuration and operational state). > > Draft location: > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) and the base I2RS topology model should both provide updated YANG Security Considerations sections. I would appreciate if Benoit or you hold a discuss until we sort out these issues. > > Thank you, > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 18, 2017 9:44 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected. I'm told it will be, thanks. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 19 10:30:58 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 3F1631294A0 for ; Thu, 19 Jan 2017 10:30:56 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGi6T442i6Xx for ; Thu, 19 Jan 2017 10:30:54 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 D43491294A9 for ; Thu, 19 Jan 2017 10:30:53 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id l23so30302481ybj.2 for ; Thu, 19 Jan 2017 10:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R4Wv+zz5Q5pua9mFej70MiJ1ZXRYypdGHrrbzDKVP84=; b=JB2ZrSMBS5Q2J9kWytzM97+hWbBiJwPZ/qCV9psZaRroR9qaTnRnc36lT8cDh3jtXz secMUXO6DYg2sdDcafj3FGr90KVbdLvO1+2oqokjceJp91Y59uByZUJ19+vccadcfyPy 4ec/HKOZbS5P1yK19K4Gyatx/3ZJXCKojuFmmglm20tvKgL+R79m5b+3f33lhoPlHEb0 eb+i9ouLr80Nlt8RD0oh7x5gM545JXWDbx9d1NQzFd/6mTatGNxHcqEwvtYcBXNtytJ5 /t9cImPqz2d64LjBFYdJdfrJ5VlL/wWBDchXQKFNoEEbHMncBX3kbxmRObwsHxbw1ish uwNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R4Wv+zz5Q5pua9mFej70MiJ1ZXRYypdGHrrbzDKVP84=; b=QEo/kyKyW+EvyPdHQzdaIGlwJY/dT/BLi0LVB3Kxw2pPyRNF3VvNS3kfKbIO7NUmmY D0SZ398hQdTKFMxZEX+sYUuosbYMZ/ZWvb29CXLOFiKUrG72Bw6gptAV852lL+VFjG8Y g/hf/VZoAD+wAVompgGure2Fr2Jt2BB+1JM/pPSZd4A4pWu6AOztplF7Vb5BP1rMydNP 7fh8kA6uIsAj42q19qnOzjCSprJyqj0FvSsLpagIBtVkY9QP9AKjuenr/ay8y194ypw7 ZvCK4os8RDZX3l0cTvE9qiC+1pGvEmciNVeaNL5ujxxXBjk+OzqBDrjXY2pBBJkQoHZE 0EEg== X-Gm-Message-State: AIkVDXI7Y+sTQpoM0BmKyt9t6a7GWGNBJuqot2dn8O5XMa1HZx3WmlmfVG11pbPjbF0wRt0Dg/6jLVgj3TKQDw== X-Received: by 10.200.57.75 with SMTP id t11mr9171513qtb.274.1484850652919; Thu, 19 Jan 2017 10:30:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 19 Jan 2017 10:30:52 -0800 (PST) In-Reply-To: <036401d2727f$fc114910$f433db30$@ndzh.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> From: Andy Bierman Date: Thu, 19 Jan 2017 10:30:52 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a113ef358b67300054676bbb4 Archived-At: Cc: "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:30:56 -0000 --001a113ef358b67300054676bbb4 Content-Type: text/plain; charset=UTF-8 Hi, I strongly agree with Juergen on this issue. But you can easily design a YANG extension that indicates a data node is OK for insecure transport. I trust that the IESG will evaluate every object of this type and decide whether it is really OK for disclosure in every possible usage scenario. The flip-side of this extension is that any node not properly tagged MUST NOT be sent without the proper security protocols. This rule will likely be ignored, since (as Juergen pointed out) this is a deployment decision, not a modeling decision. Andy On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares wrote: > Juergen: > > I recognize that dislike insecure communication. You made a similar > comment > during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG > and approved by the IESG for RFC publication and it contains the non-secure > communication. The mandate from the I2RS WG for this shepherd/co-chair is > clear. > > As the shepherd for the topology drafts, I try to write-up something that > might address Kathleen's Moriarty's concerns about the topology draft's > security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be written for > a specific non-secure transport plain broken. There is hardly any content > of > a data model I can think of which is generally suitable for insecure > transports. > > Can we please kill this idea of _standardizing_ information that is > suitable > to send over non-secure transports? I really do not see how the IETF can > make a claim that a given piece of information is never worth protecting (= > suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of the > _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data store > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Security > Considerations sections. I would appreciate if Benoit or you hold a discuss > until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alissa's comment that the YANG module security consideration > section guidelines need to be followed and this shouldn't go forward until > that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113ef358b67300054676bbb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I strongly agree with Juergen on th= is issue.
But you can easily design a YANG extension that indicat= es a data node
is OK for insecure transport.

=
I trust that the IESG will evaluate every object of this type and
decide whether it is really OK for disclosure in every possible
=
usage scenario.=C2=A0

The flip-side of this e= xtension is that any node not properly tagged
MUST NOT be sent wi= thout the proper security protocols.
This rule will likely be ign= ored, since (as Juergen pointed out)
this is a deployment decisio= n, not a modeling decision.


Andy


On Th= u, Jan 19, 2017 at 10:15 AM, Susan Hares <shares@ndzh.com> wro= te:
Juergen:

I recognize that dislike insecure communication.=C2=A0 You made a similar c= omment
during the WG LC and IETF review of
draft-ietf-i2rs-protocol-security-requirements.=C2=A0 However, the
draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS= WG
and approved by the IESG for RFC publication and it contains the non-secure=
communication.=C2=A0 The mandate from the I2RS WG for this shepherd/co-chai= r is
clear.

As the shepherd for the topology drafts, I try to write-up something that might address Kathleen's Moriarty's concerns about the topology dra= ft's
security issues about privacy and the I2RS ephemeral control plane data
store.=C2=A0 =C2=A0I welcome an open discussion on my ideas
(https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider).=C2=A0 =C2=A0The
yang doctor's YANG=C2=A0 security consideration template
(https://trac.ietf.org/trac/ops/wik= i/yang-security-guidelines) and the
privacy related RFCs (RFC6973) note that some information is sensitive.
Hopefully, this document extends these guidelines to a new data store.

Cheerily,
Sue Hares

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';
draft-ietf-i2r= s-yang-l3-topology@ietf.org; i2rs= @ietf.org;
i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

For what it is worth, I find the notion that data models may be written for=
a specific non-secure transport plain broken. There is hardly any content o= f
a data model I can think of which is generally suitable for insecure
transports.

Can we please kill this idea of _standardizing_ information that is suitabl= e
to send over non-secure transports? I really do not see how the IETF can make a claim that a given piece of information is never worth protecting (= =3D
suitable for non-secure transports).

Note that I am fine if in a certain trusted tightly-coupled deployment
information is shipped in whatever way but this is then a property of the _deployment_ and not a property of the _information_.

/js

On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote:
> Kathleen:
>
> I have written a draft suggesting a template for the I2RS YANG modules=
which are designed to exist in the I2RS Ephemeral Control Plane data store<= br> (configuration and operational state).
>
> Draft location:
> https://datatracker.ietf.or= g/doc/draft-hares-i2rs-yang-sec-consider/
>
> I would appreciate an email discussion with the security ADs, OPS/NM A= Ds,
and Routing AD (Alia Atlas).=C2=A0 I agree that this I2RS YANG data model (= L3)
and the base I2RS topology model should both provide updated YANG Security<= br> Considerations sections. I would appreciate if Benoit or you hold a discuss=
until we sort out these issues.
>
> Thank you,
>
> Sue
>
> -----Original Message-----
> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
> Sent: Wednesday, January 18, 2017 9:44 PM
> To: The IESG
> Cc: draft= -ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com;
> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
> Subject: Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-i2rs-yang-l3-topology-08: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/= doc/draft-ietf-i2rs-yang-l3-topology/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I agree with Alissa's comment that the YANG module security consid= eration
section guidelines need to be followed and this shouldn't go forward un= til
that is corrected.=C2=A0 I'm told it will be, thanks.
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a113ef358b67300054676bbb4-- From nobody Thu Jan 19 10:51:30 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 ED7121294E4; Thu, 19 Jan 2017 10:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bdPSRZ_KEVD; Thu, 19 Jan 2017 10:51:27 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFC9129481; Thu, 19 Jan 2017 10:51:26 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Andy Bierman'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> In-Reply-To: Date: Thu, 19 Jan 2017 13:47:12 -0500 Message-ID: <038c01d27284$72ff01d0$58fd0570$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038D_01D2725A.8A2BE000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwGvQSB1oKp5kmA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:51:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_038D_01D2725A.8A2BE000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 You are right to comment that =E2=80=93 the =E2=80=9Cflip side of this = extensions is that any node not properly tagged must not be = SENT=E2=80=9D. The purpose of tagging is devices which test protocol = conformation can test these portions of the model. If buyers demand = that these restrictions are followed, then these restrictions will not = be ignored. Like you and Juergen, I really hope that the IESG will very = carefully evaluate any I2RS YANG Model that suggest sending data over = non-secure transport. =20 =20 Sue Hares=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, January 19, 2017 1:31 PM To: Susan Hares Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi, =20 I strongly agree with Juergen on this issue. But you can easily design a YANG extension that indicates a data node is OK for insecure transport. =20 I trust that the IESG will evaluate every object of this type and decide whether it is really OK for disclosure in every possible usage scenario.=20 =20 The flip-side of this extension is that any node not properly tagged MUST NOT be sent without the proper security protocols. This rule will likely be ignored, since (as Juergen pointed out) this is a deployment decision, not a modeling decision. =20 =20 Andy =20 =20 On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares wrote: Juergen: I recognize that dislike insecure communication. You made a similar = comment during the WG LC and IETF review of draft-ietf-i2rs-protocol-security-requirements. However, the draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS = WG and approved by the IESG for RFC publication and it contains the = non-secure communication. The mandate from the I2RS WG for this shepherd/co-chair = is clear. As the shepherd for the topology drafts, I try to write-up something = that might address Kathleen's Moriarty's concerns about the topology draft's security issues about privacy and the I2RS ephemeral control plane data store. I welcome an open discussion on my ideas (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). = The yang doctor's YANG security consideration template (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the privacy related RFCs (RFC6973) note that some information is sensitive. Hopefully, this document extends these guidelines to a new data store. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, January 19, 2017 10:34 AM To: Susan Hares Cc: 'Kathleen Moriarty'; 'The IESG'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) For what it is worth, I find the notion that data models may be written = for a specific non-secure transport plain broken. There is hardly any = content of a data model I can think of which is generally suitable for insecure transports. Can we please kill this idea of _standardizing_ information that is = suitable to send over non-secure transports? I really do not see how the IETF can make a claim that a given piece of information is never worth protecting = (=3D suitable for non-secure transports). Note that I am fine if in a certain trusted tightly-coupled deployment information is shipped in whatever way but this is then a property of = the _deployment_ and not a property of the _information_. /js On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > Kathleen: > > I have written a draft suggesting a template for the I2RS YANG modules which are designed to exist in the I2RS Ephemeral Control Plane data = store (configuration and operational state). > > Draft location: > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > I would appreciate an email discussion with the security ADs, OPS/NM = ADs, and Routing AD (Alia Atlas). I agree that this I2RS YANG data model = (L3) and the base I2RS topology model should both provide updated YANG = Security Considerations sections. I would appreciate if Benoit or you hold a = discuss until we sort out these issues. > > Thank you, > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 18, 2017 9:44 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa's comment that the YANG module security = consideration section guidelines need to be followed and this shouldn't go forward = until that is corrected. I'm told it will be, thanks. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_038D_01D2725A.8A2BE000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

You are right to comment that =E2=80=93 the =E2=80=9Cflip side of = this extensions is that any node not properly tagged must not be = SENT=E2=80=9D.=C2=A0=C2=A0 The purpose of tagging is devices which test = protocol conformation can test these portions of the model.=C2=A0 If = buyers demand that these restrictions are followed, then these = restrictions will not be ignored. =C2=A0Like you and Juergen, I really = hope that the IESG will very carefully evaluate any I2RS YANG Model that = suggest sending data over non-secure transport.=C2=A0 =

 

Sue Hares

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, = January 19, 2017 1:31 PM
To: Susan Hares
Cc: Juergen = Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

Hi,

 

I = strongly agree with Juergen on this issue.

But you can easily design a YANG extension that = indicates a data node

is = OK for insecure transport.

 

I = trust that the IESG will evaluate every object of this type = and

decide whether it is = really OK for disclosure in every possible

usage scenario. 

 

The flip-side of this extension is that any node not = properly tagged

MUST NOT = be sent without the proper security = protocols.

This rule will = likely be ignored, since (as Juergen pointed = out)

this is a deployment = decision, not a modeling decision.

 

 

Andy

 

 

On Thu, = Jan 19, 2017 at 10:15 AM, Susan Hares <shares@ndzh.com> wrote:

Juergen:

I recognize that dislike insecure = communication.  You made a similar comment
during the WG LC and = IETF review of
draft-ietf-i2rs-protocol-security-requirements.  = However, the
draft-ietf-i2rs-protocol-security-requirements were = passed by the I2RS WG
and approved by the IESG for RFC publication = and it contains the non-secure
communication.  The mandate from = the I2RS WG for this shepherd/co-chair is
clear.

As the = shepherd for the topology drafts, I try to write-up something = that
might address Kathleen's Moriarty's concerns about the topology = draft's
security issues about privacy and the I2RS ephemeral control = plane data
store.   I welcome an open discussion on my = ideas
(https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-= sec-consider).   The
yang doctor's YANG  security = consideration template
(https://trac.ietf.org/trac/ops/wiki/yang-security-guide= lines) and the
privacy related RFCs (RFC6973) note that some = information is sensitive.
Hopefully, this document extends these = guidelines to a new data store.

Cheerily,
Sue = Hares

-----Original Message-----
From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jaco= bs-university.de]
Sent: Thursday, January 19, 2017 10:34 = AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG';
draft-ietf-i2rs= -yang-l3-topology@ietf.org; i2rs@ietf.org;
i2rs-chairs@ietf.org
Subject:= Re: [i2rs] Kathleen Moriarty's No Objection = on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

For = what it is worth, I find the notion that data models may be written = for
a specific non-secure transport plain broken. There is hardly any = content of
a data model I can think of which is generally suitable = for insecure
transports.

Can we please kill this idea of = _standardizing_ information that is suitable
to send over non-secure = transports? I really do not see how the IETF can
make a claim that a = given piece of information is never worth protecting (=3D
suitable = for non-secure transports).

Note that I am fine if in a certain = trusted tightly-coupled deployment
information is shipped in whatever = way but this is then a property of the
_deployment_ and not a = property of the _information_.

/js

On Thu, Jan 19, 2017 at = 09:28:14AM -0500, Susan Hares wrote:
> Kathleen:
>
> I = have written a draft suggesting a template for the I2RS YANG = modules
which are designed to exist in the I2RS Ephemeral Control = Plane data store
(configuration and operational = state).
>
> Draft location:
> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-= sec-consider/
>
> I would appreciate an email discussion = with the security ADs, OPS/NM ADs,
and Routing AD (Alia Atlas).  = I agree that this I2RS YANG data model (L3)
and the base I2RS = topology model should both provide updated YANG = Security
Considerations sections. I would appreciate if Benoit or you = hold a discuss
until we sort out these issues.
>
> Thank = you,
>
> Sue
>
> -----Original = Message-----
> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@g= mail.com]
> Sent: Wednesday, January 18, 2017 9:44 PM
> = To: The IESG
> Cc: draft-ietf-i2rs= -yang-l3-topology@ietf.org; shares@ndzh.com;
> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
> Subject: = Kathleen Moriarty's No Objection on
> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> = Kathleen Moriarty has entered the following ballot position for
> = draft-ietf-i2rs-yang-l3-topology-08: No Objection
>
> When = responding, please keep the subject line intact and reply to all
> = email addresses included in the To and CC lines. (Feel free to = cut
> this introductory paragraph, = however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other ballot = positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l= 3-topology/
>
>
>
> = ----------------------------------------------------------------------> COMMENT:
> = ---------------------------------------------------------------------->
> I agree with Alissa's comment that the YANG module = security consideration
section guidelines need to be followed and = this shouldn't go forward until
that is corrected.  I'm told it = will be, thanks.
>
>
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> = https://www.ietf.org/mailman/listinfo/i2rs

--
Juergen Schoenwaelder          =  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587        =  Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103      =    <http://www.jacobs-university.de/>

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

 

------=_NextPart_000_038D_01D2725A.8A2BE000-- From nobody Thu Jan 19 10:55:14 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 DAB6812953D; Thu, 19 Jan 2017 10:55:06 -0800 (PST) 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 7mEbOXKKrZ5S; Thu, 19 Jan 2017 10:55:06 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8948D12954D; Thu, 19 Jan 2017 10:55:05 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Suresh Krishnan'" , "'The IESG'" References: <148479577204.2020.2794444297680490505.idtracker@ietfa.amsl.com> In-Reply-To: <148479577204.2020.2794444297680490505.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 13:50:51 -0500 Message-ID: <03bc01d27284$f5843ee0$e08cbca0$@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: AQGMUymOcQKkib4xoC5/mGBfVS7BG6HMYvQg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:55:07 -0000 Suresh: On the example text, I will work with the authors to move the examples to an appendix. On the router-id, it is possible that one router can have multiple router-id - with each router-id being shared in virtual router. However, I need to go back and chat with the authors to refresh my understanding of the multiple instances. Good catch on the router-id. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, January 18, 2017 10:16 PM To: The IESG Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples. What is the actual intent? Is this draft supposed to be the canonical definition of ospf-topology and isis-topology? Please clarify. * Section 4 Is there a reason that router-id is defined as capable of having multiple instances? _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jan 19 10:56:31 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 156E61294AC for ; Thu, 19 Jan 2017 10:56:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMgHANAXzexW for ; Thu, 19 Jan 2017 10:56:26 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 77DC1129512 for ; Thu, 19 Jan 2017 10:56:23 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id w194so31339724ybe.0 for ; Thu, 19 Jan 2017 10:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IjGcy3qaOTk/QQdf/Ytsjw1MZu+MGuTZK/4zVySbg9E=; b=igZQxmVY4otJTqtJI5cC0WV8W+wynM4Cfg6igXI4hpTaL0TpVf7y2wUxv30+ipJ/dU 4r/b99vO+SmpJpqpjrtJ2vazoSvDivH3JYdiSx3qRebEb7qZ4GcAWmc2bts/sbmlsyX3 CIBruLVy/DEbWXDZRZlG6YffPSHkNWqzYePvRfEY1rPPmjmL5HFaBsOO5VuEdG1Zo4gN XzDRhcXql5QoadCuY1JvGq03Qmw4m/XwK7Nefkfll+4E/qoPaLFPGG5W4cKM9cPtWq6z hHl11eV6O/XhhzMxKWzzBoc4AmCtEz25EfbQWslLeXP7R3vWaC3siT5fgho60Ar3vSFC 9gdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IjGcy3qaOTk/QQdf/Ytsjw1MZu+MGuTZK/4zVySbg9E=; b=NTfwB2KVq77U8RVs7UlsMBRB4+w0yYjITT0EcCxWyEfbx7vi5TeuiHaIocPSZZoix8 dTJK5ny7XDp5/3iG67FVPvW8wWxlZw1gLxedEb4/nQ/mcF/8znaAKnzPP/NXYmoLpQmA 2Mz3GfjZz4aY93hH5o6NXpDF4lLu/EjUX1sTfMtSzyVOOni7j4YpKjAznM7NbwEJealP +j2bAzx5A+wZyXXkZVsG2MwiM6u0QMuqy3/IBX9cwydWpjeNStFkFMvweEAVrcVECwuI lTaeWlAlkmnNkvGWw+c/36WBib2uVd1VB6HhvH1ZnXDZRrjAStGinErKusbaiyQ651d6 Bxxw== X-Gm-Message-State: AIkVDXITFs9VTbO2XzE4qlawYvibynzCmf6W8nK/1APq6jjxk1rYXrXXGb14SWUtJ/lCnKsigRI2QGUBTWOVhQ== X-Received: by 10.55.135.197 with SMTP id j188mr9224411qkd.71.1484852182649; Thu, 19 Jan 2017 10:56:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 19 Jan 2017 10:56:22 -0800 (PST) In-Reply-To: <038c01d27284$72ff01d0$58fd0570$@ndzh.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <038c01d27284$72ff01d0$58fd0570$@ndzh.com> From: Andy Bierman Date: Thu, 19 Jan 2017 10:56:22 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c0777e6e4503705467716b1 Archived-At: Cc: "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:56:28 -0000 --94eb2c0777e6e4503705467716b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I realized that the NACM "default-deny-write" and "default-deny-all" tags are very similar. We are deciding (in the data model) that the data node can never be sent without an explicit NACM rule allowing it. (I have never heard from a customer that they want this NACM rule ignored). We do not abuse these NACM tags. They are rarely used. I think the same will be true for the I2RS extension. Andy On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares wrote: > Andy: > > > > You are right to comment that =E2=80=93 the =E2=80=9Cflip side of this ex= tensions is that > any node not properly tagged must not be SENT=E2=80=9D. The purpose of = tagging is > devices which test protocol conformation can test these portions of the > model. If buyers demand that these restrictions are followed, then these > restrictions will not be ignored. Like you and Juergen, I really hope th= at > the IESG will very carefully evaluate any I2RS YANG Model that suggest > sending data over non-secure transport. > > > > Sue Hares > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, January 19, 2017 1:31 PM > *To:* Susan Hares > *Cc:* Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > I strongly agree with Juergen on this issue. > > But you can easily design a YANG extension that indicates a data node > > is OK for insecure transport. > > > > I trust that the IESG will evaluate every object of this type and > > decide whether it is really OK for disclosure in every possible > > usage scenario. > > > > The flip-side of this extension is that any node not properly tagged > > MUST NOT be sent without the proper security protocols. > > This rule will likely be ignored, since (as Juergen pointed out) > > this is a deployment decision, not a modeling decision. > > > > > > Andy > > > > > > On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares wrote: > > Juergen: > > I recognize that dislike insecure communication. You made a similar > comment > during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG > and approved by the IESG for RFC publication and it contains the non-secu= re > communication. The mandate from the I2RS WG for this shepherd/co-chair i= s > clear. > > As the shepherd for the topology drafts, I try to write-up something that > might address Kathleen's Moriarty's concerns about the topology draft's > security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be written f= or > a specific non-secure transport plain broken. There is hardly any content > of > a data model I can think of which is generally suitable for insecure > transports. > > Can we please kill this idea of _standardizing_ information that is > suitable > to send over non-secure transports? I really do not see how the IETF can > make a claim that a given piece of information is never worth protecting = (=3D > suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of the > _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data stor= e > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM AD= s, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Securit= y > Considerations sections. I would appreciate if Benoit or you hold a discu= ss > until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alissa's comment that the YANG module security considerati= on > section guidelines need to be followed and this shouldn't go forward unti= l > that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --94eb2c0777e6e4503705467716b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I realized that the NACM "defa= ult-deny-write" and "default-deny-all" tags are
ve= ry similar.=C2=A0 We are deciding (in the data model) that the data node
can never be sent without an explicit NACM rule allowing it.
<= div>(I have never heard from a customer that they want this NACM rule ignor= ed).
We do not abuse these NACM tags. They are rarely used.
=
I think the same will be true for the I2RS extension.


Andy


<= div class=3D"gmail_quote">On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares <sha= res@ndzh.com> wrote:

Andy:=

=C2=A0

You are right to comment that =E2=80=93 the =E2=80=9Cflip side of th= is extensions is that any node not properly tagged must not be SENT=E2=80= =9D.=C2=A0=C2=A0 The purpose of tagging is devices which test protocol conf= ormation can test these portions of the model.=C2=A0 If buyers demand that = these restrictions are followed, then these restrictions will not be ignore= d.=C2=A0 Like you and Juergen, I really hope that the IESG will very carefu= lly evaluate any I2RS YANG Model that suggest sending data over non-secure = transport.=C2=A0

=C2=A0

Sue Hares

=C2=A0

From: Andy Bierman [mailt= o:andy@yumaworks.co= m]
Sent: Thursday, January 19, 2017 1:31 PM
To: Su= san Hares
Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-= topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject:<= /b> Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang= -l3-topology-08: (with COMMENT)

=C2=A0

Hi,<= /u>

=C2=A0

I strongly agree with Juergen on this issue.

But you can easily design a YANG ext= ension that indicates a data node

is OK for insecure transport.

=C2=A0

I= trust that the IESG will evaluate every object of this type and<= /u>

decide whether it is really OK for= disclosure in every possible

usage scenario.=C2=A0

=C2=A0

The flip-side= of this extension is that any node not properly tagged

MUST NOT be sent without the proper securit= y protocols.

This rule w= ill likely be ignored, since (as Juergen pointed out)

this is a deployment decision, not a modeling= decision.

=C2=A0=

=C2=A0

=

Andy

=C2=A0

=C2=A0<= u>

On Thu, Jan 19, 2017 at 10:15 AM, Sus= an Hares <shares@nd= zh.com> wrote:

Juergen:
<= br>I recognize that dislike insecure communication.=C2=A0 You made a simila= r comment
during the WG LC and IETF review of
draft-ietf-i2rs-protoco= l-security-requirements.=C2=A0 However, the
draft-ietf-i2rs-protoco= l-security-requirements were passed by the I2RS WG
and approved by = the IESG for RFC publication and it contains the non-secure
communicatio= n.=C2=A0 The mandate from the I2RS WG for this shepherd/co-chair is
clea= r.

As the shepherd for the topology drafts, I try to write-up someth= ing that
might address Kathleen's Moriarty's concerns about the = topology draft's
security issues about privacy and the I2RS ephemera= l control plane data
store.=C2=A0 =C2=A0I welcome an open discussion on = my ideas
(https://datatracker.ietf.org/doc/d= raft-hares-i2rs-yang-sec-consider).=C2=A0 =C2=A0The
yang doctor= 's YANG=C2=A0 security consideration template
(https= ://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and = the
privacy related RFCs (RFC6973) note that some information is sensiti= ve.
Hopefully, this document extends these guidelines to a new data stor= e.

Cheerily,
Sue Hares

-----Original Message-----
From:= Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ]
Sent: Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: &#= 39;Kathleen Moriarty'; 'The IESG';
draft-ietf-i2rs-yang-= l3-topology@ietf.org; i2rs@ietf.org;
i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriar= ty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with= COMMENT)

For what it is worth, I find the notion that data models m= ay be written for
a specific non-secure transport plain broken. There is= hardly any content of
a data model I can think of which is generally su= itable for insecure
transports.

Can we please kill this idea of _= standardizing_ information that is suitable
to send over non-secure tran= sports? I really do not see how the IETF can
make a claim that a given p= iece of information is never worth protecting (=3D
suitable for non-secu= re transports).

Note that I am fine if in a certain trusted tightly-= coupled deployment
information is shipped in whatever way but this is th= en a property of the
_deployment_ and not a property of the _information= _.

/js

On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares = wrote:
> Kathleen:
>
> I have written a draft suggesting = a template for the I2RS YANG modules
which are designed to exist in the = I2RS Ephemeral Control Plane data store
(configuration and operational s= tate).
>
> Draft location:
> http= s://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/<= /a>
>
> I would appreciate an email discussion with the securit= y ADs, OPS/NM ADs,
and Routing AD (Alia Atlas).=C2=A0 I agree that this = I2RS YANG data model (L3)
and the base I2RS topology model should both p= rovide updated YANG Security
Considerations sections. I would appreciate= if Benoit or you hold a discuss
until we sort out these issues.
>=
> Thank you,
>
> Sue
>
> -----Original Messa= ge-----
> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmai= l.com]
> Sent: Wednesday, January 18, 2017 9:44 PM
> To: Th= e IESG
> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com;> i2rs-chair= s@ietf.org; shares= @ndzh.com; i2rs@ietf= .org
> Subject: Kathleen Moriarty's No Objection on
> d= raft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> Kat= hleen Moriarty has entered the following ballot position for
> draft-= ietf-i2rs-yang-l3-topology-08: No Objection
>
> When respo= nding, please keep the subject line intact and reply to all
> email a= ddresses included in the To and CC lines. (Feel free to cut
> this in= troductory paragraph, however.)
>
>
> Please refer to
= > https://www.ietf.org/iesg/statement/discuss-criteria= .html
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other ballot po= sitions, can be found here:
> https://datatrack= er.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
>
= >
>
> -------------------------------------------------= ---------------------
> COMMENT:
> -----------------------= -----------------------------------------------
>
> I= agree with Alissa's comment that the YANG module security consideratio= n
section guidelines need to be followed and this shouldn't go forwa= rd until
that is corrected.=C2=A0 I'm told it will be, thanks.
&g= t;
>
>
> ___________________________________________= ____
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/li= stinfo/i2rs

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 = | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>

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

=C2=A0=


--94eb2c0777e6e4503705467716b1-- From nobody Thu Jan 19 11:01:57 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 0A4691294DB; Thu, 19 Jan 2017 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BgyNHBeP8QO; Thu, 19 Jan 2017 11:01:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7137129407; Thu, 19 Jan 2017 11:01:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Andy Bierman'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <038c01d27284$72ff01d0$58fd0570$@ndzh.com> In-Reply-To: Date: Thu, 19 Jan 2017 13:57:37 -0500 Message-ID: <03c901d27285$e77cd360$b6767a20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03CA_01D2725B.FEAB8650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwGvQSB1AYnnruUCkN90y6CJpwLA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 19:01:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03CA_01D2725B.FEAB8650 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 This is probably a good idea. Does the NACM apply equally to NETCONF = and RESTCONF?=20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, January 19, 2017 1:56 PM To: Susan Hares Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi, =20 I realized that the NACM "default-deny-write" and "default-deny-all" = tags are very similar. We are deciding (in the data model) that the data node can never be sent without an explicit NACM rule allowing it. (I have never heard from a customer that they want this NACM rule = ignored). We do not abuse these NACM tags. They are rarely used. I think the same will be true for the I2RS extension. =20 =20 Andy =20 =20 On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares wrote: Andy:=20 =20 You are right to comment that =E2=80=93 the =E2=80=9Cflip side of this = extensions is that any node not properly tagged must not be = SENT=E2=80=9D. The purpose of tagging is devices which test protocol = conformation can test these portions of the model. If buyers demand = that these restrictions are followed, then these restrictions will not = be ignored. Like you and Juergen, I really hope that the IESG will very = carefully evaluate any I2RS YANG Model that suggest sending data over = non-secure transport. =20 =20 Sue Hares=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, January 19, 2017 1:31 PM To: Susan Hares Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi, =20 I strongly agree with Juergen on this issue. But you can easily design a YANG extension that indicates a data node is OK for insecure transport. =20 I trust that the IESG will evaluate every object of this type and decide whether it is really OK for disclosure in every possible usage scenario.=20 =20 The flip-side of this extension is that any node not properly tagged MUST NOT be sent without the proper security protocols. This rule will likely be ignored, since (as Juergen pointed out) this is a deployment decision, not a modeling decision. =20 =20 Andy =20 =20 On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares wrote: Juergen: I recognize that dislike insecure communication. You made a similar = comment during the WG LC and IETF review of draft-ietf-i2rs-protocol-security-requirements. However, the draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS = WG and approved by the IESG for RFC publication and it contains the = non-secure communication. The mandate from the I2RS WG for this shepherd/co-chair = is clear. As the shepherd for the topology drafts, I try to write-up something = that might address Kathleen's Moriarty's concerns about the topology draft's security issues about privacy and the I2RS ephemeral control plane data store. I welcome an open discussion on my ideas (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). = The yang doctor's YANG security consideration template (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the privacy related RFCs (RFC6973) note that some information is sensitive. Hopefully, this document extends these guidelines to a new data store. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, January 19, 2017 10:34 AM To: Susan Hares Cc: 'Kathleen Moriarty'; 'The IESG'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) For what it is worth, I find the notion that data models may be written = for a specific non-secure transport plain broken. There is hardly any = content of a data model I can think of which is generally suitable for insecure transports. Can we please kill this idea of _standardizing_ information that is = suitable to send over non-secure transports? I really do not see how the IETF can make a claim that a given piece of information is never worth protecting = (=3D suitable for non-secure transports). Note that I am fine if in a certain trusted tightly-coupled deployment information is shipped in whatever way but this is then a property of = the _deployment_ and not a property of the _information_. /js On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > Kathleen: > > I have written a draft suggesting a template for the I2RS YANG modules which are designed to exist in the I2RS Ephemeral Control Plane data = store (configuration and operational state). > > Draft location: > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > I would appreciate an email discussion with the security ADs, OPS/NM = ADs, and Routing AD (Alia Atlas). I agree that this I2RS YANG data model = (L3) and the base I2RS topology model should both provide updated YANG = Security Considerations sections. I would appreciate if Benoit or you hold a = discuss until we sort out these issues. > > Thank you, > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, January 18, 2017 9:44 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa's comment that the YANG module security = consideration section guidelines need to be followed and this shouldn't go forward = until that is corrected. I'm told it will be, thanks. > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_03CA_01D2725B.FEAB8650 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

This is probably a good idea.=C2=A0 Does the NACM apply equally to = NETCONF and RESTCONF?

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, = January 19, 2017 1:56 PM
To: Susan Hares
Cc: Juergen = Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

Hi,

 

I = realized that the NACM "default-deny-write" and = "default-deny-all" tags are

very similar.  We are deciding (in the data = model) that the data node

can never be sent without an explicit NACM rule = allowing it.

(I have never = heard from a customer that they want this NACM rule = ignored).

We do not abuse = these NACM tags. They are rarely used.

I think the same will be true for the I2RS = extension.

 

 

Andy

 

 

On Thu, = Jan 19, 2017 at 10:47 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

You are right to comment that =E2=80=93 the =E2=80=9Cflip side of = this extensions is that any node not properly tagged must not be = SENT=E2=80=9D.   The purpose of tagging is devices which test = protocol conformation can test these portions of the model.  If = buyers demand that these restrictions are followed, then these = restrictions will not be ignored.  Like you and Juergen, I really = hope that the IESG will very carefully evaluate any I2RS YANG Model that = suggest sending data over non-secure transport.  =

 

Sue Hares

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, = January 19, 2017 1:31 PM
To: Susan Hares
Cc: Juergen = Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

 <= /o:p>

Hi,

 <= /o:p>

I strongly = agree with Juergen on this issue.

But you can = easily design a YANG extension that indicates a data = node

is OK for = insecure transport.

 <= /o:p>

I trust = that the IESG will evaluate every object of this type = and

decide = whether it is really OK for disclosure in every = possible

usage = scenario. 

 <= /o:p>

The = flip-side of this extension is that any node not properly = tagged

MUST NOT be = sent without the proper security protocols.

This rule = will likely be ignored, since (as Juergen pointed = out)

this is a = deployment decision, not a modeling = decision.

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

On Thu, Jan = 19, 2017 at 10:15 AM, Susan Hares <shares@ndzh.com> wrote:

Juergen:
=
I recognize that dislike insecure communication.  You made a = similar comment
during the WG LC and IETF review = of
draft-ietf-i2rs-protocol-security-requirements.  However, = the
draft-ietf-i2rs-protocol-security-requirements were passed by the = I2RS WG
and approved by the IESG for RFC publication and it contains = the non-secure
communication.  The mandate from the I2RS WG for = this shepherd/co-chair is
clear.

As the shepherd for the = topology drafts, I try to write-up something that
might address = Kathleen's Moriarty's concerns about the topology draft's
security = issues about privacy and the I2RS ephemeral control plane = data
store.   I welcome an open discussion on my = ideas
(https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-= sec-consider).   The
yang doctor's YANG  security = consideration template
(https://trac.ietf.org/trac/ops/wiki/yang-security-guide= lines) and the
privacy related RFCs (RFC6973) note that some = information is sensitive.
Hopefully, this document extends these = guidelines to a new data store.

Cheerily,
Sue = Hares

-----Original Message-----
From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]
Sent: = Thursday, January 19, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen = Moriarty'; 'The IESG';
draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;
i2rs-chairs@ietf.org
Subject: Re: [i2rs] = Kathleen Moriarty's No Objection = on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

For = what it is worth, I find the notion that data models may be written = for
a specific non-secure transport plain broken. There is hardly any = content of
a data model I can think of which is generally suitable = for insecure
transports.

Can we please kill this idea of = _standardizing_ information that is suitable
to send over non-secure = transports? I really do not see how the IETF can
make a claim that a = given piece of information is never worth protecting (=3D
suitable = for non-secure transports).

Note that I am fine if in a certain = trusted tightly-coupled deployment
information is shipped in whatever = way but this is then a property of the
_deployment_ and not a = property of the _information_.

/js

On Thu, Jan 19, 2017 at = 09:28:14AM -0500, Susan Hares wrote:
> Kathleen:
>
> I = have written a draft suggesting a template for the I2RS YANG = modules
which are designed to exist in the I2RS Ephemeral Control = Plane data store
(configuration and operational = state).
>
> Draft location:
> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-= sec-consider/
>
> I would appreciate an email discussion = with the security ADs, OPS/NM ADs,
and Routing AD (Alia Atlas).  = I agree that this I2RS YANG data model (L3)
and the base I2RS = topology model should both provide updated YANG = Security
Considerations sections. I would appreciate if Benoit or you = hold a discuss
until we sort out these issues.
>
> Thank = you,
>
> Sue
>
> -----Original = Message-----
> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
> Sent: = Wednesday, January 18, 2017 9:44 PM
> To: The IESG
> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com;
> i2rs-chairs@ietf.org; shares@ndzh.com; = i2rs@ietf.org
> Subject: Kathleen Moriarty's = No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
>
> Kathleen Moriarty has entered the following = ballot position for
> draft-ietf-i2rs-yang-l3-topology-08: No = Objection
>
> When responding, please keep the subject line = intact and reply to all
> email addresses included in the To and = CC lines. (Feel free to cut
> this introductory paragraph, = however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other ballot = positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l= 3-topology/
>
>
>
> = ----------------------------------------------------------------------> COMMENT:
> = ---------------------------------------------------------------------->
> I agree with Alissa's comment that the YANG module = security consideration
section guidelines need to be followed and = this shouldn't go forward until
that is corrected.  I'm told it = will be, thanks.
>
>
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
Juergen Schoenwaelder    =        Jacobs University Bremen = gGmbH
Phone: +49 421 = 200 3587         Campus Ring 1 | 28759 Bremen | = Germany
Fax:  =  +49 421 200 3103         <http://www.jacobs-university.de/>

= _____________________________________= __________
i2rs = mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 <= /o:p>

 

------=_NextPart_000_03CA_01D2725B.FEAB8650-- From nobody Thu Jan 19 11: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 7D40412943B; Thu, 19 Jan 2017 11:26:22 -0800 (PST) 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 UIS4RDEwu1qR; Thu, 19 Jan 2017 11:26:21 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4689129407; Thu, 19 Jan 2017 11:26:20 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Alissa Cooper'" References: <148475529732.2033.2804033282469672192.idtracker@ietfa.amsl.com> <20170118190843.GA5811@elstar.local> In-Reply-To: <20170118190843.GA5811@elstar.local> Date: Thu, 19 Jan 2017 14:22:07 -0500 Message-ID: <03ee01d27289$53ee7c30$fbcb7490$@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: AQG2NVgpOo1PoKYJOdP96c7wg3gFUQHwWW3doWklD2A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 19:26:22 -0000 Alissa and Juergen: Thank you for catching these errors. Sue Hares (Shepherd) -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, January 18, 2017 2:09 PM To: Alissa Cooper Cc: The IESG; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) On Wed, Jan 18, 2017 at 08:01:37AM -0800, Alissa Cooper wrote: > > "case interface-name { > leaf interface-name { > type string; > description > "A name of the interface. The name can (but does not > have to) correspond to an interface reference of a > containing node's interface, i.e. the path name of a > corresponding interface data node on the containing > node reminiscent of data type if-ref defined in > RFC 7223. It should be noted that data type if-ref of > RFC 7223 cannot be used directly, as this data type > is used to reference an interface in a datastore of > a single node in the network, not to uniquely > reference interfaces across a network."; > } > }" > > In RFC 7223 the data type appears to be called interface-ref, not if-ref. > Would an example of this in this document be, say, a MAC address? > Now that I read this, I must say that I do not understand the description at all. What does 'i.e. the path name of a corresponding interface data node on the containing node reminiscent of data type if-ref defined in RFC 7223.' tell me? If the intention here is that it is unique across a network I think this should be stated more clearly, that is, not as a sub-thought in a sentence trying to explain why if-ref can't be used. And then, what is a 'network'? And looking at the whole choice, the other options are not unique either. For unnumbered-id, the description says "will correspond to the ifIndex value of the interface" which very likely will clash for different nodes. Also IP adresses may not always be unique 'across a network'. So why do we have this "unique across a network" requirement for the interface-name case? That is, we can't we use /js PS: Why is interface-name marked 'ro' in the tree diagram? It looks like a config true node. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 19 11:52:50 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 049431294C6 for ; Thu, 19 Jan 2017 11:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dyyGXSCkMQe for ; Thu, 19 Jan 2017 11:52:44 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADB01294CC for ; Thu, 19 Jan 2017 11:52:42 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id l19so47072047ywc.2 for ; Thu, 19 Jan 2017 11:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T66x6j0uZHl4zPgI1vXVK1QWT2oJAh9lpjTKOYbmiPQ=; b=kmKkutM0JF9Tky15STp1PxbXbWnY2dPQujABm4j2pcS4MVu4t34/hpNLPdeAkAQOpj EEaNXtMYagDV8kO0jvR9g305zbb7XWImcJnoR1SwxLcC/9pXOfnmXpXRm+xso81ia2Jr erJGy44e+PLc8/6r9aDMaofaIAI7wjsf2+ZDKOPcXVGCx3ZJXzI+lwJeYQw20MmXuqe9 It/7zxOVBbHWTtf2rYZos4Fx6FIxXkYpX0hnZsGsTx2x4zQJoi9k511juO9FLH4U3YwZ yJlOqux7NN9PrMjLkgcINqQHK8KHZ+kGfwpxylL0VJcDw/hpZlzgyfti9X8Szx8x188I AFjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T66x6j0uZHl4zPgI1vXVK1QWT2oJAh9lpjTKOYbmiPQ=; b=ekXvRYZyVG7dmOHJYom+WPgDqUrwgGIoQ0UomY9/GGmCEfamUaQbYs2kT0TO7uap98 E32PAoGj3/LNVwrNzepEqTj+aLxzJyV0QDIXGNdZT/adRkupo6xVqSGR0Xq++mNIrQdF F7P8dVmHxQo+2+72AdE6zOIIN3nbTikT1UxgKrkRn/MsDer8KUPkyGX+IYX/zC+ponms Ye27OX4G9WJdE84YJEUnWz5vHAfmBxzgvftqkPyRFwS267lRo0+kUHkurCb8P5fmkq95 K/FSra/jdB/h8jHrNFZ8pyXfoE2Rik2EVUqdbqshiu9BiwbTKIz+ObJen8a1d0noVQSI 1Gyw== X-Gm-Message-State: AIkVDXKEBzgir+6bx3Il4g7OVhDFRK+3iv7GGU1FBE/IzQcGihaX9oQXwqM2g297+DU6IXJfoiyEvt3e5jpE+A== X-Received: by 10.55.20.137 with SMTP id 9mr9115676qku.237.1484855561713; Thu, 19 Jan 2017 11:52:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 19 Jan 2017 11:52:41 -0800 (PST) In-Reply-To: <03c901d27285$e77cd360$b6767a20$@ndzh.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <038c01d27284$72ff01d0$58fd0570$@ndzh.com> <03c901d27285$e77cd360$b6767a20$@ndzh.com> From: Andy Bierman Date: Thu, 19 Jan 2017 11:52:41 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1144d2264c8fc9054677e0d7 Archived-At: Cc: "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 19:52:46 -0000 --001a1144d2264c8fc9054677e0d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2017 at 10:57 AM, Susan Hares wrote: > Andy: > > > > This is probably a good idea. Does the NACM apply equally to NETCONF and > RESTCONF? > > > Yes -- well, soon - there is a 6536bis draft to add RESTCONF and YANG 1.1 support to NACM. > Sue > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, January 19, 2017 1:56 PM > *To:* Susan Hares > *Cc:* Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > I realized that the NACM "default-deny-write" and "default-deny-all" tags > are > > very similar. We are deciding (in the data model) that the data node > > can never be sent without an explicit NACM rule allowing it. > > (I have never heard from a customer that they want this NACM rule ignored= ). > > We do not abuse these NACM tags. They are rarely used. > > I think the same will be true for the I2RS extension. > > > > > > Andy > > > > > > On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares wrote: > > Andy: > > > > You are right to comment that =E2=80=93 the =E2=80=9Cflip side of this ex= tensions is that > any node not properly tagged must not be SENT=E2=80=9D. The purpose of = tagging is > devices which test protocol conformation can test these portions of the > model. If buyers demand that these restrictions are followed, then these > restrictions will not be ignored. Like you and Juergen, I really hope th= at > the IESG will very carefully evaluate any I2RS YANG Model that suggest > sending data over non-secure transport. > > > > Sue Hares > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, January 19, 2017 1:31 PM > *To:* Susan Hares > *Cc:* Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > I strongly agree with Juergen on this issue. > > But you can easily design a YANG extension that indicates a data node > > is OK for insecure transport. > > > > I trust that the IESG will evaluate every object of this type and > > decide whether it is really OK for disclosure in every possible > > usage scenario. > > > > The flip-side of this extension is that any node not properly tagged > > MUST NOT be sent without the proper security protocols. > > This rule will likely be ignored, since (as Juergen pointed out) > > this is a deployment decision, not a modeling decision. > > > > > > Andy > > > > > > On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares wrote: > > Juergen: > > I recognize that dislike insecure communication. You made a similar > comment > during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG > and approved by the IESG for RFC publication and it contains the non-secu= re > communication. The mandate from the I2RS WG for this shepherd/co-chair i= s > clear. > > As the shepherd for the topology drafts, I try to write-up something that > might address Kathleen's Moriarty's concerns about the topology draft's > security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be written f= or > a specific non-secure transport plain broken. There is hardly any content > of > a data model I can think of which is generally suitable for insecure > transports. > > Can we please kill this idea of _standardizing_ information that is > suitable > to send over non-secure transports? I really do not see how the IETF can > make a claim that a given piece of information is never worth protecting = (=3D > suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of the > _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data stor= e > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM AD= s, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Securit= y > Considerations sections. I would appreciate if Benoit or you hold a discu= ss > until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alissa's comment that the YANG module security considerati= on > section guidelines need to be followed and this shouldn't go forward unti= l > that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > --001a1144d2264c8fc9054677e0d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 19, 2017 at 10:57 AM, Susan Hares <shares@ndzh.com> wrote:

Andy: <= /p>

=C2=A0

This is probably= a good idea.=C2=A0 Does the NACM apply equally to NETCONF and RESTCONF?

=C2=A0


Yes -- w= ell, soon - there is a 6536bis draft to add RESTCONF and YANG 1.1 support t= o NACM.
=C2=A0

=

Sue

<= /div>


Andy
=C2=A0<= /div>

=C2=A0

From: Andy Bierman [m= ailto:andy@yumawork= s.com]
Sent: Thursday, January 19, 2017 1:56 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang= -l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subje= ct: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-= yang-l3-topology-08: (with COMMENT)

=C2=A0

Hi,

=C2=A0

I realized that the NACM "default-deny-write&q= uot; and "default-deny-all" tags are

=

very similar.=C2=A0 We are deciding (in the data mod= el) that the data node

c= an never be sent without an explicit NACM rule allowing it.

(I have never heard from a customer tha= t they want this NACM rule ignored).

We do not abuse these NACM tags. They are rarely used.

I think the same will be true= for the I2RS extension.

=C2=A0

=C2=A0=

Andy

=

=C2=A0

= =C2=A0

On Thu, Jan 19, 2017 at= 10:47 AM, Susan Hares <shares@ndzh.com> wrote:

Andy:

=C2=A0

=

You are right to comment = that =E2=80=93 the =E2=80=9Cflip side of this extensions is that any node n= ot properly tagged must not be SENT=E2=80=9D.=C2=A0=C2=A0 The purpose of ta= gging is devices which test protocol conformation can test these portions o= f the model.=C2=A0 If buyers demand that these restrictions are followed, t= hen these restrictions will not be ignored.=C2=A0 Like you and Juergen, I r= eally hope that the IESG will very carefully evaluate any I2RS YANG Model t= hat suggest sending data over non-secure transport.=C2=A0 =

=C2=A0<= /u>

Sue Hares <= /span>

= =C2=A0

From:<= /span> Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday,= January 19, 2017 1:31 PM
To: Susan Hares
Cc: Juergen S= choenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen M= oriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty&= #39;s No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMME= NT)

=C2=A0

=

Hi,

=C2=A0

I strongly agre= e with Juergen on this issue.

But you can easily design a YANG extension that indicates a data node=

is OK for insecure tran= sport.

=C2=A0<= /u>

I trust that the IESG will evaluat= e every object of this type and

decide whether it is really OK for disclosure in every possible<= /u>

usage scenario.=C2=A0

=C2=A0

The flip-side of this extension is that any no= de not properly tagged

M= UST NOT be sent without the proper security protocols.

This rule will likely be ignored, since (as = Juergen pointed out)

thi= s is a deployment decision, not a modeling decision.

=C2=A0

=C2=A0

Andy<= u>

=C2=A0

=

=C2=A0

On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares <shares@ndzh.com> wrote:

Juergen:

I recognize that dislike insec= ure communication.=C2=A0 You made a similar comment
during the WG LC and= IETF review of
draft-ietf-i2rs-protocol-security-requirements.=C2= =A0 However, the
draft-ietf-i2rs-protocol-security-requirements wer= e passed by the I2RS WG
and approved by the IESG for RFC publication and= it contains the non-secure
communication.=C2=A0 The mandate from the I2= RS WG for this shepherd/co-chair is
clear.

As the shepherd for th= e topology drafts, I try to write-up something that
might address Kathle= en's Moriarty's concerns about the topology draft's
security= issues about privacy and the I2RS ephemeral control plane data
store.= =C2=A0 =C2=A0I welcome an open discussion on my ideas
(https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-= consider).=C2=A0 =C2=A0The
yang doctor's YANG=C2=A0 security con= sideration template
(https://trac.ietf.org/trac/ops= /wiki/yang-security-guidelines) and the
privacy related RFCs (R= FC6973) note that some information is sensitive.
Hopefully, this documen= t extends these guidelines to a new data store.

Cheerily,
Sue Har= es

-----Original Message-----
From: Juergen Schoenwaelder [mailto= := j.schoenwaelder@jacobs-university.de]
Sent: Thursday, January 1= 9, 2017 10:34 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; = 9;The IESG';
draft-ietf-i2rs-yang-l3-topology@ietf.org;= i2rs@ietf.org;
<= a href=3D"mailto:i2rs-chairs@ietf.org" target=3D"_blank">i2rs-chairs@ietf.o= rg
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
dr= aft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

For what it i= s worth, I find the notion that data models may be written for
a specifi= c non-secure transport plain broken. There is hardly any content of
a da= ta model I can think of which is generally suitable for insecure
transpo= rts.

Can we please kill this idea of _standardizing_ information tha= t is suitable
to send over non-secure transports? I really do not see ho= w the IETF can
make a claim that a given piece of information is never w= orth protecting (=3D
suitable for non-secure transports).

Note th= at I am fine if in a certain trusted tightly-coupled deployment
informat= ion is shipped in whatever way but this is then a property of the
_deplo= yment_ and not a property of the _information_.

/js

On Thu, J= an 19, 2017 at 09:28:14AM -0500, Susan Hares wrote:
> Kathleen:
&g= t;
> I have written a draft suggesting a template for the I2RS YANG m= odules
which are designed to exist in the I2RS Ephemeral Control Plane d= ata store
(configuration and operational state).
>
> Draft l= ocation:
> https://datatracker.ietf.org/= doc/draft-hares-i2rs-yang-sec-consider/
>
> I would ap= preciate an email discussion with the security ADs, OPS/NM ADs,
and Rout= ing AD (Alia Atlas).=C2=A0 I agree that this I2RS YANG data model (L3)
a= nd the base I2RS topology model should both provide updated YANG SecurityConsiderations sections. I would appreciate if Benoit or you hold a discu= ss
until we sort out these issues.
>
> Thank you,
>> Sue
>
> -----Original Message-----
> From: Kathleen= Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
> Sent: Wedne= sday, January 18, 2017 9:44 PM
> To: The IESG
> Cc: draft-i= etf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com;
> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
> Subject: Kath= leen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-to= pology-08: (with COMMENT)
>
> Kathleen Moriarty has entered the= following ballot position for
> draft-ietf-i2rs-yang-l3-topolog= y-08: No Objection
>
> When responding, please keep the subject= line intact and reply to all
> email addresses included in the To an= d CC lines. (Feel free to cut
> this introductory paragraph, however.= )
>
>
> Please refer to
> https://www.= ietf.org/iesg/statement/discuss-criteria.html
> for mor= e information about IESG DISCUSS and COMMENT positions.
>
>
= > The document, along with other ballot positions, can be found here:> https://datatracker.ietf.org/doc/draft-iet= f-i2rs-yang-l3-topology/
>
>
>
> ---------= -------------------------------------------------------------
= > COMMENT:
> ------------------------------------------------= ----------------------
>
> I agree with Alissa's comme= nt that the YANG module security consideration
section guidelines need t= o be followed and this shouldn't go forward until
that is corrected.= =C2=A0 I'm told it will be, thanks.
>
>
>
> ___= ____________________________________________
> i2rs mailing list=
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+4= 9 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.d= e/>

_______________________________________________<= br>i2rs ma= iling list
i2rs@ietf.org=
https://www.ietf.org/mailman/listinfo/i2rs=

=C2=A0

=C2=A0


--001a1144d2264c8fc9054677e0d7-- From nobody Thu Jan 19 22:13:16 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 74B11129995; Thu, 19 Jan 2017 22:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q1T0qSpGyn4; Thu, 19 Jan 2017 22:13:09 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFC6129994; Thu, 19 Jan 2017 22:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9624; q=dns/txt; s=iport; t=1484892789; x=1486102389; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZUq4P1SSrgQlEH7N8DDYeYijkVnJISkj/Bti7FzBWJI=; b=X1TCxeyDDoQkzwJA+2eqcjM0wXgSNhcZETwquxLyLTJ0a8hTNLsMZ0J6 KCwis2ctKECoVQwPSuUi+CdexodAMyyT041LqYAVMT1SQcxkqSbN7IXtx XaVbSG3ASD8J24z/EP+g8tSyei3JHEWPfttXWCcnxju2PknpIZO4zQ7V0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAQDcqYFY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR9geBEHg0yKCJIEkx6CD4IMLIUsSgIagWc/FAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEDASMRRQULAgEGAhgCAiYCAgIwFRACBA4FiHwIDpF7nU6CJ?= =?us-ascii?q?YpKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VAggWCaoI9gV4QAgGDIS2CMQW?= =?us-ascii?q?JAIYrjB0BhmGLBIF3hQ+DTYYbknMBHzhyUxU6EAGEXIFIcwGIBoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,257,1477958400"; d="scan'208";a="195618318" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 06:13:08 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0K6D83m029308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jan 2017 06:13:08 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 00:13:07 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Fri, 20 Jan 2017 00:13:07 -0600 From: "Carl Moberg (camoberg)" To: "Benoit Claise (bclaise)" Thread-Topic: Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) Thread-Index: AQHSckaCsdMaAYT6DkSlwbPqH79LY6FBSJCA Date: Fri, 20 Jan 2017 06:13:07 +0000 Message-ID: <090DDF93-60EE-41BC-9D9A-BCDA9A96F670@cisco.com> References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> In-Reply-To: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.116.164] Content-Type: text/plain; charset="utf-8" Content-ID: <342E71B2488D204EA0E493A6DD8C7C62@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "Ronald P. Bonica" , "i2rs-chairs@ietf.org" , The IESG , "shares@ndzh.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 20 Jan 2017 06:13:11 -0000 DQogSW5saW5lIGJlbG93Og0KDQo+IE9uIEphbiAxOSwgMjAxNywgYXQgMTI6MjMgUE0sIEJlbm9p dCBDbGFpc2UgKGJjbGFpc2UpIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBCZW5v aXQgQ2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wODogRGlzY3Vzcw0KPiANCj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhv d2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aTJycy15YW5nLWwzLXRvcG9sb2d5Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJ U0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IDEuIFRoZSBleGFtcGxlcy4NCj4gSW4gdGhl IEFVVEg0OCBmb3IgdGhlIFJFU1RDT05GIFJGQywgdGhlIGV4YW1wbGUgWUFORyBtb2R1bGUgZGlz Y3Vzc2lvbg0KPiBjYW1lIHVwIChhZ2FpbikuICBBbmQgdGhlIGV4YW1wbGVzIGluIGRyYWZ0LWll dGYtaTJycy15YW5nLWwzLXRvcG9sb2d5DQo+IHdlcmUgYWxzbyBkaXNjdXNzZWQuIEhlcmUgaXMg dGhlIGZlZWRiYWNrIGZyb20gb25lIFlBTkcgZG9jdG9yLCBmcm9tIGENCj4gY291cGxlIG9mIGRh eXMgYWdvLg0KPiANCj4gTG9vayBhdCB0aGlzOg0KPiANCj4gICBtb2R1bGUgZXhhbXBsZS1pZXRm LW9zcGYtdG9wb2xvZ3kgew0KPiAgICAgLi4uDQo+ICAgICBuYW1lc3BhY2UNCj4gICAgICAgInVy bjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpleGFtcGxlLWlldGYtb3NwZi10b3BvbG9neSI7DQo+ ICAgICAuLi4NCj4gICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICJUaGlzIG1vZHVsZSBkZWZpbmVz IGEgbW9kZWwgZm9yIE9TUEYgbmV0d29yayB0b3BvbG9naWVzLg0KPiAgICAgICAgQ29weXJpZ2h0 IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMNCj4gICAg ICAgIGF1dGhvcnMgb2YgdGhlIGNvZGUuIA0KPiANCj4gDQo+IFRoZXkgYXJlIHVzaW5nIHRoZSBJ QU5BLWNvbnRyb2xsZWQgbmFtZXNwYWNlIHcvbyByZWdpc3RlcmluZyBpdC4NCj4gDQo+IFRoaXMg bW9kdWxlICpyZWFsbHkqIGxvb2tzIGxpa2UgYSBwcm9wZXIgbm9ybWF0aXZlIG1vZHVsZSwgcmF0 aGVyIHRoYW4NCj4gYW4NCj4gZXhhbXBsZS4gIFRoZXkgd2VudCB0byBmYXIgaW4gdHJ5aW5nIHRv IG1pbWljIGEgcmVhbCBtb2R1bGUuDQo+IA0KPiBJdCBpcyBjbGVhciB0aGF0IHdlIG5lZWQgbW9y ZSBndWlkZWxpbmVzIGluIDYwODcgZm9yIGhvdyB0byB3cml0ZQ0KPiBleGFtcGxlIG1vZHVsZXMu DQo+IA0KPiBJIHdhcyBnb2luZyB0byBhc2sgaWYgdGhpcyBtb2R1bGUgcGFzc2VkIFlBTkcgZG9j dG9yIHJldmlldyAtIHRoZW4gSQ0KPiBjaGVja2VkIGFuZCBzYXcgdGhhdCB2ZXJzaW9uIC0wMiB3 YXMgcmV2aWV3ZWQsIHdoaWNoIGRpZG4ndCBpbmNsdWRlDQo+IHRoaXMgZXhhbXBsZS4gIEhvdyBz aG91bGQgd2UgKHRoZSBZQU5HIGRvY3RvcnMpIGhhbmRsZSBzdWNoIGEgY2FzZT8NCj4gDQo+IElu IHRoaXMgY2FzZSB0aGV5IHNob3VsZDoNCj4gDQo+ICAxLiAgY2hhbmdlIHRoZSBuYW1lIHRvIGV4 YW1wbGUtb3NwZi10b3BvbG9neQ0KPiAgMi4gIGNoYW5nZSB0aGUgbmFtZXNwYWNlIHRvIHVybjpl eGFtcGxlOm9zcGYtdG9wb2xvZ3kNCj4gIDMuICByZW1vdmUgdGhlIHRvcC1sZXZlbCBzdGF0ZW1l bnRzOg0KPiAgICAgICAgICBvcmdhbml6YXRpb24sIGNvbnRhY3QsIHJldmlzaW9uDQo+IA0KPiAg NC4gIGNoYW5nZSB0aGUgdG9wLWxldmVsIGRlc2NyaXB0aW9uIHRvIHdoYXQgdGhlIHRleHQgaW4g dGhlIGRyYWZ0DQo+ICAgICAgc2F5czoNCj4gDQo+ICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAg ICJUaGlzIG1vZHVsZSBpcyBpbnRlbmRlZCBhcyBhbiBleGFtcGxlIGZvciBob3cgdGhlDQo+ICAg ICAgICAgTGF5ZXIgMyBVbmljYXN0IHRvcG9sb2d5IG1vZGVsIGNhbiBiZSBleHRlbmRlZCB0byBj b3Zlcg0KPiAgICAgICAgIE9TRlAgdG9wb2xvZ2llcy4iOw0KPiANCj4gKHNhbWUgZm9yIHRoZSBv dGhlciBleGFtcGxlIG1vZHVsZSkNCj4gDQo+IA0KPiBBcyBJIG1lbnRpb25lZCB0byB0aGUgYXV0 aG9ycywgcmVzcGVjdGl2ZSBjaGFpcnMgYW5kIEFEIGFscmVhZHksIHdlDQo+IHNob3VsZCBmb2xs b3cgdGhlIGRlY2lzaW9uIGluIHRoaXMgTkVUTU9EIGVtYWlsIHRocmVhZA0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE3NDI4Lmh0bWwN Cj4gVGhpcyB3aWxsIGhvcGVmdWxseSByZXNvbHZlIGZhc3QuIE9uY2Ugc2V0dGxlZCwgdGhlIGV4 YW1wbGVzIHNob3VsZCBiZQ0KPiB1cGRhdGVkLg0KPiANCj4gMi4gVGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNob3VsZCBiZSBiZXR0ZXIgYWxpZ25lZCB3aXRoDQo+IGh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL29wcy93aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lcywgYXMNCj4gbWVu dGlvbmVkIGJ5IG90aGVycy4NCj4gDQo+IDMuIENhcmwgTW9iZXJnLCBhcyBZQU5HIGRvY3Rvciwg cmV2aWV3ZWQgdjEgb2YgdGhlIGRyYWZ0Lg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3lhbmctZG9jdG9ycy9jdXJyZW50L21zZzAwMDMxLmh0bWwNCj4gSSdtIHdhaXRp bmcgZm9yIGZpbmFsIGJsZXNzaW5nIG9uIHY4IGFueSB0aW1lIHNvb24uIEhlbmNlIHRoaXMgbGF0 ZQ0KPiBESVNDVVNTLg0KDQogSSBoYXZlIHJlLXJldmlld2VkIHRoZSBjdXJyZW50ICgtMDgpIGRy YWZ0IHRvIGZvbGxvdyB1cCBvbiBteSByZW1hcmtzIGZyb20gLTAxLiBUaGUgb25seSByZW1hcmsg dGhhdCBoYXMgbm90IGJlZW4gYWRkcmVzc2VkIGluIHRoZSBkcmFmdCBpcyB0aGUgZm9sbG93aW5n Og0KDQrigJzigJ0iDQoxLiBBbGwgZGF0YSBkZWZpbml0aW9ucyBhcmUgb3B0aW9uYWwgY29uZmln dXJhdGlvbiAoZS5nLiBubyBjb25maWcgZmFsc2UsIGRlZmF1bHQgdmFsdWVzIG9yIG1hbmRhdG9y eSBzdGF0ZW1lbnRzKS4gVGhpcyBzZWVtcyB0byBvcGVuIHVwIGZvciBtYW55IG9kZCBjb21iaW5h dGlvbnMgb2YgZS5nLiBleGlzdGluZyBhbmQgbm9uLWV4aXN0aW5nIGxlYWZzIGluIG5vZGUsIGxp bmssIGFuZCB0ZXJtaW5hdGlvbi1wb2ludHMuIFRoaXMgaXMgYWxzbyB0cnVlIGZvciB0aGUgbm90 aWZpY2F0aW9ucy4gSXMgdGhpcyBieSBkZXNpZ24gb3Igc29tZXRoaW5nIHRoYXQgbmVlZHMgYWRk aXRpb25hbCB3b3JrPw0K4oCc4oCd4oCdDQoNCiBUaGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0aG9y cyAodGhyb3VnaCBBbGV4IENsZW1tKSBkdXJpbmcgdGhlIGZpcnN0IHJldmlldyB3YXMgdGhhdDoN Cg0K4oCc4oCdIg0KVGhpcyBpcyBhY3R1YWxseSBieSBkZXNpZ24sIGFzIHRoZXJlIGlzIGFsd2F5 cyB0aGUgaXNzdWUgZm9yIGxlYXZpbmcgZmxleGliaWxpdHkgZm9yIGltcGxlbWVudGF0aW9ucyAo SSBrbm93LCB0aGlzIGZsZXhpYmlsaXR5IGNhbiBiZSBhdCBvZGRzIHdpdGggZWFzZS1vZi11c2Up IGJ1dCB3ZSBzaGFsbCByZXZpZXcgdGhpcy4gDQrigJzigJ3igJ0NCg0KIEkgYWdyZWUgdGhhdCB0 aGlzIGlzIGEgcmVhc29uYWJsZSB0cmFkZW9mZiwgYW5kIGFtIGZpbmUgd2l0aCBsZWF2aW5nIGl0 IGFzIGlzLg0KDQo+IDQuDQo+IA0KPiAgICAgICBsZWFmLWxpc3Qgcm91dGVyLWlkIHsNCj4gICAg ICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOw0KPiAgICAgICAgICAgZGVzY3JpcHRpb24NCj4g ICAgICAgICAgICAgIlJvdXRlci1pZCBmb3IgdGhlIG5vZGUiOw0KPiAgICAgICAgIH0NCj4gDQo+ IFdlIGRvbid0IHdhbnQgdG8gd2FpdCBmb3INCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRnd2ctcm91dGluZy10eXBlcy0wMCAoYnR3LCB3ZQ0KPiBzaG91bGQgZXhw ZWRpdGUgdGhpcyBwdWJsaWNhdGlvbiksIGJ1dCBhbnkgZ29vZCByZWFzb24gd2h5DQo+IHRoaXMg aXMgYWxpZ25lZCB3aXRoIGl0cyBkZWZpbml0aW9uPw0KPiAgICB0eXBlZGVmIHJvdXRlci1pZCB7 DQo+ICAgICAgIHR5cGUgeWFuZzpkb3R0ZWQtcXVhZDsNCj4gICAgICAgZGVzY3JpcHRpb24NCj4g ICAgICAgICAiQSAzMi1iaXQgbnVtYmVyIGluIHRoZSBkb3R0ZWQgcXVhZCBmb3JtYXQgYXNzaWdu ZWQgdG8gZWFjaA0KPiAgICAgICAgICByb3V0ZXIuIFRoaXMgbnVtYmVyIHVuaXF1ZWx5IGlkZW50 aWZpZXMgdGhlIHJvdXRlciB3aXRoaW4gYW4NCj4gICAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0u IjsNCj4gICAgIH0NCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IC0gWUFORyBkZWZpbml0aW9uICJZQU5HOiBBIGRhdGEgZGVmaW5pdGlv biBsYW5ndWFnZSBmb3IgTkVUQ09ORiINCj4gSSB3b3VsZCB1c2U6DQo+ICAgWUFORyBpcyBhIGRh dGEgbW9kZWxpbmcgbGFuZ3VhZ2UgdXNlZCB0byBtb2RlbCBjb25maWd1cmF0aW9uIGRhdGEsDQo+ ICAgc3RhdGUgZGF0YSwgUmVtb3RlIFByb2NlZHVyZSBDYWxscywgYW5kIG5vdGlmaWNhdGlvbnMg Zm9yIG5ldHdvcmsNCj4gICBtYW5hZ2VtZW50IHByb3RvY29scyBbUkZDNzk1MF0NCj4gDQo+IC0g VGhlcmUgYXJlIG11bHRpcGxlIHNsaWdodGx5IGRpZmZlcmVudCBkZWZpbml0aW9ucyBvZiB0aGUg ZGF0YXN0b3JlIGluDQo+IHRoZSBkaWZmZXJlbnQgUkZDcy4NCj4gTGV0J3Mgbm90IGFkZCB0byB0 aGUgY29uZnVzaW9uLg0KPiBQaWNrIG9uZSAoUkZDNjI0MSBzaG91bGQgYmUgdGhlIGxhdGVzdCBv bmUpIGFuZCBtZW50aW9uIHRoZSByZWZlcmVuY2UuDQo+IA0KPiAtIEluc3RlYWQgb2Y6DQo+IA0K PiAgIEJyYWNrZXRzDQo+ICAgZW5jbG9zZSBsaXN0IGtleXMsICJydyIgbWVhbnMgY29uZmlndXJh dGlvbiwgInJvIiBvcGVyYXRpb25hbCBzdGF0ZQ0KPiAgIGRhdGEsICI/IiBkZXNpZ25hdGVzIG9w dGlvbmFsIG5vZGVzLCAiKiIgZGVzaWduYXRlcyBub2RlcyB0aGF0IGNhbg0KPiAgIGhhdmUgbXVs dGlwbGUgaW5zdGFuY2VzLiAgUGFyYW50aGVzZXMgZW5jbG9zZSBjaG9pY2UgYW5kIGNhc2Ugbm9k ZXMuDQo+IA0KPiBVc2UgdGhlIGN1dC9wYXN0ZSBmcm9tIFJGQzgwMjIgYW5kDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTA5XQ0KPiAN Cj4gICBvICBCcmFja2V0cyAiWyIgYW5kICJdIiBlbmNsb3NlIGxpc3Qga2V5cy4NCj4gDQo+ICAg byAgQ3VybHkgYnJhY2VzICJ7IiBhbmQgIn0iIGNvbnRhaW4gbmFtZXMgb2Ygb3B0aW9uYWwgZmVh dHVyZXMgdGhhdA0KPiAgICAgIG1ha2UgdGhlIGNvcnJlc3BvbmRpbmcgbm9kZSBjb25kaXRpb25h bC4NCj4gDQo+ICAgbyAgQWJicmV2aWF0aW9ucyBiZWZvcmUgZGF0YSBub2RlIG5hbWVzOiAicnci IG1lYW5zIGNvbmZpZ3VyYXRpb24NCj4gICAgICAocmVhZC13cml0ZSksICJybyIgc3RhdGUgZGF0 YSAocmVhZC1vbmx5KSwgIi14IiBSUEMgb3BlcmF0aW9ucyBvcg0KPiAgICAgIGFjdGlvbnMsIGFu ZCAiLW4iIG5vdGlmaWNhdGlvbnMuDQo+IA0KPiAgIG8gIFN5bWJvbHMgYWZ0ZXIgZGF0YSBub2Rl IG5hbWVzOiAiPyIgbWVhbnMgYW4gb3B0aW9uYWwgbm9kZSwgIiEiIGENCj4gICAgICBjb250YWlu ZXIgd2l0aCBwcmVzZW5jZSwgYW5kICIqIiBkZW5vdGVzIGEgImxpc3QiIG9yICJsZWFmLWxpc3Qi Lg0KPiANCj4gICBvICBQYXJlbnRoZXNlcyBlbmNsb3NlIGNob2ljZSBhbmQgY2FzZSBub2Rlcywg YW5kIGNhc2Ugbm9kZXMgYXJlDQo+IGFsc28NCj4gICAgICBtYXJrZWQgd2l0aCBhIGNvbG9uICgi OiIpLg0KPiANCj4gICBvICBFbGxpcHNpcyAoIi4uLiIpIHN0YW5kcyBmb3IgY29udGVudHMgb2Yg c3VidHJlZXMgdGhhdCBhcmUgbm90DQo+ICAgICAgc2hvd24uDQo+IA0KPiBCdHcsIG5vIG5lZWQg dG8gcmVwZWF0IHRoaXMgY29udmVudGlvbiBpbiBzZWN0aW9uIDYuMS4xIGFuZCA2LjIuMQ0KPiAN Cj4gLSBJIGFncmVlIHdpdGggU3VyZXNoOiAiT1NQRiBhbmQgSVMtSVMgYXJlIHVzZWQgbGF0ZXIg aW4gdGhlIGRvY3VtZW50IGFzDQo+IGV4YW1wbGVzIGJ1dCB0aGlzIHNlY3Rpb24gKGVzcGVjaWFs bHkgRmlndXJlIDEpIHNlZW1zIHRvIHRyZWF0IHRoZW0gYXMNCj4gbW9yZSB0aGFuIGV4YW1wbGVz Ig0KPiBFaXRoZXIgbW9kaWZ5IGZpZ3VyZSAxLCBvciBldmVuIGJldHRlciwgc3RyZXNzIGluIHNl Y3Rpb24gMyB0aGF0DQo+IG9zcGYtdG9wb2xvZ3kgYW5kIGlzaXMtdG9wb2xvZ3kgYXJlIGV4YW1w bGVzLCBhbmQgZGVmaW5lZCBhcyBzdWNoIGluIHRoaXMNCj4gZG9jdW1lbnQNCj4gDQo+IC0gc2Vj dGlvbiA3DQo+IE9MRDogDQo+IFRoZSBtb29kZWwgZGVmaW5lcw0KPiBORVc6DQo+IFRoZSBtb2Rl bCBkZWZpbmVzDQo+IA0KPiANCg0K From nobody Thu Jan 19 23:19:29 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 9339B129A26; Thu, 19 Jan 2017 23:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqs-yuKuilGE; Thu, 19 Jan 2017 23:19:22 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E184212995F; Thu, 19 Jan 2017 23:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7547; q=dns/txt; s=iport; t=1484896761; x=1486106361; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=kztuwWoye5uT4YU+hdZiPBOJBX8ux+mDk6MxPBkMEUE=; b=iH8YWKn6qdPE3kAm6z4d6kr2ED6cV45S8DZ+YJdjS4GelqLbNUEvsBST aE1OTlef7sRZcOrVa9vB2p8koIKRoUWDXAOSMQQ0PAPGDYDjwdZeBLoQa p6xN7XjuMGyJJbiVelEqagU3xAAbPprHTIClANiaHTiFaDQgIG66ie9Z/ A=; X-IronPort-AV: E=Sophos;i="5.33,257,1477958400"; d="scan'208";a="651806086" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 07:19:19 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0K7JIYb016721; Fri, 20 Jan 2017 07:19:18 GMT To: "Carl Moberg (camoberg)" References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> <090DDF93-60EE-41BC-9D9A-BCDA9A96F670@cisco.com> From: Benoit Claise Message-ID: Date: Fri, 20 Jan 2017 08:19:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <090DDF93-60EE-41BC-9D9A-BCDA9A96F670@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "Ronald P. Bonica" , "i2rs-chairs@ietf.org" , The IESG , "shares@ndzh.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 20 Jan 2017 07:19:23 -0000 On 1/20/2017 7:13 AM, Carl Moberg (camoberg) wrote: > Inline below: > >> On Jan 19, 2017, at 12:23 PM, Benoit Claise (bclaise) wrote: >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-i2rs-yang-l3-topology-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> 1. The examples. >> In the AUTH48 for the RESTCONF RFC, the example YANG module discussion >> came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology >> were also discussed. Here is the feedback from one YANG doctor, from a >> couple of days ago. >> >> Look at this: >> >> module example-ietf-ospf-topology { >> ... >> namespace >> "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; >> ... >> description >> "This module defines a model for OSPF network topologies. >> Copyright (c) 2017 IETF Trust and the persons identified as >> authors of the code. >> >> >> They are using the IANA-controlled namespace w/o registering it. >> >> This module *really* looks like a proper normative module, rather than >> an >> example. They went to far in trying to mimic a real module. >> >> It is clear that we need more guidelines in 6087 for how to write >> example modules. >> >> I was going to ask if this module passed YANG doctor review - then I >> checked and saw that version -02 was reviewed, which didn't include >> this example. How should we (the YANG doctors) handle such a case? >> >> In this case they should: >> >> 1. change the name to example-ospf-topology >> 2. change the namespace to urn:example:ospf-topology >> 3. remove the top-level statements: >> organization, contact, revision >> >> 4. change the top-level description to what the text in the draft >> says: >> >> description >> "This module is intended as an example for how the >> Layer 3 Unicast topology model can be extended to cover >> OSFP topologies."; >> >> (same for the other example module) >> >> >> As I mentioned to the authors, respective chairs and AD already, we >> should follow the decision in this NETMOD email thread >> https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html >> This will hopefully resolve fast. Once settled, the examples should be >> updated. >> >> 2. The security considerations should be better aligned with >> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as >> mentioned by others. >> >> 3. Carl Moberg, as YANG doctor, reviewed v1 of the draft. >> https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html >> I'm waiting for final blessing on v8 any time soon. Hence this late >> DISCUSS. > I have re-reviewed the current (-08) draft to follow up on my remarks from -01. The only remark that has not been addressed in the draft is the following: > > “”" > 1. All data definitions are optional configuration (e.g. no config false, default values or mandatory statements). This seems to open up for many odd combinations of e.g. existing and non-existing leafs in node, link, and termination-points. This is also true for the notifications. Is this by design or something that needs additional work? > “”” > > The response from the authors (through Alex Clemm) during the first review was that: > > “”" > This is actually by design, as there is always the issue for leaving flexibility for implementations (I know, this flexibility can be at odds with ease-of-use) but we shall review this. > “”” > > I agree that this is a reasonable tradeoff, and am fine with leaving it as is. Thanks Carl. Authors, some text clarifying that all data definitions are optional configuration (e.g. no config false, default values or mandatory statements) and stressing that this is per design would be an excellent addition to the draft. Regards, Benoit > >> 4. >> >> leaf-list router-id { >> type inet:ip-address; >> description >> "Router-id for the node"; >> } >> >> We don't want to wait for >> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we >> should expedite this publication), but any good reason why >> this is aligned with its definition? >> typedef router-id { >> type yang:dotted-quad; >> description >> "A 32-bit number in the dotted quad format assigned to each >> router. This number uniquely identifies the router within an >> Autonomous System."; >> } >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - YANG definition "YANG: A data definition language for NETCONF" >> I would use: >> YANG is a data modeling language used to model configuration data, >> state data, Remote Procedure Calls, and notifications for network >> management protocols [RFC7950] >> >> - There are multiple slightly different definitions of the datastore in >> the different RFCs. >> Let's not add to the confusion. >> Pick one (RFC6241 should be the latest one) and mention the reference. >> >> - Instead of: >> >> Brackets >> enclose list keys, "rw" means configuration, "ro" operational state >> data, "?" designates optional nodes, "*" designates nodes that can >> have multiple instances. Parantheses enclose choice and case nodes. >> >> Use the cut/paste from RFC8022 and >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] >> >> o Brackets "[" and "]" enclose list keys. >> >> o Curly braces "{" and "}" contain names of optional features that >> make the corresponding node conditional. >> >> o Abbreviations before data node names: "rw" means configuration >> (read-write), "ro" state data (read-only), "-x" RPC operations or >> actions, and "-n" notifications. >> >> o Symbols after data node names: "?" means an optional node, "!" a >> container with presence, and "*" denotes a "list" or "leaf-list". >> >> o Parentheses enclose choice and case nodes, and case nodes are >> also >> marked with a colon (":"). >> >> o Ellipsis ("...") stands for contents of subtrees that are not >> shown. >> >> Btw, no need to repeat this convention in section 6.1.1 and 6.2.1 >> >> - I agree with Suresh: "OSPF and IS-IS are used later in the document as >> examples but this section (especially Figure 1) seems to treat them as >> more than examples" >> Either modify figure 1, or even better, stress in section 3 that >> ospf-topology and isis-topology are examples, and defined as such in this >> document >> >> - section 7 >> OLD: >> The moodel defines >> NEW: >> The model defines >> >> From nobody Fri Jan 20 04:02:37 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 8692C129784; Fri, 20 Jan 2017 04:02:31 -0800 (PST) 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 vLKXjnwYuFma; Fri, 20 Jan 2017 04:02:30 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97536129546; Fri, 20 Jan 2017 04:02:29 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Carl Moberg \(camoberg\)'" , "'Benoit Claise \(bclaise\)'" References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> <090DDF93-60EE-41BC-9D9A-BCDA9A96F670@cisco.com> In-Reply-To: <090DDF93-60EE-41BC-9D9A-BCDA9A96F670@cisco.com> Date: Fri, 20 Jan 2017 06:58:08 -0500 Message-ID: <003001d27314$77e93cc0$67bbb640$@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: AQHdENFUFYAkrytHh+wzPqnQK0P7bgK+WIaHoRYUHTA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, =?utf-8?Q?'Martin_Bj=C3=B6rklund'?= , draft-ietf-i2rs-yang-l3-topology@ietf.org, "'Ronald P. Bonica'" , i2rs-chairs@ietf.org, 'The IESG' Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 20 Jan 2017 12:02:31 -0000 Carl:=20 Thank you for the re-review of this YANG Model. My understanding is = that you are fine with the trade-off the authors have made to handle = this work.=20 =E2=80=9C=E2=80=9D" 1. All data definitions are optional configuration (e.g. no config = false, default values or mandatory statements). This seems to open up = for many odd combinations of e.g. existing and non-existing leafs in = node, link, and termination-points. This is also true for the = notifications. Is this by design or something that needs additional = work? Sue=20 -----Original Message----- From: Carl Moberg (camoberg) [mailto:camoberg@cisco.com]=20 Sent: Friday, January 20, 2017 1:13 AM To: Benoit Claise (bclaise) Cc: The IESG; draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com; i2rs-chairs@ietf.org; i2rs@ietf.org; Ronald P. Bonica; = Martin Bj=C3=B6rklund Subject: Re: Benoit Claise's Discuss on = draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) Inline below: > On Jan 19, 2017, at 12:23 PM, Benoit Claise (bclaise) = wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1. The examples. > In the AUTH48 for the RESTCONF RFC, the example YANG module discussion = > came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology = > were also discussed. Here is the feedback from one YANG doctor, from a = > couple of days ago. >=20 > Look at this: >=20 > module example-ietf-ospf-topology { > ... > namespace > "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; > ... > description > "This module defines a model for OSPF network topologies. > Copyright (c) 2017 IETF Trust and the persons identified as > authors of the code.=20 >=20 >=20 > They are using the IANA-controlled namespace w/o registering it. >=20 > This module *really* looks like a proper normative module, rather than = > an example. They went to far in trying to mimic a real module. >=20 > It is clear that we need more guidelines in 6087 for how to write=20 > example modules. >=20 > I was going to ask if this module passed YANG doctor review - then I=20 > checked and saw that version -02 was reviewed, which didn't include=20 > this example. How should we (the YANG doctors) handle such a case? >=20 > In this case they should: >=20 > 1. change the name to example-ospf-topology 2. change the=20 > namespace to urn:example:ospf-topology 3. remove the top-level=20 > statements: > organization, contact, revision >=20 > 4. change the top-level description to what the text in the draft > says: >=20 > description > "This module is intended as an example for how the > Layer 3 Unicast topology model can be extended to cover > OSFP topologies."; >=20 > (same for the other example module) >=20 >=20 > As I mentioned to the authors, respective chairs and AD already, we=20 > should follow the decision in this NETMOD email thread=20 > https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html > This will hopefully resolve fast. Once settled, the examples should be = > updated. >=20 > 2. The security considerations should be better aligned with=20 > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as=20 > mentioned by others. >=20 > 3. Carl Moberg, as YANG doctor, reviewed v1 of the draft. > https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.ht > ml I'm waiting for final blessing on v8 any time soon. Hence this late = > DISCUSS. I have re-reviewed the current (-08) draft to follow up on my remarks = from -01. The only remark that has not been addressed in the draft is = the following: =E2=80=9C=E2=80=9D" 1. All data definitions are optional configuration (e.g. no config = false, default values or mandatory statements). This seems to open up = for many odd combinations of e.g. existing and non-existing leafs in = node, link, and termination-points. This is also true for the = notifications. Is this by design or something that needs additional = work? =E2=80=9C=E2=80=9D=E2=80=9D The response from the authors (through Alex Clemm) during the first = review was that: =E2=80=9C=E2=80=9D" This is actually by design, as there is always the issue for leaving = flexibility for implementations (I know, this flexibility can be at odds = with ease-of-use) but we shall review this.=20 =E2=80=9C=E2=80=9D=E2=80=9D I agree that this is a reasonable tradeoff, and am fine with leaving it = as is. > 4. >=20 > leaf-list router-id { > type inet:ip-address; > description > "Router-id for the node"; > } >=20 > We don't want to wait for > https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we = > should expedite this publication), but any good reason why this is=20 > aligned with its definition? > typedef router-id { > type yang:dotted-quad; > description > "A 32-bit number in the dotted quad format assigned to each > router. This number uniquely identifies the router within an > Autonomous System."; > } >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - YANG definition "YANG: A data definition language for NETCONF" > I would use: > YANG is a data modeling language used to model configuration data, > state data, Remote Procedure Calls, and notifications for network > management protocols [RFC7950] >=20 > - There are multiple slightly different definitions of the datastore=20 > in the different RFCs. > Let's not add to the confusion. > Pick one (RFC6241 should be the latest one) and mention the reference. >=20 > - Instead of: >=20 > Brackets > enclose list keys, "rw" means configuration, "ro" operational state > data, "?" designates optional nodes, "*" designates nodes that can > have multiple instances. Parantheses enclose choice and case nodes. >=20 > Use the cut/paste from RFC8022 and > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] >=20 > o Brackets "[" and "]" enclose list keys. >=20 > o Curly braces "{" and "}" contain names of optional features that > make the corresponding node conditional. >=20 > o Abbreviations before data node names: "rw" means configuration > (read-write), "ro" state data (read-only), "-x" RPC operations or > actions, and "-n" notifications. >=20 > o Symbols after data node names: "?" means an optional node, "!" a > container with presence, and "*" denotes a "list" or "leaf-list". >=20 > o Parentheses enclose choice and case nodes, and case nodes are=20 > also > marked with a colon (":"). >=20 > o Ellipsis ("...") stands for contents of subtrees that are not > shown. >=20 > Btw, no need to repeat this convention in section 6.1.1 and 6.2.1 >=20 > - I agree with Suresh: "OSPF and IS-IS are used later in the document=20 > as examples but this section (especially Figure 1) seems to treat them = > as more than examples" > Either modify figure 1, or even better, stress in section 3 that=20 > ospf-topology and isis-topology are examples, and defined as such in=20 > this document >=20 > - section 7 > OLD:=20 > The moodel defines > NEW: > The model defines >=20 >=20 From nobody Mon Jan 23 00:39:09 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 58C43129543; Mon, 23 Jan 2017 00:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5ilAETzTS6s; Mon, 23 Jan 2017 00:39:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CF91294BA; Mon, 23 Jan 2017 00:39:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A2D8D6EC; Mon, 23 Jan 2017 09:39:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o_vdWUYJdULG; Mon, 23 Jan 2017 09:39:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 09:39:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D79B7200AA; Mon, 23 Jan 2017 09:39:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jV2dDHAOPzCW; Mon, 23 Jan 2017 09:39:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED732200A7; Mon, 23 Jan 2017 09:39:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3DFA33E46146; Mon, 23 Jan 2017 09:39:05 +0100 (CET) Date: Mon, 23 Jan 2017 09:39:04 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123083903.GB29022@elstar.local> Mail-Followup-To: Susan Hares , 'Kathleen Moriarty' , 'The IESG' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036401d2727f$fc114910$f433db30$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:39:08 -0000 Susan, I consider tagging a YANG object statically and universally in the data model as "does not need secure communication" fundamentally flawed; I am not having an issue with insecure communication in certain deployment contexts. The topology drafts are regular generic YANG models that just happen to be done in I2RS - I believe that using the generic YANG security guidelines we have is good enough to progress these drafts. /js On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > Juergen: > > I recognize that dislike insecure communication. You made a similar comment > during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG > and approved by the IESG for RFC publication and it contains the non-secure > communication. The mandate from the I2RS WG for this shepherd/co-chair is > clear. > > As the shepherd for the topology drafts, I try to write-up something that > might address Kathleen's Moriarty's concerns about the topology draft's > security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be written for > a specific non-secure transport plain broken. There is hardly any content of > a data model I can think of which is generally suitable for insecure > transports. > > Can we please kill this idea of _standardizing_ information that is suitable > to send over non-secure transports? I really do not see how the IETF can > make a claim that a given piece of information is never worth protecting (= > suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of the > _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data store > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Security > Considerations sections. I would appreciate if Benoit or you hold a discuss > until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alissa's comment that the YANG module security consideration > section guidelines need to be followed and this shouldn't go forward until > that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 03:08:43 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 0EAB4129B15; Mon, 23 Jan 2017 03:08:42 -0800 (PST) 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 78BgHZiV7U-x; Mon, 23 Jan 2017 03:08:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD4712956B; Mon, 23 Jan 2017 03:08:40 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> In-Reply-To: <20170123083903.GB29022@elstar.local> Date: Mon, 23 Jan 2017 06:04:28 -0500 Message-ID: <01ee01d27568$784b6020$68e22060$@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: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+oLAD6IA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:08:42 -0000 Juergen: Let's focus on your second point. The topology drafts are I2RS drafts designed for the I2RS ephemeral control plane data store. How can these be generic YANG modules when the following is true: 1) I2RS Data models do not utilize the configuration data store, 2) I2RS Data Models do not require the same validation as configuration data store, 3) I2RS Data models require the use of priority to handle the multi-write contention problem into the I2RS Control Plane data store, 4) I2RS require TLS with X.509v3 over TCP for the mandatory-to-implement transport, Do you disagree with draft-ietf-netmod-revised-datastores? If so, the discussion should be taken up with netmod WG list. Do you disagree with i2rs-protocol-security-requirements? That issue is closed based on IESG approval. Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, January 23, 2017 3:39 AM To: Susan Hares Cc: 'Kathleen Moriarty'; 'The IESG'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Susan, I consider tagging a YANG object statically and universally in the data model as "does not need secure communication" fundamentally flawed; I am not having an issue with insecure communication in certain deployment contexts. The topology drafts are regular generic YANG models that just happen to be done in I2RS - I believe that using the generic YANG security guidelines we have is good enough to progress these drafts. /js On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > Juergen: > > I recognize that dislike insecure communication. You made a similar > comment during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS > WG and approved by the IESG for RFC publication and it contains the > non-secure communication. The mandate from the I2RS WG for this > shepherd/co-chair is clear. > > As the shepherd for the topology drafts, I try to write-up something > that might address Kathleen's Moriarty's concerns about the topology > draft's security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be > written for a specific non-secure transport plain broken. There is > hardly any content of a data model I can think of which is generally > suitable for insecure transports. > > Can we please kill this idea of _standardizing_ information that is > suitable to send over non-secure transports? I really do not see how > the IETF can make a claim that a given piece of information is never > worth protecting (= suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of > the _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG > > modules > which are designed to exist in the I2RS Ephemeral Control Plane data store > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM > > ADs, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model > (L3) and the base I2RS topology model should both provide updated YANG > Security Considerations sections. I would appreciate if Benoit or you > hold a discuss until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > I agree with Alissa's comment that the YANG module security > > consideration > section guidelines need to be followed and this shouldn't go forward > until that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 03:29:10 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 6B4711295DC; Mon, 23 Jan 2017 03:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb-P-KZyUPv8; Mon, 23 Jan 2017 03:29:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C921295DF; Mon, 23 Jan 2017 03:29:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4FA4877E; Mon, 23 Jan 2017 12:29:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id euYyn7gU_TpR; Mon, 23 Jan 2017 12:29:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 12:29:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43D69200A8; Mon, 23 Jan 2017 12:29:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kDAqevKPfWiS; Mon, 23 Jan 2017 12:29:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F846200A7; Mon, 23 Jan 2017 12:29:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 570B33E468DF; Mon, 23 Jan 2017 12:29:05 +0100 (CET) Date: Mon, 23 Jan 2017 12:29:05 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123112904.GA29980@elstar.local> Mail-Followup-To: Susan Hares , 'Kathleen Moriarty' , 'The IESG' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01d27568$784b6020$68e22060$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 11:29:09 -0000 I thought the topology models are coming more or less from OpenDaylight. If so, is ODL and I2RS implementation? /js On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: > Juergen: > > Let's focus on your second point. The topology drafts are I2RS drafts > designed for the I2RS ephemeral control plane data store. How can these be > generic YANG modules when the following is true: > > 1) I2RS Data models do not utilize the configuration data store, > 2) I2RS Data Models do not require the same validation as configuration data > store, > 3) I2RS Data models require the use of priority to handle the multi-write > contention problem into the I2RS Control Plane data store, > 4) I2RS require TLS with X.509v3 over TCP for the mandatory-to-implement > transport, > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, the > discussion should be taken up with netmod WG list. > Do you disagree with i2rs-protocol-security-requirements? That issue is > closed based on IESG approval. > > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 23, 2017 3:39 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Susan, > > I consider tagging a YANG object statically and universally in the data > model as "does not need secure communication" fundamentally flawed; I am not > having an issue with insecure communication in certain deployment contexts. > > The topology drafts are regular generic YANG models that just happen to be > done in I2RS - I believe that using the generic YANG security guidelines we > have is good enough to progress these drafts. > > /js > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > Juergen: > > > > I recognize that dislike insecure communication. You made a similar > > comment during the WG LC and IETF review of > > draft-ietf-i2rs-protocol-security-requirements. However, the > > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS > > WG and approved by the IESG for RFC publication and it contains the > > non-secure communication. The mandate from the I2RS WG for this > > shepherd/co-chair is clear. > > > > As the shepherd for the topology drafts, I try to write-up something > > that might address Kathleen's Moriarty's concerns about the topology > > draft's security issues about privacy and the I2RS ephemeral control plane > data > > store. I welcome an open discussion on my ideas > > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > > yang doctor's YANG security consideration template > > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > > privacy related RFCs (RFC6973) note that some information is sensitive. > > Hopefully, this document extends these guidelines to a new data store. > > > > Cheerily, > > Sue Hares > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, January 19, 2017 10:34 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > For what it is worth, I find the notion that data models may be > > written for a specific non-secure transport plain broken. There is > > hardly any content of a data model I can think of which is generally > > suitable for insecure transports. > > > > Can we please kill this idea of _standardizing_ information that is > > suitable to send over non-secure transports? I really do not see how > > the IETF can make a claim that a given piece of information is never > > worth protecting (= suitable for non-secure transports). > > > > Note that I am fine if in a certain trusted tightly-coupled deployment > > information is shipped in whatever way but this is then a property of > > the _deployment_ and not a property of the _information_. > > > > /js > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > Kathleen: > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > modules > > which are designed to exist in the I2RS Ephemeral Control Plane data store > > (configuration and operational state). > > > > > > Draft location: > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > > > I would appreciate an email discussion with the security ADs, OPS/NM > > > ADs, > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model > > (L3) and the base I2RS topology model should both provide updated YANG > > Security Considerations sections. I would appreciate if Benoit or you > > hold a discuss until we sort out these issues. > > > > > > Thank you, > > > > > > Sue > > > > > > -----Original Message----- > > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > To: The IESG > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > > Subject: Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Kathleen Moriarty has entered the following ballot position for > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > I agree with Alissa's comment that the YANG module security > > > consideration > > section guidelines need to be followed and this shouldn't go forward > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 03:45: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 AD3571295E4; Mon, 23 Jan 2017 03:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAtaPJhoKor3; Mon, 23 Jan 2017 03:45:13 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 D53D51295DF; Mon, 23 Jan 2017 03:45:12 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id r126so25787709wmr.3; Mon, 23 Jan 2017 03:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LfrIy/5NmqVhV8eBRMW640ieGTtG+K0illncr5oMwoY=; b=Zj57s9EbjSiCaUoRF+yURYy0zwA60jDlwz3GLfsYpJ4aSWx0kxgs983/D/ou83tMJS Km6kefElHZQRP30gVY2wox9yiucNe5eZP0/E6LzUY1j7qelLHvyArgCqSsJAMqp+0GFi eHUKUpp9BqE3+liS/4LhlgkxxUmLlQyow8dTrjvAWQ2irkItW3BDiDRQT0me4wT6Fy2n NhMw6C/5jyDDrcIovxB3smNs9h/ZPAHsASkHSMyM9TUJAkktErt4cshJIkmKRZ3ugQwl kAUgeu3niJZjDPUrdPqlZLX45uXp7ohSui2yQP5dDZVGPn9EFYPi54c1GXwQIeZanT3H ZZVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LfrIy/5NmqVhV8eBRMW640ieGTtG+K0illncr5oMwoY=; b=mWvAnVudv+w15AnNozx+RvJ5M5wu4NVOJ/42qpXNJ7D50yhhsi4p+nbFXkyGggQFZj aXKwahrN1L15PcrZ8IGay9dsZ21wsDCEGWIyv9P5k5STKp3haNo60bd8XYTdOlJAJ5Dy aWHvLWva/UtIPpJ5yT1Pof8wQ6E9WwB1pvFugvKJzE2uyBGkDIw+dpzrJzFkdMf3p54K oJSORO1j/R7uyHw4e2cQWWx0CIM889xHAtPlfyzAdkbNQ+t57qmwvsl9zHGOatbeIK4w i/QFflN757q+6mOTiGgDblfidr+bBXYZAdoXY5WxTIVeVglLXscUSrYVrBufE8MkEJ4h CaRA== X-Gm-Message-State: AIkVDXJwQ4P3ooiXgulSjsQA/GveUZ6lAW8akQaOjC1KQTbWs3n44GLsG5y+7maDkbGPrQ== X-Received: by 10.223.169.140 with SMTP id b12mr23500453wrd.138.1485171911281; Mon, 23 Jan 2017 03:45:11 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.40]) by smtp.gmail.com with ESMTPSA id k70sm2231270wmc.3.2017.01.23.03.45.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 03:45:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: <20170123112904.GA29980@elstar.local> Date: Mon, 23 Jan 2017 11:45:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3259) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG , Susan Hares Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:45:14 -0000 ODL does, indeed, implement the topology models, but generally the data = in the topology model is operational data, so I=E2=80=99m not sure how = that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making validation, priority etc. non-issues). > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = wrote: >=20 > I thought the topology models are coming more or less from > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > /js >=20 > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> Juergen:=20 >>=20 >> Let's focus on your second point. The topology drafts are I2RS = drafts >> designed for the I2RS ephemeral control plane data store. How can = these be >> generic YANG modules when the following is true:=20 >>=20 >> 1) I2RS Data models do not utilize the configuration data store,=20 >> 2) I2RS Data Models do not require the same validation as = configuration data >> store,=20 >> 3) I2RS Data models require the use of priority to handle the = multi-write >> contention problem into the I2RS Control Plane data store,=20 >> 4) I2RS require TLS with X.509v3 over TCP for the = mandatory-to-implement >> transport,=20 >>=20 >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, = the >> discussion should be taken up with netmod WG list. =20 >> Do you disagree with i2rs-protocol-security-requirements? That issue = is >> closed based on IESG approval.=20 >>=20 >> Sue Hares=20 >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 >> Sent: Monday, January 23, 2017 3:39 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> Susan, >>=20 >> I consider tagging a YANG object statically and universally in the = data >> model as "does not need secure communication" fundamentally flawed; I = am not >> having an issue with insecure communication in certain deployment = contexts. >>=20 >> The topology drafts are regular generic YANG models that just happen = to be >> done in I2RS - I believe that using the generic YANG security = guidelines we >> have is good enough to progress these drafts. >>=20 >> /js >>=20 >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> I recognize that dislike insecure communication. You made a similar=20= >>> comment during the WG LC and IETF review of=20 >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>> draft-ietf-i2rs-protocol-security-requirements were passed by the = I2RS=20 >>> WG and approved by the IESG for RFC publication and it contains the=20= >>> non-secure communication. The mandate from the I2RS WG for this=20 >>> shepherd/co-chair is clear. >>>=20 >>> As the shepherd for the topology drafts, I try to write-up something=20= >>> that might address Kathleen's Moriarty's concerns about the topology=20= >>> draft's security issues about privacy and the I2RS ephemeral control = plane >> data >>> store. I welcome an open discussion on my ideas >>> = (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >> The >>> yang doctor's YANG security consideration template >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and = the=20 >>> privacy related RFCs (RFC6973) note that some information is = sensitive. >>> Hopefully, this document extends these guidelines to a new data = store.=20 >>>=20 >>> Cheerily, >>> Sue Hares >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder=20 >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, January 19, 2017 10:34 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG'; >>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> For what it is worth, I find the notion that data models may be=20 >>> written for a specific non-secure transport plain broken. There is=20= >>> hardly any content of a data model I can think of which is generally=20= >>> suitable for insecure transports. >>>=20 >>> Can we please kill this idea of _standardizing_ information that is=20= >>> suitable to send over non-secure transports? I really do not see how=20= >>> the IETF can make a claim that a given piece of information is never=20= >>> worth protecting (=3D suitable for non-secure transports). >>>=20 >>> Note that I am fine if in a certain trusted tightly-coupled = deployment=20 >>> information is shipped in whatever way but this is then a property = of=20 >>> the _deployment_ and not a property of the _information_. >>>=20 >>> /js >>>=20 >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>> Kathleen:=20 >>>>=20 >>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>> modules >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >>> (configuration and operational state). =20 >>>>=20 >>>> Draft location:=20 >>>> = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ >>>>=20 >>>> I would appreciate an email discussion with the security ADs, = OPS/NM=20 >>>> ADs, >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model=20= >>> (L3) and the base I2RS topology model should both provide updated = YANG=20 >>> Security Considerations sections. I would appreciate if Benoit or = you=20 >>> hold a discuss until we sort out these issues. >>>>=20 >>>> Thank you, >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] >>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>> To: The IESG >>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com;=20 >>>> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>>> Subject: Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to=20= >>>> all email addresses included in the To and CC lines. (Feel free to=20= >>>> cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>=20 >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >>>> -- >>>> COMMENT: >>>> = -------------------------------------------------------------------- >>>> -- >>>>=20 >>>> I agree with Alissa's comment that the YANG module security=20 >>>> consideration >>> section guidelines need to be followed and this shouldn't go forward=20= >>> until that is corrected. I'm told it will be, thanks. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jan 23 03:46:59 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 4A4461295E4; Mon, 23 Jan 2017 03:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChjRuw4SVvW0; Mon, 23 Jan 2017 03:46:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 244531295BB; Mon, 23 Jan 2017 03:46:56 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 583991AE0285; Mon, 23 Jan 2017 12:46:54 +0100 (CET) Date: Mon, 23 Jan 2017 12:46:52 +0100 (CET) Message-Id: <20170123.124652.536050993360637393.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <01ee01d27568$784b6020$68e22060$@ndzh.com> References: <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:46:58 -0000 Hi, "Susan Hares" wrote: > Juergen: > > Let's focus on your second point. The topology drafts are I2RS drafts > designed for the I2RS ephemeral control plane data store. How can these be > generic YANG modules when the following is true: > > 1) I2RS Data models do not utilize the configuration data store, This was not clear to me. I note that the data model's nodes are "config true", and that "The YANG module defined in this memo is designed to be accessed via the NETCONF protocol". If it is true that these data models do not utilize the configuration data stores, what does the "server-provided" leaf, and the text about "client-configured" in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? If in fact this is correct, I think it would be helpful if a note was added to the YANG modules, that explains that these models are not supposed to be implemented in the same way as other "config true" data models. In the best of worlds it would also describe how they are supposed to be implemented (but I assume that this is up to each vendor for now). I also note that it is not clear how such models would be advertised by a NETCONF server. /martin > 2) I2RS Data Models do not require the same validation as configuration data > store, > 3) I2RS Data models require the use of priority to handle the multi-write > contention problem into the I2RS Control Plane data store, > 4) I2RS require TLS with X.509v3 over TCP for the mandatory-to-implement > transport, > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, the > discussion should be taken up with netmod WG list. > Do you disagree with i2rs-protocol-security-requirements? That issue is > closed based on IESG approval. > > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 23, 2017 3:39 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Susan, > > I consider tagging a YANG object statically and universally in the data > model as "does not need secure communication" fundamentally flawed; I am not > having an issue with insecure communication in certain deployment contexts. > > The topology drafts are regular generic YANG models that just happen to be > done in I2RS - I believe that using the generic YANG security guidelines we > have is good enough to progress these drafts. > > /js > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > Juergen: > > > > I recognize that dislike insecure communication. You made a similar > > comment during the WG LC and IETF review of > > draft-ietf-i2rs-protocol-security-requirements. However, the > > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS > > WG and approved by the IESG for RFC publication and it contains the > > non-secure communication. The mandate from the I2RS WG for this > > shepherd/co-chair is clear. > > > > As the shepherd for the topology drafts, I try to write-up something > > that might address Kathleen's Moriarty's concerns about the topology > > draft's security issues about privacy and the I2RS ephemeral control plane > data > > store. I welcome an open discussion on my ideas > > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > > yang doctor's YANG security consideration template > > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > > privacy related RFCs (RFC6973) note that some information is sensitive. > > Hopefully, this document extends these guidelines to a new data store. > > > > Cheerily, > > Sue Hares > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, January 19, 2017 10:34 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > For what it is worth, I find the notion that data models may be > > written for a specific non-secure transport plain broken. There is > > hardly any content of a data model I can think of which is generally > > suitable for insecure transports. > > > > Can we please kill this idea of _standardizing_ information that is > > suitable to send over non-secure transports? I really do not see how > > the IETF can make a claim that a given piece of information is never > > worth protecting (= suitable for non-secure transports). > > > > Note that I am fine if in a certain trusted tightly-coupled deployment > > information is shipped in whatever way but this is then a property of > > the _deployment_ and not a property of the _information_. > > > > /js > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > Kathleen: > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > modules > > which are designed to exist in the I2RS Ephemeral Control Plane data store > > (configuration and operational state). > > > > > > Draft location: > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > > > I would appreciate an email discussion with the security ADs, OPS/NM > > > ADs, > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model > > (L3) and the base I2RS topology model should both provide updated YANG > > Security Considerations sections. I would appreciate if Benoit or you > > hold a discuss until we sort out these issues. > > > > > > Thank you, > > > > > > Sue > > > > > > -----Original Message----- > > > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > To: The IESG > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > > Subject: Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Kathleen Moriarty has entered the following ballot position for > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > I agree with Alissa's comment that the YANG module security > > > consideration > > section guidelines need to be followed and this shouldn't go forward > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jan 23 03:49: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 DB0E01295BB; Mon, 23 Jan 2017 03:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBT4JFdnqSRc; Mon, 23 Jan 2017 03:49:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD4BA1270B4; Mon, 23 Jan 2017 03:49:29 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 9BDD21AE0285; Mon, 23 Jan 2017 12:49:28 +0100 (CET) Date: Mon, 23 Jan 2017 12:49:27 +0100 (CET) Message-Id: <20170123.124927.1981323175493127948.mbj@tail-f.com> To: giles.heron@gmail.com From: Martin Bjorklund In-Reply-To: References: <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:49:32 -0000 R2lsZXMgSGVyb24gPGdpbGVzLmhlcm9uQGdtYWlsLmNvbT4gd3JvdGU6DQo+IE9ETCBkb2VzLCBp bmRlZWQsIGltcGxlbWVudCB0aGUgdG9wb2xvZ3kgbW9kZWxzLCBidXQgZ2VuZXJhbGx5IHRoZQ0K PiBkYXRhIGluIHRoZSB0b3BvbG9neSBtb2RlbCBpcyBvcGVyYXRpb25hbCBkYXRhDQoNCkhtbSwg YWxtb3N0IHRoZSBlbnRpcmUgdHJlZSBpcyBkZWZpbmVkIGFzICJjb25maWcgdHJ1ZSIuICBUaGVy ZSBhcmUNCmp1c3QgYSBmZXcgImNvbmZpZyBmYWxzZSIgbGVhZnMuDQoNCj4sIHNvIEnigJltIG5v dCBzdXJlIGhvdw0KPiB0aGF0IGZpdHMgd2l0aCDigJxkZXNpZ25lZCBmb3IgdGhlIEkyUlMgZXBo ZW1lcmFsIGNvbnRyb2wgcGxhbmUgZGF0YQ0KPiBzdG9yZeKAnSAtIHNpbmNlIHVzZXJzIGRvbuKA mXQgd3JpdGUgdG8gdGhlIG1vZGVscyBkaXJlY3RseSAobWFraW5nDQo+IHZhbGlkYXRpb24sIHBy aW9yaXR5IGV0Yy4gbm9uLWlzc3VlcykuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+ID4gT24gMjMg SmFuIDIwMTcsIGF0IDExOjI5LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiANCj4gPiBJIHRob3VnaHQg dGhlIHRvcG9sb2d5IG1vZGVscyBhcmUgY29taW5nIG1vcmUgb3IgbGVzcyBmcm9tDQo+ID4gT3Bl bkRheWxpZ2h0LiBJZiBzbywgaXMgT0RMIGFuZCBJMlJTIGltcGxlbWVudGF0aW9uPw0KPiA+IA0K PiA+IC9qcw0KPiA+IA0KPiA+IE9uIE1vbiwgSmFuIDIzLCAyMDE3IGF0IDA2OjA0OjI4QU0gLTA1 MDAsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPiA+PiBKdWVyZ2VuOiANCj4gPj4gDQo+ID4+IExldCdz IGZvY3VzIG9uIHlvdXIgc2Vjb25kIHBvaW50LiAgVGhlIHRvcG9sb2d5IGRyYWZ0cyBhcmUgSTJS UyBkcmFmdHMNCj4gPj4gZGVzaWduZWQgZm9yIHRoZSBJMlJTIGVwaGVtZXJhbCBjb250cm9sIHBs YW5lIGRhdGEgc3RvcmUuICBIb3cgY2FuDQo+ID4+IHRoZXNlIGJlDQo+ID4+IGdlbmVyaWMgWUFO RyBtb2R1bGVzIHdoZW4gdGhlIGZvbGxvd2luZyBpcyB0cnVlOiANCj4gPj4gDQo+ID4+IDEpIEky UlMgRGF0YSBtb2RlbHMgZG8gbm90IHV0aWxpemUgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBzdG9y ZSwgDQo+ID4+IDIpIEkyUlMgRGF0YSBNb2RlbHMgZG8gbm90IHJlcXVpcmUgdGhlIHNhbWUgdmFs aWRhdGlvbiBhcw0KPiA+PiBjb25maWd1cmF0aW9uIGRhdGENCj4gPj4gc3RvcmUsIA0KPiA+PiAz KSBJMlJTIERhdGEgbW9kZWxzIHJlcXVpcmUgdGhlIHVzZSBvZiBwcmlvcml0eSB0byBoYW5kbGUg dGhlDQo+ID4+IG11bHRpLXdyaXRlDQo+ID4+IGNvbnRlbnRpb24gcHJvYmxlbSBpbnRvIHRoZSBJ MlJTIENvbnRyb2wgUGxhbmUgZGF0YSBzdG9yZSwgDQo+ID4+IDQpIEkyUlMgcmVxdWlyZSBUTFMg d2l0aCBYLjUwOXYzIG92ZXIgVENQIGZvciB0aGUNCj4gPj4gbWFuZGF0b3J5LXRvLWltcGxlbWVu dA0KPiA+PiB0cmFuc3BvcnQsIA0KPiA+PiANCj4gPj4gRG8geW91IGRpc2FncmVlIHdpdGggZHJh ZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzPyAgSWYgc28sIHRoZQ0KPiA+PiBkaXNj dXNzaW9uIHNob3VsZCBiZSB0YWtlbiB1cCB3aXRoIG5ldG1vZCBXRyBsaXN0LiAgDQo+ID4+IERv IHlvdSBkaXNhZ3JlZSB3aXRoIGkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzPyAg VGhhdCBpc3N1ZQ0KPiA+PiBpcw0KPiA+PiBjbG9zZWQgYmFzZWQgb24gSUVTRyBhcHByb3ZhbC4g DQo+ID4+IA0KPiA+PiBTdWUgSGFyZXMgDQo+ID4+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPj4gW21haWx0bzpq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+ID4+IFNlbnQ6IE1vbmRheSwg SmFudWFyeSAyMywgMjAxNyAzOjM5IEFNDQo+ID4+IFRvOiBTdXNhbiBIYXJlcw0KPiA+PiBDYzog J0thdGhsZWVuIE1vcmlhcnR5JzsgJ1RoZSBJRVNHJzsNCj4gPj4gZHJhZnQtaWV0Zi1pMnJzLXlh bmctbDMtdG9wb2xvZ3lAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7DQo+ID4+IGkycnMtY2hhaXJz QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbaTJyc10gS2F0aGxlZW4gTW9yaWFydHkncyBO byBPYmplY3Rpb24gb24NCj4gPj4gZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3ktMDg6 ICh3aXRoIENPTU1FTlQpDQo+ID4+IA0KPiA+PiBTdXNhbiwNCj4gPj4gDQo+ID4+IEkgY29uc2lk ZXIgdGFnZ2luZyBhIFlBTkcgb2JqZWN0IHN0YXRpY2FsbHkgYW5kIHVuaXZlcnNhbGx5IGluIHRo ZQ0KPiA+PiBkYXRhDQo+ID4+IG1vZGVsIGFzICJkb2VzIG5vdCBuZWVkIHNlY3VyZSBjb21tdW5p Y2F0aW9uIiBmdW5kYW1lbnRhbGx5IGZsYXdlZDsgSQ0KPiA+PiBhbSBub3QNCj4gPj4gaGF2aW5n IGFuIGlzc3VlIHdpdGggaW5zZWN1cmUgY29tbXVuaWNhdGlvbiBpbiBjZXJ0YWluIGRlcGxveW1l bnQNCj4gPj4gY29udGV4dHMuDQo+ID4+IA0KPiA+PiBUaGUgdG9wb2xvZ3kgZHJhZnRzIGFyZSBy ZWd1bGFyIGdlbmVyaWMgWUFORyBtb2RlbHMgdGhhdCBqdXN0IGhhcHBlbg0KPiA+PiB0byBiZQ0K PiA+PiBkb25lIGluIEkyUlMgLSBJIGJlbGlldmUgdGhhdCB1c2luZyB0aGUgZ2VuZXJpYyBZQU5H IHNlY3VyaXR5DQo+ID4+IGd1aWRlbGluZXMgd2UNCj4gPj4gaGF2ZSBpcyBnb29kIGVub3VnaCB0 byBwcm9ncmVzcyB0aGVzZSBkcmFmdHMuDQo+ID4+IA0KPiA+PiAvanMNCj4gPj4gDQo+ID4+IE9u IFRodSwgSmFuIDE5LCAyMDE3IGF0IDAxOjE1OjE1UE0gLTA1MDAsIFN1c2FuIEhhcmVzIHdyb3Rl Og0KPiA+Pj4gSnVlcmdlbjogDQo+ID4+PiANCj4gPj4+IEkgcmVjb2duaXplIHRoYXQgZGlzbGlr ZSBpbnNlY3VyZSBjb21tdW5pY2F0aW9uLiAgWW91IG1hZGUgYSBzaW1pbGFyIA0KPiA+Pj4gY29t bWVudCBkdXJpbmcgdGhlIFdHIExDIGFuZCBJRVRGIHJldmlldyBvZiANCj4gPj4+IGRyYWZ0LWll dGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMuICBIb3dldmVyLCB0aGUgDQo+ ID4+PiBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzIHdlcmUg cGFzc2VkIGJ5IHRoZSBJMlJTDQo+ID4+PiBXRyBhbmQgYXBwcm92ZWQgYnkgdGhlIElFU0cgZm9y IFJGQyBwdWJsaWNhdGlvbiBhbmQgaXQgY29udGFpbnMgdGhlIA0KPiA+Pj4gbm9uLXNlY3VyZSBj b21tdW5pY2F0aW9uLiAgVGhlIG1hbmRhdGUgZnJvbSB0aGUgSTJSUyBXRyBmb3IgdGhpcyANCj4g Pj4+IHNoZXBoZXJkL2NvLWNoYWlyIGlzIGNsZWFyLg0KPiA+Pj4gDQo+ID4+PiBBcyB0aGUgc2hl cGhlcmQgZm9yIHRoZSB0b3BvbG9neSBkcmFmdHMsIEkgdHJ5IHRvIHdyaXRlLXVwIHNvbWV0aGlu ZyANCj4gPj4+IHRoYXQgbWlnaHQgYWRkcmVzcyBLYXRobGVlbidzIE1vcmlhcnR5J3MgY29uY2Vy bnMgYWJvdXQgdGhlIHRvcG9sb2d5IA0KPiA+Pj4gZHJhZnQncyBzZWN1cml0eSBpc3N1ZXMgYWJv dXQgcHJpdmFjeSBhbmQgdGhlIEkyUlMgZXBoZW1lcmFsIGNvbnRyb2wNCj4gPj4+IHBsYW5lDQo+ ID4+IGRhdGENCj4gPj4+IHN0b3JlLiAgIEkgd2VsY29tZSBhbiBvcGVuIGRpc2N1c3Npb24gb24g bXkgaWRlYXMNCj4gPj4+IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o YXJlcy1pMnJzLXlhbmctc2VjLWNvbnNpZGVyKS4NCj4gPj4gVGhlDQo+ID4+PiB5YW5nIGRvY3Rv cidzIFlBTkcgIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gdGVtcGxhdGUNCj4gPj4+IChodHRwczov L3RyYWMuaWV0Zi5vcmcvdHJhYy9vcHMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXMpIGFu ZCB0aGUNCj4gPj4+IHByaXZhY3kgcmVsYXRlZCBSRkNzIChSRkM2OTczKSBub3RlIHRoYXQgc29t ZSBpbmZvcm1hdGlvbiBpcw0KPiA+Pj4gc2Vuc2l0aXZlLg0KPiA+Pj4gSG9wZWZ1bGx5LCB0aGlz IGRvY3VtZW50IGV4dGVuZHMgdGhlc2UgZ3VpZGVsaW5lcyB0byBhIG5ldyBkYXRhIHN0b3JlLg0K PiA+Pj4gDQo+ID4+PiBDaGVlcmlseSwNCj4gPj4+IFN1ZSBIYXJlcw0KPiA+Pj4gDQo+ID4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVs ZGVyIA0KPiA+Pj4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVd DQo+ID4+PiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxOSwgMjAxNyAxMDozNCBBTQ0KPiA+Pj4g VG86IFN1c2FuIEhhcmVzDQo+ID4+PiBDYzogJ0thdGhsZWVuIE1vcmlhcnR5JzsgJ1RoZSBJRVNH JzsNCj4gPj4+IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5QGlldGYub3JnOyBpMnJz QGlldGYub3JnOyANCj4gPj4+IGkycnMtY2hhaXJzQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBS ZTogW2kycnNdIEthdGhsZWVuIE1vcmlhcnR5J3MgTm8gT2JqZWN0aW9uIG9uDQo+ID4+PiBkcmFm dC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wODogKHdpdGggQ09NTUVOVCkNCj4gPj4+IA0K PiA+Pj4gRm9yIHdoYXQgaXQgaXMgd29ydGgsIEkgZmluZCB0aGUgbm90aW9uIHRoYXQgZGF0YSBt b2RlbHMgbWF5IGJlIA0KPiA+Pj4gd3JpdHRlbiBmb3IgYSBzcGVjaWZpYyBub24tc2VjdXJlIHRy YW5zcG9ydCBwbGFpbiBicm9rZW4uIFRoZXJlIGlzIA0KPiA+Pj4gaGFyZGx5IGFueSBjb250ZW50 IG9mIGEgZGF0YSBtb2RlbCBJIGNhbiB0aGluayBvZiB3aGljaCBpcyBnZW5lcmFsbHkgDQo+ID4+ PiBzdWl0YWJsZSBmb3IgaW5zZWN1cmUgdHJhbnNwb3J0cy4NCj4gPj4+IA0KPiA+Pj4gQ2FuIHdl IHBsZWFzZSBraWxsIHRoaXMgaWRlYSBvZiBfc3RhbmRhcmRpemluZ18gaW5mb3JtYXRpb24gdGhh dCBpcyANCj4gPj4+IHN1aXRhYmxlIHRvIHNlbmQgb3ZlciBub24tc2VjdXJlIHRyYW5zcG9ydHM/ IEkgcmVhbGx5IGRvIG5vdCBzZWUgaG93IA0KPiA+Pj4gdGhlIElFVEYgY2FuIG1ha2UgYSBjbGFp bSB0aGF0IGEgZ2l2ZW4gcGllY2Ugb2YgaW5mb3JtYXRpb24gaXMgbmV2ZXIgDQo+ID4+PiB3b3J0 aCBwcm90ZWN0aW5nICg9IHN1aXRhYmxlIGZvciBub24tc2VjdXJlIHRyYW5zcG9ydHMpLg0KPiA+ Pj4gDQo+ID4+PiBOb3RlIHRoYXQgSSBhbSBmaW5lIGlmIGluIGEgY2VydGFpbiB0cnVzdGVkIHRp Z2h0bHktY291cGxlZCBkZXBsb3ltZW50DQo+ID4+PiBpbmZvcm1hdGlvbiBpcyBzaGlwcGVkIGlu IHdoYXRldmVyIHdheSBidXQgdGhpcyBpcyB0aGVuIGEgcHJvcGVydHkgb2YgDQo+ID4+PiB0aGUg X2RlcGxveW1lbnRfIGFuZCBub3QgYSBwcm9wZXJ0eSBvZiB0aGUgX2luZm9ybWF0aW9uXy4NCj4g Pj4+IA0KPiA+Pj4gL2pzDQo+ID4+PiANCj4gPj4+IE9uIFRodSwgSmFuIDE5LCAyMDE3IGF0IDA5 OjI4OjE0QU0gLTA1MDAsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPiA+Pj4+IEthdGhsZWVuOiANCj4g Pj4+PiANCj4gPj4+PiBJIGhhdmUgd3JpdHRlbiBhIGRyYWZ0IHN1Z2dlc3RpbmcgYSB0ZW1wbGF0 ZSBmb3IgdGhlIEkyUlMgWUFORyANCj4gPj4+PiBtb2R1bGVzDQo+ID4+PiB3aGljaCBhcmUgZGVz aWduZWQgdG8gZXhpc3QgaW4gdGhlIEkyUlMgRXBoZW1lcmFsIENvbnRyb2wgUGxhbmUgZGF0YQ0K PiA+Pj4gc3RvcmUNCj4gPj4+IChjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBzdGF0ZSku ICAgIA0KPiA+Pj4+IA0KPiA+Pj4+IERyYWZ0IGxvY2F0aW9uOiANCj4gPj4+PiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pMnJzLXlhbmctc2VjLWNvbnNpZGVy Lw0KPiA+Pj4+IA0KPiA+Pj4+IEkgd291bGQgYXBwcmVjaWF0ZSBhbiBlbWFpbCBkaXNjdXNzaW9u IHdpdGggdGhlIHNlY3VyaXR5IEFEcywgT1BTL05NIA0KPiA+Pj4+IEFEcywNCj4gPj4+IGFuZCBS b3V0aW5nIEFEIChBbGlhIEF0bGFzKS4gIEkgYWdyZWUgdGhhdCB0aGlzIEkyUlMgWUFORyBkYXRh IG1vZGVsIA0KPiA+Pj4gKEwzKSBhbmQgdGhlIGJhc2UgSTJSUyB0b3BvbG9neSBtb2RlbCBzaG91 bGQgYm90aCBwcm92aWRlIHVwZGF0ZWQgWUFORw0KPiA+Pj4gU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbnMuIEkgd291bGQgYXBwcmVjaWF0ZSBpZiBCZW5vaXQgb3IgeW91IA0KPiA+Pj4g aG9sZCBhIGRpc2N1c3MgdW50aWwgd2Ugc29ydCBvdXQgdGhlc2UgaXNzdWVzLg0KPiA+Pj4+IA0K PiA+Pj4+IFRoYW5rIHlvdSwNCj4gPj4+PiANCj4gPj4+PiBTdWUNCj4gPj4+PiANCj4gPj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IEthdGhsZWVuIE1vcmlhcnR5 IFttYWlsdG86S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo+ID4+Pj4gU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDE4LCAyMDE3IDk6NDQgUE0NCj4gPj4+PiBUbzogVGhlIElFU0cN Cj4gPj4+PiBDYzogZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3lAaWV0Zi5vcmc7IHNo YXJlc0BuZHpoLmNvbTsgDQo+ID4+Pj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc7IHNoYXJlc0BuZHpo LmNvbTsgaTJyc0BpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IEthdGhsZWVuIE1vcmlhcnR5J3Mg Tm8gT2JqZWN0aW9uIG9uDQo+ID4+Pj4gZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3kt MDg6ICh3aXRoIENPTU1FTlQpDQo+ID4+Pj4gDQo+ID4+Pj4gS2F0aGxlZW4gTW9yaWFydHkgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4+Pj4gZHJhZnQt aWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3ktMDg6IE5vIE9iamVjdGlvbg0KPiA+Pj4+IA0KPiA+ Pj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIA0KPiA+Pj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byANCj4gPj4+PiBjdXQgdGhpcyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4+PiANCj4gPj4+PiANCj4gPj4+PiBQbGVh c2UgcmVmZXIgdG8NCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k aXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPj4+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+Pj4+IA0KPiA+Pj4+IA0KPiA+ Pj4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8NCj4gPj4+PiANCj4gPj4+PiANCj4gPj4+ PiANCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+ID4+Pj4gQ09NTUVOVDoNCj4gPj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+ID4+Pj4gDQo+ID4+Pj4gSSBhZ3JlZSB3aXRoIEFs aXNzYSdzIGNvbW1lbnQgdGhhdCB0aGUgWUFORyBtb2R1bGUgc2VjdXJpdHkgDQo+ID4+Pj4gY29u c2lkZXJhdGlvbg0KPiA+Pj4gc2VjdGlvbiBndWlkZWxpbmVzIG5lZWQgdG8gYmUgZm9sbG93ZWQg YW5kIHRoaXMgc2hvdWxkbid0IGdvIGZvcndhcmQgDQo+ID4+PiB1bnRpbCB0aGF0IGlzIGNvcnJl Y3RlZC4gIEknbSB0b2xkIGl0IHdpbGwgYmUsIHRoYW5rcy4NCj4gPj4+PiANCj4gPj4+PiANCj4g Pj4+PiANCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+Pj4+IGkycnMgbWFpbGluZyBsaXN0DQo+ID4+Pj4gaTJyc0BpZXRmLm9yZw0KPiA+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPiA+Pj4gDQo+ ID4+PiAtLSANCj4gPj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4+PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+ID4+PiBGYXg6ICAg KzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl Lz4NCj4gPj4+IA0KPiA+PiANCj4gPj4gLS0gDQo+ID4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4+IFBob25lOiArNDkg NDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1h bnkNCj4gPj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS8+DQo+ID4+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IEp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4g UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl bWVuIHwgR2VybWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaTJycyBtYWlsaW5nIGxpc3QNCj4g PiBpMnJzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pMnJzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBpMnJzIG1haWxpbmcgbGlzdA0KPiBpMnJzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K From nobody Mon Jan 23 03:59:22 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 AC8A81295E4; Mon, 23 Jan 2017 03:59:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbATmK0rZYlM; Mon, 23 Jan 2017 03:59:15 -0800 (PST) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (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 857011270B4; Mon, 23 Jan 2017 03:59:15 -0800 (PST) Received: by mail-wj0-x242.google.com with SMTP id i7so1725881wjf.2; Mon, 23 Jan 2017 03:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3S/vLZyLGctnjurTRf8jUzzAwHhGIR4v8Qer3vMW8k=; b=aTycFG1s8TXwznvpnYJX6ZxYxas1L0kSi0EjUWg5M7xUpij45oU6+cTBXdrOWjzfSI zaEapwYl6hgpE5O4xkMJElAfHAFBM7Oj2PL6Oh6TqD31dpYKDWsD4ipJ9DQ9CxnrSOtS gSgp0MJ/g+xWaHfAvMAueFA6wgyfT2cgVFhULjPiTF+68GruYJSqy93ncnixGpRVHQd1 Cs+diTRk+4orKgiEaAGd7F8VhXqar08l6YoQGaePBXIFq01kK7UosBS35UNl2CRTIRo0 RrmUHJHPWl1CdufqfQLR9sIgolbPvJLt0ngOIneANRoBe7qw91FG13g7yF6AAJLh6BLg Jmhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3S/vLZyLGctnjurTRf8jUzzAwHhGIR4v8Qer3vMW8k=; b=KiL6sUxzWi6tEU10BW1QfN4+TpZCkOXpxXcJin2GmETncvVtO2kC1NGnQg+WVDJ1pW 7CQmqdZu5wF77ugftUXddyxvQUbw9V3ADRvXro3yAQck9hKJl+q1np6HiB5Q58/DLSlO +gPiRoB8gdyFFNKphTmhvBUTm7X5cvk5MJatHEpp2Rq0yPjU2q+cVsPoMCSMWeLM2AKL RYO360V5RwXOOBnAUjDpe9bg8XCQ8e1a3M5KuSH9dzJu3Dyuj1cFkmeaoVHNXviGPZlD ySEuxPbciY2idJIABwhWnKjMkXxUZMlztgk89UG44ul1eFaWst9u7nSsp1qIpWMy83A3 aAyA== X-Gm-Message-State: AIkVDXLktnT7tvJVdQicO9GprmT3ROieLbwkoIl4VUu7mXmERso+x/fW7my56+v6wwwDtA== X-Received: by 10.223.153.135 with SMTP id y7mr23411499wrb.55.1485172753965; Mon, 23 Jan 2017 03:59:13 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.40]) by smtp.gmail.com with ESMTPSA id c81sm20626624wmf.22.2017.01.23.03.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 03:59:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: <20170123.124927.1981323175493127948.mbj@tail-f.com> Date: Mon, 23 Jan 2017 11:59:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <20170123.124927.1981323175493127948.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3259) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:59:17 -0000 Hi Martin, > On 23 Jan 2017, at 11:49, Martin Bjorklund wrote: >=20 > Giles Heron wrote: >> ODL does, indeed, implement the topology models, but generally the >> data in the topology model is operational data >=20 > Hmm, almost the entire tree is defined as "config true". There are > just a few "config false" leafs. hence my use of the word =E2=80=9Cgenerally=E2=80=9D. there are cases where you might want to create a config topology. But = in general the topology is operational data and is created by the = protocol plugin, or a =E2=80=9Ctopology builder=E2=80=9D associated with = the plugin (e.g. the BGP linkstate topology builder creates the = linkstate topology from the linkstate RIB). If the model was config false then surely that would unnecessarily = constrain its use? Giles >> , so I=E2=80=99m not sure how >> that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data >> store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making >> validation, priority etc. non-issues). >=20 >=20 > /martin >=20 >=20 >>=20 >>> On 23 Jan 2017, at 11:29, Juergen Schoenwaelder >>> wrote: >>>=20 >>> I thought the topology models are coming more or less from >>> OpenDaylight. If so, is ODL and I2RS implementation? >>>=20 >>> /js >>>=20 >>> On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >>>> Juergen:=20 >>>>=20 >>>> Let's focus on your second point. The topology drafts are I2RS = drafts >>>> designed for the I2RS ephemeral control plane data store. How can >>>> these be >>>> generic YANG modules when the following is true:=20 >>>>=20 >>>> 1) I2RS Data models do not utilize the configuration data store,=20 >>>> 2) I2RS Data Models do not require the same validation as >>>> configuration data >>>> store,=20 >>>> 3) I2RS Data models require the use of priority to handle the >>>> multi-write >>>> contention problem into the I2RS Control Plane data store,=20 >>>> 4) I2RS require TLS with X.509v3 over TCP for the >>>> mandatory-to-implement >>>> transport,=20 >>>>=20 >>>> Do you disagree with draft-ietf-netmod-revised-datastores? If so, = the >>>> discussion should be taken up with netmod WG list. =20 >>>> Do you disagree with i2rs-protocol-security-requirements? That = issue >>>> is >>>> closed based on IESG approval.=20 >>>>=20 >>>> Sue Hares=20 >>>>=20 >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Monday, January 23, 2017 3:39 AM >>>> To: Susan Hares >>>> Cc: 'Kathleen Moriarty'; 'The IESG'; >>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; >>>> i2rs-chairs@ietf.org >>>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Susan, >>>>=20 >>>> I consider tagging a YANG object statically and universally in the >>>> data >>>> model as "does not need secure communication" fundamentally flawed; = I >>>> am not >>>> having an issue with insecure communication in certain deployment >>>> contexts. >>>>=20 >>>> The topology drafts are regular generic YANG models that just = happen >>>> to be >>>> done in I2RS - I believe that using the generic YANG security >>>> guidelines we >>>> have is good enough to progress these drafts. >>>>=20 >>>> /js >>>>=20 >>>> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>>>> Juergen:=20 >>>>>=20 >>>>> I recognize that dislike insecure communication. You made a = similar=20 >>>>> comment during the WG LC and IETF review of=20 >>>>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>>>> draft-ietf-i2rs-protocol-security-requirements were passed by the = I2RS >>>>> WG and approved by the IESG for RFC publication and it contains = the=20 >>>>> non-secure communication. The mandate from the I2RS WG for this=20= >>>>> shepherd/co-chair is clear. >>>>>=20 >>>>> As the shepherd for the topology drafts, I try to write-up = something=20 >>>>> that might address Kathleen's Moriarty's concerns about the = topology=20 >>>>> draft's security issues about privacy and the I2RS ephemeral = control >>>>> plane >>>> data >>>>> store. I welcome an open discussion on my ideas >>>>> = (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >>>> The >>>>> yang doctor's YANG security consideration template >>>>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and = the >>>>> privacy related RFCs (RFC6973) note that some information is >>>>> sensitive. >>>>> Hopefully, this document extends these guidelines to a new data = store. >>>>>=20 >>>>> Cheerily, >>>>> Sue Hares >>>>>=20 >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder=20 >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, January 19, 2017 10:34 AM >>>>> To: Susan Hares >>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; >>>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;=20 >>>>> i2rs-chairs@ietf.org >>>>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>>=20 >>>>> For what it is worth, I find the notion that data models may be=20 >>>>> written for a specific non-secure transport plain broken. There is=20= >>>>> hardly any content of a data model I can think of which is = generally=20 >>>>> suitable for insecure transports. >>>>>=20 >>>>> Can we please kill this idea of _standardizing_ information that = is=20 >>>>> suitable to send over non-secure transports? I really do not see = how=20 >>>>> the IETF can make a claim that a given piece of information is = never=20 >>>>> worth protecting (=3D suitable for non-secure transports). >>>>>=20 >>>>> Note that I am fine if in a certain trusted tightly-coupled = deployment >>>>> information is shipped in whatever way but this is then a property = of=20 >>>>> the _deployment_ and not a property of the _information_. >>>>>=20 >>>>> /js >>>>>=20 >>>>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>>>> Kathleen:=20 >>>>>>=20 >>>>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>>>> modules >>>>> which are designed to exist in the I2RS Ephemeral Control Plane = data >>>>> store >>>>> (configuration and operational state). =20 >>>>>>=20 >>>>>> Draft location:=20 >>>>>> = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ >>>>>>=20 >>>>>> I would appreciate an email discussion with the security ADs, = OPS/NM=20 >>>>>> ADs, >>>>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data = model=20 >>>>> (L3) and the base I2RS topology model should both provide updated = YANG >>>>> Security Considerations sections. I would appreciate if Benoit or = you=20 >>>>> hold a discuss until we sort out these issues. >>>>>>=20 >>>>>> Thank you, >>>>>>=20 >>>>>> Sue >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] >>>>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>>>> To: The IESG >>>>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com;=20= >>>>>> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>>>>> Subject: Kathleen Moriarty's No Objection on >>>>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>>>=20 >>>>>> Kathleen Moriarty has entered the following ballot position for >>>>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>>>=20 >>>>>> When responding, please keep the subject line intact and reply to=20= >>>>>> all email addresses included in the To and CC lines. (Feel free = to=20 >>>>>> cut this introductory paragraph, however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found = here: >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = -------------------------------------------------------------------- >>>>>> -- >>>>>> COMMENT: >>>>>> = -------------------------------------------------------------------- >>>>>> -- >>>>>>=20 >>>>>> I agree with Alissa's comment that the YANG module security=20 >>>>>> consideration >>>>> section guidelines need to be followed and this shouldn't go = forward=20 >>>>> until that is corrected. I'm told it will be, thanks. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>=20 >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>>=20 >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jan 23 06:45:05 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 EFBB81295FE; Mon, 23 Jan 2017 06:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 hEqDzE0XmZf6; Mon, 23 Jan 2017 06:44:58 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8DF1294B6; Mon, 23 Jan 2017 06:44:58 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Giles Heron'" , "'Juergen Schoenwaelder'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> In-Reply-To: Date: Mon, 23 Jan 2017 09:40:43 -0500 Message-ID: <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023A_01D2755C.C493D770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+AvYiyDYB8tFV9gI6fU8poHcMMPA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 14:45:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023A_01D2755C.C493D770 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Giles: =20 Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang = modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). =20 The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 =20 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication = as a permissible implementation alternative.=20 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 =20 If the ODL model does not support writes to these data models, then it = would not have to support the priority mechanism to resolve two clients = writing one data node. =20 =20 A) Basic Yang considerations=20 =20 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 =20 If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 =20 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 =20 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 =20 I2RS YANG Model Security Considerations =20 The requirement for this section is the following information:=20 =20 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 2) Discussion of RPCs specific to I2RS control plane data store, =20 3) NACM policy impacts the read-write state and augmentation of NACM by = access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 =20 For the topology data models (ietf-network, ietf-network-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C =20 For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. The L3 Topology model may also read information from = the routing protocols (ospf, isis or others), or write data to the = routing protocol. RACM policy should be carefully set so that the = routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C =20 =20 Hopefully, this makes the suggestion for I2RS security policy a bit more = concrete. =20 =20 Sue Hares=20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20 =20 +--rw networks +--rw network* [network-id] +--rw network-types +--rw network-id network-id +--ro server-provided? boolean +--rw supporting-network* [network-ref] | +--rw network-ref -> /networks/network/network-id +--rw node* [node-id] +--rw node-id node-id +--rw supporting-node* [network-ref node-ref] +--rw network-ref -> ../../../supporting-network/ + | network-ref +--rw node-ref -> /networks/network/node/node-id =20 module: ietf-network-topology augment /nd:networks/nd:network: +--rw link* [link-id] +--rw source | +--rw source-node? -> ../../../nd:node/node-id | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../source-node]/termination-point/tp-id +--rw destination | +--rw dest-node? -> ../../../nd:node/node-id | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../dest-node]/termination-point/tp-id +--rw link-id link-id +--rw supporting-link* [network-ref link-ref] +--rw network-ref -> ../../../nd:supporting-network/+ | network-ref +--rw link-ref -> /nd:networks/network+ = [nd:network-id=3Dcurrent()/../network-ref]/+ link/link-id =20 augment /nd:networks/nd:network/nd:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ current()/../network-ref]/node+ [nd:node-id=3Dcurrent()/../node-ref]/+ termination-point/tp-id =20 =20 module: ietf-l3-unicast-topology augment /nd:networks/nd:network/nd:network-types: +--rw l3-unicast-topology! augment /nd:networks/nd:network: +--rw l3-topology-attributes +--rw name? string +--rw flag* l3-flag-type augment /nd:networks/nd:network/nd:node: +--rw l3-node-attributes +--rw name? inet:domain-name +--rw flag* node-flag-type +--rw router-id* inet:ip-address +--rw prefix* [prefix] +--rw prefix inet:ip-prefix +--rw metric? uint32 +--rw flag* prefix-flag-type augment /nd:networks/nd:network/lnk:link: +--rw l3-link-attributes +--rw name? string +--rw flag* link-flag-type +--rw metric? uint32 augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) | +--rw unnumbered-id? uint32 +--:(interface-name) +--ro interface-name? string =20 =20 =20 =20 =20 -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 6:45 AM To: Juergen Schoenwaelder Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 ODL does, indeed, implement the topology models, but generally the data = in the topology model is operational data, so I=E2=80=99m not sure how = that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making validation, priority etc. non-issues). =20 > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = wrote: >=20 > I thought the topology models are coming more or less from=20 > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > /js >=20 > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> Juergen:=20 >>=20 >> Let's focus on your second point. The topology drafts are I2RS = drafts >> designed for the I2RS ephemeral control plane data store. How can = these be >> generic YANG modules when the following is true:=20 >>=20 >> 1) I2RS Data models do not utilize the configuration data store, >> 2) I2RS Data Models do not require the same validation as=20 >> configuration data store, >> 3) I2RS Data models require the use of priority to handle the=20 >> multi-write contention problem into the I2RS Control Plane data=20 >> store, >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> mandatory-to-implement transport, >>=20 >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20 >> the discussion should be taken up with netmod WG list. >> Do you disagree with i2rs-protocol-security-requirements? That issue = >> is closed based on IESG approval. >>=20 >> Sue Hares >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [ = mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, January 23, 2017 3:39 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> Susan, >>=20 >> I consider tagging a YANG object statically and universally in the=20 >> data model as "does not need secure communication" fundamentally=20 >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >>=20 >> The topology drafts are regular generic YANG models that just happen=20 >> to be done in I2RS - I believe that using the generic YANG security=20 >> guidelines we have is good enough to progress these drafts. >>=20 >> /js >>=20 >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> I recognize that dislike insecure communication. You made a similar = >>> comment during the WG LC and IETF review of=20 >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20 >>> I2RS WG and approved by the IESG for RFC publication and it contains = >>> the non-secure communication. The mandate from the I2RS WG for this = >>> shepherd/co-chair is clear. >>>=20 >>> As the shepherd for the topology drafts, I try to write-up something = >>> that might address Kathleen's Moriarty's concerns about the topology = >>> draft's security issues about privacy and the I2RS ephemeral control = >>> plane >> data >>> store. I welcome an open discussion on my ideas >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >> The >>> yang doctor's YANG security consideration template >>> ( = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and=20 >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >>> Hopefully, this document extends these guidelines to a new data = store.=20 >>>=20 >>> Cheerily, >>> Sue Hares >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [ = mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, January 19, 2017 10:34 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >>> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> For what it is worth, I find the notion that data models may be=20 >>> written for a specific non-secure transport plain broken. There is=20 >>> hardly any content of a data model I can think of which is generally = >>> suitable for insecure transports. >>>=20 >>> Can we please kill this idea of _standardizing_ information that is=20 >>> suitable to send over non-secure transports? I really do not see how = >>> the IETF can make a claim that a given piece of information is never = >>> worth protecting (=3D suitable for non-secure transports). >>>=20 >>> Note that I am fine if in a certain trusted tightly-coupled=20 >>> deployment information is shipped in whatever way but this is then a = >>> property of the _deployment_ and not a property of the = _information_. >>>=20 >>> /js >>>=20 >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>> Kathleen:=20 >>>>=20 >>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>> modules >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >>> (configuration and operational state). =20 >>>>=20 >>>> Draft location:=20 >>>> = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider >>>> / >>>>=20 >>>> I would appreciate an email discussion with the security ADs,=20 >>>> OPS/NM ADs, >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model >>> (L3) and the base I2RS topology model should both provide updated=20 >>> YANG Security Considerations sections. I would appreciate if Benoit=20 >>> or you hold a discuss until we sort out these issues. >>>>=20 >>>> Thank you, >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [ = mailto:Kathleen.Moriarty.ietf@gmail.com] >>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>> To: The IESG >>>> Cc: = draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com;=20 >>>> i2rs-chairs@ietf.org; = shares@ndzh.com; = i2rs@ietf.org >>>> Subject: Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to=20 >>>> all email addresses included in the To and CC lines. (Feel free to=20 >>>> cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>>=20 >>>> I agree with Alissa's comment that the YANG module security=20 >>>> consideration >>> section guidelines need to be followed and this shouldn't go forward = >>> until that is corrected. I'm told it will be, thanks. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> = https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_023A_01D2755C.C493D770 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Giles:

 

Thank = you for your comments on ODL and your implementation within ODL.=C2=A0 = =C2=A0There are two different issues in discussion:=C2=A0 guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.=C2=A0=C2=A0 The guidelines for the I2RS Yang Module = have three security considerations: a) =C2=A0basic yang = considerations,=C2=A0 b) I2RS ephemeral state considerations, and c) = insecure considerations. =C2=A0=C2=A0Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".=C2=A0 =C2=A0=C2=A0=C2=A0Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

 

The = topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt = has read/write nodes at the network, link and termination point.=C2=A0 = Please see the copy of the YHL diagrams below. Therefore, the basic = topology model is read-write.=C2=A0 The L3 model=C2=A0 = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.=C2=A0 Please = see a copy of the YHL diagrams below.=C2=A0 Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.=C2=A0 This must be considered in the Security considerations = section. =C2=A0The basic requirements for I2RS are:

 

1) = NETCONF over TLS with X.509v3 as mandatory to implement protocol, =

2) RESTCONF which uses HTTP over = TLS with X.509v3 mutual authentication as a permissible implementation = alternative.

3) write contention = for two clients writing a node using I2RS priority (linked to I2RS = User-ID)

=C2=A0=C2=A0=C2=A0

If the ODL model does not support writes to these = data models, then it would not have to support the priority mechanism to = resolve two clients writing one data node. =C2=A0=C2=A0

 

A) = Basic Yang considerations

 

1) = readable nodes with sensitive data: =C2=A0Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.=C2=A0 A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.=C2=A0 =C2=A0Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. = =C2=A0=C2=A0

 

If the = I2RS mandatory transport is utilized, the data streams utilize mutual = authentication, confidentiality, data integrity, and [practical] replay = protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention".=C2=A0 This = level of security is useful when protecting sensitive data. = =C2=A0

 

2) writeable nodes with sensitive data:=C2=A0 Since = the topology nodes are writeable,=C2=A0 a security considerations needs = to consider how these sensitive data nodes will be protected. = =C2=A0=C2=A0While ODL does not support writes to any data node, the base = models do. Therefore, security considerations must be written here. =

 

3) RPCs: No new RPCs are considered, but providing = information on the notification data may be also useful. =

=C2=A0

I2RS YANG Model Security = Considerations

 

The requirement for this section is the following = information:

 

1) Indication of deployment requirement for = mandatory-to-implement NETCONF (RFC7589) or optional RESTCONF = (draft-ietf-netconf-restconf),

2) = Discussion of RPCs specific to I2RS control plane data store, = =C2=A0=C2=A0

3) NACM policy = impacts the read-write state and augmentation of NACM by access control = for read/writing of routing protocols (RACM), =C2=A0system information = (SACM), and between datastores (config to/from ephemeral state). =

4) Discussion of data retrieved = from routing protocols, system information, dynamic configuration (dhcp) =

5) Any suggestion for operational = knobs that control overlay of I2RS configuration over normal = configuration and I2RS operational state over other operational state. =

=C2=A0

For the topology data models (ietf-network, = ietf-network-topology),=C2=A0 the paragraph could be: =

 

=E2=80=9CThe I2RS topology data models = (ietf-network, ietf-network-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of TLS (see RFC7589), or an optional transport support of = RESTCONF (draft-ietf-netconf-restconf). =C2=A0=C2=A0=C2=A0=C2=A0This = data model does not implement any additional RPCs specific to this data = model or any notifications.=C2=A0=C2=A0

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.=C2=A0 For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node. =C2=A0NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).=C2=A0 The engagement of this policy should also be control by = user policy switches (on/of).=C2=A0

 

For = the topology mode, the access to information on interfaces may be = control by SACM related to the interface model.=C2=A0 Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. = =C2=A0=C2=A0Dynamic configuration protocols such as DHCP or DHCPv6 may = also alter the IP Addresses associated with an interface.=C2=A0 DACM = related to the inter-datastore policy on the precedence between = configuration of interface IP addresses, DHCP/DHCPv6 configuration, or = Topology configuration will need to make sure the interface IP address = does not cause fluctuations in the system. =C2=A0Deployments may provide = general configuration knobs that set the default state for NACM, RACM, = SACM and DACM for the topology database. =E2=80=9C

 

For = the L3 topology data models (ietf-l3-unicast-topology),=C2=A0 the = paragraph could be:

 

=E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). =C2=A0=C2=A0=C2=A0=C2=A0This data model = does not implement any additional RPCs specific to this data = model.=C2=A0 This data model does support the following new = notifications: l3-node-event, l3-link-event, l3-prefix-event, and = termination-point-event.=C2=A0 =C2=A0These events provide the = information about the changing L3 topology which may provide information = regarding key nodes.=C2=A0 Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned.=C2=A0

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.=C2=A0 For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node. =C2=A0NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).=C2=A0 The engagement of this policy should also be control by = user policy switches (on/of).=C2=A0

 

For = the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model.=C2=A0 Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. = =C2=A0=C2=A0Dynamic configuration protocols such as DHCP or DHCPv6 may = also alter the IP Addresses associated with an interface.=C2=A0 DACM = related to the inter-datastore policy on the precedence between = configuration of interface IP addresses, DHCP/DHCPv6 configuration, or = Topology configuration will need to make sure the interface IP address = does not cause fluctuations in the system. =C2=A0=C2=A0The L3 Topology = model may also read information from the routing protocols (ospf, isis = or others), or write data to the routing protocol.=C2=A0 RACM policy = should be carefully set so that the routing protocols do not form a = place to launch a DoS attack. =C2=A0Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. =E2=80=9C

 

 

Hopefully, this makes the suggestion for I2RS = security policy a bit more concrete.=C2=A0

 

Sue = Hares

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

High-level Yang diagrams for = draft-ietf-i2rs-yang-network-topo-10.txt

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = networks

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw network* [network-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw network-types

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0+--rw = network-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 network-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--ro server-provided?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = boolean

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw supporting-network* [network-ref]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 +--rw network-ref=C2=A0=C2=A0=C2=A0 -> = /networks/network/network-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw node* [node-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0+--rw = node-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= node-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw supporting-node* [network-ref = node-ref]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = network-ref=C2=A0=C2=A0=C2=A0 -> ../../../supporting-network/ = +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 network-ref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = node-ref=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0-> = /networks/network/node/node-id

 

module: ietf-network-topology

augment /nd:networks/nd:network:

=C2=A0=C2=A0 +--rw link* [link-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = source

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw = source-node?=C2=A0=C2=A0 -> ../../../nd:node/node-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw = source-tp?=C2=A0=C2=A0=C2=A0=C2=A0 -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = ../source-node]/termination-point/tp-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = destination

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw = dest-node?=C2=A0=C2=A0 -> ../../../nd:node/node-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw = dest-tp?=C2=A0=C2=A0=C2=A0=C2=A0 -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = ../dest-node]/termination-point/tp-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = link-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= link-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = supporting-link* [network-ref link-ref]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw network-ref=C2=A0=C2=A0=C2=A0 -> = ../../../nd:supporting-network/+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 network-ref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw link-ref=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> = /nd:networks/network+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = [nd:network-id=3Dcurrent()/../network-ref]/+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = link/link-id

 

augment = /nd:networks/nd:network/nd:node:

=C2=A0=C2=A0 +--rw termination-point* = [tp-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = tp-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 tp-id

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = supporting-termination-point* [network-ref node-ref = tp-ref]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw network-ref=C2=A0=C2=A0=C2=A0 -> = ../../../nd:supporting-node/network-ref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw node-ref=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> = ../../../nd:supporting-node/node-ref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw tp-ref=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> = /nd:networks/network[nd:network-id=3D+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = current()/../network-ref]/node+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = [nd:node-id=3Dcurrent()/../node-ref]/+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0termination-point/tp-id

 

 

=C2=A0=C2=A0 module: = ietf-l3-unicast-topology

=C2=A0=C2=A0 augment = /nd:networks/nd:network/nd:network-types:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = l3-unicast-topology!

=C2=A0=C2=A0 = augment /nd:networks/nd:network:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = l3-topology-attributes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw name?=C2=A0=C2=A0 string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw flag*=C2=A0=C2=A0 l3-flag-type

=C2=A0=C2=A0 augment = /nd:networks/nd:network/nd:node:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = l3-node-attributes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw name?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:domain-name

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw flag*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = node-flag-type

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw router-id*=C2=A0=C2=A0 inet:ip-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw prefix* [prefix]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw prefix=C2=A0=C2=A0=C2=A0 = inet:ip-prefix

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw metric?=C2=A0=C2=A0 uint32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--rw flag*=C2=A0=C2=A0=C2=A0=C2=A0 = prefix-flag-type

=C2=A0=C2=A0 = augment /nd:networks/nd:network/lnk:link:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = l3-link-attributes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw name?=C2=A0=C2=A0=C2=A0=C2=A0 string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw flag*=C2=A0=C2=A0=C2=A0=C2=A0 link-flag-type

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw metric?=C2=A0=C2=A0 uint32

=C2=A0=C2=A0 augment = /nd:networks/nd:network/nd:node/lnk:termination-point:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = l3-termination-point-attributes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw (termination-point-type)?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--:(ip)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 +--rw ip-address*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:ip-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--:(unnumbered)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 +--rw unnumbered-id?=C2=A0=C2=A0 = uint32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--:(interface-name)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro interface-name?=C2=A0 = string

 

 

 

 

 

-----Original Message-----
From: Giles Heron = [mailto:giles.heron@gmail.com]
Sent: Monday, January 23, 2017 6:45 = AM
To: Juergen Schoenwaelder
Cc: Susan Hares; = draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen = Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

ODL does, indeed, implement the topology models, = but generally the data in the topology model is operational data, so = I=E2=80=99m not sure how that fits with =E2=80=9Cdesigned for the I2RS = ephemeral control plane data store=E2=80=9D - since users don=E2=80=99t = write to the models directly (making validation, priority etc. = non-issues).

 

> = On 23 Jan 2017, at 11:29, Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:

>

> I = thought the topology models are coming more or less from =

> OpenDaylight. If so, is ODL = and I2RS implementation?

> =

> /js

>

> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares = wrote:

>> Juergen: =

>>

>> Let's focus on your second point.=C2=A0 = The topology drafts are I2RS drafts

>> designed for the I2RS ephemeral control = plane data store.=C2=A0=C2=A0 How can these be

>> generic YANG modules when the following is = true:

>>

>> 1) I2RS Data models do not utilize the = configuration data store,

>> = 2) I2RS Data Models do not require the same validation as =

>> configuration data = store,

>> 3) I2RS Data = models require the use of priority to handle the

>> multi-write contention problem into the = I2RS Control Plane data

>> = store,

>> 4) I2RS require = TLS with X.509v3 over TCP for the

>> mandatory-to-implement = transport,

>> =

>> Do you disagree with = draft-ietf-netmod-revised-datastores?=C2=A0 If so,=C2=A0 =

>> the discussion should be = taken up with netmod WG list.

>> Do you disagree with = i2rs-protocol-security-requirements?=C2=A0 That issue

>> is closed based on IESG = approval.

>> =

>> Sue = Hares

>>

>> -----Original = Message-----

>> From: = Juergen Schoenwaelder

>> = [mailto:j.schoenwaelder@ja= cobs-university.de]

>> Sent: Monday, January 23, 2017 3:39 = AM

>> To: Susan = Hares

>> Cc: 'Kathleen = Moriarty'; 'The IESG';

>> draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=

>> i2rs-chairs@ietf.org

>> Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on

>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>> =

>> Susan,

>>

>> I consider tagging a YANG object = statically and universally in the

>> data model as "does not need secure = communication" fundamentally

>> flawed; I am not having an issue with = insecure communication in certain deployment contexts.

>>

>> The topology drafts are regular generic = YANG models that just happen

>> to be done in I2RS - I believe that using = the generic YANG security

>> guidelines we have is good enough to = progress these drafts.

>> =

>> /js

>>

>> On Thu, Jan 19, 2017 at 01:15:15PM -0500, = Susan Hares wrote:

>>> = Juergen:

>>> =

>>> I recognize that = dislike insecure communication.=C2=A0 You made a similar =

>>> comment during the = WG LC and IETF review of

>>> = draft-ietf-i2rs-protocol-security-requirements.=C2=A0 However, the =

>>> = draft-ietf-i2rs-protocol-security-requirements were passed by the =

>>> I2RS WG and approved = by the IESG for RFC publication and it contains

>>> the non-secure communication.=C2=A0 = The mandate from the I2RS WG for this

>>> shepherd/co-chair is = clear.

>>> =

>>> As the shepherd for = the topology drafts, I try to write-up something

>>> that might address Kathleen's = Moriarty's concerns about the topology

>>> draft's security issues about privacy = and the I2RS ephemeral control

>>> plane

>> data

>>> store.=C2=A0=C2=A0 I welcome an open = discussion on my ideas

>>> (https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-consider).

>> The

>>> yang doctor's YANG=C2=A0 security = consideration template

>>> (https://trac.ietf.org/tra= c/ops/wiki/yang-security-guidelines) and

>>> the privacy related RFCs (RFC6973) = note that some information is sensitive.

>>> Hopefully, this document extends these = guidelines to a new data store.

>>>

>>> Cheerily,

>>> Sue Hares

>>>

>>> -----Original = Message-----

>>> From: = Juergen Schoenwaelder

>>> = [mailto:j.schoenwaelder@ja= cobs-university.de]

>>> Sent: Thursday, January 19, 2017 10:34 = AM

>>> To: Susan = Hares

>>> Cc: 'Kathleen = Moriarty'; 'The IESG';

>>> draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=

>>> i2rs-chairs@ietf.org

>>> Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on

>>> draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

>>> =

>>> For what it is = worth, I find the notion that data models may be

>>> written for a specific non-secure = transport plain broken. There is

>>> hardly any content of a data model I = can think of which is generally

>>> suitable for insecure = transports.

>>> =

>>> Can we please kill = this idea of _standardizing_ information that is

>>> suitable to send over non-secure = transports? I really do not see how

>>> the IETF can make a claim that a given = piece of information is never

>>> worth protecting (=3D suitable for = non-secure transports).

>>>

>>> Note that I am fine if in a certain = trusted tightly-coupled

>>> deployment information is shipped in = whatever way but this is then a

>>> property of the _deployment_ and not a = property of the _information_.

>>>

>>> /js

>>>

>>> On Thu, Jan 19, 2017 at 09:28:14AM = -0500, Susan Hares wrote:

>>>> Kathleen:

>>>>

>>>> I have written a draft suggesting = a template for the I2RS YANG

>>>> modules

>>> which are designed to exist in the = I2RS Ephemeral Control Plane data store

>>> (configuration and operational = state).=C2=A0=C2=A0=C2=A0

>>>>

>>>> Draft location:

>>>> https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-consider

>>>> /

>>>>

>>>> I would appreciate an email = discussion with the security ADs,

>>>> OPS/NM ADs,

>>> and Routing AD (Alia Atlas).=C2=A0 I = agree that this I2RS YANG data model

>>> (L3) and the base I2RS topology model = should both provide updated

>>> YANG Security Considerations sections. = I would appreciate if Benoit

>>> or you hold a discuss until we sort = out these issues.

>>>> =

>>>> Thank = you,

>>>> =

>>>> = Sue

>>>> =

>>>> -----Original = Message-----

>>>> = From: Kathleen Moriarty [mailto:Kathleen.Moriarty.= ietf@gmail.com]

>>>> Sent: Wednesday, January 18, 2017 = 9:44 PM

>>>> To: The = IESG

>>>> Cc: draft-ietf-i2rs-yang-l3-t= opology@ietf.org; shares@ndzh.com;

>>>> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org<= o:p>

>>>> Subject: Kathleen = Moriarty's No Objection on

>>>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

>>>>

>>>> Kathleen Moriarty has entered the = following ballot position for

>>>> = draft-ietf-i2rs-yang-l3-topology-08: No Objection

>>>>

>>>> When responding, please keep the = subject line intact and reply to

>>>> all email addresses included in = the To and CC lines. (Feel free to

>>>> cut this introductory paragraph, = however.)

>>>> =

>>>> =

>>>> Please refer = to

>>>> https://www.ietf.org/iesg= /statement/discuss-criteria.html

>>>> for more information about IESG = DISCUSS and COMMENT positions.

>>>>

>>>>

>>>> The document, along with other = ballot positions, can be found here:

>>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-yang-l3-topology/

>>>>

>>>>

>>>>

>>>> = -------------------------------------------------------------------<= /o:p>

>>>> -

>>>> --

>>>> COMMENT:

>>>> = -------------------------------------------------------------------<= /o:p>

>>>> -

>>>> --

>>>>

>>>> I agree with Alissa's comment that = the YANG module security

>>>> consideration

>>> section guidelines need to be followed = and this shouldn't go forward

>>> until that is corrected.=C2=A0 I'm = told it will be, thanks.

>>>>

>>>>

>>>>

>>>> = _______________________________________________

>>>> i2rs mailing list

>>>> i2rs@ietf.org<= o:p>

>>>> https://www.ietf.org/mail= man/listinfo/i2rs

>>>

>>> --

>>> Juergen = Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Jacobs University Bremen gGmbH

>>> Phone: +49 421 200 = 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | = 28759 Bremen | Germany

>>> Fax:=C2=A0=C2=A0 +49 421 200 = 3103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<http://www.jacobs-univers= ity.de/>

>>>

>>

>> --

>> Juergen = Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Jacobs University Bremen gGmbH

>> Phone: +49 421 200 = 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | = 28759 Bremen | Germany

>> = Fax:=C2=A0=C2=A0 +49 421 200 = 3103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.jacobs-univers= ity.de/>

>> =

>

> --

> = Juergen = Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Jacobs University Bremen gGmbH

> Phone: +49 421 200 = 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | = 28759 Bremen | Germany

> = Fax:=C2=A0=C2=A0 +49 421 200 = 3103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.jacobs-univers= ity.de/>

> =

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

------=_NextPart_000_023A_01D2755C.C493D770-- From nobody Mon Jan 23 07:16: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 5CA95129615; Mon, 23 Jan 2017 07:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 jDrUSeSBICei; Mon, 23 Jan 2017 07:16:14 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB41129612; Mon, 23 Jan 2017 07:16:13 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Martin Bjorklund'" References: <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123.124652.536050993360637393.mbj@tail-f.com> In-Reply-To: <20170123.124652.536050993360637393.mbj@tail-f.com> Date: Mon, 23 Jan 2017 10:11:37 -0500 Message-ID: <023e01d2758a$fe85bd80$fb913880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01D27561.15B61E20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAxVVTbF9SFIX9T/LXV5LoayXh2wG2rEA+AvYiyDYBZfma6Z+47Icg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 15:16:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023F_01D27561.15B61E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin: Thank you for your insightful questions. My answer to your questions come from my understanding of the draft-ietf-netmod-revised-datastores-00 and discussions with that design team at IETF 97. We have been moving many things in parallel at the IETF rather than do single threaded work. The Topoology work was completed 1 year in advance of the draft-ietf-netmod-revised-datastores-00.txt. #1) model's nodes are "config true", and that "The YANG module defined in this memo is designed to be accessed via the NETCONF protocol". If it is true that these data models do not utilize the configuration data stores, what does the "server-provided" leaf, and the text about "client-configured" in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? If the server-provided leaf is true, it indicates that the data is populated by the I2RS Agent (aka netconf server) rather than the I2RS Client (aka netconf client). The I2RS architecture has aligned the two architecture concepts so the I2RS protocol is designed to be a re-use protocol for the NETCONF protocol and the RESTCONF protocols as its message transport protocols. draft-ietf-netmod-revised-datastores-00 states the following three suggestions for supporting different datastores: o For systems supporting or configuration datastores, the operation may be used to retrieve data stored in these new datastores. o A new operation should be added to retrieve the operational state data store (e.g., ). An alternative is to define a new operation to retrieve data from any datastore (e.g., with the name of the datastore as a parameter). In principle could work but it would be a confusing name. o The operation will be deprecated since it returns data from two datastores that may overlap in the revised datastore model. Based on this input, the I2RS ephemeral control plane data store should use a "get-data I2RS-ephemeral" to get data from the I2RS ephemeral data store (CT, RW). To retrieve information from the applied configuration data store, the "get-config" may be used. To retrieve state from the operational state "get-state" should be used. 2) Your suggestion to add another note about configuration true The config "true" is being implemented as the draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see diagram). It is just in a different data store. Where and how the data store information is stored, is unclear to me at this time. Where do you think it belongs? 3) implementations Right now, the ODL implementation can utilize "get-config" to obtain the I2RS topology model since the I2RS topology database has no equivalent in the intended config. After the draft-ietf-netmod-revised-datastore is implemented, the "get-config" will return from the applied configuration the Topology model with an indication that it is dynamic (see draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL implementation can simply augment its current get-config with an indication that the topology model is a "dynamic" data store. As another example, my understanding is that a change to the ConfD implementation would be to allow a "get-data" and "write-data" that allows the specification of a data store such as the I2RS data store. A get-config of the applied data store should have a "dynamic" flag for the topology database. 4) Notifications - I am unclear how these are tagged to a datastore, but I am behind on event email. Cheerily, Sue -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Monday, January 23, 2017 6:47 AM To: shares@ndzh.com Cc: j.schoenwaelder@jacobs-university.de; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Hi, "Susan Hares" < shares@ndzh.com> wrote: > Juergen: > > Let's focus on your second point. The topology drafts are I2RS drafts > designed for the I2RS ephemeral control plane data store. How can these be > generic YANG modules when the following is true: > > 1) I2RS Data models do not utilize the configuration data store, This was not clear to me. I note that the data model's nodes are "config true", and that "The YANG module defined in this memo is designed to be accessed via the NETCONF protocol". If it is true that these data models do not utilize the configuration data stores, what does the "server-provided" leaf, and the text about "client-configured" in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? If in fact this is correct, I think it would be helpful if a note was added to the YANG modules, that explains that these models are not supposed to be implemented in the same way as other "config true" data models. In the best of worlds it would also describe how they are supposed to be implemented (but I assume that this is up to each vendor for now). I also note that it is not clear how such models would be advertised by a NETCONF server. /martin > 2) I2RS Data Models do not require the same validation as > configuration data store, > 3) I2RS Data models require the use of priority to handle the > multi-write contention problem into the I2RS Control Plane data store, > 4) I2RS require TLS with X.509v3 over TCP for the > mandatory-to-implement transport, > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > the discussion should be taken up with netmod WG list. > Do you disagree with i2rs-protocol-security-requirements? That issue > is closed based on IESG approval. > > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder > [ mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 23, 2017 3:39 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Susan, > > I consider tagging a YANG object statically and universally in the > data model as "does not need secure communication" fundamentally > flawed; I am not having an issue with insecure communication in certain deployment contexts. > > The topology drafts are regular generic YANG models that just happen > to be done in I2RS - I believe that using the generic YANG security > guidelines we have is good enough to progress these drafts. > > /js > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > Juergen: > > > > I recognize that dislike insecure communication. You made a similar > > comment during the WG LC and IETF review of > > draft-ietf-i2rs-protocol-security-requirements. However, the > > draft-ietf-i2rs-protocol-security-requirements were passed by the > > I2RS WG and approved by the IESG for RFC publication and it contains > > the non-secure communication. The mandate from the I2RS WG for this > > shepherd/co-chair is clear. > > > > As the shepherd for the topology drafts, I try to write-up something > > that might address Kathleen's Moriarty's concerns about the topology > > draft's security issues about privacy and the I2RS ephemeral control > > plane > data > > store. I welcome an open discussion on my ideas > > ( https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > > yang doctor's YANG security consideration template > > ( https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > the privacy related RFCs (RFC6973) note that some information is sensitive. > > Hopefully, this document extends these guidelines to a new data store. > > > > Cheerily, > > Sue Hares > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [ mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, January 19, 2017 10:34 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > For what it is worth, I find the notion that data models may be > > written for a specific non-secure transport plain broken. There is > > hardly any content of a data model I can think of which is generally > > suitable for insecure transports. > > > > Can we please kill this idea of _standardizing_ information that is > > suitable to send over non-secure transports? I really do not see how > > the IETF can make a claim that a given piece of information is never > > worth protecting (= suitable for non-secure transports). > > > > Note that I am fine if in a certain trusted tightly-coupled > > deployment information is shipped in whatever way but this is then a > > property of the _deployment_ and not a property of the _information_. > > > > /js > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > Kathleen: > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > modules > > which are designed to exist in the I2RS Ephemeral Control Plane data store > > (configuration and operational state). > > > > > > Draft location: > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > r/ > > > > > > I would appreciate an email discussion with the security ADs, > > > OPS/NM ADs, > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model > > (L3) and the base I2RS topology model should both provide updated > > YANG Security Considerations sections. I would appreciate if Benoit > > or you hold a discuss until we sort out these issues. > > > > > > Thank you, > > > > > > Sue > > > > > > -----Original Message----- > > > From: Kathleen Moriarty [ mailto:Kathleen.Moriarty.ietf@gmail.com] > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > To: The IESG > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; > > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > > > Subject: Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Kathleen Moriarty has entered the following ballot position for > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > -- > > > COMMENT: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > > > > I agree with Alissa's comment that the YANG module security > > > consideration > > section guidelines need to be followed and this shouldn't go forward > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > ------=_NextPart_000_023F_01D27561.15B61E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Martin: =

 

Thank you for your insightful questions.  My = answer to your questions come from my understanding of the = draft-ietf-netmod-revised-datastores-00 and discussions with that design = team at IETF 97.   We have been moving many things in parallel = at the IETF rather than do single threaded work.   The = Topoology work was completed 1 year in advance of the = draft-ietf-netmod-revised-datastores-00.txt. 

 

#1) model's nodes are "config true", = and that "The YANG module defined in this memo is designed to be = accessed via the NETCONF protocol".  If it is true that these = data models do not utilize the configuration data stores, what does the = "server-provided" leaf, and the text about = "client-configured" in section 4.4.10 of = draft-ietf-i2rs-yang-network-topo refer to?

 

If the = server-provided leaf is true, it indicates that the data is populated by = the I2RS Agent (aka netconf server) rather than the I2RS Client (aka = netconf client).    The I2RS architecture has aligned the = two architecture concepts so the  I2RS protocol is designed to be a = re-use protocol for the NETCONF protocol and the RESTCONF protocols as = its message transport protocols.  

 

draft-ietf-netmod-revised-datastores-00 states the = following three suggestions for supporting different datastores: =  

 

   o  For systems supporting = <intended> or <applied> configuration

      datastores, the = <get-config/> operation may be used to retrieve

      data stored in these = new datastores.

 

   o  A new operation should be = added to retrieve the operational state

      data store (e.g., = <get-state/>).  An alternative is to define = a

      = new operation to retrieve data from any datastore = (e.g.,

      <get-data> = with the name of the datastore as a parameter).  = In

      = principle <get-config/> could work but it would be a = confusing

      = name.

 

   o  The <get/> operation = will be deprecated since it returns data from

      two datastores that = may overlap in the revised datastore model.

 

Based = on this input, the I2RS ephemeral control plane data store should use a = "get-data I2RS-ephemeral" to get data from the I2RS ephemeral = data store (CT, RW).   To retrieve information from the = applied configuration data store, the "get-config" may be = used.  To retrieve state from the operational state = "get-state" should be used. 

 

2) = Your suggestion to add another note about configuration true =

 

The config “true” is being implemented = as the draft-ietf-netmod-revised-datastores-00 suggests in section 5 = (see diagram).  It is just in a different data store.   = Where and how the data store information is stored, is unclear to me at = this time.  Where do you think it belongs?  

 

3) = implementations

 

Right = now, the ODL implementation can utilize "get-config" to obtain = the I2RS topology model since the I2RS topology database has no = equivalent in the intended config.  After the = draft-ietf-netmod-revised-datastore is implemented, the = "get-config" will return from the applied configuration the = Topology model with an indication that it is dynamic (see = draft-ietf-netmod-revised-datastores-00.txt section 8.   The = ODL implementation can simply augment its current get-config with an = indication that the topology model is a “dynamic” data = store.    

 

As = another example, my understanding is that a change to the ConfD = implementation would be to allow a "get-data" and = "write-data" that allows the specification of a data store = such as the I2RS data store.   A get-config of the applied = data store should have a “dynamic” flag for the topology = database.

 

4) Notifications – I am unclear how = these are tagged to a datastore, but I am behind on event email. =

 

Cheerily,

 

Sue =   

 

-----Original Message-----
From: Martin = Bjorklund [mailto:mbj@tail-f.com]
Sent: Monday, January 23, 2017 = 6:47 AM
To: shares@ndzh.com
Cc: = j.schoenwaelder@jacobs-university.de; = draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; = i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No = Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

 

Hi,

 

"Susan Hares" <shares@ndzh.com> wrote:

> Juergen: =

>

> Let's focus on your second point.  The = topology drafts are I2RS drafts

> designed for the I2RS ephemeral control plane = data store.   How can these be

> generic YANG modules when the following is = true:

>

> 1) I2RS Data models do not utilize the = configuration data store,

 

This = was not clear to me.  I note that the data model's nodes are = "config true", and that "The YANG module defined in this = memo is designed to be accessed via the NETCONF = protocol".

 

If it = is true that these data models do not utilize the configuration data = stores, what does the "server-provided" leaf, and the text = about "client-configured" in section 4.4.10 of = draft-ietf-i2rs-yang-network-topo refer to?

 

If in = fact this is correct, I think it would be helpful if a note was added to = the YANG modules, that explains that these models are not supposed to be = implemented in the same way as other "config true" data = models.  In the best of worlds it would also describe how they are = supposed to be implemented (but I assume that this is up to each vendor = for now).

 

I also note that it is not clear how such models = would be advertised by a NETCONF server.

 

 

/martin

 

 

 

 

> = 2) I2RS Data Models do not require the same validation as =

> configuration data = store,

> 3) I2RS Data models = require the use of priority to handle the

> multi-write contention problem into the I2RS = Control Plane data store,

> 4) = I2RS require TLS with X.509v3 over TCP for the

> mandatory-to-implement = transport,

>

> Do you disagree with = draft-ietf-netmod-revised-datastores?  If so,  =

> the discussion should be = taken up with netmod WG list.

> = Do you disagree with i2rs-protocol-security-requirements?  That = issue

> is closed based on = IESG approval.

> =

> Sue Hares

>

> = -----Original Message-----

> = From: Juergen Schoenwaelder

> = [mailto:j.schoenwaelder@ja= cobs-university.de]

> Sent: Monday, January 23, 2017 3:39 = AM

> To: Susan = Hares

> Cc: 'Kathleen = Moriarty'; 'The IESG';

> draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=

> i2rs-chairs@ietf.org

> Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on

> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>

> Susan,

>

> I = consider tagging a YANG object statically and universally in the =

> data model as "does not = need secure communication" fundamentally

> flawed; I am not having an issue with insecure = communication in certain deployment contexts.

>

> = The topology drafts are regular generic YANG models that just happen =

> to be done in I2RS - I = believe that using the generic YANG security

> guidelines we have is good enough to progress = these drafts.

> =

> /js

>

> On = Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares = wrote:

> > Juergen: =

> >

> > I recognize that dislike insecure = communication.  You made a similar

> > comment during the WG LC and IETF review = of

> > = draft-ietf-i2rs-protocol-security-requirements.  However, the =

> > = draft-ietf-i2rs-protocol-security-requirements were passed by the =

> > I2RS WG and approved by = the IESG for RFC publication and it contains

> > the non-secure communication.  The = mandate from the I2RS WG for this

> > shepherd/co-chair is = clear.

> >

> > As the shepherd for the topology drafts, = I try to write-up something

> = > that might address Kathleen's Moriarty's concerns about the = topology

> > draft's = security issues about privacy and the I2RS ephemeral control =

> > plane

> data

> > store.   I welcome an open = discussion on my ideas

> > = (https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-consider).

> The

> = > yang doctor's YANG  security consideration = template

> > (https://trac.ietf.org/tra= c/ops/wiki/yang-security-guidelines) and

> > the privacy related RFCs (RFC6973) note = that some information is sensitive.

> > Hopefully, this document extends these = guidelines to a new data store.

> >

> > Cheerily,

> > Sue Hares

> >

> > -----Original = Message-----

> > From: = Juergen Schoenwaelder

> > = [mailto:j.schoenwaelder@ja= cobs-university.de]

> > Sent: Thursday, January 19, 2017 10:34 = AM

> > To: Susan = Hares

> > Cc: 'Kathleen = Moriarty'; 'The IESG';

> > = draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=

> > i2rs-chairs@ietf.org

> > Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on

> > draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

> > =

> > For what it is worth, I = find the notion that data models may be

> > written for a specific non-secure = transport plain broken. There is

> > hardly any content of a data model I can = think of which is generally

> = > suitable for insecure transports.

> >

> > Can we please kill this idea of = _standardizing_ information that is

> > suitable to send over non-secure = transports? I really do not see how

> > the IETF can make a claim that a given = piece of information is never

> > worth protecting (=3D suitable for = non-secure transports).

> > =

> > Note that I am fine if = in a certain trusted tightly-coupled

> > deployment information is shipped in = whatever way but this is then a

> > property of the _deployment_ and not a = property of the _information_.

> >

> > /js

> >

> > On Thu, Jan 19, 2017 at 09:28:14AM -0500, = Susan Hares wrote:

> > > = Kathleen:

> > > =

> > > I have written a = draft suggesting a template for the I2RS YANG

> > > modules

> > which are designed to exist in the I2RS = Ephemeral Control Plane data store

> > (configuration and operational = state).   

> = > >

> > > Draft = location:

> > > https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-conside

> > > r/

> > >

> > > I would appreciate an email = discussion with the security ADs,

> > > OPS/NM ADs,

> > and Routing AD (Alia Atlas).  I = agree that this I2RS YANG data model

> > (L3) and the base I2RS topology model = should both provide updated

> = > YANG Security Considerations sections. I would appreciate if Benoit =

> > or you hold a discuss = until we sort out these issues.

> > >

> > > Thank you,

> > >

> > > Sue

> > >

> > > -----Original = Message-----

> > > From: = Kathleen Moriarty [mailto:Kathleen.Moriarty.= ietf@gmail.com]

> = > > Sent: Wednesday, January 18, 2017 9:44 PM

> > > To: The IESG

> > > Cc: draft-ietf-i2rs-yang-l3-t= opology@ietf.org; shares@ndzh.com;

> > > i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org<= o:p>

> > > Subject: Kathleen = Moriarty's No Objection on

> = > > draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

> > > =

> > > Kathleen Moriarty = has entered the following ballot position for

> > > draft-ietf-i2rs-yang-l3-topology-08: = No Objection

> > > =

> > > When responding, = please keep the subject line intact and reply to

> > > all email addresses included in the = To and CC lines. (Feel free to

> > > cut this introductory paragraph, = however.)

> > > =

> > >

> > > Please refer to

> > > https://www.ietf.org/iesg= /statement/discuss-criteria.html

> > > for more information about IESG = DISCUSS and COMMENT positions.

> > >

> > >

> > > The document, along with other = ballot positions, can be found here:

> > > https://datatracker.ietf.= org/doc/draft-ietf-i2rs-yang-l3-topology/

> > >

> > >

> > >

> > > = ------------------------------------------------------------------

> > > --

> > > --

> > > COMMENT:

> > > = ------------------------------------------------------------------

> > > --

> > > --

> > >

> > > I agree with Alissa's comment that = the YANG module security

> = > > consideration

> > = section guidelines need to be followed and this shouldn't go forward =

> > until that is = corrected.  I'm told it will be, thanks.

> > >

> > >

> > >

> > > = _______________________________________________

> > > i2rs mailing list

> > > i2rs@ietf.org<= o:p>

> > > https://www.ietf.org/mail= man/listinfo/i2rs

> = >

> > -- =

> > Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

> > Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

> > = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

> > =

>

> --

> = Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

> =

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

> =

------=_NextPart_000_023F_01D27561.15B61E20-- From nobody Mon Jan 23 07:32: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 F13AC12962F; Mon, 23 Jan 2017 07:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9rSFLaBhl7B; Mon, 23 Jan 2017 07:32:19 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2BA129601; Mon, 23 Jan 2017 07:32:19 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id AF6191AE0285; Mon, 23 Jan 2017 16:32:17 +0100 (CET) Date: Mon, 23 Jan 2017 16:32:15 +0100 (CET) Message-Id: <20170123.163215.1929278119114265404.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <023e01d2758a$fe85bd80$fb913880$@ndzh.com> References: <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123.124652.536050993360637393.mbj@tail-f.com> <023e01d2758a$fe85bd80$fb913880$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 15:32:22 -0000 "Susan Hares" wrote: > Martin: > > > > Thank you for your insightful questions. My answer to your questions come > from my understanding of the draft-ietf-netmod-revised-datastores-00 and > discussions with that design team at IETF 97. We have been moving many > things in parallel at the IETF rather than do single threaded work. The > Topoology work was completed 1 year in advance of the > draft-ietf-netmod-revised-datastores-00.txt. Right; this is why I think an additional note in these modules are necessary. If you just read these topoly drafts, you will find a normal YANG module that has a "config true" subtree. Without additional guidance, it is not clear that these data models "do not utilize the configuration data store" (if this is true). > #1) model's nodes are "config true", and that "The YANG module defined in > this memo is designed to be accessed via the NETCONF protocol". If it is > true that these data models do not utilize the configuration data stores, > what does the "server-provided" leaf, and the text about "client-configured" > in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > > > > If the server-provided leaf is true, it indicates that the data is populated > by the I2RS Agent (aka netconf server) Doesn't this procedure involve the normal configuration data stores? If it does, I think we're good. If it doesn't, I think the additional note should be added. > rather than the I2RS Client (aka > netconf client). The I2RS architecture has aligned the two architecture > concepts so the I2RS protocol is designed to be a re-use protocol for the > NETCONF protocol and the RESTCONF protocols as its message transport > protocols. > > > > draft-ietf-netmod-revised-datastores-00 states the following three > suggestions for supporting different datastores: > > > > o For systems supporting or configuration > > datastores, the operation may be used to retrieve > > data stored in these new datastores. > > > > o A new operation should be added to retrieve the operational state > > data store (e.g., ). An alternative is to define a > > new operation to retrieve data from any datastore (e.g., > > with the name of the datastore as a parameter). In > > principle could work but it would be a confusing > > name. > > > > o The operation will be deprecated since it returns data from > > two datastores that may overlap in the revised datastore model. > > > > Based on this input, the I2RS ephemeral control plane data store should use > a "get-data I2RS-ephemeral" to get data from the I2RS ephemeral data store > (CT, RW). To retrieve information from the applied configuration data > store, the "get-config" may be used. To retrieve state from the operational > state "get-state" should be used. > > > > 2) Your suggestion to add another note about configuration true > > > > The config "true" is being implemented as the > draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see diagram). > It is just in a different data store. Where and how the data store > information is stored, is unclear to me at this time. Where do you think it > belongs? I always thought that the topology models could be written to through the normal configuration data stores, in which case the server would set the "server-provided" leaf to "false". It seems that you have some other mechanism in mind? /martin > 3) implementations > > > > Right now, the ODL implementation can utilize "get-config" to obtain the > I2RS topology model since the I2RS topology database has no equivalent in > the intended config. After the draft-ietf-netmod-revised-datastore is > implemented, the "get-config" will return from the applied configuration the > Topology model with an indication that it is dynamic (see > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > implementation can simply augment its current get-config with an indication > that the topology model is a "dynamic" data store. > > > > As another example, my understanding is that a change to the ConfD > implementation would be to allow a "get-data" and "write-data" that allows > the specification of a data store such as the I2RS data store. A > get-config of the applied data store should have a "dynamic" flag for the > topology database. > > > > 4) Notifications - I am unclear how these are tagged to a datastore, but I > am behind on event email. > > > > Cheerily, > > > > Sue > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, January 23, 2017 6:47 AM > To: shares@ndzh.com > Cc: j.schoenwaelder@jacobs-university.de; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > Juergen: > > > > > > Let's focus on your second point. The topology drafts are I2RS drafts > > > designed for the I2RS ephemeral control plane data store. How can these > be > > > generic YANG modules when the following is true: > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > This was not clear to me. I note that the data model's nodes are "config > true", and that "The YANG module defined in this memo is designed to be > accessed via the NETCONF protocol". > > > > If it is true that these data models do not utilize the configuration data > stores, what does the "server-provided" leaf, and the text about > "client-configured" in section 4.4.10 of draft-ietf-i2rs-yang-network-topo > refer to? > > > > If in fact this is correct, I think it would be helpful if a note was added > to the YANG modules, that explains that these models are not supposed to be > implemented in the same way as other "config true" data models. In the best > of worlds it would also describe how they are supposed to be implemented > (but I assume that this is up to each vendor for now). > > > > I also note that it is not clear how such models would be advertised by a > NETCONF server. > > > > > > /martin > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > configuration data store, > > > 3) I2RS Data models require the use of priority to handle the > > > multi-write contention problem into the I2RS Control Plane data store, > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > mandatory-to-implement transport, > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > the discussion should be taken up with netmod WG list. > > > Do you disagree with i2rs-protocol-security-requirements? That issue > > > is closed based on IESG approval. > > > > > > Sue Hares > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [ > mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, January 23, 2017 3:39 AM > > > To: Susan Hares > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; > > > i2rs-chairs@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Susan, > > > > > > I consider tagging a YANG object statically and universally in the > > > data model as "does not need secure communication" fundamentally > > > flawed; I am not having an issue with insecure communication in certain > deployment contexts. > > > > > > The topology drafts are regular generic YANG models that just happen > > > to be done in I2RS - I believe that using the generic YANG security > > > guidelines we have is good enough to progress these drafts. > > > > > > /js > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > Juergen: > > > > > > > > I recognize that dislike insecure communication. You made a similar > > > > comment during the WG LC and IETF review of > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > draft-ietf-i2rs-protocol-security-requirements were passed by the > > > > I2RS WG and approved by the IESG for RFC publication and it contains > > > > the non-secure communication. The mandate from the I2RS WG for this > > > > shepherd/co-chair is clear. > > > > > > > > As the shepherd for the topology drafts, I try to write-up something > > > > that might address Kathleen's Moriarty's concerns about the topology > > > > draft's security issues about privacy and the I2RS ephemeral control > > > > plane > > > data > > > > store. I welcome an open discussion on my ideas > > > > ( > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > The > > > > yang doctor's YANG security consideration template > > > > ( > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > the privacy related RFCs (RFC6973) note that some information is > sensitive. > > > > Hopefully, this document extends these guidelines to a new data store. > > > > > > > > Cheerily, > > > > Sue Hares > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > [ > mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > To: Susan Hares > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; > > > > i2rs-chairs@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > For what it is worth, I find the notion that data models may be > > > > written for a specific non-secure transport plain broken. There is > > > > hardly any content of a data model I can think of which is generally > > > > suitable for insecure transports. > > > > > > > > Can we please kill this idea of _standardizing_ information that is > > > > suitable to send over non-secure transports? I really do not see how > > > > the IETF can make a claim that a given piece of information is never > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > deployment information is shipped in whatever way but this is then a > > > > property of the _deployment_ and not a property of the _information_. > > > > > > > > /js > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > Kathleen: > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > modules > > > > which are designed to exist in the I2RS Ephemeral Control Plane data > store > > > > (configuration and operational state). > > > > > > > > > > Draft location: > > > > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > r/ > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > OPS/NM ADs, > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model > > > > (L3) and the base I2RS topology model should both provide updated > > > > YANG Security Considerations sections. I would appreciate if Benoit > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > Thank you, > > > > > > > > > > Sue > > > > > > > > > > -----Original Message----- > > > > > From: Kathleen Moriarty [ > mailto:Kathleen.Moriarty.ietf@gmail.com] > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > To: The IESG > > > > > Cc: > draft-ietf-i2rs-yang-l3-topology@ietf.org; > shares@ndzh.com; > > > > > i2rs-chairs@ietf.org; > shares@ndzh.com; > i2rs@ietf.org > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > Kathleen Moriarty has entered the following ballot position for > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > When responding, please keep the subject line intact and reply to > > > > > all email addresses included in the To and CC lines. (Feel free to > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > > -- > > > > > -- > > > > > COMMENT: > > > > > ------------------------------------------------------------------ > > > > > -- > > > > > -- > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > consideration > > > > section guidelines need to be followed and this shouldn't go forward > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > i2rs mailing list > > > > > i2rs@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > From nobody Mon Jan 23 08:22:05 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 F152312959D; Mon, 23 Jan 2017 08:21:58 -0800 (PST) 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 lTZ19tr70VBx; Mon, 23 Jan 2017 08:21:57 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9791294C5; Mon, 23 Jan 2017 08:21:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Martin Bjorklund'" References: <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123.124652.536050993360637393.mbj@tail-f.com> <023e01d2758a$fe85bd80$fb913880$@ndzh.com> <20170123.163215.1929278119114265404.mbj@tail-f.com> In-Reply-To: <20170123.163215.1929278119114265404.mbj@tail-f.com> Date: Mon, 23 Jan 2017 11:17:13 -0500 Message-ID: <000701d27594$28d12350$7a7369f0$@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: AQL2Isg2sAXLj+EmnJZr+77IFiDH4AFl+ZrpArYWNkEC8sZUUJ7GaCcA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 16:21:59 -0000 Martin: Answers inline. -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Monday, January 23, 2017 10:32 AM To: shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) "Susan Hares" wrote: >> Martin: >> >> >> >> Thank you for your insightful questions. My answer to your questions >> come from my understanding of the draft-ietf-netmod-revised-datastores-00 and >> discussions with that design team at IETF 97. We have been moving many >> things in parallel at the IETF rather than do single threaded work. The >> Topoology work was completed 1 year in advance of the >> draft-ietf-netmod-revised-datastores-00.txt. >Right; this is why I think an additional note in these modules are necessary. If you just read these topoly drafts, you will find a normal YANG module that has a "config true" subtree. >Without additional guidance, it is not clear that these data models "do not utilize the configuration data store" (if this is true). Sue: Sounds like a good idea. I'll suggest this to the authors as the document shepherd. >> #1) model's nodes are "config true", and that "The YANG module defined >> in this memo is designed to be accessed via the NETCONF protocol". If >> it is true that these data models do not utilize the configuration >> data stores, what does the "server-provided" leaf, and the text about "client-configured" >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? >> >> If the server-provided leaf is true, it indicates that the data is >> populated by the I2RS Agent (aka netconf server) >Doesn't this procedure involve the normal configuration data stores? >If it does, I think we're good. If it doesn't, I think the additional note should be added. Sue: The model is in the I2RS control plane data store. According to draft-ietf-netmod-revised-datatstores-00.txt this is note the normal configuration data store. Does a note in the text plus a note at the beginning of the data model suffice? >> rather than the I2RS Client (aka >> netconf client). The I2RS architecture has aligned the two architecture >> concepts so the I2RS protocol is designed to be a re-use protocol for >> the NETCONF protocol and the RESTCONF protocols as its message >> transport protocols. >> >> draft-ietf-netmod-revised-datastores-00 states the following three >> suggestions for supporting different datastores: >> >> >> o For systems supporting or configuration >> >> datastores, the operation may be used to retrieve >> >> data stored in these new datastores. >> >> >> >> o A new operation should be added to retrieve the operational >> state >> >> data store (e.g., ). An alternative is to define a >> >> new operation to retrieve data from any datastore (e.g., >> >> with the name of the datastore as a parameter). In >> >> principle could work but it would be a confusing >> >> name. >> >> >> >> o The operation will be deprecated since it returns data >> from >> >> two datastores that may overlap in the revised datastore model. >> >> >> >> Based on this input, the I2RS ephemeral control plane data store >> should use a "get-data I2RS-ephemeral" to get data from the I2RS ephemeral data store >> (CT, RW). To retrieve information from the applied configuration data >> store, the "get-config" may be used. To retrieve state from the >> operational state "get-state" should be used. >> >> >> 2) Your suggestion to add another note about configuration true >> >> The config "true" is being implemented as the >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see diagram). >> It is just in a different data store. Where and how the data store >> information is stored, is unclear to me at this time. Where do you >> think it belongs? > I always thought that the topology models could be written to through the normal configuration data stores, in which case the server would set the "server-provided" leaf to "false". It seems that you have some other mechanism in mind? The design team for drat-ietf-netmod-revised-datastores-00.txt indicated that the client written topology with "server-provided" leaf set to "false" is written in the I2RS Control Plane data store. An I2RS implementation then combines the I2RS Control Plane data store with the intended configuration data store (based on internal configuration knobs) and installs this in a node. A client can query the topology data nodes in the applied configuration data store. The response giving the topology nodes will indicate that a dynamic control plane protocol inserted these nodes. I am only trying to interpret the netmod design and align the I2RS data models (topology, RIB, FB-RIB) to this design. Thank you for your suggestions on the data model. Sue Hares /martin > 3) implementations > > > > Right now, the ODL implementation can utilize "get-config" to obtain > the I2RS topology model since the I2RS topology database has no > equivalent in the intended config. After the > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > will return from the applied configuration the Topology model with an indication that it is dynamic (see > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > implementation can simply augment its current get-config with an indication > that the topology model is a "dynamic" data store. > > > > As another example, my understanding is that a change to the ConfD > implementation would be to allow a "get-data" and "write-data" that allows > the specification of a data store such as the I2RS data store. A > get-config of the applied data store should have a "dynamic" flag for > the topology database. > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > but I am behind on event email. > > > > Cheerily, > > > > Sue > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, January 23, 2017 6:47 AM > To: shares@ndzh.com > Cc: j.schoenwaelder@jacobs-university.de; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > Juergen: > > > > > > Let's focus on your second point. The topology drafts are I2RS > > drafts > > > designed for the I2RS ephemeral control plane data store. How can these > be > > > generic YANG modules when the following is true: > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > This was not clear to me. I note that the data model's nodes are > "config true", and that "The YANG module defined in this memo is > designed to be accessed via the NETCONF protocol". > > > > If it is true that these data models do not utilize the configuration > data stores, what does the "server-provided" leaf, and the text about > "client-configured" in section 4.4.10 of > draft-ietf-i2rs-yang-network-topo refer to? > > > > If in fact this is correct, I think it would be helpful if a note was > added to the YANG modules, that explains that these models are not > supposed to be implemented in the same way as other "config true" data > models. In the best of worlds it would also describe how they are > supposed to be implemented (but I assume that this is up to each vendor for now). > > > > I also note that it is not clear how such models would be advertised > by a NETCONF server. > > > > > > /martin > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > configuration data store, > > > 3) I2RS Data models require the use of priority to handle the > > > multi-write contention problem into the I2RS Control Plane data > > store, > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > mandatory-to-implement transport, > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > the discussion should be taken up with netmod WG list. > > > Do you disagree with i2rs-protocol-security-requirements? That > > issue > > > is closed based on IESG approval. > > > > > > Sue Hares > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [ > mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, January 23, 2017 3:39 AM > > > To: Susan Hares > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; > > > i2rs-chairs@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Susan, > > > > > > I consider tagging a YANG object statically and universally in the > > > data model as "does not need secure communication" fundamentally > > > flawed; I am not having an issue with insecure communication in > > certain > deployment contexts. > > > > > > The topology drafts are regular generic YANG models that just happen > > > to be done in I2RS - I believe that using the generic YANG security > > > guidelines we have is good enough to progress these drafts. > > > > > > /js > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > Juergen: > > > > > > > > I recognize that dislike insecure communication. You made a > > > similar > > > > comment during the WG LC and IETF review of > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > draft-ietf-i2rs-protocol-security-requirements were passed by the > > > > I2RS WG and approved by the IESG for RFC publication and it > > > contains > > > > the non-secure communication. The mandate from the I2RS WG for > > > this > > > > shepherd/co-chair is clear. > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > something > > > > that might address Kathleen's Moriarty's concerns about the > > > topology > > > > draft's security issues about privacy and the I2RS ephemeral > > > control > > > > plane > > > data > > > > store. I welcome an open discussion on my ideas > > > > ( > > > > > er> > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > The > > > > yang doctor's YANG security consideration template > > > > ( > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > the privacy related RFCs (RFC6973) note that some information is > sensitive. > > > > Hopefully, this document extends these guidelines to a new data store. > > > > > > > > Cheerily, > > > > Sue Hares > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > [ > mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > To: Susan Hares > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; > > > > i2rs-chairs@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > For what it is worth, I find the notion that data models may be > > > > written for a specific non-secure transport plain broken. There is > > > > hardly any content of a data model I can think of which is > > > generally > > > > suitable for insecure transports. > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > is > > > > suitable to send over non-secure transports? I really do not see > > > how > > > > the IETF can make a claim that a given piece of information is > > > never > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > deployment information is shipped in whatever way but this is then > > > a > > > > property of the _deployment_ and not a property of the _information_. > > > > > > > > /js > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > Kathleen: > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > modules > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > data > store > > > > (configuration and operational state). > > > > > > > > > > Draft location: > > > > > > > > > > > > ide> > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > r/ > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > OPS/NM ADs, > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > model > > > > (L3) and the base I2RS topology model should both provide updated > > > > YANG Security Considerations sections. I would appreciate if > > > Benoit > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > Thank you, > > > > > > > > > > Sue > > > > > > > > > > -----Original Message----- > > > > > From: Kathleen Moriarty [ > > > > > mailto:Kathleen.Moriarty.ietf@gmail.com] > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > To: The IESG > > > > > Cc: > draft-ietf-i2rs-yang-l3-topology@ietf.org; > shares@ndzh.com; > > > > > i2rs-chairs@ietf.org; > shares@ndzh.com; > i2rs@ietf.org > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > Kathleen Moriarty has entered the following ballot position for > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > to > > > > > all email addresses included in the To and CC lines. (Feel free > > > > to > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > > > > > > gy/> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > -- > > > > > -- > > > > > -- > > > > > COMMENT: > > > > > ---------------------------------------------------------------- > > > > -- > > > > > -- > > > > > -- > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > consideration > > > > section guidelines need to be followed and this shouldn't go > > > forward > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > i2rs mailing list > > > > > i2rs@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jan 23 08:26:03 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 582A612959B; Mon, 23 Jan 2017 08:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01] 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 zUC22zDY26UM; Mon, 23 Jan 2017 08:25:59 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 DA800129599; Mon, 23 Jan 2017 08:25:58 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id c85so27462146wmi.1; Mon, 23 Jan 2017 08:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w4r7TDsug+ScOE0mhXlCdqiTL10OyHJSekGL3rDDFhM=; b=Y3gU39U0t6eZGYVCMNVGoMN/ia8tDMbq8ibuDQGMfaF4bVgRZNxBQ/17lUU+keqn4E 4VKW9c+kEPWnwgipQ5Z4cqruPz2klSOx/trVQhMnH3BRub4FzDmWwaQi+n8uTQEwJJRS /RhhSj2I6ZjK5t1bpn3VhyIpSMfPgl+N082JjfmMaXMaX7bk1rhV7+UEY6R0oBHY1QWY N7cRGKXem9T1wl+CYVxPEfYX8qpEUb9IKti5EmlmkrLRenAxCE8MriIWz6lpxh3JMXA2 YzcPR/+0i0k5tuKAMVpqFwPhUBXRE15NrTJucqCadrawfVGyZZNpAbRSf8x9Gr9hEdIO lyyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w4r7TDsug+ScOE0mhXlCdqiTL10OyHJSekGL3rDDFhM=; b=dZEmvF95kLQahs0re2j5zsNgePLz3wuafHCEwGB5K5sDASAYc5/P7dN3/Y7oeG0QVm 0RcJKsG3hvnKrQ1WZyJokNRLbPTOK51NRqRYICP6LZvDLy4XqmJrwY9mB3+VJ8I8gw78 ek4UTyZJjJIjwVj1Sz8+iudQaMxX/WFxSJDgCHNGPEdYUmeu+SIhm4jy+eYDJBw0P3ag Rn105Jha+sJmw3MqWDhgJeFodnLvyA2YAmoxxXRqAeXkDTy0+LchsyAvHhNbHic4crvV l9ev/3ctKcVXkg/ogpbu1WdPuelQ0Cb1qs9H4HOSxvT9uZ0Vw71kPdpTirSdrXjMqYDA MmmA== X-Gm-Message-State: AIkVDXJtMPdpx8UcA7LmrbwIGZo+v9tSnvW/4NEkdSbWPU//ZOxprRtSaHcCEkzSMudk8g== X-Received: by 10.28.65.196 with SMTP id o187mr8781352wma.37.1485188757035; Mon, 23 Jan 2017 08:25:57 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.40]) by smtp.gmail.com with ESMTPSA id m29sm15491700wrm.38.2017.01.23.08.25.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 08:25:56 -0800 (PST) From: Giles Heron Message-Id: <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_162B8FD7-58AA-4493-8531-AE9426510330" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 16:25:54 +0000 In-Reply-To: <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> To: Susan Hares References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 16:26:02 -0000 --Apple-Mail=_162B8FD7-58AA-4493-8531-AE9426510330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sue, > On 23 Jan 2017, at 14:40, Susan Hares wrote: >=20 > Giles: > =20 > Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS = Yang modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). i wasn=E2=80=99t the implementer of those models in ODL. But I=E2=80=99v= e used them a fair bit. at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model doesn=E2=80=99t = really =E2=80=9Cfit=E2=80=9D with the original goal of I2RS (ephemeral = configuration of RIBs, ACLs etc. on network elements) > The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20= most NETCONF implementations I=E2=80=99m aware of use ssh. And this is mandatory only per an individual ID, right? Or is it in a = WG draft now? And do we have WG consensus that this applies to = read-only data as well as to read-write? > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual = authentication as a permissible implementation alternative.=20 again isn=E2=80=99t that only specified as mandatory in an individual = ID? > 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 so that one isn=E2=80=99t an issue for read-only implementations=E2=80=A6 > If the ODL model does not support writes to these data models, then it = would not have to support the priority mechanism to resolve two clients = writing one data node. =20 indeed. Giles > A) Basic Yang considerations=20 > =20 > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 > =20 > If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 > =20 > 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 > =20 > 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 > =20 > I2RS YANG Model Security Considerations > =20 > The requirement for this section is the following information:=20 > =20 > 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 > 2) Discussion of RPCs specific to I2RS control plane data store, =20 > 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 > 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 > 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 > =20 > For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 > =20 > =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20= > =20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > =20 > For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C > =20 > For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 > =20 > =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 > =20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > =20 > For the L3 topology mode, the access to information on interfaces may = be control by SACM related to the interface model. Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol. RACM policy should be carefully set so = that the routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C > =20 > =20 > Hopefully, this makes the suggestion for I2RS security policy a bit = more concrete.=20 > Sue Hares=20 > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20= > =20 > +--rw networks > +--rw network* [network-id] > +--rw network-types > +--rw network-id network-id > +--ro server-provided? boolean > +--rw supporting-network* [network-ref] > | +--rw network-ref -> /networks/network/network-id > +--rw node* [node-id] > +--rw node-id node-id > +--rw supporting-node* [network-ref node-ref] > +--rw network-ref -> ../../../supporting-network/ = + > | network-ref > +--rw node-ref -> = /networks/network/node/node-id > =20 > module: ietf-network-topology > augment /nd:networks/nd:network: > +--rw link* [link-id] > +--rw source > | +--rw source-node? -> ../../../nd:node/node-id > | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ > | ../source-node]/termination-point/tp-id > +--rw destination > | +--rw dest-node? -> ../../../nd:node/node-id > | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+= > | ../dest-node]/termination-point/tp-id > +--rw link-id link-id > +--rw supporting-link* [network-ref link-ref] > +--rw network-ref -> ../../../nd:supporting-network/+ > | network-ref > +--rw link-ref -> /nd:networks/network+ > = [nd:network-id=3Dcurrent()/../network-ref]/+ > link/link-id > =20 > augment /nd:networks/nd:network/nd:node: > +--rw termination-point* [tp-id] > +--rw tp-id tp-id > +--rw supporting-termination-point* [network-ref node-ref = tp-ref] > +--rw network-ref -> = ../../../nd:supporting-node/network-ref > +--rw node-ref -> ../../../nd:supporting-node/node-ref > +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ > current()/../network-ref]/node+ > [nd:node-id=3Dcurrent()/../node-ref]/+ > termination-point/tp-id > =20 > =20 > module: ietf-l3-unicast-topology > augment /nd:networks/nd:network/nd:network-types: > +--rw l3-unicast-topology! > augment /nd:networks/nd:network: > +--rw l3-topology-attributes > +--rw name? string > +--rw flag* l3-flag-type > augment /nd:networks/nd:network/nd:node: > +--rw l3-node-attributes > +--rw name? inet:domain-name > +--rw flag* node-flag-type > +--rw router-id* inet:ip-address > +--rw prefix* [prefix] > +--rw prefix inet:ip-prefix > +--rw metric? uint32 > +--rw flag* prefix-flag-type > augment /nd:networks/nd:network/lnk:link: > +--rw l3-link-attributes > +--rw name? string > +--rw flag* link-flag-type > +--rw metric? uint32 > augment /nd:networks/nd:network/nd:node/lnk:termination-point: > +--rw l3-termination-point-attributes > +--rw (termination-point-type)? > +--:(ip) > | +--rw ip-address* inet:ip-address > +--:(unnumbered) > | +--rw unnumbered-id? uint32 > +--:(interface-name) > +--ro interface-name? string > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com = ]=20 > Sent: Monday, January 23, 2017 6:45 AM > To: Juergen Schoenwaelder > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > =20 > ODL does, indeed, implement the topology models, but generally the = data in the topology model is operational data, so I=E2=80=99m not sure = how that fits with =E2=80=9Cdesigned for the I2RS ephemeral control = plane data store=E2=80=9D - since users don=E2=80=99t write to the = models directly (making validation, priority etc. non-issues). > =20 > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = > wrote: > >=20 > > I thought the topology models are coming more or less from=20 > > OpenDaylight. If so, is ODL and I2RS implementation? > >=20 > > /js > >=20 > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: > >> Juergen:=20 > >>=20 > >> Let's focus on your second point. The topology drafts are I2RS = drafts > >> designed for the I2RS ephemeral control plane data store. How can = these be > >> generic YANG modules when the following is true:=20 > >>=20 > >> 1) I2RS Data models do not utilize the configuration data store, > >> 2) I2RS Data Models do not require the same validation as=20 > >> configuration data store, > >> 3) I2RS Data models require the use of priority to handle the=20 > >> multi-write contention problem into the I2RS Control Plane data=20 > >> store, > >> 4) I2RS require TLS with X.509v3 over TCP for the=20 > >> mandatory-to-implement transport, > >>=20 > >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20= > >> the discussion should be taken up with netmod WG list. > >> Do you disagree with i2rs-protocol-security-requirements? That = issue=20 > >> is closed based on IESG approval. > >>=20 > >> Sue Hares > >>=20 > >> -----Original Message----- > >> From: Juergen Schoenwaelder=20 > >> [mailto:j.schoenwaelder@jacobs-university.de = ] > >> Sent: Monday, January 23, 2017 3:39 AM > >> To: Susan Hares > >> Cc: 'Kathleen Moriarty'; 'The IESG'; > >> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 > >> i2rs-chairs@ietf.org > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >>=20 > >> Susan, > >>=20 > >> I consider tagging a YANG object statically and universally in the=20= > >> data model as "does not need secure communication" fundamentally=20 > >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. > >>=20 > >> The topology drafts are regular generic YANG models that just = happen=20 > >> to be done in I2RS - I believe that using the generic YANG security=20= > >> guidelines we have is good enough to progress these drafts. > >>=20 > >> /js > >>=20 > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > >>> Juergen:=20 > >>>=20 > >>> I recognize that dislike insecure communication. You made a = similar=20 > >>> comment during the WG LC and IETF review of=20 > >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 > >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20= > >>> I2RS WG and approved by the IESG for RFC publication and it = contains=20 > >>> the non-secure communication. The mandate from the I2RS WG for = this=20 > >>> shepherd/co-chair is clear. > >>>=20 > >>> As the shepherd for the topology drafts, I try to write-up = something=20 > >>> that might address Kathleen's Moriarty's concerns about the = topology=20 > >>> draft's security issues about privacy and the I2RS ephemeral = control=20 > >>> plane > >> data > >>> store. I welcome an open discussion on my ideas > >>> = (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = ). > >> The > >>> yang doctor's YANG security consideration template > >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines = ) and=20 > >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. > >>> Hopefully, this document extends these guidelines to a new data = store.=20 > >>>=20 > >>> Cheerily, > >>> Sue Hares > >>>=20 > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de = ] > >>> Sent: Thursday, January 19, 2017 10:34 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 > >>> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 > >>> i2rs-chairs@ietf.org > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >>>=20 > >>> For what it is worth, I find the notion that data models may be=20 > >>> written for a specific non-secure transport plain broken. There is=20= > >>> hardly any content of a data model I can think of which is = generally=20 > >>> suitable for insecure transports. > >>>=20 > >>> Can we please kill this idea of _standardizing_ information that = is=20 > >>> suitable to send over non-secure transports? I really do not see = how=20 > >>> the IETF can make a claim that a given piece of information is = never=20 > >>> worth protecting (=3D suitable for non-secure transports). > >>>=20 > >>> Note that I am fine if in a certain trusted tightly-coupled=20 > >>> deployment information is shipped in whatever way but this is then = a=20 > >>> property of the _deployment_ and not a property of the = _information_. > >>>=20 > >>> /js > >>>=20 > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > >>>> Kathleen:=20 > >>>>=20 > >>>> I have written a draft suggesting a template for the I2RS YANG=20 > >>>> modules > >>> which are designed to exist in the I2RS Ephemeral Control Plane = data store > >>> (configuration and operational state). =20 > >>>>=20 > >>>> Draft location:=20 > >>>> = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = > >>>> / > >>>>=20 > >>>> I would appreciate an email discussion with the security ADs,=20 > >>>> OPS/NM ADs, > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data = model > >>> (L3) and the base I2RS topology model should both provide updated=20= > >>> YANG Security Considerations sections. I would appreciate if = Benoit=20 > >>> or you hold a discuss until we sort out these issues. > >>>>=20 > >>>> Thank you, > >>>>=20 > >>>> Sue > >>>>=20 > >>>> -----Original Message----- > >>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com = ] > >>>> Sent: Wednesday, January 18, 2017 9:44 PM > >>>> To: The IESG > >>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org = ; shares@ndzh.com = ;=20 > >>>> i2rs-chairs@ietf.org ; = shares@ndzh.com ; i2rs@ietf.org = > >>>> Subject: Kathleen Moriarty's No Objection on > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >>>>=20 > >>>> Kathleen Moriarty has entered the following ballot position for > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection > >>>>=20 > >>>> When responding, please keep the subject line intact and reply to=20= > >>>> all email addresses included in the To and CC lines. (Feel free = to=20 > >>>> cut this introductory paragraph, however.) > >>>>=20 > >>>>=20 > >>>> Please refer to > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html = > >>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>=20 > >>>>=20 > >>>> The document, along with other ballot positions, can be found = here: > >>>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ = > >>>>=20 > >>>>=20 > >>>>=20 > >>>> = ------------------------------------------------------------------- > >>>> - > >>>> -- > >>>> COMMENT: > >>>> = ------------------------------------------------------------------- > >>>> - > >>>> -- > >>>>=20 > >>>> I agree with Alissa's comment that the YANG module security=20 > >>>> consideration > >>> section guidelines need to be followed and this shouldn't go = forward=20 > >>> until that is corrected. I'm told it will be, thanks. > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> i2rs mailing list > >>>> i2rs@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/i2rs = > >>>=20 > >>> --=20 > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >>> Fax: +49 421 200 3103 > > >>>=20 > >>=20 > >> --=20 > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >> Fax: +49 421 200 3103 > > >>=20 > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs = --Apple-Mail=_162B8FD7-58AA-4493-8531-AE9426510330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Sue,

On = 23 Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> wrote:

Giles:
 
Thank you = for your comments on ODL and your implementation within ODL.  =  There are two different issues in discussion:  guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.   The guidelines for the I2RS Yang Module = have three security considerations: a)  basic yang = considerations,  b) I2RS ephemeral state considerations, and c) = insecure considerations.   Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

i wasn=E2=80=99t the implementer of those models in = ODL.   But I=E2=80=99ve used them a fair bit.

at any rate applying the I2RS security guidelines = to the I2RS YANG topology model is a bit tricky IMHO as the topology = model doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original = goal of I2RS (ephemeral configuration of RIBs, ACLs etc. on network = elements)

The = topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt = has read/write nodes at the network, link and termination point.  = Please see the copy of the YHL diagrams below. Therefore, the basic = topology model is read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 

Sure - the models are read/write but ODL=E2=80=99= s implementation is generally read-only (as I understand it, it=E2=80=99s = down to each individual protocol or application that leverages the = models to decide whether to use them in read-write or read-only = mode).

1) = NETCONF over TLS with X.509v3 as mandatory to implement protocol, 

most NETCONF implementations I=E2=80=99m aware of = use ssh.

And this is mandatory only = per an individual ID, right?   Or is it in a WG draft now? =  And do we have WG consensus that this applies to read-only data as = well as to read-write?

2) = RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as = a permissible implementation alternative. 

again isn=E2=80=99t that only specified as = mandatory in an individual ID?

3) write contention for two clients writing a node using I2RS = priority (linked to I2RS User-ID) 

so that one isn=E2=80=99t an issue for = read-only implementations=E2=80=A6

If the ODL model does not = support writes to these data models, then it would not have to support = the priority mechanism to resolve two clients writing one data node. =   

indeed.

Giles

A) Basic Yang considerations 
 
1) = readable nodes with sensitive data:  Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.  A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.   Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. =   
 
If the I2RS mandatory transport is utilized, the data streams = utilize mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages" and support "mechanism = that mitigate DoS attacks" and "DDos prevention".  This level of = security is useful when protecting sensitive data.  
 
2) = writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 
 
3) RPCs: = No new RPCs are considered, but providing information on the = notification data may be also useful. 
 
I2RS YANG Model Security Considerations
 
The requirement for this section is the following = information: 
 
1) Indication of deployment requirement for = mandatory-to-implement NETCONF (RFC7589) or optional RESTCONF = (draft-ietf-netconf-restconf), 
2) = Discussion of RPCs specific to I2RS control plane data store, =   
3) NACM policy impacts the read-write state and augmentation = of NACM by access control for read/writing of routing protocols (RACM), =  system information (SACM), and between datastores (config to/from = ephemeral state). 
4) = Discussion of data retrieved from routing protocols, system information, = dynamic configuration (dhcp) 
5) Any = suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state. 
 
For the topology data models (ietf-network, = ietf-network-topology),  the paragraph could be: 
 
=E2=80=9CTh= e I2RS topology data models (ietf-network, ietf-network-topology) = require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of TLS (see RFC7589), or an = optional transport support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model or any = notifications.   
 
NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  
 
For the = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.  Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. =E2=80=9C
 
For the L3 topology data = models (ietf-l3-unicast-topology),  the paragraph could be: 
 
=E2=80=9CTh= e I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of NETCONF over TLS with = X.509v3 mutual authentication (RFC7589), or an optional transport = support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model.  This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event.   These events = provide the information about the changing L3 topology which may provide = information regarding key nodes.  Since these events are only = transported over secure transports that support mutual authentication, = confidentiality, data integrity, and [practice] replay protection, the = use of this information for DoS of an I2RS agent (aka NETCONF server) = requires the mutual authenticated client to be suborned.  
 
NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  
 
For the = L3 topology mode, the access to information on interfaces may be control = by SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.   The L3 Topology model may = also read information from the routing protocols (ospf, isis or others), = or write data to the routing protocol.  RACM policy should be = carefully set so that the routing protocols do not form a place to = launch a DoS attack.  Deployments may provide general configuration = knobs that set the default state for NACM, RACM, SACM and DACM for the = topology database. =E2=80=9C
 
 
Hopefully, this makes the suggestion = for I2RS security policy a bit more = concrete. 
Sue Hares 
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
High-level Yang diagrams for = draft-ietf-i2rs-yang-network-topo-10.txt 
 
      +--rw networks
         +--rw = network* [network-id]
          &nb= sp; +--rw network-types
           =  +--rw = network-id          &nbs= p; network-id
          &nb= sp; +--ro server-provided?      boolean
          &nb= sp; +--rw supporting-network* [network-ref]
          &nb= sp; |  +--rw network-ref    -> = /networks/network/network-id
          &nb= sp; +--rw node* [node-id]
          &nb= sp;    +--rw = node-id            = node-id
          &nb= sp;    +--rw supporting-node* [network-ref node-ref]
          &nb= sp;       +--rw = network-ref    -> ../../../supporting-network/ +
          &nb= sp;       = |            &= nbsp;       network-ref
          &nb= sp;       +--rw = node-ref       -> = /networks/network/node/node-id
 
module: ietf-network-topology
augment = /nd:networks/nd:network:
   +--rw link* [link-id]
      +--rw source
      |  +--rw = source-node?   -> ../../../nd:node/node-id
      |  +--rw = source-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;          = ../source-node]/termination-point/tp-id
      +--rw = destination
      |  +--rw = dest-node?   -> ../../../nd:node/node-id
      |  +--rw = dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;        = ../dest-node]/termination-point/tp-id
      +--rw = link-id            = link-id
      +--rw supporting-link* = [network-ref link-ref]
         +--rw = network-ref    -> ../../../nd:supporting-network/+
         = |            &= nbsp;       network-ref
         +--rw = link-ref       -> = /nd:networks/network+
          &nb= sp;            = ;       = [nd:network-id=3Dcurrent()/../network-ref]/+
          &nb= sp;            = ;       link/link-id
 
augment = /nd:networks/nd:network/nd:node:
   +--rw termination-point* = [tp-id]
      +--rw = tp-id           &nb= sp;            = ;   tp-id
      +--rw = supporting-termination-point* [network-ref node-ref tp-ref]
         +--rw = network-ref    -> = ../../../nd:supporting-node/network-ref
         +--rw = node-ref       -> = ../../../nd:supporting-node/node-ref
         +--rw = tp-ref         -> = /nd:networks/network[nd:network-id=3D+
          &nb= sp;            = ;       = current()/../network-ref]/node+
          &nb= sp;            = ;       = [nd:node-id=3Dcurrent()/../node-ref]/+
          &nb= sp;            = ;       termination-point/tp-id
 
 
   module: ietf-l3-unicast-topology
   augment = /nd:networks/nd:network/nd:network-types:
      +--rw = l3-unicast-topology!
   augment /nd:networks/nd:network:
      +--rw = l3-topology-attributes
         +--rw = name?   string
         +--rw = flag*   l3-flag-type
   augment = /nd:networks/nd:network/nd:node:
      +--rw = l3-node-attributes
         +--rw = name?        inet:domain-name
         +--rw = flag*        node-flag-type
         +--rw = router-id*   inet:ip-address
         +--rw = prefix* [prefix]
          &nb= sp; +--rw prefix    inet:ip-prefix
          &nb= sp; +--rw metric?   uint32
          &nb= sp; +--rw flag*     prefix-flag-type
   augment /nd:networks/nd:network/lnk:link:
      +--rw l3-link-attributes
         +--rw = name?     string
         +--rw = flag*     link-flag-type
         +--rw = metric?   uint32
   augment = /nd:networks/nd:network/nd:node/lnk:termination-point:
      +--rw = l3-termination-point-attributes
         +--rw = (termination-point-type)?
          &nb= sp; +--:(ip)
          &nb= sp; |  +--rw ip-address*      = inet:ip-address
          &nb= sp; +--:(unnumbered)
          &nb= sp; |  +--rw unnumbered-id?   uint32
          &nb= sp; +--:(interface-name)
          &nb= sp;    +--ro interface-name?  string
 
 
 
 
 
-----Original Message-----
From: Giles Heron = [mailto:giles.heron@gmail.com] 
Sent: = Monday, January 23, 2017 6:45 AM
To: Juergen = Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
 
ODL does, indeed, implement the = topology models, but generally the data in the topology model is = operational data, so I=E2=80=99m not sure how that fits with =E2=80=9Cdesi= gned for the I2RS ephemeral control plane data store=E2=80=9D - since = users don=E2=80=99t write to the models directly (making validation, = priority etc. non-issues).
 
> On 23 Jan 2017, at 11:29, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> I = thought the topology models are coming more or less from 
> = OpenDaylight. If so, is ODL and I2RS implementation?
> 
> = /js
> 
> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote:
>> = Juergen: 
>> 
>> = Let's focus on your second point.  The topology drafts are I2RS = drafts
>> designed for the I2RS ephemeral control plane data = store.   How can these be
>> generic YANG modules when the = following is true: 
>> 
>> = 1) I2RS Data models do not utilize the configuration data store,
>> = 2) I2RS Data Models do not require the same validation as 
>> = configuration data store,
>> 3) I2RS Data models require the use of priority to = handle the 
>> = multi-write contention problem into the I2RS Control Plane data 
>> = store,
>> 4) I2RS require TLS with X.509v3 over TCP for = the 
>> = mandatory-to-implement transport,
>> 
>> = Do you disagree with draft-ietf-netmod-revised-datastores?  If = so,  
>> = the discussion should be taken up with netmod WG list.
>> = Do you disagree with i2rs-protocol-security-requirements?  That = issue 
>> = is closed based on IESG approval.
>> 
>> = Sue Hares
>> 
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder 
>> = [mailto:j.schoenwaelder@jacobs-university.de]
>> = Sent: Monday, January 23, 2017 3:39 AM
>> To: Susan Hares
>> = Cc: 'Kathleen Moriarty'; 'The IESG';
>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; 
>> Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on
>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>> 
>> = Susan,
>> 
>> = I consider tagging a YANG object statically and universally in the 
>> = data model as "does not need secure communication" fundamentally 
>> = flawed; I am not having an issue with insecure communication in certain = deployment contexts.
>> 
>> = The topology drafts are regular generic YANG models that just = happen 
>> = to be done in I2RS - I believe that using the generic YANG security 
>> = guidelines we have is good enough to progress these drafts.
>> 
>> = /js
>> 
>> = On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote:
>>> Juergen: 
>>> 
>>> I recognize that dislike insecure = communication.  You made a similar 
>>> comment during the WG LC and IETF review of 
>>> = draft-ietf-i2rs-protocol-security-requirements.  However, the 
>>> draft-ietf-i2rs-protocol-security-requirements = were passed by the 
>>> I2RS WG and approved by the IESG for RFC = publication and it contains 
>>> the non-secure communication.  The mandate = from the I2RS WG for this 
>>> shepherd/co-chair is clear.
>>> 
>>> As the shepherd for the topology drafts, I try = to write-up something 
>>> that might address Kathleen's Moriarty's = concerns about the topology 
>>> draft's security issues about privacy and the = I2RS ephemeral control 
>>> plane
>> data
>>> store.   I welcome an open discussion = on my ideas
>> The
>>> yang doctor's YANG  security consideration = template
>>> the privacy related RFCs (RFC6973) note that = some information is sensitive.
>>> Hopefully, this document = extends these guidelines to a new data store. 
>>> 
>>> Cheerily,
>>> Sue Hares
>>> 
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>> Sent: Thursday, January 19, 2017 10:34 AM
>>> To: Susan Hares
>>> Cc: 'Kathleen Moriarty'; = 'The IESG'; 
>>> Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on
>>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>> 
>>> For what it is worth, I find the notion that = data models may be 
>>> written for a specific non-secure transport = plain broken. There is 
>>> hardly any content of a data model I can think = of which is generally 
>>> suitable for insecure transports.
>>> 
>>> Can we please kill this idea of _standardizing_ = information that is 
>>> suitable to send over non-secure transports? I = really do not see how 
>>> the IETF can make a claim that a given piece of = information is never 
>>> worth protecting (=3D suitable for non-secure = transports).
>>> 
>>> Note that I am fine if in a certain trusted = tightly-coupled 
>>> deployment information is shipped in whatever = way but this is then a 
>>> property of the _deployment_ and not a property = of the _information_.
>>> 
>>> /js
>>> 
>>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan = Hares wrote:
>>>> Kathleen: 
>>>> 
>>>> I have written a draft suggesting a template = for the I2RS YANG 
>>>> modules
>>> which are designed to = exist in the I2RS Ephemeral Control Plane data store
>>> (configuration and operational = state).    
>>>> 
>>>> Draft location: 
>>>> /
>>>> 
>>>> I would appreciate an email discussion with = the security ADs, 
>>>> OPS/NM ADs,
>>> and Routing AD (Alia = Atlas).  I agree that this I2RS YANG data model
>>> (L3) and the base I2RS topology model should = both provide updated 
>>> YANG Security Considerations sections. I would = appreciate if Benoit 
>>> or you hold a discuss until we sort out these = issues.
>>>> 
>>>> Thank you,
>>>> 
>>>> Sue
>>>> 
>>>> -----Original Message-----
>>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
>>>> Sent: Wednesday, January 18, 2017 9:44 = PM
>>>> To: The IESG
>>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; 
>>>> Subject: Kathleen Moriarty's No Objection = on
>>>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
>>>> 
>>>> Kathleen Moriarty has entered the following = ballot position for
>>>> draft-ietf-i2rs-yang-l3-topology-08: No = Objection
>>>> 
>>>> When responding, please keep the subject = line intact and reply to 
>>>> all email addresses included in the To and = CC lines. (Feel free to 
>>>> cut this introductory paragraph, = however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> for more information about IESG DISCUSS and = COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot = positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo= gy/
>>>> 
>>>> 
>>>> 
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> COMMENT:
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
>>>> I agree with Alissa's comment that the YANG = module security 
>>>> consideration
>>> section guidelines need to = be followed and this shouldn't go forward 
>>> until that is corrected.  I'm told it will = be, thanks.
>>>> 
>>>> 
>>>> 
>>>> = _______________________________________________
>>>> i2rs mailing list
>>> 
>>> -- 
>>> Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>>> 
>> 
>> = -- 
>> = Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>> 
> 
> = -- 
> = Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
> 
> = _______________________________________________
> i2rs = mailing list
> https://www.ietf.org/mailman/listinfo/i2rs

= --Apple-Mail=_162B8FD7-58AA-4493-8531-AE9426510330-- From nobody Mon Jan 23 08:30:38 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 8C11A129599; Mon, 23 Jan 2017 08:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXrl98TonTE3; Mon, 23 Jan 2017 08:30:29 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B7C12959B; Mon, 23 Jan 2017 08:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1485188953; bh=zTFP29XeSx+LZ3YCszzcEDYVwawlJfS6djEkvZurdVI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XWnPm4U70aUOUUiVeEeN+kfjBTJU0qfbLDg46L9WnsP4VHKMQqmtqVApezr659zF/ rsGGIdk1hW9j26w57EgcdFF3eozi6aTaUknD0td7DqOWkFOIDh+6zFetsF2DZKPHMt HFDdQ2R0ZIVU/4F0QJzMAJlQO/fr7XG0Z4hVmaxc= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_C46BEAF2-8ACA-41E1-BADE-B3F21B59697A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> Date: Mon, 23 Jan 2017 11:30:05 -0500 Message-Id: <6340C9C8-F2BA-4F3D-B7EE-3D9279AE6004@lucidvision.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> To: Giles Heron X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 619, in=4701, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG , Susan Hares Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 16:30:32 -0000 --Apple-Mail=_C46BEAF2-8ACA-41E1-BADE-B3F21B59697A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 23, 2017:11:25 AM, at 11:25 AM, Giles Heron = wrote: >=20 > Hi Sue, >=20 >> On 23 Jan 2017, at 14:40, Susan Hares > wrote: >>=20 >> Giles: >> =20 >> Thank you for your comments on ODL and your implementation within = ODL. There are two different issues in discussion: guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model. The guidelines for the I2RS Yang Module have = three security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). >=20 > i wasn=E2=80=99t the implementer of those models in ODL. But I=E2=80=99= ve used them a fair bit. >=20 > at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model doesn=E2=80=99t = really =E2=80=9Cfit=E2=80=9D with the original goal of I2RS (ephemeral = configuration of RIBs, ACLs etc. on network elements) I totally agree. The model was and is currently used as just = that and without any of the I2RS semantics. There are examples other = than ODL too. >>=20 >> The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 >=20 > Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). >=20 >> 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20= >=20 > most NETCONF implementations I=E2=80=99m aware of use ssh. +1. Again this is a model. Trying to hoist semantics from I2RS = is ill advised as the model is used in many places that are absent of = anything I2RS. =E2=80=94Tom > And this is mandatory only per an individual ID, right? Or is it in = a WG draft now? And do we have WG consensus that this applies to = read-only data as well as to read-write? >=20 >> 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual = authentication as a permissible implementation alternative.=20 >=20 > again isn=E2=80=99t that only specified as mandatory in an individual = ID? >=20 >> 3) write contention for two clients writing a node using I2RS = priority (linked to I2RS User-ID)=20 >=20 > so that one isn=E2=80=99t an issue for read-only implementations=E2=80=A6= >=20 >> If the ODL model does not support writes to these data models, then = it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 >=20 > indeed. >=20 > Giles >=20 >> A) Basic Yang considerations=20 >> =20 >> 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 >> =20 >> If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 >> =20 >> 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 >> =20 >> 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 >> =20 >> I2RS YANG Model Security Considerations >> =20 >> The requirement for this section is the following information:=20 >> =20 >> 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 >> 2) Discussion of RPCs specific to I2RS control plane data store, =20 >> 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 >> 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 >> 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 >> =20 >> For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 >> =20 >> =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20= >> =20 >> NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 >> =20 >> For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C >> =20 >> For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 >> =20 >> =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 >> =20 >> NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 >> =20 >> For the L3 topology mode, the access to information on interfaces may = be control by SACM related to the interface model. Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol. RACM policy should be carefully set so = that the routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C >> =20 >> =20 >> Hopefully, this makes the suggestion for I2RS security policy a bit = more concrete.=20 >=20 >> Sue Hares=20 >> =20 >> =20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20= >> =20 >> +--rw networks >> +--rw network* [network-id] >> +--rw network-types >> +--rw network-id network-id >> +--ro server-provided? boolean >> +--rw supporting-network* [network-ref] >> | +--rw network-ref -> /networks/network/network-id >> +--rw node* [node-id] >> +--rw node-id node-id >> +--rw supporting-node* [network-ref node-ref] >> +--rw network-ref -> = ../../../supporting-network/ + >> | network-ref >> +--rw node-ref -> = /networks/network/node/node-id >> =20 >> module: ietf-network-topology >> augment /nd:networks/nd:network: >> +--rw link* [link-id] >> +--rw source >> | +--rw source-node? -> ../../../nd:node/node-id >> | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >> | ../source-node]/termination-point/tp-id >> +--rw destination >> | +--rw dest-node? -> ../../../nd:node/node-id >> | +--rw dest-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >> | ../dest-node]/termination-point/tp-id >> +--rw link-id link-id >> +--rw supporting-link* [network-ref link-ref] >> +--rw network-ref -> ../../../nd:supporting-network/+ >> | network-ref >> +--rw link-ref -> /nd:networks/network+ >> = [nd:network-id=3Dcurrent()/../network-ref]/+ >> link/link-id >> =20 >> augment /nd:networks/nd:network/nd:node: >> +--rw termination-point* [tp-id] >> +--rw tp-id tp-id >> +--rw supporting-termination-point* [network-ref node-ref = tp-ref] >> +--rw network-ref -> = ../../../nd:supporting-node/network-ref >> +--rw node-ref -> ../../../nd:supporting-node/node-ref >> +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+= >> current()/../network-ref]/node+ >> [nd:node-id=3Dcurrent()/../node-ref]/+ >> termination-point/tp-id >> =20 >> =20 >> module: ietf-l3-unicast-topology >> augment /nd:networks/nd:network/nd:network-types: >> +--rw l3-unicast-topology! >> augment /nd:networks/nd:network: >> +--rw l3-topology-attributes >> +--rw name? string >> +--rw flag* l3-flag-type >> augment /nd:networks/nd:network/nd:node: >> +--rw l3-node-attributes >> +--rw name? inet:domain-name >> +--rw flag* node-flag-type >> +--rw router-id* inet:ip-address >> +--rw prefix* [prefix] >> +--rw prefix inet:ip-prefix >> +--rw metric? uint32 >> +--rw flag* prefix-flag-type >> augment /nd:networks/nd:network/lnk:link: >> +--rw l3-link-attributes >> +--rw name? string >> +--rw flag* link-flag-type >> +--rw metric? uint32 >> augment /nd:networks/nd:network/nd:node/lnk:termination-point: >> +--rw l3-termination-point-attributes >> +--rw (termination-point-type)? >> +--:(ip) >> | +--rw ip-address* inet:ip-address >> +--:(unnumbered) >> | +--rw unnumbered-id? uint32 >> +--:(interface-name) >> +--ro interface-name? string >> =20 >> =20 >> =20 >> =20 >> =20 >> -----Original Message----- >> From: Giles Heron [mailto:giles.heron@gmail.com = ]=20 >> Sent: Monday, January 23, 2017 6:45 AM >> To: Juergen Schoenwaelder >> Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> =20 >> ODL does, indeed, implement the topology models, but generally the = data in the topology model is operational data, so I=E2=80=99m not sure = how that fits with =E2=80=9Cdesigned for the I2RS ephemeral control = plane data store=E2=80=9D - since users don=E2=80=99t write to the = models directly (making validation, priority etc. non-issues). >> =20 >> > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = > wrote: >> >=20 >> > I thought the topology models are coming more or less from=20 >> > OpenDaylight. If so, is ODL and I2RS implementation? >> >=20 >> > /js >> >=20 >> > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> >> Juergen:=20 >> >>=20 >> >> Let's focus on your second point. The topology drafts are I2RS = drafts >> >> designed for the I2RS ephemeral control plane data store. How = can these be >> >> generic YANG modules when the following is true:=20 >> >>=20 >> >> 1) I2RS Data models do not utilize the configuration data store, >> >> 2) I2RS Data Models do not require the same validation as=20 >> >> configuration data store, >> >> 3) I2RS Data models require the use of priority to handle the=20 >> >> multi-write contention problem into the I2RS Control Plane data=20 >> >> store, >> >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> >> mandatory-to-implement transport, >> >>=20 >> >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, = =20 >> >> the discussion should be taken up with netmod WG list. >> >> Do you disagree with i2rs-protocol-security-requirements? That = issue=20 >> >> is closed based on IESG approval. >> >>=20 >> >> Sue Hares >> >>=20 >> >> -----Original Message----- >> >> From: Juergen Schoenwaelder=20 >> >> [mailto:j.schoenwaelder@jacobs-university.de = ] >> >> Sent: Monday, January 23, 2017 3:39 AM >> >> To: Susan Hares >> >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> >> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 >> >> i2rs-chairs@ietf.org >> >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>=20 >> >> Susan, >> >>=20 >> >> I consider tagging a YANG object statically and universally in the=20= >> >> data model as "does not need secure communication" fundamentally=20= >> >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >> >>=20 >> >> The topology drafts are regular generic YANG models that just = happen=20 >> >> to be done in I2RS - I believe that using the generic YANG = security=20 >> >> guidelines we have is good enough to progress these drafts. >> >>=20 >> >> /js >> >>=20 >> >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >> >>> Juergen:=20 >> >>>=20 >> >>> I recognize that dislike insecure communication. You made a = similar=20 >> >>> comment during the WG LC and IETF review of=20 >> >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >> >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20= >> >>> I2RS WG and approved by the IESG for RFC publication and it = contains=20 >> >>> the non-secure communication. The mandate from the I2RS WG for = this=20 >> >>> shepherd/co-chair is clear. >> >>>=20 >> >>> As the shepherd for the topology drafts, I try to write-up = something=20 >> >>> that might address Kathleen's Moriarty's concerns about the = topology=20 >> >>> draft's security issues about privacy and the I2RS ephemeral = control=20 >> >>> plane >> >> data >> >>> store. I welcome an open discussion on my ideas >> >>> = (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = ). >> >> The >> >>> yang doctor's YANG security consideration template >> >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines = ) and=20 >> >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >> >>> Hopefully, this document extends these guidelines to a new data = store.=20 >> >>>=20 >> >>> Cheerily, >> >>> Sue Hares >> >>>=20 >> >>> -----Original Message----- >> >>> From: Juergen Schoenwaelder >> >>> [mailto:j.schoenwaelder@jacobs-university.de = ] >> >>> Sent: Thursday, January 19, 2017 10:34 AM >> >>> To: Susan Hares >> >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >> >>> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 >> >>> i2rs-chairs@ietf.org >> >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>>=20 >> >>> For what it is worth, I find the notion that data models may be=20= >> >>> written for a specific non-secure transport plain broken. There = is=20 >> >>> hardly any content of a data model I can think of which is = generally=20 >> >>> suitable for insecure transports. >> >>>=20 >> >>> Can we please kill this idea of _standardizing_ information that = is=20 >> >>> suitable to send over non-secure transports? I really do not see = how=20 >> >>> the IETF can make a claim that a given piece of information is = never=20 >> >>> worth protecting (=3D suitable for non-secure transports). >> >>>=20 >> >>> Note that I am fine if in a certain trusted tightly-coupled=20 >> >>> deployment information is shipped in whatever way but this is = then a=20 >> >>> property of the _deployment_ and not a property of the = _information_. >> >>>=20 >> >>> /js >> >>>=20 >> >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >> >>>> Kathleen:=20 >> >>>>=20 >> >>>> I have written a draft suggesting a template for the I2RS YANG=20= >> >>>> modules >> >>> which are designed to exist in the I2RS Ephemeral Control Plane = data store >> >>> (configuration and operational state). =20 >> >>>>=20 >> >>>> Draft location:=20 >> >>>> = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = >> >>>> / >> >>>>=20 >> >>>> I would appreciate an email discussion with the security ADs,=20 >> >>>> OPS/NM ADs, >> >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data = model >> >>> (L3) and the base I2RS topology model should both provide updated=20= >> >>> YANG Security Considerations sections. I would appreciate if = Benoit=20 >> >>> or you hold a discuss until we sort out these issues. >> >>>>=20 >> >>>> Thank you, >> >>>>=20 >> >>>> Sue >> >>>>=20 >> >>>> -----Original Message----- >> >>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com = ] >> >>>> Sent: Wednesday, January 18, 2017 9:44 PM >> >>>> To: The IESG >> >>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org = ; shares@ndzh.com = ;=20 >> >>>> i2rs-chairs@ietf.org ; = shares@ndzh.com ; i2rs@ietf.org = >> >>>> Subject: Kathleen Moriarty's No Objection on >> >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>>>=20 >> >>>> Kathleen Moriarty has entered the following ballot position for >> >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >> >>>>=20 >> >>>> When responding, please keep the subject line intact and reply = to=20 >> >>>> all email addresses included in the To and CC lines. (Feel free = to=20 >> >>>> cut this introductory paragraph, however.) >> >>>>=20 >> >>>>=20 >> >>>> Please refer to >> >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html = >> >>>> for more information about IESG DISCUSS and COMMENT positions. >> >>>>=20 >> >>>>=20 >> >>>> The document, along with other ballot positions, can be found = here: >> >>>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ = >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> = ------------------------------------------------------------------- >> >>>> - >> >>>> -- >> >>>> COMMENT: >> >>>> = ------------------------------------------------------------------- >> >>>> - >> >>>> -- >> >>>>=20 >> >>>> I agree with Alissa's comment that the YANG module security=20 >> >>>> consideration >> >>> section guidelines need to be followed and this shouldn't go = forward=20 >> >>> until that is corrected. I'm told it will be, thanks. >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> _______________________________________________ >> >>>> i2rs mailing list >> >>>> i2rs@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/i2rs = >> >>>=20 >> >>> --=20 >> >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> >>> Fax: +49 421 200 3103 > >> >>>=20 >> >>=20 >> >> --=20 >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> >> Fax: +49 421 200 3103 > >> >>=20 >> >=20 >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> > Fax: +49 421 200 3103 > >> >=20 >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs = > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_C46BEAF2-8ACA-41E1-BADE-B3F21B59697A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 23, 2017:11:25 AM, at 11:25 AM, Giles Heron <giles.heron@gmail.com> wrote:

Hi Sue,

On 23 = Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> wrote:

Giles:
 
Thank you = for your comments on ODL and your implementation within ODL.  =  There are two different issues in discussion:  guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.   The guidelines for the I2RS Yang Module = have three security considerations: a)  basic yang = considerations,  b) I2RS ephemeral state considerations, and c) = insecure considerations.   Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

i wasn=E2=80=99t the implementer of those models in = ODL.   But I=E2=80=99ve used them a fair bit.

at any rate applying the = I2RS security guidelines to the I2RS YANG topology model is a bit tricky = IMHO as the topology model doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D = with the original goal of I2RS (ephemeral configuration of RIBs, ACLs = etc. on network elements)

= I totally agree. The model was and is currently used as = just that and without any of the I2RS semantics.  There are = examples other than ODL too.


The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point.  Please see the copy of the = YHL diagrams below. Therefore, the basic topology model is = read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 

Sure - the models are = read/write but ODL=E2=80=99s implementation is generally read-only (as I = understand it, it=E2=80=99s down to each individual protocol or = application that leverages the models to decide whether to use them in = read-write or read-only mode).

1) NETCONF over TLS with = X.509v3 as mandatory to implement protocol, 

most NETCONF implementations I=E2=80=99m = aware of use ssh.

+1.  Again this is a model. = Trying to hoist semantics from I2RS is ill advised as the model is used = in many places that are absent of anything I2RS.

=E2=80=94Tom


And this is mandatory only per an individual ID, right? =   Or is it in a WG draft now?  And do we have WG consensus = that this applies to read-only data as well as to read-write?

2) = RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as = a permissible implementation alternative. 

again isn=E2=80=99t that only specified = as mandatory in an individual = ID?

3) write = contention for two clients writing a node using I2RS priority (linked to = I2RS User-ID) 

so that one isn=E2=80=99t= an issue for read-only implementations=E2=80=A6

If the = ODL model does not support writes to these data models, then it would = not have to support the priority mechanism to resolve two clients = writing one data node.   

indeed.

Giles

A) Basic = Yang considerations 
 
1) = readable nodes with sensitive data:  Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.  A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.   Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. =   
 
If the I2RS mandatory transport is utilized, the data streams = utilize mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages" and support "mechanism = that mitigate DoS attacks" and "DDos prevention".  This level of = security is useful when protecting sensitive data.  
 
2) = writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 
 
3) RPCs: = No new RPCs are considered, but providing information on the = notification data may be also useful. 
 
I2RS YANG Model Security Considerations
 
The requirement for this section is the following = information: 
 
1) Indication of deployment requirement for = mandatory-to-implement NETCONF (RFC7589) or optional RESTCONF = (draft-ietf-netconf-restconf), 
2) = Discussion of RPCs specific to I2RS control plane data store, =   
3) NACM policy impacts the read-write state and augmentation = of NACM by access control for read/writing of routing protocols (RACM), =  system information (SACM), and between datastores (config to/from = ephemeral state). 
4) = Discussion of data retrieved from routing protocols, system information, = dynamic configuration (dhcp) 
5) Any = suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state. 
 
For the topology data models (ietf-network, = ietf-network-topology),  the paragraph could be: 
 
=E2=80=9CTh= e I2RS topology data models (ietf-network, ietf-network-topology) = require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of TLS (see RFC7589), or an = optional transport support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model or any = notifications.   
 
NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  
 
For the = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.  Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. =E2=80=9C
 
For the L3 topology data = models (ietf-l3-unicast-topology),  the paragraph could be: 
 
=E2=80=9CTh= e I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of NETCONF over TLS with = X.509v3 mutual authentication (RFC7589), or an optional transport = support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model.  This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event.   These events = provide the information about the changing L3 topology which may provide = information regarding key nodes.  Since these events are only = transported over secure transports that support mutual authentication, = confidentiality, data integrity, and [practice] replay protection, the = use of this information for DoS of an I2RS agent (aka NETCONF server) = requires the mutual authenticated client to be suborned.  
 
NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  
 
For the = L3 topology mode, the access to information on interfaces may be control = by SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.   The L3 Topology model may = also read information from the routing protocols (ospf, isis or others), = or write data to the routing protocol.  RACM policy should be = carefully set so that the routing protocols do not form a place to = launch a DoS attack.  Deployments may provide general configuration = knobs that set the default state for NACM, RACM, SACM and DACM for the = topology database. =E2=80=9C
 
 
Hopefully, this makes the suggestion = for I2RS security policy a bit more = concrete. 
Sue Hares 
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
High-level Yang diagrams for = draft-ietf-i2rs-yang-network-topo-10.txt 
 
      +--rw networks
         +--rw = network* [network-id]
          &nb= sp; +--rw network-types
           =  +--rw = network-id          &nbs= p; network-id
          &nb= sp; +--ro server-provided?      boolean
          &nb= sp; +--rw supporting-network* [network-ref]
          &nb= sp; |  +--rw network-ref    -> = /networks/network/network-id
          &nb= sp; +--rw node* [node-id]
          &nb= sp;    +--rw = node-id            = node-id
          &nb= sp;    +--rw supporting-node* [network-ref node-ref]
          &nb= sp;       +--rw = network-ref    -> ../../../supporting-network/ +
          &nb= sp;       = |            &= nbsp;       network-ref
          &nb= sp;       +--rw = node-ref       -> = /networks/network/node/node-id
 
module: ietf-network-topology
augment = /nd:networks/nd:network:
   +--rw link* [link-id]
      +--rw source
      |  +--rw = source-node?   -> ../../../nd:node/node-id
      |  +--rw = source-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;          = ../source-node]/termination-point/tp-id
      +--rw = destination
      |  +--rw = dest-node?   -> ../../../nd:node/node-id
      |  +--rw = dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;        = ../dest-node]/termination-point/tp-id
      +--rw = link-id            = link-id
      +--rw supporting-link* = [network-ref link-ref]
         +--rw = network-ref    -> ../../../nd:supporting-network/+
         = |            &= nbsp;       network-ref
         +--rw = link-ref       -> = /nd:networks/network+
          &nb= sp;            = ;       = [nd:network-id=3Dcurrent()/../network-ref]/+
          &nb= sp;            = ;       link/link-id
 
augment = /nd:networks/nd:network/nd:node:
   +--rw termination-point* = [tp-id]
      +--rw = tp-id           &nb= sp;            = ;   tp-id
      +--rw = supporting-termination-point* [network-ref node-ref tp-ref]
         +--rw = network-ref    -> = ../../../nd:supporting-node/network-ref
         +--rw = node-ref       -> = ../../../nd:supporting-node/node-ref
         +--rw = tp-ref         -> = /nd:networks/network[nd:network-id=3D+
          &nb= sp;            = ;       = current()/../network-ref]/node+
          &nb= sp;            = ;       = [nd:node-id=3Dcurrent()/../node-ref]/+
          &nb= sp;            = ;       termination-point/tp-id
 
 
   module: ietf-l3-unicast-topology
   augment = /nd:networks/nd:network/nd:network-types:
      +--rw = l3-unicast-topology!
   augment /nd:networks/nd:network:
      +--rw = l3-topology-attributes
         +--rw = name?   string
         +--rw = flag*   l3-flag-type
   augment = /nd:networks/nd:network/nd:node:
      +--rw = l3-node-attributes
         +--rw = name?        inet:domain-name
         +--rw = flag*        node-flag-type
         +--rw = router-id*   inet:ip-address
         +--rw = prefix* [prefix]
          &nb= sp; +--rw prefix    inet:ip-prefix
          &nb= sp; +--rw metric?   uint32
          &nb= sp; +--rw flag*     prefix-flag-type
   augment /nd:networks/nd:network/lnk:link:
      +--rw l3-link-attributes
         +--rw = name?     string
         +--rw = flag*     link-flag-type
         +--rw = metric?   uint32
   augment = /nd:networks/nd:network/nd:node/lnk:termination-point:
      +--rw = l3-termination-point-attributes
         +--rw = (termination-point-type)?
          &nb= sp; +--:(ip)
          &nb= sp; |  +--rw ip-address*      = inet:ip-address
          &nb= sp; +--:(unnumbered)
          &nb= sp; |  +--rw unnumbered-id?   uint32
          &nb= sp; +--:(interface-name)
          &nb= sp;    +--ro interface-name?  string
 
 
 
 
 
-----Original Message-----
From: Giles Heron = [mailto:giles.heron@gmail.com] 
Sent: = Monday, January 23, 2017 6:45 AM
To: Juergen = Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
 
ODL does, indeed, implement the = topology models, but generally the data in the topology model is = operational data, so I=E2=80=99m not sure how that fits with =E2=80=9Cdesi= gned for the I2RS ephemeral control plane data store=E2=80=9D - since = users don=E2=80=99t write to the models directly (making validation, = priority etc. non-issues).
 
> On 23 Jan 2017, at 11:29, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> I = thought the topology models are coming more or less from 
> = OpenDaylight. If so, is ODL and I2RS implementation?
> 
> = /js
> 
> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote:
>> = Juergen: 
>> 
>> = Let's focus on your second point.  The topology drafts are I2RS = drafts
>> designed for the I2RS ephemeral control plane data = store.   How can these be
>> generic YANG modules when the = following is true: 
>> 
>> = 1) I2RS Data models do not utilize the configuration data store,
>> = 2) I2RS Data Models do not require the same validation as 
>> = configuration data store,
>> 3) I2RS Data models require the use of priority to = handle the 
>> = multi-write contention problem into the I2RS Control Plane data 
>> = store,
>> 4) I2RS require TLS with X.509v3 over TCP for = the 
>> = mandatory-to-implement transport,
>> 
>> = Do you disagree with draft-ietf-netmod-revised-datastores?  If = so,  
>> = the discussion should be taken up with netmod WG list.
>> = Do you disagree with i2rs-protocol-security-requirements?  That = issue 
>> = is closed based on IESG approval.
>> 
>> = Sue Hares
>> 
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder 
>> = [mailto:j.schoenwaelder@jacobs-university.de]
>> = Sent: Monday, January 23, 2017 3:39 AM
>> To: Susan Hares
>> = Cc: 'Kathleen Moriarty'; 'The IESG';
>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; 
>> Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on
>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>> 
>> = Susan,
>> 
>> = I consider tagging a YANG object statically and universally in the 
>> = data model as "does not need secure communication" fundamentally 
>> = flawed; I am not having an issue with insecure communication in certain = deployment contexts.
>> 
>> = The topology drafts are regular generic YANG models that just = happen 
>> = to be done in I2RS - I believe that using the generic YANG security 
>> = guidelines we have is good enough to progress these drafts.
>> 
>> = /js
>> 
>> = On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote:
>>> Juergen: 
>>> 
>>> I recognize that dislike insecure = communication.  You made a similar 
>>> comment during the WG LC and IETF review of 
>>> = draft-ietf-i2rs-protocol-security-requirements.  However, the 
>>> draft-ietf-i2rs-protocol-security-requirements = were passed by the 
>>> I2RS WG and approved by the IESG for RFC = publication and it contains 
>>> the non-secure communication.  The mandate = from the I2RS WG for this 
>>> shepherd/co-chair is clear.
>>> 
>>> As the shepherd for the topology drafts, I try = to write-up something 
>>> that might address Kathleen's Moriarty's = concerns about the topology 
>>> draft's security issues about privacy and the = I2RS ephemeral control 
>>> plane
>> data
>>> store.   I welcome an open discussion = on my ideas
>> The
>>> yang doctor's YANG  security consideration = template
>>> the privacy related RFCs (RFC6973) note that = some information is sensitive.
>>> Hopefully, this document = extends these guidelines to a new data store. 
>>> 
>>> Cheerily,
>>> Sue Hares
>>> 
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>> Sent: Thursday, January 19, 2017 10:34 AM
>>> To: Susan Hares
>>> Cc: 'Kathleen Moriarty'; = 'The IESG'; 
>>> Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on
>>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>> 
>>> For what it is worth, I find the notion that = data models may be 
>>> written for a specific non-secure transport = plain broken. There is 
>>> hardly any content of a data model I can think = of which is generally 
>>> suitable for insecure transports.
>>> 
>>> Can we please kill this idea of _standardizing_ = information that is 
>>> suitable to send over non-secure transports? I = really do not see how 
>>> the IETF can make a claim that a given piece of = information is never 
>>> worth protecting (=3D suitable for non-secure = transports).
>>> 
>>> Note that I am fine if in a certain trusted = tightly-coupled 
>>> deployment information is shipped in whatever = way but this is then a 
>>> property of the _deployment_ and not a property = of the _information_.
>>> 
>>> /js
>>> 
>>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan = Hares wrote:
>>>> Kathleen: 
>>>> 
>>>> I have written a draft suggesting a template = for the I2RS YANG 
>>>> modules
>>> which are designed to = exist in the I2RS Ephemeral Control Plane data store
>>> (configuration and operational = state).    
>>>> 
>>>> Draft location: 
>>>> /
>>>> 
>>>> I would appreciate an email discussion with = the security ADs, 
>>>> OPS/NM ADs,
>>> and Routing AD (Alia = Atlas).  I agree that this I2RS YANG data model
>>> (L3) and the base I2RS topology model should = both provide updated 
>>> YANG Security Considerations sections. I would = appreciate if Benoit 
>>> or you hold a discuss until we sort out these = issues.
>>>> 
>>>> Thank you,
>>>> 
>>>> Sue
>>>> 
>>>> -----Original Message-----
>>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
>>>> Sent: Wednesday, January 18, 2017 9:44 = PM
>>>> To: The IESG
>>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; 
>>>> Subject: Kathleen Moriarty's No Objection = on
>>>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
>>>> 
>>>> Kathleen Moriarty has entered the following = ballot position for
>>>> draft-ietf-i2rs-yang-l3-topology-08: No = Objection
>>>> 
>>>> When responding, please keep the subject = line intact and reply to 
>>>> all email addresses included in the To and = CC lines. (Feel free to 
>>>> cut this introductory paragraph, = however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> for more information about IESG DISCUSS and = COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot = positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo= gy/
>>>> 
>>>> 
>>>> 
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> COMMENT:
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
>>>> I agree with Alissa's comment that the YANG = module security 
>>>> consideration
>>> section guidelines need to = be followed and this shouldn't go forward 
>>> until that is corrected.  I'm told it will = be, thanks.
>>>> 
>>>> 
>>>> 
>>>> = _______________________________________________
>>>> i2rs mailing list
>>> 
>>> -- 
>>> Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>>> 
>> 
>> = -- 
>> = Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>> 
> 
> = -- 
> = Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
> 
> = _______________________________________________
> i2rs = mailing list
> https://www.ietf.org/mailman/listinfo/i2rs

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

= --Apple-Mail=_C46BEAF2-8ACA-41E1-BADE-B3F21B59697A-- From nobody Mon Jan 23 08:59:01 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 638B91295A9; Mon, 23 Jan 2017 08:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 e67ygMCnHrky; Mon, 23 Jan 2017 08:58:56 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED9012959A; Mon, 23 Jan 2017 08:58:56 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Giles Heron'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> In-Reply-To: <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> Date: Mon, 23 Jan 2017 11:54:41 -0500 Message-ID: <007901d27599$649e0790$2dda16b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01D2756F.7BD32320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+AvYiyDYB8tFV9gI6fU8pAp4O91MClGFhQKBNtbNA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 16:58:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007A_01D2756F.7BD32320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Giles:=20 =20 I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals. It is a protocol independent model with information on = topology. This was in the original use cases and has been a focus for = I2RS WG. See rest of the responses below.=20 =20 The real change for RFC compliance for ODL=E2=80=99s read-only Topology = model would be: a) use of NETCONF over TLS with X.509v3 authentication, = b) denoting the =E2=80=9Cdynamic control plane data store=E2=80=9D in = the get applied (whenever that gets implemented), and support of the = opaque secondary identity in tracing (if you support tracing). The = change for the RFC compliance for the ODL=E2=80=99s read-write would be = the utilizing priority to resolve contention if multiple clients try to = write the topology database. The priority could be set per user = identifier (passed in X.509v3) in a pre-configuration set-up stored. = Ideally this pre-configuration would be stored in a key store or = something that is secure. =20 Sue=20 =20 =20 Fr om: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 11:26 AM To: Susan Hares Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi Sue, =20 On 23 Jan 2017, at 14:40, Susan Hares wrote: =20 Giles: =20 Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang = modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). =20 i wasn=E2=80=99t the implementer of those models in ODL. But = I=E2=80=99ve used them a fair bit. =20 at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network elements) . =20 [Sue]: No, the topology model was part of the original I2RS YANG = modules, and the Topology models (L2, L3, Base) fit its ue.=20 =20 The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 =20 Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). =20 [Sue]: This fits the I2RS Yang module.=20 =20 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20 =20 Giles: most NETCONF implementations I=E2=80=99m aware of use ssh. And = this is mandatory only per an individual ID, right? Or is it in a WG = draft now? And do we have WG consensus that this applies to read-only = data as well as to read-write? =20 Sue: NETCONF over TLS with X.509v3 is an RFC 7589. I2RS is requiring = this to get mutual authentication, confidentiality, data integrity, = [practical] reply protection for I2RS messages, and support DoS = mitigation. This mandatory-to-implement status is a change from the = basic NETCONF over SSH.=20 =20 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication = as a permissible implementation alternative.=20 =20 Giles: again isn=E2=80=99t that only specified as mandatory in an = individual ID? Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. Therefore, the RESTCONF protocol is an alternative = since it supports this with its basic work.=20 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 =20 Giles: so that one isn=E2=80=99t an issue for read-only = implementations=E2=80=A6 Sue: Yes. You are correct.=20 =20 Sue: If the ODL model does not support writes to these data models, then = it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 Giles: indeed. Sue: No other responses are below=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A) Basic Yang considerations=20 =20 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 =20 If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 =20 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 =20 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 =20 I2RS YANG Model Security Considerations =20 The requirement for this section is the following information:=20 =20 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 2) Discussion of RPCs specific to I2RS control plane data store, =20 3) NACM policy impacts the read-write state and augmentation of NACM by = access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 =20 For the topology data models (ietf-network, ietf-network-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C =20 For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. The L3 Topology model may also read information from = the routing protocols (ospf, isis or others), or write data to the = routing protocol. RACM policy should be carefully set so that the = routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C =20 =20 Hopefully, this makes the suggestion for I2RS security policy a bit more = concrete.=20 Sue Hares=20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20 =20 +--rw networks +--rw network* [network-id] +--rw network-types +--rw network-id network-id +--ro server-provided? boolean +--rw supporting-network* [network-ref] | +--rw network-ref -> /networks/network/network-id +--rw node* [node-id] +--rw node-id node-id +--rw supporting-node* [network-ref node-ref] +--rw network-ref -> ../../../supporting-network/ + | network-ref +--rw node-ref -> /networks/network/node/node-id =20 module: ietf-network-topology augment /nd:networks/nd:network: +--rw link* [link-id] +--rw source | +--rw source-node? -> ../../../nd:node/node-id | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../source-node]/termination-point/tp-id +--rw destination | +--rw dest-node? -> ../../../nd:node/node-id | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../dest-node]/termination-point/tp-id +--rw link-id link-id +--rw supporting-link* [network-ref link-ref] +--rw network-ref -> ../../../nd:supporting-network/+ | network-ref +--rw link-ref -> /nd:networks/network+ = [nd:network-id=3Dcurrent()/../network-ref]/+ link/link-id =20 augment /nd:networks/nd:network/nd:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ current()/../network-ref]/node+ [nd:node-id=3Dcurrent()/../node-ref]/+ termination-point/tp-id =20 =20 module: ietf-l3-unicast-topology augment /nd:networks/nd:network/nd:network-types: +--rw l3-unicast-topology! augment /nd:networks/nd:network: +--rw l3-topology-attributes +--rw name? string +--rw flag* l3-flag-type augment /nd:networks/nd:network/nd:node: +--rw l3-node-attributes +--rw name? inet:domain-name +--rw flag* node-flag-type +--rw router-id* inet:ip-address +--rw prefix* [prefix] +--rw prefix inet:ip-prefix +--rw metric? uint32 +--rw flag* prefix-flag-type augment /nd:networks/nd:network/lnk:link: +--rw l3-link-attributes +--rw name? string +--rw flag* link-flag-type +--rw metric? uint32 augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) | +--rw unnumbered-id? uint32 +--:(interface-name) +--ro interface-name? string =20 =20 =20 =20 =20 -----Original Message----- From: Giles Heron [ = mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 6:45 AM To: Juergen Schoenwaelder Cc: Susan Hares; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 ODL does, indeed, implement the topology models, but generally the data = in the topology model is operational data, so I=E2=80=99m not sure how = that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making validation, priority etc. non-issues). =20 > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder < = = j.schoenwaelder@jacobs-university.de> wrote: >=20 > I thought the topology models are coming more or less from=20 > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > /js >=20 > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> Juergen:=20 >>=20 >> Let's focus on your second point. The topology drafts are I2RS = drafts >> designed for the I2RS ephemeral control plane data store. How can = these be >> generic YANG modules when the following is true:=20 >>=20 >> 1) I2RS Data models do not utilize the configuration data store, >> 2) I2RS Data Models do not require the same validation as=20 >> configuration data store, >> 3) I2RS Data models require the use of priority to handle the=20 >> multi-write contention problem into the I2RS Control Plane data=20 >> store, >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> mandatory-to-implement transport, >>=20 >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20 >> the discussion should be taken up with netmod WG list. >> Do you disagree with i2rs-protocol-security-requirements? That issue = >> is closed based on IESG approval. >>=20 >> Sue Hares >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [ = mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, January 23, 2017 3:39 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> Susan, >>=20 >> I consider tagging a YANG object statically and universally in the=20 >> data model as "does not need secure communication" fundamentally=20 >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >>=20 >> The topology drafts are regular generic YANG models that just happen=20 >> to be done in I2RS - I believe that using the generic YANG security=20 >> guidelines we have is good enough to progress these drafts. >>=20 >> /js >>=20 >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> I recognize that dislike insecure communication. You made a similar = >>> comment during the WG LC and IETF review of=20 >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20 >>> I2RS WG and approved by the IESG for RFC publication and it contains = >>> the non-secure communication. The mandate from the I2RS WG for this = >>> shepherd/co-chair is clear. >>>=20 >>> As the shepherd for the topology drafts, I try to write-up something = >>> that might address Kathleen's Moriarty's concerns about the topology = >>> draft's security issues about privacy and the I2RS ephemeral control = >>> plane >> data >>> store. I welcome an open discussion on my ideas >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >> The >>> yang doctor's YANG security consideration template >>> ( = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and=20 >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >>> Hopefully, this document extends these guidelines to a new data = store.=20 >>>=20 >>> Cheerily, >>> Sue Hares >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [ = mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, January 19, 2017 10:34 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >>> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> For what it is worth, I find the notion that data models may be=20 >>> written for a specific non-secure transport plain broken. There is=20 >>> hardly any content of a data model I can think of which is generally = >>> suitable for insecure transports. >>>=20 >>> Can we please kill this idea of _standardizing_ information that is=20 >>> suitable to send over non-secure transports? I really do not see how = >>> the IETF can make a claim that a given piece of information is never = >>> worth protecting (=3D suitable for non-secure transports). >>>=20 >>> Note that I am fine if in a certain trusted tightly-coupled=20 >>> deployment information is shipped in whatever way but this is then a = >>> property of the _deployment_ and not a property of the = _information_. >>>=20 >>> /js >>>=20 >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>> Kathleen:=20 >>>>=20 >>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>> modules >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >>> (configuration and operational state). =20 >>>>=20 >>>> Draft location:=20 >>>> = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider >>>> / >>>>=20 >>>> I would appreciate an email discussion with the security ADs,=20 >>>> OPS/NM ADs, >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model >>> (L3) and the base I2RS topology model should both provide updated=20 >>> YANG Security Considerations sections. I would appreciate if Benoit=20 >>> or you hold a discuss until we sort out these issues. >>>>=20 >>>> Thank you, >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [ = mailto:Kathleen.Moriarty.ietf@gmail.com] >>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>> To: The IESG >>>> Cc: = draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com;=20 >>>> i2rs-chairs@ietf.org; = shares@ndzh.com; = i2rs@ietf.org >>>> Subject: Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to=20 >>>> all email addresses included in the To and CC lines. (Feel free to=20 >>>> cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>>=20 >>>> I agree with Alissa's comment that the YANG module security=20 >>>> consideration >>> section guidelines need to be followed and this shouldn't go forward = >>> until that is corrected. I'm told it will be, thanks. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> = https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_007A_01D2756F.7BD32320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Giles:

 

I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals.=C2=A0 It is a protocol independent model with = information on topology.=C2=A0=C2=A0 This was in the original use cases = and has been a focus for I2RS WG.=C2=A0=C2=A0 See rest of the responses = below.

 

The real change for RFC compliance for ODL=E2=80=99s read-only = Topology model would be:=C2=A0 a) use of NETCONF over TLS with X.509v3 = authentication, b) denoting the =E2=80=9Cdynamic control plane data = store=E2=80=9D in the get applied (whenever that gets implemented), and = support of the opaque secondary identity in tracing (if you support = tracing). =C2=A0The change for the RFC compliance for the ODL=E2=80=99s = read-write would be the utilizing priority to resolve contention if = multiple clients try to write the topology database.=C2=A0 The priority = could be set per user identifier (passed in X.509v3) in a = pre-configuration set-up stored.=C2=A0=C2=A0 Ideally this = pre-configuration would be stored in a key store or something that is = secure.

 

Sue

 

 

Fr=C2=A0 = om: Giles = Heron [mailto:giles.heron@gmail.com]
Sent: Monday, January = 23, 2017 11:26 AM
To: Susan Hares
Cc: Juergen = Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

Hi = Sue,

 

On 23 Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> = wrote:

 

Giles:=

 =

Thank you = for your comments on ODL and your implementation within ODL.  =  There are two different issues in discussion:  guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.   The guidelines for the I2RS Yang Module = have three security considerations: a)  basic yang = considerations,  b) I2RS ephemeral state considerations, and c) = insecure considerations.   Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

 

i = wasn=E2=80=99t the implementer of those models in ODL.   But = I=E2=80=99ve used them a fair bit.

 

at any rate applying the I2RS security guidelines to = the I2RS YANG topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network = elements) .

 

[Sue]: =C2=A0No, the topology model was part of the original I2RS = YANG modules, and the Topology models (L2, L3, Base) fit its ue. =

 

The = topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt = has read/write nodes at the network, link and termination point.  = Please see the copy of the YHL diagrams below. Therefore, the basic = topology model is read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 

 

Sure - the models are read/write but ODL=E2=80=99s = implementation is generally read-only (as I understand it, it=E2=80=99s = down to each individual protocol or application that leverages the = models to decide whether to use them in read-write or read-only = mode).=C2=A0=C2=A0 =

[Sue]: This fits the I2RS Yang module.

 

1) NETCONF = over TLS with X.509v3 as mandatory to implement protocol, 

 

Giles: =C2=A0most = NETCONF implementations I=E2=80=99m aware of use ssh. And this is mandatory only per an = individual ID, right?   Or is it in a WG draft now?  And do we = have WG consensus that this applies to read-only data as well as to = read-write?

 

Sue:=C2=A0 NETCONF over TLS with X.509v3 is an RFC 7589.=C2=A0 I2RS = is requiring this to get mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. =C2=A0This mandatory-to-implement status is a change = from the basic NETCONF over SSH.

 

2) = RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as = a permissible implementation alternative. 

 

Giles: again = isn=E2=80=99t that only specified as mandatory in an individual ID?

Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. =C2=A0=C2=A0Therefore, the RESTCONF protocol is an = alternative since it supports this with its basic work. =


3) write = contention for two clients writing a node using I2RS priority (linked to = I2RS User-ID) 

 

Giles: so that = one isn=E2=80=99t an issue for read-only implementations=E2=80=A6

Sue: Yes.=C2=A0 You are correct.

 

Sue: If the ODL = model does not support writes to these data models, then it would not = have to support the priority mechanism to resolve two clients writing = one data node.   

Giles: = indeed.

Sue: No other responses are below

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D



A) Basic = Yang considerations =

 =

1) = readable nodes with sensitive data:  Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.  A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.   Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. =   

 =

If the = I2RS mandatory transport is utilized, the data streams utilize mutual = authentication, confidentiality, data integrity, and [practical] replay = protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention".  This = level of security is useful when protecting sensitive data. =  

 =

2) = writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 

 =

3) RPCs: = No new RPCs are considered, but providing information on the = notification data may be also useful. 

 =

I2RS YANG = Model Security Considerations=

 =

The = requirement for this section is the following information: 

 =

1) = Indication of deployment requirement for mandatory-to-implement NETCONF = (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), 

2) = Discussion of RPCs specific to I2RS control plane data store, =   

3) NACM = policy impacts the read-write state and augmentation of NACM by access = control for read/writing of routing protocols (RACM),  system = information (SACM), and between datastores (config to/from ephemeral = state). 

4) = Discussion of data retrieved from routing protocols, system information, = dynamic configuration (dhcp) 

5) Any = suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state. 

 =

For the = topology data models (ietf-network, ietf-network-topology),  the = paragraph could be: =

 =

=E2=80=9CTh= e I2RS topology data models (ietf-network, ietf-network-topology) = require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of TLS (see RFC7589), or an = optional transport support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model or any = notifications.   

 =

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 =

For the = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.  Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. = =E2=80=9C

 =

For the L3 = topology data models (ietf-l3-unicast-topology),  the paragraph = could be: =

 =

=E2=80=9CTh= e I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of NETCONF over TLS with = X.509v3 mutual authentication (RFC7589), or an optional transport = support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model.  This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event.   These events = provide the information about the changing L3 topology which may provide = information regarding key nodes.  Since these events are only = transported over secure transports that support mutual authentication, = confidentiality, data integrity, and [practice] replay protection, the = use of this information for DoS of an I2RS agent (aka NETCONF server) = requires the mutual authenticated client to be suborned.  

 =

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 =

For the L3 = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.   The L3 Topology model may = also read information from the routing protocols (ospf, isis or others), = or write data to the routing protocol.  RACM policy should be = carefully set so that the routing protocols do not form a place to = launch a DoS attack.  Deployments may provide general configuration = knobs that set the default state for NACM, RACM, SACM and DACM for the = topology database. =E2=80=9C

 =

 =

Hopefully, = this makes the suggestion for I2RS security policy a bit more = concrete. 

Sue = Hares 

 =

 =

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 =

High-level = Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt 

 =

  = ;    +--rw networks

  = ;       +--rw network* = [network-id]

  = ;          +--rw = network-types

  = ;          +--rw = network-id          &nb= sp; network-id

  = ;          +--ro = server-provided?      = boolean

  = ;          +--rw = supporting-network* [network-ref]

  = ;          |  +--rw = network-ref    -> = /networks/network/network-id

  = ;          +--rw node* = [node-id]

  = ;            =  +--rw = node-id           = node-id

  = ;            = +--rw supporting-node* [network-ref = node-ref]

  = ;            =     +--rw network-ref    -> = ../../../supporting-network/ +

  = ;            =     = |            =         = network-ref

  = ;            =     +--rw node-ref     =   -> = /networks/network/node/node-id

 =

module: = ietf-network-topology

augment = /nd:networks/nd:network:

  = ; +--rw link* [link-id]

  = ;    +--rw source

  = ;    |  +--rw source-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw source-tp?     = -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =            = ../source-node]/termination-point/tp-id

<= p class=3DMsoNormal>  = ;    +--rw destination

  = ;    |  +--rw dest-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =          = ../dest-node]/termination-point/tp-id

  = ;    +--rw = link-id           = link-id

  = ;    +--rw supporting-link* [network-ref = link-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-network/+

  = ;       = |            =         = network-ref

  = ;       +--rw = link-ref       -> = /nd:networks/network+

  = ;            =             &= nbsp;   = [nd:network-id=3Dcurrent()/../network-ref]/+

<= div>

  = ;            =             &= nbsp;   link/link-id

 =

augment = /nd:networks/nd:network/nd:node:

  = ; +--rw termination-point* [tp-id]

  = ;    +--rw = tp-id           &n= bsp;           &nb= sp;   tp-id

  = ;    +--rw supporting-termination-point* [network-ref = node-ref tp-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-node/network-ref

<= p class=3DMsoNormal>  = ;       +--rw = node-ref       -> = ../../../nd:supporting-node/node-ref

  = ;       +--rw = tp-ref         -> = /nd:networks/network[nd:network-id=3D+

  = ;            =             &= nbsp;   = current()/../network-ref]/node+

  = ;            =             &= nbsp;   = [nd:node-id=3Dcurrent()/../node-ref]/+

  = ;            =              =    termination-point/tp-id

 =

 =

  = ; module: ietf-l3-unicast-topology

  = ; augment = /nd:networks/nd:network/nd:network-types:

  = ;    +--rw = l3-unicast-topology!

  = ; augment /nd:networks/nd:network:

  = ;    +--rw = l3-topology-attributes

  = ;       +--rw name?   = string

  = ;       +--rw flag*   = l3-flag-type

  = ; augment = /nd:networks/nd:network/nd:node:

  = ;    +--rw = l3-node-attributes

  = ;       +--rw = name?        = inet:domain-name

  = ;       +--rw = flag*        = node-flag-type

  = ;       +--rw router-id*   = inet:ip-address

  = ;       +--rw prefix* = [prefix]

  = ;          +--rw = prefix    = inet:ip-prefix

  = ;          +--rw = metric?   uint32

  = ;          +--rw = flag*     = prefix-flag-type

  = ; augment = /nd:networks/nd:network/lnk:link:

  = ;    +--rw = l3-link-attributes

  = ;       +--rw = name?     string

  = ;       +--rw = flag*     = link-flag-type

  = ;       +--rw metric?   = uint32

  = ; augment = /nd:networks/nd:network/nd:node/lnk:termination-point:<= /p>

  = ;    +--rw = l3-termination-point-attributes

  = ;       +--rw = (termination-point-type)?

  = ;          = +--:(ip)

  = ;          |  +--rw = ip-address*      = inet:ip-address

  = ;          = +--:(unnumbered)

  = ;          |  +--rw = unnumbered-id?   uint32

  = ;          = +--:(interface-name)

  = ;            = +--ro interface-name?  string

 =

 =

 =

 =

 =

-----Origin= al Message-----
From: Giles Heron [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, = 2017 6:45 AM
To: Juergen Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 =

ODL does, = indeed, implement the topology models, but generally the data in the = topology model is operational data, so I=E2=80=99m not sure how that = fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data = store=E2=80=9D - since users don=E2=80=99t write to the models directly = (making validation, priority etc. = non-issues).

 =

> On 23 = Jan 2017, at 11:29, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:

> 

> I = thought the topology models are coming more or less from 

> = OpenDaylight. If so, is ODL and I2RS = implementation?

> 

> = /js

> 

> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares = wrote:

>> = Juergen: 

>> 

>> = Let's focus on your second point.  The topology drafts are I2RS = drafts

>> = designed for the I2RS ephemeral control plane data store.   = How can these be

>> = generic YANG modules when the following is true: 

>> 

>> = 1) I2RS Data models do not utilize the configuration data = store,

>> = 2) I2RS Data Models do not require the same validation as 

>> = configuration data store,

>> = 3) I2RS Data models require the use of priority to handle the 

>> = multi-write contention problem into the I2RS Control Plane data 

>> = store,

>> = 4) I2RS require TLS with X.509v3 over TCP for the 

>> = mandatory-to-implement transport,

>> 

>> = Do you disagree with draft-ietf-netmod-revised-datastores?  If = so,  

>> = the discussion should be taken up with netmod WG = list.

>> = Do you disagree with i2rs-protocol-security-requirements?  That = issue 

>> = is closed based on IESG approval.

>> 

>> = Sue Hares

>> 

>> = -----Original Message-----

>> = From: Juergen Schoenwaelder 

>> = [mailto:j.schoenwaelder@ja= cobs-university.de]

>> = Sent: Monday, January 23, 2017 3:39 = AM

>> = To: Susan Hares

>> = Cc: 'Kathleen Moriarty'; 'The IESG';

>> i2rs-chairs@ietf.org

>> = Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>> = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>> 

>> = Susan,

>> 

>> I = consider tagging a YANG object statically and universally in the 

>> = data model as "does not need secure communication" = fundamentally 

>> = flawed; I am not having an issue with insecure communication in certain = deployment contexts.

>> 

>> = The topology drafts are regular generic YANG models that just = happen 

>> = to be done in I2RS - I believe that using the generic YANG security 

>> = guidelines we have is good enough to progress these = drafts.

>> 

>> = /js

>> 

>> = On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares = wrote:

>>>= ; Juergen: 

>>>= ; 

>>>= ; I recognize that dislike insecure communication.  You made a = similar 

>>>= ; comment during the WG LC and IETF review of 

>>>= ; draft-ietf-i2rs-protocol-security-requirements.  However, = the 

>>>= ; draft-ietf-i2rs-protocol-security-requirements were passed by the 

>>>= ; I2RS WG and approved by the IESG for RFC publication and it = contains 

>>>= ; the non-secure communication.  The mandate from the I2RS WG for = this 

>>>= ; shepherd/co-chair is clear.

>>>= ; 

>>>= ; As the shepherd for the topology drafts, I try to write-up = something 

>>>= ; that might address Kathleen's Moriarty's concerns about the = topology 

>>>= ; draft's security issues about privacy and the I2RS ephemeral = control 

>>>= ; plane

>> = data

>>>= ; store.   I welcome an open discussion on my = ideas

>> = The

>>>= ; yang doctor's YANG  security consideration = template

>>>= ; the privacy related RFCs (RFC6973) note that some information is = sensitive.

>>>= ; Hopefully, this document extends these guidelines to a new data = store. 

>>>= ; 

>>>= ; Cheerily,

>>>= ; Sue Hares

>>>= ; 

>>>= ; -----Original Message-----

>>>= ; From: Juergen Schoenwaelder

>>>= ; Sent: Thursday, January 19, 2017 10:34 = AM

>>>= ; To: Susan Hares

>>>= ; Cc: 'Kathleen Moriarty'; 'The IESG'; 

>>>= ; draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=  

>>>= ; i2rs-chairs@ietf.org

>>>= ; Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>>>= ; draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ; 

>>>= ; For what it is worth, I find the notion that data models may be 

>>>= ; written for a specific non-secure transport plain broken. There = is 

>>>= ; hardly any content of a data model I can think of which is = generally 

>>>= ; suitable for insecure transports.

>>>= ; 

>>>= ; Can we please kill this idea of _standardizing_ information that = is 

>>>= ; suitable to send over non-secure transports? I really do not see = how 

>>>= ; the IETF can make a claim that a given piece of information is = never 

>>>= ; worth protecting (=3D suitable for non-secure = transports).

>>>= ; 

>>>= ; Note that I am fine if in a certain trusted tightly-coupled 

>>>= ; deployment information is shipped in whatever way but this is then = a 

>>>= ; property of the _deployment_ and not a property of the = _information_.

>>>= ; 

>>>= ; /js

>>>= ; 

>>>= ; On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares = wrote:

>>>= ;> Kathleen: 

>>>= ;> 

>>>= ;> I have written a draft suggesting a template for the I2RS = YANG 

>>>= ;> modules

>>>= ; which are designed to exist in the I2RS Ephemeral Control Plane data = store

>>>= ; (configuration and operational state).    

>>>= ;> 

>>>= ;> Draft location: 

>>>= ;> https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-consider

>>>= ;> /

>>>= ;> 

>>>= ;> I would appreciate an email discussion with the security ADs, 

>>>= ;> OPS/NM ADs,

>>>= ; and Routing AD (Alia Atlas).  I agree that this I2RS YANG data = model

>>>= ; (L3) and the base I2RS topology model should both provide updated 

>>>= ; YANG Security Considerations sections. I would appreciate if = Benoit 

>>>= ; or you hold a discuss until we sort out these = issues.

>>>= ;> 

>>>= ;> Thank you,

>>>= ;> 

>>>= ;> Sue

>>>= ;> 

>>>= ;> -----Original Message-----

>>>= ;> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.= ietf@gmail.com]

>>>= ;> Sent: Wednesday, January 18, 2017 9:44 = PM

>>>= ;> To: The IESG

>>>= ;> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org<= o:p>

>>>= ;> Subject: Kathleen Moriarty's No Objection = on

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ;> 

>>>= ;> Kathleen Moriarty has entered the following ballot position = for

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: No = Objection

>>>= ;> 

>>>= ;> When responding, please keep the subject line intact and reply = to 

>>>= ;> all email addresses included in the To and CC lines. (Feel free = to 

>>>= ;> cut this introductory paragraph, = however.)

>>>= ;> 

>>>= ;> 

>>>= ;> Please refer to

>>>= ;> for more information about IESG DISCUSS and COMMENT = positions.

>>>= ;> 

>>>= ;> 

>>>= ;> The document, along with other ballot positions, can be found = here:

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = -------------------------------------------------------------------<= /o:p>

>>>= ;> -

>>>= ;> --

>>>= ;> COMMENT:

>>>= ;> = -------------------------------------------------------------------<= /o:p>

>>>= ;> -

>>>= ;> --

>>>= ;> 

>>>= ;> I agree with Alissa's comment that the YANG module security 

>>>= ;> consideration

>>>= ; section guidelines need to be followed and this shouldn't go = forward 

>>>= ; until that is corrected.  I'm told it will be, = thanks.

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = _______________________________________________

>>>= ;> i2rs mailing list

>>>= ;> i2rs@ietf.org<= o:p>

>>>= ; 

>>>= ; -- 

>>>= ; Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

>>>= ; Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

>>>= ; Fax:   +49 421 200 3103       =   <http://www.jacobs-univers= ity.de/>

>>>= ; 

>> 

>> = -- 

>> = Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

>> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

>> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

>> 

> 

> = -- 

> = Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

> 

> = _______________________________________________

> i2rs = mailing list

> i2rs@ietf.org<= o:p>

 

------=_NextPart_000_007A_01D2756F.7BD32320-- From nobody Mon Jan 23 10:12:24 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 75E0B129715; Mon, 23 Jan 2017 10:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em3m3t-10Vjh; Mon, 23 Jan 2017 10:12:16 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDAF1296F9; Mon, 23 Jan 2017 10:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1485195061; bh=G+DupMvI4ONrtb48j5aas2czDRMLlNMusoTznrgeAb4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dgxuPpWnO7r7UQTqwrbATVFZJ1TncXEutbYBpdmeoCzgDXNdsv51CGfllf48u1smY 1YFF2Pvgi7eIQCBI8yqBXy9Mhjk2cljSpJid0fOm/6hwqMP5GO+jlj4B0QCKzJALLH 5HoNxAg7mSdaQAPHnrjkAnSbMVyQpmWeuTiSJMDk= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_0D097B9C-9917-4039-A038-C57CC8D01B51" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <007901d27599$649e0790$2dda16b0$@ndzh.com> Date: Mon, 23 Jan 2017 13:11:53 -0500 Message-Id: <55EFDB1C-ED03-4D24-AFF9-28033DF03A7F@lucidvision.com> References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> <007901d27599$649e0790$2dda16b0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 619, in=4702, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , Kathleen Moriarty , i2rs-chairs@ietf.org, Giles Heron , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 18:12:19 -0000 --Apple-Mail=_0D097B9C-9917-4039-A038-C57CC8D01B51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares = wrote: >=20 > Giles:=20 > =20 > I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals. It is a protocol independent model with information on = topology. This was in the original use cases and has been a focus for = I2RS WG. See rest of the responses below.=20 > =20 > The real change for RFC compliance for ODL=E2=80=99s read-only = Topology model would be: a) use of NETCONF over TLS with X.509v3 = authentication, b) denoting the =E2=80=9Cdynamic control plane data = store=E2=80=9D in the get applied (whenever that gets implemented), and = support of the opaque secondary identity in tracing (if you support = tracing). The change for the RFC compliance for the ODL=E2=80=99s = read-write would be the utilizing priority to resolve contention if = multiple clients try to write the topology database. The priority could = be set per user identifier (passed in X.509v3) in a pre-configuration = set-up stored. Ideally this pre-configuration would be stored in a key = store or something that is secure. > =20 > Sue=20 Sue,=20 I am still totally confused as to why any of what that last = sentence says has to do with the topology model other than it is as you = say, protocol independent. That was the original goal. Why we are complicating things with transport or data store things is = not making sense to me at all. =E2=80=94Tom > =20 > =20 > Fr om: Giles Heron [mailto:giles.heron@gmail.com = ]=20 > Sent: Monday, January 23, 2017 11:26 AM > To: Susan Hares > Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > =20 > Hi Sue, > =20 >> On 23 Jan 2017, at 14:40, Susan Hares > wrote: >> =20 >> Giles: >> =20 >> Thank you for your comments on ODL and your implementation within = ODL. There are two different issues in discussion: guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model. The guidelines for the I2RS Yang Module have = three security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). > =20 > i wasn=E2=80=99t the implementer of those models in ODL. But I=E2=80=99= ve used them a fair bit. > =20 > at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model doesn=E2=80=99t = really =E2=80=9Cfit=E2=80=9D with the original goal of I2RS (ephemeral = configuration of RIBs, ACLs etc. on network elements) . > =20 > [Sue]: No, the topology model was part of the original I2RS YANG = modules, and the Topology models (L2, L3, Base) fit its ue.=20 > =20 >> The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 > =20 > Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). =20 > [Sue]: This fits the I2RS Yang module.=20 > =20 > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20= > =20 > Giles: most NETCONF implementations I=E2=80=99m aware of use ssh. And = this is mandatory only per an individual ID, right? Or is it in a WG = draft now? And do we have WG consensus that this applies to read-only = data as well as to read-write? > =20 > Sue: NETCONF over TLS with X.509v3 is an RFC 7589. I2RS is requiring = this to get mutual authentication, confidentiality, data integrity, = [practical] reply protection for I2RS messages, and support DoS = mitigation. This mandatory-to-implement status is a change from the = basic NETCONF over SSH.=20 > =20 > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual = authentication as a permissible implementation alternative.=20 > =20 > Giles: again isn=E2=80=99t that only specified as mandatory in an = individual ID? > Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. Therefore, the RESTCONF protocol is an alternative = since it supports this with its basic work.=20 >=20 > 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 > =20 > Giles: so that one isn=E2=80=99t an issue for read-only = implementations=E2=80=A6 > Sue: Yes. You are correct.=20 > =20 > Sue: If the ODL model does not support writes to these data models, = then it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 > Giles: indeed. > Sue: No other responses are below=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 >=20 > A) Basic Yang considerations=20 > =20 > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 > =20 > If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 > =20 > 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 > =20 > 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 > =20 > I2RS YANG Model Security Considerations > =20 > The requirement for this section is the following information:=20 > =20 > 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 > 2) Discussion of RPCs specific to I2RS control plane data store, =20 > 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 > 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 > 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 > =20 > For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 > =20 > =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20= > =20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > =20 > For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C > =20 > For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 > =20 > =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 > =20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > =20 > For the L3 topology mode, the access to information on interfaces may = be control by SACM related to the interface model. Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol. RACM policy should be carefully set so = that the routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C > =20 > =20 > Hopefully, this makes the suggestion for I2RS security policy a bit = more concrete.=20 >> Sue Hares=20 >> =20 >> =20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20= >> =20 >> +--rw networks >> +--rw network* [network-id] >> +--rw network-types >> +--rw network-id network-id >> +--ro server-provided? boolean >> +--rw supporting-network* [network-ref] >> | +--rw network-ref -> /networks/network/network-id >> +--rw node* [node-id] >> +--rw node-id node-id >> +--rw supporting-node* [network-ref node-ref] >> +--rw network-ref -> = ../../../supporting-network/ + >> | network-ref >> +--rw node-ref -> = /networks/network/node/node-id >> =20 >> module: ietf-network-topology >> augment /nd:networks/nd:network: >> +--rw link* [link-id] >> +--rw source >> | +--rw source-node? -> ../../../nd:node/node-id >> | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >> | ../source-node]/termination-point/tp-id >> +--rw destination >> | +--rw dest-node? -> ../../../nd:node/node-id >> | +--rw dest-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >> | ../dest-node]/termination-point/tp-id >> +--rw link-id link-id >> +--rw supporting-link* [network-ref link-ref] >> +--rw network-ref -> ../../../nd:supporting-network/+ >> | network-ref >> +--rw link-ref -> /nd:networks/network+ >> = [nd:network-id=3Dcurrent()/../network-ref]/+ >> link/link-id >> =20 >> augment /nd:networks/nd:network/nd:node: >> +--rw termination-point* [tp-id] >> +--rw tp-id tp-id >> +--rw supporting-termination-point* [network-ref node-ref = tp-ref] >> +--rw network-ref -> = ../../../nd:supporting-node/network-ref >> +--rw node-ref -> ../../../nd:supporting-node/node-ref >> +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+= >> current()/../network-ref]/node+ >> [nd:node-id=3Dcurrent()/../node-ref]/+ >> termination-point/tp-id >> =20 >> =20 >> module: ietf-l3-unicast-topology >> augment /nd:networks/nd:network/nd:network-types: >> +--rw l3-unicast-topology! >> augment /nd:networks/nd:network: >> +--rw l3-topology-attributes >> +--rw name? string >> +--rw flag* l3-flag-type >> augment /nd:networks/nd:network/nd:node: >> +--rw l3-node-attributes >> +--rw name? inet:domain-name >> +--rw flag* node-flag-type >> +--rw router-id* inet:ip-address >> +--rw prefix* [prefix] >> +--rw prefix inet:ip-prefix >> +--rw metric? uint32 >> +--rw flag* prefix-flag-type >> augment /nd:networks/nd:network/lnk:link: >> +--rw l3-link-attributes >> +--rw name? string >> +--rw flag* link-flag-type >> +--rw metric? uint32 >> augment /nd:networks/nd:network/nd:node/lnk:termination-point: >> +--rw l3-termination-point-attributes >> +--rw (termination-point-type)? >> +--:(ip) >> | +--rw ip-address* inet:ip-address >> +--:(unnumbered) >> | +--rw unnumbered-id? uint32 >> +--:(interface-name) >> +--ro interface-name? string >> =20 >> =20 >> =20 >> =20 >> =20 >> -----Original Message----- >> From: Giles Heron [mailto:giles.heron@gmail.com = ]=20 >> Sent: Monday, January 23, 2017 6:45 AM >> To: Juergen Schoenwaelder >> Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> =20 >> ODL does, indeed, implement the topology models, but generally the = data in the topology model is operational data, so I=E2=80=99m not sure = how that fits with =E2=80=9Cdesigned for the I2RS ephemeral control = plane data store=E2=80=9D - since users don=E2=80=99t write to the = models directly (making validation, priority etc. non-issues). >> =20 >> > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = > wrote: >> >=20 >> > I thought the topology models are coming more or less from=20 >> > OpenDaylight. If so, is ODL and I2RS implementation? >> >=20 >> > /js >> >=20 >> > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> >> Juergen:=20 >> >>=20 >> >> Let's focus on your second point. The topology drafts are I2RS = drafts >> >> designed for the I2RS ephemeral control plane data store. How = can these be >> >> generic YANG modules when the following is true:=20 >> >>=20 >> >> 1) I2RS Data models do not utilize the configuration data store, >> >> 2) I2RS Data Models do not require the same validation as=20 >> >> configuration data store, >> >> 3) I2RS Data models require the use of priority to handle the=20 >> >> multi-write contention problem into the I2RS Control Plane data=20 >> >> store, >> >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> >> mandatory-to-implement transport, >> >>=20 >> >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, = =20 >> >> the discussion should be taken up with netmod WG list. >> >> Do you disagree with i2rs-protocol-security-requirements? That = issue=20 >> >> is closed based on IESG approval. >> >>=20 >> >> Sue Hares >> >>=20 >> >> -----Original Message----- >> >> From: Juergen Schoenwaelder=20 >> >> [mailto:j.schoenwaelder@jacobs-university.de = ] >> >> Sent: Monday, January 23, 2017 3:39 AM >> >> To: Susan Hares >> >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> >> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 >> >> i2rs-chairs@ietf.org >> >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>=20 >> >> Susan, >> >>=20 >> >> I consider tagging a YANG object statically and universally in the=20= >> >> data model as "does not need secure communication" fundamentally=20= >> >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >> >>=20 >> >> The topology drafts are regular generic YANG models that just = happen=20 >> >> to be done in I2RS - I believe that using the generic YANG = security=20 >> >> guidelines we have is good enough to progress these drafts. >> >>=20 >> >> /js >> >>=20 >> >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >> >>> Juergen:=20 >> >>>=20 >> >>> I recognize that dislike insecure communication. You made a = similar=20 >> >>> comment during the WG LC and IETF review of=20 >> >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >> >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20= >> >>> I2RS WG and approved by the IESG for RFC publication and it = contains=20 >> >>> the non-secure communication. The mandate from the I2RS WG for = this=20 >> >>> shepherd/co-chair is clear. >> >>>=20 >> >>> As the shepherd for the topology drafts, I try to write-up = something=20 >> >>> that might address Kathleen's Moriarty's concerns about the = topology=20 >> >>> draft's security issues about privacy and the I2RS ephemeral = control=20 >> >>> plane >> >> data >> >>> store. I welcome an open discussion on my ideas >> >>> = (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = ). >> >> The >> >>> yang doctor's YANG security consideration template >> >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines = ) and=20 >> >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >> >>> Hopefully, this document extends these guidelines to a new data = store.=20 >> >>>=20 >> >>> Cheerily, >> >>> Sue Hares >> >>>=20 >> >>> -----Original Message----- >> >>> From: Juergen Schoenwaelder >> >>> [mailto:j.schoenwaelder@jacobs-university.de = ] >> >>> Sent: Thursday, January 19, 2017 10:34 AM >> >>> To: Susan Hares >> >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >> >>> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; i2rs@ietf.org = ;=20 >> >>> i2rs-chairs@ietf.org >> >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>>=20 >> >>> For what it is worth, I find the notion that data models may be=20= >> >>> written for a specific non-secure transport plain broken. There = is=20 >> >>> hardly any content of a data model I can think of which is = generally=20 >> >>> suitable for insecure transports. >> >>>=20 >> >>> Can we please kill this idea of _standardizing_ information that = is=20 >> >>> suitable to send over non-secure transports? I really do not see = how=20 >> >>> the IETF can make a claim that a given piece of information is = never=20 >> >>> worth protecting (=3D suitable for non-secure transports). >> >>>=20 >> >>> Note that I am fine if in a certain trusted tightly-coupled=20 >> >>> deployment information is shipped in whatever way but this is = then a=20 >> >>> property of the _deployment_ and not a property of the = _information_. >> >>>=20 >> >>> /js >> >>>=20 >> >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >> >>>> Kathleen:=20 >> >>>>=20 >> >>>> I have written a draft suggesting a template for the I2RS YANG=20= >> >>>> modules >> >>> which are designed to exist in the I2RS Ephemeral Control Plane = data store >> >>> (configuration and operational state). =20 >> >>>>=20 >> >>>> Draft location:=20 >> >>>> = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider = >> >>>> / >> >>>>=20 >> >>>> I would appreciate an email discussion with the security ADs,=20 >> >>>> OPS/NM ADs, >> >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data = model >> >>> (L3) and the base I2RS topology model should both provide updated=20= >> >>> YANG Security Considerations sections. I would appreciate if = Benoit=20 >> >>> or you hold a discuss until we sort out these issues. >> >>>>=20 >> >>>> Thank you, >> >>>>=20 >> >>>> Sue >> >>>>=20 >> >>>> -----Original Message----- >> >>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com = ] >> >>>> Sent: Wednesday, January 18, 2017 9:44 PM >> >>>> To: The IESG >> >>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org = ; shares@ndzh.com = ;=20 >> >>>> i2rs-chairs@ietf.org ; = shares@ndzh.com ; i2rs@ietf.org = >> >>>> Subject: Kathleen Moriarty's No Objection on >> >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >>>>=20 >> >>>> Kathleen Moriarty has entered the following ballot position for >> >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >> >>>>=20 >> >>>> When responding, please keep the subject line intact and reply = to=20 >> >>>> all email addresses included in the To and CC lines. (Feel free = to=20 >> >>>> cut this introductory paragraph, however.) >> >>>>=20 >> >>>>=20 >> >>>> Please refer to >> >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html = >> >>>> for more information about IESG DISCUSS and COMMENT positions. >> >>>>=20 >> >>>>=20 >> >>>> The document, along with other ballot positions, can be found = here: >> >>>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ = >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> = ------------------------------------------------------------------- >> >>>> - >> >>>> -- >> >>>> COMMENT: >> >>>> = ------------------------------------------------------------------- >> >>>> - >> >>>> -- >> >>>>=20 >> >>>> I agree with Alissa's comment that the YANG module security=20 >> >>>> consideration >> >>> section guidelines need to be followed and this shouldn't go = forward=20 >> >>> until that is corrected. I'm told it will be, thanks. >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> _______________________________________________ >> >>>> i2rs mailing list >> >>>> i2rs@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/i2rs = >> >>>=20 >> >>> --=20 >> >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> >>> Fax: +49 421 200 3103 > >> >>>=20 >> >>=20 >> >> --=20 >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> >> Fax: +49 421 200 3103 > >> >>=20 >> >=20 >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> > Fax: +49 421 200 3103 > >> >=20 >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs = > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs = --Apple-Mail=_0D097B9C-9917-4039-A038-C57CC8D01B51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares <shares@ndzh.com> = wrote:

Giles: 
 
I disagree =E2=80=93 = the I2RS Topology model does fit within the original goals.  It is = a protocol independent model with information on topology.   = This was in the original use cases and has been a focus for I2RS = WG.   See rest of the responses below. 
 
The real change for RFC = compliance for ODL=E2=80=99s read-only Topology model would be:  a) = use of NETCONF over TLS with X.509v3 authentication, b) denoting the = =E2=80=9Cdynamic control plane data store=E2=80=9D in the get applied = (whenever that gets implemented), and support of the opaque secondary = identity in tracing (if you support tracing).  The change for the = RFC compliance for the ODL=E2=80=99s read-write would be the utilizing = priority to resolve contention if multiple clients try to write the = topology database.  The priority could be set per user identifier = (passed in X.509v3) in a pre-configuration set-up stored.   = Ideally this pre-configuration would be stored in a key store or = something that is secure.
 
Sue 

Sue, 

I am still totally confused as to = why any of what that last sentence says has to do with the topology = model other than it is as you say, protocol independent.  That was = the original goal.
Why we are complicating things with = transport or data store things is not making sense to me at = all.

=E2=80=94Tom


 
 
Fr  = om: Giles Heron [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, 2017 = 11:26 AM
To: Susan Hares
Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
 
Hi Sue,
 
On 23 Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> wrote:
 
Giles:
 
Thank you for your comments on ODL and your = implementation within ODL.   There are two different issues in = discussion:  guidelines for I2RS Yang modules and the application = of these guidelines to the I2RS Yang Topology model.   The = guidelines for the I2RS Yang Module have three security considerations: = a)  basic yang considerations,  b) I2RS ephemeral state = considerations, and c) insecure considerations.   Since the = topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).
 
i wasn=E2=80=99t the implementer of those models in ODL. =   But I=E2=80=99ve used them a fair bit.
 
at any rate applying the I2RS security = guidelines to the I2RS YANG topology model is a bit tricky IMHO as the = topology model doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the = original goal of I2RS (ephemeral configuration of RIBs, ACLs etc. on = network elements) .
 
[Sue]:  No, the = topology model was part of the original I2RS YANG modules, and the = Topology models (L2, L3, Base) fit its ue. 
 
The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point.  Please see the copy of the = YHL diagrams below. Therefore, the basic topology model is = read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 
 
Sure - the models are read/write but ODL=E2=80=99s = implementation is generally read-only (as I understand it, it=E2=80=99s = down to each individual protocol or application that leverages the = models to decide whether to use them in read-write or read-only = mode).   
[Sue]: This fits the I2RS Yang = module. 
 
1)= NETCONF over TLS with X.509v3 as mandatory to implement protocol, 
 
Giles:  most NETCONF implementations I=E2=80=99m = aware of use ssh. And this is = mandatory only per an individual ID, right?   Or is it in a WG = draft now?  And do we have WG consensus that this applies to = read-only data as well as to read-write?
 
Sue:  NETCONF over = TLS with X.509v3 is an RFC 7589.  I2RS is requiring this to get = mutual authentication, confidentiality, data integrity, [practical] = reply protection for I2RS messages, and support DoS mitigation. =  This mandatory-to-implement status is a change from the basic = NETCONF over SSH. 
 
2) RESTCONF which uses = HTTP over TLS with X.509v3 mutual authentication as a permissible = implementation alternative. 
 
Giles: again isn=E2=80=99t = that only specified as mandatory in an individual ID?
Sue: The I2RS requires mutual authentication, = confidentiality, data integrity, [practical] reply protection for I2RS = messages, and support DoS mitigation.   Therefore, the = RESTCONF protocol is an alternative since it supports this with its = basic work. 

3) write contention = for two clients writing a node using I2RS priority (linked to I2RS = User-ID) 
 
Giles: so that one isn=E2=80=99= t an issue for read-only implementations=E2=80=A6
Sue: Yes.  You are correct. 
 
Sue: If= the ODL model does not support writes to these data models, then it = would not have to support the priority mechanism to resolve two clients = writing one data node.   
Giles: indeed.
Sue: No other responses are below 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


A) Basic Yang considerations 
 
1) readable nodes with sensitive data: =  Kathleen Moriarty and Stephen indicate that the topology data = could be considered sensitive read data.  A paragraph needs to be = added to each draft indicating risks involved in providing this = information, and how deployments can keep this data safe.  =  Privacy issues are involved if the topologies are within homes or = indicate user's personal devices.   
 
If the I2RS mandatory transport is utilized, the = data streams utilize mutual authentication, confidentiality, data = integrity, and [practical] replay protection for I2RS messages" and = support "mechanism that mitigate DoS attacks" and "DDos = prevention".  This level of security is useful when protecting = sensitive data.  
 
2)= writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 
 
3) RPCs: No new RPCs are considered, but = providing information on the notification data may be also useful. 
 
I2RS YANG Model Security = Considerations
 
The requirement for this = section is the following information: 
 
1) Indication of = deployment requirement for mandatory-to-implement NETCONF (RFC7589) or = optional RESTCONF (draft-ietf-netconf-restconf), 
2) Discussion of RPCs specific to I2RS control = plane data store,   
3) NACM policy impacts the read-write state and = augmentation of NACM by access control for read/writing of routing = protocols (RACM),  system information (SACM), and between = datastores (config to/from ephemeral state). 
4) Discussion of data retrieved from routing = protocols, system information, dynamic configuration (dhcp) 
5) Any suggestion for operational knobs that = control overlay of I2RS configuration over normal configuration and I2RS = operational state over other operational state. 
 
For the topology data = models (ietf-network, ietf-network-topology),  the paragraph could = be: 
 
=E2=80=9CThe I2RS topology data models = (ietf-network, ietf-network-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of TLS (see RFC7589), or an optional transport support of = RESTCONF (draft-ietf-netconf-restconf).     This = data model does not implement any additional RPCs specific to this data = model or any notifications.   
 
NACM policies may restrict exterior access to = this YANG model to simply read-only.  For those NACM policies = allowing write-access, there is a risk that a write to a topology may = create a looping topology or overload a particular node.  NACM = policies may be augment by routing protocol access control methods = (RACM), system data access control methods (SACM), and inter-data store = access control mechanisms (DACM).  The engagement of this policy = should also be control by user policy switches (on/of).  
 
For the topology mode, the access to information = on interfaces may be control by SACM related to the interface = model.  Any I2RS topology model termination point configuration = which takes augments must take care not to cause fluctuation in the = interface state.   Dynamic configuration protocols such as = DHCP or DHCPv6 may also alter the IP Addresses associated with an = interface.  DACM related to the inter-datastore policy on the = precedence between configuration of interface IP addresses, DHCP/DHCPv6 = configuration, or Topology configuration will need to make sure the = interface IP address does not cause fluctuations in the system. =  Deployments may provide general configuration knobs that set the = default state for NACM, RACM, SACM and DACM for the topology database. = =E2=80=9C
 
For the L3 topology data = models (ietf-l3-unicast-topology),  the paragraph could be: 
 
=E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf).     This data model = does not implement any additional RPCs specific to this data = model.  This data model does support the following new = notifications: l3-node-event, l3-link-event, l3-prefix-event, and = termination-point-event.   These events provide the = information about the changing L3 topology which may provide information = regarding key nodes.  Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned.  
 
NACM policies may restrict exterior access to = this YANG model to simply read-only.  For those NACM policies = allowing write-access, there is a risk that a write to a topology may = create a looping topology or overload a particular node.  NACM = policies may be augment by routing protocol access control methods = (RACM), system data access control methods (SACM), and inter-data store = access control mechanisms (DACM).  The engagement of this policy = should also be control by user policy switches (on/of).  
 
For the L3 topology mode, the access to = information on interfaces may be control by SACM related to the = interface model.  Any I2RS topology model termination point = configuration which takes augments must take care not to cause = fluctuation in the interface state.   Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface.  DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system.   The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol.  RACM policy should be carefully set = so that the routing protocols do not form a place to launch a DoS = attack.  Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C
 
 
Hopefully, this makes the suggestion for I2RS security policy = a bit more concrete. 
Sue Hares 
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
High-level Yang diagrams for = draft-ietf-i2rs-yang-network-topo-10.txt 
 
      +--rw = networks
         +--rw = network* [network-id]
          &nb= sp; +--rw network-types
           =  +--rw = network-id          &nbs= p; network-id
          &nb= sp; +--ro server-provided?      boolean
          &nb= sp; +--rw supporting-network* [network-ref]
          &nb= sp; |  +--rw network-ref    -> = /networks/network/network-id
          &nb= sp; +--rw node* [node-id]
          &nb= sp;    +--rw = node-id            = node-id
          &nb= sp;    +--rw supporting-node* [network-ref node-ref]
          &nb= sp;       +--rw = network-ref    -> ../../../supporting-network/ +
          &nb= sp;       = |            &= nbsp;       network-ref
          &nb= sp;       +--rw = node-ref       -> = /networks/network/node/node-id
 
module: ietf-network-topology
augment /nd:networks/nd:network:
   +--rw link* [link-id]
      +--rw source
      |  +--rw = source-node?   -> ../../../nd:node/node-id
      |  +--rw = source-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;          = ../source-node]/termination-point/tp-id
      +--rw = destination
      |  +--rw = dest-node?   -> ../../../nd:node/node-id
      |  +--rw = dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+
      = |            &= nbsp;        = ../dest-node]/termination-point/tp-id
      +--rw = link-id            = link-id
      +--rw supporting-link* = [network-ref link-ref]
         +--rw = network-ref    -> ../../../nd:supporting-network/+
         = |            &= nbsp;       network-ref
         = +--rw link-ref       -> = /nd:networks/network+
          &nb= sp;            = ;       = [nd:network-id=3Dcurrent()/../network-ref]/+
          &nb= sp;            = ;       link/link-id
 
augment /nd:networks/nd:network/nd:node:
   +--rw termination-point* = [tp-id]
      +--rw = tp-id           &nb= sp;            = ;   tp-id
      +--rw = supporting-termination-point* [network-ref node-ref tp-ref]
         = +--rw network-ref    -> = ../../../nd:supporting-node/network-ref
         = +--rw node-ref       -> = ../../../nd:supporting-node/node-ref
         = +--rw tp-ref         -> = /nd:networks/network[nd:network-id=3D+
          &nb= sp;            = ;       = current()/../network-ref]/node+
          &nb= sp;            = ;       = [nd:node-id=3Dcurrent()/../node-ref]/+
          &nb= sp;            = ;       termination-point/tp-id
 
 
   module: = ietf-l3-unicast-topology
   augment = /nd:networks/nd:network/nd:network-types:
      +--rw = l3-unicast-topology!
   augment /nd:networks/nd:network:
      +--rw = l3-topology-attributes
         +--rw = name?   string
         +--rw = flag*   l3-flag-type
   augment = /nd:networks/nd:network/nd:node:
      +--rw = l3-node-attributes
         +--rw = name?        inet:domain-name
         = +--rw flag*        node-flag-type
         = +--rw router-id*   inet:ip-address
         = +--rw prefix* [prefix]
          &nb= sp; +--rw prefix    inet:ip-prefix
          &nb= sp; +--rw metric?   uint32
          &nb= sp; +--rw flag*     prefix-flag-type
   augment = /nd:networks/nd:network/lnk:link:
      +--rw = l3-link-attributes
         +--rw = name?     string
         = +--rw flag*     link-flag-type
         = +--rw metric?   uint32
   augment = /nd:networks/nd:network/nd:node/lnk:termination-point:
      +--rw = l3-termination-point-attributes
         = +--rw (termination-point-type)?
          &nb= sp; +--:(ip)
          &nb= sp; |  +--rw ip-address*      = inet:ip-address
          &nb= sp; +--:(unnumbered)
          &nb= sp; |  +--rw unnumbered-id?   uint32
          &nb= sp; +--:(interface-name)
          &nb= sp;    +--ro interface-name?  string
 
 
 
 
 
-----Original Message-----
From: = Giles Heron [mailto:giles.heron@gmail.com] 
Sent: = Monday, January 23, 2017 6:45 AM
To: Juergen = Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
 
ODL does, indeed, implement the topology models, = but generally the data in the topology model is operational data, so = I=E2=80=99m not sure how that fits with =E2=80=9Cdesigned for the I2RS = ephemeral control plane data store=E2=80=9D - since users don=E2=80=99t = write to the models directly (making validation, priority etc. = non-issues).
 
> On 23 Jan 2017, at 11:29, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:
> 
> I thought the topology models are coming = more or less from 
> OpenDaylight. If so, is ODL and I2RS = implementation?
> 
> /js
> 
> On Mon, Jan 23, 2017 at 06:04:28AM -0500, = Susan Hares wrote:
>> Juergen: 
>> 
>> Let's focus on your second point.  = The topology drafts are I2RS drafts
>> designed for the I2RS ephemeral control = plane data store.   How can these be
>> generic YANG modules when the following = is true: 
>> 
>> 1) I2RS Data models do not utilize the = configuration data store,
>> 2) I2RS Data Models do not require the same = validation as 
>> configuration data store,
>> 3) I2RS Data models require the use of = priority to handle the 
>> multi-write contention problem into the = I2RS Control Plane data 
>> store,
>> 4) I2RS require TLS with X.509v3 over = TCP for the 
>> mandatory-to-implement transport,
>> 
>> Do you disagree with = draft-ietf-netmod-revised-datastores?  If so,  
>> the discussion should be taken up with = netmod WG list.
>> Do you disagree with = i2rs-protocol-security-requirements?  That issue 
>> is closed based on IESG approval.
>> 
>> Sue Hares
>> 
>> -----Original Message-----
>> From: Juergen Schoenwaelder 
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: Monday, January 23, 2017 3:39 = AM
>> To: Susan = Hares
>> Cc: 'Kathleen = Moriarty'; 'The IESG';
>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; 
>> i2rs-chairs@ietf.org
>> Subject: Re: [i2rs] Kathleen Moriarty's = No Objection on
>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
>> 
>> Susan,
>> 
>> I consider tagging a YANG object = statically and universally in the 
>> data model as "does not need secure = communication" fundamentally 
>> flawed; I am not having an issue with = insecure communication in certain deployment contexts.
>> 
>> The topology drafts are regular generic = YANG models that just happen 
>> to be done in I2RS - I believe that = using the generic YANG security 
>> guidelines we have is good enough to = progress these drafts.
>> 
>> /js
>> 
>> On Thu, Jan 19, 2017 at 01:15:15PM = -0500, Susan Hares wrote:
>>> Juergen: 
>>> 
>>> I recognize that dislike insecure = communication.  You made a similar 
>>> comment during the WG LC and IETF = review of 
>>> = draft-ietf-i2rs-protocol-security-requirements.  However, the 
>>> = draft-ietf-i2rs-protocol-security-requirements were passed by the 
>>> I2RS WG and approved by the IESG = for RFC publication and it contains 
>>> the non-secure communication.  = The mandate from the I2RS WG for this 
>>> shepherd/co-chair is clear.
>>> 
>>> As the shepherd for the topology = drafts, I try to write-up something 
>>> that might address Kathleen's = Moriarty's concerns about the topology 
>>> draft's security issues about = privacy and the I2RS ephemeral control 
>>> plane
>> data
>>> store.   I welcome an = open discussion on my ideas
>>> (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons= ider).
>> The
>>> yang doctor's YANG  security consideration = template
>>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and 
>>> the privacy related RFCs (RFC6973) = note that some information is sensitive.
>>> Hopefully, this document extends = these guidelines to a new data store. 
>>> 
>>> Cheerily,
>>> Sue Hares
>>> 
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>> Sent: Thursday, January 19, 2017 = 10:34 AM
>>> To: Susan = Hares
>>> Cc: 'Kathleen = Moriarty'; 'The IESG'; 
>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; 
>>> i2rs-chairs@ietf.org
>>> Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on
>>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)
>>> 
>>> For what it is worth, I find the = notion that data models may be 
>>> written for a specific non-secure = transport plain broken. There is 
>>> hardly any content of a data model = I can think of which is generally 
>>> suitable for insecure = transports.
>>> 
>>> Can we please kill this idea of = _standardizing_ information that is 
>>> suitable to send over non-secure = transports? I really do not see how 
>>> the IETF can make a claim that a = given piece of information is never 
>>> worth protecting (=3D suitable for = non-secure transports).
>>> 
>>> Note that I am fine if in a certain = trusted tightly-coupled 
>>> deployment information is shipped = in whatever way but this is then a 
>>> property of the _deployment_ and = not a property of the _information_.
>>> 
>>> /js
>>> 
>>> On Thu, Jan 19, 2017 at 09:28:14AM = -0500, Susan Hares wrote:
>>>> Kathleen: 
>>>> 
>>>> I have written a draft = suggesting a template for the I2RS YANG 
>>>> modules
>>> which are designed to exist in the = I2RS Ephemeral Control Plane data store
>>> (configuration and operational = state).    
>>>> 
>>>> Draft location: 
>>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons= ider
>>>> /
>>>> 
>>>> I would appreciate an email = discussion with the security ADs, 
>>>> OPS/NM ADs,
>>> and Routing AD (Alia Atlas).  = I agree that this I2RS YANG data model
>>> (L3) and the base I2RS topology = model should both provide updated 
>>> YANG Security Considerations = sections. I would appreciate if Benoit 
>>> or you hold a discuss until we sort = out these issues.
>>>> 
>>>> Thank you,
>>>> 
>>>> Sue
>>>> 
>>>> -----Original Message-----
>>>> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
>>>> Sent: Wednesday, January 18, = 2017 9:44 PM
>>>> To: The = IESG
>>>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; shares@ndzh.com; 
>>>> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
>>>> Subject: Kathleen Moriarty's No = Objection on
>>>> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>>> 
>>>> Kathleen Moriarty has entered = the following ballot position for
>>>> = draft-ietf-i2rs-yang-l3-topology-08: No Objection
>>>> 
>>>> When responding, please keep = the subject line intact and reply to 
>>>> all email addresses included in = the To and CC lines. (Feel free to 
>>>> cut this introductory = paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more = information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other = ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo= gy/
>>>> 
>>>> 
>>>> 
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> COMMENT:
>>>> = -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
>>>> I agree with Alissa's comment = that the YANG module security 
>>>> consideration
>>> section guidelines need to be = followed and this shouldn't go forward 
>>> until that is corrected.  I'm = told it will be, thanks.
>>>> 
>>>> 
>>>> 
>>>> = _______________________________________________
>>>> i2rs mailing list
>>>> i2rs@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>>> -- 
>>> Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>>> 
>> 
>> -- 
>> Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
>> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
>> 
> 
> -- 
> Juergen = Schoenwaelder           = Jacobs University Bremen gGmbH
> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany
> Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/>
> 
> = _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
 
_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
= --Apple-Mail=_0D097B9C-9917-4039-A038-C57CC8D01B51-- From nobody Mon Jan 23 10:34:10 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 0A184129762; Mon, 23 Jan 2017 10:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jaq5BkhGzIo; Mon, 23 Jan 2017 10:34:05 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3A0129705; Mon, 23 Jan 2017 10:34:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7332C6E3; Mon, 23 Jan 2017 19:34:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nLuXmdFMrmrR; Mon, 23 Jan 2017 19:34:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 19:34:01 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAEB2200A8; Mon, 23 Jan 2017 19:34:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WbR7a96ifI5F; Mon, 23 Jan 2017 19:33:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33099200A7; Mon, 23 Jan 2017 19:33:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 035DD3E4764F; Mon, 23 Jan 2017 19:34:01 +0100 (CET) Date: Mon, 23 Jan 2017 19:34:01 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123183401.GB33438@elstar.local> Mail-Followup-To: Susan Hares , 'Giles Heron' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:34:09 -0000 There are no I2RS security guidelines. We should not confuse an individual I-D with guidelines. I believe the regular YANG security guidelines do the work. /js On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote: > Giles: >=20 > =20 >=20 > Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang mod= ules and the application of these guidelines to the I2RS Yang Topology mode= l. The guidelines for the I2RS Yang Module have three security considerat= ions: a) basic yang considerations, b) I2RS ephemeral state consideration= s, and c) insecure considerations. Since the topology model does not oper= ate over an insecure transport, the only thing that I believe you are quest= ioning is the "I2RS Yang Models for Secure-Only transports". Let's walk= through the draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topolo= gy) and the draft-ietf-i2rs-yang-network-topo models (ietf-network, ietf-ne= twork-topology). >=20 > =20 >=20 > The topology model as described in draft-ietf-i2rs-yang-network-topo-10.t= xt has read/write nodes at the network, link and termination point. Please= see the copy of the YHL diagrams below. Therefore, the basic topology mode= l is read-write. The L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) i= s read write. Please see a copy of the YHL diagrams below. Therefore, alt= hough your implementation is read-only, the approved YANG modules are read-= write. This must be considered in the Security considerations section. Th= e basic requirements for I2RS are:=20 >=20 > =20 >=20 > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20 >=20 > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication a= s a permissible implementation alternative.=20 >=20 > 3) write contention for two clients writing a node using I2RS priority (l= inked to I2RS User-ID)=20 >=20 > =20 >=20 > If the ODL model does not support writes to these data models, then it wo= uld not have to support the priority mechanism to resolve two clients writi= ng one data node. =20 >=20 > =20 >=20 > A) Basic Yang considerations=20 >=20 > =20 >=20 > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen ind= icate that the topology data could be considered sensitive read data. A pa= ragraph needs to be added to each draft indicating risks involved in provid= ing this information, and how deployments can keep this data safe. Privac= y issues are involved if the topologies are within homes or indicate user's= personal devices. =20 >=20 > =20 >=20 > If the I2RS mandatory transport is utilized, the data streams utilize mut= ual authentication, confidentiality, data integrity, and [practical] replay= protection for I2RS messages" and support "mechanism that mitigate DoS att= acks" and "DDos prevention". This level of security is useful when protect= ing sensitive data. =20 >=20 > =20 >=20 > 2) writeable nodes with sensitive data: Since the topology nodes are wri= teable, a security considerations needs to consider how these sensitive da= ta nodes will be protected. While ODL does not support writes to any data= node, the base models do. Therefore, security considerations must be writt= en here.=20 >=20 > =20 >=20 > 3) RPCs: No new RPCs are considered, but providing information on the not= ification data may be also useful.=20 >=20 > =20 >=20 > I2RS YANG Model Security Considerations >=20 > =20 >=20 > The requirement for this section is the following information:=20 >=20 > =20 >=20 > 1) Indication of deployment requirement for mandatory-to-implement NETCON= F (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 >=20 > 2) Discussion of RPCs specific to I2RS control plane data store, =20 >=20 > 3) NACM policy impacts the read-write state and augmentation of NACM by a= ccess control for read/writing of routing protocols (RACM), system informa= tion (SACM), and between datastores (config to/from ephemeral state).=20 >=20 > 4) Discussion of data retrieved from routing protocols, system informatio= n, dynamic configuration (dhcp)=20 >=20 > 5) Any suggestion for operational knobs that control overlay of I2RS conf= iguration over normal configuration and I2RS operational state over other o= perational state.=20 >=20 > =20 >=20 > For the topology data models (ietf-network, ietf-network-topology), the = paragraph could be:=20 >=20 > =20 >=20 > =E2=80=9CThe I2RS topology data models (ietf-network, ietf-network-topolo= gy) require mutual authentication, confidentiality, data integrity, and [pr= actical] replay protection for I2RS messages. Therefore, there is a mandato= ry-to-implement transport protocol of TLS (see RFC7589), or an optional tra= nsport support of RESTCONF (draft-ietf-netconf-restconf). This data mod= el does not implement any additional RPCs specific to this data model or an= y notifications. =20 >=20 > =20 >=20 > NACM policies may restrict exterior access to this YANG model to simply r= ead-only. For those NACM policies allowing write-access, there is a risk t= hat a write to a topology may create a looping topology or overload a parti= cular node. NACM policies may be augment by routing protocol access contro= l methods (RACM), system data access control methods (SACM), and inter-data= store access control mechanisms (DACM). The engagement of this policy sho= uld also be control by user policy switches (on/of). =20 >=20 > =20 >=20 > For the topology mode, the access to information on interfaces may be con= trol by SACM related to the interface model. Any I2RS topology model termi= nation point configuration which takes augments must take care not to cause= fluctuation in the interface state. Dynamic configuration protocols such= as DHCP or DHCPv6 may also alter the IP Addresses associated with an inter= face. DACM related to the inter-datastore policy on the precedence between= configuration of interface IP addresses, DHCP/DHCPv6 configuration, or Top= ology configuration will need to make sure the interface IP address does no= t cause fluctuations in the system. Deployments may provide general config= uration knobs that set the default state for NACM, RACM, SACM and DACM for = the topology database. =E2=80=9C >=20 > =20 >=20 > For the L3 topology data models (ietf-l3-unicast-topology), the paragrap= h could be:=20 >=20 > =20 >=20 > =E2=80=9CThe I2RS L3 Unicast topology data model (ietf-l3-unicast-topolog= y) require mutual authentication, confidentiality, data integrity, and [pra= ctical] replay protection for I2RS messages. Therefore, there is a mandator= y-to-implement transport protocol of NETCONF over TLS with X.509v3 mutual a= uthentication (RFC7589), or an optional transport support of RESTCONF (draf= t-ietf-netconf-restconf). This data model does not implement any additi= onal RPCs specific to this data model. This data model does support the fo= llowing new notifications: l3-node-event, l3-link-event, l3-prefix-event, a= nd termination-point-event. These events provide the information about th= e changing L3 topology which may provide information regarding key nodes. = Since these events are only transported over secure transports that support= mutual authentication, confidentiality, data integrity, and [practice] rep= lay protection, the use of this information for DoS of an I2RS agent (aka N= ETCONF server) requires the mutual authenticated client to be suborned. =20 >=20 > =20 >=20 > NACM policies may restrict exterior access to this YANG model to simply r= ead-only. For those NACM policies allowing write-access, there is a risk t= hat a write to a topology may create a looping topology or overload a parti= cular node. NACM policies may be augment by routing protocol access contro= l methods (RACM), system data access control methods (SACM), and inter-data= store access control mechanisms (DACM). The engagement of this policy sho= uld also be control by user policy switches (on/of). =20 >=20 > =20 >=20 > For the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model te= rmination point configuration which takes augments must take care not to ca= use fluctuation in the interface state. Dynamic configuration protocols s= uch as DHCP or DHCPv6 may also alter the IP Addresses associated with an in= terface. DACM related to the inter-datastore policy on the precedence betw= een configuration of interface IP addresses, DHCP/DHCPv6 configuration, or = Topology configuration will need to make sure the interface IP address does= not cause fluctuations in the system. The L3 Topology model may also rea= d information from the routing protocols (ospf, isis or others), or write d= ata to the routing protocol. RACM policy should be carefully set so that t= he routing protocols do not form a place to launch a DoS attack. Deploymen= ts may provide general configuration knobs that set the default state for N= ACM, RACM, SACM and DACM for the topology database. =E2=80=9C >=20 > =20 >=20 > =20 >=20 > Hopefully, this makes the suggestion for I2RS security policy a bit more = concrete. =20 >=20 > =20 >=20 > Sue Hares=20 >=20 > =20 >=20 > =20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =20 >=20 > High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20 >=20 > =20 >=20 > +--rw networks >=20 > +--rw network* [network-id] >=20 > +--rw network-types >=20 > +--rw network-id network-id >=20 > +--ro server-provided? boolean >=20 > +--rw supporting-network* [network-ref] >=20 > | +--rw network-ref -> /networks/network/network-id >=20 > +--rw node* [node-id] >=20 > +--rw node-id node-id >=20 > +--rw supporting-node* [network-ref node-ref] >=20 > +--rw network-ref -> ../../../supporting-network/ + >=20 > | network-ref >=20 > +--rw node-ref -> /networks/network/node/node-id >=20 > =20 >=20 > module: ietf-network-topology >=20 > augment /nd:networks/nd:network: >=20 > +--rw link* [link-id] >=20 > +--rw source >=20 > | +--rw source-node? -> ../../../nd:node/node-id >=20 > | +--rw source-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ >=20 > | ../source-node]/termination-point/tp-id >=20 > +--rw destination >=20 > | +--rw dest-node? -> ../../../nd:node/node-id >=20 > | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ >=20 > | ../dest-node]/termination-point/tp-id >=20 > +--rw link-id link-id >=20 > +--rw supporting-link* [network-ref link-ref] >=20 > +--rw network-ref -> ../../../nd:supporting-network/+ >=20 > | network-ref >=20 > +--rw link-ref -> /nd:networks/network+ >=20 > [nd:network-id=3Dcurrent()/../network-ref]/+ >=20 > link/link-id >=20 > =20 >=20 > augment /nd:networks/nd:network/nd:node: >=20 > +--rw termination-point* [tp-id] >=20 > +--rw tp-id tp-id >=20 > +--rw supporting-termination-point* [network-ref node-ref tp-ref] >=20 > +--rw network-ref -> ../../../nd:supporting-node/network-ref >=20 > +--rw node-ref -> ../../../nd:supporting-node/node-ref >=20 > +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ >=20 > current()/../network-ref]/node+ >=20 > [nd:node-id=3Dcurrent()/../node-ref]/+ >=20 > termination-point/tp-id >=20 > =20 >=20 > =20 >=20 > module: ietf-l3-unicast-topology >=20 > augment /nd:networks/nd:network/nd:network-types: >=20 > +--rw l3-unicast-topology! >=20 > augment /nd:networks/nd:network: >=20 > +--rw l3-topology-attributes >=20 > +--rw name? string >=20 > +--rw flag* l3-flag-type >=20 > augment /nd:networks/nd:network/nd:node: >=20 > +--rw l3-node-attributes >=20 > +--rw name? inet:domain-name >=20 > +--rw flag* node-flag-type >=20 > +--rw router-id* inet:ip-address >=20 > +--rw prefix* [prefix] >=20 > +--rw prefix inet:ip-prefix >=20 > +--rw metric? uint32 >=20 > +--rw flag* prefix-flag-type >=20 > augment /nd:networks/nd:network/lnk:link: >=20 > +--rw l3-link-attributes >=20 > +--rw name? string >=20 > +--rw flag* link-flag-type >=20 > +--rw metric? uint32 >=20 > augment /nd:networks/nd:network/nd:node/lnk:termination-point: >=20 > +--rw l3-termination-point-attributes >=20 > +--rw (termination-point-type)? >=20 > +--:(ip) >=20 > | +--rw ip-address* inet:ip-address >=20 > +--:(unnumbered) >=20 > | +--rw unnumbered-id? uint32 >=20 > +--:(interface-name) >=20 > +--ro interface-name? string >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com]=20 > Sent: Monday, January 23, 2017 6:45 AM > To: Juergen Schoenwaelder > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org= ; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-y= ang-l3-topology-08: (with COMMENT) >=20 > =20 >=20 > ODL does, indeed, implement the topology models, but generally the data i= n the topology model is operational data, so I=E2=80=99m not sure how that = fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data store= =E2=80=9D - since users don=E2=80=99t write to the models directly (making = validation, priority etc. non-issues). >=20 > =20 >=20 > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder wrote: >=20 > >=20 >=20 > > I thought the topology models are coming more or less from=20 >=20 > > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > >=20 >=20 > > /js >=20 > >=20 >=20 > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >=20 > >> Juergen:=20 >=20 > >>=20 >=20 > >> Let's focus on your second point. The topology drafts are I2RS drafts >=20 > >> designed for the I2RS ephemeral control plane data store. How can th= ese be >=20 > >> generic YANG modules when the following is true:=20 >=20 > >>=20 >=20 > >> 1) I2RS Data models do not utilize the configuration data store, >=20 > >> 2) I2RS Data Models do not require the same validation as=20 >=20 > >> configuration data store, >=20 > >> 3) I2RS Data models require the use of priority to handle the=20 >=20 > >> multi-write contention problem into the I2RS Control Plane data=20 >=20 > >> store, >=20 > >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >=20 > >> mandatory-to-implement transport, >=20 > >>=20 >=20 > >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20 >=20 > >> the discussion should be taken up with netmod WG list. >=20 > >> Do you disagree with i2rs-protocol-security-requirements? That issue= =20 >=20 > >> is closed based on IESG approval. >=20 > >>=20 >=20 > >> Sue Hares >=20 > >>=20 >=20 > >> -----Original Message----- >=20 > >> From: Juergen Schoenwaelder=20 >=20 > >> [ mailto:j.schoenwaelder= @jacobs-university.de] >=20 > >> Sent: Monday, January 23, 2017 3:39 AM >=20 > >> To: Susan Hares >=20 > >> Cc: 'Kathleen Moriarty'; 'The IESG'; >=20 > >> draft-ietf-i2rs-ya= ng-l3-topology@ietf.org; i2rs@ietf.org;=20 >=20 > >> i2rs-chairs@ietf.org >=20 > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >=20 > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>=20 >=20 > >> Susan, >=20 > >>=20 >=20 > >> I consider tagging a YANG object statically and universally in the=20 >=20 > >> data model as "does not need secure communication" fundamentally=20 >=20 > >> flawed; I am not having an issue with insecure communication in certai= n deployment contexts. >=20 > >>=20 >=20 > >> The topology drafts are regular generic YANG models that just happen= =20 >=20 > >> to be done in I2RS - I believe that using the generic YANG security=20 >=20 > >> guidelines we have is good enough to progress these drafts. >=20 > >>=20 >=20 > >> /js >=20 > >>=20 >=20 > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >=20 > >>> Juergen:=20 >=20 > >>>=20 >=20 > >>> I recognize that dislike insecure communication. You made a similar= =20 >=20 > >>> comment during the WG LC and IETF review of=20 >=20 > >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >=20 > >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20 >=20 > >>> I2RS WG and approved by the IESG for RFC publication and it contains= =20 >=20 > >>> the non-secure communication. The mandate from the I2RS WG for this= =20 >=20 > >>> shepherd/co-chair is clear. >=20 > >>>=20 >=20 > >>> As the shepherd for the topology drafts, I try to write-up something= =20 >=20 > >>> that might address Kathleen's Moriarty's concerns about the topology= =20 >=20 > >>> draft's security issues about privacy and the I2RS ephemeral control= =20 >=20 > >>> plane >=20 > >> data >=20 > >>> store. I welcome an open discussion on my ideas >=20 > >>> ( https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >=20 > >> The >=20 > >>> yang doctor's YANG security consideration template >=20 > >>> ( http= s://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and=20 >=20 > >>> the privacy related RFCs (RFC6973) note that some information is sens= itive. >=20 > >>> Hopefully, this document extends these guidelines to a new data store= =2E=20 >=20 > >>>=20 >=20 > >>> Cheerily, >=20 > >>> Sue Hares >=20 > >>>=20 >=20 > >>> -----Original Message----- >=20 > >>> From: Juergen Schoenwaelder >=20 > >>> [ mailto:j.schoenwaelde= r@jacobs-university.de] >=20 > >>> Sent: Thursday, January 19, 2017 10:34 AM >=20 > >>> To: Susan Hares >=20 > >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >=20 > >>> draft-ietf-i2rs-y= ang-l3-topology@ietf.org; i2rs@ietf.org;=20 >=20 > >>> i2rs-chairs@ietf.org >=20 > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >=20 > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>>=20 >=20 > >>> For what it is worth, I find the notion that data models may be=20 >=20 > >>> written for a specific non-secure transport plain broken. There is=20 >=20 > >>> hardly any content of a data model I can think of which is generally= =20 >=20 > >>> suitable for insecure transports. >=20 > >>>=20 >=20 > >>> Can we please kill this idea of _standardizing_ information that is= =20 >=20 > >>> suitable to send over non-secure transports? I really do not see how= =20 >=20 > >>> the IETF can make a claim that a given piece of information is never= =20 >=20 > >>> worth protecting (=3D suitable for non-secure transports). >=20 > >>>=20 >=20 > >>> Note that I am fine if in a certain trusted tightly-coupled=20 >=20 > >>> deployment information is shipped in whatever way but this is then a= =20 >=20 > >>> property of the _deployment_ and not a property of the _information_. >=20 > >>>=20 >=20 > >>> /js >=20 > >>>=20 >=20 > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >=20 > >>>> Kathleen:=20 >=20 > >>>>=20 >=20 > >>>> I have written a draft suggesting a template for the I2RS YANG=20 >=20 > >>>> modules >=20 > >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >=20 > >>> (configuration and operational state). =20 >=20 > >>>>=20 >=20 > >>>> Draft location:=20 >=20 > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider >=20 > >>>> / >=20 > >>>>=20 >=20 > >>>> I would appreciate an email discussion with the security ADs,=20 >=20 > >>>> OPS/NM ADs, >=20 > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model >=20 > >>> (L3) and the base I2RS topology model should both provide updated=20 >=20 > >>> YANG Security Considerations sections. I would appreciate if Benoit= =20 >=20 > >>> or you hold a discuss until we sort out these issues. >=20 > >>>>=20 >=20 > >>>> Thank you, >=20 > >>>>=20 >=20 > >>>> Sue >=20 > >>>>=20 >=20 > >>>> -----Original Message----- >=20 > >>>> From: Kathleen Moriarty [ = mailto:Kathleen.Moriarty.ietf@gmail.com] >=20 > >>>> Sent: Wednesday, January 18, 2017 9:44 PM >=20 > >>>> To: The IESG >=20 > >>>> Cc: draft-ietf-i= 2rs-yang-l3-topology@ietf.org; shares@ndzh.com;= =20 >=20 > >>>> i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >=20 > >>>> Subject: Kathleen Moriarty's No Objection on >=20 > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>>>=20 >=20 > >>>> Kathleen Moriarty has entered the following ballot position for >=20 > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >=20 > >>>>=20 >=20 > >>>> When responding, please keep the subject line intact and reply to=20 >=20 > >>>> all email addresses included in the To and CC lines. (Feel free to= =20 >=20 > >>>> cut this introductory paragraph, however.) >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> Please refer to >=20 > >>>> https:/= /www.ietf.org/iesg/statement/discuss-criteria.html >=20 > >>>> for more information about IESG DISCUSS and COMMENT positions. >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> The document, along with other ballot positions, can be found here: >=20 > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> ------------------------------------------------------------------- >=20 > >>>> - >=20 > >>>> -- >=20 > >>>> COMMENT: >=20 > >>>> ------------------------------------------------------------------- >=20 > >>>> - >=20 > >>>> -- >=20 > >>>>=20 >=20 > >>>> I agree with Alissa's comment that the YANG module security=20 >=20 > >>>> consideration >=20 > >>> section guidelines need to be followed and this shouldn't go forward= =20 >=20 > >>> until that is corrected. I'm told it will be, thanks. >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> _______________________________________________ >=20 > >>>> i2rs mailing list >=20 > >>>> i2rs@ietf.org >=20 > >>>> https://www.ietf.org/m= ailman/listinfo/i2rs >=20 > >>>=20 >=20 > >>> --=20 >=20 > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >=20 > >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > >>>=20 >=20 > >>=20 >=20 > >> --=20 >=20 > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >=20 > >> Fax: +49 421 200 3103 < h= ttp://www.jacobs-university.de/> >=20 > >>=20 >=20 > >=20 >=20 > > --=20 >=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >=20 > > Fax: +49 421 200 3103 < ht= tp://www.jacobs-university.de/> >=20 > >=20 >=20 > > _______________________________________________ >=20 > > i2rs mailing list >=20 > > i2rs@ietf.org >=20 > > https://www.ietf.org/mail= man/listinfo/i2rs >=20 > =20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 10:47:31 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 7017C12978C; Mon, 23 Jan 2017 10:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xqe-Ye-4hxw; Mon, 23 Jan 2017 10:47:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFB129771; Mon, 23 Jan 2017 10:47:22 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A23E1AE0285; Mon, 23 Jan 2017 19:47:21 +0100 (CET) Date: Mon, 23 Jan 2017 19:47:21 +0100 (CET) Message-Id: <20170123.194721.1193117831378217486.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <000701d27594$28d12350$7a7369f0$@ndzh.com> References: <023e01d2758a$fe85bd80$fb913880$@ndzh.com> <20170123.163215.1929278119114265404.mbj@tail-f.com> <000701d27594$28d12350$7a7369f0$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 18:47:25 -0000 "Susan Hares" wrote: > Martin: > > Answers inline. > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Monday, January 23, 2017 10:32 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" wrote: > >> Martin: > >> > >> > >> > >> Thank you for your insightful questions. My answer to your questions > >> come from my understanding of the draft-ietf-netmod-revised-datastores-00 > and > >> discussions with that design team at IETF 97. We have been moving many > >> things in parallel at the IETF rather than do single threaded work. The > >> Topoology work was completed 1 year in advance of the > >> draft-ietf-netmod-revised-datastores-00.txt. > > >Right; this is why I think an additional note in these modules are > necessary. If you just read these topoly drafts, you will find a normal > YANG module that has a "config true" subtree. > >Without additional guidance, it is not clear that these data models "do not > utilize the configuration data store" (if this is true). > > Sue: Sounds like a good idea. I'll suggest this to the authors as the > document shepherd. > > >> #1) model's nodes are "config true", and that "The YANG module defined > >> in this memo is designed to be accessed via the NETCONF protocol". If > >> it is true that these data models do not utilize the configuration > >> data stores, what does the "server-provided" leaf, and the text about > "client-configured" > >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > >> > >> If the server-provided leaf is true, it indicates that the data is > >> populated by the I2RS Agent (aka netconf server) > > >Doesn't this procedure involve the normal configuration data stores? > >If it does, I think we're good. If it doesn't, I think the additional note > should be added. > > Sue: The model is in the I2RS control plane data store. According to > draft-ietf-netmod-revised-datatstores-00.txt this is note the normal > configuration data store. Ok. Just to make sure I understand this correctly - these topology models are intended to be I2RS-specific, and they cannot be used for any other purpose. If anyone needs a general topology model outside of the I2RS protocol, they will have to design their own model. Is this correct? > Does a note in the text plus a note at the > beginning of the data model suffice? To me, it feels weird that a model that is designed solely for the I2RS protocol is published *before* the details of the I2RS protocol are defined. But it this is what the WG wants, then a note that explains this would be useful. I assume that the idea is that vendors will use some proprietary mechanism for now. > >> rather than the I2RS Client (aka > >> netconf client). The I2RS architecture has aligned the two > architecture > >> concepts so the I2RS protocol is designed to be a re-use protocol for > >> the NETCONF protocol and the RESTCONF protocols as its message > >> transport protocols. > >> > >> draft-ietf-netmod-revised-datastores-00 states the following three > >> suggestions for supporting different datastores: > >> > >> > >> o For systems supporting or configuration > >> > >> datastores, the operation may be used to retrieve > >> > >> data stored in these new datastores. > >> > >> > >> > >> o A new operation should be added to retrieve the operational > >> state > >> > >> data store (e.g., ). An alternative is to define a > >> > >> new operation to retrieve data from any datastore (e.g., > >> > >> with the name of the datastore as a parameter). In > >> > >> principle could work but it would be a confusing > >> > >> name. > >> > >> > >> > >> o The operation will be deprecated since it returns data > >> from > >> > >> two datastores that may overlap in the revised datastore model. > >> > >> > >> > >> Based on this input, the I2RS ephemeral control plane data store > >> should use a "get-data I2RS-ephemeral" to get data from the I2RS > ephemeral data store > >> (CT, RW). To retrieve information from the applied configuration data > >> store, the "get-config" may be used. To retrieve state from the > >> operational state "get-state" should be used. > >> > >> > >> 2) Your suggestion to add another note about configuration true > >> > >> The config "true" is being implemented as the > >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see > diagram). > >> It is just in a different data store. Where and how the data store > >> information is stored, is unclear to me at this time. Where do you > >> think it belongs? > > > I always thought that the topology models could be written to through the > normal configuration data stores, in which case the server would set the > "server-provided" leaf to "false". It seems that you have some other > mechanism in mind? > > The design team for drat-ietf-netmod-revised-datastores-00.txt indicated > that the client written topology with "server-provided" leaf set to "false" > is written in the I2RS Control Plane data store. Ok. As you might know, I am the editor for drat-ietf-netmod-revised-datastores-00, and thus part of the design team, and I haven't seen any discussion about this. Was it discussed on the I2RS ML? /martin > An I2RS implementation > then combines the I2RS Control Plane data store with the intended > configuration data store (based on internal configuration knobs) and > installs this in a node. A client can query the topology data nodes in the > applied configuration data store. The response giving the topology nodes > will indicate that a dynamic control plane protocol inserted these nodes. > > I am only trying to interpret the netmod design and align the I2RS data > models (topology, RIB, FB-RIB) to this design. > > Thank you for your suggestions on the data model. > > Sue Hares > > > > > > /martin > > > > > 3) implementations > > > > > > > > Right now, the ODL implementation can utilize "get-config" to obtain > > the I2RS topology model since the I2RS topology database has no > > equivalent in the intended config. After the > > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > > will return from the applied configuration the Topology model with an > indication that it is dynamic (see > > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > > implementation can simply augment its current get-config with an > indication > > that the topology model is a "dynamic" data store. > > > > > > > > As another example, my understanding is that a change to the ConfD > > implementation would be to allow a "get-data" and "write-data" that allows > > the specification of a data store such as the I2RS data store. A > > get-config of the applied data store should have a "dynamic" flag for > > the topology database. > > > > > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > > but I am behind on event email. > > > > > > > > Cheerily, > > > > > > > > Sue > > > > > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Monday, January 23, 2017 6:47 AM > > To: shares@ndzh.com > > Cc: j.schoenwaelder@jacobs-university.de; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > Hi, > > > > > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > > > Juergen: > > > > > > > > > > Let's focus on your second point. The topology drafts are I2RS > > > drafts > > > > > designed for the I2RS ephemeral control plane data store. How can > these > > be > > > > > generic YANG modules when the following is true: > > > > > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > > > > > This was not clear to me. I note that the data model's nodes are > > "config true", and that "The YANG module defined in this memo is > > designed to be accessed via the NETCONF protocol". > > > > > > > > If it is true that these data models do not utilize the configuration > > data stores, what does the "server-provided" leaf, and the text about > > "client-configured" in section 4.4.10 of > > draft-ietf-i2rs-yang-network-topo refer to? > > > > > > > > If in fact this is correct, I think it would be helpful if a note was > > added to the YANG modules, that explains that these models are not > > supposed to be implemented in the same way as other "config true" data > > models. In the best of worlds it would also describe how they are > > supposed to be implemented (but I assume that this is up to each vendor > for now). > > > > > > > > I also note that it is not clear how such models would be advertised > > by a NETCONF server. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > > > configuration data store, > > > > > 3) I2RS Data models require the use of priority to handle the > > > > > multi-write contention problem into the I2RS Control Plane data > > > store, > > > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > > > mandatory-to-implement transport, > > > > > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > > > the discussion should be taken up with netmod WG list. > > > > > Do you disagree with i2rs-protocol-security-requirements? That > > > issue > > > > > is closed based on IESG approval. > > > > > > > > > > Sue Hares > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > [ > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > Sent: Monday, January 23, 2017 3:39 AM > > > > > To: Susan Hares > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org; > > > > > i2rs-chairs@ietf.org > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > Susan, > > > > > > > > > > I consider tagging a YANG object statically and universally in the > > > > > data model as "does not need secure communication" fundamentally > > > > > flawed; I am not having an issue with insecure communication in > > > certain > > deployment contexts. > > > > > > > > > > The topology drafts are regular generic YANG models that just happen > > > > > to be done in I2RS - I believe that using the generic YANG security > > > > > guidelines we have is good enough to progress these drafts. > > > > > > > > > > /js > > > > > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > > > Juergen: > > > > > > > > > > > > I recognize that dislike insecure communication. You made a > > > > similar > > > > > > comment during the WG LC and IETF review of > > > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > > > draft-ietf-i2rs-protocol-security-requirements were passed by the > > > > > > I2RS WG and approved by the IESG for RFC publication and it > > > > contains > > > > > > the non-secure communication. The mandate from the I2RS WG for > > > > this > > > > > > shepherd/co-chair is clear. > > > > > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > > something > > > > > > that might address Kathleen's Moriarty's concerns about the > > > > topology > > > > > > draft's security issues about privacy and the I2RS ephemeral > > > > control > > > > > > plane > > > > > data > > > > > > store. I welcome an open discussion on my ideas > > > > > > ( > > > > > > > er> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > > > The > > > > > > yang doctor's YANG security consideration template > > > > > > ( > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > > > the privacy related RFCs (RFC6973) note that some information is > > sensitive. > > > > > > Hopefully, this document extends these guidelines to a new data store. > > > > > > > > > > > > > Cheerily, > > > > > > Sue Hares > > > > > > > > > > > > -----Original Message----- > > > > > > From: Juergen Schoenwaelder > > > > > > [ > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > > > To: Susan Hares > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org; > > > > > > i2rs-chairs@ietf.org > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > For what it is worth, I find the notion that data models may be > > > > > > written for a specific non-secure transport plain broken. There is > > > > > > hardly any content of a data model I can think of which is > > > > generally > > > > > > suitable for insecure transports. > > > > > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > > is > > > > > > suitable to send over non-secure transports? I really do not see > > > > how > > > > > > the IETF can make a claim that a given piece of information is > > > > never > > > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > > > deployment information is shipped in whatever way but this is then > > > > a > > > > > > property of the _deployment_ and not a property of the _information_. > > > > > > > > > > > > /js > > > > > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > > > Kathleen: > > > > > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > > > modules > > > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > > data > > store > > > > > > (configuration and operational state). > > > > > > > > > > > > > > Draft location: > > > > > > > > > > > > > > > > ide> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > > > r/ > > > > > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > > > OPS/NM ADs, > > > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > > model > > > > > > (L3) and the base I2RS topology model should both provide updated > > > > > > YANG Security Considerations sections. I would appreciate if > > > > Benoit > > > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kathleen Moriarty [ > > > > > > > mailto:Kathleen.Moriarty.ietf@gmail.com] > > > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > > > To: The IESG > > > > > > > Cc: > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > shares@ndzh.com; > > > > > > > i2rs-chairs@ietf.org; > > shares@ndzh.com; > > i2rs@ietf.org > > > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > Kathleen Moriarty has entered the following ballot position for > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > to > > > > > > > all email addresses included in the To and CC lines. (Feel free > > > > > to > > > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > > > > Please refer to > > > > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > > > > > > > > > > gy/> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > COMMENT: > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > > > consideration > > > > > > section guidelines need to be followed and this shouldn't go > > > > forward > > > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > i2rs mailing list > > > > > > > i2rs@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > > Fax: +49 421 200 3103 < > > http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < > > http://www.jacobs-university.de/> > > > > > > > > > > _______________________________________________ > > > > > i2rs mailing list > > > > > i2rs@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jan 23 11:09:18 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 614E01297A7; Mon, 23 Jan 2017 11:09:17 -0800 (PST) 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 sNAvdeGJecGk; Mon, 23 Jan 2017 11:09:15 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E51129496; Mon, 23 Jan 2017 11:09:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <20170123183401.GB33438@elstar.local> In-Reply-To: <20170123183401.GB33438@elstar.local> Date: Mon, 23 Jan 2017 14:04:58 -0500 Message-ID: <00dd01d275ab$97ff6400$c7fe2c00$@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: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+AvYiyDYB8tFV9gI6fU8pAp4O91MCnwXEn6BNf/kg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 19:09:17 -0000 Juergen:=20 There are two I2RS drafts related to security: = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-security-environment-reqs-02. The = draft-ietf-i2rs-protocol-security-requirements has pass IESG review and = is waiting for the RFC editor. The = draft-i2rs-security-environment-reqs-02.txt has not passed WG LC. You = are correct that draft-hares-i2rs-yang-sec-consider-00.txt is an = individual draft. This individual draft is also based on = draft-ietf-netmod-ietf-revised-datastores-00.txt. =20 The impetus for this individual draft = (draft-hares-i2rs-yang-sec-consider) was the DISCUSS by the security ADs = regarding security consideration section in two drafts: = draft-ietf-i2rs-yang-network-topology and = draft-ietf-i2rs-yang-l3-topology-08.txt. The draft indicates the = following 6 areas where the I2RS protocol and environment security = requirements differ: 1) mandatory-to-implement transport layer, 2) = priority and secondary opaque identifier, 3) different data store, 4) = different validations in I2RS control plane data store, 5) different = NACM policy, and 6) optional insecure protocol. None of these are = handled in the current YANG security considerations template. Items 1, = 2, and 5 are specified in draft-ietf-protocol-security-requirements = plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the = draft-i2rs-security-environment-reqs-02.txt. Item 5 arises out of = SEC-ENV-REQ-05 and SEC-ENV-REQ-06 in the = draft-ietf-i2rs-security-environment-reqs-02.txt. Items 3 and 4 arise = out of the draft-ietf-netmod-revised-datastores-00.txt. I welcome a = discussion on whether this individual draft truly represents the content = of these 3 drafts. =20 The individual draft tries to provide the information from the = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-security-environment-reqs-02.txt in a format consistent = with the current Yang Considerations model. I welcome comments on = whether this draft provides a format consistent with the current yang = considerations model formats. The purpose behind this draft is to = establish a template for security considerations that the netmod/netconf = experts, I2RS protocol experts, and the security ADs would accept. The = urgency for this discussion is to resolve the valid points made in the = security AD's DISCUSS on these two YANG modules which are key to other = YANG modules. =20 Cheerily,=20 Sue Hares=20 -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, January 23, 2017 1:34 PM To: Susan Hares Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) There are no I2RS security guidelines. We should not confuse an = individual I-D with guidelines. I believe the regular YANG security guidelines do the work. /js On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote: > Giles: >=20 > =20 >=20 > Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS = Yang modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). >=20 > =20 >=20 > The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 >=20 > =20 >=20 > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, >=20 > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual = authentication as a permissible implementation alternative.=20 >=20 > 3) write contention for two clients writing a node using I2RS priority = > (linked to I2RS User-ID) >=20 > =20 >=20 > If the ODL model does not support writes to these data models, then it = would not have to support the priority mechanism to resolve two clients = writing one data node. =20 >=20 > =20 >=20 > A) Basic Yang considerations >=20 > =20 >=20 > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 >=20 > =20 >=20 > If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 >=20 > =20 >=20 > 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 >=20 > =20 >=20 > 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 >=20 > =20 >=20 > I2RS YANG Model Security Considerations >=20 > =20 >=20 > The requirement for this section is the following information:=20 >=20 > =20 >=20 > 1) Indication of deployment requirement for mandatory-to-implement=20 > NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), >=20 > 2) Discussion of RPCs specific to I2RS control plane data store, =20 >=20 > 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 >=20 > 4) Discussion of data retrieved from routing protocols, system=20 > information, dynamic configuration (dhcp) >=20 > 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 >=20 > =20 >=20 > For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 >=20 > =20 >=20 > =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 >=20 > =20 >=20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 >=20 > =20 >=20 > For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C >=20 > =20 >=20 > For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 >=20 > =20 >=20 > =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 >=20 > =20 >=20 > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 >=20 > =20 >=20 > For the L3 topology mode, the access to information on interfaces may = be control by SACM related to the interface model. Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol. RACM policy should be carefully set so = that the routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C >=20 > =20 >=20 > =20 >=20 > Hopefully, this makes the suggestion for I2RS security policy a bit = more concrete. =20 >=20 > =20 >=20 > Sue Hares >=20 > =20 >=20 > =20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =20 >=20 > High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt >=20 > =20 >=20 > +--rw networks >=20 > +--rw network* [network-id] >=20 > +--rw network-types >=20 > +--rw network-id network-id >=20 > +--ro server-provided? boolean >=20 > +--rw supporting-network* [network-ref] >=20 > | +--rw network-ref -> /networks/network/network-id >=20 > +--rw node* [node-id] >=20 > +--rw node-id node-id >=20 > +--rw supporting-node* [network-ref node-ref] >=20 > +--rw network-ref -> ../../../supporting-network/ = + >=20 > | network-ref >=20 > +--rw node-ref -> = /networks/network/node/node-id >=20 > =20 >=20 > module: ietf-network-topology >=20 > augment /nd:networks/nd:network: >=20 > +--rw link* [link-id] >=20 > +--rw source >=20 > | +--rw source-node? -> ../../../nd:node/node-id >=20 > | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >=20 > | ../source-node]/termination-point/tp-id >=20 > +--rw destination >=20 > | +--rw dest-node? -> ../../../nd:node/node-id >=20 > | +--rw dest-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ >=20 > | ../dest-node]/termination-point/tp-id >=20 > +--rw link-id link-id >=20 > +--rw supporting-link* [network-ref link-ref] >=20 > +--rw network-ref -> ../../../nd:supporting-network/+ >=20 > | network-ref >=20 > +--rw link-ref -> /nd:networks/network+ >=20 > =20 > [nd:network-id=3Dcurrent()/../network-ref]/+ >=20 > link/link-id >=20 > =20 >=20 > augment /nd:networks/nd:network/nd:node: >=20 > +--rw termination-point* [tp-id] >=20 > +--rw tp-id tp-id >=20 > +--rw supporting-termination-point* [network-ref node-ref=20 > tp-ref] >=20 > +--rw network-ref -> = ../../../nd:supporting-node/network-ref >=20 > +--rw node-ref -> ../../../nd:supporting-node/node-ref >=20 > +--rw tp-ref -> = /nd:networks/network[nd:network-id=3D+ >=20 > current()/../network-ref]/node+ >=20 > [nd:node-id=3Dcurrent()/../node-ref]/+ >=20 > termination-point/tp-id >=20 > =20 >=20 > =20 >=20 > module: ietf-l3-unicast-topology >=20 > augment /nd:networks/nd:network/nd:network-types: >=20 > +--rw l3-unicast-topology! >=20 > augment /nd:networks/nd:network: >=20 > +--rw l3-topology-attributes >=20 > +--rw name? string >=20 > +--rw flag* l3-flag-type >=20 > augment /nd:networks/nd:network/nd:node: >=20 > +--rw l3-node-attributes >=20 > +--rw name? inet:domain-name >=20 > +--rw flag* node-flag-type >=20 > +--rw router-id* inet:ip-address >=20 > +--rw prefix* [prefix] >=20 > +--rw prefix inet:ip-prefix >=20 > +--rw metric? uint32 >=20 > +--rw flag* prefix-flag-type >=20 > augment /nd:networks/nd:network/lnk:link: >=20 > +--rw l3-link-attributes >=20 > +--rw name? string >=20 > +--rw flag* link-flag-type >=20 > +--rw metric? uint32 >=20 > augment /nd:networks/nd:network/nd:node/lnk:termination-point: >=20 > +--rw l3-termination-point-attributes >=20 > +--rw (termination-point-type)? >=20 > +--:(ip) >=20 > | +--rw ip-address* inet:ip-address >=20 > +--:(unnumbered) >=20 > | +--rw unnumbered-id? uint32 >=20 > +--:(interface-name) >=20 > +--ro interface-name? string >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Monday, January 23, 2017 6:45 AM > To: Juergen Schoenwaelder > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org;=20 > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > =20 >=20 > ODL does, indeed, implement the topology models, but generally the = data in the topology model is operational data, so I=E2=80=99m not sure = how that fits with =E2=80=9Cdesigned for the I2RS ephemeral control = plane data store=E2=80=9D - since users don=E2=80=99t write to the = models directly (making validation, priority etc. non-issues). >=20 > =20 >=20 > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = wrote: >=20 > >=20 >=20 > > I thought the topology models are coming more or less from >=20 > > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > >=20 >=20 > > /js >=20 > >=20 >=20 > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >=20 > >> Juergen:=20 >=20 > >>=20 >=20 > >> Let's focus on your second point. The topology drafts are I2RS=20 > >> drafts >=20 > >> designed for the I2RS ephemeral control plane data store. How can = these be >=20 > >> generic YANG modules when the following is true:=20 >=20 > >>=20 >=20 > >> 1) I2RS Data models do not utilize the configuration data store, >=20 > >> 2) I2RS Data Models do not require the same validation as >=20 > >> configuration data store, >=20 > >> 3) I2RS Data models require the use of priority to handle the >=20 > >> multi-write contention problem into the I2RS Control Plane data >=20 > >> store, >=20 > >> 4) I2RS require TLS with X.509v3 over TCP for the >=20 > >> mandatory-to-implement transport, >=20 > >>=20 >=20 > >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, >=20 > >> the discussion should be taken up with netmod WG list. >=20 > >> Do you disagree with i2rs-protocol-security-requirements? That=20 > >> issue >=20 > >> is closed based on IESG approval. >=20 > >>=20 >=20 > >> Sue Hares >=20 > >>=20 >=20 > >> -----Original Message----- >=20 > >> From: Juergen Schoenwaelder >=20 > >> [ =20 > >> mailto:j.schoenwaelder@jacobs-university.de] >=20 > >> Sent: Monday, January 23, 2017 3:39 AM >=20 > >> To: Susan Hares >=20 > >> Cc: 'Kathleen Moriarty'; 'The IESG'; >=20 > >> =20 > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > >> i2rs@ietf.org; >=20 > >> i2rs-chairs@ietf.org >=20 > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >=20 > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>=20 >=20 > >> Susan, >=20 > >>=20 >=20 > >> I consider tagging a YANG object statically and universally in the >=20 > >> data model as "does not need secure communication" fundamentally >=20 > >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >=20 > >>=20 >=20 > >> The topology drafts are regular generic YANG models that just=20 > >> happen >=20 > >> to be done in I2RS - I believe that using the generic YANG security >=20 > >> guidelines we have is good enough to progress these drafts. >=20 > >>=20 >=20 > >> /js >=20 > >>=20 >=20 > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >=20 > >>> Juergen:=20 >=20 > >>>=20 >=20 > >>> I recognize that dislike insecure communication. You made a=20 > >>> similar >=20 > >>> comment during the WG LC and IETF review of >=20 > >>> draft-ietf-i2rs-protocol-security-requirements. However, the >=20 > >>> draft-ietf-i2rs-protocol-security-requirements were passed by the >=20 > >>> I2RS WG and approved by the IESG for RFC publication and it=20 > >>> contains >=20 > >>> the non-secure communication. The mandate from the I2RS WG for=20 > >>> this >=20 > >>> shepherd/co-chair is clear. >=20 > >>>=20 >=20 > >>> As the shepherd for the topology drafts, I try to write-up=20 > >>> something >=20 > >>> that might address Kathleen's Moriarty's concerns about the=20 > >>> topology >=20 > >>> draft's security issues about privacy and the I2RS ephemeral=20 > >>> control >=20 > >>> plane >=20 > >> data >=20 > >>> store. I welcome an open discussion on my ideas >=20 > >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >=20 > >> The >=20 > >>> yang doctor's YANG security consideration template >=20 > >>> ( =20 > >>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and >=20 > >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >=20 > >>> Hopefully, this document extends these guidelines to a new data = store.=20 >=20 > >>>=20 >=20 > >>> Cheerily, >=20 > >>> Sue Hares >=20 > >>>=20 >=20 > >>> -----Original Message----- >=20 > >>> From: Juergen Schoenwaelder >=20 > >>> [ =20 > >>> mailto:j.schoenwaelder@jacobs-university.de] >=20 > >>> Sent: Thursday, January 19, 2017 10:34 AM >=20 > >>> To: Susan Hares >=20 > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; >=20 > >>> =20 > >>> draft-ietf-i2rs-yang-l3-topology@ietf.org; = > >>> i2rs@ietf.org; >=20 > >>> i2rs-chairs@ietf.org >=20 > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >=20 > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>>=20 >=20 > >>> For what it is worth, I find the notion that data models may be >=20 > >>> written for a specific non-secure transport plain broken. There is >=20 > >>> hardly any content of a data model I can think of which is=20 > >>> generally >=20 > >>> suitable for insecure transports. >=20 > >>>=20 >=20 > >>> Can we please kill this idea of _standardizing_ information that=20 > >>> is >=20 > >>> suitable to send over non-secure transports? I really do not see=20 > >>> how >=20 > >>> the IETF can make a claim that a given piece of information is=20 > >>> never >=20 > >>> worth protecting (=3D suitable for non-secure transports). >=20 > >>>=20 >=20 > >>> Note that I am fine if in a certain trusted tightly-coupled >=20 > >>> deployment information is shipped in whatever way but this is then = > >>> a >=20 > >>> property of the _deployment_ and not a property of the = _information_. >=20 > >>>=20 >=20 > >>> /js >=20 > >>>=20 >=20 > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >=20 > >>>> Kathleen:=20 >=20 > >>>>=20 >=20 > >>>> I have written a draft suggesting a template for the I2RS YANG >=20 > >>>> modules >=20 > >>> which are designed to exist in the I2RS Ephemeral Control Plane=20 > >>> data store >=20 > >>> (configuration and operational state). =20 >=20 > >>>>=20 >=20 > >>>> Draft location:=20 >=20 > >>>> =20 > >>>> >>>> der>=20 > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid > >>>> er >=20 > >>>> / >=20 > >>>>=20 >=20 > >>>> I would appreciate an email discussion with the security ADs, >=20 > >>>> OPS/NM ADs, >=20 > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data=20 > >>> model >=20 > >>> (L3) and the base I2RS topology model should both provide updated >=20 > >>> YANG Security Considerations sections. I would appreciate if=20 > >>> Benoit >=20 > >>> or you hold a discuss until we sort out these issues. >=20 > >>>>=20 >=20 > >>>> Thank you, >=20 > >>>>=20 >=20 > >>>> Sue >=20 > >>>>=20 >=20 > >>>> -----Original Message----- >=20 > >>>> From: Kathleen Moriarty [=20 > >>>> =20 > >>>> mailto:Kathleen.Moriarty.ietf@gmail.com] >=20 > >>>> Sent: Wednesday, January 18, 2017 9:44 PM >=20 > >>>> To: The IESG >=20 > >>>> Cc: =20 > >>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > >>>> shares@ndzh.com; >=20 > >>>> i2rs-chairs@ietf.org; =20 > >>>> shares@ndzh.com; = > >>>> i2rs@ietf.org >=20 > >>>> Subject: Kathleen Moriarty's No Objection on >=20 > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > >>>>=20 >=20 > >>>> Kathleen Moriarty has entered the following ballot position for >=20 > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >=20 > >>>>=20 >=20 > >>>> When responding, please keep the subject line intact and reply to >=20 > >>>> all email addresses included in the To and CC lines. (Feel free=20 > >>>> to >=20 > >>>> cut this introductory paragraph, however.) >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> Please refer to >=20 > >>>> =20 > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >=20 > >>>> for more information about IESG DISCUSS and COMMENT positions. >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> The document, along with other ballot positions, can be found = here: >=20 > >>>> =20 > >>>> >>>> y/>=20 > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology > >>>> / >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> ----------------------------------------------------------------- > >>>> -- >=20 > >>>> - >=20 > >>>> -- >=20 > >>>> COMMENT: >=20 > >>>> ----------------------------------------------------------------- > >>>> -- >=20 > >>>> - >=20 > >>>> -- >=20 > >>>>=20 >=20 > >>>> I agree with Alissa's comment that the YANG module security >=20 > >>>> consideration >=20 > >>> section guidelines need to be followed and this shouldn't go=20 > >>> forward >=20 > >>> until that is corrected. I'm told it will be, thanks. >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> _______________________________________________ >=20 > >>>> i2rs mailing list >=20 > >>>> i2rs@ietf.org >=20 > >>>> =20 > >>>> https://www.ietf.org/mailman/listinfo/i2rs >=20 > >>>=20 >=20 > >>> -- >=20 > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >=20 > >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > >>>=20 >=20 > >>=20 >=20 > >> -- >=20 > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >=20 > >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > >>=20 >=20 > >=20 >=20 > > -- >=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >=20 > > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > >=20 >=20 > > _______________________________________________ >=20 > > i2rs mailing list >=20 > > i2rs@ietf.org >=20 > > =20 > > https://www.ietf.org/mailman/listinfo/i2rs >=20 > =20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 11:15:23 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 62F831297A8; Mon, 23 Jan 2017 11:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d44Ilttc0alp; Mon, 23 Jan 2017 11:15:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6FE129496; Mon, 23 Jan 2017 11:15:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE69D6FA; Mon, 23 Jan 2017 20:15:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pPF2ed340rjm; Mon, 23 Jan 2017 20:15:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 20:15:13 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5BCA200A8; Mon, 23 Jan 2017 20:15:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rpKymbry6jN3; Mon, 23 Jan 2017 20:15:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF710200A7; Mon, 23 Jan 2017 20:15:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9FE293E47AF8; Mon, 23 Jan 2017 20:15:14 +0100 (CET) Date: Mon, 23 Jan 2017 20:15:14 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123191514.GB33573@elstar.local> Mail-Followup-To: Susan Hares , 'Giles Heron' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org References: <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <20170123183401.GB33438@elstar.local> <00dd01d275ab$97ff6400$c7fe2c00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <00dd01d275ab$97ff6400$c7fe2c00$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:15:21 -0000 I suggest to use the YANG security guidelines. Or, as Martin said, there needs to be a clear statement that these YANG models only apply to I2RS agents and nothing else. In any case, I think you can't post an individual I-D and simply declare it guidelines others are expected to follow. /js On Mon, Jan 23, 2017 at 02:04:58PM -0500, Susan Hares wrote: > Juergen:=20 >=20 > There are two I2RS drafts related to security: draft-ietf-i2rs-protocol-= security-requirements and draft-ietf-i2rs-security-environment-reqs-02. Th= e draft-ietf-i2rs-protocol-security-requirements has pass IESG review and i= s waiting for the RFC editor. The draft-i2rs-security-environment-reqs-02.t= xt has not passed WG LC. You are correct that draft-hares-i2rs-yang-sec-co= nsider-00.txt is an individual draft. This individual draft is also based = on draft-ietf-netmod-ietf-revised-datastores-00.txt. =20 >=20 > The impetus for this individual draft (draft-hares-i2rs-yang-sec-consider= ) was the DISCUSS by the security ADs regarding security consideration sect= ion in two drafts: draft-ietf-i2rs-yang-network-topology and draft-ietf-i2r= s-yang-l3-topology-08.txt. The draft indicates the following 6 areas wher= e the I2RS protocol and environment security requirements differ: 1) manda= tory-to-implement transport layer, 2) priority and secondary opaque identif= ier, 3) different data store, 4) different validations in I2RS control pla= ne data store, 5) different NACM policy, and 6) optional insecure protocol.= None of these are handled in the current YANG security considerations te= mplate. Items 1, 2, and 5 are specified in draft-ietf-protocol-security-= requirements plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the draft-i2rs-secur= ity-environment-reqs-02.txt. Item 5 arises out of SEC-ENV-REQ-05 and SEC-E= NV-REQ-06 in the draft-ietf-i2rs-security-environment-reqs-02.txt. Items 3= and 4 arise out of the draft-ietf-netmod-revised-datastores-00.txt. I we= lcome a discussion on whether this individual draft truly represents the co= ntent of these 3 drafts. =20 >=20 > The individual draft tries to provide the information from the draft-ietf= -i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environme= nt-reqs-02.txt in a format consistent with the current Yang Considerations = model. I welcome comments on whether this draft provides a format consist= ent with the current yang considerations model formats. The purpose behind= this draft is to establish a template for security considerations that the= netmod/netconf experts, I2RS protocol experts, and the security ADs would = accept. The urgency for this discussion is to resolve the valid points mad= e in the security AD's DISCUSS on these two YANG modules which are key to o= ther YANG modules. =20 >=20 > Cheerily,=20 > Sue Hares=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]= =20 > Sent: Monday, January 23, 2017 1:34 PM > To: Susan Hares > Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.o= rg; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-y= ang-l3-topology-08: (with COMMENT) >=20 > There are no I2RS security guidelines. We should not confuse an individua= l I-D with guidelines. >=20 > I believe the regular YANG security guidelines do the work. >=20 > /js >=20 > On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote: > > Giles: > >=20 > > =20 > >=20 > > Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang m= odules and the application of these guidelines to the I2RS Yang Topology mo= del. The guidelines for the I2RS Yang Module have three security consider= ations: a) basic yang considerations, b) I2RS ephemeral state considerati= ons, and c) insecure considerations. Since the topology model does not op= erate over an insecure transport, the only thing that I believe you are que= stioning is the "I2RS Yang Models for Secure-Only transports". Let's wa= lk through the draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topo= logy) and the draft-ietf-i2rs-yang-network-topo models (ietf-network, ietf-= network-topology). > >=20 > > =20 > >=20 > > The topology model as described in draft-ietf-i2rs-yang-network-topo-10= =2Etxt has read/write nodes at the network, link and termination point. Pl= ease see the copy of the YHL diagrams below. Therefore, the basic topology = model is read-write. The L3 model (draft-ietf-i2rs-yang-l3-topology-08.tx= t) is read write. Please see a copy of the YHL diagrams below. Therefore,= although your implementation is read-only, the approved YANG modules are r= ead-write. This must be considered in the Security considerations section.= The basic requirements for I2RS are:=20 > >=20 > > =20 > >=20 > > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, > >=20 > > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication= as a permissible implementation alternative.=20 > >=20 > > 3) write contention for two clients writing a node using I2RS priority= =20 > > (linked to I2RS User-ID) > >=20 > > =20 > >=20 > > If the ODL model does not support writes to these data models, then it = would not have to support the priority mechanism to resolve two clients wri= ting one data node. =20 > >=20 > > =20 > >=20 > > A) Basic Yang considerations > >=20 > > =20 > >=20 > > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen i= ndicate that the topology data could be considered sensitive read data. A = paragraph needs to be added to each draft indicating risks involved in prov= iding this information, and how deployments can keep this data safe. Priv= acy issues are involved if the topologies are within homes or indicate user= 's personal devices. =20 > >=20 > > =20 > >=20 > > If the I2RS mandatory transport is utilized, the data streams utilize m= utual authentication, confidentiality, data integrity, and [practical] repl= ay protection for I2RS messages" and support "mechanism that mitigate DoS a= ttacks" and "DDos prevention". This level of security is useful when prote= cting sensitive data. =20 > >=20 > > =20 > >=20 > > 2) writeable nodes with sensitive data: Since the topology nodes are w= riteable, a security considerations needs to consider how these sensitive = data nodes will be protected. While ODL does not support writes to any da= ta node, the base models do. Therefore, security considerations must be wri= tten here.=20 > >=20 > > =20 > >=20 > > 3) RPCs: No new RPCs are considered, but providing information on the n= otification data may be also useful.=20 > >=20 > > =20 > >=20 > > I2RS YANG Model Security Considerations > >=20 > > =20 > >=20 > > The requirement for this section is the following information:=20 > >=20 > > =20 > >=20 > > 1) Indication of deployment requirement for mandatory-to-implement=20 > > NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), > >=20 > > 2) Discussion of RPCs specific to I2RS control plane data store, =20 > >=20 > > 3) NACM policy impacts the read-write state and augmentation of NACM by= access control for read/writing of routing protocols (RACM), system infor= mation (SACM), and between datastores (config to/from ephemeral state).=20 > >=20 > > 4) Discussion of data retrieved from routing protocols, system=20 > > information, dynamic configuration (dhcp) > >=20 > > 5) Any suggestion for operational knobs that control overlay of I2RS co= nfiguration over normal configuration and I2RS operational state over other= operational state.=20 > >=20 > > =20 > >=20 > > For the topology data models (ietf-network, ietf-network-topology), th= e paragraph could be:=20 > >=20 > > =20 > >=20 > > =E2=80=9CThe I2RS topology data models (ietf-network, ietf-network-topo= logy) require mutual authentication, confidentiality, data integrity, and [= practical] replay protection for I2RS messages. Therefore, there is a manda= tory-to-implement transport protocol of TLS (see RFC7589), or an optional t= ransport support of RESTCONF (draft-ietf-netconf-restconf). This data m= odel does not implement any additional RPCs specific to this data model or = any notifications. =20 > >=20 > > =20 > >=20 > > NACM policies may restrict exterior access to this YANG model to simply= read-only. For those NACM policies allowing write-access, there is a risk= that a write to a topology may create a looping topology or overload a par= ticular node. NACM policies may be augment by routing protocol access cont= rol methods (RACM), system data access control methods (SACM), and inter-da= ta store access control mechanisms (DACM). The engagement of this policy s= hould also be control by user policy switches (on/of). =20 > >=20 > > =20 > >=20 > > For the topology mode, the access to information on interfaces may be c= ontrol by SACM related to the interface model. Any I2RS topology model ter= mination point configuration which takes augments must take care not to cau= se fluctuation in the interface state. Dynamic configuration protocols su= ch as DHCP or DHCPv6 may also alter the IP Addresses associated with an int= erface. DACM related to the inter-datastore policy on the precedence betwe= en configuration of interface IP addresses, DHCP/DHCPv6 configuration, or T= opology configuration will need to make sure the interface IP address does = not cause fluctuations in the system. Deployments may provide general conf= iguration knobs that set the default state for NACM, RACM, SACM and DACM fo= r the topology database. =E2=80=9C > >=20 > > =20 > >=20 > > For the L3 topology data models (ietf-l3-unicast-topology), the paragr= aph could be:=20 > >=20 > > =20 > >=20 > > =E2=80=9CThe I2RS L3 Unicast topology data model (ietf-l3-unicast-topol= ogy) require mutual authentication, confidentiality, data integrity, and [p= ractical] replay protection for I2RS messages. Therefore, there is a mandat= ory-to-implement transport protocol of NETCONF over TLS with X.509v3 mutual= authentication (RFC7589), or an optional transport support of RESTCONF (dr= aft-ietf-netconf-restconf). This data model does not implement any addi= tional RPCs specific to this data model. This data model does support the = following new notifications: l3-node-event, l3-link-event, l3-prefix-event,= and termination-point-event. These events provide the information about = the changing L3 topology which may provide information regarding key nodes.= Since these events are only transported over secure transports that suppo= rt mutual authentication, confidentiality, data integrity, and [practice] r= eplay protection, the use of this information for DoS of an I2RS agent (aka= NETCONF server) requires the mutual authenticated client to be suborned. = =20 > >=20 > > =20 > >=20 > > NACM policies may restrict exterior access to this YANG model to simply= read-only. For those NACM policies allowing write-access, there is a risk= that a write to a topology may create a looping topology or overload a par= ticular node. NACM policies may be augment by routing protocol access cont= rol methods (RACM), system data access control methods (SACM), and inter-da= ta store access control mechanisms (DACM). The engagement of this policy s= hould also be control by user policy switches (on/of). =20 > >=20 > > =20 > >=20 > > For the L3 topology mode, the access to information on interfaces may b= e control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not to = cause fluctuation in the interface state. Dynamic configuration protocols= such as DHCP or DHCPv6 may also alter the IP Addresses associated with an = interface. DACM related to the inter-datastore policy on the precedence be= tween configuration of interface IP addresses, DHCP/DHCPv6 configuration, o= r Topology configuration will need to make sure the interface IP address do= es not cause fluctuations in the system. The L3 Topology model may also r= ead information from the routing protocols (ospf, isis or others), or write= data to the routing protocol. RACM policy should be carefully set so that= the routing protocols do not form a place to launch a DoS attack. Deploym= ents may provide general configuration knobs that set the default state for= NACM, RACM, SACM and DACM for the topology database. =E2=80=9C > >=20 > > =20 > >=20 > > =20 > >=20 > > Hopefully, this makes the suggestion for I2RS security policy a bit mor= e concrete. =20 > >=20 > > =20 > >=20 > > Sue Hares > >=20 > > =20 > >=20 > > =20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > =20 > >=20 > > High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt > >=20 > > =20 > >=20 > > +--rw networks > >=20 > > +--rw network* [network-id] > >=20 > > +--rw network-types > >=20 > > +--rw network-id network-id > >=20 > > +--ro server-provided? boolean > >=20 > > +--rw supporting-network* [network-ref] > >=20 > > | +--rw network-ref -> /networks/network/network-id > >=20 > > +--rw node* [node-id] > >=20 > > +--rw node-id node-id > >=20 > > +--rw supporting-node* [network-ref node-ref] > >=20 > > +--rw network-ref -> ../../../supporting-network/ + > >=20 > > | network-ref > >=20 > > +--rw node-ref -> /networks/network/node/node-id > >=20 > > =20 > >=20 > > module: ietf-network-topology > >=20 > > augment /nd:networks/nd:network: > >=20 > > +--rw link* [link-id] > >=20 > > +--rw source > >=20 > > | +--rw source-node? -> ../../../nd:node/node-id > >=20 > > | +--rw source-tp? -> ../../../nd:node[nd:node-id=3Dcurrent(= )/+ > >=20 > > | ../source-node]/termination-point/tp-id > >=20 > > +--rw destination > >=20 > > | +--rw dest-node? -> ../../../nd:node/node-id > >=20 > > | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ > >=20 > > | ../dest-node]/termination-point/tp-id > >=20 > > +--rw link-id link-id > >=20 > > +--rw supporting-link* [network-ref link-ref] > >=20 > > +--rw network-ref -> ../../../nd:supporting-network/+ > >=20 > > | network-ref > >=20 > > +--rw link-ref -> /nd:networks/network+ > >=20 > > =20 > > [nd:network-id=3Dcurrent()/../network-ref]/+ > >=20 > > link/link-id > >=20 > > =20 > >=20 > > augment /nd:networks/nd:network/nd:node: > >=20 > > +--rw termination-point* [tp-id] > >=20 > > +--rw tp-id tp-id > >=20 > > +--rw supporting-termination-point* [network-ref node-ref=20 > > tp-ref] > >=20 > > +--rw network-ref -> ../../../nd:supporting-node/network-ref > >=20 > > +--rw node-ref -> ../../../nd:supporting-node/node-ref > >=20 > > +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ > >=20 > > current()/../network-ref]/node+ > >=20 > > [nd:node-id=3Dcurrent()/../node-ref]/+ > >=20 > > termination-point/tp-id > >=20 > > =20 > >=20 > > =20 > >=20 > > module: ietf-l3-unicast-topology > >=20 > > augment /nd:networks/nd:network/nd:network-types: > >=20 > > +--rw l3-unicast-topology! > >=20 > > augment /nd:networks/nd:network: > >=20 > > +--rw l3-topology-attributes > >=20 > > +--rw name? string > >=20 > > +--rw flag* l3-flag-type > >=20 > > augment /nd:networks/nd:network/nd:node: > >=20 > > +--rw l3-node-attributes > >=20 > > +--rw name? inet:domain-name > >=20 > > +--rw flag* node-flag-type > >=20 > > +--rw router-id* inet:ip-address > >=20 > > +--rw prefix* [prefix] > >=20 > > +--rw prefix inet:ip-prefix > >=20 > > +--rw metric? uint32 > >=20 > > +--rw flag* prefix-flag-type > >=20 > > augment /nd:networks/nd:network/lnk:link: > >=20 > > +--rw l3-link-attributes > >=20 > > +--rw name? string > >=20 > > +--rw flag* link-flag-type > >=20 > > +--rw metric? uint32 > >=20 > > augment /nd:networks/nd:network/nd:node/lnk:termination-point: > >=20 > > +--rw l3-termination-point-attributes > >=20 > > +--rw (termination-point-type)? > >=20 > > +--:(ip) > >=20 > > | +--rw ip-address* inet:ip-address > >=20 > > +--:(unnumbered) > >=20 > > | +--rw unnumbered-id? uint32 > >=20 > > +--:(interface-name) > >=20 > > +--ro interface-name? string > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Giles Heron [mailto:giles.heron@gmail.com] > > Sent: Monday, January 23, 2017 6:45 AM > > To: Juergen Schoenwaelder > > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org;=20 > > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > =20 > >=20 > > ODL does, indeed, implement the topology models, but generally the data= in the topology model is operational data, so I=E2=80=99m not sure how tha= t fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data sto= re=E2=80=9D - since users don=E2=80=99t write to the models directly (makin= g validation, priority etc. non-issues). > >=20 > > =20 > >=20 > > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder wrote: > >=20 > > >=20 > >=20 > > > I thought the topology models are coming more or less from > >=20 > > > OpenDaylight. If so, is ODL and I2RS implementation? > >=20 > > >=20 > >=20 > > > /js > >=20 > > >=20 > >=20 > > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: > >=20 > > >> Juergen:=20 > >=20 > > >>=20 > >=20 > > >> Let's focus on your second point. The topology drafts are I2RS=20 > > >> drafts > >=20 > > >> designed for the I2RS ephemeral control plane data store. How can = these be > >=20 > > >> generic YANG modules when the following is true:=20 > >=20 > > >>=20 > >=20 > > >> 1) I2RS Data models do not utilize the configuration data store, > >=20 > > >> 2) I2RS Data Models do not require the same validation as > >=20 > > >> configuration data store, > >=20 > > >> 3) I2RS Data models require the use of priority to handle the > >=20 > > >> multi-write contention problem into the I2RS Control Plane data > >=20 > > >> store, > >=20 > > >> 4) I2RS require TLS with X.509v3 over TCP for the > >=20 > > >> mandatory-to-implement transport, > >=20 > > >>=20 > >=20 > > >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, > >=20 > > >> the discussion should be taken up with netmod WG list. > >=20 > > >> Do you disagree with i2rs-protocol-security-requirements? That=20 > > >> issue > >=20 > > >> is closed based on IESG approval. > >=20 > > >>=20 > >=20 > > >> Sue Hares > >=20 > > >>=20 > >=20 > > >> -----Original Message----- > >=20 > > >> From: Juergen Schoenwaelder > >=20 > > >> [ =20 > > >> mailto:j.schoenwaelder@jacobs-university.de] > >=20 > > >> Sent: Monday, January 23, 2017 3:39 AM > >=20 > > >> To: Susan Hares > >=20 > > >> Cc: 'Kathleen Moriarty'; 'The IESG'; > >=20 > > >> =20 > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; = =20 > > >> i2rs@ietf.org; > >=20 > > >> i2rs-chairs@ietf.org > >=20 > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >=20 > > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>=20 > >=20 > > >> Susan, > >=20 > > >>=20 > >=20 > > >> I consider tagging a YANG object statically and universally in the > >=20 > > >> data model as "does not need secure communication" fundamentally > >=20 > > >> flawed; I am not having an issue with insecure communication in cert= ain deployment contexts. > >=20 > > >>=20 > >=20 > > >> The topology drafts are regular generic YANG models that just=20 > > >> happen > >=20 > > >> to be done in I2RS - I believe that using the generic YANG security > >=20 > > >> guidelines we have is good enough to progress these drafts. > >=20 > > >>=20 > >=20 > > >> /js > >=20 > > >>=20 > >=20 > > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > >=20 > > >>> Juergen:=20 > >=20 > > >>>=20 > >=20 > > >>> I recognize that dislike insecure communication. You made a=20 > > >>> similar > >=20 > > >>> comment during the WG LC and IETF review of > >=20 > > >>> draft-ietf-i2rs-protocol-security-requirements. However, the > >=20 > > >>> draft-ietf-i2rs-protocol-security-requirements were passed by the > >=20 > > >>> I2RS WG and approved by the IESG for RFC publication and it=20 > > >>> contains > >=20 > > >>> the non-secure communication. The mandate from the I2RS WG for=20 > > >>> this > >=20 > > >>> shepherd/co-chair is clear. > >=20 > > >>>=20 > >=20 > > >>> As the shepherd for the topology drafts, I try to write-up=20 > > >>> something > >=20 > > >>> that might address Kathleen's Moriarty's concerns about the=20 > > >>> topology > >=20 > > >>> draft's security issues about privacy and the I2RS ephemeral=20 > > >>> control > >=20 > > >>> plane > >=20 > > >> data > >=20 > > >>> store. I welcome an open discussion on my ideas > >=20 > > >>> ( https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > >=20 > > >> The > >=20 > > >>> yang doctor's YANG security consideration template > >=20 > > >>> ( =20 > > >>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > >=20 > > >>> the privacy related RFCs (RFC6973) note that some information is se= nsitive. > >=20 > > >>> Hopefully, this document extends these guidelines to a new data sto= re.=20 > >=20 > > >>>=20 > >=20 > > >>> Cheerily, > >=20 > > >>> Sue Hares > >=20 > > >>>=20 > >=20 > > >>> -----Original Message----- > >=20 > > >>> From: Juergen Schoenwaelder > >=20 > > >>> [ =20 > > >>> mailto:j.schoenwaelder@jacobs-university.de] > >=20 > > >>> Sent: Thursday, January 19, 2017 10:34 AM > >=20 > > >>> To: Susan Hares > >=20 > > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; > >=20 > > >>> =20 > > >>> draft-ietf-i2rs-yang-l3-topology@ietf.org; = =20 > > >>> i2rs@ietf.org; > >=20 > > >>> i2rs-chairs@ietf.org > >=20 > > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >=20 > > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>>=20 > >=20 > > >>> For what it is worth, I find the notion that data models may be > >=20 > > >>> written for a specific non-secure transport plain broken. There is > >=20 > > >>> hardly any content of a data model I can think of which is=20 > > >>> generally > >=20 > > >>> suitable for insecure transports. > >=20 > > >>>=20 > >=20 > > >>> Can we please kill this idea of _standardizing_ information that=20 > > >>> is > >=20 > > >>> suitable to send over non-secure transports? I really do not see=20 > > >>> how > >=20 > > >>> the IETF can make a claim that a given piece of information is=20 > > >>> never > >=20 > > >>> worth protecting (=3D suitable for non-secure transports). > >=20 > > >>>=20 > >=20 > > >>> Note that I am fine if in a certain trusted tightly-coupled > >=20 > > >>> deployment information is shipped in whatever way but this is then= =20 > > >>> a > >=20 > > >>> property of the _deployment_ and not a property of the _information= _. > >=20 > > >>>=20 > >=20 > > >>> /js > >=20 > > >>>=20 > >=20 > > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > >=20 > > >>>> Kathleen:=20 > >=20 > > >>>>=20 > >=20 > > >>>> I have written a draft suggesting a template for the I2RS YANG > >=20 > > >>>> modules > >=20 > > >>> which are designed to exist in the I2RS Ephemeral Control Plane=20 > > >>> data store > >=20 > > >>> (configuration and operational state). =20 > >=20 > > >>>>=20 > >=20 > > >>>> Draft location:=20 > >=20 > > >>>> =20 > > >>>> > >>>> der>=20 > > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid > > >>>> er > >=20 > > >>>> / > >=20 > > >>>>=20 > >=20 > > >>>> I would appreciate an email discussion with the security ADs, > >=20 > > >>>> OPS/NM ADs, > >=20 > > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data=20 > > >>> model > >=20 > > >>> (L3) and the base I2RS topology model should both provide updated > >=20 > > >>> YANG Security Considerations sections. I would appreciate if=20 > > >>> Benoit > >=20 > > >>> or you hold a discuss until we sort out these issues. > >=20 > > >>>>=20 > >=20 > > >>>> Thank you, > >=20 > > >>>>=20 > >=20 > > >>>> Sue > >=20 > > >>>>=20 > >=20 > > >>>> -----Original Message----- > >=20 > > >>>> From: Kathleen Moriarty [=20 > > >>>> =20 > > >>>> mailto:Kathleen.Moriarty.ietf@gmail.com] > >=20 > > >>>> Sent: Wednesday, January 18, 2017 9:44 PM > >=20 > > >>>> To: The IESG > >=20 > > >>>> Cc: =20 > > >>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > > >>>> shares@ndzh.com; > >=20 > > >>>> i2rs-chairs@ietf.org; =20 > > >>>> shares@ndzh.com; = =20 > > >>>> i2rs@ietf.org > >=20 > > >>>> Subject: Kathleen Moriarty's No Objection on > >=20 > > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>>>=20 > >=20 > > >>>> Kathleen Moriarty has entered the following ballot position for > >=20 > > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection > >=20 > > >>>>=20 > >=20 > > >>>> When responding, please keep the subject line intact and reply to > >=20 > > >>>> all email addresses included in the To and CC lines. (Feel free=20 > > >>>> to > >=20 > > >>>> cut this introductory paragraph, however.) > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> Please refer to > >=20 > > >>>> =20 > > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >=20 > > >>>> for more information about IESG DISCUSS and COMMENT positions. > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> The document, along with other ballot positions, can be found here: > >=20 > > >>>> =20 > > >>>> > >>>> y/>=20 > > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology > > >>>> / > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> ----------------------------------------------------------------- > > >>>> -- > >=20 > > >>>> - > >=20 > > >>>> -- > >=20 > > >>>> COMMENT: > >=20 > > >>>> ----------------------------------------------------------------- > > >>>> -- > >=20 > > >>>> - > >=20 > > >>>> -- > >=20 > > >>>>=20 > >=20 > > >>>> I agree with Alissa's comment that the YANG module security > >=20 > > >>>> consideration > >=20 > > >>> section guidelines need to be followed and this shouldn't go=20 > > >>> forward > >=20 > > >>> until that is corrected. I'm told it will be, thanks. > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> _______________________________________________ > >=20 > > >>>> i2rs mailing list > >=20 > > >>>> i2rs@ietf.org > >=20 > > >>>> =20 > > >>>> https://www.ietf.org/mailman/listinfo/i2rs > >=20 > > >>>=20 > >=20 > > >>> -- > >=20 > > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > >=20 > > >>> Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > >=20 > > >>>=20 > >=20 > > >>=20 > >=20 > > >> -- > >=20 > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >=20 > > >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> > >=20 > > >>=20 > >=20 > > >=20 > >=20 > > > -- > >=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >=20 > > > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> > >=20 > > >=20 > >=20 > > > _______________________________________________ > >=20 > > > i2rs mailing list > >=20 > > > i2rs@ietf.org > >=20 > > > =20 > > > https://www.ietf.org/mailman/listinfo/i2rs > >=20 > > =20 > >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 11:17:37 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 394D81297C2; Mon, 23 Jan 2017 11:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 RMbg_hqmEo6R; Mon, 23 Jan 2017 11:17:27 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0BD129496; Mon, 23 Jan 2017 11:17:27 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Thomas Nadeau'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> <007901d27599$649e0790$2dda16b0$@ndzh.com> <55EFDB1C-ED03-4D24-AFF9-28033DF03A7F@lucidvision.com> In-Reply-To: <55EFDB1C-ED03-4D24-AFF9-28033DF03A7F@lucidvision.com> Date: Mon, 23 Jan 2017 14:12:42 -0500 Message-ID: <00df01d275ac$ac634fa0$0529eee0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01D27582.C399A3B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+AvYiyDYB8tFV9gI6fU8pAp4O91MClGFhQAKvxSLBAWbKdKugLR96IA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Juergen Schoenwaelder' , 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 19:17:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E0_01D27582.C399A3B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tom:=20 =20 Just to makes sure I understand your comment. My context was = =E2=80=9Csecurity considerations=E2=80=9D for I2RS Topology model. = Your comment is on the sentences =E2=80=9C=E2=80=9CIdeally this = pre-configuration would be stored in a key store or something that is = secure.=E2=80=9D Perhaps my rephrase would be =E2=80=9CFor ideal = security, the pre-configuration of the =E2=80=9Cpriority match to User = ID=E2=80=9D would be contained in a data repository that is = secure=E2=80=9D. =20 =20 Is that better?=20 =20 Sue=20 =20 =20 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Monday, January 23, 2017 1:12 PM To: Susan Hares Cc: Giles Heron; i2rs@ietf.org; = draft-ietf-i2rs-yang-l3-topology@ietf.org; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 =20 On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares = wrote: =20 Giles:=20 =20 I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals. It is a protocol independent model with information on = topology. This was in the original use cases and has been a focus for = I2RS WG. See rest of the responses below.=20 =20 The real change for RFC compliance for ODL=E2=80=99s read-only Topology = model would be: a) use of NETCONF over TLS with X.509v3 authentication, = b) denoting the =E2=80=9Cdynamic control plane data store=E2=80=9D in = the get applied (whenever that gets implemented), and support of the = opaque secondary identity in tracing (if you support tracing). The = change for the RFC compliance for the ODL=E2=80=99s read-write would be = the utilizing priority to resolve contention if multiple clients try to = write the topology database. The priority could be set per user = identifier (passed in X.509v3) in a pre-configuration set-up stored. = Ideally this pre-configuration would be stored in a key store or = something that is secure. =20 Sue=20 =20 Sue,=20 =20 I am still totally confused as to why any of what that last = sentence says has to do with the topology model other than it is as you = say, protocol independent. That was the original goal. Why we are complicating things with transport or data store things is = not making sense to me at all. =20 =E2=80=94Tom =20 =20 =20 Fr om: Giles Heron [ = mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 11:26 AM To: Susan Hares Cc: Juergen Schoenwaelder; = = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi Sue, =20 On 23 Jan 2017, at 14:40, Susan Hares < = shares@ndzh.com> wrote: =20 Giles: =20 Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang = modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). =20 i wasn=E2=80=99t the implementer of those models in ODL. But = I=E2=80=99ve used them a fair bit. =20 at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network elements) . =20 [Sue]: No, the topology model was part of the original I2RS YANG = modules, and the Topology models (L2, L3, Base) fit its ue.=20 =20 The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 =20 Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). =20 [Sue]: This fits the I2RS Yang module.=20 =20 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20 =20 Giles: most NETCONF implementations I=E2=80=99m aware of use ssh. And = this is mandatory only per an individual ID, right? Or is it in a WG = draft now? And do we have WG consensus that this applies to read-only = data as well as to read-write? =20 Sue: NETCONF over TLS with X.509v3 is an RFC 7589. I2RS is requiring = this to get mutual authentication, confidentiality, data integrity, = [practical] reply protection for I2RS messages, and support DoS = mitigation. This mandatory-to-implement status is a change from the = basic NETCONF over SSH.=20 =20 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication = as a permissible implementation alternative.=20 =20 Giles: again isn=E2=80=99t that only specified as mandatory in an = individual ID? Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. Therefore, the RESTCONF protocol is an alternative = since it supports this with its basic work.=20 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 =20 Giles: so that one isn=E2=80=99t an issue for read-only = implementations=E2=80=A6 Sue: Yes. You are correct.=20 =20 Sue: If the ODL model does not support writes to these data models, then = it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 Giles: indeed. Sue: No other responses are below=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A) Basic Yang considerations=20 =20 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 =20 If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 =20 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 =20 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 =20 I2RS YANG Model Security Considerations =20 The requirement for this section is the following information:=20 =20 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 2) Discussion of RPCs specific to I2RS control plane data store, =20 3) NACM policy impacts the read-write state and augmentation of NACM by = access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 =20 For the topology data models (ietf-network, ietf-network-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C =20 For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. The L3 Topology model may also read information from = the routing protocols (ospf, isis or others), or write data to the = routing protocol. RACM policy should be carefully set so that the = routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C =20 =20 Hopefully, this makes the suggestion for I2RS security policy a bit more = concrete.=20 Sue Hares=20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20 =20 +--rw networks +--rw network* [network-id] +--rw network-types +--rw network-id network-id +--ro server-provided? boolean +--rw supporting-network* [network-ref] | +--rw network-ref -> /networks/network/network-id +--rw node* [node-id] +--rw node-id node-id +--rw supporting-node* [network-ref node-ref] +--rw network-ref -> ../../../supporting-network/ + | network-ref +--rw node-ref -> /networks/network/node/node-id =20 module: ietf-network-topology augment /nd:networks/nd:network: +--rw link* [link-id] +--rw source | +--rw source-node? -> ../../../nd:node/node-id | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../source-node]/termination-point/tp-id +--rw destination | +--rw dest-node? -> ../../../nd:node/node-id | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../dest-node]/termination-point/tp-id +--rw link-id link-id +--rw supporting-link* [network-ref link-ref] +--rw network-ref -> ../../../nd:supporting-network/+ | network-ref +--rw link-ref -> /nd:networks/network+ = [nd:network-id=3Dcurrent()/../network-ref]/+ link/link-id =20 augment /nd:networks/nd:network/nd:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ current()/../network-ref]/node+ [nd:node-id=3Dcurrent()/../node-ref]/+ termination-point/tp-id =20 =20 module: ietf-l3-unicast-topology augment /nd:networks/nd:network/nd:network-types: +--rw l3-unicast-topology! augment /nd:networks/nd:network: +--rw l3-topology-attributes +--rw name? string +--rw flag* l3-flag-type augment /nd:networks/nd:network/nd:node: +--rw l3-node-attributes +--rw name? inet:domain-name +--rw flag* node-flag-type +--rw router-id* inet:ip-address +--rw prefix* [prefix] +--rw prefix inet:ip-prefix +--rw metric? uint32 +--rw flag* prefix-flag-type augment /nd:networks/nd:network/lnk:link: +--rw l3-link-attributes +--rw name? string +--rw flag* link-flag-type +--rw metric? uint32 augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) | +--rw unnumbered-id? uint32 +--:(interface-name) +--ro interface-name? string =20 =20 =20 =20 =20 -----Original Message----- From: Giles Heron [ = mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 6:45 AM To: Juergen Schoenwaelder Cc: Susan Hares; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 ODL does, indeed, implement the topology models, but generally the data = in the topology model is operational data, so I=E2=80=99m not sure how = that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making validation, priority etc. non-issues). =20 > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder < = = j.schoenwaelder@jacobs-university.de> wrote: >=20 > I thought the topology models are coming more or less from=20 > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > /js >=20 > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> Juergen:=20 >>=20 >> Let's focus on your second point. The topology drafts are I2RS = drafts >> designed for the I2RS ephemeral control plane data store. How can = these be >> generic YANG modules when the following is true:=20 >>=20 >> 1) I2RS Data models do not utilize the configuration data store, >> 2) I2RS Data Models do not require the same validation as=20 >> configuration data store, >> 3) I2RS Data models require the use of priority to handle the=20 >> multi-write contention problem into the I2RS Control Plane data=20 >> store, >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> mandatory-to-implement transport, >>=20 >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20 >> the discussion should be taken up with netmod WG list. >> Do you disagree with i2rs-protocol-security-requirements? That issue = >> is closed based on IESG approval. >>=20 >> Sue Hares >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [ = mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, January 23, 2017 3:39 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> Susan, >>=20 >> I consider tagging a YANG object statically and universally in the=20 >> data model as "does not need secure communication" fundamentally=20 >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >>=20 >> The topology drafts are regular generic YANG models that just happen=20 >> to be done in I2RS - I believe that using the generic YANG security=20 >> guidelines we have is good enough to progress these drafts. >>=20 >> /js >>=20 >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> I recognize that dislike insecure communication. You made a similar = >>> comment during the WG LC and IETF review of=20 >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20 >>> I2RS WG and approved by the IESG for RFC publication and it contains = >>> the non-secure communication. The mandate from the I2RS WG for this = >>> shepherd/co-chair is clear. >>>=20 >>> As the shepherd for the topology drafts, I try to write-up something = >>> that might address Kathleen's Moriarty's concerns about the topology = >>> draft's security issues about privacy and the I2RS ephemeral control = >>> plane >> data >>> store. I welcome an open discussion on my ideas >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >> The >>> yang doctor's YANG security consideration template >>> ( = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and=20 >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >>> Hopefully, this document extends these guidelines to a new data = store.=20 >>>=20 >>> Cheerily, >>> Sue Hares >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [ = mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, January 19, 2017 10:34 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >>> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> For what it is worth, I find the notion that data models may be=20 >>> written for a specific non-secure transport plain broken. There is=20 >>> hardly any content of a data model I can think of which is generally = >>> suitable for insecure transports. >>>=20 >>> Can we please kill this idea of _standardizing_ information that is=20 >>> suitable to send over non-secure transports? I really do not see how = >>> the IETF can make a claim that a given piece of information is never = >>> worth protecting (=3D suitable for non-secure transports). >>>=20 >>> Note that I am fine if in a certain trusted tightly-coupled=20 >>> deployment information is shipped in whatever way but this is then a = >>> property of the _deployment_ and not a property of the = _information_. >>>=20 >>> /js >>>=20 >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>> Kathleen:=20 >>>>=20 >>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>> modules >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >>> (configuration and operational state). =20 >>>>=20 >>>> Draft location:=20 >>>> = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider >>>> / >>>>=20 >>>> I would appreciate an email discussion with the security ADs,=20 >>>> OPS/NM ADs, >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model >>> (L3) and the base I2RS topology model should both provide updated=20 >>> YANG Security Considerations sections. I would appreciate if Benoit=20 >>> or you hold a discuss until we sort out these issues. >>>>=20 >>>> Thank you, >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [ = mailto:Kathleen.Moriarty.ietf@gmail.com] >>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>> To: The IESG >>>> Cc: = draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com;=20 >>>> i2rs-chairs@ietf.org; = shares@ndzh.com; = i2rs@ietf.org >>>> Subject: Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to=20 >>>> all email addresses included in the To and CC lines. (Feel free to=20 >>>> cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>>=20 >>>> I agree with Alissa's comment that the YANG module security=20 >>>> consideration >>> section guidelines need to be followed and this shouldn't go forward = >>> until that is corrected. I'm told it will be, thanks. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> = https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs =20 _______________________________________________ i2rs mailing list i2rs@ietf.org = https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_00E0_01D27582.C399A3B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Tom:

 

Just to makes sure I understand your comment.=C2=A0 My context was = =E2=80=9Csecurity considerations=E2=80=9D for I2RS Topology model. = =C2=A0=C2=A0Your comment is on the sentences = =E2=80=9C=E2=80=9CIdeally this pre-configuration would be stored in a key store or = something that is secure.=E2=80=9D=C2=A0=C2=A0 Perhaps my rephrase would be =E2=80=9CFor ideal = security, the pre-configuration of the =E2=80=9Cpriority match to User = ID=E2=80=9D would be contained in a data repository that is = secure=E2=80=9D.=C2=A0

 

Is that better?

 

Sue

=C2=A0

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Monday, = January 23, 2017 1:12 PM
To: Susan Hares
Cc: Giles = Heron; i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; Juergen = Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; The = IESG
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

 

On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares = <shares@ndzh.com> = wrote:

 

Giles: 

 

I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals.  It is a protocol independent model with = information on topology.   This was in the original use cases = and has been a focus for I2RS WG.   See rest of the responses = below. 

 

The real change for RFC compliance for ODL=E2=80=99s read-only = Topology model would be:  a) use of NETCONF over TLS with X.509v3 = authentication, b) denoting the =E2=80=9Cdynamic control plane data = store=E2=80=9D in the get applied (whenever that gets implemented), and = support of the opaque secondary identity in tracing (if you support = tracing).  The change for the RFC compliance for the ODL=E2=80=99s = read-write would be the utilizing priority to resolve contention if = multiple clients try to write the topology database.  The priority = could be set per user identifier (passed in X.509v3) in a = pre-configuration set-up stored.   Ideally this = pre-configuration would be stored in a key store or something that is = secure.

 

Sue 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Sue, 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 I am still totally confused as to why any of what = that last sentence says has to do with the topology model other than it = is as you say, protocol independent.  That was the original = goal.

Why we are = complicating things with transport or data store things is not making = sense to me at all.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =E2=80=94Tom

 



 

 

Fr  = om: Giles Heron = [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, 2017 = 11:26 AM
To: Susan = Hares
Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject:=  Re: [i2rs] Kathleen = Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

Hi Sue,

 

On 23 Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> = wrote:

 

Giles:

 

Thank you = for your comments on ODL and your implementation within ODL.  =  There are two different issues in discussion:  guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.   The guidelines for the I2RS Yang Module = have three security considerations: a)  basic yang = considerations,  b) I2RS ephemeral state considerations, and c) = insecure considerations.   Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

 

i wasn=E2=80=99t the implementer of those models in = ODL.   But I=E2=80=99ve used them a fair = bit.

 

at any rate applying the I2RS security guidelines to = the I2RS YANG topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network = elements) .

 

[Sue]:  No, the topology model was part of the original I2RS = YANG modules, and the Topology models (L2, L3, Base) fit its ue. 

 

The = topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt = has read/write nodes at the network, link and termination point.  = Please see the copy of the YHL diagrams below. Therefore, the basic = topology model is read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 

 

Sure - the models are read/write but ODL=E2=80=99s = implementation is generally read-only (as I understand it, it=E2=80=99s = down to each individual protocol or application that leverages the = models to decide whether to use them in read-write or read-only = mode).   

[Sue]: This fits the I2RS Yang module. 

 

1) NETCONF = over TLS with X.509v3 as mandatory to implement protocol, 

 

Giles:  most = NETCONF implementations I=E2=80=99m aware of use ssh. And this is mandatory only = per an individual ID, right?   Or is it in a WG draft now? =  And do we have WG consensus that this applies to read-only data as = well as to read-write?

 

Sue:  NETCONF over TLS with X.509v3 is an RFC 7589.  I2RS = is requiring this to get mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation.  This mandatory-to-implement status is a change = from the basic NETCONF over SSH. 

 

2) = RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as = a permissible implementation alternative. 

 

Giles: again isn=E2=80=99t = that only specified as mandatory in an individual = ID?

Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation.   Therefore, the RESTCONF protocol is an = alternative since it supports this with its basic work. 


3) write = contention for two clients writing a node using I2RS priority (linked to = I2RS User-ID) 

 

Giles: so that one = isn=E2=80=99t an issue for read-only = implementations=E2=80=A6

Sue: Yes.  You are correct. 

 

Sue: If the ODL = model does not support writes to these data models, then it would not = have to support the priority mechanism to resolve two clients writing = one data node. =   

Giles: indeed.

<= /div>

Sue: No other responses are below 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D




A) Basic = Yang considerations 

 

1) = readable nodes with sensitive data:  Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.  A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.   Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. =   

 

If the = I2RS mandatory transport is utilized, the data streams utilize mutual = authentication, confidentiality, data integrity, and [practical] replay = protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention".  This = level of security is useful when protecting sensitive data. =  

 

2) = writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 

 

3) RPCs: = No new RPCs are considered, but providing information on the = notification data may be also useful. 

 

I2RS YANG = Model Security = Considerations

 

The = requirement for this section is the following information: 

 

1) = Indication of deployment requirement for mandatory-to-implement NETCONF = (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), 

2) = Discussion of RPCs specific to I2RS control plane data store, =   

3) NACM = policy impacts the read-write state and augmentation of NACM by access = control for read/writing of routing protocols (RACM),  system = information (SACM), and between datastores (config to/from ephemeral = state). 

4) = Discussion of data retrieved from routing protocols, system information, = dynamic configuration (dhcp) 

5) Any = suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state. 

 

For the = topology data models (ietf-network, ietf-network-topology),  the = paragraph could be: 

 

=E2=80=9CTh= e I2RS topology data models (ietf-network, ietf-network-topology) = require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of TLS (see RFC7589), or an = optional transport support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model or any = notifications.   

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 

For the = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.  Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. = =E2=80=9C

 

For the L3 = topology data models (ietf-l3-unicast-topology),  the paragraph = could be: 

 

=E2=80=9CTh= e I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of NETCONF over TLS with = X.509v3 mutual authentication (RFC7589), or an optional transport = support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model.  This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event.   These events = provide the information about the changing L3 topology which may provide = information regarding key nodes.  Since these events are only = transported over secure transports that support mutual authentication, = confidentiality, data integrity, and [practice] replay protection, the = use of this information for DoS of an I2RS agent (aka NETCONF server) = requires the mutual authenticated client to be suborned.  

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 

For the L3 = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.   The L3 Topology model may = also read information from the routing protocols (ospf, isis or others), = or write data to the routing protocol.  RACM policy should be = carefully set so that the routing protocols do not form a place to = launch a DoS attack.  Deployments may provide general configuration = knobs that set the default state for NACM, RACM, SACM and DACM for the = topology database. = =E2=80=9C

 

 

Hopefully, = this makes the suggestion for I2RS security policy a bit more = concrete. 

Sue = Hares 

 

 

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

High-level = Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt 

 

  = ;    +--rw = networks

  = ;       +--rw network* = [network-id]

  = ;          +--rw = network-types

  = ;          +--rw = network-id          &nb= sp; network-id

  = ;          +--ro = server-provided?      = boolean

  = ;          +--rw = supporting-network* = [network-ref]

  = ;          |  +--rw = network-ref    -> = /networks/network/network-id

<= p class=3DMsoNormal>  = ;          +--rw node* = [node-id]

  = ;            =  +--rw = node-id           = node-id

  = ;            = +--rw supporting-node* [network-ref = node-ref]

  = ;            =     +--rw network-ref    -> = ../../../supporting-network/ = +

  = ;            =     = |            =         = network-ref

  = ;            =     +--rw node-ref     =   -> = /networks/network/node/node-id

 

module: = ietf-network-topology

augment = /nd:networks/nd:network:

  = ; +--rw link* [link-id]

  = ;    +--rw = source

  = ;    |  +--rw source-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw source-tp?     = -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =            = ../source-node]/termination-point/tp-id

=

  = ;    +--rw = destination

  = ;    |  +--rw dest-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =          = ../dest-node]/termination-point/tp-id

  = ;    +--rw = link-id           = link-id

  = ;    +--rw supporting-link* [network-ref = link-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-network/+

  = ;       = |            =         = network-ref

  = ;       +--rw = link-ref       -> = /nd:networks/network+

  = ;            =             &= nbsp;   = [nd:network-id=3Dcurrent()/../network-ref]/+

<= /div>

  = ;            =             &= nbsp;   = link/link-id

 

augment = /nd:networks/nd:network/nd:node:

  = ; +--rw termination-point* = [tp-id]

  = ;    +--rw = tp-id           &n= bsp;           &nb= sp;   tp-id

  = ;    +--rw supporting-termination-point* [network-ref = node-ref tp-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-node/network-ref

=

  = ;       +--rw = node-ref       -> = ../../../nd:supporting-node/node-ref

  = ;       +--rw = tp-ref         -> = /nd:networks/network[nd:network-id=3D+

<= div>

  = ;            =             &= nbsp;   = current()/../network-ref]/node+

  = ;            =             &= nbsp;   = [nd:node-id=3Dcurrent()/../node-ref]/+

<= div>

  = ;            =              =    termination-point/tp-id

 

 

  = ; module: = ietf-l3-unicast-topology

  = ; augment = /nd:networks/nd:network/nd:network-types:

  = ;    +--rw = l3-unicast-topology!

  = ; augment = /nd:networks/nd:network:

  = ;    +--rw = l3-topology-attributes

  = ;       +--rw name?   = string

  = ;       +--rw flag*   = l3-flag-type

  = ; augment = /nd:networks/nd:network/nd:node:

  = ;    +--rw = l3-node-attributes

  = ;       +--rw = name?        = inet:domain-name

  = ;       +--rw = flag*        = node-flag-type

  = ;       +--rw router-id*   = inet:ip-address

  = ;       +--rw prefix* = [prefix]

  = ;          +--rw = prefix    = inet:ip-prefix

  = ;          +--rw = metric?   uint32

  = ;          +--rw = flag*     = prefix-flag-type

  = ; augment = /nd:networks/nd:network/lnk:link:

<= div>

  = ;    +--rw = l3-link-attributes

  = ;       +--rw = name?     = string

  = ;       +--rw = flag*     = link-flag-type

  = ;       +--rw metric?   = uint32

  = ; augment = /nd:networks/nd:network/nd:node/lnk:termination-point:<= /p>

  = ;    +--rw = l3-termination-point-attributes

  = ;       +--rw = (termination-point-type)?

  = ;          = +--:(ip)

  = ;          |  +--rw = ip-address*      = inet:ip-address

  = ;          = +--:(unnumbered)

  = ;          |  +--rw = unnumbered-id?   = uint32

  = ;          = +--:(interface-name)

  = ;            = +--ro interface-name?  = string

 

 

 

 

 

-----Origin= al Message-----
From: Giles Heron [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, = 2017 6:45 AM
To: Juergen Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

ODL does, = indeed, implement the topology models, but generally the data in the = topology model is operational data, so I=E2=80=99m not sure how that = fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data = store=E2=80=9D - since users don=E2=80=99t write to the models directly = (making validation, priority etc. = non-issues).

 

> On 23 = Jan 2017, at 11:29, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:

> 

> I = thought the topology models are coming more or less from 

> = OpenDaylight. If so, is ODL and I2RS = implementation?

> 

> = /js

> 

> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares = wrote:

>> = Juergen: 

>> 

>> = Let's focus on your second point.  The topology drafts are I2RS = drafts

>> = designed for the I2RS ephemeral control plane data store.   = How can these be

>> = generic YANG modules when the following is true: 

>> 

>> = 1) I2RS Data models do not utilize the configuration data = store,

>> = 2) I2RS Data Models do not require the same validation as 

>> = configuration data store,

>> = 3) I2RS Data models require the use of priority to handle the 

>> = multi-write contention problem into the I2RS Control Plane data 

>> = store,

>> = 4) I2RS require TLS with X.509v3 over TCP for the 

>> = mandatory-to-implement = transport,

>> 

>> = Do you disagree with draft-ietf-netmod-revised-datastores?  If = so,  

>> = the discussion should be taken up with netmod WG = list.

>> = Do you disagree with i2rs-protocol-security-requirements?  That = issue 

>> = is closed based on IESG = approval.

>> 

>> = Sue Hares

>> 

>> = -----Original Message-----

>> = From: Juergen Schoenwaelder 

>> = Sent: Monday, January 23, 2017 3:39 = AM

>> = To: Susan Hares

>> = Cc: 'Kathleen Moriarty'; 'The = IESG';

>> = Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>> = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>> 

>> = Susan,

>> 

>> I = consider tagging a YANG object statically and universally in the 

>> = data model as "does not need secure communication" = fundamentally 

>> = flawed; I am not having an issue with insecure communication in certain = deployment contexts.

>> 

>> = The topology drafts are regular generic YANG models that just = happen 

>> = to be done in I2RS - I believe that using the generic YANG security 

>> = guidelines we have is good enough to progress these = drafts.

>> 

>> = /js

>> 

>> = On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares = wrote:

>>>= ; Juergen: 

>>>= ; 

>>>= ; I recognize that dislike insecure communication.  You made a = similar 

>>>= ; comment during the WG LC and IETF review of 

>>>= ; draft-ietf-i2rs-protocol-security-requirements.  However, = the 

>>>= ; draft-ietf-i2rs-protocol-security-requirements were passed by the 

>>>= ; I2RS WG and approved by the IESG for RFC publication and it = contains 

>>>= ; the non-secure communication.  The mandate from the I2RS WG for = this 

>>>= ; shepherd/co-chair is = clear.

>>>= ; 

>>>= ; As the shepherd for the topology drafts, I try to write-up = something 

>>>= ; that might address Kathleen's Moriarty's concerns about the = topology 

>>>= ; draft's security issues about privacy and the I2RS ephemeral = control 

>>>= ; plane

>> = data

>>>= ; store.   I welcome an open discussion on my = ideas

>> = The

>>>= ; yang doctor's YANG  security consideration = template

>>>= ; the privacy related RFCs (RFC6973) note that some information is = sensitive.

>>>= ; Hopefully, this document extends these guidelines to a new data = store. 

>>>= ; 

>>>= ; Cheerily,

>>>= ; Sue Hares

>>>= ; 

>>>= ; -----Original = Message-----

>>>= ; From: Juergen = Schoenwaelder

>>>= ; Sent: Thursday, January 19, 2017 10:34 = AM

>>>= ; To: Susan Hares

>>>= ; Cc: 'Kathleen Moriarty'; 'The IESG'; 

>>>= ; Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>>>= ; draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ; 

>>>= ; For what it is worth, I find the notion that data models may be 

>>>= ; written for a specific non-secure transport plain broken. There = is 

>>>= ; hardly any content of a data model I can think of which is = generally 

>>>= ; suitable for insecure = transports.

>>>= ; 

>>>= ; Can we please kill this idea of _standardizing_ information that = is 

>>>= ; suitable to send over non-secure transports? I really do not see = how 

>>>= ; the IETF can make a claim that a given piece of information is = never 

>>>= ; worth protecting (=3D suitable for non-secure = transports).

>>>= ; 

>>>= ; Note that I am fine if in a certain trusted tightly-coupled 

>>>= ; deployment information is shipped in whatever way but this is then = a 

>>>= ; property of the _deployment_ and not a property of the = _information_.

>>>= ; 

>>>= ; /js

>>>= ; 

>>>= ; On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares = wrote:

>>>= ;> Kathleen: 

>>>= ;> 

>>>= ;> I have written a draft suggesting a template for the I2RS = YANG 

>>>= ;> modules

>>>= ; which are designed to exist in the I2RS Ephemeral Control Plane data = store

>>>= ; (configuration and operational state).    

>>>= ;> 

>>>= ;> Draft location: 

>>>= ;> /

>>>= ;> 

>>>= ;> I would appreciate an email discussion with the security ADs, 

>>>= ;> OPS/NM ADs,

>>>= ; and Routing AD (Alia Atlas).  I agree that this I2RS YANG data = model

>>>= ; (L3) and the base I2RS topology model should both provide updated 

>>>= ; YANG Security Considerations sections. I would appreciate if = Benoit 

>>>= ; or you hold a discuss until we sort out these = issues.

>>>= ;> 

>>>= ;> Thank you,

>>>= ;> 

>>>= ;> Sue

>>>= ;> 

>>>= ;> -----Original = Message-----

>>>= ;> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.= ietf@gmail.com]

>>>= ;> Sent: Wednesday, January 18, 2017 9:44 = PM

>>>= ;> To: The IESG

>>>= ;> Subject: Kathleen Moriarty's No Objection = on

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ;> 

>>>= ;> Kathleen Moriarty has entered the following ballot position = for

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: No = Objection

>>>= ;> 

>>>= ;> When responding, please keep the subject line intact and reply = to 

>>>= ;> all email addresses included in the To and CC lines. (Feel free = to 

>>>= ;> cut this introductory paragraph, = however.)

>>>= ;> 

>>>= ;> 

>>>= ;> Please refer to

>>>= ;> for more information about IESG DISCUSS and COMMENT = positions.

>>>= ;> 

>>>= ;> 

>>>= ;> The document, along with other ballot positions, can be found = here:

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = -------------------------------------------------------------------

>>>= ;> -

>>>= ;> --

>>>= ;> COMMENT:

>>>= ;> = -------------------------------------------------------------------

>>>= ;> -

>>>= ;> --

>>>= ;> 

>>>= ;> I agree with Alissa's comment that the YANG module security 

>>>= ;> consideration

>>>= ; section guidelines need to be followed and this shouldn't go = forward 

>>>= ; until that is corrected.  I'm told it will be, = thanks.

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = _______________________________________________

>>>= ;> i2rs mailing list

>>>= ;> i2rs@ietf.org<= /span>

<= p class=3DMsoNormal>>>>= ; 

>>>= ; -- 

>>>= ; Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

>>>= ; Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

>>>= ; Fax:   +49 421 200 3103       =   <http://www.jacobs-univers= ity.de/>

>>>= ; 

>> 

>> = -- 

>> = Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

>> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

>> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

>> 

> 

> = -- 

> = Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

> 

> = _______________________________________________

> i2rs = mailing list

> i2rs@ietf.org<= /span>

 

__________________________= _____________________
i2rs mailing list
i2rs@ietf.org=
https://www.i= etf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_00E0_01D27582.C399A3B0-- From nobody Mon Jan 23 11:42:18 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 3A7CA1297E9; Mon, 23 Jan 2017 11:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_DOS_OUTLOOK_TO_MX_IMAGE=0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 GH_q_GjMeA00; Mon, 23 Jan 2017 11:42:06 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380CF1294F7; Mon, 23 Jan 2017 11:42:06 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Martin Bjorklund'" References: <023e01d2758a$fe85bd80$fb913880$@ndzh.com> <20170123.163215.1929278119114265404.mbj@tail-f.com> <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> In-Reply-To: <20170123.194721.1193117831378217486.mbj@tail-f.com> Date: Mon, 23 Jan 2017 14:37:11 -0500 Message-ID: <010a01d275b0$183d7360$48b85a20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_010B_01D27586.2F6FCFD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK2FjZB2e27lApU9Dveoqove81CuALyxlRQAa+0tjMCuq2KUJ9EQjaw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 19:42:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010B_01D27586.2F6FCFD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_010C_01D27586.2F6FCFD0" ------=_NextPart_001_010C_01D27586.2F6FCFD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin: I'm pulling your questions to the top of this email. Question 1: Ok. Just to make sure I understand this correctly - these topology models are intended to be I2RS-specific, and they cannot be used for any other purpose. If anyone needs a general topology model outside of the I2RS protocol, they will have to design their own model. Is this correct? Response 1: Not really. Most of the topology models I have seen abide by the concepts found in the I2RS topology model. See the diagram below. The 6 differences for security listed in my draft are: 1) different mandatory transport for NETCONF (use RFC7895), 2) support for priority for write conflicts plus secondary opaque identifier for tracing, 3) optional insecure protocol, 4) different data store, 5) different validations for data store(optional), and 6) different NACM policy (optional) plus backend policy (to/from routing protocols, to/from system). Using RESTCONF (which is fine as is) is an option that I suspect most Topology models will use. The current topology models implemented tend to 1) use RESTCONF, 2) use read-only and do not support tracing, 3) do not allow insecure protocols, and 4) operate as a different data store (that is they load from internal protocols), and 6) may use different NACM policy (for nodes) and provide some logic for back-end policy. What needs to be refined is the client-write Topology models based on the I2RS Control Plane datastore (e.g. or read-data datastore or write data datastore) . This concept is coming from the netmod working group draft-ietf-netmod-ietf-revised-datastores-00.txt. The netmod WG has cycled on many different ways to handle I2RS ephemeral data store, and settled on this proposal. Questions 2: To me, it feels weird that a model that is designed solely for the I2RS protocol is published *before* the details of the I2RS protocol are defined. But it this is what the WG wants, then a note that explains this would be useful. I assume that the idea is that vendors will use some proprietary mechanism for now. Response: Due to the wide spread use of the topology models, the I2RS WG passed WG LC on these YANG models and Benoit Claise review felt it was ok. The benefit in this approach is that the main structures are stable. The deficit is that adding the I2RS protocol definitions could cause changes. The I2RS protocol depends on the revised data store model (draft-ietf-netmod-revised-datastores, the revised NACM (draft-ietf-netconf-rfc6536bis-00.txt, the advances in the notification and pub/sub solutions, and proposals for I2RS protocol implementation in NETCONF and RESTCONF. I have individual proposal for the I2RS protocol (get-data datastore and write-data datastore) that I would like some private review of these proposals prior to sending them to NETCONF. Cheerily, Sue Hares part4 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Monday, January 23, 2017 1:47 PM To: shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) "Susan Hares" < shares@ndzh.com> wrote: > Martin: > > Answers inline. > > -----Original Message----- > From: i2rs [ mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: Monday, January 23, 2017 10:32 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" < shares@ndzh.com> wrote: > >> Martin: > >> > >> > >> > >> Thank you for your insightful questions. My answer to your > >> questions come from my understanding of the > >> draft-ietf-netmod-revised-datastores-00 > and > >> discussions with that design team at IETF 97. We have been moving many > >> things in parallel at the IETF rather than do single threaded work. The > >> Topoology work was completed 1 year in advance of the > >> draft-ietf-netmod-revised-datastores-00.txt. > > >Right; this is why I think an additional note in these modules are > necessary. If you just read these topoly drafts, you will find a > normal YANG module that has a "config true" subtree. > >Without additional guidance, it is not clear that these data models > >"do not > utilize the configuration data store" (if this is true). > > Sue: Sounds like a good idea. I'll suggest this to the authors as the > document shepherd. > > >> #1) model's nodes are "config true", and that "The YANG module > >> defined in this memo is designed to be accessed via the NETCONF > >> protocol". If it is true that these data models do not utilize the > >> configuration data stores, what does the "server-provided" leaf, > >> and the text about > "client-configured" > >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > >> > >> If the server-provided leaf is true, it indicates that the data is > >> populated by the I2RS Agent (aka netconf server) > > >Doesn't this procedure involve the normal configuration data stores? > >If it does, I think we're good. If it doesn't, I think the > >additional note > should be added. > > Sue: The model is in the I2RS control plane data store. According to > draft-ietf-netmod-revised-datatstores-00.txt this is note the normal > configuration data store. Ok. Just to make sure I understand this correctly - these topology models are intended to be I2RS-specific, and they cannot be used for any other purpose. If anyone needs a general topology model outside of the I2RS protocol, they will have to design their own model. Is this correct? > Does a note in the text plus a note at the beginning of the data model > suffice? To me, it feels weird that a model that is designed solely for the I2RS protocol is published *before* the details of the I2RS protocol are defined. But it this is what the WG wants, then a note that explains this would be useful. I assume that the idea is that vendors will use some proprietary mechanism for now. > >> rather than the I2RS Client (aka > >> netconf client). The I2RS architecture has aligned the two > architecture > >> concepts so the I2RS protocol is designed to be a re-use protocol > >> for the NETCONF protocol and the RESTCONF protocols as its message > >> transport protocols. > >> > >> draft-ietf-netmod-revised-datastores-00 states the following three > >> suggestions for supporting different datastores: > >> > >> > >> o For systems supporting or configuration > >> > >> datastores, the operation may be used to > >> retrieve > >> > >> data stored in these new datastores. > >> > >> > >> > >> o A new operation should be added to retrieve the operational > >> state > >> > >> data store (e.g., ). An alternative is to define > >> a > >> > >> new operation to retrieve data from any datastore (e.g., > >> > >> with the name of the datastore as a parameter). > >> In > >> > >> principle could work but it would be a > >> confusing > >> > >> name. > >> > >> > >> > >> o The operation will be deprecated since it returns data > >> from > >> > >> two datastores that may overlap in the revised datastore model. > >> > >> > >> > >> Based on this input, the I2RS ephemeral control plane data store > >> should use a "get-data I2RS-ephemeral" to get data from the I2RS > ephemeral data store > >> (CT, RW). To retrieve information from the applied configuration data > >> store, the "get-config" may be used. To retrieve state from the > >> operational state "get-state" should be used. > >> > >> > >> 2) Your suggestion to add another note about configuration true > >> > >> The config "true" is being implemented as the > >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see > diagram). > >> It is just in a different data store. Where and how the data store > >> information is stored, is unclear to me at this time. Where do you > >> think it belongs? > > > I always thought that the topology models could be written to > > through the > normal configuration data stores, in which case the server would set > the "server-provided" leaf to "false". It seems that you have some > other mechanism in mind? > > The design team for drat-ietf-netmod-revised-datastores-00.txt > indicated that the client written topology with "server-provided" leaf set to "false" > is written in the I2RS Control Plane data store. Ok. As you might know, I am the editor for drat-ietf-netmod-revised-datastores-00, and thus part of the design team, and I haven't seen any discussion about this. Was it discussed on the I2RS ML? /martin > An I2RS implementation > then combines the I2RS Control Plane data store with the intended > configuration data store (based on internal configuration knobs) and > installs this in a node. A client can query the topology data nodes > in the applied configuration data store. The response giving the > topology nodes will indicate that a dynamic control plane protocol inserted these nodes. > > I am only trying to interpret the netmod design and align the I2RS > data models (topology, RIB, FB-RIB) to this design. > > Thank you for your suggestions on the data model. > > Sue Hares > > > > > > /martin > > > > > 3) implementations > > > > > > > > Right now, the ODL implementation can utilize "get-config" to obtain > > the I2RS topology model since the I2RS topology database has no > > equivalent in the intended config. After the > > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > > will return from the applied configuration the Topology model with > > an > indication that it is dynamic (see > > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > > implementation can simply augment its current get-config with an > indication > > that the topology model is a "dynamic" data store. > > > > > > > > As another example, my understanding is that a change to the ConfD > > implementation would be to allow a "get-data" and "write-data" that allows > > the specification of a data store such as the I2RS data store. A > > get-config of the applied data store should have a "dynamic" flag > > for the topology database. > > > > > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > > but I am behind on event email. > > > > > > > > Cheerily, > > > > > > > > Sue > > > > > > > > -----Original Message----- > > From: Martin Bjorklund [ mailto:mbj@tail-f.com] > > Sent: Monday, January 23, 2017 6:47 AM > > To: shares@ndzh.com > > Cc: j.schoenwaelder@jacobs-university.de; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > > i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > Hi, > > > > > > > > "Susan Hares" < < mailto:shares@ndzh.com> shares@ndzh.com> wrote: > > > > > Juergen: > > > > > > > > > > Let's focus on your second point. The topology drafts are I2RS > > > drafts > > > > > designed for the I2RS ephemeral control plane data store. How can > these > > be > > > > > generic YANG modules when the following is true: > > > > > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > > > > > This was not clear to me. I note that the data model's nodes are > > "config true", and that "The YANG module defined in this memo is > > designed to be accessed via the NETCONF protocol". > > > > > > > > If it is true that these data models do not utilize the > > configuration data stores, what does the "server-provided" leaf, and > > the text about "client-configured" in section 4.4.10 of > > draft-ietf-i2rs-yang-network-topo refer to? > > > > > > > > If in fact this is correct, I think it would be helpful if a note > > was added to the YANG modules, that explains that these models are > > not supposed to be implemented in the same way as other "config > > true" data models. In the best of worlds it would also describe how > > they are supposed to be implemented (but I assume that this is up to > > each vendor > for now). > > > > > > > > I also note that it is not clear how such models would be advertised > > by a NETCONF server. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > > > configuration data store, > > > > > 3) I2RS Data models require the use of priority to handle the > > > > > multi-write contention problem into the I2RS Control Plane data > > > store, > > > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > > > mandatory-to-implement transport, > > > > > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > > > the discussion should be taken up with netmod WG list. > > > > > Do you disagree with i2rs-protocol-security-requirements? That > > > issue > > > > > is closed based on IESG approval. > > > > > > > > > > Sue Hares > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > [ < mailto:j.schoenwaelder@jacobs-university.de> > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > Sent: Monday, January 23, 2017 3:39 AM > > > > > To: Susan Hares > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > < mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < mailto:i2rs@ietf.org> > > i2rs@ietf.org; > > > > > < mailto:i2rs-chairs@ietf.org> i2rs-chairs@ietf.org > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > Susan, > > > > > > > > > > I consider tagging a YANG object statically and universally in the > > > > > data model as "does not need secure communication" fundamentally > > > > > flawed; I am not having an issue with insecure communication in > > > certain > > deployment contexts. > > > > > > > > > > The topology drafts are regular generic YANG models that just > > > happen > > > > > to be done in I2RS - I believe that using the generic YANG > > > security > > > > > guidelines we have is good enough to progress these drafts. > > > > > > > > > > /js > > > > > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > > > Juergen: > > > > > > > > > > > > I recognize that dislike insecure communication. You made a > > > > similar > > > > > > comment during the WG LC and IETF review of > > > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > > > draft-ietf-i2rs-protocol-security-requirements were passed by > > > > the > > > > > > I2RS WG and approved by the IESG for RFC publication and it > > > > contains > > > > > > the non-secure communication. The mandate from the I2RS WG for > > > > this > > > > > > shepherd/co-chair is clear. > > > > > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > > something > > > > > > that might address Kathleen's Moriarty's concerns about the > > > > topology > > > > > > draft's security issues about privacy and the I2RS ephemeral > > > > control > > > > > > plane > > > > > data > > > > > > store. I welcome an open discussion on my ideas > > > > > > ( > > > > > > > id > > > > er> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > > > The > > > > > > yang doctor's YANG security consideration template > > > > > > ( < https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > > > the privacy related RFCs (RFC6973) note that some information is > > sensitive. > > > > > > Hopefully, this document extends these guidelines to a new data store. > > > > > > > > > > > > > Cheerily, > > > > > > Sue Hares > > > > > > > > > > > > -----Original Message----- > > > > > > From: Juergen Schoenwaelder > > > > > > [ < mailto:j.schoenwaelder@jacobs-university.de> > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > > > To: Susan Hares > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > < mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < mailto:i2rs@ietf.org> > > i2rs@ietf.org; > > > > > > < mailto:i2rs-chairs@ietf.org> i2rs-chairs@ietf.org > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > For what it is worth, I find the notion that data models may be > > > > > > written for a specific non-secure transport plain broken. There > > > > is > > > > > > hardly any content of a data model I can think of which is > > > > generally > > > > > > suitable for insecure transports. > > > > > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > > is > > > > > > suitable to send over non-secure transports? I really do not see > > > > how > > > > > > the IETF can make a claim that a given piece of information is > > > > never > > > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > > > deployment information is shipped in whatever way but this is > > > > then a > > > > > > property of the _deployment_ and not a property of the _information_. > > > > > > > > > > > > /js > > > > > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > > > Kathleen: > > > > > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > > > modules > > > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > > data > > store > > > > > > (configuration and operational state). > > > > > > > > > > > > > > Draft location: > > > > > > > > > > > > > > > > ns > > > > > ide> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > > > r/ > > > > > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > > > OPS/NM ADs, > > > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > > model > > > > > > (L3) and the base I2RS topology model should both provide > > > > updated > > > > > > YANG Security Considerations sections. I would appreciate if > > > > Benoit > > > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kathleen Moriarty [ > > > > > < mailto:Kathleen.Moriarty.ietf@gmail.com> > > mailto:Kathleen.Moriarty.ietf@gmail.com] > > > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > > > To: The IESG > > > > > > > Cc: < mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < mailto:shares@ndzh.com> > > shares@ndzh.com; > > > > > > > < mailto:i2rs-chairs@ietf.org> i2rs-chairs@ietf.org; > > < mailto:shares@ndzh.com> shares@ndzh.com; < mailto:i2rs@ietf.org> > > i2rs@ietf.org > > > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > Kathleen Moriarty has entered the following ballot position > > > > > for > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > to > > > > > > > all email addresses included in the To and CC lines. (Feel > > > > > free to > > > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > > > > Please refer to > > > > > > > < https://www.ietf.org/iesg/statement/discuss-criteria.html> > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > > > > > > > > > > lo > > > > > gy/> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > COMMENT: > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > > > consideration > > > > > > section guidelines need to be followed and this shouldn't go > > > > forward > > > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > i2rs mailing list > > > > > > > < mailto:i2rs@ietf.org> i2rs@ietf.org > > > > > > > < https://www.ietf.org/mailman/listinfo/i2rs> > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > > Fax: +49 421 200 3103 < < http://www.jacobs-university.de/> > > http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < < http://www.jacobs-university.de/> > > http://www.jacobs-university.de/> > > > > > > > > > > _______________________________________________ > > > > > i2rs mailing list > > > > > < mailto:i2rs@ietf.org> i2rs@ietf.org > > > > > < https://www.ietf.org/mailman/listinfo/i2rs> > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > ------=_NextPart_001_010C_01D27586.2F6FCFD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Martin: =

 

I'm pulling your questions to the top of this = email.

 

Question 1: Ok.  Just to make sure I = understand this correctly - these topology models are intended to be = I2RS-specific, and they cannot be used for any other purpose.  If = anyone needs a general topology model outside of the I2RS protocol, they = will have to design their own model.  Is this = correct?

 

Response 1:  Not really.  =

 

Most of the topology models I have seen abide by = the concepts found in the I2RS topology model.   See the = diagram below.    The 6 differences for security listed = in my draft are:  1) different mandatory transport for NETCONF (use = RFC7895), 2) support for priority for write conflicts plus secondary = opaque identifier for tracing,   3) optional insecure = protocol, 4) different data store,  5) different validations for = data store(optional), and 6) different NACM policy (optional) plus = backend policy (to/from routing protocols, to/from system).  =  Using RESTCONF (which is fine as is) is an option that I suspect = most Topology models will use.

 

The = current topology models implemented tend to 1) use RESTCONF,  2) = use read-only and do not support tracing,  3) do not allow insecure = protocols, and 4) operate as a different data store (that is they load = from internal protocols), and 6) may use different NACM policy (for = nodes) and provide some logic for back-end policy. =    What needs to be refined is the client-write Topology = models based on the I2RS Control Plane datastore (e.g. or read-data = datastore or  write data datastore) .  This concept is coming = from the netmod working group = draft-ietf-netmod-ietf-revised-datastores-00.txt.   The netmod = WG has cycled on many different ways to handle I2RS ephemeral data = store, and settled on this proposal.   

 

 

Questions 2: To me, it feels weird that a = model that is designed solely for the I2RS protocol is published = *before* the details of the I2RS protocol are defined.  But it this = is what the WG wants, then a note that explains this would be = useful.  I assume that the idea is that vendors will use some = proprietary mechanism for now.

 

Response:  Due to the wide spread use = of the topology models, the I2RS WG passed WG LC on these YANG models = and Benoit Claise review felt it was ok.  The benefit in this = approach is that the main structures are stable.  The deficit is = that adding the I2RS protocol definitions could cause changes.  =  The I2RS protocol depends on the revised data store model = (draft-ietf-netmod-revised-datastores, the revised NACM = (draft-ietf-netconf-rfc6536bis-00.txt, the advances in the notification = and pub/sub solutions, and proposals for I2RS protocol implementation in = NETCONF and RESTCONF.    I have individual proposal for = the I2RS protocol (get-data datastore and write-data datastore) that I = would like some private review of these proposals prior to sending them = to NETCONF.  

 

Cheerily,

Sue Hares

 

3Dpart4

 

 

-----Original Message-----
From: Martin = Bjorklund [mailto:mbj@tail-f.com]
Sent: Monday, January 23, 2017 = 1:47 PM
To: shares@ndzh.com
Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org
Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

 

"Susan Hares" <shares@ndzh.com> wrote:

> Martin: =

>

> Answers inline.

>

> = -----Original Message-----

> = From: i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of Martin

> Bjorklund

> Sent: Monday, January 23, 2017 10:32 = AM

> To: shares@ndzh.com

> Cc: i2rs@ietf.org;= draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

> = j.schoenwaelder@jacobs-un= iversity.de; i2rs-chairs@ietf.org;

> Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org<= o:p>

> Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

>

> = "Susan Hares" <shares@ndzh.com> wrote:

> >> Martin: =

> >>

> >> 

> >>

> >> Thank you for your insightful = questions.  My answer to your

> >> questions come from my understanding = of the

> >> = draft-ietf-netmod-revised-datastores-00

> and

> = >> discussions with that design team at IETF 97.   We = have been moving many

> = >> things in parallel at the IETF rather than do single threaded = work.   The

> = >> Topoology work was completed 1 year in advance of the =

> >> = draft-ietf-netmod-revised-datastores-00.txt.

>

> = >Right; this is why I think an additional note in these modules = are

> necessary.  If you = just read these topoly drafts, you will find a

> normal YANG module that has a "config = true" subtree.

> = >Without additional guidance, it is not clear that these data models =

> >"do = not

> utilize the configuration = data store" (if this is true).

>

> = Sue: Sounds like a good idea.  I'll suggest this to the authors as = the

> document = shepherd.

>

> >> #1) model's nodes are "config = true", and that "The YANG module

> >> defined in this memo is designed to = be accessed via the NETCONF

> = >> protocol".  If it is true that these data models do = not utilize the

> >> = configuration data stores, what does the "server-provided" = leaf,

> >> and the text = about

> = "client-configured"

> = >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer = to? 

> >> =

> >> If the = server-provided leaf is true, it indicates that the data is =

> >> populated by the = I2RS Agent (aka netconf server)

>

> = >Doesn't this procedure involve the normal configuration data = stores?

> >If it does, I = think we're good.  If it doesn't, I think the

> >additional note

> should be added.

>

> = Sue:  The model is in the I2RS control plane data store. According = to

> = draft-ietf-netmod-revised-datatstores-00.txt this is note the normal =

> configuration data = store.

 

Ok.  Just to make sure I understand this = correctly - these topology models are intended to be I2RS-specific, and = they cannot be used for any other purpose.  If anyone needs a = general topology model outside of the I2RS protocol, they will have to = design their own model.  Is this correct?

 

> = Does a note in the text plus a note at the beginning of the data model =

> suffice?

 

To me, = it feels weird that a model that is designed solely for the I2RS = protocol is published *before* the details of the I2RS protocol are = defined.  But it this is what the WG wants, then a note that = explains this would be useful.  I assume that the idea is that = vendors will use some proprietary mechanism for now.

 

 

> = >> rather than the I2RS Client (aka

> >> netconf client).    = The I2RS architecture has aligned the two

> architecture

> >> concepts so the  I2RS protocol = is designed to be a re-use protocol

> >> for the NETCONF protocol and the = RESTCONF protocols as its message

> >> transport protocols.

> >>

> >> = draft-ietf-netmod-revised-datastores-00 states the following three =

> >> suggestions for = supporting different datastores:

> >>

> >>

> >>   o  For systems = supporting <intended> or <applied> = configuration

> >> =

> = >>      datastores, the = <get-config/> operation may be used to

> >> retrieve

> >>

> >>       = data stored in these new datastores.

> >>

> >> 

> >>

> >>   o  A new operation = should be added to retrieve the operational

> >> state

> >>

> >>       = data store (e.g., <get-state/>).  An alternative is to define =

> >> a

> >>

> >>       = new operation to retrieve data from any datastore = (e.g.,

> >> =

> = >>       <get-data> with the = name of the datastore as a parameter). 

> >> In

> >>

> >>       = principle <get-config/> could work but it would be a =

> >> = confusing

> >> =

> = >>       name.

> >>

> >>

> >>

> >>    o  The = <get/> operation will be deprecated since it returns data =

> >> = from

> >> =

> = >>       two datastores that may = overlap in the revised datastore model.

> >>

> >>

> >>

> >> Based on this input, the I2RS = ephemeral control plane data store

> >> should use a "get-data = I2RS-ephemeral" to get data from the I2RS

> ephemeral data store

> >> (CT, RW).   To retrieve = information from the applied configuration data

> >> store, the "get-config" may = be used.  To retrieve state from the

> >> operational state = "get-state" should be used.

> >> 

> >>

> >> 2) Your suggestion to add another = note about configuration true

> = >>

> >> The config = "true" is being implemented as the

> >> = draft-ietf-netmod-revised-datastores-00 suggests in section 5 = (see

> = diagram).

> >> It is just = in a different data store.   Where and how the data = store

> >> information is = stored, is unclear to me at this time.  Where do you =

> >> think it = belongs?

>

> > I always thought that the topology models = could be written to

> > = through the

> normal = configuration data stores, in which case the server would set =

> the = "server-provided" leaf to "false".  It seems = that you have some

> other = mechanism in mind?

> =

> The design team for = drat-ietf-netmod-revised-datastores-00.txt

> indicated that the client written topology = with "server-provided" leaf set to = "false"

> is written = in the I2RS Control Plane data store.

 

Ok.  As you might know, I am the editor for = drat-ietf-netmod-revised-datastores-00, and thus part of the design = team, and I haven't seen any discussion about this.  Was it = discussed on the I2RS ML?

 

 

/martin

 

 

> = An I2RS implementation

> then = combines the I2RS Control Plane data store with the intended =

> configuration data store = (based on internal configuration knobs) and

> installs this in a node.  A client can = query the topology data nodes

> in the applied configuration data store.  = The response giving the

> = topology nodes will indicate that a dynamic control plane protocol = inserted these nodes.

> =

> I am only trying to = interpret the netmod design and align the I2RS

> data models (topology, RIB, FB-RIB) to this = design.

>

> Thank you for your suggestions on the data = model.

>

> Sue Hares

> 

>

> =

>

>

> = /martin

>

>

> =

> > 3) = implementations

> > =

> > 

> >

> > Right now, the ODL implementation can = utilize "get-config" to obtain

> > the I2RS topology model since the I2RS = topology database has no

> = > equivalent in the intended config.  After the =

> > = draft-ietf-netmod-revised-datastore is implemented, the = "get-config"

> > = will return from the applied configuration the Topology model with =

> > an

> indication that it is dynamic = (see

> > = draft-ietf-netmod-revised-datastores-00.txt section 8.   The = ODL

> > implementation can = simply augment its current get-config with an

> indication

> > that the topology model is a = "dynamic" data store.   

> >

> > 

> >

> > As another example, my understanding is = that a change to the ConfD

> = > implementation would be to allow a "get-data" and = "write-data" that allows

> > the specification of a data store such as = the I2RS data store.   A

> > get-config of the applied data store = should have a "dynamic" flag

> > for the topology = database.

> > =

> > 

> >

> > 4) Notifications - I am unclear how these = are tagged to a datastore,

> = > but I am behind on event email.

> >

> > 

> >

> > Cheerily,

> >

> > 

> >

> > Sue  

> >

> > 

> >

> > -----Original = Message-----

> > From: = Martin Bjorklund [mailto:mbj@tail-f.com]

> > Sent: Monday, = January 23, 2017 6:47 AM

> > = To: shares@ndzh.com

> > Cc: j.schoenwaelder@jacobs-un= iversity.de;

> > = draft-ietf-i2rs-yang-l3-t= opology@ietf.org; i2rs@ietf.org;=

> > Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org;=

> > i2rs-chairs@ietf.org

> > Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on

> > draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

> > =

> > 

> >

> > Hi,

> >

> > 

> >

> > "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:

> > =

> > > Juergen: =

> >

> > >

> >

> > > Let's focus on your second = point.  The topology drafts are I2RS

> > > drafts

> >

> > > designed for the I2RS ephemeral = control plane data store.   How can

> these

> > be

> >

> > > generic YANG modules when the = following is true:

> > =

> > >

> >

> > > 1) I2RS Data models do not utilize = the configuration data store,

> = >

> >  =

> >

> > This was not clear to me.  I note = that the data model's nodes are

> > "config true", and that = "The YANG module defined in this memo is

> > designed to be accessed via the NETCONF = protocol".

> > =

> > 

> >

> > If it is true that these data models do = not utilize the

> > = configuration data stores, what does the "server-provided" = leaf, and

> > the text = about "client-configured" in section 4.4.10 of =

> > = draft-ietf-i2rs-yang-network-topo refer to?

> >

> > 

> >

> > If in fact this is correct, I think it = would be helpful if a note

> = > was added to the YANG modules, that explains that these models are =

> > not supposed to be = implemented in the same way as other "config

> > true" data models.  In the best = of worlds it would also describe how

> > they are supposed to be implemented (but = I assume that this is up to

> = > each vendor

> for = now).

> >

> > 

> >

> > I also note that it is not clear how such = models would be advertised

> = > by a NETCONF server.

> = >

> >  =

> >

> > 

> >

> > /martin

> >

> > 

> >

> > 

> >

> > 

> >

> > 

> >

> > > 2) I2RS Data Models do not require = the same validation as

> > =

> > > configuration data = store,

> >

> > > 3) I2RS Data models require the use = of priority to handle the

> = >

> > > multi-write = contention problem into the I2RS Control Plane data

> > > store,

> >

> > > 4) I2RS require TLS with X.509v3 = over TCP for the

> > =

> > > = mandatory-to-implement transport,

> >

> > >

> >

> > > Do you disagree with = draft-ietf-netmod-revised-datastores?  If so,

> >

> > > the discussion should be taken up = with netmod WG list.

> > =

> > > Do you disagree = with i2rs-protocol-security-requirements?  That

> > > issue

> >

> > > is closed based on IESG = approval.

> > =

> > >

> >

> > > Sue Hares

> >

> > >

> >

> > > -----Original = Message-----

> > =

> > > From: Juergen = Schoenwaelder

> > =

> > > [ <mailto:j.schoenwaelder@ja= cobs-university.de>

> > mailto:j.schoenwaelder@ja= cobs-university.de]

> >

> > > Sent: Monday, January 23, 2017 3:39 = AM

> >

> > > To: Susan Hares

> >

> > > Cc: 'Kathleen Moriarty'; 'The = IESG';

> >

> > >  <mailto:draft-ietf-i2rs-ya= ng-l3-topology@ietf.org>

> > draft-ietf-i2rs-yang-l3-t= opology@ietf.org;  <mailto:i2rs@ietf.org>

> > i2rs@ietf.org;=

> >

> > >  <mailto:i2rs-chairs@ietf.o= rg> i2rs-chairs@ietf.org

> >

> > > Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

> = >

> > > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> >

> > >

> >

> > > Susan,

> >

> > >

> >

> > > I consider tagging a YANG object = statically and universally in the

> >

> > > data model as "does not need = secure communication" fundamentally

> >

> > > flawed; I am not having an issue = with insecure communication in

> > > certain

> > deployment contexts.

> >

> > >

> >

> > > The topology drafts are regular = generic YANG models that just

> > > happen

> >

> > > to be done in I2RS - I believe that = using the generic YANG

> > = > security

> > =

> > > guidelines we have = is good enough to progress these drafts.

> >

> > >

> >

> > > /js

> >

> > >

> >

> > > On Thu, Jan 19, 2017 at 01:15:15PM = -0500, Susan Hares wrote:

> = >

> > > > Juergen: =

> >

> > > >

> >

> > > > I recognize that dislike = insecure communication.  You made a

> > > > similar

> >

> > > > comment during the WG LC and = IETF review of

> > =

> > > > = draft-ietf-i2rs-protocol-security-requirements.  However, = the

> >

> > > > = draft-ietf-i2rs-protocol-security-requirements were passed by =

> > > > = the

> >

> > > > I2RS WG and approved by the = IESG for RFC publication and it

> > > > contains

> >

> > > > the non-secure = communication.  The mandate from the I2RS WG for

> > > > this

> >

> > > > shepherd/co-chair is = clear.

> >

> > > >

> >

> > > > As the shepherd for the = topology drafts, I try to write-up

> > > > something

> >

> > > > that might address Kathleen's = Moriarty's concerns about the

> > > > topology

> >

> > > > draft's security issues about = privacy and the I2RS ephemeral

> > > > control

> >

> > > > plane

> >

> > > data

> >

> > > > store.   I welcome an = open discussion on my ideas

> = >

> > > > = (

> > > > = <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons<= /o:p>

> > > > id

> > > > er>

> > https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-consider).

> >

> > > The

> >

> > > > yang doctor's YANG  = security consideration template

> >

> > > > ( <https://trac.ietf.org/tra= c/ops/wiki/yang-security-guidelines>

> > https://trac.ietf.org/tra= c/ops/wiki/yang-security-guidelines) and

> >

> > > > the privacy related RFCs = (RFC6973) note that some information is

> > sensitive.

> >

> > > > Hopefully, this document = extends these guidelines to a new data store.

>

> = >

> > > > =

> >

> > > > Cheerily,

> >

> > > > Sue Hares

> >

> > > >

> >

> > > > -----Original = Message-----

> > =

> > > > From: Juergen = Schoenwaelder

> > =

> > > > [ <mailto:j.schoenwaelder@ja= cobs-university.de>

> > mailto:j.schoenwaelder@ja= cobs-university.de]

> >

> > > > Sent: Thursday, January 19, = 2017 10:34 AM

> > =

> > > > To: Susan = Hares

> >

> > > > Cc: 'Kathleen Moriarty'; 'The = IESG';

> >

> > > >  <mailto:draft-ietf-i2rs-ya= ng-l3-topology@ietf.org>

> > draft-ietf-i2rs-yang-l3-t= opology@ietf.org;  <mailto:i2rs@ietf.org>

> > i2rs@ietf.org;=

> >

> > > >  <mailto:i2rs-chairs@ietf.o= rg> i2rs-chairs@ietf.org

> >

> > > > Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

> = >

> > > > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> >

> > > >

> >

> > > > For what it is worth, I find = the notion that data models may be

> >

> > > > written for a specific = non-secure transport plain broken. There

> > > > is

> >

> > > > hardly any content of a data = model I can think of which is

> > > > generally

> >

> > > > suitable for insecure = transports.

> > =

> > > > =

> >

> > > > Can we please kill this idea of = _standardizing_ information that

> > > > is

> >

> > > > suitable to send over = non-secure transports? I really do not see

> > > > how

> >

> > > > the IETF can make a claim that = a given piece of information is

> > > > never

> >

> > > > worth protecting (=3D suitable = for non-secure transports).

> = >

> > > > =

> >

> > > > Note that I am fine if in a = certain trusted tightly-coupled

> >

> > > > deployment information is = shipped in whatever way but this is

> > > > then a

> >

> > > > property of the _deployment_ = and not a property of the _information_.

> >

> > > >

> >

> > > > /js

> >

> > > >

> >

> > > > On Thu, Jan 19, 2017 at = 09:28:14AM -0500, Susan Hares wrote:

> >

> > > > > Kathleen: =

> >

> > > > >

> >

> > > > > I have written a draft = suggesting a template for the I2RS YANG

> >

> > > > > modules

> >

> > > > which are designed to exist in = the I2RS Ephemeral Control Plane

> > > > data

> > store

> >

> > > > (configuration and operational = state).   

> = >

> > > > > =

> >

> > > > > Draft location: =

> >

> > > > > 

> > > > > = <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-co

> > > > > = ns

> > > > > = ide>

> > https://datatracker.ietf.= org/doc/draft-hares-i2rs-yang-sec-conside

> >

> > > > > r/

> >

> > > > >

> >

> > > > > I would appreciate an = email discussion with the security ADs,

> >

> > > > > OPS/NM = ADs,

> >

> > > > and Routing AD (Alia = Atlas).  I agree that this I2RS YANG data

> > > > model

> >

> > > > (L3) and the base I2RS topology = model should both provide

> = > > > updated

> > =

> > > > YANG Security = Considerations sections. I would appreciate if

> > > > Benoit

> >

> > > > or you hold a discuss until we = sort out these issues.

> > =

> > > > > =

> >

> > > > > Thank = you,

> >

> > > > >

> >

> > > > > Sue

> >

> > > > >

> >

> > > > > -----Original = Message-----

> > =

> > > > > From: = Kathleen Moriarty [

> > > = > > <mailto:Kathleen.Moriarty.= ietf@gmail.com>

> = > mailto:Kathleen.Moriarty.= ietf@gmail.com]

> = >

> > > > > = Sent: Wednesday, January 18, 2017 9:44 PM

> >

> > > > > To: The = IESG

> >

> > > > > Cc:  <mailto:draft-ietf-i2rs-ya= ng-l3-topology@ietf.org>

> > draft-ietf-i2rs-yang-l3-t= opology@ietf.org;  <mailto:shares@ndzh.com>

> > shares@ndzh.com;

> >

> > > > >  <mailto:i2rs-chairs@ietf.o= rg> i2rs-chairs@ietf.org;

> > <mailto:shares@ndzh.com> shares@ndzh.com;  <mailto:i2rs@ietf.org>

> > i2rs@ietf.org<= o:p>

> >

> > > > > Subject: Kathleen = Moriarty's No Objection on

> = >

> > > > > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> >

> > > > >

> >

> > > > > Kathleen Moriarty has = entered the following ballot position

> > > > > for

> >

> > > > > = draft-ietf-i2rs-yang-l3-topology-08: No Objection

> >

> > > > >

> >

> > > > > When responding, please = keep the subject line intact and reply

> > > > > to

> >

> > > > > all email addresses = included in the To and CC lines. (Feel

> > > > > free to

> >

> > > > > cut this introductory = paragraph, however.)

> > =

> > > > > =

> >

> > > > >

> >

> > > > > Please refer = to

> >

> > > > >  <https://www.ietf.org/iesg= /statement/discuss-criteria.html>

> > https://www.ietf.org/iesg= /statement/discuss-criteria.html

> >

> > > > > for more information about = IESG DISCUSS and COMMENT positions.

> >

> > > > >

> >

> > > > >

> >

> > > > > The document, along with = other ballot positions, can be found here:

> >

> > > > > 

> > > > > = <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topo

> > > > > = lo

> > > > > = gy/>

> > https://datatracker.ietf.= org/doc/draft-ietf-i2rs-yang-l3-topology/

> >

> > > > >

> >

> > > > >

> >

> > > > >

> >

> > > > > = --------------------------------------------------------------=

> > > > > --

> > > > > --

> >

> > > > > --

> >

> > > > > --

> >

> > > > > COMMENT:

> >

> > > > > = --------------------------------------------------------------=

> > > > > --

> > > > > --

> >

> > > > > --

> >

> > > > > --

> >

> > > > >

> >

> > > > > I agree with Alissa's = comment that the YANG module security

> >

> > > > > = consideration

> > =

> > > > section = guidelines need to be followed and this shouldn't go

> > > > forward

> >

> > > > until that is corrected.  = I'm told it will be, thanks.

> = >

> > > > > =

> >

> > > > >

> >

> > > > >

> >

> > > > > = _______________________________________________

> >

> > > > > i2rs mailing = list

> >

> > > > >  <mailto:i2rs@ietf.org> i2rs@ietf.org<= o:p>

> >

> > > > >  <https://www.ietf.org/mail= man/listinfo/i2rs>

> > https://www.ietf.org/mail= man/listinfo/i2rs

> = >

> > > > =

> >

> > > > --

> >

> > > > Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

> >

> > > > Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

> > =

> > > > = Fax:   +49 421 200 = 3103         < <http://www.jacobs-univers= ity.de/>

> > = http://www.jacobs-univers= ity.de/>

> > =

> > > > =

> >

> > >

> >

> > > --

> >

> > > Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

> >

> > > Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

> > =

> > > Fax:   = +49 421 200 3103         < = <http://www.jacobs-univers= ity.de/>

> > = http://www.jacobs-univers= ity.de/>

> > =

> > >

> >

> > > = _______________________________________________

> >

> > > i2rs mailing list

> >

> > >  <mailto:i2rs@ietf.org> i2rs@ietf.org<= o:p>

> >

> > >  <https://www.ietf.org/mail= man/listinfo/i2rs>

> > https://www.ietf.org/mail= man/listinfo/i2rs

> = >

> > > =

> >

>

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

> =

------=_NextPart_001_010C_01D27586.2F6FCFD0-- ------=_NextPart_000_010B_01D27586.2F6FCFD0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAILAz4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKTOKKAFopAQe lRXV1FZW7TzuFjXqaTaSuwJqK4+68YXLyH7LCkaDoX5Jp1n4wmWQC9hVkPVo+CPwrm+uUr2uRzo6 6io4J47mFZYWDRuMgipK6k7lhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVi/8ACQqm qNbzLHHCGZd5fkEdyPQ1NPr1v5a/Yit1I2cKrYxgZJNZe2hrqLmRqUVgweIZriSBxbxrbzPsUGT9 57nHoK0DrWnAEm8h4O0/N3ojWhLqCki9RVB9b05CQ15DkcH5s0s+s2NvbiVrmMhgSoVslvpVe0h3 QXRZuLmG1j8y4lSNPVjiqK+IdMd9ou0B9wQPzridQ1CbUrpppmJyflXso9BVYc4A71588fK/urQz dTseoI6yKGRgynoQcg06uI0bU5dG1A2t02ICcOCchD6iupfWtOjI3XkPIzw2a66WIjON3oy1JMvU VTl1axhRGkuogrjKnd1qkmvq16VZYhZhygm39wM5+laOrBbsd0bNFU49WsZYnlS7iKJ947ulRrru msQBeRZPTmn7SHdBdGhRVeO/tprhreOeNpl6oDyKsVSaewwoprHajH0Ga53TtdufPIuVmn8xCyJH DznOOPUe9ROrGDSfUTdjpKKwrnWLycyiwgZDAgaRZY/mJ/uj/Gizu76PUokvJsrJEZJEaMKqD2Pe p9vG9kLmN2mu6xoWdgqgZJPQVmN4ggRDK1tdeR2l8v5TWJ4l1aa5iihWCaCFuT5gwX/+tU1MRCEW 1qDkkjSufF1lDIVhSSbH8S8D9alsfE9leSCNi0Lk4Afofxrk5tKuYhbYjd2uF3KoX9KiOn3YmMJt pfNAyU2849a4vrddS1RnzyPSqK53SdYltrUWl9DO13HwkYTLMvrSXuuXBuHMBe3WCMPJHLHyTnGP y9K7vrEOXmNOZWOjorL/ALegQB54bmGE/dlkjwrUj66sa7msbwKSArGPg56d6v20O4+ZGrRWWviC 0d41VZjuIVjs4RicAH3rTY7VJ9BVRnGXwsE7i0Vzena9ceey3KyzeYm6NI4ec5xx6j3qe51i8m8z +z7dwYFDSJLGdxOfuj8OayWIg1cXMjdorEsrq+XU4orubcJIjI6GLaE+h7+9TS+IIUjeVbe5eFQc TCP5Cfr/AFqlWja70HzI1ao6hq9ppgH2iT5z0ReWNUItXvoSwurWSVpIxJEIY/u57H6cVyN6bhru RrxXWdjlg4wa56+L5I+6tSZTstDqV8ZWhfDQTKvrwa27S9gvoRLbSB1746j61wM+lXUP2cCJ3adN yqF5+lWNJe+0vVBtt5iQP3sQXkr9Kyp4qopWqLQlTd9TvaKy/wC3oPueRc/aP+eHl/P9fpWfea7c G5doS0EVuitJHLH8xy2CPy9K7JV4RV7luSOkorL/ALet0G6eG4giP3ZJIyFakfXlRQzWN6FJAUmL rnp3qvbQ7j5katFZaa/aSSxoqzHeQpbZwjHoD71qVUZxl8LBO4UUUVQwooooAKKKKAMXxEjS/ZIl xh3bKliAcKTziqlrqeoR2UKL9nL+VlY3Lb2GOuen4Vo61DO7W0sELTeWzblUjPKkd6y/suoNHHHJ a3QmWMRjZOBEfQnvXFU5lUbV/wCrGb3IhbxvIjXF8JUe38943d8M3PPHb2ptpOt1DaWLzEQgPLIC WGTzhM+gHNK2n3oCIbKVpEga3Zgy7D6EVcutKu7Y20iST3gUMrISvy5XHFZKMt7ev4CsytaTPZSl 7IRJFJAHdnZii/MQCB1NQ6s99qzLATETGglRIyf3wPGRn09Knt7XUIoFRrOcRrCInMcgD5BJytVL uWfTJxdPbTrIVCQNO4fHqT7+1TJvks7pA9ihPYmC1lx5cjJMELpknOMkD2ptrprXEXmSTRW6F9im XI3N6CpZNTSOOQWayQs0olByPl4wQPxNXLBxqVt/pziVo5t4PmhGHHfPUcdua51GEpWRNkIgu7LT Lu0N1CkQlMfO7cW6kLj1qzGbkWzWLSwQQtOVG52y/TKqew+vrVeWCfVvtJsoWkjFy0gkyACMdB71 ca1upJA9xptwwEhkjCSKODjKt+VbxT6Xt8xijUFt7BrGGZo5DdNHk5zGm71/T8akivLqx86CGa38 iOYqkkxdif8AZ/D1pTpN7PYyyiWaORpDItsxG3G7OD71G0V2xlzZXyRvKZF8qVQ249QfatffVtyt SS81C6vYjby+TZqZBE5dzmRhjIXHb3PrWjoiCKG5iXOyO4dVBOcDjisdtPu8J9qsZpQJDLH5coJX OMqxP0HNbekxypDM80RiaWZpAjHkA1pS5nO8hq9y/RRRXYWFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHKsI f7THmhc+fNszj72BjrxTo5pkv7cSRvHcurqGkKb2GOAQPfpW3Jo9hNK8slrGzv8AeJ70xdD05Y2Q WqYbrnJP59a4/YTvp/X4EcrOejluriKzSX7S7oHJWFV3Ag470QGK2AmmQq0B+zFJQN21jwT+Ga6a 00y0sXL20CoxGCRk8UlxpFjdTGae2R5CMEnvS+rTte+ouVnPWh8i4ltLdC/kIFzCV8zOckgHgj1p Gjnje5GmNG915wMhVVDBcenTr1xW+2h6e0Sxm1TapJGM5H49aSXQtPliWM2yKFBCleCPxo+rztb+ vyDlZz090bOO4ezMa7rtQSoBHTnHtmql99jt9SuCDMtwsuU2AbBVbU9Mn0u4McoJjJ+R+zD/ABqk T6muCpUknytGbZ09yb1ri7a0AN2ZF28LkxY7Z7ZpdswjuDpqxmXzl37Ap52/NjPbPWqXh/Q3v5hP cqRbJ2JwX9vpW0/h0NdbFMS2O8SGIAhs4xjPpXVCM5rmtv5lpN6meu4vcf2WEM3nfvdgU8YHr/Dn OcUii284hPK8v7U2zP3N+zj8M1vyaLp8qIrWseEGFxxx+FH9h6dkn7HFyMYxxWv1efkPlZhYfdD9 uC/bsv5IkCg9OM44xnpTbmWeGPTzfqN7s6SZAztPHOK1rjw/Aqq9gscMynq43Kw9DntVRtAvXeKV pLMNF9yIRnyx7/WolSqLS39aA0yTRLIRXxXOVtE8vd6u3LH8sVv1V0+z+xW2wuZJGYu7n+Jj1q1X ZShyRsWlZDZOY2+hrj4LuEW4hZo1YwbC0gO1WDE4bHTNdlTfLQgjauD1461NWk5tNMTVzjZLhXjn jaaIK1v5aSKrBCQc7QT1p8Fs+oeZJb28FyEiRSZGYEHbyBiuv8tNoXYu0dscUqqFGFAA9hWX1XXV i5DjpbmB7JhNIjSeWFG0MsoI/hZehA9apXl7F/adxK8Ed1G+AhcnA47V3vlpuLbF3Hqcc1jeIdPt 7y3Rd6R3Cn92PXPas6uHko3TE4uxhx3UDRwZuUjL2zQ9TmNs559vep7V4zC1st4GaK2cNOudoyRw D1xWJcWNzaSFJ4JEI/2eD+NWNO02/u3KWyOiONruRhce9ckakua3LqQmzQSaIW4t/PDAQ+UbrB2b t27bnrjHFNe6hRPL3+cUgCBgDiQ7wdq+uBXU6fp0Wn2K2yAMByxI+8fWrQjQAAIoC9OOldqw0mtW acrOQe7gjmnmEwuPPZdsIB3feB+YHgY6Ut2jQ2GoSfad5eVCq4YFTnPOeh/wrqbizhuYZI5IxtkG GIGD+dZreHEl4nvbuXbzHuf7h9felKhPpqJxZUsYFudRt8IVBH2qUEYwxGAP5muik/1bfQ1WsdPj sVch3llkOXkkOWarddNKHLHXdlpWONgu4BB5LPGrGAJukztUhidrEcimzXAljuIzPEAbcRpIoYIx BztBPWux8qMgjYuD1GOtHlIVC7F2joMcVh9Wla1/6+8nkOShtZNSmlkt4YblVijXMkjDB28gYpDP EG8wzYYReV9m+bfu2427emM85rr1RUGFUKPQCjy0379i7v72Oaf1bz1DkOLkuUS1kZbhRI1msWwE 7lYHkGq1xewAwF4I7o/Z0Ul2PykZz0ru2gifO6NDnrletcXrHh2eylaS2RpbYnI28lPY1z16M4K6 1JlFodHcwtDCPtSRmS1MOcnMbZzz6A9M1NA6NBJbreKXitWVrgE7RlhxnrisBYpHbasblj2CnNdF o/hqd0aS8d4EcY8terD3rKk51HZIlXZEJo/I8gzgjyRF9qO7yywbdt3dcY4zTZLuFV2bxMY4UTcA f3pDg4GeuBXYiKMR7Ni7P7uOKBEg24Rfl6cdK7Pqz7/195pynJG7gillk89brz5FKxLkt97PzA9C OlJdq1vp16/2oSs06Mo5yDnPOeh9vaupuLGC6heKSMYfqVGD9c1nP4dE3+vvruUrzGWYfIfX3qZU J7LUTiyrYW6T6nBtTCgfapQeMOwwB/M10dVLGwSxV8O8kkhy8jnLMat100ockdS0rBRRRWowoooo AKKKKACiiigAooooAbI2yNmALYGcDvXP3N7/AGy62bwqI3br1Ye9P1fU2nb7JaEnJwzDv7CoVn0/ Q2jNxK0l0oO5E5xn1rkq1FJ2vp1IbuZ114TvoZD5GydOxBwfxBp1n4Su5pB9qKQxjrzuY/StiDxb p8rhX82LP8Trx+lbSSLKivGwZWGQQcg1nDDUJu8XcSjF7EdraxWdukEC7UQYAqaiiu5JJWRoFFFF MAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBkkaSoUkRXU9QwyKqpo+nxu HWzhDDvtq7RUuMXugscxcXUtpqkxifYN+OeldJExaJGYqSRnK9KpavZC6sm2qN6fMMd/Wqug3pZP s0h5XlCe49KwhenU5X1JWjsbVFFFdJQUUUUAFFFFABRRRQAUUUUANd1jRnc4VRkmsGzs3u75bxQR D5mRuOSRVu8dtRuxZRH90nMrD+VaaIsaKiDCqMAVi17SXkidyG+nFtZySdwOPrVDQ71pozBJksvI Y+lazAMMEAj3rE8OHab2I/wymid1UjqD3NyiiitigooooAKKKKACiiigAooooAKwdbvZhMIFBRev u1b1YEP+n+KJJOqW64FY172UV1JkbcDCSFHH8Sg1JSdKWtkUFFFFABRRRQAUUUUAFYF7rc9pqxRm AtkdUYeWTwRnOfX2rfrmL66httVlMxHFzG23vjaece1c+Ik4pWdtSZGhNrhcpBawSrcythBPGVGO 7fQVSGqaq0KTyBYR5gi8own5znBJPaqn2tYZ4N01uyCcSFopGkKjpuJPQc1Dbo86RWisl1ILiRig mIBGBg5Fc0qspPcjmZsTaheXU8rWkoht45BErGEvvbufYCnWXiBWtQbiOZ3QlZXiiJRcHvWKsn2O YwSssBW9jYx+YSAuOTk9RU0F5F5EDRzW6GFn3iWRlP3icgD72aI1pXvcOY138R2piYxJO0hUmNfK Pz+49qND1Ke8Wf7UynYqtu2bMZGf8msGKdP7Lkt/tCrLMGZGH3YwTnYT23Ypyp9pimkhhSZI4E3v 5xXb8vTA60KvNyTv/X4j5mdA/iC1VS/lXLRD/lqsJ2keoPpWbq2tzzRkWqTww+WWZ3hPzH0HoMd6 ry7nivJVuB5TW3EO47l4HBXtj196rT3ivd3RMwaL7IFQbuCcLwPeipWm1ZsTkxY3uo4pbmBWhCRF g7xn5ucfKT9etY8cU1wzeWjyt1O0Emt6e5jaO/l+2RyRTxjy4d5z1HGO2OlUob2EW96baMWjGHaA shJY7h0/CuapFNpNksoNZ3KI7PbyqqHDEocKfetzw5fzaeNt2siWUnKSMp2q319DUb3yvOQ9xuj+ whSC/BbHT61LdXiSRzSQvbvHNGEWPexc9Pl2dAR61VOKpy5ovYFpqi/fa1dOHlsQY4Ioy++WE4kO cYFOsNecrLHcxzzyxvjMUBzj1I7VmXFwjR6hJ9tjaOeL93Fv5HI429sdKkW4tjc3EguYj/pAYh5i ihcD5gB941v7WXNfm/rUq7udJFf281mbpZAIQCWLcbcdc1mXeutIYYbNJYpJnCrJNCQpHqPWs14v tD3txBbLcQLMWLrMeRweFHBpjXKLqEMrahG8T3IkVA2cDnk5+7jpirnXk1bYbkzYtdfjS2QagskU +O8RAk5/h9albxBbIQskN0jt91GhILfSubtbtJY4/tV0ykXhYMX5C7TyPQZxzV03cEYtB51uHinZ iEmL7QVODk0o4iTW4KTNY+ILVdoeK6V2+4hhIL+4p39vWgBEizxPjKo8RDP/ALo71zVje/u7Nrif 94ly7He3IBTr9M1Jp1/GttbG6mzKHlGXYkpleCe4GaUcVJ9f60/zDnZrXutyyOkNnuglCu7ieIg4 AyOPeti0mNxZwzMADIgYge4rk2ukRo45Jrb5Y5f9XIz4yvA3H19K6jTRjS7UH/nkv8q2oVHOTuxx d2WqKKK6iwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArm722az1DMXGT5kZ9+4rpKpapam4tS U/1sZ3IayrQ5o+gpK5NZ3S3dssq9+o9DU9YNjdC2nSXpBccMP7j1vU6c+ZAncKKKK0GFFFFABRRR QAVS1K8NvEI4uZ5flQD+dWZ50t4WlkOFUZqhp0D3EzX9wPmb/Vqf4RWc2/hW4n2LNhZiztwvWRuX b1NWqKKtJJWQwrC0j93ruoRepzW7WDD+68WSj++v9Kyq6Si/Ml9DeooorYoKKKKACiiigAooooAK KKKAIbuYW9rJKf4VJrK8NQn7PLcN96V+tP8AEk+yzWFT80jfpV7ToPs9hDHjkLk1h8VX0J3kWqKK K3KCiiigAooooAKKKKACmGGNn3tGhfGNxUZp9FAES28KBgkMahuoCgZpY7eGI5jijQ+qqBUlFKyA je3hkYs8UbMeMlQTSG2gYqTDGSvTKDipaKLICL7NDtK+THtJyRtGDWffyooNhZxIZZhhgowFHvU+ oXxgxBbjfcScKPT3NUGja1xawHfez/6yT+6KxqSWy/ryJbKkemzXdwLL7bNNaxAeZnGOO2eproVt LeONUWCMKnQbRxRZ2iWdusafUn1NUtV1UWqmKAgzdz/dpRhGlHml/XkCSRU1K5065ikg+z5Z+C4Q KQfX1rmL/SrrT5MTRNs7OBkGulsNJmuPLuZmAy4bBHLCugIBGCMisHh3XXNLTsTy8255jFDJO4SG N3Y9AozXZeHtCOnIZ7kD7Q4wB12D/GttUVfuqB9BTqujg403zN3Y4wsQm0tyxYwRFj1OwZo+yW5x +4i46fIOKmorr5V2LGpGkS7Y0VV9FGKj+y2/zfuIvm6/IOamoosgIjbQnkwxnjH3R0pPsdtjH2eH H+4Kmoo5V2Aia1gY5aGMnpygpfs8WSfKTJGCdo5FSUUWQEItbcLtEEQXOcbBjNS0tFCSQBRRRTAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMOa2WK9ktX4hufmQ/wB16u6XctJG1vNxND8p z3HrT9TtTc2h2f6xPmQ+9Z7ys8UOpQj94nyzKO4rmf7uWn9L/gE7M3KKZFKs0SyIcqwyKfXSUFFF FABRRWdqd0/y2lvzNLxx/CPWplJRVwbsQyE6tfeUv/HrCfmP941rAAAADAFQ2lqlpbrEnbqfU1PS hFrV7sSQUUUVYwrAvP3Xii3fswArfrn9d/d6paSf561hiPhT7NEy2OgopByKWtygooooAKKKKACi iigAoopk0giheRuigmgDn9QP27Xo4RyqED/GuiHAxXPaEhn1GW4bqAT+Jroqwoapz7kx7hRRRW5Q UUUUAFFFFABRRRQAUUUUAFFFFABVLUL8WqhIxvnfhEH86df3y2cQ43StwiDqTVaCEWUb31826dh/ 3z7Cspy+yv8AhhNkeP7LhM0p829m6d+atadZG3RpZjuuJOXY9vaobC3e5nN9dD5j/q0P8Ipb2+eW U2tkR5n8cnZBURtFcz+QvMNQ1Ioxt7Ugy4+d+yCqWmacLqTzpATCpyN3WQ+v0otbRbyQwwk/ZkOZ JO8rVvIqooVQAoGABSjF1Jc0tgSvqxelLRRXSUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVkhRY6o0bD/AEe67dga1qqala/arRgv+sT5 kPvWdRXV1uhMq2bHT71rOQ/un+aIn+VatZJH9q6WrrxcRdD3DCrenXf2u2DNxIvyuPQ1NN293p0E i3RRSEhQSTgDqa2KIby6Szt2lft0HqaraZauN11cczy88/wj0qCIHVr7zmH+jQnCD+8fWteso+++ bp0FuFFFFajCiiigArB8Srj7O/oTW9WP4kXNnG3o9Y11emyZbGpA2+3jb1UGpKqaY+/ToD/s4q3W sXdJlIKKKKYBRRRQAUUUUAFZuuTeXY+WDzIcfh3rSrntbm8282L0jXH4msq8rQYpbF3QYfLsi/eR s/hWpUVrF5FrHH/dUCpaqnHlikC0QUUUVYwooooAKKKKACiiigAooooAKrXt4llDvbljwqjqTTru 6js4DJIfoO5NU7K1kuZvtt4PmP8Aq4+yis5Sd+WO4mxbK0beb2+I80jIB6IKijDaxd+YwItIj8o/ vmlvJX1G5+xwNiJeZXH8qSSZrgix075Y1GHkHQD2rJ226fmyR91eSXMps7Dr0eQdFFVhCJG+wWRO wf6+b19qklxABp2nj963+sf0HvWlaWkdnAI4x9T3JoUXN6/15f5j3HwwpbxLHGMKo4qSiiulKxQU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAZQ/4l2rY6QXP5BqS6B02/W6QfuZTtlA7H1q3qNr9rtGUffX5kPvUdpIupacUlHzY 2OPQ1g42fKvVE2LwIYAg5B6GszUZnuZ1sLc8tzIw/hFV49QfToZLSUFpk4i/2h2q/ptmbaIvLzPJ 8zk/yp83tPdXzC9yzBClvCsUYwqjAqSiitkrFBRRRQAUUUUAFZuvLu00n0YGtKqWrru0yb2Gf1qK ivBiexHoT7tMUf3WIrRrH8PN/o8qejZ/StilRd4II7BRRRWgwooooAKKKKAGswRSx6AZNc5bKbvU Iy3PmSGQ/QdK19YmMVgyr96QhB+NVNIhH2yZ/wCGJRGP61z1femokvV2NmiiiugoKKKKACiiigAo oooAKKKKACori4jtYWllOFH60s0yQRNJIwVV6ms2CJ9VnFzcArbqf3cZ7+5qJytotxNi2tvJqE4v LsYQf6qM9vc1JqV46lbW25nk7/3R61Nf3q2Nvu4LnhF9TWNaQzX0jhGI3n99N7f3RWMny+5Hdiem hNEjSr9isTiMf66f1PtVqeRNOhSzslzO/Qd/qaluJodJtFjhTLnhEHUn1o06xaHdPcHdcScsT29q ai0+Vb/kFiSwsVs4jk7pX5dz3NW6KK3SUVZFBRRRTAKKKKACiiigAopskixIzyMFVRkkngVgXPjC 0icrBFJMB/FnaDWc6sKfxOwm0tzoaKxLHxVZ3cgjkDQOeBv6H8a26cKkZq8XcE09goooqxhRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFZEjDS9TMjHFvOOfZq1 6xNVDatKbODG2P5nb39KyrOyut+gpEEsM99IdTUY8k/ulI6gVuWtwt1bpKnRhyPQ1BpU4nsVXADR /Iy+mKrR/wDEr1Exni2nOV/2WqIe5aXR7iWmprUUUV0FBRRRQAUUUUAFV75d9jOvqhqxTJRuhceq kUpK6sBi+HmxNMvqoat2ud0Q7L9B/ejI/I10VY4d+4THYKKKK3KCiiigAoopCcDJ6UAZGpyh7+ND 9yBDK317VZ0aIx6erN96QlzWVK5njuJR965lEa/QV0MaCOJUHRQBXPT96bkStWPoooroKCiiigAo oooAKKKKACmySLFGzuQqqMkmlZgilmIAHJJrJ+fWZ+62cZ/77NROVtFuJsI0fWJxLICtoh+Vf759 a0ppo7S3aSQhUQU793BF2SNB9ABWA3meI7zC7ksIj1/vms2/ZrTWT/r7hbEcMc+u3hmbKQDgH29B W3LJBpdnwAqrwqjqTUhMNha54SJB0qhawvqNwLy5GI1/1UZ/nSjHk0WsmFrElhaSSym9ux+9b7in +AVpUUVtGKirDSsFFFFUMQ8A1zdhrV2LnEyzTiVWZEVAOQ2OD6Y9a6Q/dNcdDdRJF5Mny/uWjdmj JWNt5IDY9a5cRJxas7ESdjUuNUvrl5EsoWgeBN7rKoyx7Ac4x702K7v4LuEXFwWaSJ5HQqoRcDIA I5rKeZWV1aVfINuYUmWJljDZzgdzT7S1bUC8kEUEyxQIp80NwQOQMd65/aSlLR6+pN2SJrF2qR/a L9lWSJZMJEGckkjao9K1rbVXhtbv7U4ka2UMHxtLgjIBHY+tc4GimWE/aXtmjiUCQIdquCeCRyDg 1YZUunkkxbyZjUebcKymRgOWGP60oVZrZ/iCbF1dtXuzDayDzBMol2xgDHsfYe9Yc8EtrKY50ZHH UGttL61KhXmRTLbJEd6MQjKejex9qqXeoRLMi+XbXapGEBKMqrz25yfxrCqoy95yJepFNo9zGbZV jaRrhNwAxx7flW/pWq3VnB9iurS4lni6Bcfc7fWsuO6tjDGrXIjMlqYGIU5iO7PPsfapreSF7eS2 S7JWG1ZWn2nHLA4HfFXStCV4P8UNabG7/bybvJ+yXH2r/nhtGceuemPes+91q6N1IU8y2S3jV3id ASxLYP4Y9KpedF5Hlb28jyRF9q2Ns3bt231x2prXUSIsaFptkKojbCPNIcEhc9hW0q0mt/6/r5Dc mb515IgHubW4ghb7sjLkH0GByM+9JJrkkShn065VWIUElRknp3rE+2W8M00schuXnlU+VsYEfPn5 s8ZHQUl7CbbTbxlmd3luEKgoykHJPfqfpVOvOzs/yHzM3E8QQSSxosMuGYI7YHyMf4T78dq1q52w gW41OA7Cu1ftUyngiRhgDH4E/jXRV00ZSkm5FRbYUUUVsUFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRUVxOltC0shwqihuwFbU7w28Yih5nl+VAO3vUlhZiztwnVzy7epqtpsDzytfXA+ d/8AVqf4VrTrOC5nzv5CXcypP+Jdqwk6Q3PDezVdvrVby2aM8Hqp9DSX9qLu0eP+Lqp9DUel3Rub QB/9ZH8rj3pJJNwezDyE0u6aeExTcTRHawP86vVl6jG1ncpfwjgfLKB3HrWlHIssauhyrDINODfw vdAuw6iiitBhRRRQAUh5paKAOasf3eow+0rJXS1zUn7q9c/3LkH866WufD6JomIUUUV0FBRRRQAV U1Of7PYSsPvEbR9TVusvUv8ASL61te2d7/QVFR2joJ7Fe3g/06zt+0EfmN9TW5WZpX765urrsz7V +grTqaKtG4RCiiitRhRRRQAUUUUAFISACScAUtZNxNJqk5tbYkQKf3sg7+wqZS5RNiSO+sTmKIlb RD87j+P2FaYEVrBjhI0H4AU1VhsbbHCRIKwL67m1OVYogRGx+Re7e5rKUvZq71kxXsOuJ5tfu/ss BKWqnLt61uxRRWVsEQBIoxUdhZJYWwRcZ6s3qapSu2r3JgiJFrGfnYfxH0pRTh70tZMNgRW1i58x wRZxn5R/fNawAAAAwBSRxrEiogAVRgAU6tYR5d9xpBRRRVjCiiigApNo54HPXimySpEu6R1VfUnF Z8msozbLOJ7h/UDiplOMdxNmltXGMDHpiqtxqNraZDOu7+6vJqlLFeTIXvrlbaH+4hqvDtJI023G B964m7fnWUqr6L+vQTZJc6pO0ZMcKQRH+KQcn6CsqZ3lbdKzue270+narqQm4nK25NxN/HO/3V+l a9npsVqCW/eSt952rHknVe5NmzGXQzqelbmYJLndEcfz+tc7c6bd2blZ7eRcdwMg/jXo6qEUKoAA GABS06mDjNLWzG4Jnnljot7fyARwsiHrI4wBXVr4atBbxRbpRsXaxVseZzk5rYoqqWEhBa6goJDQ ihduBt9MUu0ccDjpx0paK6iyG4tYbqB4pUBRxhuxrObw5byY865u5Cv3C8udnuK16KiVOMviQmky rY2EVgjiMu7OdzvI2WY+5q1RRVJJKyGFFFFMAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKyHJ1a+2D/AI9YD8x/vGptTuXJWzt/9dL1I/hFW7S2S0t1iToOp9TWUvffL0W4tyUAAADoKWii tRhWVN/xL9VWYcQ3Hyt7NWrVe+thd2jxHqRlT6GonFtaboTJnRZEKMMqwwRWZYO1jdvYyn5T80RP celWNLuTcWu2T/WxHY4o1O0NxAHj4miO5D/SpfvJTiHmXaKrWF2Ly2V+jDhh6GrNaJpq6GFFFFMA ooooA5zUF23V76go9dBG26JG9QDWLqSZv7lf79vn8q1bB99hA3qgrnpaTa/rclbliiiiugoKKKKA CsPzsy3972QeWlal9P8AZ7OWTuF4+tZDwldPs7X+Od9zVhVetv67ImRqaXD5GnxKepG4/jVukACg AdBS1tFWSRQUUUUwCiiigAoorMvbuS4m+xWZ+c/6x+yiplJRQm7Dbu4kvpzZ2hwo/wBbIOw9KuIk Gm2mMhI0HJPemxx2+lWZycKOWY9WNUDuv83d7mO0j5SM/wAX1rK7jq/i/IRDdXDXa/aLgFbcHEUX eQ1oaZYmFTPOB58nb+6PSobGBr64F5OuI14hj7AetS6heOZBZ2nM79SP4BUxSXvyEu5HeXEl7ObK 1OB/y1kHYelaFvbpbQrFGMKv60yys0soBGnJPLN3JqxWsIv4pblJBRRTJJUhXdI6qvqTitBj6KzJ NZV2KWcTzv6gYFN+x397zdT+Sh/gj61n7RP4dRXLVzqdta8PIC391eTVCPVbjUpXisRGm37xZgWH 4Vft9NtrUZSMFv7zcmubtYpxOssM7IvlyMxRV3Ab8YGfX1NY1ZzTV/wJbZsnTII8Talc+Yc9Xbat MOsQeb9k0tEkl9uAP8ayrlRL5rX000yC2ZowwXfGcjOccZ6YNAdoTZ/2dbvI0UG/G1RgsMBieprJ 1bP3Vb8xXNJoYFZptTulmlTrErfd9sVIkFxqmN4+z2Y+7GvBasiO2jd7RoGeOT7OZJW2qS3PbP8A Fn1rRt9Qu7f5Ns10HQsgYL5kZHHzYOCKcZJ/EtP63BM14Bbw5t4CgKDJQHkfWp65GIGIWssUskFw 0cr3Em0E4B+b8c9KlW9unVCmoTrbkOWZ418xWUZx6EVpHEK2w+Y19Z1iPSbcMRvmf7ievufauQn1 /Up3LG6dAeix/KBVq6thfSJdTXc7W4jYsZFG9dvYAcdxUcVnDHumt2Z4ZraQr5gG5SOOa5K1SpUl o7IiTbH6f4ovLWQC4c3EWeQ33h9DXZ29xHdQJNC26NxkGuHfSrcmW3hmka7hTcwKgIemQO/erayn T7S6htL+5D2uN6bV2kkgHHeqoVp07qeqHGTW52VFcrJf6ipwlw7iN0WLCrmbdzz+HpUl5qU5eaaa e6tI1dUWFFUscjOf0rq+sx7F8yOmormRdX8szwvc3BWLbtaCNQWBGQzE8D6Uk17dxtIl1fSosUpi VoYxluM7mz2A9Kf1hdg5joY7y3lneGOaNpU+8gbkVNXHRCSLTY76OcqIvN3yRKNz5bjGe3v2q2ku oPBGXvpVmeLeDtQRjjIB7596mOJvuhKR0aTRyMypIrMhwwByR9afXOaKipf25tA4R7YNPuA55OD9 c5ro62pT543KTuFFFFaDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKr3l0lnbtK3Xoo9TU5IUEk4A6 msmEHVb7z3H+jQnCA/xH1qJya0W7E2T6Zauoa6uOZ5eTn+EelaFFFOMVFWQ0rBRRRVAFFFFAGVcf 8S/VEnHEM/yv7H1rVqC9thd2rxHqRwfQ1BpVyZ7by5P9bEdjA1mvdlbuLZleYf2ZqInX/j3nOHH9 0+taoORkdKjuYEuYHiccMPyqnpdw677Of/Ww9Cf4lpL3JW6MNjRooorUYUUUUAZN+v8AxNoR/wA9 ImWp9FbdpkY/ukr+tR6l8uoWL/7ZWl0U7Yp4/wC5Ka546VX/AF2J6mlRRRXQUFFFFAGZq5M0ltaL /wAtHy30FIoE+unH3LePA+tJCwn1i4nP3IF2j696doyl45rhusshP4Vz/FL5/l/wSd2adFFFdBQU UUUAFFFUNQvmjYW9sN1w/Qf3feplJRV2Ddht/euZBaWfM7dT/cFPijg0izLO3PVmPVjTIo4dHtWl mbdI3LN3Y+gqO2tZdQmF1ejCD/Vxdh7msru/n+RIkMEmpSi6vBtgXmOI/wAzTTnV7vavFnCecfxm pL6d7ucWNqcf89XH8I9Kmnmh0mzVEXJ6IvdjSstb7dfMAv737IiwwLunfhFHb3p2n2ItIyzndO/L sahs7cW267vnUTvySx+6PSkk1kOxSyhed/UDAp8yvzS+SDzZp1UudTtrXh5Azf3V5NVfsd9e83c/ lIf+WcdW7bTba15jjBb+83Jq+actlb1HqVPtWoXv/HtCIIz/ABydadHoyM2+8le4f3PFadV7q9gs 1zM4B7KOppOCWs3cLdyWONIl2xoqr6AYqtd6nBafKTvk7IvJqr5l9qfEQNtAf4j941btNOgs+UXd J3duTRzOXwbBe+xU8i91Lm4Y28B/gX7x+tUTot5bKSZrXyI0ZAsgOJFJzhv/AK1bV5fw2SZkOXP3 UHU1TSzuNScS3xKRdVhH9aynTi3bdktIxrSxurqZ2t7e1EWwxFApCEH36k1o2fh7cc6ksUmyNY0C FuAO5rcRFjQKihVHQCnVUMNFb6jUUc9/Yl9GyJE1o0cSsgMgbLoTnaw/rUlp4djZ999FAFVdqRQZ AHuT1JrWuL2C1GZpFU+nf8qonUbq7yLG3IT/AJ6ScCpdOlF66+QrJFF9Fu7YqIZLUQxFtjS5ztbq h7YrOe5NpcrvFuIUikCJEpKbiO+eTmtCVfOm2NI97P8A3V4RasroTyx5mkVXyMKg4Ud6xdNy/hoV uxgXNzdWot5/IhW2ZCgiVTsIPUHPOaqPqkjv8sUUcYiaJI0BAUHqfrXeTWFvcWf2WWMNFjAHpXOz +DG8wm2uhs9JF5H4ioq4aqvg1E4voY8mryyRMPKiSV1CyTKvzsB+laF3dQTWVwtuFlmnC7ikDK+B yS/b8q0tP8JQ28gku5PPYHIQDC//AF66AKB0AH0q6WGqNPndhqL6nN6ZZR6kIY5QZrS1jKhypUO5 PbvwOKhuIUtryawt7VJPNmQrHKGK428nPsa6rpRW/wBXVkupXKYDaPqGDvazuN7eYRIrARtjHGOo xjrQdJ1FpJJJBZSmRw+xw2FYDGR/hXQUVX1eAcqOcXRNSUpmW2cJvyCDiQN1B9qQaFelI0kWxdlX YJmUlkX0x0OOxNdJRS+rQDlRi6fpF1aXsDu8JigjMYZchpF7AjpxW1RRWsIKCshpWCiiirGFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRVTULwWdvleZX4RfU0m1FXYFbUJnup1sLc8nmVh2FaEMKQRLHGMKow KrabZm1hLSczSfM5/pV2ogn8T3Yl3CiiitBhRRRQAUUUUAFZV1/oGppcjiKb5ZPY+tatQXlut1av E38Q4PoaicbrTcTJqztUgdCl7AP3sX3gP4lp+k3LS25ik/1sJ2sKvEAgg9DRpUiG6I7edLmBJYz8 rCpayYCdM1A27f8AHvMcxn0PpWtRCV1ruCYUUUVYzM1n5VtpP7soo0/5NSvo/Vg1O1wf8S8t/dcG o7c7dcf0lhBrnlpU+79Sepq0UUV0FBUVxKILeSQ9FUmpazdZctDFbr96ZwPwqZy5YtiZVQm20CSQ /wCsnOfzrVsofIs4o/RRmqN+ge5srNfug7iPYVq1nTjZ+mgkFFFFbFBRRVS/vls4wFG+Z+EQd6Up KKuwG6hffZgIoRvuJOFUdveoI0i0m3ae5bfcSdT3J9BTECaZGbq8PmXUnQd/oKWCDL/bdTdVb+BG PCisG23fr+RI61s5LyYXd8P+ucXZRU2pXrQKsEA3XEnCgdveqt34giiU/Zo2lboD0GaqxabcSB73 UrjytwyVXqB6VLmkuWGr6sV+iLSXVnotqRJIJJjy23kk1Ut01HUbn7V5Yjz9wyfwj2FS6bpkdzML lotsCn92rclvc1vU4Qc0r6IErmbHo0bNvu5HuH/2jxWhHGkShY1CqOwGKdTXdY1LOwVR1JNbxhGO xVrDqjmnit0LzOFX3rPk1R7hzFp0RkbvIfuinQ6TvcS30hnk9D90VPtL6Q1/IL9hhvrq/JSwj2R9 5X/pU1rpMULeZMTNMerPzV4AKAFAAHQCmTzx28ZklYKo7mjkXxSdwt3H9KzrnU2eU29gvmy92/hW oi9zq5xHugtO7d3q6i2umQYysa+pPJqXJy20XcL3IrPTFhfzp2864PVj2+lXiQBknAHrWY2rSXDF LC3aQ/324UUg0y4ujuv7kkf884+BRGSStBXFfsTXGsW8TbI8zSf3Y+f1qHGpX3Ui1iPYctVsJaab FuwkSjv3NUzd3eokrZqYYe8rdT9KUr7SfyQPzGPDp+mHMmZ5z0DfMSfpTxb3mpYNwTb2/aNep+tW rTTIbQ78GSU9Xbk1cpxp330XYLENvaxWseyFAo/U1NRRWqSWiKCiiimAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAMkkWKNnc4VRkms2xja/ujfTD5BxEp/nSXTtqV4L SI/uYzmVh39q1ERUQKowoGAKy+OXkhbjqKKK1GFFFFABRRRQAUUUUAFFFFAGVeD7BqUd2v8Aqpfk k/xrUByMiorq3W6tnibow49jVbSbhpIGgl/1sJ2t9O1Zr3ZW7i2ZLqFoLy2ZOjjlD6GmaZdm5g2y cTRna4/rV2sq+Q2N4t9GPkb5ZQP50p+6+f7wempq0U1HV0DKcqRkGnVqMpauu7TJvYZqmjY1HT5P 78O39K0r5d9jMvqhrI3YttLl/uttNc9XSV/T8yXub1FFFdBQVlj/AErXT3S3T9TWlI4jjZ26KMms zSz5djPdydZCX/Cs56tL5iYtr/pGtXE3VYhsFalZ2ixlbLzW+9KxY1o0Uvhv3BbBRUcs0cC7pXVB 6k1l3fiCONT9mjaU9ATwKcqkYbsG0i/fXqWUO5vmduFUdSayPtkNgWurxxLeP92Nedvt7VVnguJC LnUJT50n+rgTr/8AWrU0rRktiJ51DTHoDzt/+vXPzTqS0RN22UreDUb6f7SyCNj91pP4R7Cr39lQ RKZ76VpioySx4rU6VkyMdXu/KUkWkR+Y/wB81bpxgu7Haw2zhF3N9slRY7eP/VJjA+tO+bWbnuLO M/8AfZomdtSm+yW3y20f+scd/YVqRRJDGscYAVRgCiMebTp+f/ABIcqhVAUYA4AFBOBk9Kp3eqQW x2LmWU9ETk1WFreaid12/kw/88k6n61o6ivaOrHcluNWQP5Vohnm9F6D8ajTTZrthJqMpI7RL0FX 7e1htU2QoFH6mpqXI5fGFu4yOJIUCRqFUdgKfTJJUhQvI6oo7scViXWuSXTm30qNpG6GQDgfSnOp GC1BtI0b3Uo7T5FHmTHoi/1rMd4/NE2pS+ZJ/DAnIX60610O4Yl7mYoW6heSfxrVttPtrT/VRjd/ ePJrK1Spq1ZC1ZSEuoXgAgiW1i7M3XFSw6NCrb7hmnk9XPH5Vo1Su9ThtTsGZJT0ROTWjhGOs3cd l1LYCxpxhVH4AVnTaqZJDDYRmaTu38Ipgs7rUSHvXMUXaJf61pQwR28YSJAqjsKLyltog1ZRg0rf IJr+QzS/3f4RWiAAAAMAdhS0VcYqOwJWCiiiqGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAVR1O8aCNYYeZ5eFA7e9WbidLaBpZDhVH51R02B5pGvrgfvJPuA/ wrWc237q3E+xasLNbO3CdXPLt6mrNFFWkkrIYUUUUwCiiigAooooAKKKKACiiigArKvQbHUI7xf9 W/yS/wCNatRXMC3Nu8TdGH5VE48y03E0SAggEdDTZI1ljZHGVYYIqlpM7NC1vL/rYDtPuO1aFOLU lcFqZenSNaXD2Ex+7zET3FalUNUtWmiWaHieH5lI7+1T2V0t5bLKvXow9DUw918j+QLTQllG6Jx6 qawP+YDE3eKb+tdDWDGudGvY/wC5ITUVl+TFI3lO5QfUUtQ2b+ZZwt6oKdLPHAu6V1Qe5rZPS5RT 1mUpZeWv3pWCCo9SH2bSUt06tiMf1qldaib7VIVs4mmEI3dMDNNmtrvUNUhgvJQqqN5SPtXLKpzN 8uvQhs021C1sIUiL7mVQNqcmovtGo3v+oiFvGf4361cttPtrX/VRDd/ePJqWedLeFpJWwq1tyyt7 zsvIqzMyTT7a1jNxfyvOw/vHgn0Aqpv2OtxNGDK3/HvbqOB7kUTXL3M6yyIWY/6iD+prTsNPMLGe 4PmXD9Sf4fYVilzu0VoTvsJY2DI5ubo77hvyX6VoUVR1G9NsgjhG64k4RR2966PdpxK2IdQuHuZh Y2p+Zv8AWMP4RUcp+7pthxgfvHHYd6hmmXSbfyVcG7l5d/SkshcyReXYoY0b7879WPtXO5Xlbr/W n+ZNzQM1ppFuse7kfwjlmNQZvtT6Ztbc/wDfRFWLTSobZt7ZllPV35q6zBQSxAA7mtlBta6LsVYr 2mnwWY/dplu7nkmrNZ02swI2yBWnk9EHH51H5Oo33+tkFtEf4V+9QpxWkFf0C/YuXOoW9oP3sgDf 3RyazbrWLgx7oYvJjPR5Op+gpHW1spPKtYvtN2e7c4+tWrXTCZPtF83mzdh/CtZtzm7L+vmLVmbb aTcao4mvpH8rqFJ5Nb8FvFbRCOFFRB2AqWms6opZ2CqOpNawpRhr1GlYdUNxdQ2ib5nCjsO5qjJq cly5i06PzD3kP3RT7fSVD+dduZ5vVug/CjnctIBfsRedeanxADb25/jP3j9KuWmnwWYyi7nPV25J qz0pacYJO71YWCiiirGFFFFABRRRQAUUUUAFFFQ3F3BaJuuJkjB6bjjNJtLVgTUVRh1nT53CR3cR Y9BnGfzq9RGSlswuFFFFMAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoorN1O5dmWztz++l6n +6KmUuVXBuxE2dWv9o/49YDz/tNWsBgYHSorW2S0t1ijHA6n1NTUoRtq92JIKKKKsYUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQBlX4NlfRXqj5G+SUD+dagIYAjkGo7iBbiB4n6MMVT0mZvLe1l/1sB2/ UdqzXuzt0YtmaNZL/wDEr1LeOLa4PPorVpSzxQLulkVB7msq8v11CJre1t3mz/FjAB9aVVpddQZs Z71z322C3Oowu24ux2heaWxgur0tbXtyyGHgxr3H1qewtIbbVrqJEGNgIJ5NZSlKdmlYm9yPTptQ u7GJIFWGMDHmN1NXI9HhUmW6kedxyS54/KjRDi0dP7kjCpdWn8nT5Mfef5R+NVGK5FKWo0tLsg0W MN59yFCiR8KAOgFGm/v7+7ue27Yv0FTgCw0j0KR/rTdLQW2lo0hC5BdifenFWcY9tQLksqQxtJIw VVGSTXO3V3JqFyu1Cwz+6i9fc0Xt7LqlyIYFJjB+VfX3NbGn6clkm5vmmb7zf0FQ26ztHYXxCafp 4tQZJTvnb7zensKvUhIUEkgAdzWZda0ibltV85wOW/hH41teNNFaIuXt5HY2zSykADoPU1za6jMZ mlij8y6lOFJHCj2FP2NdZvtTcvGDiKLoGP8AhVm1nt7RjPN+8uW+7HGM7B6VzTm6jWtl/X9Ihu5Z 0/Q1jPn3rGe4blt3QVoz3UFqmZZFQDoP/rVQ3alffdAtYj3P3qlg0e3ibfLmaT+8/P6VtDRWpr7y l5ER1Se6O2wt2Yf89H4FKuky3BD39w0n+wvCitMAAYAwB2FVry/isl+c7nP3UHU1TgrXmx27j0it 7KIlVSJB1NUHurjVGMdnmODo0p7/AEojs59RcS35KRDlYR/WtREWNQqKFUdAKSTn5IW5BZ2MNkm2 MfMerHqas1Xur2GzTdM4B7KOpqjm91Tpm2tj3/iYVTko+7Ed7aFi61WKBvKiBmmPRE/rUC6fcXzC TUJMJ1EKHj8au2tjBZriJOe7HqasUuRy+P7gtfcZHEkKBI1CqOwFPoorUYUUUUAFFFFABRRRQBkR 6/GdQe3lVI41LDzGkH8PXI7VJda7bRQq1sRdM2cLGw4AGST6VkeVE96PMVWfzpygIB3MMYHPX8aE klS8jxBIl1JFIMvGis4xx8o964fbTta5nzM0bfXnuJoCLYLBO21GMg3n32+lJJ4hCSbxCn2QS+X5 rSgEnOCQO4FYsl25h0/7RJKm2JmzFECwbJH8qfbPJPb6fArKYw0pUPGCSF6cetSq83pf8vL/ADDm Zt3euxqFWw8u6kYMTiQAKAMnNcRc3ct7O09xIXdu57ewrqPLb7VZymM+e0coPmoqluOAQOKqx+ar Qy3kMaXoimJUoBlQPlJH1zWdfmq7v+tP8xSuznmjKxJISpD5wAeRj1Hauk8Ma2wY2d1JlApaN2PT HUVDas1xbQTbEe7ZJmjBUfM+R2+maqzxCS7H29XhumQfJboCSefvDsaypp0mpxZK01R1FnrsF1P5 TjyC4DReYw/eA9CPyqd9X09GZWvIAynBG8cVzkkkt09nBLjy7m1CRvtAAfqOfqBTojLsvEsYlkkt zHGp2BjxncQD3zmutYie2/8AVy+ZnSyajZxQpM9zEsb/AHWLjB+lJLqVlCqNJdQqrjKkuOa59I0R 7hreMm7GzzEhRXKEr82AeMZ64otlUXF15Nq6NvUMI0SRl45BXspPpV+3l2HzM6hHV1DIwZTyCDkG nVl6Cvl2k8W5WEc7qCv3cdePzrUrphLmimUncKKKKoYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABTZJEijaSRgqKMknoBTqoa5/wAgW6/3P61M3yxbBlm2u4LyLzLe VZEzjK+tJNe20D7Jp40fG7azAHFc3HFLbmZvtVwI2lwBHIiEnAyST1+lRuls237UXuZTeBTKpX5u Bj8Mdq5vrErbakcx0ceq2U0MksdzGY4/vtnpU9vcxXUIlgkV4z0YVys0zzrelYnMckiIJC6/IFb0 /lUltFKEmEN3dFxK/wAkTqCvuVP3s+1CxEr7BzHQJqdnKJTHcRsIRl8H7ork9T8TXV3Ky2rmCEHj b94/U0ttaiby0lnk+e3yYwwQv8x+XJ6etU7nSZknmEMb+VFyfMIDAYz68/hXNWrVZxVtPQmUm0Rx avfwuGS8mz/tNkfka63QddGqKYpgFuEGTjow9RWFfWtibqaZllSGGOMMiEZZiOMenFJDZ29m0l2k 1yECI8RjID4bIwfyqaUqlKe90JNpnb1Xe/to7pbZ50EzdEJ5rnZbyeOAvLeXLWyhTH5eFkbcM4Y+ 2KiMc0kr7bhmeSaFkldRuAIOM+9dksT/ACovmOvorl4Lu4l3fZL24xuCSeftbg5+ZcdDweKh+1mS OKSO/v1V5hE2+QcZHB4FP6yuwc5017drZ27SNyeij1NV9MtGjVrm45nl5Oew9Kx7X7Ve6pafa5CZ AWZoz90KvAOPUmuoqqcvaPm7DWuoUUUVuUFFFFABRRRQAUUUUAFFFFABRRRQAUUVHNPFAu6WRUHu aG7ASUVltq7TMUsbd5m/vEYWk/s+8vOb24Kr/wA846z9pf4VcV+xYudVtbc7d+9/7qcmsi8lvTcL exRG2jPyMx6keuK27awt7UfuogD/AHjyfzqWeFbiB4nHysMVEqc5rViabKMGjwEiW4drhzzljxWg iLGoVFCgdgKoaTMwV7SU/vIDj6jtWjV01G10hozNThaGRL6AfPH98D+JaZBMsuuLJGcrLDkVqkBg QRkHgiuO+0yWurKIcgAsoU9qxrP2ck+jZMtDf0shLy9iyM+ZkDNJff6TqltbDlU/ePWGgeC9KtMk cq5yWcCpLCaS3uPtOGKL98+v41mquii11FfobOtvmCKDOPNcA/Ss29vJNSnWysgTEvGR3qveXU2t 6jFDbps2jnn9a2IvseiQCPO+Y9QvLGm5e0k3e0e4blnT9OjsIsD5pD95qbdarDA3lxAzTHoic1m3 N/Lcf6+X7PEf+Wacu1PtY7ll22FsLdD1lk5Y1p7T7MP6/rzHfoiSSCa5Hm6nOIIeoiU4/Os28v45 QYLGI/ZYz87AYDGpr20US+S0zTTnmR2PCCrGnWS3ZRtu20i+4v8AfPqayalJ8q/4ItyO00q41Irc X0hSMDEcSDGBWzb2Vvaj9zGqn16n86n6UtdUKUYepaVgpKZPPHbRmSZwqj1rMLXOrnCboLT1/ien KdtFuDZLc6k0kpt7BfMl7v8AwrUlnpiwP507ebcHq7dvpU0ENvZRBI9qL3JPWqV5r1tASkLLLL7H gfjUO0feqMXmzSkkSJC8jBVHUk1mvqM96xj06P5e8rDgfSqIuLe4cS6hcmU9oowcCry6zCqhLe1m ZR0CpgVLqqXWy/EL3JrXSo4X82djPMerN2+lX6y/7SvX/wBVp7/8COKPM1eTpDDGPc5qozjFWivw C6NSisv7Lqkn37uNP91aP7Jnf/XX8zew4queXSI7mmWVfvED6moXvbaP708Y/wCBCqY0K26yPK59 2qZNHsk/5YKfqSaL1H0QaiPrNkn/AC2B/wB0E1EddtzxHHM59lq6lpbx/dhjH/ARUoAHQAfSi1R9 Q1Mz+1bl/wDU6fKfduKPtGqyfdtYo/8AeatSopbiGAZlkVPqaTg+sgt5lDydWk+9cQx/7ozR/Zl0 /wDrdQl/4CMU59bhLbbaOSdv9kcUzdqt191Y7ZD68mo9x7XYtCFvDViCzzySNnklnwM+tV5bTQ4M ja80h7q7M351oLoqyHddzyzt6E4FXYbSC3H7qJF9wOaSop7RS/EXL5GHa2hVi1jpoTIxvnYtgewN I/hcyB5HkXzSdwVcgA/0ro6Kr6vBqzHyow28L2xs2RWf7QQcSFz1+lcfcwT2dw0VwGSQcHJ6j6+l emVDc2dveJtuIUkH+0KyrYSM17mjFKCex5puIx8x46c9K6fwvpEvn/b7lSAB+7DdTnvW3Domn27h 47SMMOhIz/Or9RQwfJLmmxRhbVmFdaA0d6lxpywLweJckI395R61GfDsqMIY5UNs5QykkhyV64x6 10NFdDw9N9CuVGc2g6e0SILcLs6MrEN+fU01vD2nMqAQbdoxlWIJ+p71p0VfsofyodkRwW8VrCsU CBI16KKkoorRK2iGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFV7+2N5YzW4baZFwD6VYopNJqzAwP7EvsMXls5t7bjHLESqnpkU0+H7tVxHcW77pBKS8eNrj +7jtXQ0Vj9XgTyowv+EbjNiwbyjel9/nbTgHOcfSmrouoIwPnWbtuLhniJMZPXbW/RT+rwDlRzUm i39vC8gkt7gJHt8poyRIM55965i7uZLuYyShQQAoVRgKB0AFemVi6n4Ztb52mjYwSnklRwfqK5sR hW1+7+4mUOxyw1iffuaOBwUEbqyZEgHTPvVuwvprs3CmJJZZjGiIYsxgA9MDoBVqx8KR3P7xrwtG GIIRMHiums7KCwgENugVR+Z+tZ0cPVk7ydkKMX1MCTS9TjumB+zziYcq6fu+OgA7YqtNZanHIzT5 UM6uXjTO0r0A7YrsKK6nhYvqyuRHGySuFSUzRRhJA7pbw7WY/wB456/So7yeG8ijt4M+WsnmSSRW xUJ/wHOSa6XVjbxQfPCjyv8AKgxzmq1r4fWKEOJpYp25YqawlQlflWonF7Ednpv9ovJd3HnRhsJE PunaO5HvVr+xAPuXdwv/AAKjydUt/wDVzRzr6OMGj+1poOLuzkT/AGl5FbKMEveQ9Oov9kzr9zUJ x9aT+z79fu6gx+q1Yh1azn4WYKfRuKthgwypBHqK0UIP4fzKsjM+y6ov3byM/Vf/AK1GzV1/5aW7 fhWpRVezXd/eFjL36uvWK3b6Gj7Vqi9bOM/Rq1KKPZv+ZhYy/wC0L5fvaex+jUf2tOv39PnH0/8A 1VqUUckv5vyCz7mX/baj79rcL/wGlGvW38STL9Uq/NcRW67ppFQe5rOfVjcMUsbZpj/eYYWok3He X4C26kg12yPV2H1U0yXxFp8Y4lLt/dUGmf2XcXhBvplC/wDPOMD+dXIdKsoVwtvGfdlyaSdZ9g94 zP7XmvTiKSK2j/vOeamgs7AtvnuluJPV3GPyq8dNs2628f4LTDpFi3/Luv4E0eznvKzCzILzWLfT 3SOOIyLt3N5ZGFXOM1ckvreKJ5GlTCLuIBycfSuf1fT7aG7kRYwq/Zi2Tzg7gM1BeQ20HnotrxDg owt8Y6YJfPzA1m604t3sLmaNY+IlfesFncSPHzIpwuwepya0o7uJ4I5WcIJFDAOQDiuXvrlv+Jmr xQqpeMbvK5we/vVbfDHDcy70vTFGoQzREBOfQ1CxMovXX+n/AJC5rHRaiy2txDqEbKUztkIPBFTX OtWttMkZ3PuwSyDKoD0JNYIihEUk4iXPlxuIhEZFTcOWCZpjSpbR3vk2i7dsbskkXvzx2FN1pK7W lw5jrfPiyB5qZIz94dK4zxLfQzahstQoKfekU/eNTDT7V0aJVUMzfaFf0i9PyzTYESQ2vk2EUkN0 7eYxTO0Z6A/w4FRWqSqR5dvxFJt6GHFC88qxxKXdugHepLa8ltsort5bfeTPBrbtPKguNOiiii/e F90u3LEAnGDVK7trXzIQJRDZsmUmEe5nbvu965PZOK5k9f8AhiLBZztHMZULoXJ2v0HHWtm000zJ 50t1GiN/EGBJ/GqNusc9tYQeWksIkk2tsxvIHAP1p1vbrcmB57GNZGZ1EapsEgC56ex4zW9NW31/ pFI6C2t9PtV3o8RI6uzgmodR12K3j22mLiVgT8jAhQOpNYcFulwsEs9pHHOfM2wqm0S7RxkfX86S NA0UVxJbpbzvFKpVE2hlA4OK2deXLaKsVzdh9vd288gV5HKE7pCB8zn0rYGvwIBHDA5C8AZAxWML dFZoBbIlutv5i3IX5gcZ3bvrxillhXbeR/YovJit98cxTknA53d881EJzgtBJtGz/al5IFMdooDf dLyDBqC61LUoXEeIRK3RF+Y1jyWwltVkhjDfadohjAzsPV8Dt0rVt7j+zI/MksZd5+9I55P6VaqS lu7f16Du2OXR9QvWEt9dAN2QD7tOurWK1UC5v53btGh5NRya1e3i4s7OVE7yYz+VLaOLVt72FxLM ervzVfu/s/e7hoRwaG962+UPDCegZssa1oNGsbdQEt0OO7ck1D/bD97G4/Kj+2m72Vx+VaQVGI1y ovrbwp92JB9FFSdKzP7b9bO4/wC+aP7cX/n0uP8AvmtPawXUq6NSisv+3Y/+fa4/75o/t2L/AJ4T /wDfNP2sO4cyNSiss6/bqMtHMo91qJvFFkvAWZj6BaTrU11DmRs0Vz0niOaXiC3MY/vOMmovtSXH N5d3DD+4iYFQ8RH7IuZG5PqNrb58yZc+g5NVTq0s/FnaSP8A7TcCq0F3pFvjbExPqyZNWxr1kONz j/gNHtL7ySC/mM+y6ldf6+4WFT/DGOali0W1jO6QNK3q5zSf27Zf32/75o/tyy/56N/3yaa9l1dw 0L6RpGuI0VR6AYpQQSQCMiqH9t2X/PU/98muesWuIrkXVu0YEglZnYMcKG6kDqfSideMWktQcrHY 0m5S23Iz6ZrmLmWa+DC8uQsKwNJG8asuSO5HXI9KrrJBYz2U8RMsvlGV3VGLSEg4z7E/yqHibPbT 1FzHX7l3bcjd6Z5oJA6kDPrXHfIBY3Czxi7kJmeWRWzx2+nbFWLrzb6dPtksZj+zPJHJsZNpyOSv XIoWJ02/EOY6qsDWfEyWMrW9qqyzL95j91fb3NRLqt8yBUubbyfKMn2jY3IHB47EViHThMEczxpC IzI8xU8jdjJHcms62Ik1an/X9dxSk+hKvirUxJuMkZH90oMV0Wi+II9UPlSKIrgDO3PDfSuMuLRo ZmWM+egAIeMEgg/yq+mlzWmJ4p1+1QqJjHsbgdfvdCcdq5aVetGWuq6kqTud5SEgYyQM9K59tXvI C5aa2neNA7wKjKdpx36Z5qnqDPdLdTXE8L3FvGMRxhh5R3Dv39K9CWISWiNHI62k6VgNq17bvIDL bXLxAF4UUqcHuD0zyMiqupX17PZXELT27lcCWONWBQZHQ9/Q0SxMUnoHMjqQQRkHIpa5azubiwRo luraFDcNGisjH5uOBz05pbaWY3UF20he7e6aF4xnaFHBA7YHWksQtNA5jqKKKK6SgooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiuZ1Wa5TW3eHe/kmIKiyEde2Ohz WdSp7NXE3Y6aiufl1S8uNsINvGskgjaWGXcY/Y8dTWfchobSSWa+M0iTeVEVnPyDPp3NZSxKWyE5 HYUVjTa4SSLM27xphWmmk2qWPYepph1u7YkLbQQlG2N58uNzei4H61ft4BzI22YKpZiAAMkntXL6 r4rVg8Fkm4Hgysf5Clvb6+1aw8tFt7dJWKqGm+ZyDyorHnsYbbRkmfa1zI5GN5yuD029/euXEV5N Wp6LuTKT6FjSvEb2DsJIg8TdQpwRXY2d5Df26zW77kP5g+hrhE0zzdMgmhZWnllKBN3NaGki90mc Lbm3uEnOz5ZPlVhzz6Gow9apBpS1Qoya3OypkkixRs7nCqMk1iDXLwMgNtby+YSqtDLkBh2Y9qp3 93caj5UU/leQQ53W8pILBcgH6V1yxEUtNy3JGrYxtfXRvphhRxEp7D1rVrnLPWLyOzgzBAwEQbyz LiVlA6gYxUp1q9aNpEgtVATzPLeY+YF9SMUoVoJf8AFJG9RXMyeIb9d4EFuCiCQnJIKnpj35rRQ6 xKitmCPIzgjpVxrxl8KYcyZdmsLa4/1kKE+uMGqh0VYzutbiWE+gORSfZNUf716i/wC6tH9mXbf6 zUZfwFJpS+wHyDbq1t0aK4UevBpP7a8k7by2kiPr1FL/AGIG/wBZd3Df8CpkulafbruuJXA/2nqb VFtp6sNS3Hq1jKPluYwfRjg0ranZr1uI/wADmsR7WxuSUstPaU/3ySAKVPC0jLl5xGeyKMil7Wq/ hSYrs0J/Eenwj5ZTI3oimqEmvXFycQqYUPcLlqngsbrTh8lpbTgdwPmqymsxRnbc28kB/wB3ik5T l8crfL9Q16mfCYd2+S1urmT1ccVfXULoKFh011Xtk4FXYb62n/1cyE+mcGrFaQp2XuyGkZf2rVX+ 7Zxr/vN/9ej/AInD/wDPun61qU1nVBlmCj1JxV+z7yY7Gb9m1V/vXka/7q0f2beN9/UZP+Aip5dX s4eDMGPovNQf2vJNxa2csnu3ArN+zW7v82LQil8OR3Dbp7u4YkbTzjI9KX/hG7UxhJZrl4V6RtL8 o/CpNurXHVordT6cmgaMZebq6ml9s4FL2cXtD7xWXYqy6bpML5nupXxj5GmLA46DFQTx6bcyg29p cScYKoSFb61tQ6XZw/dgUn1bmrQUKMKAB6Cn7C/RIfKcxHoty7B4Y5LdhwHaY7lHp9KZdaC9knnt cyEMds2xjlgfU966umSxrNE0bjKsMGk8LC3mLkRg/wDCLQyOjw3UvlFccnJ2+mfSsrXbCbSZn+yy OlpN1VWOAfQiuk0qVojLZSn54T8pPda568jmuHnYBpPmJLAZHWuetThye6rNkyStoYazSqUKyOCn 3cH7v0p0Yln2wqzFc5254Hqa3bq001VjEdsDIYwWIcgA/SpNDtorq7mh2KqLHjKjHJrlVB8yjcnl 1sUls922GFpmTIIRWPJ9cetStHNBdCYyM8yKVK3DkHBGODWuNLuNMYXMLLMU6rjHFVdRv11l47a2 jznrkc5rodJRWujKtYxQjzzIZWnLqB+83Fse9ao0mG7ffHqZklIwTKxDEelaNvo1xp0e6zmBYj50 ccGqV3f2zEwzWQW66blOAPyoVJQXvha25XvdKls7YpK2YT92NZTtz6haZIb97AxCxaFGTaX3MVx7 L0GasNZi0CTC9EtweVjA3AVPI2qzhTewv5HdYuCfrRyLXdfiFjPsdRW3mQrCqGJCkSAkgE9WJ9a2 LaO3u5BLe3iTP2TdhRU1re6YEEWxYvVZF/rVk6dYXA3CKMg90/8ArVvTpu2jTKSLabNoEe3aOm3p TqzDoVuOYpJoz/stSf2dexf6nUGIHZxmujmkt4lXZqUVhTaneWRxJLbTeynmmjX7x0zHprn/AGuc VPt4LRi5kb9RTXMNuMyyon1Nc/8A2jNcti7uXtl/uolXLWDSSQTMsr+sjUlW5vh/EOa5M+txM222 iknb/ZHFJnVbrtHbIfxNaEXlBcQ7Nv8As4qSr5G939w7GYmio53XU0k7e5wKuw2kEAxFEi/QVNRT jCMdkFkJtHoKTav90flTqY8scf33VfqcVQxdi/3R+VHlp/cX8qqyarZx/enUn0HNQHXIDxDFNKfZ ah1ILqK6NDyoz/Av5Unkxf8APNP++RWf/aF9L/qbAgernFGzV5eskMI9hml7RPZX+QXND7PD/wA8 k/75Fc39kv7Usht18pQ6t++CFwzZG09iK1P7KuZf9ffyn2XinJoVoOX8yQ/7TVnOEp9Lf18xNXOe bMZaRosxtG0TRG43SEH+LPT8KLByxXeLuIxwrEvkPy2CTz+ddVHp9pF9y3jH1GasKqqMKAB7CoWF d7ti5DkbW31CNoSLCVhFG0e7eFY7jnKnsasyQX77C+myuixPGQ1wGZg2DnPXPFdNRVrDJK13+H+Q cpybadf/AGYpDYFIWiaNUMoLAk5LNWVHqKxxrbzwM0QiMUi7sE/NnIPbFeg1g6x4ZS/ka4tXEUzf eB+63+BrGthpJXpu4pRfQ5Z9QkV3FmXtYWAHlox59z6mrjaidQxElvK11Koj/wBcdmemdvrT18Ka kZNpWID+9v4roNG8PxaWfNdvNuCMbscL9K56VGtJ2eiJUZMyzpmpm4nnW0AM8YiA8wZTAHzH8qS+ t7mG2vJJNPKNKo82USgr1ByB74rraayq6lXUMpGCCMg12vCqzs/yL5DmBBJqFxcnToVXcdrXDSZT sTgepwKJtP1CVZxFYeVLL/rGMwKnnJCjtk10sMMdumyGNY0/uqMCpKf1ZNasfKclNpepXMiv9j2e XM0+DIvzZx8v14qe3stSW4jb7KYybkzBxKMKG+8CO/FdNRQsNFO92HIgooorpKCiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK57UYruPVZZILWSXeY2Uj7vy5yCe1dD RWdSHOrXE1c5R4byRwYYL9wsglZJgqgAHOB/eNNg0+4nuVjiiuYVNw03myRj5QR6dOtdbRWX1ZN6 snkOYvdPnjLQ3S3FzEzb0mgjXPTBUr/WkQXcMrvJaXcQkIZViCyAqBjawPAPHWuoop/V1e6Y+U4u WWzW3tpriGVGjlkdYo8YHzfdPpVF9UcJC8J2TK8jMdoI+Y9s12p0ixLTN9mQNMCHPrmuW1LwvdWh eS3xNAOeuGA96461GrBXX4ESi0QQasixRtOHeeOYycABXBGD9Ksadc2iXUFvaCYxtKZJGlwP4TgD H86q2fh7ULzaViEcZ/jc8V0qaNp+m6UyXMazAHczN1Zvapowqy1eiXcUU2YsMgtzElna3EkUjF2L gBnBGML9PWpUtpoI1S3sbxoQXLNIgDFiuAAB2962tIs8D7VIgUsMRoOiLWrXTTw91dstRORMc8SL LLY3f2mOLbtCgxnC43Z69O1LtjW0e8lDKWt9u4MpQnbjjvn2rraof2Hp3nGX7JHvPJ44/LpVPDNf Cw5Tnbdkjt7GC7G1iwZyDk+WvK5x7mukTV7J+k6j68U1LXTtLRiscUQbrnkmqctxDdkrZ6esx/vs uBRBOkrXVwWhqrd27/dmjP8AwIVXuNXtoTtVvNf+7HzWenhwTtuu3Cg/wRcVYXw7aR8wtLGfUNV8 1ZrRDvIXzNSvf9WgtYz3b71SQ6NAjb5y08nq54/Kmf2VcR/6rUJR/vc1BLLeWv3tRtz7MOaW2s03 9weptKqooVQAB2Apa51ddvQ21IUnP+wDUj6pq7L8unGMepBNV9Yh0v8AcHMjeqKaWFFPnOgHoxFc 8bu4lP8Aps1zGPRExU0B0cHMjOzesuaXt77fiHMPupdIckLGWf8A6ZAiq8ceobv+JetwidvNPFbE Fzp6gCGSBfpgVaWWN/uup+hpezUtb/cFrmDKNex+8IK/9MsZpkX2Hd/pxut/fzOldJTXjSQYdVYe hGaboed/XUOUqWiafgfZhCfp1q7VCXRrOU5Eflt6ocVF/Z15b/8AHresQP4ZBmrTlH7P3D1RqUVl /bNRt/8AX2glUfxRmnx63asdsu+FvR1p+1j10C6NGio4p4phmKRXHsakrRO4wooqOedLeFpZDhVG aG7AYniF/JnheBiJmG1sf3auuLe30VlRxsKYyO5NVVtJ7qzuLsgmeYfIvotc1f61p2j74tSu/Icj IiClmJ/3R/WuO8uZtLcjqatsLTzE87cECfMeeWq94aAX7UuACz7h9K4OLx3o8jlWNxGM8M0fH6V0 9lfqtulzp93FKkq/fiOQPY+hrOKlTalJbCWht61qZhAtbbmeTjjsKqxaVLpUAvI5AJgMyK3Qj0qL T57a3aW9uC0lwT8oNDT3Oqz8IXA6IPur9apyUnzPfp5Be+pO+sNqMZETi3hH+sdj830Aogt3uojD ZwiOA/emkGWalfQJEAuVdXuF52Y+U+1X7bVrZ4T5zLDInDI3b6VUU2/3jsP1KyeHxaESWUzJMO7c g1KNTntCF1CAqP8AnonINK2tRu221hlnb2GBTSuqXgIbyreM9upq/dX8P8Ng06FpmsbyLe5hdPU4 4rIuBYQufsdxMsnYRcipW8MREbvPk8317flSxzyaRhbiCJo/+ekeM/jUy5n8at5g/MijuNc2Hy4g 69jIMGohK0j41Sa5j/2QMLWquu2DKCs4J/u4OajfWYJRtjtpZh6bOKHGP89/xDTuS2Vvp2AbYROf UnJ/Wr/SuemtJbo5g00wn+9vx+lOSx1yNP3d2gH91jmqjUa0UfuGn5G8yK4wyqw9xmqk9lp55ljh X3zisZ1vEb/iYtdbe5jPFWrW30iYj94Wb0lYg0e059LfeF7jZoNJj5S5dG/2GJqv9pkTizurqT2Z Mit6KxtYxmOCP64zU4AUYAAHtT9i35egcpgR3eun7tsrj1cY/wAKSW71sf6yDYPWNc/410NFP2L/ AJmHL5nMicScXl3dqe424FWoLfSHwTPvP+25FbTKrDDKCPcVBJp1pL9+3jP0GKXsWuz9Q5RsNpZL /qYoT7jBq0FCjCgAe1ZzaFaHlPMjP+y1N/sq5i/1F/KPZuatOUfs/cPXsalFZezV4ukkMw9xij7f fxf66wLAd0NP2i6phc1KKzBrkK8TQzRH3Wp49Ws5Ok6j/e4pqpB9Qui5RTEmjk+5IrfQ5p9WMKKK KACiisLVvE8NjK0NugmlXhjnCrUVKkaavJibS3N2iuNj8Y3ivmSGFl9BkfrXR6XrFvqsRMWVkX70 bdR/9as6eJp1HaL1EpJl+iiitygooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKQnAyelVbTUrW+d0t5NzJyeCOPUetJySdmBboqvdX9tZFBczJGXPygn rUEGs2VxKUjlJIBYEqQCB1we9JzinZsV0X6KzR4g08jick9lCNk++MdKu29zFdwiWBw6HuKIzjLZ hdEtFFMllSCJ5ZG2ogyT6CqGPrL10zC0Xy87SfnxUN/4ktoLEy2x8yRjtVSCMH3BrkLrUbu8ctPO 7Z7A4H5VxYjEwiuVa3IlNbHW6XdPa6fNJMGMaY2D1PtTYbg61eokoCRRjdsznca5SHUbmFDGJXaI 9UY5BrodP1KytYBNb7pbhxhkbjZWVOup2i3oiVK50/TignAyeBWIPEQuD5dtEPNA+be3AqGSZJj/ AKbetJ/0ygHH511uvH7OpfMjUuNXtoDtVjK/91Oag36le/cVbWM9z96obedoxiw01h/tvxTLu8u4 XRby7jtt/ICKWOPXjpUOd1eT08tPxYrl2LSLeI+ZcMZn7tIeKlk1Kytht85Bj+FOf5VXXRY5MNcX Es2eeWwKtw6dawf6uBM+pGa0ipL4UkNXKh1nzTi1tZpT64wKN2rXHRYrdT68mtMADgDFLVcknvId jL/siWbm6vJX9l4FTxaRZw8iEMfVuau0U1SiugWQ1UVBhFCj0AxTqKKsYnWmNBE/3okP1UVJSZA7 0WAqvpdm/W3T8BioW0KzPKq6H/Zar5kQdXUfjTTPEOsqD/gQrNwg90hWRn/2Ls/1V3On45o+wagn +r1An/fWrxu7cdZ4/wDvoU039qOtxH/31U8lNf8ADisint1ePo8Eg9xij7Xqcf37JW/3GqydTsx/ y8x/nSHV7If8vC/rS91bT/ENO5X/ALXlT/W2E6/QZpr6vYzDFxE4/wB+OpzrViP+W/5KaY2tWB6s W/4AaTl/fQX8yo0ejzHdHN5LeqkimTzzWEPmW+oCdchVjPzMSewqeTUdKf70G76R1n3zadOIVt7d 1ZpkBJGBjPPesZtJNxav5EsvW2t3DwrJLaEqSRleuR14qnf63FeTxRrFM0Qb7gXmRvQVWW2tIFj3 oredI4OUdiMHGFx0NPtp1jGnosEbASSqGYHcMf1qHUm1yt/1oK7IvFXjYaR4ckktYmiv2fyI4pBy hxyfwFeaaVoDanm/1WSSRpjuwW+Z/cmu7isLW61O0uZbiJ3MmDbBTwGPPX6VftrW01DymNvHAFna MrHn5wBkD68USrznFRi7MOZtaHGt4Y06ceXHakMeAYyc1hxm78H6wkkbNLayH5h2de4I9RXqdp9m F9bSxQxiTzGT5I3VcY9+9V7a2tLkLdTW8axkGFkA4EhOAfyNRTlOOjd0wTaEgljlEc2Q0LANweqn mto6wlvARZ2wSNRnc5AH/wBesVbWCztpQLZJZbZVVkYHGWPJIHpwKW5it7aGec2qMxjjZYpCSIy3 UURnKF7f1+Ak7F+PU5LwN9ru3tsY/dhMEg9DUU0Nq+Hs4biScHO5hkN9ai1C2jeNJI9rSsIlkJ48 oY4x9fWtxJNWVQq20GAP73/160inJtS/zKWpXtdVvJyYIbKOOVfvKxx+lWfJ1ab708UQ9FGaq3Vp qdy6yiKGOZOjq2DRb6hqkspgdYEmXqG4zWik1pO4/Utf2RLJ/wAfF9M/sOKemh2a8sjOf9pjTP8A icHtbijbrB/itxWlofysenYfNoVlIMpEInHRkqIHUNP4Ki6hHccMKds1j/nrbj8P/rUeVq//AD3g H/Af/rUNLeMWgLFrqltdfKH2P/cfg1crDuNJvrvmaSDd/eC4NR/Ytas0/c3SyoP4T1H50KrNfFFh d9joKrT6da3H+shXPqBg1jQ3l5K/ly3ogk/uumP1q6LPUmGft649lp+0U18N/uC9xTpEkBzZ3ckf +y3IpPtGp2v+ugWdR/FH1pfsGo99Q/8AHaP7Pv8AvqDf981NmvhTX3APi1u2c7Zd8Lejir0cqSrm N1YeoOay5NHuJhiW9Lj3SoB4adTujvpI29VH/wBemp1V9m4XZvUVz8mmavD/AKu9eZfTdg1AHmjO 28uLyE+uMj+dDrtbxsHMdPRWJBax3OPL1WVvbdg1P/Yzd724/OrU5PZfiO7NSisv+xB3u7j/AL6o /sNO9zcH/gVPmn/L+IXZpMAVOQD9a420Dxy+Y8MLrJGzs80hCrhiMn09MCugOhQ4/wBfOf8AgVY8 MN7BH5RsrkIkZid0xu+8SCvrXNX5m02v1JkRSW4uGlbdDbLHB5iNHKSr8/ez6DpimyuunSwmO9Ik 8kyO/mlt5xwMHgZ7VM9rdsHdrW9eCSEw5YgyZznO3sKn07TbydnkzNZ7YkjwyKS5A96wUW3ZLX+v QmxW3ywtaXEd2jXDqZZZJJztx6Y9KmuJbu/nbzpY49lv5sMkUpEZ5+8aigt7qF43ksLj91CYt6oC ytuJ3KD1qWfz7g4l0+/ZDAYWJA3E7s59KavbqBO+r38kbQgWqnyfM+0bzsK9NwrAbS2kkQK8KIIR I8zOdpySM/j6Vfnt7lLR0jsbkQfZzEhYAt97cSwHSqSajbvCLeZJfKaBI2KYyGUk5HtzWdWXM0pi eu5RuLdra4aGQruB+8DkY9c+lbEdnJpmsGSznhEUKqXeRyFGR0P161nyai0YlhssxWzjGxsMTxgk n3q4b22v5Hg8m5ZZwjERgFldRjj1GKyhyJ6b/wDD/wDAErG4davN0gMNrEsQXe8kp2nd0IPcUNrl yNytDbwtFjzJZZP3Zz93aRycisxihjuIriCeIJ5McUakGTHOOO55qWS2ujGfOsbhbdtvlCLDSJtG 35h7g12e1n0f9fcXdiPdXbX73JV/tCTxxpEsvyFSp/DBxnNaC63cjA8m3nLtsVoJcqrejZ6cd6oC O/E+5NOmGHjdFJGNiqRgn15pi77UxIlrPHE8oDtckJ/CQFBHsTzSjOUer/r5Cu0aB1m9/dFFspVl corJISMgZxUllrst7dwKtuFhm3Bct8w2jkn2zxWLeQrBDZ2tqWE/nGRQ8i54HHTgVuaTEkt/cXMa gRRjyY8dM9XI/E1dOdSU+W/9f1+g03c2KKKK7jQKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAGS/6p/8AdNcfaQqtukzSyKggBZfN2BiXIA3dhXZMu5Sp6EYrDj8PTw8x32Cq 7EBiBUrnOGHeuavCUmmlcmSuZhktgl4zE3SfZgcGbdsG7ld315zT57gm6/dJEqR2oQLLPtA3L1AN aJ8PzndJ9uzM67HzENhX0C9qmttBjSKUXbJcSSKFDmMDaAMDFYqjUelrfcTZnPT3MlrPEVlkiRoY leSNMsBjsautfzWv27yDDiZRIrtKEbBXrjuaupoFzFlkvwW2hMNCCpUdMj196twaJAIpBdYuZpfv yOoz9B6ClGjV9AUWc27zCe5g+0XHlxW/nIPMOQ20c5qSby3iuII3uhLHAshdpiytkDIwe3Naz6Fd tC0A1AeUV8v5oQW2+hPeo/8AhGpvnf7d+8kTy3PlDBXt39ql0anb8v8AMXKzIura0t5HlukmmDy+ WoV+V+UEn3PPSl0/TLWUKs0TfvXKq8kojOO2F6k1a1S1v9GiNzFcCUSN+8JjGFPQEDt9ax4dZvYF ASVThiwZkBIz15NYz5YTtNfghOyepdg0u1ktCu0yXBLDHm7GGCcbVPDClnVZfsawLHC4tQWMkoUH r6+9Z6avdxRlFkUAkkEoCVz1we1dDoekzXMFtPflWjjBEcTRjJB9TTppVHywQLXRFIxQS2lkHRlE cLyOY35cA8j8T3ohjhdY5U8+KBkkYxLLkhl9G64rXbQJlkX7Pe+XFGxaNfKBK56jPce1VbmyvrC5 jny90xjdFEUQCxk9OK1dKUdWvy8h2K0U7SWokjmuUtSrM8Pm5YlSBw3XBzTGG+KSRGkCvbOAkkm/ YQwBw3cVqpodw6pPJelboLhdsYCKO67ehpsnh64my0l/8zL5bBYgFC+gHaq9lUa2/L/P8B2ZQDtF NLFBPcrcxJnzWl3BumQU6Ac8VHcSRql5h7sy2+CXNwfn5wcgdK0brQr1rSSNb3zFC/KvlhWfHQFq p3Jup7OW3itL1mcAP5kSjaB/tD7xqZRlG6aE0xu27eSNIrmb5pFW1Jc8LjcSfXHTmtr7HqZ63yj6 LVfRrSQzRyPHNHDbx+XEJhhiT1OO3pW5XRRpXV3cqKMv+z9QPXUT+C0f2Zdn72oy/gK1KK29lH+m yrIy/wCyJj97UJ6P7Fz968uD/wACrUoo9lDsFkZf9hRH7085/wCBUv8AYNr3eY/V606KPZQ7BZGa NCs+4kP1enDQ7Ef8sifqxrQoo9lDsFkURo1iP+WA/EmnDSbIf8u6Vcop+zh2CyKo02zHS3j/ACpw sbYdLeP/AL5FWKKfLHsOxELWAdIY/wDvgUohiHSNB/wEVJUcs8UC7pZFQe5p2SAcEUdFA/Cq+oWs V1aMszNGqkPvU4Kkd6rPrIkbZZQSTt64wKyNSurqaYW11OI1PLpFyQPSsKlaCj3JckJaW8KLK7ah cQQuxwiv8z+p9qguEhXCWT3MMYO4Kz8Z9RWhbaZJMB5EIgi/vycua1bbSba3ByvmOerPzWEaMpKy ViVG559rsN9b2K6hpab5rEFmGMnYep/DrWRofif+0LcRSTeVOH3lAcAn+8K7zVFWK8aK3AWMAAqn r71zurfCeHUYlu9NnFlcONzwuuYyfbHK0RoxqJw6rqHKnoE+pXLsk090+6PlXZvu1zl14qvbzVFs tJ/ftLIGZiCdzev4etTXHwu1mBA15qNsIs4GGdj+AIrt/BHhXSdIglaBXmvGXbJLLjOD2X0FFPDR jK05XYKKT1ILO2nadPKuHW6f70gbG49/wq9N4dulZmdmuFc5kHmYLn3qxFpgGoTQxyskkYDRtV+H UpLeQQaimxu0g+61KFKNvfBRXUxhaWqFhdm/hdl2MxIIK+nTpWhBY2kgAtNQlXHQb+a2iFkXkBlP 4iqk2kWc3JiCn1Tit1Q5drMfKQf2ffp/q9QYj0darXenalPtYyQs6fdccGrP9mXVv/x6Xrgf3ZOR R9r1K2/19qsqj+KM80nFWtJNfiFipDq2oxSi2uLVGmHocbqt/wBrTJ/rbCZfcc1Dc3tjfoEn3wSr 91mXBU1Lp+p4kFtdOpf+CQHh6IyaduYF6jhrtt/y0SZD7rUqaxZP/wAtwPqCKulQ33gD9RUL2dvJ 96CM/wDARW1qi6orUEvbaT7s8Z/4EKmDK33SD9DVN9Hsn/5YAf7pIqE6FbfwNKh9movUXRBqXbi1 hul2zRq3ueoqgdPurM7rCclf+eUnIpf7ImT/AFV/Ov15o+yanH9y9R/95aiWurj9wvkLFrARxHex NA/qR8prRR1kUMjBlPcGsqRNUZSssNtOvoaomDULZ99tbSRHuqtuU1PtZR3TfyC7R0tFYMfiKS3w uoWcqf7arxVyPX7GQZEjD6rWir031HzI0qQqGGGAI9DVVNTs3+7cJ+JxU6zxP9yVG+jCrUovZjuV p9ItJ+fK2N6pxVf+z722/wCPS8LKP4JOa1OtLUunF6isjK/tG9tv+PuzLKP44+asQavaT8ebsb0f irtV57G3uP8AWwox9cc0cs1s7+oak4YMMqQR6ilrLOjeUd1ncywn0zkUnm6pa/fjS5Ud14NHO18S C5q0Vmx63Bu2zpJA3o44q9FPFOMxSK49jVRnGWzC6JKKKKoYnWuW1bwo7StNp+3DHJiY4x9DXVUV lVpRqq0hNJ7nAR+HNTkfb9mK+7MAK6fRNATSwZZWElwwxuHRR6CtI3duJNhni3/3d4zUtZUsLTg+ ZaslQSK8mn2st0lzJAjTp91z1FWaKK6UktiwqOeCK5haKdFeNuqsODUlFNq4GcNB00Rsgs49rHJ9 fzq7DDHbxLFCipGowFUcCpKKmMIx2QrIKKKKoYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADXRZEKOoZWGCD0NYV14QtJnLQSSQZ/hHIrforOdK FT4lcTSe5iWPhWytJBJIWnccjf0H4VtdKWinCnGCtFWBJLYKKKKsYUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFU7jVLW24aQM391eTVb7bf3n/AB62/lIf45Kh1IrTcVzTZlRcswUDuTVGbWbd G2Q7p39EH9ajXRzM26+uHmP90HAqWS4sdMXaoUN/cQZY1DlK13oguyHOp3nQLaxn15aoZbawsjuu 5WuJv7pOT+VS7tQ1H7o+ywnufvGrVrplvafOF3v3d+TUcvNtr5v/ACFa5mXV3dm1LRxi0g6KMfM1 W9I0mO1hEsq77h/mZm5IpsQ/tTUTM3/HvAcIP7x9a1qdOCk+Z69gS6hVDUb1odsFuN1xJwoHb3qW /vVsod2N0jcIvqai06yaLdcXHzXEnJ/2R6VpJtvliN9iSwsVs4cH5pW5dj3NW6KKtJRVkMrX1kl9 b+WxKkHIYdjVHQ4VgkuYz/rUbBPtWvWXJ/ouuo/RLhdp+tZzilJTE97i3H7nXLeTtKpQ1fmgjuIy kqBlPY1R1oFYYZx1ikBrRU7lBHQjNOK96UQRlGC60slrYme37xnqv0q7aX0N4mYm+YdVPUVZqhd6 Wkz+dbsYZx0Ze/1pcrh8O3YLW2L9FZkOpvBIINQTy37SD7rVpAggEHIPcVcZqWwJ3GSwRTDEsauP cZrPufD9pcKdgaJuxU9K1KKUoRl8SBpM5xJdT06cW8k6up+40nRvxq//AGrcQf8AH3ZuB/eTkVeu baO7hMcq5B6HuKz4LmXTJRbXh3QniOX+hrHldN76CtYsw6tZz8LMFPo/FXAwYZUgj1FV5rG1uRmS FGz3A/rVQ6KIzutLmWE+mcitbzXS49TUorLzqtt2juVH4GlXWkQ7bqCWE+pGRR7VddAuadFQQ3tt cf6qZGPpnmp6tNPYYjKHUqwBB6g1m3GhwO2+3PkyewyPyrTopShGW6E1cwXjNrxf2Mcqf89Yl/nU 8Nhpd6MwcH0DEEfhWvVG50m3nbegMUn95OKydK2yuKxCdDjX/VXM6fRqP7NvU/1WoP8ARhmk8zUb D/WKLqIfxL94VatdTtrrhH2v/cbg0kqbdtmGhnXtxqWmxozyxzb2CqoXkmn2+pahNBHKtvE6uMjD YP5Zp+uosn2JHAZWuACD34NYsdtbJHbxvFvEsZYuEdn7/dI4GPSspylCbSenqS20zSj8T7pFj+xS u7fdCc7vXFTL4jgIwbe4Eu7YI9uSW9OtZUN3sFni3hI+ySEMV54zx+n61Bpkuyey/ewyY3ERhGBQ sMnk8cdKhV53Sv8A1oHMzfTWLG5Dx3S+U6nDRzLyKpQ/2bezlYvNtHI3IxO0OM4yKp6daw3Ii8+3 tx9p3NgK7OR6g9FApI40lTT7aS0WRHiIMxzlRk9D2x1o9pKSTkl/X/Dhdsv3V1d6X5fl3K3Qdtqp jLVYg18NHG1xbugcZDLzkfSsGBIBLp1v9nibzYy7yEfM3Lf4U14ljs4447XcTAsnngncp6k56YHT FSq01qthczOqs9Vhu2dSdjKTjceo9a5fXtelvJ3t7eQpbIduVP3/AP61JHGm2WTzYr4wxb1iVWAJ yBkg9euaW3t0Mktw9nDAu1PlmDOqk+ijnn36UqlWdSKjewNtqxh4rY0TXZtPnSKZ2e2Y4IJzs9xV q7tYLL7ZJFZJMUeIqpU4Xcpzx1x7ULYQw3E0nkQCMlBiVWfYxGSoUfzNYQpzpyvF6/1/kSk0zoG1 m3S/FsVflgvmY+TcRkDP0o/tiA6gbTZJkNs8zHy7sZxn6Vg3MSWS3iRWqzIlyu1XBIXKeg/KiOyh M72/Ij+1KduTkHyyduevtXb7epe3mXzM6xWVuVYH6Goby8jsrdpZMkDACr1JJxgVzEN0LVo5rdo7 ZyxRj5LiNhjoR6/SlaUzSxXEkcd5JLPsL4bCgYwFHbrnn0qnibrTcfMdJZ38V5B5gzH8xQq/BBHU VYMigMdwwvXnpXKSQwRs0kkaymW5kVt6O+MHou3oagggicOU3CC2lcXAbILoPmXd75GKSxElo0HM dJY6zBfuyosiYXeC4wGXOMj8avF1ChiygHvmuLhhi+zpceQjsLYPsIO3JkIyQOuBUiRIlvNNJAEA kULBKGdYwRnIUdM+9KOJlbVCUmdj1payNCl5uYE3iKJlKK4IK5GSOecela9dcJc0blp3CiiiqGFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRTJJY4V3SOqj1JxVCTWoy2y1ied/9kcVMpxjuxXsaVQT3kFsMzSq vtnn8qo+TqV5/rZVtoz/AAp1qaDR7WE7mUyv/ec5qeaUvhX3hdkR1aW4O2xtXf8A234FJ/Z13d83 t0Qv/POPgVqABRgAAegqrdalb2nDNufsi8mpcVa82K3cW3062tf9XEN3948mkutSt7Th33P2ReTV T/iYaj/06wn/AL6NW7XTbe05Vdz93bk0Jt6QVkHoVM6hqPT/AEWE/wDfRq3a6Zb2vzKu6Tu7cmrd FUqaTu9WOwVnapcO2yzg/wBbN1I/hWrlzOltA8rnhR+dUtLgdi95OP3s3QH+FaJu/uIH2Lttbpaw JEg4UfnRc3KWsDSyHAH6093WNGdyAqjJJrKhRtXuhPKCLWM/u1P8R9aJPl92O4MfY273U/266HJ/ 1aH+EVqUlLVRjyoErBRRRVDCs7WoybRZl+9CwYVo0yWMSxPG3RgRUzjzRaEytdgXmlOV53R7h/On abL52nwt324P4VX0dy1m8D/eiYofpRop2RTQHrFIR+FZxleSl3QkaVFFFbFEc8EdxGUlQMp9azDD daUS1uTPbd4z1X6Vr0VEoKWvUTRXtL2G8TdE3I6qeoqxVC70tZX863byZx/EvQ/Wo4NTeGQQagnl v2f+FqSm46T+8L9zTqOeCO4iMcqhlNPBBGQcg0taPUZkRyy6RKIrgl7Vj8kn932NaysGUMpBB6EU 2WJJoykihlbqDWUDLo0m1t0lmx4PdKy1p+n5C2NikZQwwwBHoRSI6yIHRgynkEU6tRlKbSLObkxB G9U4qD+zLq3/AOPS9cD+7JyK1KKzdKL1sKyMv7XqNt/r7USr/ejNPi1u1c7ZC8TejitGo5YIphiW NXHuKOWS2f3hZixzRzDMbq49jmn1nSaJbMd0JeFvVGpn2bU7b/U3KzL/AHZBzRzSW6+4Ls1Kq3Wm 213zImH/ALy8Gqv9q3EHF5Zuo/vJyKsQ6rZz8LMFPo3FLnhLRhdMzL7S73ylRJnmjRgy4OHU+1QW tpZMBB9qvLYfxwtJgMe/PvXSghhlSCPUVDcWcF0uJow3v3H41EqCvdC5TNbw3bsAI7m5SIZ2xq4w oPXHHerd1pUNzbQwh5IvJxsaM4I4xUBsLuyObGfen/PKSnxawgfy7yNreT/aHBoShHSStcNCJPDy RKEhvbyKIchFk4B/KkTw7Gq7Ptt2YiMMm8AEenStZXV1DIwZT3Bp1X7Gn2HyoxR4YtgVKz3IZOI2 DjKD0HHvTx4ctwqxfaLn7MOsBk+U1r0Uewp9g5UU7vTIbtY8F4ZIvuSRHaVHp9K43Ukv9I1GUG4m HmdJd33xXfVDc2sN5EYriNZEPZhWdfDqorx0YpRucDHq9zHbyqJZPOkZT5u7kAAjH60/Slvry9MV rPKpkOZXDHp6mun/AOET03zN22XH93fxWna2dvZReXbRLGvt3+tc0MJUbXO9EQoPqZy+HgjFk1C8 VjySHHPGPT0pB4ZtA2fOucE7seZ/H/ez1zWzRXb7Cn2NOVGfa6RHb3AnlnmuZVGEMzZ2j2FNudGj mneWK4nt2k/1gibAb3x61pUU/ZQtawWRkL4ejiB8m8u42c5kKyffPqeOtObw7aHaqNLGm0K6K3Eg zn5vWtWil7Gn2DlRjr4bgjO6K5ukdRiNlf7gznA46Uo8PRR/PFdXUc7fflEnL/Wteij2FPsHKitZ WMVjEUi3Esdzu5yzH1JqzRRWiSSshhRRRTAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiqtxqNta/6yUbv7o5NJtLVgWqQkKMk gAdzWX/aF5d8WVqVU/8ALSTilGky3B3X1y8n+wvAqPaX+FXFfsSz6xawnarGV/7qDNQ+dqd5/qo1 toz/ABPyavwWcFsMQxKvvjn86mo5ZP4n9wWZmx6LEW33Ujzv/tHir8cSRLtjRVHoBin1TutTt7U7 S2+TsicmnaFNX2DRFyqd1qdvafKzb5OyLyaq7dQ1H7x+ywnsPvGrlrp1vacxpl+7tyanmlL4UF2y njUNR6n7LCe38Rq3a6bb2nKJufu7cmrdFUqaTu9WFgoooqxhRRVHU7s28Iji5mlO1AP50pSUVdgy vMf7U1EQr/x7wHLn+8fStXhR6AVXsbQWdssY5Y8sfU1Uvrh7yf7Dan/rq4/hHpWafIuZ7sWwyVm1 e68mMkWsZ+dh/EfStVEWNAiABQMACmW9ulrCsUYwq/rUtVCNtXuCQUUUVYwooooAKKKKAMtP9F11 16JcLkfUUtv+412ePtKgcfWl1lSiQ3K/ehcE/Sm3rBNRsrlfuv8AKT9a537r9Hf7ydjUoooroKCi iigAqOeCO5jKTIGU+tSUUNXAyDDdaUd0BM9t3Q9V+lX7S9hvE3RNyOqnqKsVQu9LWV/Otm8mcfxL 0P1rLlcPh27CtbYv010WRCrgMp4INZ0GpvDIINQTy5Oz/wALVpAgjI5Bq4yUloCdzJZZdGkLx5ks 2PK90rUilSeNZI2DKehFOIDAhgCD1BrJlhl0mUzWwL2zH54/7vuKjWntt+QbGvRUUFxHcxCSJtym pa1TuMKKKKACiiigAqvNYW1x/rIUJ9cYNWKKTSe4GWdFEZzaXMsJ9M5FGdVtuojuVHpwa1KKj2SX w6CsZi62iHbdQSwt7jIqwJ7K/TbvjkB7HrVplVxhgCPQis+707T8BpgkJJwGDbeaTU0t0w1GNpUl uxfT52jP9xjlTQuqyW7BNQgaM/315U0g026g5tL1sdlk5FRTalc2kZ+3QwyRZwWVhWbfJrt+KJ2N aKaOdN0Tq6+oNSVzZm09j5tvO9lJ15+6auQ6rPCoNwqTxdpoSCPxqo111HzGxRVHT9Tiv4GcMqsn 3hnoPWuf1TxZK8rR6fhIxx5hGS30pzxEIR5m9wcklc66ivP4vEOpxPu+1M/s4BBrqtE1yPVUKOoj uEGWXsR6iopYqFR8q0YKaZrUUUV0lBRTJJUhQvK6oo7scCnKwdQykFT0IPWi4C0UUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRTXdY13OwUDuTigB1FZ0utQBtlurzv6IOKj26nefeK2sZ7DlqzdVbR1Fc0JrmG3XM0ioPc1QbW GmO2xt3mP94jAqSHRraNt8u6Z/Vz/Sr6qqABQAB2AotOXkGpl/Yr675u7nykP8EdWrfS7W25SIM3 95uTVuimqcVqFgooqldapb2x258yTsicmqlJRV2Mu1TutUt7U7d3mSdkTk1V8vUNR/1jfZYT/CPv Grlrp9vaD92nzd2bk1nzSl8KsLVlPZqGo/6w/ZYT2H3jVy1063tOY0y/d25NWqKpU0nd6sLBRRRV jCiiigAooooAbJIsUbO5wqjJNZunxteXL38w4+7ED2HrSX7tfXa2MR+QfNKw7D0qxe3aafbqka5c /LGgrFtN3ey/MkZqN6yFba2+a4k9P4R61PY2S2UG0cueXb1NRadYmANNOd1xJyxPb2q9VRTb5pDX cKKKK0GFFFFABRRRQAUUUUARXUIuLaSI/wASkViu5m0JWP8ArLZxn8DW/WN5ey+vbU/dnQuo96wq r8dCWa0T+ZEjj+IA0+qOkS+ZpsWeq/Kfwq9WsXeKZSCiiiqAKKKKACiiigCKe3iuYykyBlPrWaYr rSjuhzPbd0P3lrXoqJQT16iaK9rew3ibom5HVT1FTnng1QutLWR/OtW8mcd16H60yDU2ikEGoJ5U nZ/4WpKbjpML9xk9rLp0pubIZjPMkX9RWha3Ud3CJIjkdx3FSggjI5BrMurOS0mN3Yjn/lpF2YUm nDWOwbGpRVezvY72LfGcEfeU9QasVommroYUUUUwCiiigAooooAKwPEkXnTW6ccRytyuei+lb9Ze sWFzdPFJa+WWVXQhyRwwxmsq8eaDRMtjNaXUY7QoLlldYASvkjZjHQNnOcVWMWn28s7ruYx2quFe IMoJx82CeSc1ak0O9mOyWK0MhQIbnLZx0zt6Z96bJoeoSMylLYB4lheQOeQCOcY68VxyhN/Z/P8A r9CLMggx+5S9t5I47e2ZkEkQILdScHrjjFV4rB5bCWWGWYZjaTIh2xnvjNa954fdCDp4X5o2jcSy McA9x1pg0zUQCPs9oziLyfNMjcrjHA6Ck6Ur2kgsZ08EYMkdnMY53tlZolTCkbckZ9TVX7BBC7Rx zM8v2YyMGjG0ArnA961bnTdSW3lkFtbCUQ+X5iOS20DGAPX3rAOoMbh5vLGWh8nGeg24zWNVKL95 fmS9CW406GIGKO4aS8UqDFs4Ynsp74qzpWnXUNy8rGe3miAKokYZ2B74J6VUuNT8+Jh9niSZ9u+Y Z3Nj+X4VNo/2i6uGhSBbkkBsu5UpjuGHIqI8nOrfqCtc20v9QmjLNOyokhjDQ2+WcjuwPQe1RS6n eRK73V95e2YxAQwhgcAHPPbmp59Jv5QTPFa3Qdt+wsy+WenB7jAFFrod0JQlyLfyNzufLz/EuMAe 1djVR6a/iXqVLme7vmSC7kQLHcCNfkBErcndj0xjj3qO3v7iwsIVN6ImEZeOIxAoRk4DN6ntVxtG 1JmgdjblrXGwbj+87ZPHBxim/wBiX/lJE8VpIwQoszMcoD2x3xng1HJUvezuKzJje6jHmVpSXVPM aPyQIsddobOc4rcglWeCOVPuuoYfjXPyaHeTNskitCxUIbnLZx0zt6bsd66CGJYII4k+6ihRn0Fd VHnu+bYuNySiiiugoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA oqjqeq2+lwh5iSzfdRerVzcvjG8Z8xQQovock1hUxFOm7SepLkkdlRWBpfimK8lWG6QQyNwrA5Un +lbkkiRRl5GCqvUmrhVjUXNFjTTH0VWmv7a3UNJKoyMgDk/lVM6pcXXFjasR/ffgU3UitAujUJx1 qncata252+Zvf+6nJquNMubrm+umI/uR8CrtvYW9qP3USg+p5P50rzlsrBqUvtWo3n/HvAIEP8cn WnJowkbfeTyTt6E4FadFHs0/i1C3cjigigXbFGqD2FSUUVolYYUUVSutVgtzsUmWTsic0pSUVdhc u1SutVt7Y7ATJL2ROTVbyb/UP9e32aE/wL941dtbC3tB+6Qbu7Hkms+aUvh0Fqyl5V/qP+ub7NCf 4V+8au2un29mP3SDd3Y8k1Zoqo00nd6sLBRRRVjCiiigAooooAKKKKACqt/dizti/Vzwg9TVkkAE ngCshJFvbx7yY4tbfhM9z61nUlZWW7E2S24XS7Fp7g5lk+ZvUn0osLV55Te3Y/eN9xT/AAio7eN9 VuRdTgi3Q/ukPf3rXqYR5rPotv8AMSQUUUVsUFFFFABRRRQAUUUUAFFFFABWZqo8ie2ux/A+1voa 06rX8H2iylj7lcj61FRXixPYq6SfLmu4Oyybh9DWnWDpc+dQjY/8tYtp+oreqaLvEI7BRRRWowoo ooAKKKKACiiigAqKe3iuYykyBlPr2qWihq+4GQY7vSTmLNxa91P3lrQtbyG8j3Qtn1U9RU9Z91pY eTz7VvJnHcdD9ay5ZQ+HVdhbDbyxkjl+12Pyyj7ydnFWLG+jvY8j5ZF4ZD1Bqvb6m0cggv08qXs3 8LUt7YM7i6s22Tjnjo9Sn9qHzQvQ0aKp2OoLdqUYbJk+8hq5W0ZKSuigooopgFFFFABRRRQAUUUU AFFFFABWBqnhWK8laa1cQyMcspGVP+Fb9FRUpxqK0kJpPc4+PwbdFx5lzCq+qgk10mm6Xb6XB5cA JJ+856tVyis6eHp03eKEopBRRRW5QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZr28 2USRsQZJlUgMVyPTIrN0/VL2G0iiKwM2WCLLKQ8mCen8ua1NZSRraJ4onlMcyuVTqQPSsYLeeXCs tpfI6Z2iHG1hnIyf4TXHVbVS6uQ9xVE13JbPPqBVbkM0sPmEdM4Ax0x3qTStWjt7N4YXE9w8zCOI yEhV9Sx7cZqr9lu4WtfNsblpbfeCUAZWDZ7+vNXV0q8t7C3fe0/lr89vtUHBGCAfUZrKHPe6X9af 8ElXJF1263CPybZyyl1mSX92AOue/FKNavGdY1htTlDJ5olPlso6/Ss2KwlTc0Wn3ZgMZjkL4Eje mB04xSvb3RjKxWFz5TRPGrOBuLMckkdhT9pU8/6+Q7s0Brd40nlrHaH935vm+adhXpTjrlwAUMVv u2iTzvN/dbPXPXrxislbW9S3Fv8AYbjcIGh3BeMls5z6VLbw3sEKxtZXSokAido8bgQxIK+o5oVW p5/18hXZo/25cbSvk26sF3mYyfutp6EHr17VQvp7u7imlluBC8ciRrFHKdrA98jrmka1unidpLW8 e3ZQoJIMoIOc7emPaohZTRwyKunXSxvIkkYXDN8v970zUylOSs7g2y3p+oXttC0OIMCZkQzzHLHP 3V/xNWY9avJsMIbWEM5jVJpSGLDtWe0E0m03On3mBIzR+WBypbO1vTnvUctpqEs0Uj2MoaGZpnAA wQSDhfWmpzirK/8AXyC7Kt1aS3/kyk4mkaQytI/yoAf0AquNHmaYKssLRlC4mDZTA61dbVPsc3lT QzRk+YHGAGAY5BFRLq0KXaMr3hVEIEhcbwT3A6Y9q5pKm3q9SdCumkStLIvnwBIwGMu/5eela01/ 51iIbq8iWWD5TGDkyHsQR1zVUa3B9raRRPESgXzUChmI6ll6GtWCwu7y1lubdxbLKd8cJRfm9ye2 fatKUVqqeo15FeCb7ArSXFrbzPHjzFSTLoT0yDxVttcu442dYrSRVYIyxykmMnpnj+VU2t7iRp/J 0+582X/WLIQEAzlgD3zinzSXL28kSWN8QzKVUxqFTBzgY/nWqlKKsnb5f8AepcbVr5N+5bEBG2uf OOIz2z9ac/iKOG1lE4jW8jO3yd3DHsQfSsWWyvZYrtFsZwbmYSrkDgDPX3q89jfXVndzKJogzArb si5cADPv2qlVq62v/X3Duy0+rX0e/eliPLOJMzH5PQmhtbuVDK8VtC0ZAeSSXCEnkbe54rIns72f 7dtsbgfa3DJkDjB7+lPa+di8LRXUYJXb5QBcELggj0qfbTW7f9X/AOALmZNdTXV75kk85tykyReS khwQeuMdc9qsQajc6ZG0JVLpFlMahZcuhP3Qc1TNtdgO0tldkPKkseCHb5eMNTIbXUIppXSxm3TT rMmQMAAng+hpKUk7q9wuy1d399OdrNE8Zbyyls+SrHoGJ/nUEUMlvIt1bmKSbz1jVY5SV6cg1JDb 3Ks32OwuAd4kfzyFGASdq+vXrUa28ixiO306+P74SMXwvAB4BHek7t3d/wCvkBsWOryTXi284gJc Ha8L5GR1BB5Fa1YNhFc3N9BK0M6iEsWluFVXYEY2jHX61vV20XJx1LiFFFFbFBRRRQAUUUUAFFFF ABRRVW+vlsURmUtuJHFJtRV2BX1SdnZbKE4eT75/urVaKIag628OVsoOp/vmqtus1/O6ofnlOZZB /CvoK6GCBLeFYoxhVFc8U6ru9v6/pkLUeqhFCqAAOABS0UV0lhRRRQAUUUUAFFFFABRRRQAUUUUA FFFFAHMyf6Fq4XoFl3D6Gumrn/EIT7TEysPMx8w9u1a2n3f2u2D7Su35cnua5qT5ZygSt7Fqiiiu koKKKKACiiigAooooAKKKKACiiigCK4torqMpMgZf5Vm7LvSTmPNxa91P3lrXoqJQT16iaMqSOHU 1FzZSbLlPwP0NT2GofaCYZl8u4T7ynv7im3WlhpPPtG8mcdx0P1qjPJ57rHeD7NeJ9yUfdasW5Qd /wDhn/wRbG9RWdZ6lndDeYjmQZJPRh6itBWDqGU5UjINbxkpLQadxaKKKoYUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFAGTrehR6qodGEdwowGxwR6GuWl8OanE+37MX91YEV39Fc1XC06j5noyXBM5PS/Cc hlWXUNqopz5SnJP1NdWAAAAMAdqWitKVGNJWiNRS2CiiqFzq0MLeXFmaXsqc/rVyko7jvYv1QudW ggby48zS9lTmofst9qHN1J5ER/5Zp1P1q9bWUFouIYwD3Pc/jUXlLbQWrKP2a+1Dm5k+zxH/AJZp 1P1q7bWUFouIYwD3Y8k/jViiqjTSd+oWCiiirGFFFFABRRRQAUUUUAFFZuv7jphVTgtIi9cZyayd Ovb21tlhV7dQZGWMS7iX56DHQduaxnWUZ8rRLlZ2OopMjGc8VyojN3LbyXV2yPPI6yxbmwQP4R9K hglt5IxaI52yXY/dpuC7Mdiaz+s+X4i5jsKytY1+HSv3ar5twRkJngfWuftJY5Z0t3hmJAYtO0rA xgZwR2wPeqVjF/aOrILyRisjfM7A/NWU8XJpKC1YnPsXG8W6iZNw8kL/AHdnFWk1f+3WigkCwzgn bz8rf4VlppAk5F3AnmMVhDZ/eY/l+NOh0dykLm6iilkJEaNnJYHpXLGdbrqiLyOx03TvsCt+9Llu oxgVdrnotZvpI4sm1ikdcJHITukI4JyOBz0qnYTz2ZWWIonmQ75nmYkKdxGcdz2rvVeEbKK0NOZI 66isA61dhCD9mVQokNySxQqeBgdc5psmt3ls5Mv2aWNEWQiIHJU8ZFX9YgPmR0NFZmlX9zdyzx3C Rjy9vKZ4JGcH6Vp1rGSkroadwoooqhhRRRQAUUVm61eT2lvF9nO15H252biBjPAqZSUVdibsaVFY ln4hR7BJp4Z2IX95JHESgP1qL+0NWuJIljRIo51Lq4jLGNR/Mms/bwsrai5kdBRWBBq17JawxJse 6lZ9rMmPkXuQO/ap7fxAjWweW3uNyDEpSIlUYdRQq8GHMiTXPsa2u+7kEbD7jdSfbHesuy8UWdpC kPlTMB1fA5/DNY0kk+v6vjJzIcKOoRarCwumMuy3lYREhyFPFcE8TNy5qaM3J3uj0Cx1K21GMvbS hsdV6EfUVarzvTvt1pMl5bQysq8kqpwV712H9v2zRmSOOeSNRlpEjJVfxrroYlTj7+jLjK+5qUVz 1hrs3mIbrMonQvEkMeWHOMflV/8At22J2LHcNPnmARnePcj0rSNeEle41JGlRWWNftRLsljuIsYy 0keAuemasWOpw37OsQkUqAcOuMg9CKtVYN2THdFyiiirGFFFFABRRRQAUUUUAR+dF5vleYnmddm4 Z/Km3MENxCVuFUp6nt+Nc1dwzNrbyW7KsoucAlc4+TJPr+FTMZruSCO7nlltWkwyyQ7GLYJHHda5 fb3unEjmINQAt7gWwm81RymeuD2FTS6+dK06OEKJLgj5QTwF7E/4VThS2Wytvs6SzO9wS2IgXKqe gPbAqJLA6tezy3LXCSvKRsSEnZ6bj2rl55r4N2Td9Cs/iLU5H3faivsqgCtXSfFchmWHUNpVjgSg Yx9RWV/ZcMSH7Xd+U7OyR4TKnbxlj2FWW02znhslWVoi1u8jvt4OO9Z05Vou9/xJTkdt1pa52w1W S3ijRTNeQPETEwi+dcHGCB296gj1XUCiBp8LIrO8hjAMW3O5cfl19a9D6zGyNeZHU0VzA1K6j2/8 TAvP5In8poRtIxkgkV0cEont45QMB1DY+oq6dVT2GnckooorUYUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVFczi2tpZmBIjUtgd8Vn2Wv29xHIbgx25RgPm kBByM8GolUjF2bFdGrRWReeIYbWQhInnjUgNIhGNx6D3qaw1OS6upYJ7cQvGoY4kDjnsfQ0lVg3y phdGjRVZNQtJJGRLmFmXqA44pBqdkyswu4Sq/eO8cVXPHuFy1RVQapYsrMLuAhep3jinxX9pMHMd zEwQZYhxwKOePcLliop7qC1TdcSpGvqxxVS71m1gsJrmKaOXyx0Vgee1cNNNc6ncSSyEyOAWPPCg elc9fFKnZR1bJlOx3kGs6fcPsiu4i3oTj+dXa8vkjMe3cVO5Qwwc10GgeIGt43t7p9yhcxMx6H0z WVHG80uWasKNTudfkc89OtUbnV4Ym8uEGeXsqc/rXPrdyz3Tee7eQ8iiR0kGOen4V0FnJpsKOLWW DCDLkOCR9TW8a3tNtClK5B9kvdQ5u5PJiP8AyzTr+NX7azgtFxDGF9T3P40xdSs3jaRbqEovU7xx UsFzDcpvglSRR3U5rSKhfe7GrEtFV3vrWOcQvcRLKf4CwzSNqFok3lPcwiTptLjNVzR7juWaKqf2 rY7tv2uDP++KmguYbpC1vKkig4JU5oUovZhcloooqgCiiigAooooAKKKKAKOsQyz2GIUMjq6vtBw Tg5rFFvfiJFmsrnhmZPJnC8E5w3+NdRRWM6Km73JcbnKCxv7cwB7GSR4ZGkDRyAqQ3bnnNWBpV7b WFrIrzyvG4d7beNoHtXR0VKw0V1DlRyY0+U2RgfTrxSxLSGN0G854z7D0rKTULuzuo4rhpTHbv8A 6lj0xXoNY2teHo9TPnRMI7gDGccN9awq4aSV6b1RLh2OaTUbQeWXtpWNuxMPzgcE5w34+lTtfW62 9jNLE0typZ1CPgBt3AIqM+F9TD7REhH94OMVtaN4YWzlW4vGWSVeVRfuqfX3rnp060na1vkSlIrr ZXoMBnsHmnTlHSQBDzkbu/BNNSz1DYVmsXaMJsfbIoYnduDLXV0V3fVl3f4GnIciVkEhtbmHyIGh HlxvKFc4Oc7umc9qYZrf+1lZHiFtbwBJQZM5HoPU59K6u4tILtAtxCkqjkBhnFRf2XZfJ/okP7v7 vyDioeGl0YuVkWiwNFYB5BiWdjK/Hr2/KtCiiuqMeVJFrQKKKKoAooooAKyddkWJbSSRgqLNyx6D 5TWtTWRXXa6hh6EZqZx5o2E9TkILyIQWrxy28Zij2ssjPuz7KOGzUQukU2btcKhSB43QsQytzjIr sjBEWDGJCy9DtGRQ0ETNuaJC3qVGa5fq0u5PKzlI7VrE2VzNbx28Z4MwlZuqnqD05psN3EkNqUuL VWt1Kvvd8k56gDhga7BlVl2sAQexFR/Z4cqfJjyvT5RxT+rNfCw5DhrK+tlvbc/Z0gKyZaYO3Tnt 0FWYpE/0XGoRxfZZGMo3H5+c5H97I4qTXvDssU73Nmhkic7mReqn6elc/sbdt2Nu9Mc1wTc6T5ZI zd0dF5qlbC5F2tvCjPIYiSCRu7Dv6U2K5iD20rXAt1gB3wMSG6k8L3yCKNG0K5vJIZb0MttDyiN1 Pfp6V1zQxMwZo0LDoSoyK6qVKdRc2xaTZxsV3A8CxLKsLNCV3EkBPnJ2kjpkVIZUngkt4bgeYkSq 1wCdp+Ynbu649/autMERDAxoQ3UbRzVO80lLh0kt5ntZVG3dFjBHoRVvDyS3uHKzAmAl1aO0kk8y Oa1VJHGT05B/StvQoswS3RGDcPlf9wcLUA8NrvL/AG653SDExyMyD09q2I41hjWONQqKMADsKujS kpc0kOKd9R9FFFdRYUUUUAFFFFABRRRQBg3emag2ovLbeSEMnmhnJ5+XbtIqBNFvRIk0VraW7RNu CB2bzD6Z7CulorB4eLdyeVHN2ehTvIiXcSRW8bO4Ecpzlu2fas25u5NHuWtJbdZhFIZInd2HB9cH n8a7aqGqaRb6rEFmBV1+7IvUVnUw1o/u9xOOmhx39sZLGS1hlIdniLk/uyev1H1pi6o3kRxmBWdY 3iDgnJDe1aMng67D4jnhZfU5B/KtXSvDENjIs1w/nSr93jCrXHGhXlKz0IUZFfTdCuHW3S+UJDFG 23ZIQzFjnnHpUlzoVwPNtbTYtpMQS7sSyeoHrnAroaK71hoJWNOVHKnQ9SMnnbINwi8jbvPTGN2f 6V0ttEYLWKInJRApI9hUtFXToxpu6Go2CiiitRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFAFPVv8AkE3f/XJv5Vz6RBDcPbRlrgMgYJErkLtHY9ia6mSNZomj kG5GGCPUVnf8I5p2wAROCD94SNu+mc1z1qUpyTRMk2Yxmkht7pbSIRhLmMsm1TsyOfpz+VNuJZft F9IZbhFZ/Lfy4QUKj1bt1rcfw7pzqq+QVCjHyORn6+tW7axgtbY28SfujnIY5znrnNZLDzejf9fg Tys5i4hJuY0uoIUs1nCxttC/L2AI+8D3p/lu0sBvoERxcKsQ8sLkc5HHUdK2U8PacjlvI3AggKzE hfoO1NHhzTgCDE5J6EyMSv0OeKX1ef8AT/4AcrMK2m+2SwNNFFmO82LtQD5cHiltHjv1gkukiG24 aNQqBQRtyFPqM1uN4b05iMQsuB/DIw/Hr1p3/CO6bnP2fjGNu44+uPX3pLD1Otv6+QcrMVk8ye3+ 1W5E25thljVN2BwuAeRmmW8l+sz+bBHHcyW78KgDNjpla2JvDdm1pNHEpErj5ZHYsVI6YzXGXMNx Z3LR3AdJV7knP4GsaylSs2v6+4l3RtKjrG0lpCj3ggi2qUBIBzuIHr0pLiT7FFdzRxwrchIjINoI RznOB2rA3sGDb2BHQ55rovDuhG5zc3qHyT9xGz859TUU5Oo+WK/ruJa6IcI4JHbzlRI5XgdwBgZK /wCNLMpMkQubQkicBN6JGCP7oweRWwvhzTlbPks3s0jEflmlTw9pyhgYS+4Y+dy20e3pXV9Xn5f1 8i+VmTJD/p1vM8W8neojeJUk6dQOjY7UxjNbX26KaeN5YskRWo38H+Jc4B962B4d04IymFmJ/iZy WH0ParVlpttYBvs6EM33mYksfxNUqE29dPmPlZzkCM8cX7pHs5Iy00jICS3O4luoIOKksrTNkI5F 3xPAzfLCNpOOCXPJatiXQbCa4MrQ8sdzKGIVj7jpTG8OaezlvLdQTnasjAD6DNJUJr/h/wDgC5WY ccwUpAYYWjFl5pDRgksBwSav6DK0t3FKwUPNbbn2qACQ2AcCrg8N6cBjyX+vmNnHp16e1WbPSrSw keS3jKswxyxOB6D0p06NSMk3sNRdy5RRRXYWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFJtGc4GfXFLRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABUFzZ294u24hSQdtwzip 6KTSejAoQaHp1u++O0j3erc4/Or9FFKMYx+FWC1goooqgCiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKAP/Z ------=_NextPart_000_010B_01D27586.2F6FCFD0-- From nobody Mon Jan 23 11:50:13 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 AD2D1129801; Mon, 23 Jan 2017 11:50:11 -0800 (PST) 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 K9Uf5vGfVcVH; Mon, 23 Jan 2017 11:50:09 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D158B1297F3; Mon, 23 Jan 2017 11:50:08 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <20170123183401.GB33438@elstar.local> <00dd01d275ab$97ff6400$c7fe2c00$@ndzh.com> <20170123191514.GB33573@elstar.local> In-Reply-To: <20170123191514.GB33573@elstar.local> Date: Mon, 23 Jan 2017 14:45:57 -0500 Message-ID: <011901d275b1$51574260$f405c720$@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: AQG9jePVIS5uC4TbhX28EOTtM+D9KAG1tmZ1AoDFVVMBtqxAPgL2Isg2AfLRVfYCOn1PKQKeDvdTAp8FxJ8CAdLlWQJj8NkjoLqo5XA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 19:50:11 -0000 Juergen:=20 First of all, I posted an individual I-D to start a discussion. I = indicated to Benoit Claise that this was my personal recommendation as = shepherd after looking at the problem. I have not mandated anything. =20 Second, I hear that you want to use the YANG security guidelines, but = there are 6 differences between the Yang security considerations and the = references in the I2RS security documents and the = draft-ietf-nemod-ietf-revised-datastore-00.txt. If you want to debate = these 6 differences or the suggestions for the yang security = considerations, I am still willing to continue this discussion.=20 My understanding from this email messages is that you do not want to = discuss these differences and how to craft a security considerations = section that addresses these differences. =20 Cheerily, Sue Hares =20 -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, January 23, 2017 2:15 PM To: Susan Hares Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) I suggest to use the YANG security guidelines. Or, as Martin said, there needs to be a clear statement that these YANG = models only apply to I2RS agents and nothing else. In any case, I think you can't post an individual I-D and simply declare = it guidelines others are expected to follow. /js On Mon, Jan 23, 2017 at 02:04:58PM -0500, Susan Hares wrote: > Juergen:=20 >=20 > There are two I2RS drafts related to security: = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-security-environment-reqs-02. The = draft-ietf-i2rs-protocol-security-requirements has pass IESG review and = is waiting for the RFC editor. The = draft-i2rs-security-environment-reqs-02.txt has not passed WG LC. You = are correct that draft-hares-i2rs-yang-sec-consider-00.txt is an = individual draft. This individual draft is also based on = draft-ietf-netmod-ietf-revised-datastores-00.txt. =20 >=20 > The impetus for this individual draft = (draft-hares-i2rs-yang-sec-consider) was the DISCUSS by the security ADs = regarding security consideration section in two drafts: = draft-ietf-i2rs-yang-network-topology and = draft-ietf-i2rs-yang-l3-topology-08.txt. The draft indicates the = following 6 areas where the I2RS protocol and environment security = requirements differ: 1) mandatory-to-implement transport layer, 2) = priority and secondary opaque identifier, 3) different data store, 4) = different validations in I2RS control plane data store, 5) different = NACM policy, and 6) optional insecure protocol. None of these are = handled in the current YANG security considerations template. Items 1, = 2, and 5 are specified in draft-ietf-protocol-security-requirements = plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the = draft-i2rs-security-environment-reqs-02.txt. Item 5 arises out of = SEC-ENV-REQ-05 and SEC-ENV-REQ-06 in the = draft-ietf-i2rs-security-environment-reqs-02.txt. Items 3 and 4 arise = out of the draft-ietf-netmod-revised-datastores-00.txt. I welcome a = discussion on whether this individual draft truly represents the content = of these 3 drafts. =20 >=20 > The individual draft tries to provide the information from the = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-security-environment-reqs-02.txt in a format consistent = with the current Yang Considerations model. I welcome comments on = whether this draft provides a format consistent with the current yang = considerations model formats. The purpose behind this draft is to = establish a template for security considerations that the netmod/netconf = experts, I2RS protocol experts, and the security ADs would accept. The = urgency for this discussion is to resolve the valid points made in the = security AD's DISCUSS on these two YANG modules which are key to other = YANG modules. =20 >=20 > Cheerily, > Sue Hares >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 23, 2017 1:34 PM > To: Susan Hares > Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org;=20 > i2rs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > There are no I2RS security guidelines. We should not confuse an = individual I-D with guidelines. >=20 > I believe the regular YANG security guidelines do the work. >=20 > /js >=20 > On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote: > > Giles: > >=20 > > =20 > >=20 > > Thank you for your comments on ODL and your implementation within = ODL. There are two different issues in discussion: guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model. The guidelines for the I2RS Yang Module have = three security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). > >=20 > > =20 > >=20 > > The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 > >=20 > > =20 > >=20 > > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, > >=20 > > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual = authentication as a permissible implementation alternative.=20 > >=20 > > 3) write contention for two clients writing a node using I2RS=20 > > priority (linked to I2RS User-ID) > >=20 > > =20 > >=20 > > If the ODL model does not support writes to these data models, then = it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 > >=20 > > =20 > >=20 > > A) Basic Yang considerations > >=20 > > =20 > >=20 > > 1) readable nodes with sensitive data: Kathleen Moriarty and = Stephen indicate that the topology data could be considered sensitive = read data. A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe. Privacy issues are involved if the topologies are = within homes or indicate user's personal devices. =20 > >=20 > > =20 > >=20 > > If the I2RS mandatory transport is utilized, the data streams = utilize mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages" and support "mechanism = that mitigate DoS attacks" and "DDos prevention". This level of = security is useful when protecting sensitive data. =20 > >=20 > > =20 > >=20 > > 2) writeable nodes with sensitive data: Since the topology nodes = are writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 > >=20 > > =20 > >=20 > > 3) RPCs: No new RPCs are considered, but providing information on = the notification data may be also useful.=20 > >=20 > > =20 > >=20 > > I2RS YANG Model Security Considerations > >=20 > > =20 > >=20 > > The requirement for this section is the following information:=20 > >=20 > > =20 > >=20 > > 1) Indication of deployment requirement for mandatory-to-implement=20 > > NETCONF (RFC7589) or optional RESTCONF=20 > > (draft-ietf-netconf-restconf), > >=20 > > 2) Discussion of RPCs specific to I2RS control plane data store, =20 > >=20 > > 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 > >=20 > > 4) Discussion of data retrieved from routing protocols, system=20 > > information, dynamic configuration (dhcp) > >=20 > > 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 > >=20 > > =20 > >=20 > > For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 > >=20 > > =20 > >=20 > > =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 > >=20 > > =20 > >=20 > > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > >=20 > > =20 > >=20 > > For the topology mode, the access to information on interfaces may = be control by SACM related to the interface model. Any I2RS topology = model termination point configuration which takes augments must take = care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. =E2=80=9C > >=20 > > =20 > >=20 > > For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 > >=20 > > =20 > >=20 > > =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 > >=20 > > =20 > >=20 > > NACM policies may restrict exterior access to this YANG model to = simply read-only. For those NACM policies allowing write-access, there = is a risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 > >=20 > > =20 > >=20 > > For the L3 topology mode, the access to information on interfaces = may be control by SACM related to the interface model. Any I2RS = topology model termination point configuration which takes augments must = take care not to cause fluctuation in the interface state. Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface. DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system. The L3 Topology model may also read = information from the routing protocols (ospf, isis or others), or write = data to the routing protocol. RACM policy should be carefully set so = that the routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C > >=20 > > =20 > >=20 > > =20 > >=20 > > Hopefully, this makes the suggestion for I2RS security policy a bit = more concrete. =20 > >=20 > > =20 > >=20 > > Sue Hares > >=20 > > =20 > >=20 > > =20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > =20 > >=20 > > High-level Yang diagrams for=20 > > draft-ietf-i2rs-yang-network-topo-10.txt > >=20 > > =20 > >=20 > > +--rw networks > >=20 > > +--rw network* [network-id] > >=20 > > +--rw network-types > >=20 > > +--rw network-id network-id > >=20 > > +--ro server-provided? boolean > >=20 > > +--rw supporting-network* [network-ref] > >=20 > > | +--rw network-ref -> /networks/network/network-id > >=20 > > +--rw node* [node-id] > >=20 > > +--rw node-id node-id > >=20 > > +--rw supporting-node* [network-ref node-ref] > >=20 > > +--rw network-ref -> = ../../../supporting-network/ + > >=20 > > | network-ref > >=20 > > +--rw node-ref -> = /networks/network/node/node-id > >=20 > > =20 > >=20 > > module: ietf-network-topology > >=20 > > augment /nd:networks/nd:network: > >=20 > > +--rw link* [link-id] > >=20 > > +--rw source > >=20 > > | +--rw source-node? -> ../../../nd:node/node-id > >=20 > > | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ > >=20 > > | = ../source-node]/termination-point/tp-id > >=20 > > +--rw destination > >=20 > > | +--rw dest-node? -> ../../../nd:node/node-id > >=20 > > | +--rw dest-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ > >=20 > > | ../dest-node]/termination-point/tp-id > >=20 > > +--rw link-id link-id > >=20 > > +--rw supporting-link* [network-ref link-ref] > >=20 > > +--rw network-ref -> ../../../nd:supporting-network/+ > >=20 > > | network-ref > >=20 > > +--rw link-ref -> /nd:networks/network+ > >=20 > > =20 > > [nd:network-id=3Dcurrent()/../network-ref]/+ > >=20 > > link/link-id > >=20 > > =20 > >=20 > > augment /nd:networks/nd:network/nd:node: > >=20 > > +--rw termination-point* [tp-id] > >=20 > > +--rw tp-id tp-id > >=20 > > +--rw supporting-termination-point* [network-ref node-ref=20 > > tp-ref] > >=20 > > +--rw network-ref -> = ../../../nd:supporting-node/network-ref > >=20 > > +--rw node-ref -> = ../../../nd:supporting-node/node-ref > >=20 > > +--rw tp-ref -> = /nd:networks/network[nd:network-id=3D+ > >=20 > > current()/../network-ref]/node+ > >=20 > > [nd:node-id=3Dcurrent()/../node-ref]/+ > >=20 > > termination-point/tp-id > >=20 > > =20 > >=20 > > =20 > >=20 > > module: ietf-l3-unicast-topology > >=20 > > augment /nd:networks/nd:network/nd:network-types: > >=20 > > +--rw l3-unicast-topology! > >=20 > > augment /nd:networks/nd:network: > >=20 > > +--rw l3-topology-attributes > >=20 > > +--rw name? string > >=20 > > +--rw flag* l3-flag-type > >=20 > > augment /nd:networks/nd:network/nd:node: > >=20 > > +--rw l3-node-attributes > >=20 > > +--rw name? inet:domain-name > >=20 > > +--rw flag* node-flag-type > >=20 > > +--rw router-id* inet:ip-address > >=20 > > +--rw prefix* [prefix] > >=20 > > +--rw prefix inet:ip-prefix > >=20 > > +--rw metric? uint32 > >=20 > > +--rw flag* prefix-flag-type > >=20 > > augment /nd:networks/nd:network/lnk:link: > >=20 > > +--rw l3-link-attributes > >=20 > > +--rw name? string > >=20 > > +--rw flag* link-flag-type > >=20 > > +--rw metric? uint32 > >=20 > > augment /nd:networks/nd:network/nd:node/lnk:termination-point: > >=20 > > +--rw l3-termination-point-attributes > >=20 > > +--rw (termination-point-type)? > >=20 > > +--:(ip) > >=20 > > | +--rw ip-address* inet:ip-address > >=20 > > +--:(unnumbered) > >=20 > > | +--rw unnumbered-id? uint32 > >=20 > > +--:(interface-name) > >=20 > > +--ro interface-name? string > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Giles Heron [mailto:giles.heron@gmail.com] > > Sent: Monday, January 23, 2017 6:45 AM > > To: Juergen Schoenwaelder > > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > =20 > >=20 > > ODL does, indeed, implement the topology models, but generally the = data in the topology model is operational data, so I=E2=80=99m not sure = how that fits with =E2=80=9Cdesigned for the I2RS ephemeral control = plane data store=E2=80=9D - since users don=E2=80=99t write to the = models directly (making validation, priority etc. non-issues). > >=20 > > =20 > >=20 > > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder = wrote: > >=20 > > >=20 > >=20 > > > I thought the topology models are coming more or less from > >=20 > > > OpenDaylight. If so, is ODL and I2RS implementation? > >=20 > > >=20 > >=20 > > > /js > >=20 > > >=20 > >=20 > > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: > >=20 > > >> Juergen:=20 > >=20 > > >>=20 > >=20 > > >> Let's focus on your second point. The topology drafts are I2RS=20 > > >> drafts > >=20 > > >> designed for the I2RS ephemeral control plane data store. How = can these be > >=20 > > >> generic YANG modules when the following is true:=20 > >=20 > > >>=20 > >=20 > > >> 1) I2RS Data models do not utilize the configuration data store, > >=20 > > >> 2) I2RS Data Models do not require the same validation as > >=20 > > >> configuration data store, > >=20 > > >> 3) I2RS Data models require the use of priority to handle the > >=20 > > >> multi-write contention problem into the I2RS Control Plane data > >=20 > > >> store, > >=20 > > >> 4) I2RS require TLS with X.509v3 over TCP for the > >=20 > > >> mandatory-to-implement transport, > >=20 > > >>=20 > >=20 > > >> Do you disagree with draft-ietf-netmod-revised-datastores? If=20 > > >> so, > >=20 > > >> the discussion should be taken up with netmod WG list. > >=20 > > >> Do you disagree with i2rs-protocol-security-requirements? That=20 > > >> issue > >=20 > > >> is closed based on IESG approval. > >=20 > > >>=20 > >=20 > > >> Sue Hares > >=20 > > >>=20 > >=20 > > >> -----Original Message----- > >=20 > > >> From: Juergen Schoenwaelder > >=20 > > >> [ > > >> mailto:j.schoenwaelder@jacobs-university.de] > >=20 > > >> Sent: Monday, January 23, 2017 3:39 AM > >=20 > > >> To: Susan Hares > >=20 > > >> Cc: 'Kathleen Moriarty'; 'The IESG'; > >=20 > > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > > >> i2rs@ietf.org; > >=20 > > >> i2rs-chairs@ietf.org > >=20 > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >=20 > > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>=20 > >=20 > > >> Susan, > >=20 > > >>=20 > >=20 > > >> I consider tagging a YANG object statically and universally in=20 > > >> the > >=20 > > >> data model as "does not need secure communication" fundamentally > >=20 > > >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. > >=20 > > >>=20 > >=20 > > >> The topology drafts are regular generic YANG models that just=20 > > >> happen > >=20 > > >> to be done in I2RS - I believe that using the generic YANG=20 > > >> security > >=20 > > >> guidelines we have is good enough to progress these drafts. > >=20 > > >>=20 > >=20 > > >> /js > >=20 > > >>=20 > >=20 > > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > >=20 > > >>> Juergen:=20 > >=20 > > >>>=20 > >=20 > > >>> I recognize that dislike insecure communication. You made a=20 > > >>> similar > >=20 > > >>> comment during the WG LC and IETF review of > >=20 > > >>> draft-ietf-i2rs-protocol-security-requirements. However, the > >=20 > > >>> draft-ietf-i2rs-protocol-security-requirements were passed by=20 > > >>> the > >=20 > > >>> I2RS WG and approved by the IESG for RFC publication and it=20 > > >>> contains > >=20 > > >>> the non-secure communication. The mandate from the I2RS WG for=20 > > >>> this > >=20 > > >>> shepherd/co-chair is clear. > >=20 > > >>>=20 > >=20 > > >>> As the shepherd for the topology drafts, I try to write-up=20 > > >>> something > >=20 > > >>> that might address Kathleen's Moriarty's concerns about the=20 > > >>> topology > >=20 > > >>> draft's security issues about privacy and the I2RS ephemeral=20 > > >>> control > >=20 > > >>> plane > >=20 > > >> data > >=20 > > >>> store. I welcome an open discussion on my ideas > >=20 > > >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > >=20 > > >> The > >=20 > > >>> yang doctor's YANG security consideration template > >=20 > > >>> ( > > >>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines)=20 > > >>> and > >=20 > > >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. > >=20 > > >>> Hopefully, this document extends these guidelines to a new data = store.=20 > >=20 > > >>>=20 > >=20 > > >>> Cheerily, > >=20 > > >>> Sue Hares > >=20 > > >>>=20 > >=20 > > >>> -----Original Message----- > >=20 > > >>> From: Juergen Schoenwaelder > >=20 > > >>> [ > > >>> mailto:j.schoenwaelder@jacobs-university.de] > >=20 > > >>> Sent: Thursday, January 19, 2017 10:34 AM > >=20 > > >>> To: Susan Hares > >=20 > > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; > >=20 > > >>> > > >>> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > > >>> i2rs@ietf.org; > >=20 > > >>> i2rs-chairs@ietf.org > >=20 > > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >=20 > > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>>=20 > >=20 > > >>> For what it is worth, I find the notion that data models may be > >=20 > > >>> written for a specific non-secure transport plain broken. There=20 > > >>> is > >=20 > > >>> hardly any content of a data model I can think of which is=20 > > >>> generally > >=20 > > >>> suitable for insecure transports. > >=20 > > >>>=20 > >=20 > > >>> Can we please kill this idea of _standardizing_ information that = > > >>> is > >=20 > > >>> suitable to send over non-secure transports? I really do not see = > > >>> how > >=20 > > >>> the IETF can make a claim that a given piece of information is=20 > > >>> never > >=20 > > >>> worth protecting (=3D suitable for non-secure transports). > >=20 > > >>>=20 > >=20 > > >>> Note that I am fine if in a certain trusted tightly-coupled > >=20 > > >>> deployment information is shipped in whatever way but this is=20 > > >>> then a > >=20 > > >>> property of the _deployment_ and not a property of the = _information_. > >=20 > > >>>=20 > >=20 > > >>> /js > >=20 > > >>>=20 > >=20 > > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > >=20 > > >>>> Kathleen:=20 > >=20 > > >>>>=20 > >=20 > > >>>> I have written a draft suggesting a template for the I2RS YANG > >=20 > > >>>> modules > >=20 > > >>> which are designed to exist in the I2RS Ephemeral Control Plane=20 > > >>> data store > >=20 > > >>> (configuration and operational state). =20 > >=20 > > >>>>=20 > >=20 > > >>>> Draft location:=20 > >=20 > > >>>> =20 > > >>>> > >>>> si > > >>>> der>=20 > > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons > > >>>> id > > >>>> er > >=20 > > >>>> / > >=20 > > >>>>=20 > >=20 > > >>>> I would appreciate an email discussion with the security ADs, > >=20 > > >>>> OPS/NM ADs, > >=20 > > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data=20 > > >>> model > >=20 > > >>> (L3) and the base I2RS topology model should both provide=20 > > >>> updated > >=20 > > >>> YANG Security Considerations sections. I would appreciate if=20 > > >>> Benoit > >=20 > > >>> or you hold a discuss until we sort out these issues. > >=20 > > >>>>=20 > >=20 > > >>>> Thank you, > >=20 > > >>>>=20 > >=20 > > >>>> Sue > >=20 > > >>>>=20 > >=20 > > >>>> -----Original Message----- > >=20 > > >>>> From: Kathleen Moriarty [ > > >>>> > > >>>> mailto:Kathleen.Moriarty.ietf@gmail.com] > >=20 > > >>>> Sent: Wednesday, January 18, 2017 9:44 PM > >=20 > > >>>> To: The IESG > >=20 > > >>>> Cc: > > >>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; > > >>>> shares@ndzh.com; > >=20 > > >>>> i2rs-chairs@ietf.org;=20 > > >>>> shares@ndzh.com; =20 > > >>>> i2rs@ietf.org > >=20 > > >>>> Subject: Kathleen Moriarty's No Objection on > >=20 > > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > >>>>=20 > >=20 > > >>>> Kathleen Moriarty has entered the following ballot position for > >=20 > > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection > >=20 > > >>>>=20 > >=20 > > >>>> When responding, please keep the subject line intact and reply=20 > > >>>> to > >=20 > > >>>> all email addresses included in the To and CC lines. (Feel free = > > >>>> to > >=20 > > >>>> cut this introductory paragraph, however.) > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> Please refer to > >=20 > > >>>> > > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >=20 > > >>>> for more information about IESG DISCUSS and COMMENT positions. > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> The document, along with other ballot positions, can be found = here: > >=20 > > >>>> =20 > > >>>> > >>>> og > > >>>> y/> > > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo > > >>>> gy > > >>>> / > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> --------------------------------------------------------------- > > >>>> -- > > >>>> -- > >=20 > > >>>> - > >=20 > > >>>> -- > >=20 > > >>>> COMMENT: > >=20 > > >>>> --------------------------------------------------------------- > > >>>> -- > > >>>> -- > >=20 > > >>>> - > >=20 > > >>>> -- > >=20 > > >>>>=20 > >=20 > > >>>> I agree with Alissa's comment that the YANG module security > >=20 > > >>>> consideration > >=20 > > >>> section guidelines need to be followed and this shouldn't go=20 > > >>> forward > >=20 > > >>> until that is corrected. I'm told it will be, thanks. > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>>=20 > >=20 > > >>>> _______________________________________________ > >=20 > > >>>> i2rs mailing list > >=20 > > >>>> i2rs@ietf.org > >=20 > > >>>> > > >>>> https://www.ietf.org/mailman/listinfo/i2rs > >=20 > > >>>=20 > >=20 > > >>> -- > >=20 > > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >=20 > > >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> > >=20 > > >>>=20 > >=20 > > >>=20 > >=20 > > >> -- > >=20 > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >=20 > > >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> > >=20 > > >>=20 > >=20 > > >=20 > >=20 > > > -- > >=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >=20 > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >=20 > > > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> > >=20 > > >=20 > >=20 > > > _______________________________________________ > >=20 > > > i2rs mailing list > >=20 > > > i2rs@ietf.org > >=20 > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > >=20 > > =20 > >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 11:57:04 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 69B94129842; Mon, 23 Jan 2017 11:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc0B9qu-Lv5X; Mon, 23 Jan 2017 11:57:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B2F129847; Mon, 23 Jan 2017 11:56:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 937D96A1; Mon, 23 Jan 2017 20:56:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CdIOA2uRd56w; Mon, 23 Jan 2017 20:56:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 20:56:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23089200A8; Mon, 23 Jan 2017 20:56:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f-y0mHJa1BDO; Mon, 23 Jan 2017 20:56:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFD93200A7; Mon, 23 Jan 2017 20:56:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BFCFA3E47CF6; Mon, 23 Jan 2017 20:56:52 +0100 (CET) Date: Mon, 23 Jan 2017 20:56:52 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123195652.GC33787@elstar.local> Mail-Followup-To: Susan Hares , 'Giles Heron' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , i2rs-chairs@ietf.org References: <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <20170123183401.GB33438@elstar.local> <00dd01d275ab$97ff6400$c7fe2c00$@ndzh.com> <20170123191514.GB33573@elstar.local> <011901d275b1$51574260$f405c720$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <011901d275b1$51574260$f405c720$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:57:03 -0000 In case the modules are indeed only for I2RS agents and this is clearly stated in the document and the module, then feel free to do whatever you think needs to be done. Well, actually, it would be nice to do whatever the I2RS WG wants to be done (which is remarkably silent anyway). I was under the impression that these YANG models are applicable in other contexts as well (e.g. OpenDaylight). If this perception is wrong, then I apologize. And then Benoit probably needs to think about where we get generic topology models defined - but this is then a different problem (and not specifically yours). /js On Mon, Jan 23, 2017 at 02:45:57PM -0500, Susan Hares wrote: > Juergen:=20 >=20 > First of all, I posted an individual I-D to start a discussion. I indica= ted to Benoit Claise that this was my personal recommendation as shepherd a= fter looking at the problem. I have not mandated anything. =20 >=20 > Second, I hear that you want to use the YANG security guidelines, but the= re are 6 differences between the Yang security considerations and the refer= ences in the I2RS security documents and the draft-ietf-nemod-ietf-revised-= datastore-00.txt. If you want to debate these 6 differences or the suggest= ions for the yang security considerations, I am still willing to continue t= his discussion.=20 >=20 > My understanding from this email messages is that you do not want to dis= cuss these differences and how to craft a security considerations section t= hat addresses these differences. =20 >=20 > Cheerily, Sue Hares =20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]= =20 > Sent: Monday, January 23, 2017 2:15 PM > To: Susan Hares > Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.o= rg; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-y= ang-l3-topology-08: (with COMMENT) >=20 > I suggest to use the YANG security guidelines. >=20 > Or, as Martin said, there needs to be a clear statement that these YANG m= odels only apply to I2RS agents and nothing else. >=20 > In any case, I think you can't post an individual I-D and simply declare = it guidelines others are expected to follow. >=20 > /js >=20 > On Mon, Jan 23, 2017 at 02:04:58PM -0500, Susan Hares wrote: > > Juergen:=20 > >=20 > > There are two I2RS drafts related to security: draft-ietf-i2rs-protoco= l-security-requirements and draft-ietf-i2rs-security-environment-reqs-02. = The draft-ietf-i2rs-protocol-security-requirements has pass IESG review and= is waiting for the RFC editor. The draft-i2rs-security-environment-reqs-02= =2Etxt has not passed WG LC. You are correct that draft-hares-i2rs-yang-se= c-consider-00.txt is an individual draft. This individual draft is also ba= sed on draft-ietf-netmod-ietf-revised-datastores-00.txt. =20 > >=20 > > The impetus for this individual draft (draft-hares-i2rs-yang-sec-consid= er) was the DISCUSS by the security ADs regarding security consideration se= ction in two drafts: draft-ietf-i2rs-yang-network-topology and draft-ietf-i= 2rs-yang-l3-topology-08.txt. The draft indicates the following 6 areas wh= ere the I2RS protocol and environment security requirements differ: 1) man= datory-to-implement transport layer, 2) priority and secondary opaque ident= ifier, 3) different data store, 4) different validations in I2RS control p= lane data store, 5) different NACM policy, and 6) optional insecure protoco= l. None of these are handled in the current YANG security considerations = template. Items 1, 2, and 5 are specified in draft-ietf-protocol-securit= y-requirements plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the draft-i2rs-sec= urity-environment-reqs-02.txt. Item 5 arises out of SEC-ENV-REQ-05 and SEC= -ENV-REQ-06 in the draft-ietf-i2rs-security-environment-reqs-02.txt. Items= 3 and 4 arise out of the draft-ietf-netmod-revised-datastores-00.txt. I = welcome a discussion on whether this individual draft truly represents the = content of these 3 drafts. =20 > >=20 > > The individual draft tries to provide the information from the draft-ie= tf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environ= ment-reqs-02.txt in a format consistent with the current Yang Consideration= s model. I welcome comments on whether this draft provides a format consi= stent with the current yang considerations model formats. The purpose behi= nd this draft is to establish a template for security considerations that t= he netmod/netconf experts, I2RS protocol experts, and the security ADs woul= d accept. The urgency for this discussion is to resolve the valid points m= ade in the security AD's DISCUSS on these two YANG modules which are key to= other YANG modules. =20 > >=20 > > Cheerily, > > Sue Hares > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder=20 > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, January 23, 2017 1:34 PM > > To: Susan Hares > > Cc: 'Giles Heron'; draft-ietf-i2rs-yang-l3-topology@ietf.org;=20 > > i2rs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > There are no I2RS security guidelines. We should not confuse an individ= ual I-D with guidelines. > >=20 > > I believe the regular YANG security guidelines do the work. > >=20 > > /js > >=20 > > On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares wrote: > > > Giles: > > >=20 > > > =20 > > >=20 > > > Thank you for your comments on ODL and your implementation within ODL= =2E There are two different issues in discussion: guidelines for I2RS Ya= ng modules and the application of these guidelines to the I2RS Yang Topolog= y model. The guidelines for the I2RS Yang Module have three security cons= iderations: a) basic yang considerations, b) I2RS ephemeral state conside= rations, and c) insecure considerations. Since the topology model does no= t operate over an insecure transport, the only thing that I believe you are= questioning is the "I2RS Yang Models for Secure-Only transports". Let'= s walk through the draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-= topology) and the draft-ietf-i2rs-yang-network-topo models (ietf-network, i= etf-network-topology). > > >=20 > > > =20 > > >=20 > > > The topology model as described in draft-ietf-i2rs-yang-network-topo-= 10.txt has read/write nodes at the network, link and termination point. Pl= ease see the copy of the YHL diagrams below. Therefore, the basic topology = model is read-write. The L3 model (draft-ietf-i2rs-yang-l3-topology-08.tx= t) is read write. Please see a copy of the YHL diagrams below. Therefore,= although your implementation is read-only, the approved YANG modules are r= ead-write. This must be considered in the Security considerations section.= The basic requirements for I2RS are:=20 > > >=20 > > > =20 > > >=20 > > > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, > > >=20 > > > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authenticati= on as a permissible implementation alternative.=20 > > >=20 > > > 3) write contention for two clients writing a node using I2RS=20 > > > priority (linked to I2RS User-ID) > > >=20 > > > =20 > > >=20 > > > If the ODL model does not support writes to these data models, then i= t would not have to support the priority mechanism to resolve two clients w= riting one data node. =20 > > >=20 > > > =20 > > >=20 > > > A) Basic Yang considerations > > >=20 > > > =20 > > >=20 > > > 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen= indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved in pr= oviding this information, and how deployments can keep this data safe. Pr= ivacy issues are involved if the topologies are within homes or indicate us= er's personal devices. =20 > > >=20 > > > =20 > > >=20 > > > If the I2RS mandatory transport is utilized, the data streams utilize= mutual authentication, confidentiality, data integrity, and [practical] re= play protection for I2RS messages" and support "mechanism that mitigate DoS= attacks" and "DDos prevention". This level of security is useful when pro= tecting sensitive data. =20 > > >=20 > > > =20 > > >=20 > > > 2) writeable nodes with sensitive data: Since the topology nodes are= writeable, a security considerations needs to consider how these sensitiv= e data nodes will be protected. While ODL does not support writes to any = data node, the base models do. Therefore, security considerations must be w= ritten here.=20 > > >=20 > > > =20 > > >=20 > > > 3) RPCs: No new RPCs are considered, but providing information on the= notification data may be also useful.=20 > > >=20 > > > =20 > > >=20 > > > I2RS YANG Model Security Considerations > > >=20 > > > =20 > > >=20 > > > The requirement for this section is the following information:=20 > > >=20 > > > =20 > > >=20 > > > 1) Indication of deployment requirement for mandatory-to-implement=20 > > > NETCONF (RFC7589) or optional RESTCONF=20 > > > (draft-ietf-netconf-restconf), > > >=20 > > > 2) Discussion of RPCs specific to I2RS control plane data store, =20 > > >=20 > > > 3) NACM policy impacts the read-write state and augmentation of NACM = by access control for read/writing of routing protocols (RACM), system inf= ormation (SACM), and between datastores (config to/from ephemeral state).= =20 > > >=20 > > > 4) Discussion of data retrieved from routing protocols, system=20 > > > information, dynamic configuration (dhcp) > > >=20 > > > 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over oth= er operational state.=20 > > >=20 > > > =20 > > >=20 > > > For the topology data models (ietf-network, ietf-network-topology), = the paragraph could be:=20 > > >=20 > > > =20 > > >=20 > > > =E2=80=9CThe I2RS topology data models (ietf-network, ietf-network-to= pology) require mutual authentication, confidentiality, data integrity, and= [practical] replay protection for I2RS messages. Therefore, there is a man= datory-to-implement transport protocol of TLS (see RFC7589), or an optional= transport support of RESTCONF (draft-ietf-netconf-restconf). This data= model does not implement any additional RPCs specific to this data model o= r any notifications. =20 > > >=20 > > > =20 > > >=20 > > > NACM policies may restrict exterior access to this YANG model to simp= ly read-only. For those NACM policies allowing write-access, there is a ri= sk that a write to a topology may create a looping topology or overload a p= articular node. NACM policies may be augment by routing protocol access co= ntrol methods (RACM), system data access control methods (SACM), and inter-= data store access control mechanisms (DACM). The engagement of this policy= should also be control by user policy switches (on/of). =20 > > >=20 > > > =20 > > >=20 > > > For the topology mode, the access to information on interfaces may be= control by SACM related to the interface model. Any I2RS topology model t= ermination point configuration which takes augments must take care not to c= ause fluctuation in the interface state. Dynamic configuration protocols = such as DHCP or DHCPv6 may also alter the IP Addresses associated with an i= nterface. DACM related to the inter-datastore policy on the precedence bet= ween configuration of interface IP addresses, DHCP/DHCPv6 configuration, or= Topology configuration will need to make sure the interface IP address doe= s not cause fluctuations in the system. Deployments may provide general co= nfiguration knobs that set the default state for NACM, RACM, SACM and DACM = for the topology database. =E2=80=9C > > >=20 > > > =20 > > >=20 > > > For the L3 topology data models (ietf-l3-unicast-topology), the para= graph could be:=20 > > >=20 > > > =20 > > >=20 > > > =E2=80=9CThe I2RS L3 Unicast topology data model (ietf-l3-unicast-top= ology) require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a mand= atory-to-implement transport protocol of NETCONF over TLS with X.509v3 mutu= al authentication (RFC7589), or an optional transport support of RESTCONF (= draft-ietf-netconf-restconf). This data model does not implement any ad= ditional RPCs specific to this data model. This data model does support th= e following new notifications: l3-node-event, l3-link-event, l3-prefix-even= t, and termination-point-event. These events provide the information abou= t the changing L3 topology which may provide information regarding key node= s. Since these events are only transported over secure transports that sup= port mutual authentication, confidentiality, data integrity, and [practice]= replay protection, the use of this information for DoS of an I2RS agent (a= ka NETCONF server) requires the mutual authenticated client to be suborned.= =20 > > >=20 > > > =20 > > >=20 > > > NACM policies may restrict exterior access to this YANG model to simp= ly read-only. For those NACM policies allowing write-access, there is a ri= sk that a write to a topology may create a looping topology or overload a p= articular node. NACM policies may be augment by routing protocol access co= ntrol methods (RACM), system data access control methods (SACM), and inter-= data store access control mechanisms (DACM). The engagement of this policy= should also be control by user policy switches (on/of). =20 > > >=20 > > > =20 > > >=20 > > > For the L3 topology mode, the access to information on interfaces may= be control by SACM related to the interface model. Any I2RS topology mode= l termination point configuration which takes augments must take care not t= o cause fluctuation in the interface state. Dynamic configuration protoco= ls such as DHCP or DHCPv6 may also alter the IP Addresses associated with a= n interface. DACM related to the inter-datastore policy on the precedence = between configuration of interface IP addresses, DHCP/DHCPv6 configuration,= or Topology configuration will need to make sure the interface IP address = does not cause fluctuations in the system. The L3 Topology model may also= read information from the routing protocols (ospf, isis or others), or wri= te data to the routing protocol. RACM policy should be carefully set so th= at the routing protocols do not form a place to launch a DoS attack. Deplo= yments may provide general configuration knobs that set the default state f= or NACM, RACM, SACM and DACM for the topology database. =E2=80=9C > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > Hopefully, this makes the suggestion for I2RS security policy a bit m= ore concrete. =20 > > >=20 > > > =20 > > >=20 > > > Sue Hares > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > =20 > > >=20 > > > High-level Yang diagrams for=20 > > > draft-ietf-i2rs-yang-network-topo-10.txt > > >=20 > > > =20 > > >=20 > > > +--rw networks > > >=20 > > > +--rw network* [network-id] > > >=20 > > > +--rw network-types > > >=20 > > > +--rw network-id network-id > > >=20 > > > +--ro server-provided? boolean > > >=20 > > > +--rw supporting-network* [network-ref] > > >=20 > > > | +--rw network-ref -> /networks/network/network-id > > >=20 > > > +--rw node* [node-id] > > >=20 > > > +--rw node-id node-id > > >=20 > > > +--rw supporting-node* [network-ref node-ref] > > >=20 > > > +--rw network-ref -> ../../../supporting-network= / + > > >=20 > > > | network-ref > > >=20 > > > +--rw node-ref -> /networks/network/node/node= -id > > >=20 > > > =20 > > >=20 > > > module: ietf-network-topology > > >=20 > > > augment /nd:networks/nd:network: > > >=20 > > > +--rw link* [link-id] > > >=20 > > > +--rw source > > >=20 > > > | +--rw source-node? -> ../../../nd:node/node-id > > >=20 > > > | +--rw source-tp? -> ../../../nd:node[nd:node-id=3Dcurren= t()/+ > > >=20 > > > | ../source-node]/termination-point/tp-id > > >=20 > > > +--rw destination > > >=20 > > > | +--rw dest-node? -> ../../../nd:node/node-id > > >=20 > > > | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent(= )/+ > > >=20 > > > | ../dest-node]/termination-point/tp-id > > >=20 > > > +--rw link-id link-id > > >=20 > > > +--rw supporting-link* [network-ref link-ref] > > >=20 > > > +--rw network-ref -> ../../../nd:supporting-network/+ > > >=20 > > > | network-ref > > >=20 > > > +--rw link-ref -> /nd:networks/network+ > > >=20 > > > =20 > > > [nd:network-id=3Dcurrent()/../network-ref]/+ > > >=20 > > > link/link-id > > >=20 > > > =20 > > >=20 > > > augment /nd:networks/nd:network/nd:node: > > >=20 > > > +--rw termination-point* [tp-id] > > >=20 > > > +--rw tp-id tp-id > > >=20 > > > +--rw supporting-termination-point* [network-ref node-ref=20 > > > tp-ref] > > >=20 > > > +--rw network-ref -> ../../../nd:supporting-node/network-= ref > > >=20 > > > +--rw node-ref -> ../../../nd:supporting-node/node-ref > > >=20 > > > +--rw tp-ref -> /nd:networks/network[nd:network-id= =3D+ > > >=20 > > > current()/../network-ref]/node+ > > >=20 > > > [nd:node-id=3Dcurrent()/../node-ref]/+ > > >=20 > > > termination-point/tp-id > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > module: ietf-l3-unicast-topology > > >=20 > > > augment /nd:networks/nd:network/nd:network-types: > > >=20 > > > +--rw l3-unicast-topology! > > >=20 > > > augment /nd:networks/nd:network: > > >=20 > > > +--rw l3-topology-attributes > > >=20 > > > +--rw name? string > > >=20 > > > +--rw flag* l3-flag-type > > >=20 > > > augment /nd:networks/nd:network/nd:node: > > >=20 > > > +--rw l3-node-attributes > > >=20 > > > +--rw name? inet:domain-name > > >=20 > > > +--rw flag* node-flag-type > > >=20 > > > +--rw router-id* inet:ip-address > > >=20 > > > +--rw prefix* [prefix] > > >=20 > > > +--rw prefix inet:ip-prefix > > >=20 > > > +--rw metric? uint32 > > >=20 > > > +--rw flag* prefix-flag-type > > >=20 > > > augment /nd:networks/nd:network/lnk:link: > > >=20 > > > +--rw l3-link-attributes > > >=20 > > > +--rw name? string > > >=20 > > > +--rw flag* link-flag-type > > >=20 > > > +--rw metric? uint32 > > >=20 > > > augment /nd:networks/nd:network/nd:node/lnk:termination-point: > > >=20 > > > +--rw l3-termination-point-attributes > > >=20 > > > +--rw (termination-point-type)? > > >=20 > > > +--:(ip) > > >=20 > > > | +--rw ip-address* inet:ip-address > > >=20 > > > +--:(unnumbered) > > >=20 > > > | +--rw unnumbered-id? uint32 > > >=20 > > > +--:(interface-name) > > >=20 > > > +--ro interface-name? string > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Monday, January 23, 2017 6:45 AM > > > To: Juergen Schoenwaelder > > > Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-chairs@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >=20 > > > =20 > > >=20 > > > ODL does, indeed, implement the topology models, but generally the da= ta in the topology model is operational data, so I=E2=80=99m not sure how t= hat fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data s= tore=E2=80=9D - since users don=E2=80=99t write to the models directly (mak= ing validation, priority etc. non-issues). > > >=20 > > > =20 > > >=20 > > > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder wrote: > > >=20 > > > >=20 > > >=20 > > > > I thought the topology models are coming more or less from > > >=20 > > > > OpenDaylight. If so, is ODL and I2RS implementation? > > >=20 > > > >=20 > > >=20 > > > > /js > > >=20 > > > >=20 > > >=20 > > > > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: > > >=20 > > > >> Juergen:=20 > > >=20 > > > >>=20 > > >=20 > > > >> Let's focus on your second point. The topology drafts are I2RS=20 > > > >> drafts > > >=20 > > > >> designed for the I2RS ephemeral control plane data store. How ca= n these be > > >=20 > > > >> generic YANG modules when the following is true:=20 > > >=20 > > > >>=20 > > >=20 > > > >> 1) I2RS Data models do not utilize the configuration data store, > > >=20 > > > >> 2) I2RS Data Models do not require the same validation as > > >=20 > > > >> configuration data store, > > >=20 > > > >> 3) I2RS Data models require the use of priority to handle the > > >=20 > > > >> multi-write contention problem into the I2RS Control Plane data > > >=20 > > > >> store, > > >=20 > > > >> 4) I2RS require TLS with X.509v3 over TCP for the > > >=20 > > > >> mandatory-to-implement transport, > > >=20 > > > >>=20 > > >=20 > > > >> Do you disagree with draft-ietf-netmod-revised-datastores? If=20 > > > >> so, > > >=20 > > > >> the discussion should be taken up with netmod WG list. > > >=20 > > > >> Do you disagree with i2rs-protocol-security-requirements? That=20 > > > >> issue > > >=20 > > > >> is closed based on IESG approval. > > >=20 > > > >>=20 > > >=20 > > > >> Sue Hares > > >=20 > > > >>=20 > > >=20 > > > >> -----Original Message----- > > >=20 > > > >> From: Juergen Schoenwaelder > > >=20 > > > >> [ > > > >> mailto:j.schoenwaelder@jacobs-university.de] > > >=20 > > > >> Sent: Monday, January 23, 2017 3:39 AM > > >=20 > > > >> To: Susan Hares > > >=20 > > > >> Cc: 'Kathleen Moriarty'; 'The IESG'; > > >=20 > > > >> > > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > > > >> i2rs@ietf.org; > > >=20 > > > >> i2rs-chairs@ietf.org > > >=20 > > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >=20 > > > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >=20 > > > >>=20 > > >=20 > > > >> Susan, > > >=20 > > > >>=20 > > >=20 > > > >> I consider tagging a YANG object statically and universally in=20 > > > >> the > > >=20 > > > >> data model as "does not need secure communication" fundamentally > > >=20 > > > >> flawed; I am not having an issue with insecure communication in ce= rtain deployment contexts. > > >=20 > > > >>=20 > > >=20 > > > >> The topology drafts are regular generic YANG models that just=20 > > > >> happen > > >=20 > > > >> to be done in I2RS - I believe that using the generic YANG=20 > > > >> security > > >=20 > > > >> guidelines we have is good enough to progress these drafts. > > >=20 > > > >>=20 > > >=20 > > > >> /js > > >=20 > > > >>=20 > > >=20 > > > >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > >=20 > > > >>> Juergen:=20 > > >=20 > > > >>>=20 > > >=20 > > > >>> I recognize that dislike insecure communication. You made a=20 > > > >>> similar > > >=20 > > > >>> comment during the WG LC and IETF review of > > >=20 > > > >>> draft-ietf-i2rs-protocol-security-requirements. However, the > > >=20 > > > >>> draft-ietf-i2rs-protocol-security-requirements were passed by=20 > > > >>> the > > >=20 > > > >>> I2RS WG and approved by the IESG for RFC publication and it=20 > > > >>> contains > > >=20 > > > >>> the non-secure communication. The mandate from the I2RS WG for= =20 > > > >>> this > > >=20 > > > >>> shepherd/co-chair is clear. > > >=20 > > > >>>=20 > > >=20 > > > >>> As the shepherd for the topology drafts, I try to write-up=20 > > > >>> something > > >=20 > > > >>> that might address Kathleen's Moriarty's concerns about the=20 > > > >>> topology > > >=20 > > > >>> draft's security issues about privacy and the I2RS ephemeral=20 > > > >>> control > > >=20 > > > >>> plane > > >=20 > > > >> data > > >=20 > > > >>> store. I welcome an open discussion on my ideas > > >=20 > > > >>> ( https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > >=20 > > > >> The > > >=20 > > > >>> yang doctor's YANG security consideration template > > >=20 > > > >>> ( > > > >>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines)=20 > > > >>> and > > >=20 > > > >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. > > >=20 > > > >>> Hopefully, this document extends these guidelines to a new data s= tore.=20 > > >=20 > > > >>>=20 > > >=20 > > > >>> Cheerily, > > >=20 > > > >>> Sue Hares > > >=20 > > > >>>=20 > > >=20 > > > >>> -----Original Message----- > > >=20 > > > >>> From: Juergen Schoenwaelder > > >=20 > > > >>> [ > > > >>> mailto:j.schoenwaelder@jacobs-university.de] > > >=20 > > > >>> Sent: Thursday, January 19, 2017 10:34 AM > > >=20 > > > >>> To: Susan Hares > > >=20 > > > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; > > >=20 > > > >>> > > > >>> draft-ietf-i2rs-yang-l3-topology@ietf.org; =20 > > > >>> i2rs@ietf.org; > > >=20 > > > >>> i2rs-chairs@ietf.org > > >=20 > > > >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >=20 > > > >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >=20 > > > >>>=20 > > >=20 > > > >>> For what it is worth, I find the notion that data models may be > > >=20 > > > >>> written for a specific non-secure transport plain broken. There= =20 > > > >>> is > > >=20 > > > >>> hardly any content of a data model I can think of which is=20 > > > >>> generally > > >=20 > > > >>> suitable for insecure transports. > > >=20 > > > >>>=20 > > >=20 > > > >>> Can we please kill this idea of _standardizing_ information that= =20 > > > >>> is > > >=20 > > > >>> suitable to send over non-secure transports? I really do not see= =20 > > > >>> how > > >=20 > > > >>> the IETF can make a claim that a given piece of information is=20 > > > >>> never > > >=20 > > > >>> worth protecting (=3D suitable for non-secure transports). > > >=20 > > > >>>=20 > > >=20 > > > >>> Note that I am fine if in a certain trusted tightly-coupled > > >=20 > > > >>> deployment information is shipped in whatever way but this is=20 > > > >>> then a > > >=20 > > > >>> property of the _deployment_ and not a property of the _informati= on_. > > >=20 > > > >>>=20 > > >=20 > > > >>> /js > > >=20 > > > >>>=20 > > >=20 > > > >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > >=20 > > > >>>> Kathleen:=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> I have written a draft suggesting a template for the I2RS YANG > > >=20 > > > >>>> modules > > >=20 > > > >>> which are designed to exist in the I2RS Ephemeral Control Plane= =20 > > > >>> data store > > >=20 > > > >>> (configuration and operational state). =20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> Draft location:=20 > > >=20 > > > >>>> =20 > > > >>>> > > >>>> si > > > >>>> der>=20 > > > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons > > > >>>> id > > > >>>> er > > >=20 > > > >>>> / > > >=20 > > > >>>>=20 > > >=20 > > > >>>> I would appreciate an email discussion with the security ADs, > > >=20 > > > >>>> OPS/NM ADs, > > >=20 > > > >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data=20 > > > >>> model > > >=20 > > > >>> (L3) and the base I2RS topology model should both provide=20 > > > >>> updated > > >=20 > > > >>> YANG Security Considerations sections. I would appreciate if=20 > > > >>> Benoit > > >=20 > > > >>> or you hold a discuss until we sort out these issues. > > >=20 > > > >>>>=20 > > >=20 > > > >>>> Thank you, > > >=20 > > > >>>>=20 > > >=20 > > > >>>> Sue > > >=20 > > > >>>>=20 > > >=20 > > > >>>> -----Original Message----- > > >=20 > > > >>>> From: Kathleen Moriarty [ > > > >>>> > > > >>>> mailto:Kathleen.Moriarty.ietf@gmail.com] > > >=20 > > > >>>> Sent: Wednesday, January 18, 2017 9:44 PM > > >=20 > > > >>>> To: The IESG > > >=20 > > > >>>> Cc: > > > >>>> draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > >>>> shares@ndzh.com; > > >=20 > > > >>>> i2rs-chairs@ietf.org;=20 > > > >>>> shares@ndzh.com; =20 > > > >>>> i2rs@ietf.org > > >=20 > > > >>>> Subject: Kathleen Moriarty's No Objection on > > >=20 > > > >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >=20 > > > >>>>=20 > > >=20 > > > >>>> Kathleen Moriarty has entered the following ballot position for > > >=20 > > > >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection > > >=20 > > > >>>>=20 > > >=20 > > > >>>> When responding, please keep the subject line intact and reply= =20 > > > >>>> to > > >=20 > > > >>>> all email addresses included in the To and CC lines. (Feel free= =20 > > > >>>> to > > >=20 > > > >>>> cut this introductory paragraph, however.) > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> Please refer to > > >=20 > > > >>>> > > > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > > >=20 > > > >>>> for more information about IESG DISCUSS and COMMENT positions. > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> The document, along with other ballot positions, can be found he= re: > > >=20 > > > >>>> =20 > > > >>>> > > >>>> og > > > >>>> y/> > > > >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topolo > > > >>>> gy > > > >>>> / > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> --------------------------------------------------------------- > > > >>>> -- > > > >>>> -- > > >=20 > > > >>>> - > > >=20 > > > >>>> -- > > >=20 > > > >>>> COMMENT: > > >=20 > > > >>>> --------------------------------------------------------------- > > > >>>> -- > > > >>>> -- > > >=20 > > > >>>> - > > >=20 > > > >>>> -- > > >=20 > > > >>>>=20 > > >=20 > > > >>>> I agree with Alissa's comment that the YANG module security > > >=20 > > > >>>> consideration > > >=20 > > > >>> section guidelines need to be followed and this shouldn't go=20 > > > >>> forward > > >=20 > > > >>> until that is corrected. I'm told it will be, thanks. > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>>=20 > > >=20 > > > >>>> _______________________________________________ > > >=20 > > > >>>> i2rs mailing list > > >=20 > > > >>>> i2rs@ietf.org > > >=20 > > > >>>> > > > >>>> https://www.ietf.org/mailman/listinfo/i2rs > > >=20 > > > >>>=20 > > >=20 > > > >>> -- > > >=20 > > > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >=20 > > > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Ge= rmany > > >=20 > > > >>> Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > > >=20 > > > >>>=20 > > >=20 > > > >>=20 > > >=20 > > > >> -- > > >=20 > > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >=20 > > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Ger= many > > >=20 > > > >> Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > > >=20 > > > >>=20 > > >=20 > > > >=20 > > >=20 > > > > -- > > >=20 > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >=20 > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > >=20 > > > > Fax: +49 421 200 3103 < http://www.jacobs-university.de/> > > >=20 > > > >=20 > > >=20 > > > > _______________________________________________ > > >=20 > > > > i2rs mailing list > > >=20 > > > > i2rs@ietf.org > > >=20 > > > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > >=20 > > > =20 > > >=20 > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 12:26:29 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 CE24A129868; Mon, 23 Jan 2017 12:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHdrDQxXmEEE; Mon, 23 Jan 2017 12:26:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78A581297F3; Mon, 23 Jan 2017 12:26:24 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E2621AE02EF; Mon, 23 Jan 2017 21:26:21 +0100 (CET) Date: Mon, 23 Jan 2017 21:26:21 +0100 (CET) Message-Id: <20170123.212621.119545616051737472.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <010a01d275b0$183d7360$48b85a20$@ndzh.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 20:26:28 -0000 "Susan Hares" wrote: > Martin: > > > > I'm pulling your questions to the top of this email. > > > > Question 1: Ok. Just to make sure I understand this correctly - these > topology models are intended to be I2RS-specific, and they cannot be used > for any other purpose. If anyone needs a general topology model outside of > the I2RS protocol, they will have to design their own model. Is this > correct? > > > > Response 1: Not really. Ok, so are you saying that the models are in fact generic, and can be used outside of I2RS? I.e., they *can* be used with the normal configuration datastores? > Most of the topology models I have seen abide by the concepts found in the > I2RS topology model. See the diagram below. The 6 differences for > security listed in my draft are: 1) different mandatory transport for > NETCONF (use RFC7895), 2) support for priority for write conflicts plus > secondary opaque identifier for tracing, 3) optional insecure protocol, 4) > different data store, 5) different validations for data store(optional), > and 6) different NACM policy (optional) plus backend policy (to/from routing > protocols, to/from system). Using RESTCONF (which is fine as is) is an > option that I suspect most Topology models will use. > > > > The current topology models implemented tend to 1) use RESTCONF, 2) use > read-only and do not support tracing, 3) do not allow insecure protocols, > and 4) operate as a different data store (that is they load from internal > protocols), and 6) may use different NACM policy (for nodes) and provide > some logic for back-end policy. What needs to be refined is the > client-write Topology models based on the I2RS Control Plane datastore (e.g. > or read-data datastore or write data datastore) . This concept is coming > from the netmod working group > draft-ietf-netmod-ietf-revised-datastores-00.txt. The netmod WG has cycled > on many different ways to handle I2RS ephemeral data store, and settled on > this proposal. Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly work-in-progress, and (2) none of the topology drafts reference draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a solution in that draft, it is not very clear to the reader. > Questions 2: To me, it feels weird that a model that is designed solely for > the I2RS protocol is published *before* the details of the I2RS protocol are > defined. But it this is what the WG wants, then a note that explains this > would be useful. I assume that the idea is that vendors will use some > proprietary mechanism for now. > > > > Response: Due to the wide spread use of the topology models, the I2RS WG > passed WG LC on these YANG models and Benoit Claise review felt it was ok. Since the documents don't mention it, I think that some people might have missed the fact that these models are intended to be used solely for the I2RS protocol - if that is correct; I must admit that I am a bit confused at this point. > The benefit in this approach is that the main structures are stable. The > deficit is that adding the I2RS protocol definitions could cause changes. > The I2RS protocol depends on the revised data store model > (draft-ietf-netmod-revised-datastores, the revised NACM > (draft-ietf-netconf-rfc6536bis-00.txt, the advances in the notification and > pub/sub solutions, and proposals for I2RS protocol implementation in NETCONF > and RESTCONF. I have individual proposal for the I2RS protocol (get-data > datastore and write-data datastore) that I would like some private review of > these proposals prior to sending them to NETCONF. /martin > > > > Cheerily, > > Sue Hares > > > > part4 > > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, January 23, 2017 1:47 PM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > Martin: > > > > > > Answers inline. > > > > > > -----Original Message----- > > > From: i2rs [ mailto:i2rs-bounces@ietf.org] > On Behalf Of Martin > > > Bjorklund > > > Sent: Monday, January 23, 2017 10:32 AM > > > To: shares@ndzh.com > > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > j.schoenwaelder@jacobs-university.de; > i2rs-chairs@ietf.org; > > > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > >> Martin: > > > >> > > > >> > > > >> > > > >> Thank you for your insightful questions. My answer to your > > > >> questions come from my understanding of the > > > >> draft-ietf-netmod-revised-datastores-00 > > > and > > > >> discussions with that design team at IETF 97. We have been moving > many > > > >> things in parallel at the IETF rather than do single threaded work. > The > > > >> Topoology work was completed 1 year in advance of the > > > >> draft-ietf-netmod-revised-datastores-00.txt. > > > > > > >Right; this is why I think an additional note in these modules are > > > necessary. If you just read these topoly drafts, you will find a > > > normal YANG module that has a "config true" subtree. > > > >Without additional guidance, it is not clear that these data models > > > >"do not > > > utilize the configuration data store" (if this is true). > > > > > > Sue: Sounds like a good idea. I'll suggest this to the authors as the > > > document shepherd. > > > > > > >> #1) model's nodes are "config true", and that "The YANG module > > > >> defined in this memo is designed to be accessed via the NETCONF > > > >> protocol". If it is true that these data models do not utilize the > > > >> configuration data stores, what does the "server-provided" leaf, > > > >> and the text about > > > "client-configured" > > > >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > > > >> > > > >> If the server-provided leaf is true, it indicates that the data is > > > >> populated by the I2RS Agent (aka netconf server) > > > > > > >Doesn't this procedure involve the normal configuration data stores? > > > >If it does, I think we're good. If it doesn't, I think the > > > >additional note > > > should be added. > > > > > > Sue: The model is in the I2RS control plane data store. According to > > > draft-ietf-netmod-revised-datatstores-00.txt this is note the normal > > > configuration data store. > > > > Ok. Just to make sure I understand this correctly - these topology models > are intended to be I2RS-specific, and they cannot be used for any other > purpose. If anyone needs a general topology model outside of the I2RS > protocol, they will have to design their own model. Is this correct? > > > > > Does a note in the text plus a note at the beginning of the data model > > > suffice? > > > > To me, it feels weird that a model that is designed solely for the I2RS > protocol is published *before* the details of the I2RS protocol are defined. > But it this is what the WG wants, then a note that explains this would be > useful. I assume that the idea is that vendors will use some proprietary > mechanism for now. > > > > > > > >> rather than the I2RS Client (aka > > > >> netconf client). The I2RS architecture has aligned the two > > > architecture > > > >> concepts so the I2RS protocol is designed to be a re-use protocol > > > >> for the NETCONF protocol and the RESTCONF protocols as its message > > > >> transport protocols. > > > >> > > > >> draft-ietf-netmod-revised-datastores-00 states the following three > > > >> suggestions for supporting different datastores: > > > >> > > > >> > > > >> o For systems supporting or configuration > > > >> > > > >> datastores, the operation may be used to > > > >> retrieve > > > >> > > > >> data stored in these new datastores. > > > >> > > > >> > > > >> > > > >> o A new operation should be added to retrieve the operational > > > >> state > > > >> > > > >> data store (e.g., ). An alternative is to define > > > >> a > > > >> > > > >> new operation to retrieve data from any datastore (e.g., > > > >> > > > >> with the name of the datastore as a parameter). > > > >> In > > > >> > > > >> principle could work but it would be a > > > >> confusing > > > >> > > > >> name. > > > >> > > > >> > > > >> > > > >> o The operation will be deprecated since it returns data > > > >> from > > > >> > > > >> two datastores that may overlap in the revised datastore model. > > > >> > > > >> > > > >> > > > >> Based on this input, the I2RS ephemeral control plane data store > > > >> should use a "get-data I2RS-ephemeral" to get data from the I2RS > > > ephemeral data store > > > >> (CT, RW). To retrieve information from the applied configuration data > > > >> store, the "get-config" may be used. To retrieve state from the > > > >> operational state "get-state" should be used. > > > >> > > > >> > > > >> 2) Your suggestion to add another note about configuration true > > > >> > > > >> The config "true" is being implemented as the > > > >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see > > > diagram). > > > >> It is just in a different data store. Where and how the data store > > > >> information is stored, is unclear to me at this time. Where do you > > > >> think it belongs? > > > > > > > I always thought that the topology models could be written to > > > > through the > > > normal configuration data stores, in which case the server would set > > > the "server-provided" leaf to "false". It seems that you have some > > > other mechanism in mind? > > > > > > The design team for drat-ietf-netmod-revised-datastores-00.txt > > > indicated that the client written topology with "server-provided" leaf set > to "false" > > > is written in the I2RS Control Plane data store. > > > > Ok. As you might know, I am the editor for > drat-ietf-netmod-revised-datastores-00, and thus part of the design team, > and I haven't seen any discussion about this. Was it discussed on the I2RS > ML? > > > > > > /martin > > > > > > > An I2RS implementation > > > then combines the I2RS Control Plane data store with the intended > > > configuration data store (based on internal configuration knobs) and > > > installs this in a node. A client can query the topology data nodes > > > in the applied configuration data store. The response giving the > > > topology nodes will indicate that a dynamic control plane protocol > inserted these nodes. > > > > > > I am only trying to interpret the netmod design and align the I2RS > > > data models (topology, RIB, FB-RIB) to this design. > > > > > > Thank you for your suggestions on the data model. > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > 3) implementations > > > > > > > > > > > > > > > > Right now, the ODL implementation can utilize "get-config" to obtain > > > > the I2RS topology model since the I2RS topology database has no > > > > equivalent in the intended config. After the > > > > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > > > > will return from the applied configuration the Topology model with > > > > an > > > indication that it is dynamic (see > > > > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > > > > implementation can simply augment its current get-config with an > > > indication > > > > that the topology model is a "dynamic" data store. > > > > > > > > > > > > > > > > As another example, my understanding is that a change to the ConfD > > > > implementation would be to allow a "get-data" and "write-data" that > allows > > > > the specification of a data store such as the I2RS data store. A > > > > get-config of the applied data store should have a "dynamic" flag > > > > for the topology database. > > > > > > > > > > > > > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > > > > but I am behind on event email. > > > > > > > > > > > > > > > > Cheerily, > > > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [ mailto:mbj@tail-f.com] > > > > Sent: Monday, January 23, 2017 6:47 AM > > > > To: shares@ndzh.com > > > > Cc: > j.schoenwaelder@jacobs-university.de; > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org; > > > > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > > > > i2rs-chairs@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > "Susan Hares" < < mailto:shares@ndzh.com> > shares@ndzh.com> wrote: > > > > > > > > > Juergen: > > > > > > > > > > > > > > > > > > Let's focus on your second point. The topology drafts are I2RS > > > > > drafts > > > > > > > > > designed for the I2RS ephemeral control plane data store. How can > > > these > > > > be > > > > > > > > > generic YANG modules when the following is true: > > > > > > > > > > > > > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > > > > > > > > > > > > > This was not clear to me. I note that the data model's nodes are > > > > "config true", and that "The YANG module defined in this memo is > > > > designed to be accessed via the NETCONF protocol". > > > > > > > > > > > > > > > > If it is true that these data models do not utilize the > > > > configuration data stores, what does the "server-provided" leaf, and > > > > the text about "client-configured" in section 4.4.10 of > > > > draft-ietf-i2rs-yang-network-topo refer to? > > > > > > > > > > > > > > > > If in fact this is correct, I think it would be helpful if a note > > > > was added to the YANG modules, that explains that these models are > > > > not supposed to be implemented in the same way as other "config > > > > true" data models. In the best of worlds it would also describe how > > > > they are supposed to be implemented (but I assume that this is up to > > > > each vendor > > > for now). > > > > > > > > > > > > > > > > I also note that it is not clear how such models would be advertised > > > > by a NETCONF server. > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > > > > > > > configuration data store, > > > > > > > > > 3) I2RS Data models require the use of priority to handle the > > > > > > > > > multi-write contention problem into the I2RS Control Plane data > > > > > store, > > > > > > > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > > > > > > > mandatory-to-implement transport, > > > > > > > > > > > > > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > > > > > > > the discussion should be taken up with netmod WG list. > > > > > > > > > Do you disagree with i2rs-protocol-security-requirements? That > > > > > issue > > > > > > > > > is closed based on IESG approval. > > > > > > > > > > > > > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Juergen Schoenwaelder > > > > > > > > > [ < > mailto:j.schoenwaelder@jacobs-university.de> > > > > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > > > > > Sent: Monday, January 23, 2017 3:39 AM > > > > > > > > > To: Susan Hares > > > > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > > > < > mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < > mailto:i2rs@ietf.org> > > > > i2rs@ietf.org; > > > > > > > > > < mailto:i2rs-chairs@ietf.org> > i2rs-chairs@ietf.org > > > > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > Susan, > > > > > > > > > > > > > > > > > > I consider tagging a YANG object statically and universally in the > > > > > > > > > data model as "does not need secure communication" fundamentally > > > > > > > > > flawed; I am not having an issue with insecure communication in > > > > > certain > > > > deployment contexts. > > > > > > > > > > > > > > > > > > The topology drafts are regular generic YANG models that just > > > > > happen > > > > > > > > > to be done in I2RS - I believe that using the generic YANG > > > > > security > > > > > > > > > guidelines we have is good enough to progress these drafts. > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > > > > > > > Juergen: > > > > > > > > > > > > > > > > > > > > I recognize that dislike insecure communication. You made a > > > > > > similar > > > > > > > > > > comment during the WG LC and IETF review of > > > > > > > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > > > > > > > draft-ietf-i2rs-protocol-security-requirements were passed by > > > > > > the > > > > > > > > > > I2RS WG and approved by the IESG for RFC publication and it > > > > > > contains > > > > > > > > > > the non-secure communication. The mandate from the I2RS WG for > > > > > > this > > > > > > > > > > shepherd/co-chair is clear. > > > > > > > > > > > > > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > > > > something > > > > > > > > > > that might address Kathleen's Moriarty's concerns about the > > > > > > topology > > > > > > > > > > draft's security issues about privacy and the I2RS ephemeral > > > > > > control > > > > > > > > > > plane > > > > > > > > > data > > > > > > > > > > store. I welcome an open discussion on my ideas > > > > > > > > > > ( > > > > > > > > > > > id > > > > > > er> > > > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > > > > > > > The > > > > > > > > > > yang doctor's YANG security consideration template > > > > > > > > > > ( < > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > > > > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > > > > > > > the privacy related RFCs (RFC6973) note that some information is > > > > sensitive. > > > > > > > > > > Hopefully, this document extends these guidelines to a new data > store. > > > > > > > > > > > > > > > > > > > > > > > Cheerily, > > > > > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Juergen Schoenwaelder > > > > > > > > > > [ < > mailto:j.schoenwaelder@jacobs-university.de> > > > > > mailto:j.schoenwaelder@jacobs-university.de] > > > > > > > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > > > > > > > To: Susan Hares > > > > > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > > > > < > mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < > mailto:i2rs@ietf.org> > > > > i2rs@ietf.org; > > > > > > > > > > < mailto:i2rs-chairs@ietf.org> > i2rs-chairs@ietf.org > > > > > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > > > For what it is worth, I find the notion that data models may be > > > > > > > > > > written for a specific non-secure transport plain broken. There > > > > > > is > > > > > > > > > > hardly any content of a data model I can think of which is > > > > > > generally > > > > > > > > > > suitable for insecure transports. > > > > > > > > > > > > > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > > > > is > > > > > > > > > > suitable to send over non-secure transports? I really do not see > > > > > > how > > > > > > > > > > the IETF can make a claim that a given piece of information is > > > > > > never > > > > > > > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > > > > > > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > > > > > > > deployment information is shipped in whatever way but this is > > > > > > then a > > > > > > > > > > property of the _deployment_ and not a property of the > _information_. > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > > > > > > > Kathleen: > > > > > > > > > > > > > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > > > > > > > modules > > > > > > > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > > > > data > > > > store > > > > > > > > > > (configuration and operational state). > > > > > > > > > > > > > > > > > > > > > > Draft location: > > > > > > > > > > > > > > > > > > > > > > > > ns > > > > > > > ide> > > > > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > > > > > > > r/ > > > > > > > > > > > > > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > > > > > > > OPS/NM ADs, > > > > > > > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > > > > model > > > > > > > > > > (L3) and the base I2RS topology model should both provide > > > > > > updated > > > > > > > > > > YANG Security Considerations sections. I would appreciate if > > > > > > Benoit > > > > > > > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Kathleen Moriarty [ > > > > > > > < > mailto:Kathleen.Moriarty.ietf@gmail.com> > > > > > mailto:Kathleen.Moriarty.ietf@gmail.com] > > > > > > > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > > > > > > > To: The IESG > > > > > > > > > > > Cc: < > mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> > > > > > draft-ietf-i2rs-yang-l3-topology@ietf.org; < > mailto:shares@ndzh.com> > > > > shares@ndzh.com; > > > > > > > > > > > < mailto:i2rs-chairs@ietf.org> > i2rs-chairs@ietf.org; > > > > < mailto:shares@ndzh.com> > shares@ndzh.com; < > mailto:i2rs@ietf.org> > > > > i2rs@ietf.org > > > > > > > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > > > > > Kathleen Moriarty has entered the following ballot position > > > > > > > for > > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > > > to > > > > > > > > > > > all email addresses included in the To and CC lines. (Feel > > > > > > > free to > > > > > > > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please refer to > > > > > > > > > > > < > https://www.ietf.org/iesg/statement/discuss-criteria.html> > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > > > > > > > > > > > > > > > > > > > > > > lo > > > > > > > gy/> > > > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > COMMENT: > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > > > > > > > consideration > > > > > > > > > > section guidelines need to be followed and this shouldn't go > > > > > > forward > > > > > > > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > i2rs mailing list > > > > > > > > > > > < mailto:i2rs@ietf.org> > i2rs@ietf.org > > > > > > > > > > > < > https://www.ietf.org/mailman/listinfo/i2rs> > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > > > > > > Fax: +49 421 200 3103 < < > http://www.jacobs-university.de/> > > > > http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > > > > > Fax: +49 421 200 3103 < < > http://www.jacobs-university.de/> > > > > http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > i2rs mailing list > > > > > > > > > < mailto:i2rs@ietf.org> > i2rs@ietf.org > > > > > > > > > < > https://www.ietf.org/mailman/listinfo/i2rs> > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > From nobody Mon Jan 23 13:10:59 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 D2B6D1298A5; Mon, 23 Jan 2017 13:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk 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 tDYuloBvrFEE; Mon, 23 Jan 2017 13:10:54 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCB21298A1; Mon, 23 Jan 2017 13:10:53 -0800 (PST) Received: from [10.137.2.13] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 32C6D24032D; Mon, 23 Jan 2017 22:10:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1485205851; bh=9z/vGhaLxhBjaka4JTTp8PwMhM5zL4k0IN/owIhxG4c=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=EyJ/LuFDNkUcgRJosr8ZHpORQNQ1RPZDtw8HNgV4N7t5rsvkXyvO2vvIfUr42URCl mIrGd17rIWweSNo7sSYdlJOFtxQkzs7/Y0yJkWu5Be2pQS2s/5CGL2oo2qTy9aDUHU PyBJQXoIrFdFPRNGgmFaqiOf9pZKNoz2cUwlyZP8= To: Martin Bjorklund , shares@ndzh.com References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> From: Robert Varga Message-ID: Date: Mon, 23 Jan 2017 22:10:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170123.212621.119545616051737472.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f8M5Arpkf8huSiGhgioNoS737smqrMnOw" Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 21:10:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f8M5Arpkf8huSiGhgioNoS737smqrMnOw Content-Type: multipart/mixed; boundary="3k0oCpG8O3qsPjTEIUnCn5JslwRx4BLOt"; protected-headers="v1" From: Robert Varga To: Martin Bjorklund , shares@ndzh.com Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Message-ID: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> In-Reply-To: <20170123.212621.119545616051737472.mbj@tail-f.com> --3k0oCpG8O3qsPjTEIUnCn5JslwRx4BLOt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >> I'm pulling your questions to the top of this email.=20 >> >> =20 >> >> Question 1: Ok. Just to make sure I understand this correctly - these= >> topology models are intended to be I2RS-specific, and they cannot be u= sed >> for any other purpose. If anyone needs a general topology model outsi= de of >> the I2RS protocol, they will have to design their own model. Is this >> correct? >> >> =20 >> >> Response 1: Not really. =20 > Ok, so are you saying that the models are in fact generic, and can be > used outside of I2RS? I.e., they *can* be used with the normal > configuration datastores? >=20 =46rom implementation experience, yes, they can be used for storing configuration. OpenDaylight uses (an ancient predecessor of) yang-network-topo to store configure details about devices in its managed networks. Regards, Robert --3k0oCpG8O3qsPjTEIUnCn5JslwRx4BLOt-- --f8M5Arpkf8huSiGhgioNoS737smqrMnOw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIoBAEBCgASBQJYhnFYCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTxNoP/RAi1mlU D/kdy3pAm3kiwrQ2mUxE/w0ATQqNIEVkcqgO3YVVFK561WwkFTXFXbD2b4lrMMNA KH5l1ZpLqwM8LCrJ076COgTbUUk6NDnE3+aiDZUmJmzvY0R5K890Iu8aUtQeTm13 xyen5bZsVWHanAaFR81soAT63ROl5KTGYU2+cgoHVw8DrDQ5p8nUkpigBO/hgdx6 SP85VAYZugSswiJ0liDoAAug7DQ45c0PEtpHYvpAN9H08BtRdMHUnhFJuicg8z1e fPx8CZjsLW7o2fRV7L3A7/8SRr1IebG8MsNVmDtc/4az2OUoo9P9tQnbp2zq1MH2 gLXygfdrJbUTToi2vnjbNgnBbbRGYVn4iGl4xsAKQmta3mhCEBkGEvPj1RekLlDH KES9J6Rkhuo5VJWrDC3Poo40z3r8AHS19rVfyQknGIC4IWHOXd2HrQTOPjfRffvT v0DoAeXJZIL9/TuSKejDGSXSRV7arkoUvh10Cv8t8gSs2sJONYJVPYdWekqX0W5j JMex1mW4BWqxJNWA/pqjxtoee5MG1dBj3VgIY/e8Gvz2Aq/FhAcu2+p/mofEdosD UdXypaWoG0N/6X2pVWX2kDXmc/0m2SB4f2NOCzY8dk4TGmEQf+On8wGAewhjfIPu /IqSyN9L2KcI/Uo7Dg6BGe9t4iRWqh650MXB =N1+1 -----END PGP SIGNATURE----- --f8M5Arpkf8huSiGhgioNoS737smqrMnOw-- From nobody Mon Jan 23 13:19:57 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 6A6481298C8; Mon, 23 Jan 2017 13:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XFXSDM2ZMri; Mon, 23 Jan 2017 13:19:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 212171298C6; Mon, 23 Jan 2017 13:19:52 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 283CB1AE02EF; Mon, 23 Jan 2017 22:19:51 +0100 (CET) Date: Mon, 23 Jan 2017 22:19:51 +0100 (CET) Message-Id: <20170123.221951.1538450846109848280.mbj@tail-f.com> To: nite@hq.sk From: Martin Bjorklund In-Reply-To: References: <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT), Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 21:19:53 -0000 Robert Varga wrote: > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - these > >> topology models are intended to be I2RS-specific, and they cannot be used > >> for any other purpose. If anyone needs a general topology model outside of > >> the I2RS protocol, they will have to design their own model. Is this > >> correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can be > > used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its > managed networks. Robert, this sub-thread started with Susan's statement: 1) I2RS Data models do not utilize the configuration data store, i.e., despite the fact that the data model is config true, it cannot be edited via running etc in NETCONF (or normal edit in RESTCONF). My comment on this was that *if* this is true, it should be noted in the document. At this point, I am not sure if it is true or not. /martin From nobody Mon Jan 23 13:36:17 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 233CC1298CC; Mon, 23 Jan 2017 13:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Y_zQUNOfnYcT; Mon, 23 Jan 2017 13:36:10 -0800 (PST) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 6E3491298B5; Mon, 23 Jan 2017 13:36:10 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id l7so20360395qtd.3; Mon, 23 Jan 2017 13:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X44L9AXB+anSegyW2q7XxgKS1lNgtfmtxlJdhn+uXTs=; b=tc1/JH7dpRoDWDbB4tGlXdV0b9L6SyB2Zf6Z7mKywxGcPH2agreEmM+8U4yxgxrUbl egRodyuqQtRjgzQVpgnINv7uZQH1jE8HOCaPML8soCBF3oyRSb/m78ClFLR3iLZcIR2Q n9aJ2Kvh7+WFv4oumVXrDVZdpYn4luWHlW7VmFcFd7pLivFGRN3SQk1jSOM6zBuNcrhU qgZyPlkCifOYE8uJojLVhIqhvHnPc+OFhiAxFwFP5daZet0wNGbEutcIXZ40hIQ3k/oU cEmvqzcd0DDnQ9DqlqeyI2caiFeUTmQypJD/Q1eMHr+TLLtYPZO24UiLuiJoqCOkvM3c t5kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X44L9AXB+anSegyW2q7XxgKS1lNgtfmtxlJdhn+uXTs=; b=Vm6+GJItm8fv15ukhLXp1G4qVFu/18TIVTWaJ+2AjSVTNpjFuQ9yMG5V3cGjr1G953 qO0SBc1DqIBbts9dwaF/KBgw69oqa/Si6qll7xQImpqKYVOTgn8HX/aViYFukQbBlINK JA6pUlc3ZY7bIN9/pzGQ08wmqxgI3tRbAX+B4gqOKSfz44N9iVFGPaWY4JDivAY4UCnP qINTRHb9zBawoTKXvSuHUEbxxBv1328zLubqquaMIVSlAN4izOf1Dv5MDjEV+x0jFYaf IxqEsRWrnIk4XNYY4096Ww3hQ+DHRaARIiXz7wLjLW56qwG5qw19/NPAmX6BbyXROg6C KrIg== X-Gm-Message-State: AIkVDXJ5tQANPETGaIzGWXxmmD9lTg3Z5lHbn7qtykAYWGRTCJMXKljrY/MryZILVriPdSDfMBYYe5/9fp7VMw== X-Received: by 10.200.55.230 with SMTP id e35mr25853380qtc.30.1485207369614; Mon, 23 Jan 2017 13:36:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 23 Jan 2017 13:36:08 -0800 (PST) In-Reply-To: <20170123.221951.1538450846109848280.mbj@tail-f.com> References: <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <20170123.221951.1538450846109848280.mbj@tail-f.com> From: Kathleen Moriarty Date: Mon, 23 Jan 2017 16:36:08 -0500 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1139522aaf09980546c9c900 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, nite@hq.sk, "iesg@ietf.org" , Susan Hares Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT), Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 21:36:12 -0000 --001a1139522aaf09980546c9c900 Content-Type: text/plain; charset=UTF-8 The discussion on my no objection is very lengthy as there does not seem to be agreement on a few things from the WG. Does this document need to go back to the working group? Thank you, Kathleen On Mon, Jan 23, 2017 at 4:19 PM, Martin Bjorklund wrote: > Robert Varga wrote: > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - these > > >> topology models are intended to be I2RS-specific, and they cannot be > used > > >> for any other purpose. If anyone needs a general topology model > outside of > > >> the I2RS protocol, they will have to design their own model. Is this > > >> correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can be > > > used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > Robert, this sub-thread started with Susan's statement: > > 1) I2RS Data models do not utilize the configuration data store, > > i.e., despite the fact that the data model is config true, it cannot > be edited via running etc in NETCONF (or normal edit in RESTCONF). > > My comment on this was that *if* this is true, it should be noted in > the document. At this point, I am not sure if it is true or not. > > > /martin > > > -- Best regards, Kathleen --001a1139522aaf09980546c9c900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The discussion on my no objection is very lengthy as there= does not seem to be agreement on a few things from the WG.=C2=A0 Does this= document need to go back to the working group?

Thank yo= u,
Kathleen

On Mon, Jan 23, 2017 at 4:19 PM, Martin Bjorklund <mbj@tail-= f.com> wrote:
Robert Varga = <nite@hq.sk> wrote:
> On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
> >> I'm pulling your questions to the top of this email.
> >>
> >>
> >>
> >> Question 1: Ok.=C2=A0 Just to make sure I understand this cor= rectly - these
> >> topology models are intended to be I2RS-specific, and they ca= nnot be used
> >> for any other purpose.=C2=A0 If anyone needs a general topolo= gy model outside of
> >> the I2RS protocol, they will have to design their own model.= =C2=A0 Is this
> >> correct?
> >>
> >>
> >>
> >> Response 1:=C2=A0 Not really.
> > Ok, so are you saying that the models are in fact generic, and ca= n be
> > used outside of I2RS?=C2=A0 I.e., they *can* be used with the nor= mal
> > configuration datastores?
> >
>
> From implementation experience, yes, they can be used for storing
> configuration. OpenDaylight uses (an ancient predecessor of)
> yang-network-topo to store configure details about devices in its
> managed networks.

Robert, this sub-thread started with Susan's statement:

=C2=A0 =C2=A01) I2RS Data models do not utilize the configuration data stor= e,

i.e., despite the fact that the data model is config true, it cannot
be edited via running etc in NETCONF (or normal edit in RESTCONF).

My comment on this was that *if* this is true, it should be noted in
the document.=C2=A0 At this point, I am not sure if it is true or not.


/martin





--

Best regards,
Kathleen
--001a1139522aaf09980546c9c900-- From nobody Mon Jan 23 13:40: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 EA03F1204D9 for ; Mon, 23 Jan 2017 13:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUI6YeEtdQaW for ; Mon, 23 Jan 2017 13:40:29 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 11DEB1298CC for ; Mon, 23 Jan 2017 13:40:27 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s140so56722514qke.0 for ; Mon, 23 Jan 2017 13:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xObSJbfAnHGpzgJY0XHT2t3cl2FbgHw/56+TsB9YIMI=; b=dIcMwL++WGeTXxqNyjGDvBI5JyCdbpElaPYRHdm0xoU+ezsz/FMFCtF/BbCgHCsGFO 6548iaZvL7dz22r7bKRNbMoNRBUgACWh6Lx/Famva8vwrvxrKcTuU8Owmng8bx3ZWNcP FqZryb6BV48hEA5BSlzqN0Y1imthuBpQlki3o9YY3nMSPWSH6ZmMXkF7i4ixbjWWXKju c9Z+S6ZuVz9w3AYYIm1vINz4X8/c/uZ1aTT3esNnoDDmrM0w4JEvAtXxa9YyDt/xfDKp BWJWUZaQbZq75VdQ5H31j21Gjyqw/cAl7ju/AI4WT3HfZ9rGUoyGkHvSxGRlLHoZ5Nob kAVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xObSJbfAnHGpzgJY0XHT2t3cl2FbgHw/56+TsB9YIMI=; b=opFAHGtdJzUZYCJub8ROExlZAXqjo8bRmVrRayAwbXxhs7dKli1QRdOdzODh54YT97 6Kw8ARIic8cSeYGZ4ebkIWgCo/wfcIxDkYJv+qVsL+9S8tDRVnXxxZ9CleXyC36QM4kN aFQlFF0vW13T60DByuHgG49AHXXhUyE941RDo03FNgIqhnlBeC1hw3WJS+1sJ4vtVbcp 30E3JmghjtD3havdeETDGg1gb1zIh+QZrzIxpePRRo79OsLwl4WKiL+trROTE0J6N+YU DM6j+AgNoPZWPXn3KjO9u/6bYe/TULQMbb+4vngLUkvG09U26vz34RoAcpALxJT1dUsj g2bw== X-Gm-Message-State: AIkVDXIBE2naI44goblyls+B109rwzT7RaqKK9WZMWT6KPygq7WgB2QK1L3W1E7ydjNpvfpYUwNI4Aq0afi/Ow== X-Received: by 10.55.135.197 with SMTP id j188mr26768877qkd.71.1485207626106; Mon, 23 Jan 2017 13:40:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Mon, 23 Jan 2017 13:40:25 -0800 (PST) In-Reply-To: <20170123.221951.1538450846109848280.mbj@tail-f.com> References: <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <20170123.221951.1538450846109848280.mbj@tail-f.com> From: Andy Bierman Date: Mon, 23 Jan 2017 13:40:25 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c0777e6f925c40546c9d888 Archived-At: Cc: "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Robert Varga , Kathleen Moriarty , The IESG , Susan Hares Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT), Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 21:40:31 -0000 --94eb2c0777e6f925c40546c9d888 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 1:19 PM, Martin Bjorklund wrote: > Robert Varga wrote: > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - these > > >> topology models are intended to be I2RS-specific, and they cannot be > used > > >> for any other purpose. If anyone needs a general topology model > outside of > > >> the I2RS protocol, they will have to design their own model. Is this > > >> correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can be > > > used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > Robert, this sub-thread started with Susan's statement: > > 1) I2RS Data models do not utilize the configuration data store, > > i.e., despite the fact that the data model is config true, it cannot > be edited via running etc in NETCONF (or normal edit in RESTCONF). > > My comment on this was that *if* this is true, it should be noted in > the document. At this point, I am not sure if it is true or not. > > Agreed. But a larger issue is the balkanization of YANG. To every YANG reader, the YANG data-def-stmts look exactly like those that would be interpreted as configuration and state data nodes. I little note that says "This is not regular YANG that is intended for NETCONF or RESTCONF servers" is not really a solution. RFC 7950 says YANG is for NETCONF, which is extra confusing. > /martin > > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --94eb2c0777e6f925c40546c9d888 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 23, 2017 at 1:19 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Robert Varga <nite@hq.sk> wrote:
> On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
> >> I'm pulling your questions to the top of this email.
> >>
> >>
> >>
> >> Question 1: Ok.=C2=A0 Just to make sure I understand this cor= rectly - these
> >> topology models are intended to be I2RS-specific, and they ca= nnot be used
> >> for any other purpose.=C2=A0 If anyone needs a general topolo= gy model outside of
> >> the I2RS protocol, they will have to design their own model.= =C2=A0 Is this
> >> correct?
> >>
> >>
> >>
> >> Response 1:=C2=A0 Not really.
> > Ok, so are you saying that the models are in fact generic, and ca= n be
> > used outside of I2RS?=C2=A0 I.e., they *can* be used with the nor= mal
> > configuration datastores?
> >
>
> From implementation experience, yes, they can be used for storing
> configuration. OpenDaylight uses (an ancient predecessor of)
> yang-network-topo to store configure details about devices in its
> managed networks.

Robert, this sub-thread started with Susan's statement:

=C2=A0 =C2=A01) I2RS Data models do not utilize the configuration data stor= e,

i.e., despite the fact that the data model is config true, it cannot
be edited via running etc in NETCONF (or normal edit in RESTCONF).

My comment on this was that *if* this is true, it should be noted in
the document.=C2=A0 At this point, I am not sure if it is true or not.


Agreed.

But a= larger issue is the balkanization of YANG.
To every YANG reader,= the YANG data-def-stmts look exactly
like those that would be in= terpreted as configuration and state data nodes.

I= little note that says "This is not regular YANG that is intended for<= /div>
NETCONF or RESTCONF servers" is not really a solution.
=
RFC 7950 says YANG is for NETCONF, which is extra confusing.



/martin


Andy
=C2=A0

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

--94eb2c0777e6f925c40546c9d888-- From nobody Mon Jan 23 14:11:19 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 35B011298CE; Mon, 23 Jan 2017 14:11:13 -0800 (PST) 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 sNg_nINDmVKF; Mon, 23 Jan 2017 14:11:12 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1180126579; Mon, 23 Jan 2017 14:11:11 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Robert Varga'" , "'Martin Bjorklund'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> In-Reply-To: Date: Mon, 23 Jan 2017 17:06:04 -0500 Message-ID: <019c01d275c4$edf51f30$c9df5d90$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+oUhObIA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 22:11:13 -0000 Robert and Martin: I agree with Robert that the current implementations of the ODL topology models are handled as part of the configuration data store with ephemeral state. I will point out that these implementation are pre-standards implementations of the I2RS YANG Data model. While standardizing the topology data models, the I2RS WG have been asked to align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG document. This NETMOD WG document moves the I2RS ephemeral data store from configuration data store to a Control Plane data store. If we follow this draft, the I2RS Topology models are part of the I2RS ephemeral data store. If you disagree with the placement of the Topology data models, please indicate this to the NETMOD WG and to Benoit. Could you propose a way that you would see the ephemeral state working with the configuration data store to the NETMOD WG? Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks for Control Plane Data store. You ask for configuration data store (which was the I2RS initial proposal). It is possible for either one to work for I2RS Topology models - if the right details are taken care of. How do we make progress on choosing one method so we can write the I2RS Topology Models security considerations.? Sue -----Original Message----- From: Robert Varga [mailto:nite@hq.sk] Sent: Monday, January 23, 2017 4:11 PM To: Martin Bjorklund; shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >> I'm pulling your questions to the top of this email. >> >> >> >> Question 1: Ok. Just to make sure I understand this correctly - >> these topology models are intended to be I2RS-specific, and they >> cannot be used for any other purpose. If anyone needs a general >> topology model outside of the I2RS protocol, they will have to design >> their own model. Is this correct? >> >> >> >> Response 1: Not really. > Ok, so are you saying that the models are in fact generic, and can be > used outside of I2RS? I.e., they *can* be used with the normal > configuration datastores? > >From implementation experience, yes, they can be used for storing configuration. OpenDaylight uses (an ancient predecessor of) yang-network-topo to store configure details about devices in its managed networks. Regards, Robert From nobody Mon Jan 23 14:15:05 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 6C6E312997A; Mon, 23 Jan 2017 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVDG3sMz8grb; Mon, 23 Jan 2017 14:14:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C28F129979; Mon, 23 Jan 2017 14:14:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4849712; Mon, 23 Jan 2017 23:14:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id i8DAtiycq4Eu; Mon, 23 Jan 2017 23:14:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jan 2017 23:14:56 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55BD8200A8; Mon, 23 Jan 2017 23:14:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id toM5dpm9D7Eu; Mon, 23 Jan 2017 23:14:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1383200A7; Mon, 23 Jan 2017 23:14:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A03BC3E480A7; Mon, 23 Jan 2017 23:14:58 +0100 (CET) Date: Mon, 23 Jan 2017 23:14:58 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170123221458.GA34192@elstar.local> Mail-Followup-To: Susan Hares , 'Robert Varga' , 'Martin Bjorklund' , i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:15:00 -0000 Perhaps just adding to the confusion, here is what the WG charter says: o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as a work item. Such topology-related models will be based on a generic topology model to support multiple uses; the generic topology model should support topology extension for non-I2RS uses. And as a milestone: Dec 2016 - Request Publication of Protocol Independent Topology Data Models /js On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote: > Robert and Martin: > > I agree with Robert that the current implementations of the ODL topology > models are handled as part of the configuration data store with ephemeral > state. I will point out that these implementation are pre-standards > implementations of the I2RS YANG Data model. > > While standardizing the topology data models, the I2RS WG have been asked to > align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG > document. This NETMOD WG document moves the I2RS ephemeral data store from > configuration data store to a Control Plane data store. If we follow this > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > If you disagree with the placement of the Topology data models, please > indicate this to the NETMOD WG and to Benoit. Could you propose a way that > you would see the ephemeral state working with the configuration data store > to the NETMOD WG? > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks for > Control Plane Data store. You ask for configuration data store (which was > the I2RS initial proposal). It is possible for either one to work for I2RS > Topology models - if the right details are taken care of. How do we make > progress on choosing one method so we can write the I2RS Topology Models > security considerations.? > > Sue > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, January 23, 2017 4:11 PM > To: Martin Bjorklund; shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - > >> these topology models are intended to be I2RS-specific, and they > >> cannot be used for any other purpose. If anyone needs a general > >> topology model outside of the I2RS protocol, they will have to design > >> their own model. Is this correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can be > > used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its managed > networks. > > Regards, > Robert > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 14:26:03 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 B1C6B12996C; Mon, 23 Jan 2017 14:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2v_PkkGmQ6b; Mon, 23 Jan 2017 14:25:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E54B8126B6D; Mon, 23 Jan 2017 14:25:56 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id DE8071AE02EF; Mon, 23 Jan 2017 23:25:55 +0100 (CET) Date: Mon, 23 Jan 2017 23:25:55 +0100 (CET) Message-Id: <20170123.232555.71314888595817367.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> References: <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 22:25:59 -0000 "Susan Hares" wrote: > Robert and Martin: > > I agree with Robert that the current implementations of the ODL topology > models are handled as part of the configuration data store with ephemeral > state. I will point out that these implementation are pre-standards > implementations of the I2RS YANG Data model. > > While standardizing the topology data models, the I2RS WG have been asked to > align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG > document. This NETMOD WG document moves the I2RS ephemeral data store from > configuration data store to a Control Plane data store. If we follow this > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > If you disagree with the placement of the Topology data models, please > indicate this to the NETMOD WG and to Benoit. Could you propose a way that > you would see the ephemeral state working with the configuration data store > to the NETMOD WG? > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks for > Control Plane Data store. You ask for configuration data store (which was > the I2RS initial proposal). Not really; I ask for clarification. > It is possible for either one to work for I2RS > Topology models - if the right details are taken care of. How do we make > progress on choosing one method so we can write the I2RS Topology Models > security considerations.? One problem is that relying on the solution in draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that document does not yet provide any details at all on the I2RS ephemeral datastore. So I see two alternatives. Either wait with these documents, or publish them with their datamodels as is (i.e., no new additional notes), for the existing protocols and architecure. This would allow them to be implemented just like any other YANG data model. This would mean that the normal YANG security considerations guidelines should be followed. /martin > > Sue > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, January 23, 2017 4:11 PM > To: Martin Bjorklund; shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - > >> these topology models are intended to be I2RS-specific, and they > >> cannot be used for any other purpose. If anyone needs a general > >> topology model outside of the I2RS protocol, they will have to design > >> their own model. Is this correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can be > > used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its managed > networks. > > Regards, > Robert > > From nobody Mon Jan 23 14:54:26 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 8AD96129407 for ; Mon, 23 Jan 2017 14:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNKwwizh0155 for ; Mon, 23 Jan 2017 14:54:23 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 3DD0A128E19 for ; Mon, 23 Jan 2017 14:54:23 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l7so151622796qtd.1 for ; Mon, 23 Jan 2017 14:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZMb73sCfmFUa2d/2LdmnxYiIzMZBegDvLo4vy0Q82ys=; b=evjKwDu4cwxdd5AGoKFTdo9o2Q7/4SzzbrXPlm0K0Ce0Y42oAonAWMFFY9JDoAe7ZI lpYrYNC/O1CGZH4PJgV3I9y+dvsPFXwf0h6SvCPlcSirFMKdtR7UxVKxayLskwsLnuzs z5/+xPZObh3SAV9qEGxwVxJjywpAb2pFqIbkTCPWpOAvX83bb+XU/IikUDXVoEeBmOvI FOmau3EHdCA4j3AyTX48l/Z5Fld9/jbJuWYivadjCoNMdqAgA6qPAomkNvRmeTGhLGtJ AXlMAVJjVwh6Q++ogf1xmto3Jn/pB7tbNar+1KycdVQSLNPBGuHoxjaTQX+lxp5kxF+l 9nAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZMb73sCfmFUa2d/2LdmnxYiIzMZBegDvLo4vy0Q82ys=; b=iHcnwq4NSfAl4wRlZGQnIPOaH97zCdqhQGPpSFqSV/sNS6SgxWq34wa0XrnlI6c4i5 Xc9VahU5oEjcHc6JTrR0qvarlE18V+orecneC+FFCafZ/jm5D8CAheFmMgxVVQrBYyVA +yTI3VH+85VNooHixDJDqPz3EkwAS1CWF1GBQzscQkNbnJc+DHeuc3OzBO35G9QjrdY8 G+lhvGtYUUGL3kOLslLsGvah7J6zb7dvitSOyInaYQn+H7v9TwyTCt+kT1f6vry7av72 B88fxIKOkyGusXwT0PdDiADnFHACAvrL1rl90ZOyD/Fxc0NfGnpEmPmxoUpmTlsnKmME g9cA== X-Gm-Message-State: AIkVDXKzmmRhiY2P5DL+zzsg8KQvz5Jz11sF6P7WsmTp+5kzvxGLVEPf2PhgXTyELk6DA1zjVbrmjJXf3s4CzA== X-Received: by 10.200.45.177 with SMTP id p46mr25089195qta.240.1485212062348; Mon, 23 Jan 2017 14:54:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Mon, 23 Jan 2017 14:54:21 -0800 (PST) In-Reply-To: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> From: Andy Bierman Date: Mon, 23 Jan 2017 14:54:21 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114796e864a5d50546cae1c7 Archived-At: Cc: "i2rs@ietf.org" , Martin Bjorklund , draft-ietf-i2rs-yang-l3-topology@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, Robert Varga , Kathleen Moriarty , The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 22:54:25 -0000 --001a114796e864a5d50546cae1c7 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 2:06 PM, Susan Hares wrote: > Robert and Martin: > > I agree with Robert that the current implementations of the ODL topology > models are handled as part of the configuration data store with ephemeral > state. I will point out that these implementation are pre-standards > implementations of the I2RS YANG Data model. > > While standardizing the topology data models, the I2RS WG have been asked > to > align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG > document. This NETMOD WG document moves the I2RS ephemeral data store from > configuration data store to a Control Plane data store. If we follow this > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > If you disagree with the placement of the Topology data models, please > indicate this to the NETMOD WG and to Benoit. Could you propose a way that > you would see the ephemeral state working with the configuration data store > to the NETMOD WG? > This was discussed many times, going back to the NYC interim for NETMOD WG. There are 2 choices that are backward compatible 1) I2RS nodes are config=true This is OK if the data nodes represent configuration that can be overridden by the values in the ephemeral datastore. NETCONF can write the configuration datastore. I2RS can write the ephemeral datastore 2) I2RS nodes are config=false This is OK if the data nodes represent I2RS-only data that cannot be written to a configuration datastore. I2RS can write to this data in the ephemeral datastore only > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > for > Control Plane Data store. You ask for configuration data store (which was > the I2RS initial proposal). It is possible for either one to work for > I2RS > Topology models - if the right details are taken care of. How do we make > progress on choosing one method so we can write the I2RS Topology Models > security considerations.? > > Sue > Andy > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, January 23, 2017 4:11 PM > To: Martin Bjorklund; shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - > >> these topology models are intended to be I2RS-specific, and they > >> cannot be used for any other purpose. If anyone needs a general > >> topology model outside of the I2RS protocol, they will have to design > >> their own model. Is this correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can be > > used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > >From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its managed > networks. > > Regards, > Robert > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114796e864a5d50546cae1c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 23, 2017 at 2:06 PM, Susan Hares <shares@ndzh.com> wrote:
Robert and Martin:

I agree with Robert that the current implementations of the ODL topology models are handled as part of the configuration data store with ephemeral state.=C2=A0 =C2=A0I will point out that these implementation are pre-stand= ards
implementations of the I2RS YANG Data model.

While standardizing the topology data models, the I2RS WG have been asked t= o
align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG document.=C2=A0 This NETMOD WG document moves the I2RS ephemeral data store= from
configuration data store to a Control Plane data store.=C2=A0 =C2=A0If we f= ollow this
draft, the I2RS Topology models are part of the I2RS ephemeral data store.<= br> If you disagree with the placement of the Topology data models, please
indicate this to the NETMOD WG and to Benoit.=C2=A0 Could you propose a way= that
you would see the ephemeral state working with the configuration data store=
to the NETMOD WG?


This w= as discussed many times, going back to the NYC interim for NETMOD WG.
=

There are 2 choices that are backward compatible
<= div>
1) I2RS nodes are config=3Dtrue
=C2=A0 =C2=A0 = This is OK if the data nodes represent configuration that can be overridden=
=C2=A0 =C2=A0 =C2=A0by the values in the ephemeral datastore.=C2= =A0 NETCONF can write the
=C2=A0 =C2=A0 configuration datastore. = I2RS can write the ephemeral datastore

2) I2RS nod= es are config=3Dfalse
=C2=A0 =C2=A0This is OK if the data nodes r= epresent I2RS-only data that cannot be written
=C2=A0 =C2=A0to a = configuration datastore. I2RS can write to this data in the ephemeral datas= tore only




=

Quite frankly, I feel a bit of whip-lash on this topic.=C2=A0 =C2=A0NETMOD = WG asks for
Control Plane Data store.=C2=A0 You ask for configuration data store (which= was
the I2RS initial proposal).=C2=A0 =C2=A0It is possible for either one to wo= rk for I2RS
Topology models - if the right details are taken care of.=C2=A0 =C2=A0How d= o we make
progress on choosing one method so we can write the I2RS Topology Models security considerations.?

Sue


Andy
=C2= =A0

-----Original Message-----
From: Robert Varga [mailto:nite@hq.sk] Sent: Monday, January 23, 2017 4:11 PM
To: Martin Bjorklund; shares@ndzh.com
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topo= logy@ietf.org;
j.schoenwaelder@jac= obs-university.de; i2rs-ch= airs@ietf.org;
Kathleen.Moriarty.ietf@= gmail.com; iesg@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
>> I'm pulling your questions to the top of this email.
>>
>>
>>
>> Question 1: Ok.=C2=A0 Just to make sure I understand this correctl= y -
>> these topology models are intended to be I2RS-specific, and they >> cannot be used for any other purpose.=C2=A0 If anyone needs a gene= ral
>> topology model outside of the I2RS protocol, they will have to des= ign
>> their own model.=C2=A0 Is this correct?
>>
>>
>>
>> Response 1:=C2=A0 Not really.
> Ok, so are you saying that the models are in fact generic, and can be<= br> > used outside of I2RS?=C2=A0 I.e., they *can* be used with the normal > configuration datastores?
>

>From implementation experience, yes, they can be used for storing
configuration. OpenDaylight uses (an ancient predecessor of)
yang-network-topo to store configure details about devices in its managed networks.

Regards,
Robert


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

--001a114796e864a5d50546cae1c7-- From nobody Tue Jan 24 03:47:22 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 CA2F212958A; Tue, 24 Jan 2017 03:47:20 -0800 (PST) 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 HQkMxvYhL3nM; Tue, 24 Jan 2017 03:47:19 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0513712956B; Tue, 24 Jan 2017 03:47:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.1.59; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> In-Reply-To: <20170123221458.GA34192@elstar.local> Date: Tue, 24 Jan 2017 06:42:30 -0500 Message-ID: <029301d27636$f2514690$d6f3d3b0$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aaEwHmfg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 11:47:21 -0000 Juergen: Yep. That's the charter. draft-ietf-i2rs-yang-network-topo-10.txt is a generic topology model. draft-ietf-i2rs-yang-l3-topology-08.txt is a generic topology for L3 unicast. These support topology extension for non-I2RS user. We met the milestone and deliver the YANG Modules to the IESG. We discussed the "write" feature during WG LC and in the WG. We passed this by AD Benoit Claise who agreed to the reasons present by the draft authors. Kinda' missed your comments in the normal comment period (WG LC, IETF LC). Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, January 23, 2017 5:15 PM To: Susan Hares Cc: i2rs@ietf.org; 'Martin Bjorklund'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; 'Robert Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Perhaps just adding to the confusion, here is what the WG charter says: o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as a work item. Such topology-related models will be based on a generic topology model to support multiple uses; the generic topology model should support topology extension for non-I2RS uses. And as a milestone: Dec 2016 - Request Publication of Protocol Independent Topology Data Models /js On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote: > Robert and Martin: > > I agree with Robert that the current implementations of the ODL > topology models are handled as part of the configuration data store with ephemeral > state. I will point out that these implementation are pre-standards > implementations of the I2RS YANG Data model. > > While standardizing the topology data models, the I2RS WG have been > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > NETMOD WG document. This NETMOD WG document moves the I2RS ephemeral data store from > configuration data store to a Control Plane data store. If we follow this > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > If you disagree with the placement of the Topology data models, please > indicate this to the NETMOD WG and to Benoit. Could you propose a way > that you would see the ephemeral state working with the configuration data store > to the NETMOD WG? > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks for > Control Plane Data store. You ask for configuration data store (which was > the I2RS initial proposal). It is possible for either one to work for I2RS > Topology models - if the right details are taken care of. How do we make > progress on choosing one method so we can write the I2RS Topology > Models security considerations.? > > Sue > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, January 23, 2017 4:11 PM > To: Martin Bjorklund; shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - > >> these topology models are intended to be I2RS-specific, and they > >> cannot be used for any other purpose. If anyone needs a general > >> topology model outside of the I2RS protocol, they will have to > >> design their own model. Is this correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can > > be used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its > managed networks. > > Regards, > Robert > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 03:52: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 44D04129581; Tue, 24 Jan 2017 03:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C78ElfNFES5Q; Tue, 24 Jan 2017 03:52:21 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5391294AC; Tue, 24 Jan 2017 03:52:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51A937F4; Tue, 24 Jan 2017 12:52:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eYE3Fcj5vyrw; Tue, 24 Jan 2017 12:52:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jan 2017 12:52:19 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A227200AB; Tue, 24 Jan 2017 12:52:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rG49vc16_PGv; Tue, 24 Jan 2017 12:52:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C8FA200AA; Tue, 24 Jan 2017 12:52:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C59D3E49122; Tue, 24 Jan 2017 12:52:22 +0100 (CET) Date: Tue, 24 Jan 2017 12:52:21 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170124115221.GD35835@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029301d27636$f2514690$d6f3d3b0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 11:52:23 -0000 Susan, so are these YANG models regular YANG models or are these YANG models specific to the yet to be defined I2RS protocol and yet to be defined datastores? I think this is the core of Martin's and my question. A simple clear and concise answer would be nice. /js On Tue, Jan 24, 2017 at 06:42:30AM -0500, Susan Hares wrote: > Juergen: > > Yep. That's the charter. draft-ietf-i2rs-yang-network-topo-10.txt is a > generic topology model. draft-ietf-i2rs-yang-l3-topology-08.txt is a > generic topology for L3 unicast. These support topology extension for > non-I2RS user. We met the milestone and deliver the YANG Modules to the > IESG. We discussed the "write" feature during WG LC and in the WG. We > passed this by AD Benoit Claise who agreed to the reasons present by the > draft authors. > > Kinda' missed your comments in the normal comment period (WG LC, IETF LC). > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Monday, January 23, 2017 5:15 PM > To: Susan Hares > Cc: i2rs@ietf.org; 'Martin Bjorklund'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; 'Robert > Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Perhaps just adding to the confusion, here is what the WG charter > says: > > o The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as a work > item. Such topology-related models will be based on a generic > topology model to support multiple uses; the generic topology model > should support topology extension for non-I2RS uses. > > And as a milestone: > > Dec 2016 - Request Publication of Protocol Independent Topology Data > Models > > /js > > On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote: > > Robert and Martin: > > > > I agree with Robert that the current implementations of the ODL > > topology models are handled as part of the configuration data store with > ephemeral > > state. I will point out that these implementation are pre-standards > > implementations of the I2RS YANG Data model. > > > > While standardizing the topology data models, the I2RS WG have been > > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > > NETMOD WG document. This NETMOD WG document moves the I2RS ephemeral data > store from > > configuration data store to a Control Plane data store. If we follow > this > > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > > If you disagree with the placement of the Topology data models, please > > indicate this to the NETMOD WG and to Benoit. Could you propose a way > > that you would see the ephemeral state working with the configuration data > store > > to the NETMOD WG? > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > for > > Control Plane Data store. You ask for configuration data store (which was > > the I2RS initial proposal). It is possible for either one to work for > I2RS > > Topology models - if the right details are taken care of. How do we make > > progress on choosing one method so we can write the I2RS Topology > > Models security considerations.? > > > > Sue > > > > -----Original Message----- > > From: Robert Varga [mailto:nite@hq.sk] > > Sent: Monday, January 23, 2017 4:11 PM > > To: Martin Bjorklund; shares@ndzh.com > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - > > >> these topology models are intended to be I2RS-specific, and they > > >> cannot be used for any other purpose. If anyone needs a general > > >> topology model outside of the I2RS protocol, they will have to > > >> design their own model. Is this correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can > > > be used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > > > Regards, > > Robert > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 24 05:30:13 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 CB2DC129638 for ; Tue, 24 Jan 2017 05:30:11 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw_pSiIDOyJN for ; Tue, 24 Jan 2017 05:30:10 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 53EDA1295F5 for ; Tue, 24 Jan 2017 05:30:09 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cW1Aj-0003PW-Ty for i2rs@ietf.org; Tue, 24 Jan 2017 13:30:05 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cW1Aj-0000jK-Mv for i2rs@ietf.org; Tue, 24 Jan 2017 13:30:05 +0000 To: i2rs@ietf.org References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> From: Anton Ivanov Message-ID: <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> Date: Tue, 24 Jan 2017 13:30:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170124115221.GD35835@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 13:30:11 -0000 On 24/01/17 11:52, Juergen Schoenwaelder wrote: > Susan, > > so are these YANG models regular YANG models or are these YANG models > specific to the yet to be defined I2RS protocol and yet to be defined > datastores? > > I think this is the core of Martin's and my question. A simple clear > and concise answer would be nice. +1. A. From nobody Tue Jan 24 06:30:58 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 84EEF129602; Tue, 24 Jan 2017 06:30:53 -0800 (PST) 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 zyl2Mc4Ws5eV; Tue, 24 Jan 2017 06:30:52 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3301295FD; Tue, 24 Jan 2017 06:30:51 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> In-Reply-To: <20170124115221.GD35835@elstar.local> Date: Tue, 24 Jan 2017 09:25:52 -0500 Message-ID: <02d401d2764d$c5056470$4f102d50$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcShF5xXEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 14:30:53 -0000 Juergen and Martin: Your question is appropriate at this point. These Yang Modules are I2RS Yang Modules. Knowing whether these are attached to the configuration data store or a control plane data store is important. For that answer, I must await Benoit and the NETMOD Chairs. However, the security involved in these data models still has the same security issues whether it is ephemeral state attached to the configuration data store or the control plane data store. The solution is just different. The 6 issues for I2RS security considerations are: 1) different mandatory-to-implement transport for NETCONF, 2) priority resolving multiple client writes, 3) non-secure transport, 4 ) different validations with rpc actions, 5) different NACM, RACM, and SACM policy, 6) different data store behavior (ephemeral/configuration or ephemeral/Control Plane data store). Only #6 would operate different between the two data store choices. To recap our discussion: Any I2RS YANG module MUST have security comments on #1 and #2 if it contains writes. The topology modules particular module does not use #3 and #4 beyond the regular YANG module section. #5 - The NACM policy may be the same, but the policy toward the routing system (RACM) or system information (SACM) is different as the L3 topology models may load information from routing protocols. The proposal for I2RS Yang module security considerations has 3 parts: A) Basic Yang Security considerations, B) I2RS Security considerations for secure transport, and C) non-secure security considerations . A+B are all that is needed for these drafts. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, January 24, 2017 6:52 AM To: Susan Hares Cc: i2rs@ietf.org; 'Martin Bjorklund'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; 'Robert Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Susan, so are these YANG models regular YANG models or are these YANG models specific to the yet to be defined I2RS protocol and yet to be defined datastores? I think this is the core of Martin's and my question. A simple clear and concise answer would be nice. /js On Tue, Jan 24, 2017 at 06:42:30AM -0500, Susan Hares wrote: > Juergen: > > Yep. That's the charter. draft-ietf-i2rs-yang-network-topo-10.txt is > a generic topology model. draft-ietf-i2rs-yang-l3-topology-08.txt is a > generic topology for L3 unicast. These support topology extension for > non-I2RS user. We met the milestone and deliver the YANG Modules to the > IESG. We discussed the "write" feature during WG LC and in the WG. We > passed this by AD Benoit Claise who agreed to the reasons present by > the draft authors. > > Kinda' missed your comments in the normal comment period (WG LC, IETF LC). > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Monday, January 23, 2017 5:15 PM > To: Susan Hares > Cc: i2rs@ietf.org; 'Martin Bjorklund'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; > 'Robert Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Perhaps just adding to the confusion, here is what the WG charter > says: > > o The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as a work > item. Such topology-related models will be based on a generic > topology model to support multiple uses; the generic topology model > should support topology extension for non-I2RS uses. > > And as a milestone: > > Dec 2016 - Request Publication of Protocol Independent Topology Data > Models > > /js > > On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote: > > Robert and Martin: > > > > I agree with Robert that the current implementations of the ODL > > topology models are handled as part of the configuration data store > > with > ephemeral > > state. I will point out that these implementation are pre-standards > > implementations of the I2RS YANG Data model. > > > > While standardizing the topology data models, the I2RS WG have been > > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > > NETMOD WG document. This NETMOD WG document moves the I2RS > > ephemeral data > store from > > configuration data store to a Control Plane data store. If we follow > this > > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > > If you disagree with the placement of the Topology data models, > > please indicate this to the NETMOD WG and to Benoit. Could you > > propose a way that you would see the ephemeral state working with > > the configuration data > store > > to the NETMOD WG? > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > for > > Control Plane Data store. You ask for configuration data store (which was > > the I2RS initial proposal). It is possible for either one to work for > I2RS > > Topology models - if the right details are taken care of. How do we make > > progress on choosing one method so we can write the I2RS Topology > > Models security considerations.? > > > > Sue > > > > -----Original Message----- > > From: Robert Varga [mailto:nite@hq.sk] > > Sent: Monday, January 23, 2017 4:11 PM > > To: Martin Bjorklund; shares@ndzh.com > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - > > >> these topology models are intended to be I2RS-specific, and they > > >> cannot be used for any other purpose. If anyone needs a general > > >> topology model outside of the I2RS protocol, they will have to > > >> design their own model. Is this correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can > > > be used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > > > Regards, > > Robert > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 24 07:31:23 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 1AAE712945A; Tue, 24 Jan 2017 07:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.057 X-Spam-Level: X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTkoYeVrdDZk; Tue, 24 Jan 2017 07:31:17 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94F9128AC9; Tue, 24 Jan 2017 07:31:17 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id ED6722DC37FA3; Tue, 24 Jan 2017 15:31:12 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0OFE70Y019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 15:31:15 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0OEm5Gd008243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 14:48:34 GMT Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.116]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 15:48:25 +0100 From: "Scharf, Michael (Nokia - DE)" To: Susan Hares , "'Juergen Schoenwaelder'" Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+oLAD6ID///5/AIAAOTWAgAAFxICAAAyQgIAAKfOAgAAN7ICAAA29gIAADGOAgAAPeQCAAAJ9AIAA4Z8AgAACwICAACrlAIAAFGTw Date: Tue, 24 Jan 2017 14:48:25 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48C64675@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <02d401d2764d$c5056470$4f102d50$@ndzh.com> In-Reply-To: <02d401d2764d$c5056470$4f102d50$@ndzh.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , 'Martin Bjorklund' , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs-chairs@ietf.org" , 'Robert Varga' , "Kathleen.Moriarty.ietf@gmail.com" , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:31:19 -0000 Has it been considered that draft-ietf-teas-yang-te-topo augments draft-iet= f-i2rs-yang-network-topo? Michael From nobody Tue Jan 24 07:33:51 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 CCB7E129A54; Tue, 24 Jan 2017 07:33:49 -0800 (PST) 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 eyqDbnkHQUqZ; Tue, 24 Jan 2017 07:33:48 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EB2129A40; Tue, 24 Jan 2017 07:33:48 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Scharf, Michael \(Nokia - DE\)'" , "'Juergen Schoenwaelder'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <02d401d2764d$c5056470$4f102d50$@ndzh.com> <655C07320163294895BBADA28372AF5D48C64675@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48C64675@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 24 Jan 2017 10:29:00 -0500 Message-ID: <003601d27656$970b4950$c521dbf0$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcQBCI+ayQG3/AP1oQGzkkA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, 'Robert Varga' , Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:33:50 -0000 Michael: Yes. Do you want a longer explanation of the details? Sue -----Original Message----- From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Tuesday, January 24, 2017 9:48 AM To: Susan Hares; 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; 'Martin Bjorklund'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; 'Robert Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: RE: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Has it been considered that draft-ietf-teas-yang-te-topo augments draft-ietf-i2rs-yang-network-topo? Michael From nobody Tue Jan 24 07:53:49 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 80FAD129625; Tue, 24 Jan 2017 07:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 6rjjsfFwnbfy; Tue, 24 Jan 2017 07:53:45 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880E5129619; Tue, 24 Jan 2017 07:53:44 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Thomas Nadeau'" References: <148479382192.2016.17507851181705214581.idtracker@ietfa.amsl.com> <026f01d27260$45554a10$cfffde30$@ndzh.com> <20170119153400.GA8004@elstar.local> <036401d2727f$fc114910$f433db30$@ndzh.com> <20170123083903.GB29022@elstar.local> <01ee01d27568$784b6020$68e22060$@ndzh.com> <20170123112904.GA29980@elstar.local> <023901d27586$ad63c4f0$082b4ed0$@ndzh.com> <741C5CFE-3ED8-46FE-953A-8F905F184583@gmail.com> <007901d27599$649e0790$2dda16b0$@ndzh.com> <55EFDB1C-ED03-4D24-AFF9-28033DF03A7F@lucidvision.com> In-Reply-To: <55EFDB1C-ED03-4D24-AFF9-28033DF03A7F@lucidvision.com> Date: Tue, 24 Jan 2017 10:48:54 -0500 Message-ID: <004101d27659$5e9cb1a0$1bd614e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D2762F.75D01F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+ufYYBtIA0WoGRREYM1y0KVh6/gG9jePVAbW2ZnUCgMVVUwG2rEA+AvYiyDYB8tFV9gI6fU8pAp4O91MClGFhQAKvxSLBAWbKdKugLoL+AA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Juergen Schoenwaelder' , 'Kathleen Moriarty' , i2rs-chairs@ietf.org, 'Giles Heron' , 'The IESG' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:53:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D2762F.75D01F80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tom:=20 Original goal =3D protocol independent yang in ephemeral storage with = appropriate security. YANG drafts on plan and on-time. For I2RS = appropriate security see draft-ietf-i2rs-protocol-security-requirements = and draft-ietf-i2rs-security-environment-req-02.txt as WG drafts. All 6 = requirements from 2 WG documents. Only unique question to data store = =E2=80=93 Ephemeral + config or Ephemeral in Control Plane data store. = NETMOD=E2=80=99s choice on datastore. Awaiting their comments. = Discussion is long, but fix is short. Fix to drafts for Security: 1-2 = Paragraphs for Yang Basics security considerations, fix is 1 paragraph = for YANG I2RS Models. =20 =20 Sue=20 =20 =20 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Monday, January 23, 2017 1:12 PM To: Susan Hares Cc: Giles Heron; i2rs@ietf.org; = draft-ietf-i2rs-yang-l3-topology@ietf.org; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; The IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 =20 On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares = wrote: =20 Giles:=20 =20 I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals. It is a protocol independent model with information on = topology. This was in the original use cases and has been a focus for = I2RS WG. See rest of the responses below.=20 =20 The real change for RFC compliance for ODL=E2=80=99s read-only Topology = model would be: a) use of NETCONF over TLS with X.509v3 authentication, = b) denoting the =E2=80=9Cdynamic control plane data store=E2=80=9D in = the get applied (whenever that gets implemented), and support of the = opaque secondary identity in tracing (if you support tracing). The = change for the RFC compliance for the ODL=E2=80=99s read-write would be = the utilizing priority to resolve contention if multiple clients try to = write the topology database. The priority could be set per user = identifier (passed in X.509v3) in a pre-configuration set-up stored. = Ideally this pre-configuration would be stored in a key store or = something that is secure. =20 Sue=20 =20 Sue,=20 =20 I am still totally confused as to why any of what that last = sentence says has to do with the topology model other than it is as you = say, protocol independent. That was the original goal. Why we are complicating things with transport or data store things is = not making sense to me at all. =20 =E2=80=94Tom =20 =20 =20 Fr om: Giles Heron [ = mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 11:26 AM To: Susan Hares Cc: Juergen Schoenwaelder; = = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 Hi Sue, =20 On 23 Jan 2017, at 14:40, Susan Hares < = shares@ndzh.com> wrote: =20 Giles: =20 Thank you for your comments on ODL and your implementation within ODL. = There are two different issues in discussion: guidelines for I2RS Yang = modules and the application of these guidelines to the I2RS Yang = Topology model. The guidelines for the I2RS Yang Module have three = security considerations: a) basic yang considerations, b) I2RS = ephemeral state considerations, and c) insecure considerations. Since = the topology model does not operate over an insecure transport, the only = thing that I believe you are questioning is the "I2RS Yang Models for = Secure-Only transports". Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology). =20 i wasn=E2=80=99t the implementer of those models in ODL. But = I=E2=80=99ve used them a fair bit. =20 at any rate applying the I2RS security guidelines to the I2RS YANG = topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network elements) . =20 [Sue]: No, the topology model was part of the original I2RS YANG = modules, and the Topology models (L2, L3, Base) fit its ue.=20 =20 The topology model as described in = draft-ietf-i2rs-yang-network-topo-10.txt has read/write nodes at the = network, link and termination point. Please see the copy of the YHL = diagrams below. Therefore, the basic topology model is read-write. The = L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write. = Please see a copy of the YHL diagrams below. Therefore, although your = implementation is read-only, the approved YANG modules are read-write. = This must be considered in the Security considerations section. The = basic requirements for I2RS are:=20 =20 Sure - the models are read/write but ODL=E2=80=99s implementation is = generally read-only (as I understand it, it=E2=80=99s down to each = individual protocol or application that leverages the models to decide = whether to use them in read-write or read-only mode). =20 [Sue]: This fits the I2RS Yang module.=20 =20 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,=20 =20 Giles: most NETCONF implementations I=E2=80=99m aware of use ssh. And = this is mandatory only per an individual ID, right? Or is it in a WG = draft now? And do we have WG consensus that this applies to read-only = data as well as to read-write? =20 Sue: NETCONF over TLS with X.509v3 is an RFC 7589. I2RS is requiring = this to get mutual authentication, confidentiality, data integrity, = [practical] reply protection for I2RS messages, and support DoS = mitigation. This mandatory-to-implement status is a change from the = basic NETCONF over SSH.=20 =20 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication = as a permissible implementation alternative.=20 =20 Giles: again isn=E2=80=99t that only specified as mandatory in an = individual ID? Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation. Therefore, the RESTCONF protocol is an alternative = since it supports this with its basic work.=20 3) write contention for two clients writing a node using I2RS priority = (linked to I2RS User-ID)=20 =20 Giles: so that one isn=E2=80=99t an issue for read-only = implementations=E2=80=A6 Sue: Yes. You are correct.=20 =20 Sue: If the ODL model does not support writes to these data models, then = it would not have to support the priority mechanism to resolve two = clients writing one data node. =20 Giles: indeed. Sue: No other responses are below=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A) Basic Yang considerations=20 =20 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read data. = A paragraph needs to be added to each draft indicating risks involved = in providing this information, and how deployments can keep this data = safe. Privacy issues are involved if the topologies are within homes = or indicate user's personal devices. =20 =20 If the I2RS mandatory transport is utilized, the data streams utilize = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention". This level of security is = useful when protecting sensitive data. =20 =20 2) writeable nodes with sensitive data: Since the topology nodes are = writeable, a security considerations needs to consider how these = sensitive data nodes will be protected. While ODL does not support = writes to any data node, the base models do. Therefore, security = considerations must be written here.=20 =20 3) RPCs: No new RPCs are considered, but providing information on the = notification data may be also useful.=20 =20 I2RS YANG Model Security Considerations =20 The requirement for this section is the following information:=20 =20 1) Indication of deployment requirement for mandatory-to-implement = NETCONF (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),=20 2) Discussion of RPCs specific to I2RS control plane data store, =20 3) NACM policy impacts the read-write state and augmentation of NACM by = access control for read/writing of routing protocols (RACM), system = information (SACM), and between datastores (config to/from ephemeral = state).=20 4) Discussion of data retrieved from routing protocols, system = information, dynamic configuration (dhcp)=20 5) Any suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state.=20 =20 For the topology data models (ietf-network, ietf-network-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS topology data models (ietf-network, = ietf-network-topology) require mutual authentication, confidentiality, = data integrity, and [practical] replay protection for I2RS messages. = Therefore, there is a mandatory-to-implement transport protocol of TLS = (see RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model or any notifications. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. Deployments may provide general configuration knobs that = set the default state for NACM, RACM, SACM and DACM for the topology = database. =E2=80=9C =20 For the L3 topology data models (ietf-l3-unicast-topology), the = paragraph could be:=20 =20 =E2=80=9CThe I2RS L3 Unicast topology data model = (ietf-l3-unicast-topology) require mutual authentication, = confidentiality, data integrity, and [practical] replay protection for = I2RS messages. Therefore, there is a mandatory-to-implement transport = protocol of NETCONF over TLS with X.509v3 mutual authentication = (RFC7589), or an optional transport support of RESTCONF = (draft-ietf-netconf-restconf). This data model does not implement = any additional RPCs specific to this data model. This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event. These events provide the = information about the changing L3 topology which may provide information = regarding key nodes. Since these events are only transported over = secure transports that support mutual authentication, confidentiality, = data integrity, and [practice] replay protection, the use of this = information for DoS of an I2RS agent (aka NETCONF server) requires the = mutual authenticated client to be suborned. =20 =20 NACM policies may restrict exterior access to this YANG model to simply = read-only. For those NACM policies allowing write-access, there is a = risk that a write to a topology may create a looping topology or = overload a particular node. NACM policies may be augment by routing = protocol access control methods (RACM), system data access control = methods (SACM), and inter-data store access control mechanisms (DACM). = The engagement of this policy should also be control by user policy = switches (on/of). =20 =20 For the L3 topology mode, the access to information on interfaces may be = control by SACM related to the interface model. Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state. Dynamic configuration = protocols such as DHCP or DHCPv6 may also alter the IP Addresses = associated with an interface. DACM related to the inter-datastore = policy on the precedence between configuration of interface IP = addresses, DHCP/DHCPv6 configuration, or Topology configuration will = need to make sure the interface IP address does not cause fluctuations = in the system. The L3 Topology model may also read information from = the routing protocols (ospf, isis or others), or write data to the = routing protocol. RACM policy should be carefully set so that the = routing protocols do not form a place to launch a DoS attack. = Deployments may provide general configuration knobs that set the default = state for NACM, RACM, SACM and DACM for the topology database. =E2=80=9C =20 =20 Hopefully, this makes the suggestion for I2RS security policy a bit more = concrete.=20 Sue Hares=20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt=20 =20 +--rw networks +--rw network* [network-id] +--rw network-types +--rw network-id network-id +--ro server-provided? boolean +--rw supporting-network* [network-ref] | +--rw network-ref -> /networks/network/network-id +--rw node* [node-id] +--rw node-id node-id +--rw supporting-node* [network-ref node-ref] +--rw network-ref -> ../../../supporting-network/ + | network-ref +--rw node-ref -> /networks/network/node/node-id =20 module: ietf-network-topology augment /nd:networks/nd:network: +--rw link* [link-id] +--rw source | +--rw source-node? -> ../../../nd:node/node-id | +--rw source-tp? -> = ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../source-node]/termination-point/tp-id +--rw destination | +--rw dest-node? -> ../../../nd:node/node-id | +--rw dest-tp? -> ../../../nd:node[nd:node-id=3Dcurrent()/+ | ../dest-node]/termination-point/tp-id +--rw link-id link-id +--rw supporting-link* [network-ref link-ref] +--rw network-ref -> ../../../nd:supporting-network/+ | network-ref +--rw link-ref -> /nd:networks/network+ = [nd:network-id=3Dcurrent()/../network-ref]/+ link/link-id =20 augment /nd:networks/nd:network/nd:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=3D+ current()/../network-ref]/node+ [nd:node-id=3Dcurrent()/../node-ref]/+ termination-point/tp-id =20 =20 module: ietf-l3-unicast-topology augment /nd:networks/nd:network/nd:network-types: +--rw l3-unicast-topology! augment /nd:networks/nd:network: +--rw l3-topology-attributes +--rw name? string +--rw flag* l3-flag-type augment /nd:networks/nd:network/nd:node: +--rw l3-node-attributes +--rw name? inet:domain-name +--rw flag* node-flag-type +--rw router-id* inet:ip-address +--rw prefix* [prefix] +--rw prefix inet:ip-prefix +--rw metric? uint32 +--rw flag* prefix-flag-type augment /nd:networks/nd:network/lnk:link: +--rw l3-link-attributes +--rw name? string +--rw flag* link-flag-type +--rw metric? uint32 augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) | +--rw unnumbered-id? uint32 +--:(interface-name) +--ro interface-name? string =20 =20 =20 =20 =20 -----Original Message----- From: Giles Heron [ = mailto:giles.heron@gmail.com]=20 Sent: Monday, January 23, 2017 6:45 AM To: Juergen Schoenwaelder Cc: Susan Hares; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; Kathleen Moriarty; The IESG; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 ODL does, indeed, implement the topology models, but generally the data = in the topology model is operational data, so I=E2=80=99m not sure how = that fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane = data store=E2=80=9D - since users don=E2=80=99t write to the models = directly (making validation, priority etc. non-issues). =20 > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder < = = j.schoenwaelder@jacobs-university.de> wrote: >=20 > I thought the topology models are coming more or less from=20 > OpenDaylight. If so, is ODL and I2RS implementation? >=20 > /js >=20 > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote: >> Juergen:=20 >>=20 >> Let's focus on your second point. The topology drafts are I2RS = drafts >> designed for the I2RS ephemeral control plane data store. How can = these be >> generic YANG modules when the following is true:=20 >>=20 >> 1) I2RS Data models do not utilize the configuration data store, >> 2) I2RS Data Models do not require the same validation as=20 >> configuration data store, >> 3) I2RS Data models require the use of priority to handle the=20 >> multi-write contention problem into the I2RS Control Plane data=20 >> store, >> 4) I2RS require TLS with X.509v3 over TCP for the=20 >> mandatory-to-implement transport, >>=20 >> Do you disagree with draft-ietf-netmod-revised-datastores? If so, =20 >> the discussion should be taken up with netmod WG list. >> Do you disagree with i2rs-protocol-security-requirements? That issue = >> is closed based on IESG approval. >>=20 >> Sue Hares >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [ = mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, January 23, 2017 3:39 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; >> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> Susan, >>=20 >> I consider tagging a YANG object statically and universally in the=20 >> data model as "does not need secure communication" fundamentally=20 >> flawed; I am not having an issue with insecure communication in = certain deployment contexts. >>=20 >> The topology drafts are regular generic YANG models that just happen=20 >> to be done in I2RS - I believe that using the generic YANG security=20 >> guidelines we have is good enough to progress these drafts. >>=20 >> /js >>=20 >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> I recognize that dislike insecure communication. You made a similar = >>> comment during the WG LC and IETF review of=20 >>> draft-ietf-i2rs-protocol-security-requirements. However, the=20 >>> draft-ietf-i2rs-protocol-security-requirements were passed by the=20 >>> I2RS WG and approved by the IESG for RFC publication and it contains = >>> the non-secure communication. The mandate from the I2RS WG for this = >>> shepherd/co-chair is clear. >>>=20 >>> As the shepherd for the topology drafts, I try to write-up something = >>> that might address Kathleen's Moriarty's concerns about the topology = >>> draft's security issues about privacy and the I2RS ephemeral control = >>> plane >> data >>> store. I welcome an open discussion on my ideas >>> ( = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). >> The >>> yang doctor's YANG security consideration template >>> ( = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and=20 >>> the privacy related RFCs (RFC6973) note that some information is = sensitive. >>> Hopefully, this document extends these guidelines to a new data = store.=20 >>>=20 >>> Cheerily, >>> Sue Hares >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [ = mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, January 19, 2017 10:34 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG';=20 >>> = draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> For what it is worth, I find the notion that data models may be=20 >>> written for a specific non-secure transport plain broken. There is=20 >>> hardly any content of a data model I can think of which is generally = >>> suitable for insecure transports. >>>=20 >>> Can we please kill this idea of _standardizing_ information that is=20 >>> suitable to send over non-secure transports? I really do not see how = >>> the IETF can make a claim that a given piece of information is never = >>> worth protecting (=3D suitable for non-secure transports). >>>=20 >>> Note that I am fine if in a certain trusted tightly-coupled=20 >>> deployment information is shipped in whatever way but this is then a = >>> property of the _deployment_ and not a property of the = _information_. >>>=20 >>> /js >>>=20 >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: >>>> Kathleen:=20 >>>>=20 >>>> I have written a draft suggesting a template for the I2RS YANG=20 >>>> modules >>> which are designed to exist in the I2RS Ephemeral Control Plane data = store >>> (configuration and operational state). =20 >>>>=20 >>>> Draft location:=20 >>>> = = https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider >>>> / >>>>=20 >>>> I would appreciate an email discussion with the security ADs,=20 >>>> OPS/NM ADs, >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model >>> (L3) and the base I2RS topology model should both provide updated=20 >>> YANG Security Considerations sections. I would appreciate if Benoit=20 >>> or you hold a discuss until we sort out these issues. >>>>=20 >>>> Thank you, >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [ = mailto:Kathleen.Moriarty.ietf@gmail.com] >>>> Sent: Wednesday, January 18, 2017 9:44 PM >>>> To: The IESG >>>> Cc: = draft-ietf-i2rs-yang-l3-topology@ietf.org; = shares@ndzh.com;=20 >>>> i2rs-chairs@ietf.org; = shares@ndzh.com; = i2rs@ietf.org >>>> Subject: Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to=20 >>>> all email addresses included in the To and CC lines. (Feel free to=20 >>>> cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = = https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ >>>>=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>>=20 >>>> I agree with Alissa's comment that the YANG module security=20 >>>> consideration >>> section guidelines need to be followed and this shouldn't go forward = >>> until that is corrected. I'm told it will be, thanks. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> = https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs =20 _______________________________________________ i2rs mailing list i2rs@ietf.org = https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0042_01D2762F.75D01F80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Tom:

Original goal =3D protocol independent yang in ephemeral storage with = appropriate security.=C2=A0 =C2=A0YANG drafts on plan and on-time. = =C2=A0For I2RS appropriate security see = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-security-environment-req-02.txt as WG drafts. =C2=A0All = 6 requirements from 2 WG documents.=C2=A0 Only unique question to data = store =E2=80=93 Ephemeral + config or Ephemeral in Control Plane data = store. =C2=A0=C2=A0NETMOD=E2=80=99s choice on datastore. =C2=A0Awaiting = their comments. =C2=A0Discussion is long, but fix is short.=C2=A0 = =C2=A0Fix to drafts for Security:=C2=A0 1-2 Paragraphs for Yang Basics = security considerations, fix is=C2=A0 1 paragraph for YANG I2RS = Models.=C2=A0 =C2=A0

 

Sue

 

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Monday, = January 23, 2017 1:12 PM
To: Susan Hares
Cc: Giles = Heron; i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; Juergen = Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; The = IESG
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

 

On Jan 23, 2017:11:54 AM, at 11:54 AM, Susan Hares = <shares@ndzh.com> = wrote:

 

Giles: 

 

I disagree =E2=80=93 the I2RS Topology model does fit within the = original goals.  It is a protocol independent model with = information on topology.   This was in the original use cases = and has been a focus for I2RS WG.   See rest of the responses = below. 

 

The real change for RFC compliance for ODL=E2=80=99s read-only = Topology model would be:  a) use of NETCONF over TLS with X.509v3 = authentication, b) denoting the =E2=80=9Cdynamic control plane data = store=E2=80=9D in the get applied (whenever that gets implemented), and = support of the opaque secondary identity in tracing (if you support = tracing).  The change for the RFC compliance for the ODL=E2=80=99s = read-write would be the utilizing priority to resolve contention if = multiple clients try to write the topology database.  The priority = could be set per user identifier (passed in X.509v3) in a = pre-configuration set-up stored.   Ideally this = pre-configuration would be stored in a key store or something that is = secure.

 

Sue 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Sue, 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 I am still totally confused as to why any of what = that last sentence says has to do with the topology model other than it = is as you say, protocol independent.  That was the original = goal.

Why we are = complicating things with transport or data store things is not making = sense to me at all.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =E2=80=94Tom

 



 

 

Fr  = om: Giles Heron = [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, 2017 = 11:26 AM
To: Susan = Hares
Cc: Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject:=  Re: [i2rs] Kathleen = Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

Hi Sue,

 

On 23 Jan 2017, at 14:40, Susan Hares <shares@ndzh.com> = wrote:

 

Giles:

 

Thank you = for your comments on ODL and your implementation within ODL.  =  There are two different issues in discussion:  guidelines for = I2RS Yang modules and the application of these guidelines to the I2RS = Yang Topology model.   The guidelines for the I2RS Yang Module = have three security considerations: a)  basic yang = considerations,  b) I2RS ephemeral state considerations, and c) = insecure considerations.   Since the topology model does not = operate over an insecure transport, the only thing that I believe you = are questioning is the "I2RS Yang Models for Secure-Only = transports".     Let's walk through the = draft-ietf-i2rs-yang-l3-topology model (ietf-l3-unicast-topology) and = the draft-ietf-i2rs-yang-network-topo models (ietf-network, = ietf-network-topology).

 

i wasn=E2=80=99t the implementer of those models in = ODL.   But I=E2=80=99ve used them a fair = bit.

 

at any rate applying the I2RS security guidelines to = the I2RS YANG topology model is a bit tricky IMHO as the topology model = doesn=E2=80=99t really =E2=80=9Cfit=E2=80=9D with the original goal of = I2RS (ephemeral configuration of RIBs, ACLs etc. on network = elements) .

 

[Sue]:  No, the topology model was part of the original I2RS = YANG modules, and the Topology models (L2, L3, Base) fit its ue. 

 

The = topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt = has read/write nodes at the network, link and termination point.  = Please see the copy of the YHL diagrams below. Therefore, the basic = topology model is read-write.  The L3 model  = (draft-ietf-i2rs-yang-l3-topology-08.txt) is read write.  Please = see a copy of the YHL diagrams below.  Therefore, although your = implementation is read-only, the approved YANG modules are = read-write.  This must be considered in the Security considerations = section.  The basic requirements for I2RS are: 

 

Sure - the models are read/write but ODL=E2=80=99s = implementation is generally read-only (as I understand it, it=E2=80=99s = down to each individual protocol or application that leverages the = models to decide whether to use them in read-write or read-only = mode).   

[Sue]: This fits the I2RS Yang module. 

 

1) NETCONF = over TLS with X.509v3 as mandatory to implement protocol, 

 

Giles:  most = NETCONF implementations I=E2=80=99m aware of use ssh. And this is mandatory only = per an individual ID, right?   Or is it in a WG draft now? =  And do we have WG consensus that this applies to read-only data as = well as to read-write?

 

Sue:  NETCONF over TLS with X.509v3 is an RFC 7589.  I2RS = is requiring this to get mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation.  This mandatory-to-implement status is a change = from the basic NETCONF over SSH. 

 

2) = RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as = a permissible implementation alternative. 

 

Giles: again isn=E2=80=99t = that only specified as mandatory in an individual = ID?

Sue: The I2RS requires mutual authentication, confidentiality, data = integrity, [practical] reply protection for I2RS messages, and support = DoS mitigation.   Therefore, the RESTCONF protocol is an = alternative since it supports this with its basic work. 


3) write = contention for two clients writing a node using I2RS priority (linked to = I2RS User-ID) 

 

Giles: so that one = isn=E2=80=99t an issue for read-only = implementations=E2=80=A6

Sue: Yes.  You are correct. 

 

Sue: If the ODL = model does not support writes to these data models, then it would not = have to support the priority mechanism to resolve two clients writing = one data node. =   

Giles: indeed.

<= /div>

Sue: No other responses are below 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D




A) Basic = Yang considerations 

 

1) = readable nodes with sensitive data:  Kathleen Moriarty and Stephen = indicate that the topology data could be considered sensitive read = data.  A paragraph needs to be added to each draft indicating risks = involved in providing this information, and how deployments can keep = this data safe.   Privacy issues are involved if the = topologies are within homes or indicate user's personal devices. =   

 

If the = I2RS mandatory transport is utilized, the data streams utilize mutual = authentication, confidentiality, data integrity, and [practical] replay = protection for I2RS messages" and support "mechanism that = mitigate DoS attacks" and "DDos prevention".  This = level of security is useful when protecting sensitive data. =  

 

2) = writeable nodes with sensitive data:  Since the topology nodes are = writeable,  a security considerations needs to consider how these = sensitive data nodes will be protected.   While ODL does not = support writes to any data node, the base models do. Therefore, security = considerations must be written here. 

 

3) RPCs: = No new RPCs are considered, but providing information on the = notification data may be also useful. 

 

I2RS YANG = Model Security = Considerations

 

The = requirement for this section is the following information: 

 

1) = Indication of deployment requirement for mandatory-to-implement NETCONF = (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf), 

2) = Discussion of RPCs specific to I2RS control plane data store, =   

3) NACM = policy impacts the read-write state and augmentation of NACM by access = control for read/writing of routing protocols (RACM),  system = information (SACM), and between datastores (config to/from ephemeral = state). 

4) = Discussion of data retrieved from routing protocols, system information, = dynamic configuration (dhcp) 

5) Any = suggestion for operational knobs that control overlay of I2RS = configuration over normal configuration and I2RS operational state over = other operational state. 

 

For the = topology data models (ietf-network, ietf-network-topology),  the = paragraph could be: 

 

=E2=80=9CTh= e I2RS topology data models (ietf-network, ietf-network-topology) = require mutual authentication, confidentiality, data integrity, and = [practical] replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of TLS (see RFC7589), or an = optional transport support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model or any = notifications.   

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 

For the = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.  Deployments may provide general = configuration knobs that set the default state for NACM, RACM, SACM and = DACM for the topology database. = =E2=80=9C

 

For the L3 = topology data models (ietf-l3-unicast-topology),  the paragraph = could be: 

 

=E2=80=9CTh= e I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require = mutual authentication, confidentiality, data integrity, and [practical] = replay protection for I2RS messages. Therefore, there is a = mandatory-to-implement transport protocol of NETCONF over TLS with = X.509v3 mutual authentication (RFC7589), or an optional transport = support of RESTCONF (draft-ietf-netconf-restconf). =     This data model does not implement any = additional RPCs specific to this data model.  This data model does = support the following new notifications: l3-node-event, l3-link-event, = l3-prefix-event, and termination-point-event.   These events = provide the information about the changing L3 topology which may provide = information regarding key nodes.  Since these events are only = transported over secure transports that support mutual authentication, = confidentiality, data integrity, and [practice] replay protection, the = use of this information for DoS of an I2RS agent (aka NETCONF server) = requires the mutual authenticated client to be suborned.  

 

NACM = policies may restrict exterior access to this YANG model to simply = read-only.  For those NACM policies allowing write-access, there is = a risk that a write to a topology may create a looping topology or = overload a particular node.  NACM policies may be augment by = routing protocol access control methods (RACM), system data access = control methods (SACM), and inter-data store access control mechanisms = (DACM).  The engagement of this policy should also be control by = user policy switches (on/of).  

 

For the L3 = topology mode, the access to information on interfaces may be control by = SACM related to the interface model.  Any I2RS topology model = termination point configuration which takes augments must take care not = to cause fluctuation in the interface state.   Dynamic = configuration protocols such as DHCP or DHCPv6 may also alter the IP = Addresses associated with an interface.  DACM related to the = inter-datastore policy on the precedence between configuration of = interface IP addresses, DHCP/DHCPv6 configuration, or Topology = configuration will need to make sure the interface IP address does not = cause fluctuations in the system.   The L3 Topology model may = also read information from the routing protocols (ospf, isis or others), = or write data to the routing protocol.  RACM policy should be = carefully set so that the routing protocols do not form a place to = launch a DoS attack.  Deployments may provide general configuration = knobs that set the default state for NACM, RACM, SACM and DACM for the = topology database. = =E2=80=9C

 

 

Hopefully, = this makes the suggestion for I2RS security policy a bit more = concrete. 

Sue = Hares 

 

 

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

High-level = Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt 

 

  = ;    +--rw = networks

  = ;       +--rw network* = [network-id]

  = ;          +--rw = network-types

  = ;          +--rw = network-id          &nb= sp; network-id

  = ;          +--ro = server-provided?      = boolean

  = ;          +--rw = supporting-network* = [network-ref]

  = ;          |  +--rw = network-ref    -> = /networks/network/network-id

<= p class=3DMsoNormal>  = ;          +--rw node* = [node-id]

  = ;            =  +--rw = node-id           = node-id

  = ;            = +--rw supporting-node* [network-ref = node-ref]

  = ;            =     +--rw network-ref    -> = ../../../supporting-network/ = +

  = ;            =     = |            =         = network-ref

  = ;            =     +--rw node-ref     =   -> = /networks/network/node/node-id

 

module: = ietf-network-topology

augment = /nd:networks/nd:network:

  = ; +--rw link* [link-id]

  = ;    +--rw = source

  = ;    |  +--rw source-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw source-tp?     = -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =            = ../source-node]/termination-point/tp-id

=

  = ;    +--rw = destination

  = ;    |  +--rw dest-node?   -> = ../../../nd:node/node-id

  = ;    |  +--rw dest-tp?     -> = ../../../nd:node[nd:node-id=3Dcurrent()/+

  = ;    = |            =          = ../dest-node]/termination-point/tp-id

  = ;    +--rw = link-id           = link-id

  = ;    +--rw supporting-link* [network-ref = link-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-network/+

  = ;       = |            =         = network-ref

  = ;       +--rw = link-ref       -> = /nd:networks/network+

  = ;            =             &= nbsp;   = [nd:network-id=3Dcurrent()/../network-ref]/+

<= /div>

  = ;            =             &= nbsp;   = link/link-id

 

augment = /nd:networks/nd:network/nd:node:

  = ; +--rw termination-point* = [tp-id]

  = ;    +--rw = tp-id           &n= bsp;           &nb= sp;   tp-id

  = ;    +--rw supporting-termination-point* [network-ref = node-ref tp-ref]

  = ;       +--rw = network-ref    -> = ../../../nd:supporting-node/network-ref

=

  = ;       +--rw = node-ref       -> = ../../../nd:supporting-node/node-ref

  = ;       +--rw = tp-ref         -> = /nd:networks/network[nd:network-id=3D+

<= div>

  = ;            =             &= nbsp;   = current()/../network-ref]/node+

  = ;            =             &= nbsp;   = [nd:node-id=3Dcurrent()/../node-ref]/+

<= div>

  = ;            =              =    termination-point/tp-id

 

 

  = ; module: = ietf-l3-unicast-topology

  = ; augment = /nd:networks/nd:network/nd:network-types:

  = ;    +--rw = l3-unicast-topology!

  = ; augment = /nd:networks/nd:network:

  = ;    +--rw = l3-topology-attributes

  = ;       +--rw name?   = string

  = ;       +--rw flag*   = l3-flag-type

  = ; augment = /nd:networks/nd:network/nd:node:

  = ;    +--rw = l3-node-attributes

  = ;       +--rw = name?        = inet:domain-name

  = ;       +--rw = flag*        = node-flag-type

  = ;       +--rw router-id*   = inet:ip-address

  = ;       +--rw prefix* = [prefix]

  = ;          +--rw = prefix    = inet:ip-prefix

  = ;          +--rw = metric?   uint32

  = ;          +--rw = flag*     = prefix-flag-type

  = ; augment = /nd:networks/nd:network/lnk:link:

<= div>

  = ;    +--rw = l3-link-attributes

  = ;       +--rw = name?     = string

  = ;       +--rw = flag*     = link-flag-type

  = ;       +--rw metric?   = uint32

  = ; augment = /nd:networks/nd:network/nd:node/lnk:termination-point:<= /p>

  = ;    +--rw = l3-termination-point-attributes

  = ;       +--rw = (termination-point-type)?

  = ;          = +--:(ip)

  = ;          |  +--rw = ip-address*      = inet:ip-address

  = ;          = +--:(unnumbered)

  = ;          |  +--rw = unnumbered-id?   = uint32

  = ;          = +--:(interface-name)

  = ;            = +--ro interface-name?  = string

 

 

 

 

 

-----Origin= al Message-----
From: Giles Heron [mailto:giles.heron@gmail.com] 
Sent: Monday, January 23, = 2017 6:45 AM
To: Juergen Schoenwaelder
Cc: Susan Hares; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Kathleen Moriarty; The = IESG; i2rs-chairs@ietf.org
Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

ODL does, = indeed, implement the topology models, but generally the data in the = topology model is operational data, so I=E2=80=99m not sure how that = fits with =E2=80=9Cdesigned for the I2RS ephemeral control plane data = store=E2=80=9D - since users don=E2=80=99t write to the models directly = (making validation, priority etc. = non-issues).

 

> On 23 = Jan 2017, at 11:29, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:

> 

> I = thought the topology models are coming more or less from 

> = OpenDaylight. If so, is ODL and I2RS = implementation?

> 

> = /js

> 

> On = Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares = wrote:

>> = Juergen: 

>> 

>> = Let's focus on your second point.  The topology drafts are I2RS = drafts

>> = designed for the I2RS ephemeral control plane data store.   = How can these be

>> = generic YANG modules when the following is true: 

>> 

>> = 1) I2RS Data models do not utilize the configuration data = store,

>> = 2) I2RS Data Models do not require the same validation as 

>> = configuration data store,

>> = 3) I2RS Data models require the use of priority to handle the 

>> = multi-write contention problem into the I2RS Control Plane data 

>> = store,

>> = 4) I2RS require TLS with X.509v3 over TCP for the 

>> = mandatory-to-implement = transport,

>> 

>> = Do you disagree with draft-ietf-netmod-revised-datastores?  If = so,  

>> = the discussion should be taken up with netmod WG = list.

>> = Do you disagree with i2rs-protocol-security-requirements?  That = issue 

>> = is closed based on IESG = approval.

>> 

>> = Sue Hares

>> 

>> = -----Original Message-----

>> = From: Juergen Schoenwaelder 

>> = Sent: Monday, January 23, 2017 3:39 = AM

>> = To: Susan Hares

>> = Cc: 'Kathleen Moriarty'; 'The = IESG';

>> = Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>> = draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>> 

>> = Susan,

>> 

>> I = consider tagging a YANG object statically and universally in the 

>> = data model as "does not need secure communication" = fundamentally 

>> = flawed; I am not having an issue with insecure communication in certain = deployment contexts.

>> 

>> = The topology drafts are regular generic YANG models that just = happen 

>> = to be done in I2RS - I believe that using the generic YANG security 

>> = guidelines we have is good enough to progress these = drafts.

>> 

>> = /js

>> 

>> = On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares = wrote:

>>>= ; Juergen: 

>>>= ; 

>>>= ; I recognize that dislike insecure communication.  You made a = similar 

>>>= ; comment during the WG LC and IETF review of 

>>>= ; draft-ietf-i2rs-protocol-security-requirements.  However, = the 

>>>= ; draft-ietf-i2rs-protocol-security-requirements were passed by the 

>>>= ; I2RS WG and approved by the IESG for RFC publication and it = contains 

>>>= ; the non-secure communication.  The mandate from the I2RS WG for = this 

>>>= ; shepherd/co-chair is = clear.

>>>= ; 

>>>= ; As the shepherd for the topology drafts, I try to write-up = something 

>>>= ; that might address Kathleen's Moriarty's concerns about the = topology 

>>>= ; draft's security issues about privacy and the I2RS ephemeral = control 

>>>= ; plane

>> = data

>>>= ; store.   I welcome an open discussion on my = ideas

>> = The

>>>= ; yang doctor's YANG  security consideration = template

>>>= ; the privacy related RFCs (RFC6973) note that some information is = sensitive.

>>>= ; Hopefully, this document extends these guidelines to a new data = store. 

>>>= ; 

>>>= ; Cheerily,

>>>= ; Sue Hares

>>>= ; 

>>>= ; -----Original = Message-----

>>>= ; From: Juergen = Schoenwaelder

>>>= ; Sent: Thursday, January 19, 2017 10:34 = AM

>>>= ; To: Susan Hares

>>>= ; Cc: 'Kathleen Moriarty'; 'The IESG'; 

>>>= ; Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on

>>>= ; draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ; 

>>>= ; For what it is worth, I find the notion that data models may be 

>>>= ; written for a specific non-secure transport plain broken. There = is 

>>>= ; hardly any content of a data model I can think of which is = generally 

>>>= ; suitable for insecure = transports.

>>>= ; 

>>>= ; Can we please kill this idea of _standardizing_ information that = is 

>>>= ; suitable to send over non-secure transports? I really do not see = how 

>>>= ; the IETF can make a claim that a given piece of information is = never 

>>>= ; worth protecting (=3D suitable for non-secure = transports).

>>>= ; 

>>>= ; Note that I am fine if in a certain trusted tightly-coupled 

>>>= ; deployment information is shipped in whatever way but this is then = a 

>>>= ; property of the _deployment_ and not a property of the = _information_.

>>>= ; 

>>>= ; /js

>>>= ; 

>>>= ; On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares = wrote:

>>>= ;> Kathleen: 

>>>= ;> 

>>>= ;> I have written a draft suggesting a template for the I2RS = YANG 

>>>= ;> modules

>>>= ; which are designed to exist in the I2RS Ephemeral Control Plane data = store

>>>= ; (configuration and operational state).    

>>>= ;> 

>>>= ;> Draft location: 

>>>= ;> /

>>>= ;> 

>>>= ;> I would appreciate an email discussion with the security ADs, 

>>>= ;> OPS/NM ADs,

>>>= ; and Routing AD (Alia Atlas).  I agree that this I2RS YANG data = model

>>>= ; (L3) and the base I2RS topology model should both provide updated 

>>>= ; YANG Security Considerations sections. I would appreciate if = Benoit 

>>>= ; or you hold a discuss until we sort out these = issues.

>>>= ;> 

>>>= ;> Thank you,

>>>= ;> 

>>>= ;> Sue

>>>= ;> 

>>>= ;> -----Original = Message-----

>>>= ;> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.= ietf@gmail.com]

>>>= ;> Sent: Wednesday, January 18, 2017 9:44 = PM

>>>= ;> To: The IESG

>>>= ;> Subject: Kathleen Moriarty's No Objection = on

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>>>= ;> 

>>>= ;> Kathleen Moriarty has entered the following ballot position = for

>>>= ;> draft-ietf-i2rs-yang-l3-topology-08: No = Objection

>>>= ;> 

>>>= ;> When responding, please keep the subject line intact and reply = to 

>>>= ;> all email addresses included in the To and CC lines. (Feel free = to 

>>>= ;> cut this introductory paragraph, = however.)

>>>= ;> 

>>>= ;> 

>>>= ;> Please refer to

>>>= ;> for more information about IESG DISCUSS and COMMENT = positions.

>>>= ;> 

>>>= ;> 

>>>= ;> The document, along with other ballot positions, can be found = here:

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = -------------------------------------------------------------------

>>>= ;> -

>>>= ;> --

>>>= ;> COMMENT:

>>>= ;> = -------------------------------------------------------------------

>>>= ;> -

>>>= ;> --

>>>= ;> 

>>>= ;> I agree with Alissa's comment that the YANG module security 

>>>= ;> consideration

>>>= ; section guidelines need to be followed and this shouldn't go = forward 

>>>= ; until that is corrected.  I'm told it will be, = thanks.

>>>= ;> 

>>>= ;> 

>>>= ;> 

>>>= ;> = _______________________________________________

>>>= ;> i2rs mailing list

>>>= ;> i2rs@ietf.org<= /span>

<= p class=3DMsoNormal>>>>= ; 

>>>= ; -- 

>>>= ; Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

>>>= ; Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

>>>= ; Fax:   +49 421 200 3103       =   <http://www.jacobs-univers= ity.de/>

>>>= ; 

>> 

>> = -- 

>> = Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

>> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

>> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

>> 

> 

> = -- 

> = Juergen = Schoenwaelder          = Jacobs University Bremen = gGmbH

> = Phone: +49 421 200 3587         = Campus Ring 1 | 28759 Bremen | = Germany

> = Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

> 

> = _______________________________________________

> i2rs = mailing list

> i2rs@ietf.org<= /span>

 

__________________________= _____________________
i2rs mailing list
i2rs@ietf.org=
https://www.i= etf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_0042_01D2762F.75D01F80-- From nobody Tue Jan 24 09:00:48 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 AB0DE129598 for ; Tue, 24 Jan 2017 09:00:46 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs15iSTlmEsj for ; Tue, 24 Jan 2017 09:00:44 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 E12F01294CF for ; Tue, 24 Jan 2017 09:00:43 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cW4SV-0003U6-3V for i2rs@ietf.org; Tue, 24 Jan 2017 17:00:39 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cW4SU-0002br-SO for i2rs@ietf.org; Tue, 24 Jan 2017 17:00:38 +0000 To: i2rs@ietf.org References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <02d401d2764d$c5056470$4f102d50$@ndzh.com> From: Anton Ivanov Message-ID: Date: Tue, 24 Jan 2017 17:00:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <02d401d2764d$c5056470$4f102d50$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 17:00:46 -0000 On 24/01/17 14:25, Susan Hares wrote: > Juergen and Martin: > > Your question is appropriate at this point. These Yang Modules are I2RS > Yang Modules. Knowing whether these are attached to the configuration data > store or a control plane data store is important. For that answer, I must > await Benoit and the NETMOD Chairs. > > However, the security involved in these data models still has the same > security issues whether it is ephemeral state attached to the configuration > data store or the control plane data store. No it is not. If it is the control plane you need a security model for the northbound write access. If that model is not necessary because there is no write access, then the question is why do you need it to be in the config in the first place. A. > The solution is just different. > The 6 issues for I2RS security considerations are: 1) different > mandatory-to-implement transport for NETCONF, 2) priority resolving multiple > client writes, 3) non-secure transport, 4 ) different validations with rpc > actions, 5) different NACM, RACM, and SACM policy, 6) different data store > behavior (ephemeral/configuration or ephemeral/Control Plane data store). > Only #6 would operate different between the two data store choices. > > To recap our discussion: Any I2RS YANG module MUST have security comments > on #1 and #2 if it contains writes. The topology modules particular module > does not use #3 and #4 beyond the regular YANG module section. #5 - The > NACM policy may be the same, but the policy toward the routing system (RACM) > or system information (SACM) is different as the L3 topology models may load > information from routing protocols. The proposal for I2RS Yang module > security considerations has 3 parts: A) Basic Yang Security > considerations, B) I2RS Security considerations for secure transport, and > C) non-secure security considerations . A+B are all that is needed for > these drafts. > > Cheerily, > > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, January 24, 2017 6:52 AM > To: Susan Hares > Cc: i2rs@ietf.org; 'Martin Bjorklund'; > draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; 'Robert > Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Susan, > > so are these YANG models regular YANG models or are these YANG models > specific to the yet to be defined I2RS protocol and yet to be defined > datastores? > > I think this is the core of Martin's and my question. A simple clear and > concise answer would be nice. > > /js > > On Tue, Jan 24, 2017 at 06:42:30AM -0500, Susan Hares wrote: >> Juergen: >> >> Yep. That's the charter. draft-ietf-i2rs-yang-network-topo-10.txt is >> a generic topology model. draft-ietf-i2rs-yang-l3-topology-08.txt is a >> generic topology for L3 unicast. These support topology extension for >> non-I2RS user. We met the milestone and deliver the YANG Modules to the >> IESG. We discussed the "write" feature during WG LC and in the WG. We >> passed this by AD Benoit Claise who agreed to the reasons present by >> the draft authors. >> >> Kinda' missed your comments in the normal comment period (WG LC, IETF LC). >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >> Schoenwaelder >> Sent: Monday, January 23, 2017 5:15 PM >> To: Susan Hares >> Cc: i2rs@ietf.org; 'Martin Bjorklund'; >> draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; >> 'Robert Varga'; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> Perhaps just adding to the confusion, here is what the WG charter >> says: >> >> o The ability to extract information about topology from the network. >> Injection and creation of topology will not be considered as a work >> item. Such topology-related models will be based on a generic >> topology model to support multiple uses; the generic topology model >> should support topology extension for non-I2RS uses. >> >> And as a milestone: >> >> Dec 2016 - Request Publication of Protocol Independent Topology Data >> Models >> >> /js >> >> On Mon, Jan 23, 2017 at 05:06:04PM -0500, Susan Hares wrote: >>> Robert and Martin: >>> >>> I agree with Robert that the current implementations of the ODL >>> topology models are handled as part of the configuration data store >>> with >> ephemeral >>> state. I will point out that these implementation are pre-standards >>> implementations of the I2RS YANG Data model. >>> >>> While standardizing the topology data models, the I2RS WG have been >>> asked to align with the draft-ietf-netmod-revised-datastores-00.txt >>> NETMOD WG document. This NETMOD WG document moves the I2RS >>> ephemeral data >> store from >>> configuration data store to a Control Plane data store. If we follow >> this >>> draft, the I2RS Topology models are part of the I2RS ephemeral data > store. >>> If you disagree with the placement of the Topology data models, >>> please indicate this to the NETMOD WG and to Benoit. Could you >>> propose a way that you would see the ephemeral state working with >>> the configuration data >> store >>> to the NETMOD WG? >>> >>> Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks >> for >>> Control Plane Data store. You ask for configuration data store (which > was >>> the I2RS initial proposal). It is possible for either one to work for >> I2RS >>> Topology models - if the right details are taken care of. How do we > make >>> progress on choosing one method so we can write the I2RS Topology >>> Models security considerations.? >>> >>> Sue >>> >>> -----Original Message----- >>> From: Robert Varga [mailto:nite@hq.sk] >>> Sent: Monday, January 23, 2017 4:11 PM >>> To: Martin Bjorklund; shares@ndzh.com >>> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; >>> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; >>> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>> >>> On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >>>>> I'm pulling your questions to the top of this email. >>>>> >>>>> >>>>> >>>>> Question 1: Ok. Just to make sure I understand this correctly - >>>>> these topology models are intended to be I2RS-specific, and they >>>>> cannot be used for any other purpose. If anyone needs a general >>>>> topology model outside of the I2RS protocol, they will have to >>>>> design their own model. Is this correct? >>>>> >>>>> >>>>> >>>>> Response 1: Not really. >>>> Ok, so are you saying that the models are in fact generic, and can >>>> be used outside of I2RS? I.e., they *can* be used with the normal >>>> configuration datastores? >>>> >>> From implementation experience, yes, they can be used for storing >>> configuration. OpenDaylight uses (an ancient predecessor of) >>> yang-network-topo to store configure details about devices in its >>> managed networks. >>> >>> Regards, >>> Robert >>> >>> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> From nobody Tue Jan 24 09:42:18 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 23D4512947D; Thu, 19 Jan 2017 10:25:58 -0800 (PST) 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 kQmV0_5eAGnN; Thu, 19 Jan 2017 10:25:57 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9435B129477; Thu, 19 Jan 2017 10:25:56 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.227; From: "Susan Hares" To: "'Ladislav Lhotka'" , =?iso-8859-1?Q?'J=FCrgen_Sch=F6nw=E4lder'?= References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> <20170119132155.GB7666@elstar.local> <4E980F7E-7AA4-471C-9063-813CEBA454D0@nic.cz> In-Reply-To: <4E980F7E-7AA4-471C-9063-813CEBA454D0@nic.cz> Date: Thu, 19 Jan 2017 13:20:30 -0500 Message-ID: <037d01d27280$bfcd0330$3f670990$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdENFUFYAkrytHh+wzPqnQK0P7bgHOx5AFAdFMEtuhDd6s8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, =?iso-8859-1?Q?'Martin_Bj=F6rklund'?= , draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, 'The IESG' , 'Benoit Claise' , "'Carl Moberg \(camoberg\)'" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 18:25:58 -0000 Lada and Jurgen:=20 The reason why is the draft-ietf-rtgwg-routing-types-00 was not firm by = that time period, and Benoit suggested we publish rather than wait. The publication has taken long enough to bring these drafts closer. =20 Sigh,=20 Sue=20 -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Thursday, January 19, 2017 8:31 AM To: J=FCrgen Sch=F6nw=E4lder Cc: Benoit Claise; i2rs@ietf.org; Martin Bj=F6rklund; draft-ietf-i2rs-yang-l3-topology@ietf.org; rbonica@juniper.net; i2rs-chairs@ietf.org; The IESG; Carl Moberg (camoberg); shares@ndzh.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) > On 19 Jan 2017, at 14:21, Juergen Schoenwaelder wrote: >=20 > On Thu, Jan 19, 2017 at 03:23:48AM -0800, Benoit Claise wrote: >> 4. >>=20 >> leaf-list router-id { >> type inet:ip-address; >> description >> "Router-id for the node"; >> } >>=20 >> We don't want to wait for >> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw,=20 >> we should expedite this publication), but any good reason why this is = >> aligned with its definition? >> typedef router-id { >> type yang:dotted-quad; >> description >> "A 32-bit number in the dotted quad format assigned to each >> router. This number uniquely identifies the router within an >> Autonomous System."; >> } >=20 > For the sake of completeness, RFC 8022 has: >=20 > leaf router-id { > type yang:dotted-quad; > description > "A 32-bit number in the form of a dotted quad that is used = by > some routing protocols identifying a router."; > reference > "RFC 2328: OSPF Version 2."; > } >=20 > Using yang:dotted-quad seems appropriate here. Right, inet:ip-address value may also contain a zone index, which is = clearly undesirable in router-id. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 24 09:42:22 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 5BA9C12958A; Tue, 24 Jan 2017 03:49:54 -0800 (PST) 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 mF59KWG6Yau3; Tue, 24 Jan 2017 03:49:53 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20B01294AC; Tue, 24 Jan 2017 03:49:52 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.1.59; From: "Susan Hares" To: "'Martin Bjorklund'" References: <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123.232555.71314888595817367.mbj@tail-f.com> In-Reply-To: <20170123.232555.71314888595817367.mbj@tail-f.com> Date: Tue, 24 Jan 2017 06:44:49 -0500 Message-ID: <029501d27637$456c9af0$d045d0d0$@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: AQJx4tjLdLL/sQvcczdLrPXB8yADyAFHvL5+Afu0CsQBs0Tnjp/gE8xw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, 'Kent Watsen' , draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 11:49:54 -0000 Martin: Your statement "One problem is that relying on the solution in draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that document does not yet provide any details at all on the I2RS ephemeral data store." This statement is not what I understood from IETF 98 or the netmod ADs. I guess your objection to this data model falls into Benoit Claise (AD) and the NETMOD folks to answer. Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Monday, January 23, 2017 5:26 PM To: shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) "Susan Hares" wrote: > Robert and Martin: > > I agree with Robert that the current implementations of the ODL > topology models are handled as part of the configuration data store with ephemeral > state. I will point out that these implementation are pre-standards > implementations of the I2RS YANG Data model. > > While standardizing the topology data models, the I2RS WG have been > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > NETMOD WG document. This NETMOD WG document moves the I2RS ephemeral data store from > configuration data store to a Control Plane data store. If we follow this > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > If you disagree with the placement of the Topology data models, please > indicate this to the NETMOD WG and to Benoit. Could you propose a way > that you would see the ephemeral state working with the configuration data store > to the NETMOD WG? > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks for > Control Plane Data store. You ask for configuration data store (which > was the I2RS initial proposal). Not really; I ask for clarification. > It is possible for either one to work for I2RS > Topology models - if the right details are taken care of. How do we make > progress on choosing one method so we can write the I2RS Topology > Models security considerations.? One problem is that relying on the solution in draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that document does not yet provide any details at all on the I2RS ephemeral datastore. So I see two alternatives. Either wait with these documents, or publish them with their datamodels as is (i.e., no new additional notes), for the existing protocols and architecure. This would allow them to be implemented just like any other YANG data model. This would mean that the normal YANG security considerations guidelines should be followed. /martin > > Sue > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, January 23, 2017 4:11 PM > To: Martin Bjorklund; shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> I'm pulling your questions to the top of this email. > >> > >> > >> > >> Question 1: Ok. Just to make sure I understand this correctly - > >> these topology models are intended to be I2RS-specific, and they > >> cannot be used for any other purpose. If anyone needs a general > >> topology model outside of the I2RS protocol, they will have to > >> design their own model. Is this correct? > >> > >> > >> > >> Response 1: Not really. > > Ok, so are you saying that the models are in fact generic, and can > > be used outside of I2RS? I.e., they *can* be used with the normal > > configuration datastores? > > > > From implementation experience, yes, they can be used for storing > configuration. OpenDaylight uses (an ancient predecessor of) > yang-network-topo to store configure details about devices in its > managed networks. > > Regards, > Robert > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 09:42:26 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 F1EED1295D5; Tue, 24 Jan 2017 04:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easFANpG4YdW; Tue, 24 Jan 2017 04:35:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC11295D1; Tue, 24 Jan 2017 04:35:32 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 149761AE0402; Tue, 24 Jan 2017 13:35:31 +0100 (CET) Date: Tue, 24 Jan 2017 13:35:29 +0100 (CET) Message-Id: <20170124.133529.2274781221200613254.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <029501d27637$456c9af0$d045d0d0$@ndzh.com> References: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123.232555.71314888595817367.mbj@tail-f.com> <029501d27637$456c9af0$d045d0d0$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 12:35:34 -0000 "Susan Hares" wrote: > Martin: > > Your statement "One problem is that relying on the solution in > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that > document does not yet provide any details at all on the I2RS ephemeral data > store." This statement is not what I understood from IETF 98 or the netmod > ADs. I guess your objection to this data model falls into Benoit Claise > (AD) and the NETMOD folks to answer. Why do you think that I have any objection to draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. My objection regards your statement: 1) I2RS Data models do not utilize the configuration data store, If this is true it needs to be clarified in the document. After all these emails back and forth, it is still not clear whether this statement is true or not. /martin > > Sue Hares > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Monday, January 23, 2017 5:26 PM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" wrote: > > Robert and Martin: > > > > I agree with Robert that the current implementations of the ODL > > topology models are handled as part of the configuration data store with > ephemeral > > state. I will point out that these implementation are pre-standards > > implementations of the I2RS YANG Data model. > > > > While standardizing the topology data models, the I2RS WG have been > > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > > NETMOD WG document. This NETMOD WG document moves the I2RS ephemeral data > store from > > configuration data store to a Control Plane data store. If we follow > this > > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > > If you disagree with the placement of the Topology data models, please > > indicate this to the NETMOD WG and to Benoit. Could you propose a way > > that you would see the ephemeral state working with the configuration data > store > > to the NETMOD WG? > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > for > > Control Plane Data store. You ask for configuration data store (which > > was the I2RS initial proposal). > > Not really; I ask for clarification. > > > It is possible for either one to work for I2RS > > Topology models - if the right details are taken care of. How do we make > > progress on choosing one method so we can write the I2RS Topology > > Models security considerations.? > > One problem is that relying on the solution in > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, that > document does not yet provide any details at all on the I2RS ephemeral > datastore. > > So I see two alternatives. Either wait with these documents, or publish > them with their datamodels as is (i.e., no new additional notes), for the > existing protocols and architecure. This would allow them to be implemented > just like any other YANG data model. This would mean that the normal YANG > security considerations guidelines should be followed. > > > > /martin > > > > > Sue > > > > -----Original Message----- > > From: Robert Varga [mailto:nite@hq.sk] > > Sent: Monday, January 23, 2017 4:11 PM > > To: Martin Bjorklund; shares@ndzh.com > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - > > >> these topology models are intended to be I2RS-specific, and they > > >> cannot be used for any other purpose. If anyone needs a general > > >> topology model outside of the I2RS protocol, they will have to > > >> design their own model. Is this correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can > > > be used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > > > Regards, > > Robert > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jan 24 09:42:30 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 80101129A20; Tue, 24 Jan 2017 06:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 oCO3pQGawhfI; Tue, 24 Jan 2017 06:46:34 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B14F12960B; Tue, 24 Jan 2017 06:46:33 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Martin Bjorklund'" References: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123.232555.71314888595817367.mbj@tail-f.com> <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> In-Reply-To: <20170124.133529.2274781221200613254.mbj@tail-f.com> Date: Tue, 24 Jan 2017 09:41:15 -0500 Message-ID: <02e301d2764f$eb622f20$c2268d60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E4_01D27626.02906CE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7tArENGLfHVIiaysz/5nkUtqLdwGzROeOAb0DVI0CitQxRqDFXO3Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 14:46:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E4_01D27626.02906CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin: I'm sorry if misunderstood your comments regarding the draft-ietf-netmod-revised-datastores-00.txt. The reason the answer is unclear is that it depends on the context of the question. . If you ask if the pre-standardization I2RS Yang Topology models (basic and L3) implemented are part of the configuration data store, the answer is yes - AFAIK. . If you ask if the WG LC Topology models are approved to be part of the configuration data store, my understanding was no. I2RS WG was to abide by the decision of NETMOD WG on which data store I2RS modules were placed in. If you are concerned the implementation varies from the standardized, please express this to Benoit Claise. Based on your comments on my email thread, I will be brief in my answers today. Sue -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, January 24, 2017 7:35 AM To: shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) "Susan Hares" < shares@ndzh.com> wrote: > Martin: > > Your statement "One problem is that relying on the solution in > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, > that document does not yet provide any details at all on the I2RS > ephemeral data store." This statement is not what I understood from IETF 98 or the netmod > ADs. I guess your objection to this data model falls into Benoit Claise > (AD) and the NETMOD folks to answer. Why do you think that I have any objection to draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. My objection regards your statement: 1) I2RS Data models do not utilize the configuration data store, If this is true it needs to be clarified in the document. After all these emails back and forth, it is still not clear whether this statement is true or not. /martin > > Sue Hares > > -----Original Message----- > From: i2rs [ mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: Monday, January 23, 2017 5:26 PM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" < shares@ndzh.com> wrote: > > Robert and Martin: > > > > I agree with Robert that the current implementations of the ODL > > topology models are handled as part of the configuration data store > > with > ephemeral > > state. I will point out that these implementation are pre-standards > > implementations of the I2RS YANG Data model. > > > > While standardizing the topology data models, the I2RS WG have been > > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > > NETMOD WG document. This NETMOD WG document moves the I2RS > > ephemeral data > store from > > configuration data store to a Control Plane data store. If we follow > this > > draft, the I2RS Topology models are part of the I2RS ephemeral data store. > > If you disagree with the placement of the Topology data models, > > please indicate this to the NETMOD WG and to Benoit. Could you > > propose a way that you would see the ephemeral state working with > > the configuration data > store > > to the NETMOD WG? > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > for > > Control Plane Data store. You ask for configuration data store > > (which was the I2RS initial proposal). > > Not really; I ask for clarification. > > > It is possible for either one to work for I2RS > > Topology models - if the right details are taken care of. How do we make > > progress on choosing one method so we can write the I2RS Topology > > Models security considerations.? > > One problem is that relying on the solution in > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, > that document does not yet provide any details at all on the I2RS > ephemeral datastore. > > So I see two alternatives. Either wait with these documents, or > publish them with their datamodels as is (i.e., no new additional > notes), for the existing protocols and architecure. This would allow > them to be implemented just like any other YANG data model. This > would mean that the normal YANG security considerations guidelines should be followed. > > > > /martin > > > > > Sue > > > > -----Original Message----- > > From: Robert Varga [ mailto:nite@hq.sk] > > Sent: Monday, January 23, 2017 4:11 PM > > To: Martin Bjorklund; shares@ndzh.com > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly - > > >> these topology models are intended to be I2RS-specific, and they > > >> cannot be used for any other purpose. If anyone needs a general > > >> topology model outside of the I2RS protocol, they will have to > > >> design their own model. Is this correct? > > >> > > >> > > >> > > >> Response 1: Not really. > > > Ok, so are you saying that the models are in fact generic, and can > > > be used outside of I2RS? I.e., they *can* be used with the normal > > > configuration datastores? > > > > > > > From implementation experience, yes, they can be used for storing > > configuration. OpenDaylight uses (an ancient predecessor of) > > yang-network-topo to store configure details about devices in its > > managed networks. > > > > Regards, > > Robert > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > ------=_NextPart_000_02E4_01D27626.02906CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Martin: =

 

I'm sorry if misunderstood your comments regarding = the draft-ietf-netmod-revised-datastores-00.txt.  The reason the = answer is unclear is that it depends on the context of the question. =

 

·         = If you ask if the pre-standardization = I2RS Yang Topology models (basic and L3)  implemented are part of = the configuration data store, the answer is yes - AFAIK. =

·         = If you ask if the WG LC Topology models = are approved to be part of the configuration data store, my = understanding was no.   I2RS WG was to abide by the decision = of NETMOD WG on which data store I2RS modules were placed in. =

 

If you are concerned the implementation varies from = the standardized, please express this to Benoit Claise. =   Based on your comments on my email thread,  I will be = brief in my answers today.  

 

Sue =

 

 

-----Original Message-----
From: Martin = Bjorklund [mailto:mbj@tail-f.com]
Sent: Tuesday, January 24, 2017 = 7:35 AM
To: shares@ndzh.com
Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; = Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; = kwatsen@juniper.net
Subject: Re: [i2rs] Kathleen Moriarty's No = Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

 

"Susan Hares" <shares@ndzh.com> wrote:

> Martin: =

>

> Your statement "One problem is that = relying on the solution in

> = draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, =

> that document does not yet = provide any details at all on the I2RS

> ephemeral data store." This statement is = not what I understood from IETF 98 or the netmod

> ADs.   I guess your objection to = this data model falls into Benoit Claise

> (AD) and the NETMOD folks to answer. =

 

Why do you think that I have any objection to = draft-ietf-netmod-revised-datastores-00.  Please re-read what I = wrote.

 

My objection regards your = statement:

 

   1) I2RS Data models do not utilize the = configuration data store,

 

If = this is true it needs to be clarified in the document.

 

After = all these emails back and forth, it is still not clear whether this = statement is true or not.

 

 

/martin

 

 

 

 

 

> =

> Sue Hares

>

> = -----Original Message-----

> = From: i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of Martin

> Bjorklund

> Sent: Monday, January 23, 2017 5:26 = PM

> To: shares@ndzh.com

> Cc: i2rs@ietf.org;= draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

> = j.schoenwaelder@jacobs-un= iversity.de; i2rs-chairs@ietf.org;

> nite@hq.sk; = Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org<= o:p>

> Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

>

> = "Susan Hares" <shares@ndzh.com> wrote:

> > Robert and = Martin:

> > =

> > I agree with Robert = that the current implementations of the ODL

> > topology models are handled as part of = the configuration data store

> = > with

> = ephemeral

> > = state.   I will point out that these implementation are = pre-standards

> > = implementations of the I2RS YANG Data model. 

> >

> > While standardizing the topology data = models, the I2RS WG have been

> > asked to align with the = draft-ietf-netmod-revised-datastores-00.txt

> > NETMOD WG document.  This NETMOD WG = document moves the I2RS

> > = ephemeral data

> store = from

> > configuration data = store to a Control Plane data store.   If we = follow

> this

> > draft, the I2RS Topology models are part = of the I2RS ephemeral data store.

> > If you disagree with the placement of the = Topology data models,

> > = please indicate this to the NETMOD WG and to Benoit.  Could you =

> > propose a way that you = would see the ephemeral state working with

> > the configuration data

> store

> > to the NETMOD WG?   =

> >

> > Quite frankly, I feel a bit of whip-lash = on this topic.   NETMOD WG asks

> for

> = > Control Plane Data store.  You ask for configuration data = store

> > (which was the = I2RS initial proposal).

> =

> Not really; I ask for = clarification.

> =

> > It is possible for = either one to work for I2RS

> = > Topology models - if the right details are taken care = of.   How do we make

> > progress on choosing one method so we can = write the I2RS Topology

> > = Models security considerations.?

>

> = One problem is that relying on the solution in

> draft-ietf-netmod-revised-datastores-00 is a = bit premature - in fact,

> = that document does not yet provide any details at all on the I2RS =

> ephemeral = datastore.

>

> So I see two alternatives.  Either wait = with these documents, or

> = publish them with their datamodels as is (i.e., no new additional =

> notes), for the existing = protocols and architecure.  This would allow

> them to be implemented just like any other = YANG data model.  This

> = would mean that the normal YANG security considerations guidelines = should be followed.

> =

>

>

> = /martin

>

> >

> > Sue

> >  

> > -----Original = Message-----

> > From: = Robert Varga [mailto:nite@hq.sk<= /a>]

> > Sent: Monday, = January 23, 2017 4:11 PM

> > = To: Martin Bjorklund; shares@ndzh.com

> > Cc: i2rs@ietf.org;= draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

> = > j.schoenwaelder@jacobs-un= iversity.de; i2rs-chairs@ietf.org;

> > Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org<= o:p>

> > Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on

> > draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

> > =

> > On 01/23/2017 09:26 PM, = Martin Bjorklund wrote:

> > = >> I'm pulling your questions to the top of this email. =

> > = >>

> > >>  =

> > = >>

> > >> = Question 1: Ok.  Just to make sure I understand this correctly - =

> > >> these topology = models are intended to be I2RS-specific, and they

> > >> cannot be used for any other = purpose.  If anyone needs a general

> > >> topology model outside of the = I2RS protocol, they will have to

> > >> design their own model.  Is = this correct?

> > = >>

> > >>  =

> > = >>

> > >> = Response 1:  Not really. 

> > > Ok, so are you saying that the = models are in fact generic, and can

> > > be used outside of I2RS?  I.e., = they *can* be used with the normal

> > > configuration = datastores?

> > > =

> >

> > From implementation experience, yes, they = can be used for storing

> > = configuration. OpenDaylight uses (an ancient predecessor of) =

> > yang-network-topo to = store configure details about devices in its

> > managed networks.

> >

> > Regards,

> > Robert

> >

> >

>

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

> =

------=_NextPart_000_02E4_01D27626.02906CE0-- From nobody Tue Jan 24 09:42:34 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 8AC81129A7C; Tue, 24 Jan 2017 07:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu1T9fUkcacW; Tue, 24 Jan 2017 07:39:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9B129A74; Tue, 24 Jan 2017 07:39:15 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id CF5A21AE0402; Tue, 24 Jan 2017 16:39:12 +0100 (CET) Date: Tue, 24 Jan 2017 16:39:10 +0100 (CET) Message-Id: <20170124.163910.1660442168342299903.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <02e301d2764f$eb622f20$c2268d60$@ndzh.com> References: <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:39:17 -0000 "Susan Hares" wrote: > Martin: > > > > I'm sorry if misunderstood your comments regarding the > draft-ietf-netmod-revised-datastores-00.txt. The reason the answer is > unclear is that it depends on the context of the question. > > > > . If you ask if the pre-standardization I2RS Yang Topology models > (basic and L3) implemented are part of the configuration data store, the > answer is yes - AFAIK. This is not my question. > . If you ask if the WG LC Topology models are approved to be part of > the configuration data store, my understanding was no. I2RS WG was to > abide by the decision of NETMOD WG on which data store I2RS modules were > placed in. Yes, this is my question. And my concern is that even if your understanding is that they are not designed to be part of the configuration datastores, this fact is not mentioned in the drafts. > If you are concerned the implementation varies from the standardized, please > express this to Benoit Claise. Based on your comments on my email thread, > I will be brief in my answers today. This is not my concern. /martin > > > > Sue > > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, January 24, 2017 7:35 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; > kwatsen@juniper.net > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > Martin: > > > > > > Your statement "One problem is that relying on the solution in > > > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, > > > that document does not yet provide any details at all on the I2RS > > > ephemeral data store." This statement is not what I understood from IETF > 98 or the netmod > > > ADs. I guess your objection to this data model falls into Benoit Claise > > > (AD) and the NETMOD folks to answer. > > > > Why do you think that I have any objection to > draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. > > > > My objection regards your statement: > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > If this is true it needs to be clarified in the document. > > > > After all these emails back and forth, it is still not clear whether this > statement is true or not. > > > > > > /martin > > > > > > > > > > > > > > > > Sue Hares > > > > > > -----Original Message----- > > > From: i2rs [ mailto:i2rs-bounces@ietf.org] > On Behalf Of Martin > > > Bjorklund > > > Sent: Monday, January 23, 2017 5:26 PM > > > To: shares@ndzh.com > > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > j.schoenwaelder@jacobs-university.de; > i2rs-chairs@ietf.org; > > > nite@hq.sk; > Kathleen.Moriarty.ietf@gmail.com; > iesg@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > > Robert and Martin: > > > > > > > > I agree with Robert that the current implementations of the ODL > > > > topology models are handled as part of the configuration data store > > > > with > > > ephemeral > > > > state. I will point out that these implementation are pre-standards > > > > implementations of the I2RS YANG Data model. > > > > > > > > While standardizing the topology data models, the I2RS WG have been > > > > asked to align with the draft-ietf-netmod-revised-datastores-00.txt > > > > NETMOD WG document. This NETMOD WG document moves the I2RS > > > > ephemeral data > > > store from > > > > configuration data store to a Control Plane data store. If we follow > > > this > > > > draft, the I2RS Topology models are part of the I2RS ephemeral data > store. > > > > If you disagree with the placement of the Topology data models, > > > > please indicate this to the NETMOD WG and to Benoit. Could you > > > > propose a way that you would see the ephemeral state working with > > > > the configuration data > > > store > > > > to the NETMOD WG? > > > > > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > > > for > > > > Control Plane Data store. You ask for configuration data store > > > > (which was the I2RS initial proposal). > > > > > > Not really; I ask for clarification. > > > > > > > It is possible for either one to work for I2RS > > > > Topology models - if the right details are taken care of. How do we > make > > > > progress on choosing one method so we can write the I2RS Topology > > > > Models security considerations.? > > > > > > One problem is that relying on the solution in > > > draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact, > > > that document does not yet provide any details at all on the I2RS > > > ephemeral datastore. > > > > > > So I see two alternatives. Either wait with these documents, or > > > publish them with their datamodels as is (i.e., no new additional > > > notes), for the existing protocols and architecure. This would allow > > > them to be implemented just like any other YANG data model. This > > > would mean that the normal YANG security considerations guidelines should > be followed. > > > > > > > > > > > > /martin > > > > > > > > > > > Sue > > > > > > > > -----Original Message----- > > > > From: Robert Varga [ mailto:nite@hq.sk] > > > > Sent: Monday, January 23, 2017 4:11 PM > > > > To: Martin Bjorklund; shares@ndzh.com > > > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > > j.schoenwaelder@jacobs-university.de; > i2rs-chairs@ietf.org; > > > > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > > > >> I'm pulling your questions to the top of this email. > > > > >> > > > > >> > > > > >> > > > > >> Question 1: Ok. Just to make sure I understand this correctly - > > > > >> these topology models are intended to be I2RS-specific, and they > > > > >> cannot be used for any other purpose. If anyone needs a general > > > > >> topology model outside of the I2RS protocol, they will have to > > > > >> design their own model. Is this correct? > > > > >> > > > > >> > > > > >> > > > > >> Response 1: Not really. > > > > > Ok, so are you saying that the models are in fact generic, and can > > > > > be used outside of I2RS? I.e., they *can* be used with the normal > > > > > configuration datastores? > > > > > > > > > > > > > From implementation experience, yes, they can be used for storing > > > > configuration. OpenDaylight uses (an ancient predecessor of) > > > > yang-network-topo to store configure details about devices in its > > > > managed networks. > > > > > > > > Regards, > > > > Robert > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > From nobody Tue Jan 24 09:42:38 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 82CEA129636; Tue, 24 Jan 2017 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO6bf1w7cBsR; Tue, 24 Jan 2017 08:26:21 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1699812961D; Tue, 24 Jan 2017 08:26:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D67E36BD; Tue, 24 Jan 2017 17:26:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Usn5Ol9po3XH; Tue, 24 Jan 2017 17:26:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jan 2017 17:26:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90FB7200AD; Tue, 24 Jan 2017 17:26:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Q0LX13nBXQoX; Tue, 24 Jan 2017 17:26:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3F10200AB; Tue, 24 Jan 2017 17:26:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D2EE53E49B5A; Tue, 24 Jan 2017 17:26:21 +0100 (CET) Date: Tue, 24 Jan 2017 17:26:21 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170124162619.GA37666@elstar.local> Mail-Followup-To: Susan Hares , 'Martin Bjorklund' , i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net, kwatsen@juniper.net References: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123.232555.71314888595817367.mbj@tail-f.com> <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e301d2764f$eb622f20$c2268d60$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, 'Martin Bjorklund' , kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:26:22 -0000 On Tue, Jan 24, 2017 at 09:41:15AM -0500, Susan Hares wrote: > > . If you ask if the pre-standardization I2RS Yang Topology models > (basic and L3) implemented are part of the configuration data store, the > answer is yes - AFAIK. > > . If you ask if the WG LC Topology models are approved to be part of > the configuration data store, my understanding was no. I2RS WG was to > abide by the decision of NETMOD WG on which data store I2RS modules were > placed in. > So you are saying we have to redo topology models elsewhere in order to have some that can be implemented and used outside an I2RS system? If so, this is probably important for Benoit to understand. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 24 09:42:41 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 3B43B129597; Tue, 24 Jan 2017 08:56:30 -0800 (PST) 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 XLZwXlmNb61o; Tue, 24 Jan 2017 08:56:28 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9501294CF; Tue, 24 Jan 2017 08:56:28 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Martin Bjorklund'" References: <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> <20170124.163910.1660442168342299903.mbj@tail-f.com> In-Reply-To: <20170124.163910.1660442168342299903.mbj@tail-f.com> Date: Tue, 24 Jan 2017 11:50:31 -0500 Message-ID: <000d01d27662$0216d8d0$06448a70$@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: AQG9A1SNU/Tx/H65OFF6mQFqXkq7xgKK1DFGAq3LlN8CJ7hLsqE3sQ4w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:14 -0800 Cc: i2rs@ietf.org, kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 16:56:30 -0000 To: Martin: You have a reasonable request. If the NETMOD WG Chairs confirm their decision to make I2RS Yang Modules part of the Control Plane Datastore then as shepherd/WG-chair I will recommend these get added to the draft. Note to authors : As we wait for the NETMOD WG Chairs and Benoit to deliver the decision on Config/Control Plane datastore, the authors should work on: Basic Yang security considerations and the other I2RS Yang Module information. Sue Hares (Shepherd) -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, January 24, 2017 10:39 AM To: shares@ndzh.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) "Susan Hares" wrote: > Martin: > > > > I'm sorry if misunderstood your comments regarding the > draft-ietf-netmod-revised-datastores-00.txt. The reason the answer is > unclear is that it depends on the context of the question. > > > > . If you ask if the pre-standardization I2RS Yang Topology models > (basic and L3) implemented are part of the configuration data store, > the answer is yes - AFAIK. This is not my question. > . If you ask if the WG LC Topology models are approved to be part of > the configuration data store, my understanding was no. I2RS WG was to > abide by the decision of NETMOD WG on which data store I2RS modules > were placed in. Yes, this is my question. And my concern is that even if your understanding is that they are not designed to be part of the configuration datastores, this fact is not mentioned in the drafts. > If you are concerned the implementation varies from the standardized, please > express this to Benoit Claise. Based on your comments on my email thread, > I will be brief in my answers today. This is not my concern. /martin > > > > Sue > > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, January 24, 2017 7:35 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > lberger@labn.net; kwatsen@juniper.net > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > Martin: > > > > > > Your statement "One problem is that relying on the solution in > > > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > > fact, > > > that document does not yet provide any details at all on the I2RS > > > ephemeral data store." This statement is not what I understood from > > IETF > 98 or the netmod > > > ADs. I guess your objection to this data model falls into Benoit Claise > > > (AD) and the NETMOD folks to answer. > > > > Why do you think that I have any objection to > draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. > > > > My objection regards your statement: > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > If this is true it needs to be clarified in the document. > > > > After all these emails back and forth, it is still not clear whether > this statement is true or not. > > > > > > /martin > > > > > > > > > > > > > > > > Sue Hares > > > > > > -----Original Message----- > > > From: i2rs [ > > mailto:i2rs-bounces@ietf.org] > On Behalf Of Martin > > > Bjorklund > > > Sent: Monday, January 23, 2017 5:26 PM > > > To: shares@ndzh.com > > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > j.schoenwaelder@jacobs-university.de; > i2rs-chairs@ietf.org; > > > nite@hq.sk; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" < shares@ndzh.com> wrote: > > > > Robert and Martin: > > > > > > > > I agree with Robert that the current implementations of the ODL > > > > topology models are handled as part of the configuration data > > > store > > > > with > > > ephemeral > > > > state. I will point out that these implementation are pre-standards > > > > implementations of the I2RS YANG Data model. > > > > > > > > While standardizing the topology data models, the I2RS WG have > > > been > > > > asked to align with the > > > draft-ietf-netmod-revised-datastores-00.txt > > > > NETMOD WG document. This NETMOD WG document moves the I2RS > > > > ephemeral data > > > store from > > > > configuration data store to a Control Plane data store. If we follow > > > this > > > > draft, the I2RS Topology models are part of the I2RS ephemeral > > > data > store. > > > > If you disagree with the placement of the Topology data models, > > > > please indicate this to the NETMOD WG and to Benoit. Could you > > > > propose a way that you would see the ephemeral state working with > > > > the configuration data > > > store > > > > to the NETMOD WG? > > > > > > > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG asks > > > for > > > > Control Plane Data store. You ask for configuration data store > > > > (which was the I2RS initial proposal). > > > > > > Not really; I ask for clarification. > > > > > > > It is possible for either one to work for I2RS > > > > Topology models - if the right details are taken care of. How do we > make > > > > progress on choosing one method so we can write the I2RS Topology > > > > Models security considerations.? > > > > > > One problem is that relying on the solution in > > > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > > fact, > > > that document does not yet provide any details at all on the I2RS > > > ephemeral datastore. > > > > > > So I see two alternatives. Either wait with these documents, or > > > publish them with their datamodels as is (i.e., no new additional > > > notes), for the existing protocols and architecure. This would > > allow > > > them to be implemented just like any other YANG data model. This > > > would mean that the normal YANG security considerations guidelines > > should > be followed. > > > > > > > > > > > > /martin > > > > > > > > > > > Sue > > > > > > > > -----Original Message----- > > > > From: Robert Varga [ mailto:nite@hq.sk] > > > > Sent: Monday, January 23, 2017 4:11 PM > > > > To: Martin Bjorklund; shares@ndzh.com > > > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > > j.schoenwaelder@jacobs-university.de; > i2rs-chairs@ietf.org; > > > > > Kathleen.Moriarty.ietf@gmail.com; > iesg@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > > > >> I'm pulling your questions to the top of this email. > > > > >> > > > > >> > > > > >> > > > > >> Question 1: Ok. Just to make sure I understand this correctly > > > >> - > > > > >> these topology models are intended to be I2RS-specific, and > > > >> they > > > > >> cannot be used for any other purpose. If anyone needs a > > > >> general > > > > >> topology model outside of the I2RS protocol, they will have to > > > > >> design their own model. Is this correct? > > > > >> > > > > >> > > > > >> > > > > >> Response 1: Not really. > > > > > Ok, so are you saying that the models are in fact generic, and > > > > can > > > > > be used outside of I2RS? I.e., they *can* be used with the > > > > normal > > > > > configuration datastores? > > > > > > > > > > > > > From implementation experience, yes, they can be used for storing > > > > configuration. OpenDaylight uses (an ancient predecessor of) > > > > yang-network-topo to store configure details about devices in its > > > > managed networks. > > > > > > > > Regards, > > > > Robert > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > From nobody Tue Jan 24 09:42:43 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 510B51294D8; Tue, 24 Jan 2017 09:32:16 -0800 (PST) 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 5tdYRy6RJRTo; Tue, 24 Jan 2017 09:32:15 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC79129547; Tue, 24 Jan 2017 09:32:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123.232555.71314888595817367.mbj@tail-f.com> <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> <20170124162619.GA37666@elstar.local> In-Reply-To: <20170124162619.GA37666@elstar.local> Date: Tue, 24 Jan 2017 12:26:50 -0500 Message-ID: <007e01d27667$0d1cb560$27562020$@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: AQH7tArENGLfHVIiaysz/5nkUtqLdwGzROeOAb0DVI0CitQxRgKty5TfAgvA0Xegn7+x4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:15 -0800 Cc: i2rs@ietf.org, 'Martin Bjorklund' , kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 17:32:16 -0000 Juergen: Per my earlier answer to Martin, No. Most topology live in the same ephemeral space as the I2RS Topology drafts. Whether it is ephemeral state in configuration data store or ephemeral state for the Control Plane data store - the topology models seem (AFAIK) to be the same type of information. Cheerily, Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, January 24, 2017 11:26 AM To: Susan Hares Cc: 'Martin Bjorklund'; i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs-chairs@ietf.org; nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) On Tue, Jan 24, 2017 at 09:41:15AM -0500, Susan Hares wrote: > > . If you ask if the pre-standardization I2RS Yang Topology models > (basic and L3) implemented are part of the configuration data store, > the answer is yes - AFAIK. > > . If you ask if the WG LC Topology models are approved to be part of > the configuration data store, my understanding was no. I2RS WG was to > abide by the decision of NETMOD WG on which data store I2RS modules > were placed in. > So you are saying we have to redo topology models elsewhere in order to have some that can be implemented and used outside an I2RS system? If so, this is probably important for Benoit to understand. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 24 09:42:48 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 C231012951D; Thu, 19 Jan 2017 05:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96TLAXoz6g2P; Thu, 19 Jan 2017 05:31:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6300129439; Thu, 19 Jan 2017 05:31:21 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0] (unknown [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0]) by mail.nic.cz (Postfix) with ESMTPSA id E6CDD60FD1; Thu, 19 Jan 2017 14:31:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484832680; bh=TWcNzvBtO0axAodtKr4x+BrxVSL4wXjn3/hsSe+BqFQ=; h=From:Date:To; b=Vzwhd4lr/XbNtOZddQZg6TpkON5CI1g7um4Qyg0R3nOlcAQSgNUj4WkWgaMiEuOoT Q1c2dHxla145XOFPCwyKnI7qB76CzG52zX86BHMBDD9PJ6np4IENjG2xwgvoQGB7ES NhPTOO5sAGgzuLPf51dcNe9fqKG28vyjlwt736Io= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170119132155.GB7666@elstar.local> Date: Thu, 19 Jan 2017 14:31:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E980F7E-7AA4-471C-9063-813CEBA454D0@nic.cz> References: <148482502894.10313.4003397942513514837.idtracker@ietfa.amsl.com> <20170119132155.GB7666@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 09:42:37 -0800 Cc: i2rs@ietf.org, =?utf-8?Q?Martin_Bj=C3=B6rklund?= , draft-ietf-i2rs-yang-l3-topology@ietf.org, rbonica@juniper.net, i2rs-chairs@ietf.org, The IESG , Benoit Claise , "Carl Moberg \(camoberg\)" , shares@ndzh.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 19 Jan 2017 13:31:24 -0000 > On 19 Jan 2017, at 14:21, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 19, 2017 at 03:23:48AM -0800, Benoit Claise wrote: >> 4. >>=20 >> leaf-list router-id { >> type inet:ip-address; >> description >> "Router-id for the node"; >> } >>=20 >> We don't want to wait for >> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, = we >> should expedite this publication), but any good reason why >> this is aligned with its definition? >> typedef router-id { >> type yang:dotted-quad; >> description >> "A 32-bit number in the dotted quad format assigned to each >> router. This number uniquely identifies the router within an >> Autonomous System."; >> } >=20 > For the sake of completeness, RFC 8022 has: >=20 > leaf router-id { > type yang:dotted-quad; > description > "A 32-bit number in the form of a dotted quad that is used = by > some routing protocols identifying a router."; > reference > "RFC 2328: OSPF Version 2."; > } >=20 > Using yang:dotted-quad seems appropriate here. Right, inet:ip-address value may also contain a zone index, which is = clearly undesirable in router-id. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 24 09:54:25 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 CDBF512959F for ; Tue, 24 Jan 2017 09:54:24 -0800 (PST) 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 TMtHYJy9rzgB for ; Tue, 24 Jan 2017 09:54:23 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EAF129595 for ; Tue, 24 Jan 2017 09:54:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Anton Ivanov'" , References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> In-Reply-To: <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> Date: Tue, 24 Jan 2017 12:50:17 -0500 Message-ID: <008d01d2766a$5387def0$fa979cd0$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcQBMLE3y6EOWEkQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 17:54:25 -0000 Anton: See earlier message to Martin. Topology models are I2RS YANG Models designed for ephemeral state with specific security concerns. This is not your basic YANG model no matter which data store ephemeral gets linked to. Where is ephemeral state? By IESG Design of charter, I2RS is not in charge of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. Do not blame the messenger echoing NETMOD results, Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov Sent: Tuesday, January 24, 2017 8:30 AM To: i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) On 24/01/17 11:52, Juergen Schoenwaelder wrote: > Susan, > > so are these YANG models regular YANG models or are these YANG models > specific to the yet to be defined I2RS protocol and yet to be defined > datastores? > > I think this is the core of Martin's and my question. A simple clear > and concise answer would be nice. +1. A. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 10:14:55 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 C9D86129601 for ; Tue, 24 Jan 2017 10:14:53 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT7EwQWTp_Ne for ; Tue, 24 Jan 2017 10:14:52 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 E5DF91295B3 for ; Tue, 24 Jan 2017 10:14:51 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cW5cH-0003Wv-Iy; Tue, 24 Jan 2017 18:14:49 +0000 Received: from wyvern.kot-begemot.co.uk ([192.168.3.72]) by smaug.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cW5cH-0003JP-Ad; Tue, 24 Jan 2017 18:14:49 +0000 To: Susan Hares , i2rs@ietf.org References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> From: Anton Ivanov Message-ID: <605f2ce5-6685-3792-83b6-f95faa8a76ec@kot-begemot.co.uk> Date: Tue, 24 Jan 2017 18:14:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <008d01d2766a$5387def0$fa979cd0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 18:14:54 -0000 I am not blaming the messenger. I am just noting that from my implementer's viewpoint your security concerns seem different if you are presented as config=true or config=false. These have a different security model by definition and by implementation in most cases. This is in addition to the specific I2RS security concerns. A. On 24/01/17 17:50, Susan Hares wrote: > Anton: > > See earlier message to Martin. Topology models are I2RS YANG Models > designed for ephemeral state with specific security concerns. This is not > your basic YANG model no matter which data store ephemeral gets linked to. > Where is ephemeral state? By IESG Design of charter, I2RS is not in charge > of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. > > Do not blame the messenger echoing NETMOD results, > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > Sent: Tuesday, January 24, 2017 8:30 AM > To: i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 24/01/17 11:52, Juergen Schoenwaelder wrote: >> Susan, >> >> so are these YANG models regular YANG models or are these YANG models >> specific to the yet to be defined I2RS protocol and yet to be defined >> datastores? >> >> I think this is the core of Martin's and my question. A simple clear >> and concise answer would be nice. > +1. > > A. > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue Jan 24 10:32:52 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 AF6E6129621 for ; Tue, 24 Jan 2017 10:32:50 -0800 (PST) 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 NZXg_OImxeus for ; Tue, 24 Jan 2017 10:32:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58801295AD for ; Tue, 24 Jan 2017 10:32:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.161.15; From: "Susan Hares" To: "'Anton Ivanov'" , References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <605f2ce5-6685-3792-83b6-f95faa8a76ec@kot-begemot.co.uk> In-Reply-To: <605f2ce5-6685-3792-83b6-f95faa8a76ec@kot-begemot.co.uk> Date: Tue, 24 Jan 2017 13:28:44 -0500 Message-ID: <014301d2766f$b246d680$16d48380$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcQBMLE3ywNEukgjAVwK55Cg6V35QA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 18:32:51 -0000 Anton: I understand you question. I2RS YANG Models are mostly config=true. However, these contain a few nodes of operational state (config=false). We've been focusing on the config=true nodes in the discussion. You are right about the config=false nodes. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov Sent: Tuesday, January 24, 2017 1:15 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) I am not blaming the messenger. I am just noting that from my implementer's viewpoint your security concerns seem different if you are presented as config=true or config=false. These have a different security model by definition and by implementation in most cases. This is in addition to the specific I2RS security concerns. A. On 24/01/17 17:50, Susan Hares wrote: > Anton: > > See earlier message to Martin. Topology models are I2RS YANG Models > designed for ephemeral state with specific security concerns. This is > not your basic YANG model no matter which data store ephemeral gets linked to. > Where is ephemeral state? By IESG Design of charter, I2RS is not in > charge of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. > > Do not blame the messenger echoing NETMOD results, > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > Sent: Tuesday, January 24, 2017 8:30 AM > To: i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On 24/01/17 11:52, Juergen Schoenwaelder wrote: >> Susan, >> >> so are these YANG models regular YANG models or are these YANG models >> specific to the yet to be defined I2RS protocol and yet to be defined >> datastores? >> >> I think this is the core of Martin's and my question. A simple clear >> and concise answer would be nice. > +1. > > A. > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 12:02:18 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 BFE1B1296BE for ; Tue, 24 Jan 2017 12:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SVYITCfOnsf for ; Tue, 24 Jan 2017 12:02:15 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB7D1296C9 for ; Tue, 24 Jan 2017 12:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1485288059; bh=uI9N5AjWEuTVMHRKQoLhHvBfMq7AtLPv4TH1ti7IlPs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lSnJ8knFLCro7C1yZ/ns+C5Sqv2OnT7nTQfofxbJLnKMccrMqoasBr4SZ1nQ0qsSc hAbjB/jsYbYSBuk5AvmxiSCDT5WQL9tTFSiRkvvI8whpLlSY6ofiJt1643ANafP0nX c+gY1vAG8ed2CIBprTe8nA19OyG2Tdp2fYlmMb1o= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <008d01d2766a$5387def0$fa979cd0$@ndzh.com> Date: Tue, 24 Jan 2017 15:01:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 620, in=4705, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: i2rs@ietf.org, Anton Ivanov Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 20:02:16 -0000 Sue:=20 The implication of that statement is that actual implementations = (like ODL etc) now=20 need to copy/paste this model without the I2RS text to use them in other = ways. This seems strange and just about the most inefficient way to use these that I can = think of. =E2=80=94Tom > On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares = wrote: >=20 > Anton: =20 >=20 > See earlier message to Martin. Topology models are I2RS YANG Models > designed for ephemeral state with specific security concerns. This is = not > your basic YANG model no matter which data store ephemeral gets linked = to. > Where is ephemeral state? By IESG Design of charter, I2RS is not in = charge > of defining ephemeral state solution. NETMOD/NETCONF are. Go ask = them.=20 >=20 > Do not blame the messenger echoing NETMOD results,=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > Sent: Tuesday, January 24, 2017 8:30 AM > To: i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > On 24/01/17 11:52, Juergen Schoenwaelder wrote: >> Susan, >>=20 >> so are these YANG models regular YANG models or are these YANG models=20= >> specific to the yet to be defined I2RS protocol and yet to be defined=20= >> datastores? >>=20 >> I think this is the core of Martin's and my question. A simple clear=20= >> and concise answer would be nice. >=20 > +1. >=20 > A. >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 14:05:05 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 7AA26129408; Tue, 24 Jan 2017 14:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4p_NoxoUbcU; Tue, 24 Jan 2017 14:05:01 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48A81293FE; Tue, 24 Jan 2017 14:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10657; q=dns/txt; s=iport; t=1485295501; x=1486505101; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=slpj2h33/gBlD52GGPxCR7uNEHtFRywhXgaRpsZoDgM=; b=Lf0jYdLFg+Cmo+nA+hYjCGaoPK60a4UKQQGQXiga+Nh6EdF36Xik1ERP nKCi8c6y47srT239QavD6StBokLypp8BjK+YXRchOipAVFR7XmCi3s8x5 S07kwzzJOqc3rYXk5QSulS/8gtOvS/gw5UaC6YP6jINlmURnyaawFhv55 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQB2zodY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzQBAQEBAX8qX4NTighykRWQA4Urgg0fAQqFeAKCYRgBAgEBAQE?= =?us-ascii?q?BAQFiKIRpAQEBBAEBIUsLDAQLDgMEAQEBJwMCAicfCQgGDQYCAQEXiH8OrhaCJ?= =?us-ascii?q?SuKMwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GS4IFgmqEJoMpgl8Fm02GYosKgXd?= =?us-ascii?q?Sh2cjhhuKeYd+HziBGBMIFRU6hHGBST01hT2CPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,280,1477958400"; d="scan'208,217";a="691668918" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2017 22:04:58 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0OM4wvS019382; Tue, 24 Jan 2017 22:04:58 GMT To: Thomas Nadeau References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> From: Benoit Claise Message-ID: <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> Date: Tue, 24 Jan 2017 23:04:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> Content-Type: multipart/alternative; boundary="------------177F42CAFBEF54870A9695DD" Archived-At: Cc: i2rs@ietf.org, Anton Ivanov , IESG IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 22:05:03 -0000 This is a multi-part message in MIME format. --------------177F42CAFBEF54870A9695DD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, The thread that grows faster than you can read... Let me repeat what I mentioned already on the I2RS mailing list: This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF. Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements. We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)". Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be. I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though. Regards, Benoit > Sue: > > The implication of that statement is that actual implementations (like ODL etc) now > need to copy/paste this model without the I2RS text to use them in other ways. This seems > strange and just about the most inefficient way to use these that I can think of. > > —Tom > > > >> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares wrote: >> >> Anton: >> >> See earlier message to Martin. Topology models are I2RS YANG Models >> designed for ephemeral state with specific security concerns. This is not >> your basic YANG model no matter which data store ephemeral gets linked to. >> Where is ephemeral state? By IESG Design of charter, I2RS is not in charge >> of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. >> >> Do not blame the messenger echoing NETMOD results, >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov >> Sent: Tuesday, January 24, 2017 8:30 AM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>> Susan, >>> >>> so are these YANG models regular YANG models or are these YANG models >>> specific to the yet to be defined I2RS protocol and yet to be defined >>> datastores? >>> >>> I think this is the core of Martin's and my question. A simple clear >>> and concise answer would be nice. >> +1. >> >> A. >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --------------177F42CAFBEF54870A9695DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

The thread that grows faster than you can read...

Let me repeat what I mentioned already on the I2RS mailing list:
This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.
This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though.

Regards, Benoit
	Sue: 

	The implication of that statement is that actual implementations (like ODL etc) now 
need to copy/paste this model without the I2RS text to use them in other ways. This seems
strange and just about the most inefficient way to use these that I can think of.

	—Tom




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

Anton:  

See earlier message to Martin.  Topology models are I2RS YANG Models
designed for ephemeral state with specific security concerns.  This is not
your basic YANG model no matter which data store ephemeral gets linked to.
Where is ephemeral state?  By IESG Design of charter, I2RS is not in charge
of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them. 

Do not blame the messenger echoing NETMOD results, 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To: i2rs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On 24/01/17 11:52, Juergen Schoenwaelder wrote:

Susan,

so are these YANG models regular YANG models or are these YANG models 
specific to the yet to be defined I2RS protocol and yet to be defined 
datastores?

I think this is the core of Martin's and my question. A simple clear 
and concise answer would be nice.

+1.

A.


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

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

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

--------------177F42CAFBEF54870A9695DD-- From nobody Tue Jan 24 14:11:40 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 7AAF7129405; Tue, 24 Jan 2017 14:11:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148529589449.12573.9605834830058893631.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 14:11:34 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 22:11:34 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- To make sure both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my DISCUSS. As background, email sent to I2RS/IESG on Jan 24th 2017 Let me repeat what I mentioned already on the I2RS mailing list: This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF. Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements. We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)". Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be. I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though. Regards, Benoit ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Reading this document one more time, some more editorial comment - OLD: At the same time, where data specific to a network type does comes into play NEW: At the same time, where data specific to a network type does come into play - The figure shows two Service Functions - X1 and X2 - mapping onto a single L3 network element; this could happen, for example, if two service functions reside in the same VM (or server) and share the same set of network interfaces. You meant X1 and X3, mapping to the same Y2 L3 network element, right? - please expand ROADM - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - OLD: The abstract (base) network model is defined in the network.yang module. Its structure is shown in the following figure. Brackets enclose list keys, "rw" means configuration data, "ro" means operational state data, and "?" designates optional nodes. A "+" indicates a line break. NEW (cut/paste from RFC8022 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), "ro" state data (read-only), "-x" RPC operations or actions, and "-n" notifications. o Symbols after data node names: "?" means an optional node, "!" a container with presence, and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. Note that you have two instances of this. - Final comment: the security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as replied to Kathleen's DISCUSS. From nobody Tue Jan 24 16:15:39 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 B22D41295C5 for ; Tue, 24 Jan 2017 16:15:38 -0800 (PST) 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 WDb17Oits3wA for ; Tue, 24 Jan 2017 16:15:37 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB001295C2 for ; Tue, 24 Jan 2017 16:15:37 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Thomas Nadeau'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> In-Reply-To: <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> Date: Tue, 24 Jan 2017 19:10:57 -0500 Message-ID: <009601d2769f$80c35bd0$824a1370$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcQBMLE3ywNEukgjAiaetzeg41nl0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Anton Ivanov' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 00:15:39 -0000 Tom: Unclear what you are saying. =20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Tuesday, January 24, 2017 3:02 PM To: Susan Hares Cc: i2rs@ietf.org; Anton Ivanov Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Sue:=20 The implication of that statement is that actual implementations (like = ODL etc) now need to copy/paste this model without the I2RS text to use = them in other ways. This seems strange and just about the most = inefficient way to use these that I can think of. =E2=80=94Tom > On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares = wrote: >=20 > Anton: =20 >=20 > See earlier message to Martin. Topology models are I2RS YANG Models=20 > designed for ephemeral state with specific security concerns. This is = > not your basic YANG model no matter which data store ephemeral gets = linked to. > Where is ephemeral state? By IESG Design of charter, I2RS is not in=20 > charge of defining ephemeral state solution. NETMOD/NETCONF are. Go = ask them. >=20 > Do not blame the messenger echoing NETMOD results, >=20 > Sue >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > Sent: Tuesday, January 24, 2017 8:30 AM > To: i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > On 24/01/17 11:52, Juergen Schoenwaelder wrote: >> Susan, >>=20 >> so are these YANG models regular YANG models or are these YANG models = >> specific to the yet to be defined I2RS protocol and yet to be defined = >> datastores? >>=20 >> I think this is the core of Martin's and my question. A simple clear=20 >> and concise answer would be nice. >=20 > +1. >=20 > A. >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 16:17:06 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 6705A1295C2 for ; Tue, 24 Jan 2017 16:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLojpdFbya7k for ; Tue, 24 Jan 2017 16:17:04 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADD31295C4 for ; Tue, 24 Jan 2017 16:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1485303347; bh=pmo3peOXJFHnhhlS2XeRN/a07VcA/8GuhliBxyqKWTk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bJQz9Kqt6nl4ysmwJ+04zcjTWWZkv+QdbLNi/ji7ynqdnXTAAazj+gFH2iIsw6KQM D6Ws3DUd8GFOs0xZWHS/e+yU0pWGzEwFpyYe+SZ4cuQSsDH2XII3zRH13DbL/GdJMY /T/XaUQODobYKavlbH3Ruwg5EEdWm6Q2rs44zYhM= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <009601d2769f$80c35bd0$824a1370$@ndzh.com> Date: Tue, 24 Jan 2017 19:16:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <009601d2769f$80c35bd0$824a1370$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=14 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 621, in=4717, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: i2rs@ietf.org, Anton Ivanov Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 00:17:05 -0000 Please refer to what Benoit just said. =E2=80=94Tom > On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares = wrote: >=20 > Tom: >=20 > Unclear what you are saying. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Tuesday, January 24, 2017 3:02 PM > To: Susan Hares > Cc: i2rs@ietf.org; Anton Ivanov > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 >=20 > Sue:=20 >=20 > The implication of that statement is that actual implementations = (like ODL etc) now need to copy/paste this model without the I2RS text = to use them in other ways. This seems strange and just about the most = inefficient way to use these that I can think of. >=20 > =E2=80=94Tom >=20 >=20 >=20 >> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares = wrote: >>=20 >> Anton: =20 >>=20 >> See earlier message to Martin. Topology models are I2RS YANG Models=20= >> designed for ephemeral state with specific security concerns. This = is=20 >> not your basic YANG model no matter which data store ephemeral gets = linked to. >> Where is ephemeral state? By IESG Design of charter, I2RS is not in=20= >> charge of defining ephemeral state solution. NETMOD/NETCONF are. Go = ask them. >>=20 >> Do not blame the messenger echoing NETMOD results, >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov >> Sent: Tuesday, January 24, 2017 8:30 AM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>> Susan, >>>=20 >>> so are these YANG models regular YANG models or are these YANG = models=20 >>> specific to the yet to be defined I2RS protocol and yet to be = defined=20 >>> datastores? >>>=20 >>> I think this is the core of Martin's and my question. A simple clear=20= >>> and concise answer would be nice. >>=20 >> +1. >>=20 >> A. >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 16:26:14 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 E8B691295D2 for ; Tue, 24 Jan 2017 16:26:12 -0800 (PST) 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 mNuGITI8Nhyl for ; Tue, 24 Jan 2017 16:26:11 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37F11295CF for ; Tue, 24 Jan 2017 16:26:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Thomas Nadeau'" References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <009601d2769f$80c35bd0$824a1370$@ndzh.com> <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> In-Reply-To: <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> Date: Tue, 24 Jan 2017 19:21:42 -0500 Message-ID: <00b301d276a1$01590870$040b1950$@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: AQGvtLYzrkxhP8mTK1eafm2axwyjOwK6rYpQAgVFSKQCceLYywFHvL5+Afu0CsQBDML0aQEdpFRFAhHGRcQBMLE3ywNEukgjAiaetzcBPZfcUALsY95MoMIcmOA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Anton Ivanov' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 00:26:13 -0000 Thank you for your comment. I will follow-up with Benoit.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Tuesday, January 24, 2017 7:17 PM To: Susan Hares Cc: i2rs@ietf.org; Anton Ivanov Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Please refer to what Benoit just said. =E2=80=94Tom > On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares = wrote: >=20 > Tom: >=20 > Unclear what you are saying. =20 >=20 > Sue >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Tuesday, January 24, 2017 3:02 PM > To: Susan Hares > Cc: i2rs@ietf.org; Anton Ivanov > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 >=20 > Sue:=20 >=20 > The implication of that statement is that actual implementations = (like ODL etc) now need to copy/paste this model without the I2RS text = to use them in other ways. This seems strange and just about the most = inefficient way to use these that I can think of. >=20 > =E2=80=94Tom >=20 >=20 >=20 >> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares = wrote: >>=20 >> Anton: =20 >>=20 >> See earlier message to Martin. Topology models are I2RS YANG Models=20 >> designed for ephemeral state with specific security concerns. This=20 >> is not your basic YANG model no matter which data store ephemeral = gets linked to. >> Where is ephemeral state? By IESG Design of charter, I2RS is not in=20 >> charge of defining ephemeral state solution. NETMOD/NETCONF are. Go = ask them. >>=20 >> Do not blame the messenger echoing NETMOD results, >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov >> Sent: Tuesday, January 24, 2017 8:30 AM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>=20 >> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>> Susan, >>>=20 >>> so are these YANG models regular YANG models or are these YANG=20 >>> models specific to the yet to be defined I2RS protocol and yet to be = >>> defined datastores? >>>=20 >>> I think this is the core of Martin's and my question. A simple clear = >>> and concise answer would be nice. >>=20 >> +1. >>=20 >> A. >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jan 24 18:51:09 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 BC4D8129632 for ; Tue, 24 Jan 2017 18:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lHOIXJSfKmU for ; Tue, 24 Jan 2017 18:51:05 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 8388712962A for ; Tue, 24 Jan 2017 18:51:05 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id l23so2288172ybj.2 for ; Tue, 24 Jan 2017 18:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QIp0cR8AXZVfD1s6t8AnaAdSbkhEbyOBzUNIYqv6d9s=; b=r/hYMcOwTQfUb7kaxURBG3lULmfjQU6JGr/JnFKbFE+NNnrvb2JF85DBhp1hvOlLKR Ld+szvsZm0L3Nh8Rd2sH3KPMXuEh6ifmovhHGNCkh+KatwY7rd3FAFvbyoiJiiRq0Qza Vr/2wZnjMJB3O8sdqEwSvjEs/uHh9aWOHJRFDajt/mDLFuuWq71FzA8LmycrtK4CCBk8 m1UFoRuz+G1uTBjaxV1r5aRxBtW4XSrdcTSoW9bozyhIDgEmnnaju8/SKMS4ZTxIowne A2UT9QiJAGfbHvrkJed5bAWboorBsfN1BqbIBayaAFjU3A/Fl1feNK8/b+mVRFJZowq0 nIGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QIp0cR8AXZVfD1s6t8AnaAdSbkhEbyOBzUNIYqv6d9s=; b=oGUwu9PKK62AQ08i0htunt0MeXRL1gaBLEAo8K0J1NaTPgnEQsXT2wSvWEElI/wId0 Vlwsg3e4yFHa3zKjJUNj+Q+4M0FzQJkQxrwonlRddzEmyxE+mgchAopAs1tFpupHkyOX Rarkf7DPg8YnFxa7Vuu1o8FsXDsx3PPLK7Ktq9Jr+WmNn+Eaydvn0f+6BjmH5aNYj4kZ fWw4LgzjW8zbC30ymxNkzLsG2iIDMRmAxf2sac2o6dV+WTKousUp/VvvBVc34eCzQdjy 01O/qn27NYfFdx2cFhoE1bn3KPChC7YljpVoKTHEqik5dBoM95G2oJFEEytKFYjNFylD pETg== X-Gm-Message-State: AIkVDXK1lNfxCtagZf9ux+3LgGmDjkKwSQMR9OcYRq1ZedMEhAZUwoCsytsPncmej7LQNtY78+I67gTG/ysUyg== X-Received: by 10.37.170.166 with SMTP id t35mr25545578ybi.86.1485312664446; Tue, 24 Jan 2017 18:51:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Tue, 24 Jan 2017 18:51:03 -0800 (PST) In-Reply-To: <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <009601d2769f$80c35bd0$824a1370$@ndzh.com> <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> From: Alia Atlas Date: Tue, 24 Jan 2017 21:51:03 -0500 Message-ID: To: Thomas Nadeau Content-Type: multipart/alternative; boundary=94eb2c1882d8beeb150546e24dca Archived-At: Cc: "i2rs@ietf.org" , Anton Ivanov , Susan Hares Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 02:51:08 -0000 --94eb2c1882d8beeb150546e24dca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tom, Let me be absolutely clear - and this is not just directed at you, obviously. The IESG shares the various balloting positions for transparency. They are supposed to be handling specific technical concerns and objections= . I am extremely disappointed in the quality of the discussion, the efforts to reopen topics that have been closed and approved for publication, and the shocking and appalling unwillingness to listen or discuss the actual issues involved. I2RS uses feature extensions that were not available in basic YANG and NetConf. Those features are used in I2RS models. Unsurprisingly, this can and does carry security implications depending on the details of the feature. IF several of you have not been thinking through the implications of the work, it is not for lack of effort on the part of the I2RS WG or its chairs, in the past and present. It would be fascinating to see conversation delving into the technical questions instead of trying to assert how things should be without doing the detailed work of understanding the implications. I have excellent technical conversations with most of you across many years= . I am extremely disappointed. Alia On Tue, Jan 24, 2017 at 7:16 PM, Thomas Nadeau wrote: > > Please refer to what Benoit just said. > > =E2=80=94Tom > > > > On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares > wrote: > > > > Tom: > > > > Unclear what you are saying. > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau > > Sent: Tuesday, January 24, 2017 3:02 PM > > To: Susan Hares > > Cc: i2rs@ietf.org; Anton Ivanov > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > Sue: > > > > The implication of that statement is that actual implementations > (like ODL etc) now need to copy/paste this model without the I2RS text to > use them in other ways. This seems strange and just about the most > inefficient way to use these that I can think of. > > > > =E2=80=94Tom > > > > > > > >> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares > wrote: > >> > >> Anton: > >> > >> See earlier message to Martin. Topology models are I2RS YANG Models > >> designed for ephemeral state with specific security concerns. This is > >> not your basic YANG model no matter which data store ephemeral gets > linked to. > >> Where is ephemeral state? By IESG Design of charter, I2RS is not in > >> charge of defining ephemeral state solution. NETMOD/NETCONF are. Go > ask them. > >> > >> Do not blame the messenger echoing NETMOD results, > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > >> Sent: Tuesday, January 24, 2017 8:30 AM > >> To: i2rs@ietf.org > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> On 24/01/17 11:52, Juergen Schoenwaelder wrote: > >>> Susan, > >>> > >>> so are these YANG models regular YANG models or are these YANG models > >>> specific to the yet to be defined I2RS protocol and yet to be defined > >>> datastores? > >>> > >>> I think this is the core of Martin's and my question. A simple clear > >>> and concise answer would be nice. > >> > >> +1. > >> > >> A. > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --94eb2c1882d8beeb150546e24dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tom,

Let me be absolutely clear - and t= his is not just directed at you, obviously.

The IE= SG shares the various balloting positions for transparency.
They = are supposed to be handling specific technical concerns and objections.

I am extremely disappointed in the quality of the dis= cussion, the efforts to reopen
topics that have been closed and a= pproved for publication, and the shocking and
appalling unwilling= ness to listen or discuss the actual issues involved.

<= div>I2RS uses feature extensions that were not available in basic YANG and = NetConf.
Those features are used in I2RS models. =C2=A0 Unsurpris= ingly, this can and does carry
security implications depending on= the details of the feature.

IF several of you hav= e not been thinking through the implications of the work, it=C2=A0
is not for lack of effort on the part of the I2RS WG or its chairs, in th= e past and present.

It would be fascinating to see= conversation delving into the technical questions instead
of try= ing to assert how things should be without doing the detailed work of under= standing
the implications.

I have excell= ent technical conversations with most of you across many years.
<= br>
I am extremely disappointed.

Alia

On Tue, = Jan 24, 2017 at 7:16 PM, Thomas Nadeau <tnadeau@lucidvision.com&= gt; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please refer to what Benoit just said.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom


> On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares <shares@ndzh.com> wrote:
>
> Tom:
>
> Unclear what you are saying.
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Thomas Nadeau
> Sent: Tuesday, January 24, 2017 3:02 PM
> To: Susan Hares
> Cc: i2rs@ietf.org; Anton Ivanov > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf= -i2rs-yang-l3-topology-08: (with COMMENT)
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sue:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The implication of that statement is that ac= tual implementations (like ODL etc) now need to copy/paste this model witho= ut the I2RS text to use them in other ways. This seems strange and just abo= ut the most inefficient way to use these that I can think of.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=94Tom
>
>
>
>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares <shares@ndzh.com> wrote:
>>
>> Anton:
>>
>> See earlier message to Martin.=C2=A0 Topology models are I2RS YANG= Models
>> designed for ephemeral state with specific security concerns.=C2= =A0 This is
>> not your basic YANG model no matter which data store ephemeral get= s linked to.
>> Where is ephemeral state?=C2=A0 By IESG Design of charter, I2RS is= not in
>> charge of defining ephemeral state solution.=C2=A0 NETMOD/NETCONF = are.=C2=A0 Go ask them.
>>
>> Do not blame the messenger echoing NETMOD results,
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of Anton Ivanov
>> Sent: Tuesday, January 24, 2017 8:30 AM
>> To: i2rs@ietf.org
>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>> On 24/01/17 11:52, Juergen Schoenwaelder wrote:
>>> Susan,
>>>
>>> so are these YANG models regular YANG models or are these YANG= models
>>> specific to the yet to be defined I2RS protocol and yet to be = defined
>>> datastores?
>>>
>>> I think this is the core of Martin's and my question. A si= mple clear
>>> and concise answer would be nice.
>>
>> +1.
>>
>> A.
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs >
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--94eb2c1882d8beeb150546e24dca-- From nobody Tue Jan 24 22:47:06 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 D7E2F1297C3 for ; Tue, 24 Jan 2017 22:47:04 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uum46wBbV66N for ; Tue, 24 Jan 2017 22:47:02 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 A8047129698 for ; Tue, 24 Jan 2017 22:47:01 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWHM9-0003qg-JG; Wed, 25 Jan 2017 06:46:57 +0000 Received: from wyvern.kot-begemot.co.uk ([192.168.3.72]) by smaug.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWHM9-0001bN-CD; Wed, 25 Jan 2017 06:46:57 +0000 To: Thomas Nadeau , Susan Hares References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <009601d2769f$80c35bd0$824a1370$@ndzh.com> <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> From: Anton Ivanov Message-ID: <78ef2af1-6cea-0beb-4718-ed2dc1a9a1f3@kot-begemot.co.uk> Date: Wed, 25 Jan 2017 06:46:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <8705AFF2-9533-497D-951D-10D0544F28ED@lucidvision.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 06:47:05 -0000 On 25/01/17 00:16, Thomas Nadeau wrote: > Please refer to what Benoit just said. Concur. +1. A. > > —Tom > > >> On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares wrote: >> >> Tom: >> >> Unclear what you are saying. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Tuesday, January 24, 2017 3:02 PM >> To: Susan Hares >> Cc: i2rs@ietf.org; Anton Ivanov >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> >> Sue: >> >> The implication of that statement is that actual implementations (like ODL etc) now need to copy/paste this model without the I2RS text to use them in other ways. This seems strange and just about the most inefficient way to use these that I can think of. >> >> —Tom >> >> >> >>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares wrote: >>> >>> Anton: >>> >>> See earlier message to Martin. Topology models are I2RS YANG Models >>> designed for ephemeral state with specific security concerns. This is >>> not your basic YANG model no matter which data store ephemeral gets linked to. >>> Where is ephemeral state? By IESG Design of charter, I2RS is not in >>> charge of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. >>> >>> Do not blame the messenger echoing NETMOD results, >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov >>> Sent: Tuesday, January 24, 2017 8:30 AM >>> To: i2rs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>> >>> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>>> Susan, >>>> >>>> so are these YANG models regular YANG models or are these YANG models >>>> specific to the yet to be defined I2RS protocol and yet to be defined >>>> datastores? >>>> >>>> I think this is the core of Martin's and my question. A simple clear >>>> and concise answer would be nice. >>> +1. >>> >>> A. >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Jan 25 01:02:13 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 934C5129889; Wed, 25 Jan 2017 01:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl3ruXITCIdB; Wed, 25 Jan 2017 01:02:07 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A13512984C; Wed, 25 Jan 2017 01:02:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3A2A57BC; Wed, 25 Jan 2017 10:02:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Z34GviuanRQ5; Wed, 25 Jan 2017 10:02:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 10:02:04 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CB14200AD; Wed, 25 Jan 2017 10:02:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wkLnaZGYbMeB; Wed, 25 Jan 2017 10:02:03 +0100 (CET) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7450200AC; Wed, 25 Jan 2017 10:02:03 +0100 (CET) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 9F42A3E4AE6F; Wed, 25 Jan 2017 10:02:07 +0100 (CET) Date: Wed, 25 Jan 2017 10:02:07 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20170125090207.GC40289@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Benoit Claise , i2rs@ietf.org, IESG IESG References: <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, IESG IESG Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 09:02:09 -0000 +1 /js On Tue, Jan 24, 2017 at 11:04:56PM +0100, Benoit Claise wrote: > Dear all, > > The thread that grows faster than you can read... > > Let me repeat what I mentioned already on the I2RS mailing list: > > This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. > This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. > Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. > > This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally > applicable to this draft-ietf-i2rs-yang-l3-topology draft. > I still maintain this point of view: it would be a mistake to limit a data > model usage to a particular protocol. These topology documents are not I2RS > YANG models, these are YANG models, which can be used in different contexts. > I'm very concerned if we start having per-WG or per context data models in > the IETF. > Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the > requirements. > We can't modify the current generic YANG security considerations for an I2RS > control plane and a new datastore that are not yet specified. If you want to > describe how I2RS will be using those topology YANG models (and any YANG > models btw), then it's suitable to include this part of the I2RS protocol > spec or part of an I2RS applicability statement. This is typically where you > would describe some protocol specific information such as "write contention > for two clients writing a node using I2RS priority (linked to I2RS > User-ID)". > > Let me make my point differently. Let's assume for a moment that I2RS needs > to use the IETF interface YANG model, does it mean that you will require RFC > 7223bis with an updated security considerations? This can't be. > > I still think the generic YANG security guidelines is suitable, as it > relates to IETF specified protocols NETCONF and RESTCONF. Addition of some > generic information about the data model (not I2RS protocol) might be useful > though. For example, text around "there is a risk that a write to a topology > may create a looping topology or overload a particular node". Note that I > don't think the the security considerations is the best section for this > though. > > Regards, Benoit > > Sue: > > > > The implication of that statement is that actual implementations (like ODL etc) now > > need to copy/paste this model without the I2RS text to use them in other ways. This seems > > strange and just about the most inefficient way to use these that I can think of. > > > > —Tom > > > > > > > > > On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares wrote: > > > > > > Anton: > > > > > > See earlier message to Martin. Topology models are I2RS YANG Models > > > designed for ephemeral state with specific security concerns. This is not > > > your basic YANG model no matter which data store ephemeral gets linked to. > > > Where is ephemeral state? By IESG Design of charter, I2RS is not in charge > > > of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. > > > > > > Do not blame the messenger echoing NETMOD results, > > > > > > Sue > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov > > > Sent: Tuesday, January 24, 2017 8:30 AM > > > To: i2rs@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > On 24/01/17 11:52, Juergen Schoenwaelder wrote: > > > > Susan, > > > > > > > > so are these YANG models regular YANG models or are these YANG models > > > > specific to the yet to be defined I2RS protocol and yet to be defined > > > > datastores? > > > > > > > > I think this is the core of Martin's and my question. A simple clear > > > > and concise answer would be nice. > > > +1. > > > > > > A. > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 01:30:48 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 F1CBD129889; Wed, 25 Jan 2017 01:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 gfRS4ehW_k2d; Wed, 25 Jan 2017 01:30:42 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 DFBF012984A; Wed, 25 Jan 2017 01:30:41 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r144so19938115wme.1; Wed, 25 Jan 2017 01:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WBYq2bqr4UQhf+Od12VnOUTcHq/EEGtkOeXTi9snLCQ=; b=uMOR6qjdniEtAkiFIyqQjruH27MMGkpoIwDEYZhQbShDtu/VxlWatkVQmavCUQNwk1 v3c7m5HPprw1+av6vErD0Iko1LUT+XYBNvK72Bx/1mB3zaN/5/xvTt8zrSCTpZO/AeQb QKNX8ur4taRDYTYwiHrLAAm2lcH4gqefRgVAYP/SbHxqz/uJenPTy7lCjSSd1qFijnM7 c81GN057gQ0xbDG9pX74VCll36ZKwRJMhDIqFfMjjyAVqv1fT08Id1IJM5j/MiZ6Gtwh wlMb3wem3/sctmjVzz1+iS5ASBYzXi5/mUOoCrKtu1MHmsWyeKvN3lb0dKvjCES3nHzH qKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WBYq2bqr4UQhf+Od12VnOUTcHq/EEGtkOeXTi9snLCQ=; b=iC9T+rwmpxHXUQk1YYJGCVztl9syRIXW1yINSOjmUAeM8NNiNQwwRJWdEECQQEZimO jI9nE9bUHEpD36mBAoVR+Cig/jzUPdxhMCsNYR1e0pfYHVSsjVYMFc3jaNATtcloFlqA Jh3+3yNBDQDz0Q+BUytxmzWRz3MRrH1EvUkj40ydkoZbFalJeA5oA9QNuuJjlaMV7VQx SW7wWIJB/yPZMpyFvbR4aUFWmTcjpiLNZx8ncJLAGDVnUFVFlNGulLSqYEH3BDv37/DC Xic3Oft63vm78c2RJjgfsFBV5bS81MX4cXHX2t357K8nzpW6nAv0DF5eod9dSNyuzOhK v3tw== X-Gm-Message-State: AIkVDXLgb4y2z63Yyi8oRCdz+n0x3UNZBvTCCxIWt3Bjg6LUphytEuaVQVsMxzeWSWk8SA== X-Received: by 10.28.140.140 with SMTP id o134mr23439865wmd.87.1485336640312; Wed, 25 Jan 2017 01:30:40 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id z134sm30330033wmc.20.2017.01.25.01.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 01:30:39 -0800 (PST) From: Giles Heron Message-Id: <1FD0813A-D31B-4BCE-BEBB-54D302F61DA6@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B89092E-FF72-441D-8E9B-A60A6C8FDFFE" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 25 Jan 2017 09:30:36 +0000 In-Reply-To: <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> To: Benoit Claise References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IESG IESG , Thomas Nadeau , Anton Ivanov , i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 09:30:45 -0000 --Apple-Mail=_8B89092E-FF72-441D-8E9B-A60A6C8FDFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benoit agreed - the model should be independent of the protocol used to access = it. As mentioned earlier on the thread, OpenDaylight has implemented older = versions of the model. Over time I=E2=80=99d expect each service in = OpenDaylight that uses the models to upgrade to the upcoming RFC. In = general OpenDaylight implements the models as read-only (i.e. in its = operational data-store), though as Robert Varga has noted there=E2=80=99s = a case where we use the config data-store for device inventory (longer = term that will move to the ietf-network model but not = ietf-network-topology - though there might be use cases where you=E2=80=99= d have read-write access to ietf-network-topology, e.g when using it to = express intent.) OpenDaylight enables access to topology data using NETCONF and RESTCONF = as the north-bound protocoIs are independent of the models accessed. I = believe there has also been some work on using AMQP as a north-bound = protocol, and that the Kafka plug-in could be used to send data change = notifications for the operational models (so you=E2=80=99d get a message = when a link went up or down etc.) South-bound we have also used ODL to = read topology data from a device using NETCONF/YANG (IIRC we showed a = demo of this using Homenet running on OpenWrt at IETF a couple of years = back). I=E2=80=99m also working with other groups such as MEF and OpenROADM to = leverage the I2RS topology models for their YANG efforts. So clearly = the models need to be used in a non-I2RS environment. Giles > On 24 Jan 2017, at 22:04, Benoit Claise wrote: >=20 > Dear all, >=20 > The thread that grows faster than you can read... >=20 > Let me repeat what I mentioned already on the I2RS mailing list: > This document contains a YANG model, a generic YANG model that could = be accessed by NETCONF, RESTCONF, or the future I2RS protocol. > This document doesn't say (and that would be a mistake IMO if it = would) that this YANG model can only be accessed by the I2RS protocol. > Hence I'm advocating that the security considerations diligently = follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines = , and that = they don't go in the I2RS protocol specific details. > This comment was made for draft-ietf-i2rs-yang-network-topo, but is = equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. > I still maintain this point of view: it would be a mistake to limit a = data model usage to a particular protocol. These topology documents are = not I2RS YANG models, these are YANG models, which can be used in = different contexts. I'm very concerned if we start having per-WG or per = context data models in the IETF. > Btw, I haven't seen a RFC specifying what the I2RS protocol is, only = the requirements. > We can't modify the current generic YANG security considerations for = an I2RS control plane and a new datastore that are not yet specified. If = you want to describe how I2RS will be using those topology YANG models = (and any YANG models btw), then it's suitable to include this part of = the I2RS protocol spec or part of an I2RS applicability statement. This = is typically where you would describe some protocol specific information = such as "write contention for two clients writing a node using I2RS = priority (linked to I2RS User-ID)".=20 >=20 > Let me make my point differently. Let's assume for a moment that I2RS = needs to use the IETF interface YANG model, does it mean that you will = require RFC 7223bis with an updated security considerations? This can't = be. >=20 > I still think the generic YANG security guidelines is suitable, as it = relates to IETF specified protocols NETCONF and RESTCONF. Addition of = some generic information about the data model (not I2RS protocol) might = be useful though. For example, text around "there is a risk that a write = to a topology may create a looping topology or overload a particular = node". Note that I don't think the the security considerations is the = best section for this though.=20 >=20 > Regards, Benoit >> Sue:=20 >>=20 >> The implication of that statement is that actual implementations = (like ODL etc) now=20 >> need to copy/paste this model without the I2RS text to use them in = other ways. This seems >> strange and just about the most inefficient way to use these that I = can think of. >>=20 >> =E2=80=94Tom >>=20 >>=20 >>=20 >>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares = wrote: >>>=20 >>> Anton: =20 >>>=20 >>> See earlier message to Martin. Topology models are I2RS YANG Models >>> designed for ephemeral state with specific security concerns. This = is not >>> your basic YANG model no matter which data store ephemeral gets = linked to. >>> Where is ephemeral state? By IESG Design of charter, I2RS is not in = charge >>> of defining ephemeral state solution. NETMOD/NETCONF are. Go ask = them.=20 >>>=20 >>> Do not blame the messenger echoing NETMOD results,=20 >>>=20 >>> Sue=20 >>>=20 >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org = ] On Behalf Of Anton Ivanov >>> Sent: Tuesday, January 24, 2017 8:30 AM >>> To: i2rs@ietf.org >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>=20 >>> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>>> Susan, >>>>=20 >>>> so are these YANG models regular YANG models or are these YANG = models=20 >>>> specific to the yet to be defined I2RS protocol and yet to be = defined=20 >>>> datastores? >>>>=20 >>>> I think this is the core of Martin's and my question. A simple = clear=20 >>>> and concise answer would be nice. >>> +1. >>>=20 >>> A. >>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs = >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs = >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs = >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_8B89092E-FF72-441D-8E9B-A60A6C8FDFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Benoit

agreed - the model should be independent of the protocol used = to access it.

As= mentioned earlier on the thread, OpenDaylight has implemented older = versions of the model.  Over time I=E2=80=99d expect each service = in OpenDaylight that uses the models to upgrade to the upcoming RFC. =  In general OpenDaylight implements the models as read-only (i.e. = in its operational data-store), though as Robert Varga has noted = there=E2=80=99s a case where we use the config data-store for device = inventory (longer term that will move to the ietf-network model but not = ietf-network-topology - though there might be use cases where you=E2=80=99= d have read-write access to ietf-network-topology, e.g when using it to = express intent.)

OpenDaylight enables access to topology data using NETCONF = and RESTCONF as the north-bound protocoIs are independent of the models = accessed.  I believe there has also been some work on using AMQP as = a north-bound protocol, and that the Kafka plug-in could be used to send = data change notifications for the operational models (so you=E2=80=99d = get a message when a link went up or down etc.)   South-bound we = have also used ODL to read topology data from a device using = NETCONF/YANG (IIRC we showed a demo of this using Homenet running on = OpenWrt at IETF a couple of years back).

I=E2=80=99m also working with other = groups such as MEF and OpenROADM to leverage the I2RS topology models = for their YANG efforts.    So clearly the models need to be = used in a non-I2RS environment.

Giles

On 24 Jan 2017, at 22:04, Benoit Claise = <bclaise@cisco.com> wrote:

=20 =20
Dear all,

The thread that grows faster than you can read...

Let me repeat what I mentioned already on the I2RS mailing = list:
This document contains a YANG model, a =
generic YANG model that could be accessed by NETCONF, RESTCONF, or the =
future I2RS protocol.
This document doesn't say (and that would be a mistake IMO if it would) =
that this YANG model can only be accessed by the I2RS protocol.
Hence I'm advocating that the security considerations diligently follow =
http=
s://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that =
they don't go in the I2RS protocol specific details.
This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
= Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though.

Regards, Benoit
	Sue:=20

	The implication of that statement is that actual implementations =
(like ODL etc) now=20
need to copy/paste this model without the I2RS text to use them in other =
ways. This seems
strange and just about the most inefficient way to use these that I can =
think of.

	=E2=80=94Tom




On Jan 24, 2017:12:50 PM, at 12:50 PM, =
Susan Hares <shares@ndzh.com> wrote:

Anton: =20

See earlier message to Martin.  Topology models are I2RS YANG Models
designed for ephemeral state with specific security concerns.  This is =
not
your basic YANG model no matter which data store ephemeral gets linked =
to.
Where is ephemeral state?  By IESG Design of charter, I2RS is not in =
charge
of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them.=20=


Do not blame the messenger echoing NETMOD results,=20

Sue=20

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] =
On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To: i2rs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On 24/01/17 11:52, Juergen Schoenwaelder wrote:

Susan,

so are these YANG models regular YANG models or are these YANG models=20
specific to the yet to be defined I2RS protocol and yet to be defined=20
datastores?

I think this is the core of Martin's and my question. A simple clear=20
and concise answer would be nice.

+1.

A.


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/m=
ailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/m=
ailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/m=
ailman/listinfo/i2rs

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

= --Apple-Mail=_8B89092E-FF72-441D-8E9B-A60A6C8FDFFE-- From nobody Wed Jan 25 01:37:04 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 333F812984C; Wed, 25 Jan 2017 01:37:03 -0800 (PST) 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 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 zOUVKEBh1Lml; Wed, 25 Jan 2017 01:37:00 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 2B06112988D; Wed, 25 Jan 2017 01:36:59 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWK0f-0003wo-J5; Wed, 25 Jan 2017 09:36:57 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cWK0f-00034r-Bc; Wed, 25 Jan 2017 09:36:57 +0000 To: Giles Heron , Benoit Claise References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> <1FD0813A-D31B-4BCE-BEBB-54D302F61DA6@gmail.com> From: Anton Ivanov Message-ID: <4284518e-9d8c-a6b0-db05-d23b4d261793@kot-begemot.co.uk> Date: Wed, 25 Jan 2017 09:36:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <1FD0813A-D31B-4BCE-BEBB-54D302F61DA6@gmail.com> Content-Type: multipart/alternative; boundary="------------C09A32E6B3D34E09F939AEA7" X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Cc: Thomas Nadeau , IESG IESG , i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 09:37:03 -0000 This is a multi-part message in MIME format. --------------C09A32E6B3D34E09F939AEA7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 25/01/17 09:30, Giles Heron wrote: > Hi Benoit > > agreed - the model should be independent of the protocol used to > access it. > > As mentioned earlier on the thread, OpenDaylight has implemented older > versions of the model. Over time I’d expect each service in > OpenDaylight that uses the models to upgrade to the upcoming RFC. In > general OpenDaylight implements the models as read-only (i.e. in its > operational data-store), though as Robert Varga has noted there’s a > case where we use the config data-store for device inventory (longer > term that will move to the ietf-network model but not > ietf-network-topology - though there might be use cases where you’d > have read-write access to ietf-network-topology, e.g when using it to > express intent.) > > OpenDaylight enables access to topology data using NETCONF and > RESTCONF as the north-bound protocoIs are independent of the models > accessed. I believe there has also been some work on using AMQP as a > north-bound protocol, and that the Kafka plug-in could be used to send > data change notifications for the operational models (so you’d get a > message when a link went up or down etc.) South-bound we have also > used ODL to read topology data from a device using NETCONF/YANG (IIRC > we showed a demo of this using Homenet running on OpenWrt at IETF a > couple of years back). > > I’m also working with other groups such as MEF and OpenROADM to > leverage the I2RS topology models for their YANG efforts. So > clearly the models need to be used in a non-I2RS environment. +1. I am working on JSON RPC ODL southbound into non-ODL systems. For some of the use cases you may need to build topologies out of the information you receive from it. So from my extremely selfish implementer perspective having topology models which is stapled to a particular protocol and are not allowed to be used in a more generic way, namely in a non-I2RS environment, is a definitive NO GO. A. > > Giles > >> On 24 Jan 2017, at 22:04, Benoit Claise > > wrote: >> >> Dear all, >> >> The thread that grows faster than you can read... >> >> Let me repeat what I mentioned already on the I2RS mailing list: >> >> This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. >> This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. >> Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. >> >> This comment was made for draft-ietf-i2rs-yang-network-topo, but is >> equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. >> I still maintain this point of view: it would be a mistake to limit a >> data model usage to a particular protocol. These topology documents >> are not I2RS YANG models, these are YANG models, which can be used in >> different contexts. I'm very concerned if we start having per-WG or >> per context data models in the IETF. >> Btw, I haven't seen a RFC specifying what the I2RS protocol is, only >> the requirements. >> We can't modify the current generic YANG security considerations for >> an I2RS control plane and a new datastore that are not yet specified. >> If you want to describe how I2RS will be using those topology YANG >> models (and any YANG models btw), then it's suitable to include this >> part of the I2RS protocol spec or part of an I2RS applicability >> statement. This is typically where you would describe some protocol >> specific information such as "write contention for two clients >> writing a node using I2RS priority (linked to I2RS User-ID)". >> >> Let me make my point differently. Let's assume for a moment that I2RS >> needs to use the IETF interface YANG model, does it mean that you >> will require RFC 7223bis with an updated security considerations? >> This can't be. >> >> I still think the generic YANG security guidelines is suitable, as it >> relates to IETF specified protocols NETCONF and RESTCONF. Addition of >> some generic information about the data model (not I2RS protocol) >> might be useful though. For example, text around "there is a risk >> that a write to a topology may create a looping topology or overload >> a particular node". Note that I don't think the the security >> considerations is the best section for this though. >> >> Regards, Benoit >>> Sue: >>> >>> The implication of that statement is that actual implementations (like ODL etc) now >>> need to copy/paste this model without the I2RS text to use them in other ways. This seems >>> strange and just about the most inefficient way to use these that I can think of. >>> >>> —Tom >>> >>> >>> >>>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares wrote: >>>> >>>> Anton: >>>> >>>> See earlier message to Martin. Topology models are I2RS YANG Models >>>> designed for ephemeral state with specific security concerns. This is not >>>> your basic YANG model no matter which data store ephemeral gets linked to. >>>> Where is ephemeral state? By IESG Design of charter, I2RS is not in charge >>>> of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. >>>> >>>> Do not blame the messenger echoing NETMOD results, >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov >>>> Sent: Tuesday, January 24, 2017 8:30 AM >>>> To:i2rs@ietf.org >>>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>>> >>>> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>>>> Susan, >>>>> >>>>> so are these YANG models regular YANG models or are these YANG models >>>>> specific to the yet to be defined I2RS protocol and yet to be defined >>>>> datastores? >>>>> >>>>> I think this is the core of Martin's and my question. A simple clear >>>>> and concise answer would be nice. >>>> +1. >>>> >>>> A. >>>> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > --------------C09A32E6B3D34E09F939AEA7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 25/01/17 09:30, Giles Heron wrote:
Hi Benoit

agreed - the model should be independent of the protocol used to access it.

As mentioned earlier on the thread, OpenDaylight has implemented older versions of the model.  Over time I’d expect each service in OpenDaylight that uses the models to upgrade to the upcoming RFC.  In general OpenDaylight implements the models as read-only (i.e. in its operational data-store), though as Robert Varga has noted there’s a case where we use the config data-store for device inventory (longer term that will move to the ietf-network model but not ietf-network-topology - though there might be use cases where you’d have read-write access to ietf-network-topology, e.g when using it to express intent.)

OpenDaylight enables access to topology data using NETCONF and RESTCONF as the north-bound protocoIs are independent of the models accessed.  I believe there has also been some work on using AMQP as a north-bound protocol, and that the Kafka plug-in could be used to send data change notifications for the operational models (so you’d get a message when a link went up or down etc.)   South-bound we have also used ODL to read topology data from a device using NETCONF/YANG (IIRC we showed a demo of this using Homenet running on OpenWrt at IETF a couple of years back).

I’m also working with other groups such as MEF and OpenROADM to leverage the I2RS topology models for their YANG efforts.    So clearly the models need to be used in a non-I2RS environment.

+1.

I am working on JSON RPC ODL southbound into non-ODL systems. For some of the use cases you may need to build topologies out of the information you receive from it.

So from my extremely selfish implementer perspective having topology models which is stapled to a particular protocol and are not allowed to be used in a more generic way, namely in a non-I2RS environment, is a definitive NO GO.

A.


Giles

On 24 Jan 2017, at 22:04, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

The thread that grows faster than you can read...

Let me repeat what I mentioned already on the I2RS mailing list:
This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.
This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though.

Regards, Benoit
	Sue: 

	The implication of that statement is that actual implementations (like ODL etc) now 
need to copy/paste this model without the I2RS text to use them in other ways. This seems
strange and just about the most inefficient way to use these that I can think of.

	—Tom




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

Anton:  

See earlier message to Martin.  Topology models are I2RS YANG Models
designed for ephemeral state with specific security concerns.  This is not
your basic YANG model no matter which data store ephemeral gets linked to.
Where is ephemeral state?  By IESG Design of charter, I2RS is not in charge
of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them. 

Do not blame the messenger echoing NETMOD results, 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To: i2rs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On 24/01/17 11:52, Juergen Schoenwaelder wrote:

Susan,

so are these YANG models regular YANG models or are these YANG models 
specific to the yet to be defined I2RS protocol and yet to be defined 
datastores?

I think this is the core of Martin's and my question. A simple clear 
and concise answer would be nice.

+1.

A.


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

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

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

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


--------------C09A32E6B3D34E09F939AEA7-- From nobody Wed Jan 25 05:36:05 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 6AAA11298C5; Wed, 25 Jan 2017 05:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ_0DSSPPic0; Wed, 25 Jan 2017 05:35:56 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 0F83C1298AC; Wed, 25 Jan 2017 05:35:56 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id 123so9694390ybe.3; Wed, 25 Jan 2017 05:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=LK8kpKpdstQlG9Ug64M94+Wq1DDokVShsjwaKthIOEA=; b=ZzH+1rRqXnYe29RPfdd8COVG8Jb61DKZVM/x/4rm58yCC9wVIhsJH9+7Wd8Q+GcdSK mn8/OQq59Q3y+9+tg40rS5S7F7XTF8KkkHx2d84W63q+KFx2VjnsHB45gdpCFSjnU/v3 jgPVWa9OjlZJOlq5QEgGTpU+wTvYR8KFHoMnWC0LAN4eGmf+8P8Nsy0qVgEVqNuB8CXr JiryKdv/c+W8rUnb1cIeSIgBipnDbn+8w30PhAxFXs55vbZyi88laKsYy3fiz+aBJ2+R z7sL0GCft746FH1tiPnlB47YB0VahFK2d66Ei0vBQIVdNd4oli7nc01g+e6G+D+0XtvH VDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=LK8kpKpdstQlG9Ug64M94+Wq1DDokVShsjwaKthIOEA=; b=dWHY2ktw+jLIY8TmV6fHCgUu75v3bjT5ZIA1fR/dY0OGUzKkhURpjtsxBXf6W8xA7i oq61vbOuv7A4pkpnNaO40QSH1C+y2AyBQxVeZPX7uov/i6B1bFCNW3eIT3TXsuvIr36W V6h2KwKESFsXX2XBq7a2UuUgmyFYAf+lrw1y3OgBDLCXY5eqFjZxA+LxxYIKIcn1dOVc /+ZcHT/nSTosQvp+1+9Rwwt1c5NJLkOXhR7yCmokt2iW4UAsyA3Da7UQr35F2VvzP9F7 DmLFQJi+bO4JyBrk/rGccofIjXwoQN40HWK3JT66/hzh7yDeFM2f1hlodItNCn6eWwN4 wLIg== X-Gm-Message-State: AIkVDXJhcYhP6fhOK+Bg9dmlaWkf0n8vvdrepRcyOjg2RRsQs128HP/uBHWvz8tOj7lWDsRijPSVF0plxrxHxQ== X-Received: by 10.13.212.149 with SMTP id w143mr35084332ywd.180.1485351355079; Wed, 25 Jan 2017 05:35:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Wed, 25 Jan 2017 05:35:53 -0800 (PST) From: Alia Atlas Date: Wed, 25 Jan 2017 08:35:53 -0500 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a114fab10e32a9d0546eb4f4a Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 13:35:59 -0000 --001a114fab10e32a9d0546eb4f4a Content-Type: text/plain; charset=UTF-8 Could one of you who are saying that a writable topology model can appear in the regular configuration data-store please explain: How does validation at reboot work when there is dependency on learned topology data that isn't yet available? I'd prefer more technology discussion of the nuances. This one has been an active topic of discussion for at least 2 years, so I'm hopeful that you all have well thought out answers. Regards, Alia On Wed, Jan 25, 2017 at 7:27 AM, Lou Berger wrote: Sue, > >> > In short, I'm going to agree with Benoit - but for slightly different > > reasons as I also co-chair TEAS, a group that is basing some of its > > work on I2RS developed models. > >> > As a WG chair, I have always viewed the models being developed by I2RS > > as typical models that are generally useful, and being defined by I2RS > > simply because they were ahead of other groups that might otherwise > > define the models -- and I view this as a fine thing that has benefit > > for YANG users and other WGs. As TEAS chair, this is what lead me to > > ensure that the models being defined in TEAS built on the I2RS YANG > > modules vs their original path of redefining parallel function. > >> > As part of my view of the I2RS models being generally applicable to uses > > beyond I2RS together with I2RS choosing YANG for modeling ephemeral > > data, I have always expected that the I2RS WG would at some (perhaps as > > part of the I2RS protocol definition) define how any YANG model can be > > used to support I2RS. This view certainly lead me to conclude that > > having the I2RS models move forward, just like any other YANG model, > > makes sense and would benefit the other models and WGs that reference > > this core work. This view also allows for the relationship to the > > revised-data store work, as well as the specification of which data > > store(s) I2RS uses, to be separately defined -- and to not gate > > publication of these models. This separate specification would be > > the location for any I2RS-specific transport and security considers, > > so such would not belong in the generally reusable models developed > > by I2RS. > >> > Essentially, As NETMOD co-chair, I concluded that the revised data > > store work provided the direction on how ephemeral would be supported > > in a general YANG context and, therefore, the major open issue / gating > > impediment to progressing I2RS models had been removed and publication > > of these models were unblocked. This also motivated my comments in the > > related discussions at the last meeting. > >> > If my understanding/view is correct, i.e., that the topology models are > > just like any other YANG model, then I think publication can and > > should proceed (with the appropriate text for a typical YANG model). If > > I misunderstood something, and the models produced by I2RS are limited > > to ephemeral representations/data stores as well as specific YANG > > transport protocols -- then as TEAS chair, I have to hit reset on the > > TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to > > discuss what it means for a YANG model to be protocol/datastore > > specific and if any guidelines or other new NTEMOD documents are need > > to support such. > >> > Less importantly, as I2RS participant, I'd also ask for the documents > > to be sent back to the WG for a new last call once the documents > > are updated to reflect their narrow scope -- as I bet I'm not the only > > person who viewed this work applicable to non-ephemeral uses. > >> > I hope this helps. > >> > Lou > > > On January 24, 2017 11:56:32 AM "Susan Hares" wrote: > > > To: Martin: > > > > You have a reasonable request. If the NETMOD WG Chairs confirm their > > decision to make I2RS Yang Modules part of the Control Plane Datastore > then > > as shepherd/WG-chair I will recommend these get added to the draft. > > > > Note to authors : > > > > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision on > > Config/Control Plane datastore, the authors should work on: Basic Yang > > security considerations and the other I2RS Yang Module information. > > > > Sue Hares (Shepherd) > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, January 24, 2017 10:39 AM > > To: shares@ndzh.com > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; > > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; > > kwatsen@juniper.net > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" wrote: > >> Martin: > >> > >> > >> > >> I'm sorry if misunderstood your comments regarding the > >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer is > >> unclear is that it depends on the context of the question. > >> > >> > >> > >> . If you ask if the pre-standardization I2RS Yang Topology > models > >> (basic and L3) implemented are part of the configuration data store, > >> the answer is yes - AFAIK. > > > > This is not my question. > > > >> . If you ask if the WG LC Topology models are approved to be > part > > of > >> the configuration data store, my understanding was no. I2RS WG was to > >> abide by the decision of NETMOD WG on which data store I2RS modules > >> were placed in. > > > > Yes, this is my question. And my concern is that even if your > understanding > > is that they are not designed to be part of the configuration datastores, > > this fact is not mentioned in the drafts. > > > >> If you are concerned the implementation varies from the standardized, > > please > >> express this to Benoit Claise. Based on your comments on my email > > thread, > >> I will be brief in my answers today. > > > > This is not my concern. > > > > > > /martin > > > > > > > >> > >> > >> > >> Sue > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Martin Bjorklund [mailto:mbj@tail-f.com] > >> Sent: Tuesday, January 24, 2017 7:35 AM > >> To: shares@ndzh.com > >> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > >> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > >> nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > >> lberger@labn.net; kwatsen@juniper.net > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > >> > >> "Susan Hares" < shares@ndzh.com> wrote: > >> > >> > Martin: > >> > >> > > >> > >> > Your statement "One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral data store." This statement is not what I understood from > >> > IETF > >> 98 or the netmod > >> > >> > ADs. I guess your objection to this data model falls into Benoit > > Claise > >> > >> > (AD) and the NETMOD folks to answer. > >> > >> > >> > >> Why do you think that I have any objection to > >> draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. > >> > >> > >> > >> My objection regards your statement: > >> > >> > >> > >> 1) I2RS Data models do not utilize the configuration data store, > >> > >> > >> > >> If this is true it needs to be clarified in the document. > >> > >> > >> > >> After all these emails back and forth, it is still not clear whether > >> this statement is true or not. > >> > >> > >> > >> > >> > >> /martin > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > >> > Sue Hares > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: i2rs [ > >> > mailto:i2rs-bounces@ietf.org] > >> On Behalf Of Martin > >> > >> > Bjorklund > >> > >> > Sent: Monday, January 23, 2017 5:26 PM > >> > >> > To: shares@ndzh.com > >> > >> > Cc: i2rs@ietf.org; > >> > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; > >> > >> > > >> j.schoenwaelder@jacobs-university.de; > >> i2rs-chairs@ietf.org; > >> > >> > nite@hq.sk; > >> > >> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org > >> > >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > >> > >> > "Susan Hares" < shares@ndzh.com> wrote: > >> > >> > > Robert and Martin: > >> > >> > > > >> > >> > > I agree with Robert that the current implementations of the ODL > >> > >> > > topology models are handled as part of the configuration data > >> > > store > >> > >> > > with > >> > >> > ephemeral > >> > >> > > state. I will point out that these implementation are > pre-standards > >> > >> > > implementations of the I2RS YANG Data model. > >> > >> > > > >> > >> > > While standardizing the topology data models, the I2RS WG have > >> > > been > >> > >> > > asked to align with the > >> > > draft-ietf-netmod-revised-datastores-00.txt > >> > >> > > NETMOD WG document. This NETMOD WG document moves the I2RS > >> > >> > > ephemeral data > >> > >> > store from > >> > >> > > configuration data store to a Control Plane data store. If we > follow > >> > >> > this > >> > >> > > draft, the I2RS Topology models are part of the I2RS ephemeral > >> > > data > >> store. > >> > >> > > If you disagree with the placement of the Topology data models, > >> > >> > > please indicate this to the NETMOD WG and to Benoit. Could you > >> > >> > > propose a way that you would see the ephemeral state working with > >> > >> > > the configuration data > >> > >> > store > >> > >> > > to the NETMOD WG? > >> > >> > > > >> > >> > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG > > asks > >> > >> > for > >> > >> > > Control Plane Data store. You ask for configuration data store > >> > >> > > (which was the I2RS initial proposal). > >> > >> > > >> > >> > Not really; I ask for clarification. > >> > >> > > >> > >> > > It is possible for either one to work for I2RS > >> > >> > > Topology models - if the right details are taken care of. How do > we > >> make > >> > >> > > progress on choosing one method so we can write the I2RS Topology > >> > >> > > Models security considerations.? > >> > >> > > >> > >> > One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral datastore. > >> > >> > > >> > >> > So I see two alternatives. Either wait with these documents, or > >> > >> > publish them with their datamodels as is (i.e., no new additional > >> > >> > notes), for the existing protocols and architecure. This would > >> > allow > >> > >> > them to be implemented just like any other YANG data model. This > >> > >> > would mean that the normal YANG security considerations guidelines > >> > should > >> be followed. > >> > >> > > >> > >> > > >> > >> > > >> > >> > /martin > >> > >> > > >> > >> > > > >> > >> > > Sue > >> > >> > > > >> > >> > > -----Original Message----- > >> > >> > > From: Robert Varga [ mailto:nite@hq.sk] > >> > >> > > Sent: Monday, January 23, 2017 4:11 PM > >> > >> > > To: Martin Bjorklund; shares@ndzh.com > >> > >> > > Cc: i2rs@ietf.org; > >> > >> draft-ietf-i2rs-yang-l3-topology@ietf.org; > >> > >> > > > >> j.schoenwaelder@jacobs-university.de; > >> i2rs-chairs@ietf.org; > >> > >> > > > >> Kathleen.Moriarty.ietf@gmail.com; > >> iesg@ietf.org > >> > >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > > >> > >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> > >> > > >> I'm pulling your questions to the top of this email. > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Question 1: Ok. Just to make sure I understand this correctly > >> > > >> - > >> > >> > > >> these topology models are intended to be I2RS-specific, and > >> > > >> they > >> > >> > > >> cannot be used for any other purpose. If anyone needs a > >> > > >> general > >> > >> > > >> topology model outside of the I2RS protocol, they will have to > >> > >> > > >> design their own model. Is this correct? > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Response 1: Not really. > >> > >> > > > Ok, so are you saying that the models are in fact generic, and > >> > > > can > >> > >> > > > be used outside of I2RS? I.e., they *can* be used with the > >> > > > normal > >> > >> > > > configuration datastores? > >> > >> > > > > >> > >> > > > >> > >> > > From implementation experience, yes, they can be used for storing > >> > >> > > configuration. OpenDaylight uses (an ancient predecessor of) > >> > >> > > yang-network-topo to store configure details about devices in its > >> > >> > > managed networks. > >> > >> > > > >> > >> > > Regards, > >> > >> > > Robert > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > i2rs mailing list > >> > >> > i2rs@ietf.org > >> > >> > > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > > >> > > > > > > --001a114fab10e32a9d0546eb4f4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Coul= d one of you who are saying that a writable topology model can appear in th= e regular configuration data-store please explain:

How does validati= on at reboot work when there is dependency on learned topology data that is= n't yet available?

I'd prefer more technology discussion of = the nuances.=C2=A0 This one has been an active topic of discussion for at l= east 2 years, so I'm hopeful that you all have well thought out answers= .

Regards,
Alia

On Wed, Jan 25, 2017 at 7:27 AM, Lou Berger = <lberger@labn.net> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Sue,

In short, I'm g= oing to agree with Benoit - but for slightly different
reasons as I also co-chair TEAS, a group that is basi= ng some of its
work on I2RS devel= oped models.

As a WG chair, I ha= ve always viewed the models being developed by I2RS
as typical models that are generally useful, and being d= efined by I2RS
simply because the= y were ahead of other groups that might otherwise
define the models -- and I view this as a fine thing that = has benefit
for YANG users and ot= her WGs. As TEAS chair, this is what lead me to
modules vs their original= path of redefining parallel function.

As part of my view = of the I2RS models being generally applicable to uses
beyond I2RS together with I2RS choosing YANG for mode= ling ephemeral
data, I have alway= s expected that the I2RS WG would at some (perhaps as
part of the I2RS protocol definition) define how any = YANG model can be
used to support= I2RS. This view certainly lead me to conclude that
having the I2RS models move forward, just like any other= YANG model,
makes sense and woul= d benefit the other models and WGs that reference
this core work. This view also allows for the relationship= to the
revised-data store work, = as well as the specification of which data
store(s) I2RS uses, to be separately defined -- and to not gate
publication of these models. This = separate specification would be
t= he location for any I2RS-specific transport and security considers,
so such would not belong in the generall= y reusable models developed
by I2= RS.

Essentially, As NET= MOD co-chair, I concluded that the revised data
in a general YANG conte= xt and, therefore, the major open issue / gating
impediment to progressing I2RS models had been removed and = publication
of these models were = unblocked. This also motivated my comments in the
related discussions at the last meeting.

If my understanding= /view is correct, i.e., that the topology models are
just like any other YANG model, then I think publicat= ion can and
should proceed (with = the appropriate text for a typical YANG model). If
I misunderstood something, and the models produced by I2R= S are limited
to ephemeral repres= entations/data stores as well as specific YANG
transport protocols -- then as TEAS chair, I have to hit rese= t on the
TEAS topology work, and = as NETMOD chair I think the NETMOD WG needs to
discuss what it means for a YANG model to be protocol/datasto= re
specific and if any guidelines= or other new NTEMOD documents are need
to support such.
Less importantly, a= s I2RS participant, I'd also ask for the documents
to be sent back to the WG for a new last call once th= e documents
are updated to reflec= t their narrow scope -- as I bet I'm not the only
person who viewed this work applicable to non-ephemer= al uses.

I hope this helps.<= br>

<= /blockquote>Lou


On= January 24, 2017 11:56:32 AM "Susan Hares" <shares@ndzh.com> wrote:

&= gt; To: Martin:
>
> You have a reasonable request. If the NETMO= D WG Chairs confirm their
> decision to make I2RS Yang Modules part o= f the Control Plane Datastore then
> as shepherd/WG-chair I will reco= mmend these get added to the draft.
>
> Note to authors :
&g= t;
> As we wait for the NETMOD WG Chairs and Benoit to deliver the de= cision on
> Config/Control Plane datastore, the authors should work o= n:=C2=A0 Basic Yang
> security considerations and the other I2RS Yang= Module information.
>
> Sue Hares (Shepherd)
> -----Orig= inal Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday= , January 24, 2017 10:39 AM
> To: shares@ndzh.com
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-to= pology@ietf.org;
> j.schoenwaelder@jacobs-university.de<= /a>; i2rs-chairs@= ietf.org; nite@hq.sk;
> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net;
> kwatsen@juniper.net
> Subject:= Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs= -yang-l3-topology-08: (with COMMENT)
>
> "Susan Hares= " <shares@ndzh= .com> wrote:
>> Martin:
>>
>>
>>=
>> I'm sorry if misunderstood your comments regarding the
= >> draft-ietf-netmod-revised-datastores-00.txt.=C2=A0 The reason= the answer is
>> unclear is that it depends on the context of the= question.
>>
>>
>>
>> .=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0If you ask if the pre-standardization I2RS Yang Topolog= y models
>> (basic and L3)=C2=A0 implemented are part of the confi= guration data store,
>> the answer is yes - AFAIK.
>
>= This is not my question.
>
>> .=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0If you ask if the WG LC Topology models are approved to be part
&g= t; of
>> the configuration data store, my understanding was no.=C2= =A0 =C2=A0I2RS WG was to
>> abide by the decision of NETMOD WG on = which data store I2RS modules
>> were placed in.
>
> Y= es, this is my question.=C2=A0 And my concern is that even if your understa= nding
> is that they are not designed to be part of the configuration= datastores,
> this fact is not mentioned in the drafts.
>
&= gt;> If you are concerned the implementation varies from the standardize= d,
> please
>> express this to Benoit Claise.=C2=A0 =C2=A0Ba= sed on your comments on my email
> thread,
>> I will be brie= f in my answers today.
>
> This is not my concern.
>
&= gt;
> /martin
>
>
>
>>
>>
>= >
>> Sue
>>
>>
>>
>>
>= ;>
>> -----Original Message-----
>> From: Martin Bjork= lund [mailto:mbj@tail-f= .com]
>> Sent: Tuesday, January 24, 2017 7:35 AM
>> T= o: shares@ndzh.com=
>> Cc: i2rs@ie= tf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org;
>= > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org;
>> nite@hq.sk; Kathleen.Moriarty.i= etf@gmail.com; = iesg@ietf.org;
>> lberger@labn.net; kwatsen@juniper.net
>> Subject: Re: [i2rs] Kat= hleen Moriarty's No Objection on
>> draft-ietf-i2rs-yang-l3-to= pology-08: (with COMMENT)
>>
>>
>>
>&= gt; "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:
>>
>&= gt; > Martin:
>>
>> >
>>
>> > = Your statement "One problem is that relying on the solution in
>= >
>> > draft-ietf-netmod-revised-datastores-00 is a bit= premature - in
>> > fact,
>>
>> > that do= cument does not yet provide any details at all on the I2RS
>>
&= gt;> > ephemeral data store." This statement is not what I under= stood from
>> > IETF
>> 98 or the netmod
>>>> > ADs.=C2=A0 =C2=A0I guess your objection to this data model = falls into Benoit
> Claise
>>
>> > (AD) and the = NETMOD folks to answer.
>>
>>
>>
>> Why= do you think that I have any objection to
>> draft-ietf-netmod-re= vised-datastores-00.=C2=A0 Please re-read what I wrote.
>>>>
>>
>> My objection regards your statement:
&= gt;>
>>
>>
>>=C2=A0 =C2=A0 1) I2RS Data model= s do not utilize the configuration data store,
>>
>>
&= gt;>
>> If this is true it needs to be clarified in the documen= t.
>>
>>
>>
>> After all these emails b= ack and forth, it is still not clear whether
>> this statement is = true or not.
>>
>>
>>
>>
>>>> /martin
>>
>>
>>
>>
>&g= t;
>>
>>
>>
>>
>>
>><= br>>> >
>>
>> > Sue Hares
>>
>= > >
>>
>> > -----Original Message-----
>&g= t;
>> > From: i2rs [ <mailto:i2rs-bounces@ietf.org>
>> > = mailto:i2rs-boun= ces@ietf.org]
>> On Behalf Of Martin
>>
>> &= gt; Bjorklund
>>
>> > Sent: Monday, January 23, 2017 5= :26 PM
>>
>> > To:=C2=A0 <mailto:shares@ndzh.com> shares@ndzh.com
>>
>= ;> > Cc:=C2=A0 <mailto:i2rs@ietf.org> i2rs@ietf.org;
>> <mailto:draft-ietf-i2rs-yang-l<= wbr>3-topology@ietf.org>
>> draft-ietf-i2rs-yang-l3-top= ology@ietf.org;
>>
>> >=C2=A0 <mailto:j.sch= oenwaelder@jacobs-university.de>
>> j.schoenwaelder@jac= obs-university.de;=C2=A0 <mailto:i2rs-chairs@ietf.org>
>> i2rs-chairs@ietf.org;
>>
>> >=C2=A0 <mailto:nite@hq.sk> nite@hq.sk;
>> <mailto:Kathleen.Moriarty.ietf= @gmail.com>
>> Kathleen.Moriarty.ietf@gmail.com; <ma= ilto:iesg@ietf.org&g= t; iesg@ietf.org
= >>
>> > Subject: Re: [i2rs] Kathleen Moriarty's No Ob= jection on
>>
>> > draft-ietf-i2rs-yang-l3-topolo= gy-08: (with COMMENT)
>>
>> >
>>
>> = > "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:
>>
>= > > > Robert and Martin:
>>
>> > >
>= >
>> > > I agree with Robert that the current implementat= ions of the ODL
>>
>> > > topology models are handl= ed as part of the configuration data
>> > > store
>>= ;
>> > > with
>>
>> > ephemeral
>= >
>> > > state.=C2=A0 =C2=A0I will point out that these i= mplementation are pre-standards
>>
>> > > implement= ations of the I2RS YANG Data model.
>>
>> > >
&g= t;>
>> > > While standardizing the topology data models, = the I2RS WG have
>> > > been
>>
>> > &g= t; asked to align with the
>> > > draft-ietf-netmod-revised-= datastores-00.txt
>>
>> > > NETMOD WG document= .=C2=A0 This NETMOD WG document moves the I2RS
>>
>> >= > ephemeral data
>>
>> > store from
>>>> > > configuration data store to a Control Plane data store.= =C2=A0 =C2=A0If we follow
>>
>> > this
>>
= >> > > draft, the I2RS Topology models are part of the I2RS eph= emeral
>> > > data
>> store.
>>
>>= ; > > If you disagree with the placement of the Topology data models,=
>>
>> > > please indicate this to the NETMOD WG an= d to Benoit.=C2=A0 Could you
>>
>> > > propose a wa= y that you would see the ephemeral state working with
>>
>&g= t; > > the configuration data
>>
>> > store
&= gt;>
>> > > to the NETMOD WG?
>>
>> >= ; >
>>
>> > > Quite frankly, I feel a bit of whi= p-lash on this topic.=C2=A0 =C2=A0NETMOD WG
> asks
>>
>= ;> > for
>>
>> > > Control Plane Data store.= =C2=A0 You ask for configuration data store
>>
>> > &g= t; (which was the I2RS initial proposal).
>>
>> >
&= gt;>
>> > Not really; I ask for clarification.
>>>> >
>>
>> > > It is possible for either= one to work for I2RS
>>
>> > > Topology models - i= f the right details are taken care of.=C2=A0 =C2=A0How do we
>> ma= ke
>>
>> > > progress on choosing one method so we = can write the I2RS Topology
>>
>> > > Models securi= ty considerations.?
>>
>> >
>>
>> &g= t; One problem is that relying on the solution in
>>
>> &= gt; draft-ietf-netmod-revised-datastores-00 is a bit premature - in>> > fact,
>>
>> > that document does not ye= t provide any details at all on the I2RS
>>
>> > ephem= eral datastore.
>>
>> >
>>
>> > S= o I see two alternatives.=C2=A0 Either wait with these documents, or
>= ;>
>> > publish them with their datamodels as is (i.e., no n= ew additional
>>
>> > notes), for the existing protoco= ls and architecure.=C2=A0 This would
>> > allow
>>
= >> > them to be implemented just like any other YANG data model.= =C2=A0 This
>>
>> > would mean that the normal YANG se= curity considerations guidelines
>> > should
>> be fol= lowed.
>>
>> >
>>
>> >
>>= ;
>> >
>>
>> > /martin
>>
>= > >
>>
>> > >
>>
>> > &g= t; Sue
>>
>> > >
>>
>> > > = -----Original Message-----
>>
>> > > From: Robert V= arga [ <mailto:nite@hq.s= k> mailto:nite@hq.sk= ]
>>
>> > > Sent: Monday, January 23, 2017 4:11= PM
>>
>> > > To: Martin Bjorklund;=C2=A0 <mailt= o:shares@ndzh.com&= gt; shares@ndzh.com
>>
>> > > Cc:=C2=A0 <mailto:i2rs@ietf.org> i2rs@ietf.org;
>> <mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org>
>> dr= aft-ietf-i2rs-yang-l3-topology@ietf.org;
>>
>> &= gt; >=C2=A0 <mailto:j.schoenwaelder@jacobs-university.de><= br>>> j.schoenwaelder@jacobs-university.de;=C2=A0 <mailto= :i2rs-chairs@ietf= .org>
>> i2rs-chairs@ietf.org;
>>
>> > >=C2=A0 &= lt;mailto:Kathleen.Moriarty.ietf@gmail.com>
>> Kathleen.Moriarty= .ietf@gmail.com;=C2=A0 <mailto:iesg@ietf.org>
>> iesg@ietf.org
>>
>> >= > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>&g= t;
>> > > draft-ietf-i2rs-yang-l3-topology-08: (with CO= MMENT)
>>
>> > >
>>
>> > > = On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
>>
>> >= ; > >> I'm pulling your questions to the top of this email.>>
>> > > >>
>>
>> > > = >>
>>
>> > > >>
>>
>>= > > >> Question 1: Ok.=C2=A0 Just to make sure I understand th= is correctly
>> > > >> -
>>
>> > = > >> these topology models are intended to be I2RS-specific, and>> > > >> they
>>
>> > > >&g= t; cannot be used for any other purpose.=C2=A0 If anyone needs a
>>= ; > > >> general
>>
>> > > >> top= ology model outside of the I2RS protocol, they will have to
>>
= >> > > >> design their own model.=C2=A0 Is this correct?<= br>>>
>> > > >>
>>
>> > >= ; >>
>>
>> > > >>
>>
>&g= t; > > >> Response 1:=C2=A0 Not really.
>>
>>= > > > Ok, so are you saying that the models are in fact generic, = and
>> > > > can
>>
>> > > > b= e used outside of I2RS?=C2=A0 I.e., they *can* be used with the
>>= > > > normal
>>
>> > > > configuration= datastores?
>>
>> > > >
>>
>>= > >
>>
>> > > From implementation experience= , yes, they can be used for storing
>>
>> > > confi= guration. OpenDaylight uses (an ancient predecessor of)
>>
>= > > > yang-network-topo to store configure details about devices i= n its
>>
>> > > managed networks.
>>
&g= t;> > >
>>
>> > > Regards,
>>
= >> > > Robert
>>
>> > >
>>
= >> > >
>>
>> >
>>
>> >= ; _______________________________________________
>>
>&= gt; > i2rs mailing list
>>
>> >=C2=A0 <mailto:i2rs@ietf.org> i2rs@ietf.org
>>= ;
>> >=C2=A0 <https://www.ietf.org/mailman/= listinfo/i2rs>
>> https://www.ietf.or= g/mailman/listinfo/i2rs
>>
>> >
>>>
>


--001a114fab10e32a9d0546eb4f4a-- From nobody Wed Jan 25 06:03:17 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 BF31F1298C5; Wed, 25 Jan 2017 06:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 FdudTsHC8KJi; Wed, 25 Jan 2017 06:03:12 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 DD7B512989C; Wed, 25 Jan 2017 06:03:11 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id d140so42926044wmd.2; Wed, 25 Jan 2017 06:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ipIAoDqIhic2rTt33S7tmqiIKNnzYu+RFnk1Ncf5VVA=; b=h6E5JMoanX9NrzSGN8I213kFZnDqeSA7mbOjNSWChUhTykhzLr0kFfMMN7+HHSAPt0 QbxcUEchdYX6c2irfA2Lfy7AKYuh0sRyRL0r0TEdmJAPHNbxj6VpdVmsje70+G/IZB6D rQRE1XqiLo8Mi/a0sJPhvan52tABhTz9BgrCOnUl1DwqLwlmuEV55ecgh7rRU5OVb3U4 fRuzjD/HvkiRItstLRpAXODAXWHANamT6e2X/ObJiSYbhWqdwOUhbz9A4EYk9Z9XlOWN KYJcfozOGYF0zQPEMmlB1PNUNB0jGwRWcWmFh0/TjApgjcvw5btYt96FUURMuOQsYqko liRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ipIAoDqIhic2rTt33S7tmqiIKNnzYu+RFnk1Ncf5VVA=; b=s2ykyEnMY+2iiFoTdKNxTiUdgJMwZFnDivLMHCA9PcSTLDFa5/5pe3C4RgRSNbPpwi dsR8oo5yHOhPm6A81YRuRDyuIp4++BGnXEqDGrAyK4zl/NjBoaGWrzA136VKs31bCTdX I4nsGr5BrR6LawHIpwKl8zz69lJ49vjZnBs83Nde3PC8XXFIVjJ9kDq8e9oLCAG4qcNi plNBeSEhSU6rSXVyAzUFqi3902RkcvaD7KZKVG5etA9gQYWJwXOhqRoC+FccqfQQrXsQ FrKWa+uRsk17Wl4DX3NUl7RUYSMua/gBZIWD2upqqFJQ1PBAOYX0IjyVZnWZETTcmPCy zJrw== X-Gm-Message-State: AIkVDXJ5G96iAOXuVo9+EOYyJnRAUGwnRR2FkLhUzBRMquwjtYGm/1Z7R16amL+1Nm5JNw== X-Received: by 10.28.11.135 with SMTP id 129mr21961099wml.111.1485352990003; Wed, 25 Jan 2017 06:03:10 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id z134sm31474324wmc.20.2017.01.25.06.03.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 06:03:09 -0800 (PST) From: Giles Heron Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_07DE9BF6-5534-4367-B083-7F9EF2B6B4BB" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 25 Jan 2017 14:03:07 +0000 In-Reply-To: To: Alia Atlas References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 14:03:16 -0000 --Apple-Mail=_07DE9BF6-5534-4367-B083-7F9EF2B6B4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, > On 25 Jan 2017, at 13:35, Alia Atlas wrote: >=20 > Could one of you who are saying that a writable topology model can = appear in the regular configuration data-store please explain: >=20 > How does validation at reboot work when there is dependency on learned = topology data that isn't yet available? um - it can=E2=80=99t? (or I don=E2=80=99t think it can). But why = would you have a writeable topology depend on learned topology data? Or = am I totally misunderstanding your question? At any rate I=E2=80=99m only thinking of writeable topology in the = context of inventory (so stuff that is configured rather than learned = from a dynamic protocol) and perhaps intent (so, for example a = point-to-point circuit could be expressed in a =E2=80=9Cservice=E2=80=9D = model as a pair of nodes connected by a pair of unidirectional links = with bandwidth parameters etc. - which the network-facing OSS would = create by configuring a PWE between the two nodes). > I'd prefer more technology discussion of the nuances. This one has = been an active topic of discussion for at least 2 years, so I'm hopeful = that you all have well thought out answers. I=E2=80=99m afraid I=E2=80=99ve not followed I2RS closely enough. When = the WG was set up I hoped it would define an ephemeral data store, = define that YANG-modelled data could be carried over various = transports/encodings (and perhaps define a binary-encoded protocol over = an asynchronous transport as an example of such), and then shut itself = down. It has taken a very different path so to a great extent I have = disengaged (but remained subscribed to the list). I only got suck(er)ed = into this thread because Juergen mentioned ODL. I=E2=80=99m not saying that the discussions over traceability, priority, = security etc. are wrong but I see them as being largely orthogonal to = the issue of ephemeral vs persistent config and to the selection of = transport/protocol used to access the NE (just as I see the topology = models themselves as being general rather than I2RS-specific). Giles > Regards, > Alia >=20 > On Wed, Jan 25, 2017 at 7:27 AM, Lou Berger > wrote: >=20 > Sue, >=20 > In short, I'm going to agree with Benoit - but for slightly different > reasons as I also co-chair TEAS, a group that is basing some of its > work on I2RS developed models. >=20 > As a WG chair, I have always viewed the models being developed by I2RS > as typical models that are generally useful, and being defined by I2RS > simply because they were ahead of other groups that might otherwise > define the models -- and I view this as a fine thing that has benefit > for YANG users and other WGs. As TEAS chair, this is what lead me to > ensure that the models being defined in TEAS built on the I2RS YANG > modules vs their original path of redefining parallel function. >=20 > As part of my view of the I2RS models being generally applicable to = uses > beyond I2RS together with I2RS choosing YANG for modeling ephemeral > data, I have always expected that the I2RS WG would at some (perhaps = as > part of the I2RS protocol definition) define how any YANG model can be > used to support I2RS. This view certainly lead me to conclude that > having the I2RS models move forward, just like any other YANG model, > makes sense and would benefit the other models and WGs that reference > this core work. This view also allows for the relationship to the > revised-data store work, as well as the specification of which data > store(s) I2RS uses, to be separately defined -- and to not gate > publication of these models. This separate specification would be > the location for any I2RS-specific transport and security considers, > so such would not belong in the generally reusable models developed > by I2RS. >=20 > Essentially, As NETMOD co-chair, I concluded that the revised data > store work provided the direction on how ephemeral would be supported > in a general YANG context and, therefore, the major open issue / = gating > impediment to progressing I2RS models had been removed and publication > of these models were unblocked. This also motivated my comments in the > related discussions at the last meeting. >=20 > If my understanding/view is correct, i.e., that the topology models = are > just like any other YANG model, then I think publication can and > should proceed (with the appropriate text for a typical YANG model). = If > I misunderstood something, and the models produced by I2RS are limited > to ephemeral representations/data stores as well as specific YANG > transport protocols -- then as TEAS chair, I have to hit reset on the > TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to > discuss what it means for a YANG model to be protocol/datastore > specific and if any guidelines or other new NTEMOD documents are need > to support such. >=20 > Less importantly, as I2RS participant, I'd also ask for the documents > to be sent back to the WG for a new last call once the documents > are updated to reflect their narrow scope -- as I bet I'm not the only > person who viewed this work applicable to non-ephemeral uses. >=20 > I hope this helps. >=20 > Lou >=20 >=20 > On January 24, 2017 11:56:32 AM "Susan Hares" > wrote: >=20 > > To: Martin: > > > > You have a reasonable request. If the NETMOD WG Chairs confirm their > > decision to make I2RS Yang Modules part of the Control Plane = Datastore then > > as shepherd/WG-chair I will recommend these get added to the draft. > > > > Note to authors : > > > > As we wait for the NETMOD WG Chairs and Benoit to deliver the = decision on > > Config/Control Plane datastore, the authors should work on: Basic = Yang > > security considerations and the other I2RS Yang Module information. > > > > Sue Hares (Shepherd) > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com = ] > > Sent: Tuesday, January 24, 2017 10:39 AM > > To: shares@ndzh.com > > Cc: i2rs@ietf.org ; = draft-ietf-i2rs-yang-l3-topology@ietf.org = ; > > j.schoenwaelder@jacobs-university.de = ; i2rs-chairs@ietf.org = ; nite@hq.sk ; > > Kathleen.Moriarty.ietf@gmail.com = ; iesg@ietf.org = ; lberger@labn.net ; > > kwatsen@juniper.net > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" > wrote: > >> Martin: > >> > >> > >> > >> I'm sorry if misunderstood your comments regarding the > >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer = is > >> unclear is that it depends on the context of the question. > >> > >> > >> > >> . If you ask if the pre-standardization I2RS Yang Topology = models > >> (basic and L3) implemented are part of the configuration data = store, > >> the answer is yes - AFAIK. > > > > This is not my question. > > > >> . If you ask if the WG LC Topology models are approved to = be part > > of > >> the configuration data store, my understanding was no. I2RS WG = was to > >> abide by the decision of NETMOD WG on which data store I2RS modules > >> were placed in. > > > > Yes, this is my question. And my concern is that even if your = understanding > > is that they are not designed to be part of the configuration = datastores, > > this fact is not mentioned in the drafts. > > > >> If you are concerned the implementation varies from the = standardized, > > please > >> express this to Benoit Claise. Based on your comments on my email > > thread, > >> I will be brief in my answers today. > > > > This is not my concern. > > > > > > /martin > > > > > > > >> > >> > >> > >> Sue > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Martin Bjorklund [mailto:mbj@tail-f.com = ] > >> Sent: Tuesday, January 24, 2017 7:35 AM > >> To: shares@ndzh.com > >> Cc: i2rs@ietf.org ; = draft-ietf-i2rs-yang-l3-topology@ietf.org = ; > >> j.schoenwaelder@jacobs-university.de = ; i2rs-chairs@ietf.org = ; > >> nite@hq.sk ; Kathleen.Moriarty.ietf@gmail.com = ; iesg@ietf.org = ; > >> lberger@labn.net ; kwatsen@juniper.net = > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > >> > >> "Susan Hares" < > = shares@ndzh.com > wrote: > >> > >> > Martin: > >> > >> > > >> > >> > Your statement "One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral data store." This statement is not what I understood = from > >> > IETF > >> 98 or the netmod > >> > >> > ADs. I guess your objection to this data model falls into = Benoit > > Claise > >> > >> > (AD) and the NETMOD folks to answer. > >> > >> > >> > >> Why do you think that I have any objection to > >> draft-ietf-netmod-revised-datastores-00. Please re-read what I = wrote. > >> > >> > >> > >> My objection regards your statement: > >> > >> > >> > >> 1) I2RS Data models do not utilize the configuration data store, > >> > >> > >> > >> If this is true it needs to be clarified in the document. > >> > >> > >> > >> After all these emails back and forth, it is still not clear = whether > >> this statement is true or not. > >> > >> > >> > >> > >> > >> /martin > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > >> > Sue Hares > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: i2rs [ > > >> > mailto:i2rs-bounces@ietf.org ] > >> On Behalf Of Martin > >> > >> > Bjorklund > >> > >> > Sent: Monday, January 23, 2017 5:26 PM > >> > >> > To: > = shares@ndzh.com > >> > >> > Cc: > i2rs@ietf.org = ; > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; > >> > >> > > > >> j.schoenwaelder@jacobs-university.de = ; = > > >> i2rs-chairs@ietf.org ; > >> > >> > > nite@hq.sk = ; > >> > > >> Kathleen.Moriarty.ietf@gmail.com = ; > iesg@ietf.org > >> > >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > >> > >> > "Susan Hares" < > = shares@ndzh.com > wrote: > >> > >> > > Robert and Martin: > >> > >> > > > >> > >> > > I agree with Robert that the current implementations of the ODL > >> > >> > > topology models are handled as part of the configuration data > >> > > store > >> > >> > > with > >> > >> > ephemeral > >> > >> > > state. I will point out that these implementation are = pre-standards > >> > >> > > implementations of the I2RS YANG Data model. > >> > >> > > > >> > >> > > While standardizing the topology data models, the I2RS WG have > >> > > been > >> > >> > > asked to align with the > >> > > draft-ietf-netmod-revised-datastores-00.txt > >> > >> > > NETMOD WG document. This NETMOD WG document moves the I2RS > >> > >> > > ephemeral data > >> > >> > store from > >> > >> > > configuration data store to a Control Plane data store. If we = follow > >> > >> > this > >> > >> > > draft, the I2RS Topology models are part of the I2RS ephemeral > >> > > data > >> store. > >> > >> > > If you disagree with the placement of the Topology data models, > >> > >> > > please indicate this to the NETMOD WG and to Benoit. Could you > >> > >> > > propose a way that you would see the ephemeral state working = with > >> > >> > > the configuration data > >> > >> > store > >> > >> > > to the NETMOD WG? > >> > >> > > > >> > >> > > Quite frankly, I feel a bit of whip-lash on this topic. = NETMOD WG > > asks > >> > >> > for > >> > >> > > Control Plane Data store. You ask for configuration data store > >> > >> > > (which was the I2RS initial proposal). > >> > >> > > >> > >> > Not really; I ask for clarification. > >> > >> > > >> > >> > > It is possible for either one to work for I2RS > >> > >> > > Topology models - if the right details are taken care of. How = do we > >> make > >> > >> > > progress on choosing one method so we can write the I2RS = Topology > >> > >> > > Models security considerations.? > >> > >> > > >> > >> > One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral datastore. > >> > >> > > >> > >> > So I see two alternatives. Either wait with these documents, or > >> > >> > publish them with their datamodels as is (i.e., no new additional > >> > >> > notes), for the existing protocols and architecure. This would > >> > allow > >> > >> > them to be implemented just like any other YANG data model. This > >> > >> > would mean that the normal YANG security considerations = guidelines > >> > should > >> be followed. > >> > >> > > >> > >> > > >> > >> > > >> > >> > /martin > >> > >> > > >> > >> > > > >> > >> > > Sue > >> > >> > > > >> > >> > > -----Original Message----- > >> > >> > > From: Robert Varga [ > = mailto:nite@hq.sk ] > >> > >> > > Sent: Monday, January 23, 2017 4:11 PM > >> > >> > > To: Martin Bjorklund; > shares@ndzh.com > >> > >> > > Cc: > = i2rs@ietf.org ; > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org = ; > >> > >> > > > > >> j.schoenwaelder@jacobs-university.de = ; = > > >> i2rs-chairs@ietf.org ; > >> > >> > > > > >> Kathleen.Moriarty.ietf@gmail.com = ; > > >> iesg@ietf.org > >> > >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > > >> > >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> > >> > > >> I'm pulling your questions to the top of this email. > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Question 1: Ok. Just to make sure I understand this = correctly > >> > > >> - > >> > >> > > >> these topology models are intended to be I2RS-specific, and > >> > > >> they > >> > >> > > >> cannot be used for any other purpose. If anyone needs a > >> > > >> general > >> > >> > > >> topology model outside of the I2RS protocol, they will have = to > >> > >> > > >> design their own model. Is this correct? > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Response 1: Not really. > >> > >> > > > Ok, so are you saying that the models are in fact generic, = and > >> > > > can > >> > >> > > > be used outside of I2RS? I.e., they *can* be used with the > >> > > > normal > >> > >> > > > configuration datastores? > >> > >> > > > > >> > >> > > > >> > >> > > =46rom implementation experience, yes, they can be used for = storing > >> > >> > > configuration. OpenDaylight uses (an ancient predecessor of) > >> > >> > > yang-network-topo to store configure details about devices in = its > >> > >> > > managed networks. > >> > >> > > > >> > >> > > Regards, > >> > >> > > Robert > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > i2rs mailing list > >> > >> > > i2rs@ietf.org = > >> > >> > > > >> https://www.ietf.org/mailman/listinfo/i2rs = > >> > >> > > >> > > > > >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_07DE9BF6-5534-4367-B083-7F9EF2B6B4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alia,

On 25 Jan 2017, at 13:35, Alia = Atlas <akatlas@gmail.com> wrote:

Could = one of you who are saying that a writable topology model can appear in = the regular configuration data-store please explain:

How does validation at reboot work when there is dependency = on learned topology data that isn't yet available?

um - it can=E2=80=99t? (or I don=E2=80=99t think it = can).    But why would you have a writeable topology depend on = learned topology data?  Or am I totally misunderstanding your = question?

At any rate I=E2=80=99m = only thinking of writeable topology in the context of inventory (so = stuff that is configured rather than learned from a dynamic protocol) = and perhaps intent (so, for example a point-to-point circuit could be = expressed in a =E2=80=9Cservice=E2=80=9D model as a pair of nodes = connected by a pair of unidirectional links with bandwidth parameters = etc. - which the network-facing OSS would create by configuring a PWE = between the two nodes).

I'd prefer more = technology discussion of the nuances.  This one has been an active = topic of discussion for at least 2 years, so I'm hopeful that you all = have well thought out answers.

I=E2=80=99m afraid I=E2=80=99ve not followed I2RS = closely enough.  When the WG was set up I hoped it would define an = ephemeral data store, define that YANG-modelled data could be carried = over various transports/encodings (and perhaps define a binary-encoded = protocol over an asynchronous transport as an example of such), and then = shut itself down.   It has taken a very different path so to a = great extent I have disengaged (but remained subscribed to the list). =  I only got suck(er)ed into this thread because Juergen mentioned = ODL.

I=E2=80=99m not saying that the = discussions over traceability, priority, security etc. are wrong but I = see them as being largely orthogonal to the issue of ephemeral vs = persistent config and to the selection of transport/protocol used to = access the NE (just as I see the topology models themselves as being = general rather than I2RS-specific).

Giles

Regards,
Alia

On Wed, = Jan 25, 2017 at 7:27 AM, Lou Berger <lberger@labn.net> wrote:

Sue,

In = short, I'm going to agree with Benoit - but for slightly different
reasons = as I also co-chair TEAS, a group that is basing some of its
work = on I2RS developed models.

As a = WG chair, I have always viewed the models being developed by I2RS
as = typical models that are generally useful, and being defined by I2RS
simply = because they were ahead of other groups that might otherwise
define = the models -- and I view this as a fine thing that has benefit
for = YANG users and other WGs. As TEAS chair, this is what lead me to
ensure = that the models being defined in TEAS built on the I2RS YANG
modules = vs their original path of redefining parallel function.

As = part of my view of the I2RS models being generally applicable to uses
beyond = I2RS together with I2RS choosing YANG for modeling ephemeral
data, = I have always expected that the I2RS WG would at some (perhaps as
part = of the I2RS protocol definition) define how any YANG model can be
used = to support I2RS. This view certainly lead me to conclude that
having = the I2RS models move forward, just like any other YANG model,
makes = sense and would benefit the other models and WGs that reference
this = core work. This view also allows for the relationship to the
revised-= data store work, as well as the specification of which data
store(s)= I2RS uses, to be separately defined -- and to not gate
publicat= ion of these models. This separate specification would be
the = location for any I2RS-specific transport and security considers,
so = such would not belong in the generally reusable models developed
by = I2RS.

Essentia= lly, As NETMOD co-chair, I concluded that the revised data
store = work provided the direction on how ephemeral would be supported
in a = general YANG context and, therefore, the major open issue / gating
impedime= nt to progressing I2RS models had been removed and publication
of = these models were unblocked. This also motivated my comments in the
related = discussions at the last meeting.

If my = understanding/view is correct, i.e., that the topology models are
just = like any other YANG model, then I think publication can and
should = proceed (with the appropriate text for a typical YANG model). If
I = misunderstood something, and the models produced by I2RS are limited
to = ephemeral representations/data stores as well as specific YANG
transpor= t protocols -- then as TEAS chair, I have to hit reset on the
TEAS = topology work, and as NETMOD chair I think the NETMOD WG needs to
discuss = what it means for a YANG model to be protocol/datastore
specific= and if any guidelines or other new NTEMOD documents are need
to = support such.

Less = importantly, as I2RS participant, I'd also ask for the documents
to be = sent back to the WG for a new last call once the documents
are = updated to reflect their narrow scope -- as I bet I'm not the only
person = who viewed this work applicable to non-ephemeral uses.

I hope = this helps.

Lou


On January 24, 2017 11:56:32 AM "Susan Hares" = <shares@ndzh.com> wrote:

> To: Martin:
>
> You = have a reasonable request. If the NETMOD WG Chairs confirm their
> decision to make I2RS Yang Modules part of the Control = Plane Datastore then
> as shepherd/WG-chair I will = recommend these get added to the draft.
>
> Note to authors :
>
> = As we wait for the NETMOD WG Chairs and Benoit to deliver the decision = on
> Config/Control Plane datastore, the authors should = work on:  Basic Yang
> security considerations and = the other I2RS Yang Module information.
>
> Sue Hares (Shepherd)
> -----Original = Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday, January = 24, 2017 10:39 AM
> To: shares@ndzh.com
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org;
> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk;
> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net;
> kwatsen@juniper.net
> Subject: Re: = [i2rs] Kathleen Moriarty's No Objection on
> = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> "Susan Hares" <shares@ndzh.com> wrote:
>> = Martin:
>>
>>
>>
>> I'm sorry if misunderstood = your comments regarding the
>> = draft-ietf-netmod-revised-datastores-00.txt.  The = reason the answer is
>> unclear is that it depends = on the context of the question.
>>
>>
>>
>> = .         If you ask if the pre-standardization = I2RS Yang Topology models
>> (basic and L3)  = implemented are part of the configuration data store,
>> the answer is yes - AFAIK.
>
> This is not my question.
>
>> .         If you ask if the = WG LC Topology models are approved to be part
> of
>> the configuration data store, my understanding was = no.   I2RS WG was to
>> abide by the = decision of NETMOD WG on which data store I2RS modules
>> were placed in.
>
> = Yes, this is my question.  And my concern is that even if your = understanding
> is that they are not designed to be = part of the configuration datastores,
> this fact is = not mentioned in the drafts.
>
>> = If you are concerned the implementation varies from the standardized,
> please
>> express this to Benoit = Claise.   Based on your comments on my email
> = thread,
>> I will be brief in my answers today.
>
> This is not my concern.
>
>
> /martin
>
>
>
>>
>>
>>
>> Sue
>>
>>
>>
>>
>>
>> -----Original Message-----
>> = From: Martin Bjorklund [mailto:mbj@tail-f.com]
>> = Sent: Tuesday, January 24, 2017 7:35 AM
>> To: shares@ndzh.com
>> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org;
>> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org;
>> nite@hq.sk; = Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org;
>> lberger@labn.net; kwatsen@juniper.net
>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection = on
>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>>
>>
>> "Susan = Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:
>>
>> > Martin:
>>
>> >
>>
>> = > Your statement "One problem is that relying on the solution in
>>
>> > = draft-ietf-netmod-revised-datastores-00 is a bit = premature - in
>> > fact,
>>>> > that document does not yet provide any details = at all on the I2RS
>>
>> > = ephemeral data store." This statement is not what I understood from
>> > IETF
>> 98 or the netmod
>>
>> > ADs.   I guess = your objection to this data model falls into Benoit
> = Claise
>>
>> > (AD) and the = NETMOD folks to answer.
>>
>>
>>
>> Why do you think that I have = any objection to
>> = draft-ietf-netmod-revised-datastores-00.  Please = re-read what I wrote.
>>
>>
>>
>> My objection regards your = statement:
>>
>>
>>
>>    1) I2RS Data = models do not utilize the configuration data store,
>>
>>
>>
>> If this is true it needs to be clarified in the = document.
>>
>>
>>
>> After all these emails back = and forth, it is still not clear whether
>> this = statement is true or not.
>>
>>>>
>>
>>
>> /martin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >
>>
>> > Sue Hares
>>
>> >
>>
>> = > -----Original Message-----
>>
>> > From: i2rs [ <mailto:i2rs-bounces@ietf.org>
>> > = mailto:i2rs-bounces@ietf.org]
>> On Behalf = Of Martin
>>
>> > = Bjorklund
>>
>> > Sent: = Monday, January 23, 2017 5:26 PM
>>
>> > To:  <mailto:shares@ndzh.com> shares@ndzh.com
>>>> > Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;
>> = <mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org>
>> draft-ietf-i2rs-yang-l3-topology@ietf.org;
>>
>> = >  <mailto:j.schoenwaelder@jacobs-university.de>>> j.schoenwaelder@jacobs-university.de; = <mailto:i2rs-chairs@ietf.org>
>> i2rs-chairs@ietf.org;
>>
>> >  <mailto:nite@hq.sk> nite@hq.sk;>> <mailto:Kathleen.Moriarty.ietf@gmail.com>
>> Kathleen.Moriarty.ietf@gmail.com; <mailto:iesg@ietf.org> iesg@ietf.org
>>
>>= > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>>
>> > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>> >
>>
>> > "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:
>>
>> > > Robert and = Martin:
>>
>> > >
>>
>> > > I agree with Robert = that the current implementations of the ODL
>>
>> > > topology models are handled as part of the = configuration data
>> > > store
>>
>> > > with
>>
>> > ephemeral
>>
>> > > state.  =  I will point out that these implementation are pre-standards
>>
>> > > implementations of = the I2RS YANG Data model.
>>
>> = > >
>>
>> > > While = standardizing the topology data models, the I2RS WG have
>> > > been
>>
>> > > asked to align with the
>> > > draft-ietf-netmod-revised-datastores-00.txt
>>
>> = > > NETMOD WG document.  This NETMOD WG document moves the = I2RS
>>
>> > > ephemeral = data
>>
>> > store from
>>
>> > > configuration data = store to a Control Plane data store.   If we follow
>>
>> > this
>>
>> > > draft, the I2RS = Topology models are part of the I2RS ephemeral
>> = > > data
>> store.
>>
>> > > If you disagree with the placement of the = Topology data models,
>>
>> > = > please indicate this to the NETMOD WG and to Benoit.  Could = you
>>
>> > > propose a = way that you would see the ephemeral state working with
>>
>> > > the configuration = data
>>
>> > store
>>
>> > > to the NETMOD = WG?
>>
>> > >
>>
>> > > Quite frankly, I = feel a bit of whip-lash on this topic.   NETMOD WG
> asks
>>
>> > = for
>>
>> > > Control = Plane Data store.  You ask for configuration data store
>>
>> > > (which was the I2RS = initial proposal).
>>
>> >
>>
>> > Not really; I ask for = clarification.
>>
>> >
>>
>> > > It is possible for = either one to work for I2RS
>>
>> = > > Topology models - if the right details are taken care = of.   How do we
>> make
>>
>> > > progress on = choosing one method so we can write the I2RS Topology
>>
>> > > Models security = considerations.?
>>
>> >
>>
>> > One problem is that = relying on the solution in
>>
>> = > draft-ietf-netmod-revised-datastores-00 is a bit = premature - in
>> > fact,
>>>> > that document does not yet provide any details = at all on the I2RS
>>
>> > = ephemeral datastore.
>>
>> = >
>>
>> > So I see two = alternatives.  Either wait with these documents, or
>>
>> > publish them with their = datamodels as is (i.e., no new additional
>>
>> > notes), for the existing protocols and = architecure.  This would
>> > allow
>>
>> > them to be implemented = just like any other YANG data model.  This
>>
>> > would mean that the normal YANG security = considerations guidelines
>> > should
>> be followed.
>>
>> >
>>
>> = >
>>
>> >
>>
>> > /martin
>>
>> >
>>
>> > >
>>
>> > > Sue
>>
>> > >
>>
>> > > -----Original Message-----
>>
>> > > From: Robert Varga = [ <mailto:nite@hq.sk> mailto:nite@hq.sk]
>>
>> > > Sent: Monday, January 23, 2017 4:11 PM
>>
>> > > To: Martin = Bjorklund;  <mailto:shares@ndzh.com> shares@ndzh.com
>>
>> > > Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;
>> = <mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org>
>> draft-ietf-i2rs-yang-l3-topology@ietf.org;
>>
>> = > >  <mailto:j.schoenwaelder@jacobs-university.de>>> j.schoenwaelder@jacobs-university.de; = <mailto:i2rs-chairs@ietf.org>
>> i2rs-chairs@ietf.org;
>>
>> > >  <mailto:Kathleen.Moriarty.ietf@gmail.com>
>> Kathleen.Moriarty.ietf@gmail.com;  <mailto:iesg@ietf.org>
>> = iesg@ietf.org
>>
>>= > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>>
>> > > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>> > >
>>
>> > > On 01/23/2017 09:26 = PM, Martin Bjorklund wrote:
>>
>> = > > >> I'm pulling your questions to the top of this = email.
>>
>> > > = >>
>>
>> > > = >>
>>
>> > > = >>
>>
>> > > = >> Question 1: Ok.  Just to make sure I understand this = correctly
>> > > >> -
>>
>> > > >> these = topology models are intended to be I2RS-specific, and
>> > > >> they
>>
>> > > >> cannot be used for any other = purpose.  If anyone needs a
>> > > = >> general
>>
>> > > = >> topology model outside of the I2RS protocol, they will have = to
>>
>> > > >> = design their own model.  Is this correct?
>>
>> > > >>
>>
>> > > >>
>>
>> > > >>
>>
>> > > >> Response 1:  Not really.
>>
>> > > > Ok, so are you = saying that the models are in fact generic, and
>> = > > > can
>>
>> > = > > be used outside of I2RS?  I.e., they *can* be used with = the
>> > > > normal
>>>> > > > configuration datastores?
>>
>> > > >
>>
>> > >
>>
>> > > =46rom = implementation experience, yes, they can be used for storing
>>
>> > > configuration. = OpenDaylight uses (an ancient predecessor of)
>>
>> > > yang-network-topo to store configure = details about devices in its
>>
>>= > > managed networks.
>>
>>= > >
>>
>> > > = Regards,
>>
>> > > = Robert
>>
>> > >
>>
>> > >
>>
>> >
>>
>> > _______________________________________________
>>
>>= > i2rs mailing list
>>
>> = >  <mailto:i2rs@ietf.org> i2rs@ietf.org
>>
>> >  <https://www.ietf.org/mailman/listinfo/i2rs>
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> = >
>>
>
>


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

= --Apple-Mail=_07DE9BF6-5534-4367-B083-7F9EF2B6B4BB-- From nobody Wed Jan 25 06:09:09 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 93C48129963 for ; Wed, 25 Jan 2017 06:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 lZep5nxPI2Tk for ; Wed, 25 Jan 2017 06:09:05 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1EDBE12995B for ; Wed, 25 Jan 2017 06:09:05 -0800 (PST) Received: (qmail 24204 invoked by uid 0); 25 Jan 2017 14:09:02 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 25 Jan 2017 14:09:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ce8b1u0132SSUrH01e8eV5; Wed, 25 Jan 2017 07:08:38 -0700 X-Authority-Analysis: v=2.1 cv=JsBi8qIC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=wU2YTnxGAAAA:8 a=1sjgXBK7AAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=OUXY8nFuAAAA:8 a=szcjVd9AbkxzTTu0EuAA:9 a=KNv3TmyYm5Q97R_D:21 a=UOs-8jXeny_0dfIx:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=qowbMnUzjQcM5iyYROrS:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=cAcMbU7R10T-QSRYIcO_:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hkF6yaasoMFDtiQMPBkSuCIt7+63/scGEqObYEgo0kA=; b=YxDnMFUYCfzREVAlWEkFyuYpqc 0p8kOB32PveveOYb6UY2DoY9iWL7OfpMJDQo3ORxMi7XHbfc0rFvLcdrGM141v8svE4WyiQTeHZRF mQrBrOAdnDSQ6meXP5VtLez8p; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:46132 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cWOFX-0000lf-7N; Wed, 25 Jan 2017 07:08:35 -0700 To: Alia Atlas References: From: Lou Berger Message-ID: Date: Wed, 25 Jan 2017 09:08:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cWOFX-0000lf-7N X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:46132 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 14:09:07 -0000 Alia, On 1/25/2017 8:35 AM, Alia Atlas wrote: > Could one of you who are saying that a writable topology model can > appear in the regular configuration data-store please explain: > > How does validation at reboot work when there is dependency on learned > topology data that isn't yet available? > I'm not sure, but there are a bunch of implementations/implementers out there who can answer what they do. > I'd prefer more technology discussion of the nuances. > This one has been an active topic of discussion for at least 2 years, > so I'm hopeful that you all have well thought out answers. > During that time, the documents has never said anything about being limited to I2RS/ephemeral state. The word ephemeral didn't even show up in the documents (the base topology one at least) until after Seoul. I'd like to discuss this one the TEAS list to see what the folks depending on the model think of such a restriction and if it means a full reset on the work there or not... In the interest of limiting cross-posts I'll forward your mail there to start the discussion. Lou > Regards, > Alia > > On Wed, Jan 25, 2017 at 7:27 AM, Lou Berger >wrote: > > Sue, > > > In short, I'm going to agree with Benoit - but for slightly different > reasons as I also co-chair TEAS, a group that is basing some of its > work on I2RS developed models. > > > As a WG chair, I have always viewed the models being developed by I2RS > as typical models that are generally useful, and being defined by I2RS > simply because they were ahead of other groups that might otherwise > define the models -- and I view this as a fine thing that has benefit > for YANG users and other WGs. As TEAS chair, this is what lead me to > ensure that the models being defined in TEAS built on the I2RS YANG > modules vs their original path of redefining parallel function. > > > As part of my view of the I2RS models being generally applicable > to uses > beyond I2RS together with I2RS choosing YANG for modeling ephemeral > data, I have always expected that the I2RS WG would at some > (perhaps as > part of the I2RS protocol definition) define how any YANG model can be > used to support I2RS. This view certainly lead me to conclude that > having the I2RS models move forward, just like any other YANG model, > makes sense and would benefit the other models and WGs that reference > this core work. This view also allows for the relationship to the > revised-data store work, as well as the specification of which data > store(s) I2RS uses, to be separately defined -- and to not gate > publication of these models. This separate specification would be > the location for any I2RS-specific transport and security considers, > so such would not belong in the generally reusable models developed > by I2RS. > > > Essentially, As NETMOD co-chair, I concluded that the revised data > store work provided the direction on how ephemeral would be supported > in a general YANG context and, therefore, the major open issue / > gating > impediment to progressing I2RS models had been removed and publication > of these models were unblocked. This also motivated my comments in the > related discussions at the last meeting. > > > If my understanding/view is correct, i.e., that the topology > models are > just like any other YANG model, then I think publication can and > should proceed (with the appropriate text for a typical YANG > model). If > I misunderstood something, and the models produced by I2RS are limited > to ephemeral representations/data stores as well as specific YANG > transport protocols -- then as TEAS chair, I have to hit reset on the > TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to > discuss what it means for a YANG model to be protocol/datastore > specific and if any guidelines or other new NTEMOD documents are need > to support such. > > > Less importantly, as I2RS participant, I'd also ask for the documents > to be sent back to the WG for a new last call once the documents > are updated to reflect their narrow scope -- as I bet I'm not the only > person who viewed this work applicable to non-ephemeral uses. > > > I hope this helps. > > > Lou > > > On January 24, 2017 11:56:32 AM "Susan Hares" > wrote: > > > To: Martin: > > > > You have a reasonable request. If the NETMOD WG Chairs confirm their > > decision to make I2RS Yang Modules part of the Control Plane > Datastore then > > as shepherd/WG-chair I will recommend these get added to the draft. > > > > Note to authors : > > > > As we wait for the NETMOD WG Chairs and Benoit to deliver the > decision on > > Config/Control Plane datastore, the authors should work on: > Basic Yang > > security considerations and the other I2RS Yang Module information. > > > > Sue Hares (Shepherd) > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com > ] > > Sent: Tuesday, January 24, 2017 10:39 AM > > To: shares@ndzh.com > > Cc: i2rs@ietf.org ; > draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > > j.schoenwaelder@jacobs-university.de > ; > i2rs-chairs@ietf.org ; nite@hq.sk > ; > > Kathleen.Moriarty.ietf@gmail.com > ; iesg@ietf.org > ; lberger@labn.net ; > > kwatsen@juniper.net > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" > wrote: > >> Martin: > >> > >> > >> > >> I'm sorry if misunderstood your comments regarding the > >> draft-ietf-netmod-revised-datastores-00.txt. The reason the > answer is > >> unclear is that it depends on the context of the question. > >> > >> > >> > >> . If you ask if the pre-standardization I2RS Yang > Topology models > >> (basic and L3) implemented are part of the configuration data > store, > >> the answer is yes - AFAIK. > > > > This is not my question. > > > >> . If you ask if the WG LC Topology models are approved > to be part > > of > >> the configuration data store, my understanding was no. I2RS > WG was to > >> abide by the decision of NETMOD WG on which data store I2RS modules > >> were placed in. > > > > Yes, this is my question. And my concern is that even if your > understanding > > is that they are not designed to be part of the configuration > datastores, > > this fact is not mentioned in the drafts. > > > >> If you are concerned the implementation varies from the > standardized, > > please > >> express this to Benoit Claise. Based on your comments on my email > > thread, > >> I will be brief in my answers today. > > > > This is not my concern. > > > > > > /martin > > > > > > > >> > >> > >> > >> Sue > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Martin Bjorklund [mailto:mbj@tail-f.com > ] > >> Sent: Tuesday, January 24, 2017 7:35 AM > >> To: shares@ndzh.com > >> Cc: i2rs@ietf.org ; > draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > >> j.schoenwaelder@jacobs-university.de > ; > i2rs-chairs@ietf.org ; > >> nite@hq.sk ; > Kathleen.Moriarty.ietf@gmail.com > ; iesg@ietf.org > ; > >> lberger@labn.net ; kwatsen@juniper.net > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > >> > >> "Susan Hares" < > shares@ndzh.com > > wrote: > >> > >> > Martin: > >> > >> > > >> > >> > Your statement "One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral data store." This statement is not what I > understood from > >> > IETF > >> 98 or the netmod > >> > >> > ADs. I guess your objection to this data model falls into > Benoit > > Claise > >> > >> > (AD) and the NETMOD folks to answer. > >> > >> > >> > >> Why do you think that I have any objection to > >> draft-ietf-netmod-revised-datastores-00. Please re-read what I > wrote. > >> > >> > >> > >> My objection regards your statement: > >> > >> > >> > >> 1) I2RS Data models do not utilize the configuration data store, > >> > >> > >> > >> If this is true it needs to be clarified in the document. > >> > >> > >> > >> After all these emails back and forth, it is still not clear > whether > >> this statement is true or not. > >> > >> > >> > >> > >> > >> /martin > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > >> > Sue Hares > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: i2rs [ > > >> > mailto:i2rs-bounces@ietf.org ] > >> On Behalf Of Martin > >> > >> > Bjorklund > >> > >> > Sent: Monday, January 23, 2017 5:26 PM > >> > >> > To: > > shares@ndzh.com > >> > >> > Cc: > > i2rs@ietf.org ; > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > >> > >> > > > >> j.schoenwaelder@jacobs-university.de > ; > > > >> i2rs-chairs@ietf.org ; > >> > >> > > nite@hq.sk > ; > >> > > >> Kathleen.Moriarty.ietf@gmail.com > ; > iesg@ietf.org > >> > >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > >> > >> > "Susan Hares" < > shares@ndzh.com > > wrote: > >> > >> > > Robert and Martin: > >> > >> > > > >> > >> > > I agree with Robert that the current implementations of the ODL > >> > >> > > topology models are handled as part of the configuration data > >> > > store > >> > >> > > with > >> > >> > ephemeral > >> > >> > > state. I will point out that these implementation are > pre-standards > >> > >> > > implementations of the I2RS YANG Data model. > >> > >> > > > >> > >> > > While standardizing the topology data models, the I2RS WG have > >> > > been > >> > >> > > asked to align with the > >> > > draft-ietf-netmod-revised-datastores-00.txt > >> > >> > > NETMOD WG document. This NETMOD WG document moves the I2RS > >> > >> > > ephemeral data > >> > >> > store from > >> > >> > > configuration data store to a Control Plane data store. > If we follow > >> > >> > this > >> > >> > > draft, the I2RS Topology models are part of the I2RS ephemeral > >> > > data > >> store. > >> > >> > > If you disagree with the placement of the Topology data models, > >> > >> > > please indicate this to the NETMOD WG and to Benoit. Could you > >> > >> > > propose a way that you would see the ephemeral state > working with > >> > >> > > the configuration data > >> > >> > store > >> > >> > > to the NETMOD WG? > >> > >> > > > >> > >> > > Quite frankly, I feel a bit of whip-lash on this topic. > NETMOD WG > > asks > >> > >> > for > >> > >> > > Control Plane Data store. You ask for configuration data store > >> > >> > > (which was the I2RS initial proposal). > >> > >> > > >> > >> > Not really; I ask for clarification. > >> > >> > > >> > >> > > It is possible for either one to work for I2RS > >> > >> > > Topology models - if the right details are taken care of. > How do we > >> make > >> > >> > > progress on choosing one method so we can write the I2RS > Topology > >> > >> > > Models security considerations.? > >> > >> > > >> > >> > One problem is that relying on the solution in > >> > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > >> > fact, > >> > >> > that document does not yet provide any details at all on the I2RS > >> > >> > ephemeral datastore. > >> > >> > > >> > >> > So I see two alternatives. Either wait with these documents, or > >> > >> > publish them with their datamodels as is (i.e., no new additional > >> > >> > notes), for the existing protocols and architecure. This would > >> > allow > >> > >> > them to be implemented just like any other YANG data model. This > >> > >> > would mean that the normal YANG security considerations > guidelines > >> > should > >> be followed. > >> > >> > > >> > >> > > >> > >> > > >> > >> > /martin > >> > >> > > >> > >> > > > >> > >> > > Sue > >> > >> > > > >> > >> > > -----Original Message----- > >> > >> > > From: Robert Varga [ > mailto:nite@hq.sk ] > >> > >> > > Sent: Monday, January 23, 2017 4:11 PM > >> > >> > > To: Martin Bjorklund; > shares@ndzh.com > >> > >> > > Cc: > > i2rs@ietf.org ; > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > >> > >> > > > > >> j.schoenwaelder@jacobs-university.de > ; > > > >> i2rs-chairs@ietf.org ; > >> > >> > > > > >> Kathleen.Moriarty.ietf@gmail.com > ; > > >> iesg@ietf.org > >> > >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > >> > >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >> > >> > > > >> > >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > >> > >> > > >> I'm pulling your questions to the top of this email. > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Question 1: Ok. Just to make sure I understand this > correctly > >> > > >> - > >> > >> > > >> these topology models are intended to be I2RS-specific, and > >> > > >> they > >> > >> > > >> cannot be used for any other purpose. If anyone needs a > >> > > >> general > >> > >> > > >> topology model outside of the I2RS protocol, they will > have to > >> > >> > > >> design their own model. Is this correct? > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> Response 1: Not really. > >> > >> > > > Ok, so are you saying that the models are in fact > generic, and > >> > > > can > >> > >> > > > be used outside of I2RS? I.e., they *can* be used with the > >> > > > normal > >> > >> > > > configuration datastores? > >> > >> > > > > >> > >> > > > >> > >> > > From implementation experience, yes, they can be used for > storing > >> > >> > > configuration. OpenDaylight uses (an ancient predecessor of) > >> > >> > > yang-network-topo to store configure details about devices > in its > >> > >> > > managed networks. > >> > >> > > > >> > >> > > Regards, > >> > >> > > Robert > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > i2rs mailing list > >> > >> > > i2rs@ietf.org > > >> > >> > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > >> > > >> > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jan 25 06:52:26 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 C420212996E; Wed, 25 Jan 2017 06:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uplasIE-PtZF; Wed, 25 Jan 2017 06:52:16 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BC1129961; Wed, 25 Jan 2017 06:52:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5C8BF6FA; Wed, 25 Jan 2017 15:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Nhodm4f2gHqP; Wed, 25 Jan 2017 15:52:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 15:52:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 169F3200AB; Wed, 25 Jan 2017 15:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HR527YBvbroR; Wed, 25 Jan 2017 15:52:14 +0100 (CET) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D5AF200AC; Wed, 25 Jan 2017 15:52:14 +0100 (CET) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 2B3043E4BA0C; Wed, 25 Jan 2017 15:52:18 +0100 (CET) Date: Wed, 25 Jan 2017 15:52:17 +0100 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Alia Atlas , Lou Berger , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 14:52:19 -0000 On Wed, Jan 25, 2017 at 08:35:53AM -0500, Alia Atlas wrote: > Could one of you who are saying that a writable topology model can appear > in the regular configuration data-store please explain: > > How does validation at reboot work when there is dependency on learned > topology data that isn't yet available? A configuration datastore never has a dependency on state data. Validation is scoped by a datastore. A configuration datastore that is valid before a report is going to be valid after a reboot. These are core principles of how NETCONF and YANG work. For the larger picture how information flows from configuration datastores to the actual operational state, see the conceptual datastore discussions in NETMOD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 07:07:51 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 8684B129987; Wed, 25 Jan 2017 07:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBcRtIlvMMB6; Wed, 25 Jan 2017 07:07:48 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 044BD129847; Wed, 25 Jan 2017 07:07:48 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id f67so8995820ybc.2; Wed, 25 Jan 2017 07:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tQyho2Z/bZzSfnNM9JvY44HNktvrIDjlwCX5DI3/7pA=; b=kfgSfamMl7y1zCkRM2Xff1sAnBobn7gYfJzZfTa7EZb79F2v2CHyiC6RKo4Kw0072A 0fNMm5c3sQLSzq3XPpfaIPkICZ9w/FRsSlEK7B40V/4WlCQmqKDLgFHDaL9zbaH1Fci+ jux6L3LnnaEOSOI7m3HkJ3TEp3cgvb2AYIkV6leHzSwGkhWR9HhLXMFD7ctwOHVmZHkY FJE/YierZFtfCNkpCSgLRsgxaf6UeFe0xQ3Uvy2F5CF2xLLowIMDqaCG0DB3QcRK4FaC KKP8xEl5l7Z151eHHA514pgYxHgdLRb/YXwvZvk/lZkrHbP8Vx5teV9UiUUs8AKxDoxO 4M7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tQyho2Z/bZzSfnNM9JvY44HNktvrIDjlwCX5DI3/7pA=; b=ALID8tF9UBTTvQSHS8RDWB11mKIuwi6UWOWsBq+jqxtPpO0DM1WfRetku2trZFGBJQ Wog4oUY1DzDm9ebqPKVmyFmFRoPVYRpGMhxNjpdJFgQpX6Ly0y21DwLGVki60QynJaay 7AcKJ3Se23oRvXvOdxKujuNBWqdUR4vaXo+a8lZZq3qA7OVdQOCJomK3uJ0mrCEUaI98 dP6SuDi6BRkjd9XKy3NAFiTnPz8xSbq+W8Ufprxd8vQ9ORupk4JfJsFrHsc7WVGh0ydm 1/gy/apRcXKIxdN6S8L5/ek9wlK2ZRGGR2+A3KHGJlyGLLigy0akQWsadZ+PBsMZNNF6 UYNw== X-Gm-Message-State: AIkVDXJRIs+a14wEm52R8jtF41b01ysDapBlVGPZr3vtMKIsMWAd/MOmxCtg+E0PzgW1YQb/ZaT8gmIWVdryWw== X-Received: by 10.129.124.84 with SMTP id x81mr34557410ywc.224.1485356867101; Wed, 25 Jan 2017 07:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Wed, 25 Jan 2017 07:07:45 -0800 (PST) In-Reply-To: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> From: Alia Atlas Date: Wed, 25 Jan 2017 10:07:45 -0500 Message-ID: To: Juergen Schoenwaelder , Alia Atlas , Lou Berger , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a114941686de9200546ec98e8 Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 15:07:49 -0000 --001a114941686de9200546ec98e8 Content-Type: text/plain; charset=UTF-8 Juergen, On Wed, Jan 25, 2017 at 9:52 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jan 25, 2017 at 08:35:53AM -0500, Alia Atlas wrote: > > Could one of you who are saying that a writable topology model can appear > > in the regular configuration data-store please explain: > > > > How does validation at reboot work when there is dependency on learned > > topology data that isn't yet available? > > A configuration datastore never has a dependency on state data. > Validation is scoped by a datastore. A configuration datastore that is > valid before a report is going to be valid after a reboot. These are > core principles of how NETCONF and YANG work. > > For the larger picture how information flows from configuration > datastores to the actual operational state, see the conceptual > datastore discussions in NETMOD. Thank you for confirming my understanding. So - if one has models - such as a writable topology - where there can be dependencies on dynamic data, then those models can't be in the configuration data-store as currently defined. Regards, Alia > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114941686de9200546ec98e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

On Wed, Jan 25, 2017 at 9:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=
On Wed, Jan 25, 2017 at 08:= 35:53AM -0500, Alia Atlas wrote:
> Could one of you who are saying that a writable topology model can app= ear
> in the regular configuration data-store please explain:
>
> How does validation at reboot work when there is dependency on learned=
> topology data that isn't yet available?

A configuration datastore never has a dependency on state data.
Validation is scoped by a datastore. A configuration datastore that is
valid before a report is going to be valid after a reboot. These are
core principles of how NETCONF and YANG work.

For the larger picture how information flows from configuration
datastores to the actual operational state, see the conceptual
datastore discussions in NETMOD.

Thank you = for confirming my understanding.

So - if one has m= odels - such as a writable topology - where there can be
dependen= cies on dynamic data, then those models can't be in the configuration
data-store as currently defined.=C2=A0

Re= gards,
Alia
=C2=A0
= /js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a114941686de9200546ec98e8-- From nobody Wed Jan 25 07:18:08 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 6D2C2129991; Wed, 25 Jan 2017 07:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djdCkE-rIch0; Wed, 25 Jan 2017 07:18:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6258D129990; Wed, 25 Jan 2017 07:18:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 317327C0; Wed, 25 Jan 2017 16:17:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ei1xoF7X_xAl; Wed, 25 Jan 2017 16:17:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 16:17:59 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE1F3200AC; Wed, 25 Jan 2017 16:17:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1PdZXc4EpK0K; Wed, 25 Jan 2017 16:17:58 +0100 (CET) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9229200AB; Wed, 25 Jan 2017 16:17:58 +0100 (CET) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 8270C3E4BAF9; Wed, 25 Jan 2017 16:18:02 +0100 (CET) Date: Wed, 25 Jan 2017 16:18:02 +0100 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Alia Atlas , Lou Berger , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:18:01 -0000 On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > So - if one has models - such as a writable topology - where there > can be dependencies on dynamic data, then those models can't be in > the configuration data-store as currently defined. > Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 07:20:06 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 DB90F129990; Wed, 25 Jan 2017 07:20:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvK6foJ3mzCE; Wed, 25 Jan 2017 07:20:02 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 52CCA129985; Wed, 25 Jan 2017 07:20:02 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id r144so43242086wme.0; Wed, 25 Jan 2017 07:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PIE1Q5BdD2Q+pccYg3pRGVWGIKJJFwymv3Nv5Q+GnTk=; b=HsSavk26blU45KT4cYFSrJ7dP5EXgms5x6m5ywSx4N3YH+7NPCI/rrUbswQvHfVcN+ bSuRwkUuoXXgDwHsqw0vkT8i+kYlEEAifoeRpSOcfZO6eanLPj9dBtbLx+iinqfynkEb wlbqVCMRCVFKD+iVG05ZY79ru8EZKuAW1/hflHSQn6GLzVucW57tE0ffPvJ3zOvWF6DD TFz0BkuDXdcb4+xmzGs8Xnpf2mIC61frpv1zp7q3NB9ZB7KXty+sV658dZvqoxG8fkNC ThvQvpHR1DDz7mcnWlL8ITKD0+SB98FF13XRIwOEou9/M9yeqVP17NP4h5VqzYyWXW1t XxKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PIE1Q5BdD2Q+pccYg3pRGVWGIKJJFwymv3Nv5Q+GnTk=; b=Ek3o8kB3KJeVcHshHMstpzQFm5k5Yd6qr81stO/AAyQYTigLvrVqA/EDUxMpzDtem2 BeRV3seP8bQaSRzzRbznc5zT8l01L05pjS7SukOgNsWTMASoCogNT2y3hTpw4Q+aZGfw JJKfwMVMj5SIXV3Kn41zUAIrW1B/gKW3sI3u0dXQW5IyqWxzosMtbBu/MDR830CG06Sq fWeZN2TcW/O+qYQAmOO/oV6K97mIzklU9fga7Vsf6E2T58BOscoxSplOat0l+FAVUIC/ tX/hQwNkl9QzDoUqSWcLuk+7Ya0X4wG2DcqvqRQmeSjWrfOqltIkS9S3gnYsTxA2qu9L fspg== X-Gm-Message-State: AIkVDXLVJs6KWb1o8cg5rB9oV6nFuN5HAdiaZnIsfH2Vjr/7BtrPmlua5iQHPmmhPG43MQ== X-Received: by 10.28.209.202 with SMTP id i193mr25816859wmg.20.1485357600747; Wed, 25 Jan 2017 07:20:00 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id d29sm1209161wmi.19.2017.01.25.07.19.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 07:20:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> Date: Wed, 25 Jan 2017 15:19:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" , Alia Atlas Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 15:20:04 -0000 > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: >>=20 >> So - if one has models - such as a writable topology - where there >> can be dependencies on dynamic data, then those models can't be in >> the configuration data-store as currently defined. >>=20 >=20 > Yes but isn=E2=80=99t this confusing models and implementation? if you have a case where you have a dependency on dynamic data then you = can=E2=80=99t put that instantiation of the model in the configuration = data-store. but if your implementation never depends on dynamic data then it ought = to be fine. or again am I missing something obvious? more to the point. Alia - what=E2=80=99s the dependency on dynamic data = that you=E2=80=99re concerned about? Giles > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jan 25 07:33:30 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 67663129999; Wed, 25 Jan 2017 07:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSvBGv0bw__o; Wed, 25 Jan 2017 07:33:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099A512997D; Wed, 25 Jan 2017 07:33:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CC38F798; Wed, 25 Jan 2017 16:33:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P1mf0OCtJHmp; Wed, 25 Jan 2017 16:33:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 16:33:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 786A7200AC; Wed, 25 Jan 2017 16:33:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Dw16Y5UOEoMh; Wed, 25 Jan 2017 16:33:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28022200AB; Wed, 25 Jan 2017 16:33:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4F2AD3E4BBF4; Wed, 25 Jan 2017 16:33:28 +0100 (CET) Date: Wed, 25 Jan 2017 16:33:27 +0100 From: Juergen Schoenwaelder To: Giles Heron Message-ID: <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Giles Heron , Alia Atlas , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , Lou Berger , "iesg@ietf.org" , Alia Atlas Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:33:28 -0000 On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder wrote: > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > >> > >> So - if one has models - such as a writable topology - where there > >> can be dependencies on dynamic data, then those models can't be in > >> the configuration data-store as currently defined. > >> > > > > Yes > > but isn’t this confusing models and implementation? I just confirmed that the old datastore model does not support writable ephemeral datastores. No more no less. And there is work in NETMOD (and NETCONF) to revise the datastore model and to make data model reuse in different datastores even simpler. > if you have a case where you have a dependency on dynamic data then you can’t put that instantiation of the model in the configuration data-store. > > but if your implementation never depends on dynamic data then it ought to be fine. Yes. This should be fine. And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 09:34: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 13CFD129AA7; Wed, 25 Jan 2017 09:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 zIworTECDbmO; Wed, 25 Jan 2017 09:34:23 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76993129A8E; Wed, 25 Jan 2017 09:34:22 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Lou Berger'" References: <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> <20170124.163910.1660442168342299903.mbj@tail-f.com> <000d01d27662$0216d8d0$06448a70$@ndzh.com> <8fca02ad-b589-a77e-0ed9-c12796dc47c3@labn.net> In-Reply-To: <8fca02ad-b589-a77e-0ed9-c12796dc47c3@labn.net> Date: Wed, 25 Jan 2017 12:29:11 -0500 Message-ID: <018d01d27730$8b4b7740$a1e265c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018E_01D27706.A27E48E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9A1SNU/Tx/H65OFF6mQFqXkq7xgKK1DFGAq3LlN8CJ7hLsgF7GDVDAcTy6cGhHxYtEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 17:34:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018E_01D27706.A27E48E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lou: I am happy to receive your email as it demonstrates misconceptions about what I stated. The original topic of this thread was the security considerations section regarding an I2RS Topology model. Due to my respect for you, I am going to provide you a technical response on list. I have labeled my responses to respond to your points. I have responded on l but I will not follow-up on this thread. I encourage you to contact me directly via phone or email. Cheerily, Sue ----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, January 25, 2017 7:27 AM To: Susan Hares Cc: 'Martin Bjorklund'; i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; kwatsen@juniper.net Subject: RE: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Sue, In short, I'm going to agree with Benoit - but for slightly different reasons as I also co-chair TEAS, a group that is basing some of its work on I2RS developed models. >Lou 1: As a WG chair, I have always viewed the models being developed by I2RS as typical models that are generally useful, and being defined by I2RS simply because they were ahead of other groups that might otherwise define the >models -- and I view this as a fine thing that has benefit for YANG users and other WGs. As TEAS chair, this is what lead me to ensure that the models being defined in TEAS built on the I2RS YANG modules vs their original path of redefining >parallel function. Sue 1: I am pleased that TEAS WG and other WG find the Topology models useful. The topology model design encompasses ephemeral state and security for ephemeral state. It was built to be a platform for topology models, and to had early experimentation in the ODL models. Perhaps you missed the email on this thread where an insightful Martin asked "Does this mean I2RS models cannot be used by Topology models in other WGs?" I responded "not really" and more specifically " Most of the topology models I have seen abide by the concepts found in the I2RS topology model." Please see the mail at: https://www.ietf.org/mail-archive/web/i2rs/current/msg04231.html. The Topology models really operate best in an ephemeral state environment. Ephemeral state is not a I2RS-only functionality. Starting 4 years ago with discussions with NETCONF/NETMOD at the NYC interim, It was indicated that ephemeral state would be used by other WGs. One of these key uses is the use for Topology models. Topology model's ephemeral state allow operational state learned from the routing system to be altered with writes from the I2RS Client. (Please note the security considerations occur once read sensitive information or write sensitive information). This mixture of state does not really match the definition of the o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. Let's look at how this applies to the draft-ietf-teas-yang-te-topo-06.txt in section 3.1: " TE topology is a traffic engineering representation of one or more layers of network topologies. TE topology is comprised of TE nodes (TE graph vertices) interconnected via TE links (TE graph edges). A TE topology is mapped to a TE graph." TE topology model defines: underlay TE topology, overlay TE topology, and Abstract TE topology. The model in draft-ietf-teas-yang-te-topo-06.txt (ietf-te-topology) is technology agnostic blending learned topology (underlay TE topology) and configured topology to create an abstract TE topology. This is a wonderful use of the I2RS Topology model. Let's look what additional security is needed for Topology Models in Ephemeral state: Transport: Ephemeral state with topology models has security risks which include topology information may be sensitive or allow DoS attacks. Based on this point, the I2RS WG spent time looking at what protocol security and environment security is needed. To protect this information, I2RS WG decide the NETCONF/RESTCONF must run over a transport that provide mutual authentication, data confidentiality, data integrity and practical replay protections which had structure to limit DoS attacks. Mutual authentication requires a key management system and the definition of what an I2RS identifier is. The security environment would need policy that determine the interaction with other data stores, control plane protocols, and dynamic configuration protocols. These are additions to the basic yang security considerations (sensitive/privacy read nodes, sensitive/privacy in write nodes, or sensitive/privacy in rpc commands). I2RS allowed the security association to exist without transport connections, or to have multiple transport connections. This mechanism provide better bandwidth for accessing topology models. AFAIK - the NETCONF over SSH does not provide this level of security but NETCONF over TLS with X.509v3 does and RESTCONF do. If I NETCONF over SSH (RFC4722) does provide this level of security, then please let me know. Any data store must solve the problem of multiple clients writing a data node. I2RS decided multiple I2RS clients might want to write the topology in the I2RS Agent, but defined the simultaneous write as an error (with priority system as resolution). This write contention is an alternative to the configuration data store lock or the RESTCONF lock for a single actions. I2RS felt the speed choices on priority (similar to BGP choices) were better for ephemeral state. If the priority system is used, then one priority must be assigned per user identifier. If TEAS or NETMOD wants to define another mechanism, then this is a change from the I2RS protocol/ephemeral store definitions. It would be wonderful to have a discussion of this in NETMOD since the ephemeral state requirement require it. It would be nice to have one multiple-write mechanism for a generalize ephemeral state. I2RS felt tracing, better notification and pub/sub was necessary for I2RS. TEAS can refuse to import the trace, better notification or pub/sub work. >Lou 2: As part of my view of the I2RS models being generally applicable to uses beyond I2RS together with I2RS choosing YANG for modeling ephemeral data, I have always expected that the I2RS WG would at some (perhaps as part of >the I2RS protocol definition) define how any YANG model can be used to support I2RS. This view certainly lead me to conclude that having the I2RS models move forward, just like any other YANG model, makes sense and would benefit the > other models and WGs that reference this core work. This view also allows for the relationship to the revised-data store work, as well as the specification of which data > store(s) I2RS uses, to be separately defined -- and to not gate publication of these models. This separate specification would be the location for any I2RS-specific transport and security considers, so such would not belong in the > generally reusable models developed by I2RS. >Essentially, As NETMOD co-chair, I concluded that the revised data store work provided the direction on how ephemeral would be supported in a general YANG context and, therefore, the major open issue / gating impediment to >progressing I2RS models had been removed and publication of these models were unblocked. This also motivated my comments in the related discussions at the last meeting. Sue 2: Is the direction for the ephemeral state concepts agreed upon? The real test is if we are able to define ephemeral state within the control plane data store. You and I both thought that the adoption of draft-ietf-netmod-ietf-revised-datastores-00.txt completed this work on getting ephemeral data store concepts completed. You, I, Alia, Benoit thought progressing these key models based on these concepts of ephemeral state in this document seemed reasonable. However, this discussion seems to be stuck on what is ephemeral state and why is it different. If so, NETMOD does not have a clear ephemeral data store definition. Let's try 2 tests: a) did we get stuck on the security considerations section? (yes), b) Is there general agreement and a proposal for Yang modifications for ephemeral state? (no) Draft-ietf-netmod-ietf-revised-datastores-00.txt suggest the Control Plane Data stores but there has been confusion on this being an ephemeral data store with config=true nodes and operational state. There document suggests a ", but does not suggest a "write-data datastore> command for ephemeral data store. Perhaps based on the feedback from Juergen and Martin, means we need to create: a) an I2RS ephemeral Control Plane data store description, and b) create a document or a section in these documents on the assumptions of data stores. At the very least we should add to this document what Martin's suggests in the email at: https://www.ietf.org/mail-archive/web/i2rs/current/msg04234.html Which states: "Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly work-in-progress, and (2) none of the topology drafts reference draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a solution in that draft, it is not very clear to the reader". The draft-hares-i2rs-yang-sec-consider-00 suggests security considerations need to indicate: mandatory transport, 4 features of the ephemeral data store defined by I2RS, and whether any portion of the YANG model can move over insecure transport. Since these 4 features of I2RS ephemeral data store set by the I2RS ephemeral state requirements (draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed to in draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not completed Lou 3: If my understanding/view is correct, i.e., that the topology models are just like any other YANG model, then I think publication can and should proceed (with the appropriate text for a typical YANG model). Sue 3: I hope that my explanation above indicates that the I2RS Topology models are ephemeral models built for Topologies like TEAS. It is the very qualities you see in topology models that cause them to be ephemeral in order to mix the operational state with configuration state in a way that the configuration data store cannot. If we have a solid definition of Ephemeral data stores and Ephemeral Data models, then these data models are like any other ephemeral YANG model. Any ephemeral model must choose a multiple client-write design. It would be lovely to have a single ephemeral data store design. Lou 4: If I misunderstood something, and the models produced by I2RS are limited to ephemeral representations/data stores as well as specific YANG transport protocols -- then as TEAS chair, I have to hit reset on the TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to discuss what it means for a YANG model to be protocol/datastore specific and if any guidelines or other new NTEMOD documents are need to support such. Sue 4: Perhaps the TEAS WG Chair needs to discuss with the NETMOD WG Chair about completing the Ephemeral data store work before coming to a conclusion. Lou 5: Less importantly, as I2RS participant, I'd also ask for the documents to be sent back to the WG for a new last call once the documents are updated to reflect their narrow scope -- as I bet I'm not the only person who viewed this work applicable to non-ephemeral uses. Sue 5: As an I2RS Chair, I am not sure you have correctly defined the narrow scope of the I2RS work or these documents. Of course, after we complete the revisions of these documents if the ADs (Alia and Benoit) deem these need to go back to the WG for another WG LC, then we will send the drafts for another WG LC. Right now, the only thing that the drafts have firmly to revise is the Yang Security considerations define by https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines The rest of this list discussion is simply a discussion of IESG members and people who did not participate in the WG LC or the IETF LC regarding a proposal for addition security considerations. As Shepherd, Kathleen's questions about security consideration found missing piece and I wrote a discussion document. Unfortunately, the discussion has not examined the document (draft-hares-i2rs-yang-sec-consider) or the open issues in ephemeral stsate. Lou 6: I hope this helps. Sue 6: Was it meant to be helpful? I really, really hope you are engaging in a technical discussion about ephemeral state and how we can move forward. Two comments: . "then as a TEAS chair, I have to hit rest on the TEAS topology work" or as a . "I2RS participant, I'd also ask for the document to be sent to the WG for a new last call once the documents are updated" seem to be making conclusions without discussion. Cheerily, Sue On January 24, 2017 11:56:32 AM "Susan Hares" < shares@ndzh.com> wrote: > To: Martin: > > You have a reasonable request. If the NETMOD WG Chairs confirm their > decision to make I2RS Yang Modules part of the Control Plane Datastore > then as shepherd/WG-chair I will recommend these get added to the draft. > > Note to authors : > > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision > on Config/Control Plane datastore, the authors should work on: Basic > Yang security considerations and the other I2RS Yang Module information. > > Sue Hares (Shepherd) > -----Original Message----- > From: Martin Bjorklund [ mailto:mbj@tail-f.com] > Sent: Tuesday, January 24, 2017 10:39 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > lberger@labn.net; kwatsen@juniper.net > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" < shares@ndzh.com> wrote: >> Martin: >> >> >> >> I'm sorry if misunderstood your comments regarding the >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer >> is unclear is that it depends on the context of the question. >> >> >> >> . If you ask if the pre-standardization I2RS Yang Topology models >> (basic and L3) implemented are part of the configuration data store, >> the answer is yes - AFAIK. > > This is not my question. > >> . If you ask if the WG LC Topology models are approved to be part > of >> the configuration data store, my understanding was no. I2RS WG was to >> abide by the decision of NETMOD WG on which data store I2RS modules >> were placed in. > > Yes, this is my question. And my concern is that even if your > understanding is that they are not designed to be part of the > configuration datastores, this fact is not mentioned in the drafts. > >> If you are concerned the implementation varies from the standardized, > please >> express this to Benoit Claise. Based on your comments on my email > thread, >> I will be brief in my answers today. > > This is not my concern. > > > /martin > > > >> >> >> >> Sue >> >> >> >> >> >> -----Original Message----- >> From: Martin Bjorklund [ mailto:mbj@tail-f.com] >> Sent: Tuesday, January 24, 2017 7:35 AM >> To: shares@ndzh.com >> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; >> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; >> nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; >> lberger@labn.net; kwatsen@juniper.net >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> >> >> "Susan Hares" < < mailto:shares@ndzh.com> shares@ndzh.com> wrote: >> >> > Martin: >> >> > >> >> > Your statement "One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral data store." This statement is not what I understood from >> > IETF >> 98 or the netmod >> >> > ADs. I guess your objection to this data model falls into Benoit > Claise >> >> > (AD) and the NETMOD folks to answer. >> >> >> >> Why do you think that I have any objection to >> draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. >> >> >> >> My objection regards your statement: >> >> >> >> 1) I2RS Data models do not utilize the configuration data store, >> >> >> >> If this is true it needs to be clarified in the document. >> >> >> >> After all these emails back and forth, it is still not clear whether >> this statement is true or not. >> >> >> >> >> >> /martin >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > Sue Hares >> >> > >> >> > -----Original Message----- >> >> > From: i2rs [ < mailto:i2rs-bounces@ietf.org> >> > mailto:i2rs-bounces@ietf.org] >> On Behalf Of Martin >> >> > Bjorklund >> >> > Sent: Monday, January 23, 2017 5:26 PM >> >> > To: < mailto:shares@ndzh.com> shares@ndzh.com >> >> > Cc: < mailto:i2rs@ietf.org> i2rs@ietf.org; >> < mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> >> draft-ietf-i2rs-yang-l3-topology@ietf.org; >> >> > < mailto:j.schoenwaelder@jacobs-university.de> >> j.schoenwaelder@jacobs-university.de; < mailto:i2rs-chairs@ietf.org> >> i2rs-chairs@ietf.org; >> >> > < mailto:nite@hq.sk> nite@hq.sk; >> < mailto:Kathleen.Moriarty.ietf@gmail.com> >> Kathleen.Moriarty.ietf@gmail.com; < mailto:iesg@ietf.org> >> iesg@ietf.org >> >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> > >> >> > "Susan Hares" < < mailto:shares@ndzh.com> shares@ndzh.com> wrote: >> >> > > Robert and Martin: >> >> > > >> >> > > I agree with Robert that the current implementations of the ODL >> >> > > topology models are handled as part of the configuration data >> > > store >> >> > > with >> >> > ephemeral >> >> > > state. I will point out that these implementation are pre-standards >> >> > > implementations of the I2RS YANG Data model. >> >> > > >> >> > > While standardizing the topology data models, the I2RS WG have >> > > been >> >> > > asked to align with the >> > > draft-ietf-netmod-revised-datastores-00.txt >> >> > > NETMOD WG document. This NETMOD WG document moves the I2RS >> >> > > ephemeral data >> >> > store from >> >> > > configuration data store to a Control Plane data store. If we follow >> >> > this >> >> > > draft, the I2RS Topology models are part of the I2RS ephemeral >> > > data >> store. >> >> > > If you disagree with the placement of the Topology data models, >> >> > > please indicate this to the NETMOD WG and to Benoit. Could you >> >> > > propose a way that you would see the ephemeral state working with >> >> > > the configuration data >> >> > store >> >> > > to the NETMOD WG? >> >> > > >> >> > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG > asks >> >> > for >> >> > > Control Plane Data store. You ask for configuration data store >> >> > > (which was the I2RS initial proposal). >> >> > >> >> > Not really; I ask for clarification. >> >> > >> >> > > It is possible for either one to work for I2RS >> >> > > Topology models - if the right details are taken care of. How do we >> make >> >> > > progress on choosing one method so we can write the I2RS Topology >> >> > > Models security considerations.? >> >> > >> >> > One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral datastore. >> >> > >> >> > So I see two alternatives. Either wait with these documents, or >> >> > publish them with their datamodels as is (i.e., no new additional >> >> > notes), for the existing protocols and architecure. This would >> > allow >> >> > them to be implemented just like any other YANG data model. This >> >> > would mean that the normal YANG security considerations guidelines >> > should >> be followed. >> >> > >> >> > >> >> > >> >> > /martin >> >> > >> >> > > >> >> > > Sue >> >> > > >> >> > > -----Original Message----- >> >> > > From: Robert Varga [ < mailto:nite@hq.sk> mailto:nite@hq.sk] >> >> > > Sent: Monday, January 23, 2017 4:11 PM >> >> > > To: Martin Bjorklund; < mailto:shares@ndzh.com> shares@ndzh.com >> >> > > Cc: < mailto:i2rs@ietf.org> i2rs@ietf.org; >> < mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org> >> draft-ietf-i2rs-yang-l3-topology@ietf.org; >> >> > > < mailto:j.schoenwaelder@jacobs-university.de> >> j.schoenwaelder@jacobs-university.de; < mailto:i2rs-chairs@ietf.org> >> i2rs-chairs@ietf.org; >> >> > > < mailto:Kathleen.Moriarty.ietf@gmail.com> >> Kathleen.Moriarty.ietf@gmail.com; < mailto:iesg@ietf.org> >> iesg@ietf.org >> >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> > > >> >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >> >> > > >> I'm pulling your questions to the top of this email. >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Question 1: Ok. Just to make sure I understand this correctly >> > > >> - >> >> > > >> these topology models are intended to be I2RS-specific, and >> > > >> they >> >> > > >> cannot be used for any other purpose. If anyone needs a >> > > >> general >> >> > > >> topology model outside of the I2RS protocol, they will have to >> >> > > >> design their own model. Is this correct? >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Response 1: Not really. >> >> > > > Ok, so are you saying that the models are in fact generic, and >> > > > can >> >> > > > be used outside of I2RS? I.e., they *can* be used with the >> > > > normal >> >> > > > configuration datastores? >> >> > > > >> >> > > >> >> > > From implementation experience, yes, they can be used for storing >> >> > > configuration. OpenDaylight uses (an ancient predecessor of) >> >> > > yang-network-topo to store configure details about devices in its >> >> > > managed networks. >> >> > > >> >> > > Regards, >> >> > > Robert >> >> > > >> >> > > >> >> > >> >> > _______________________________________________ >> >> > i2rs mailing list >> >> > < mailto:i2rs@ietf.org> i2rs@ietf.org >> >> > < https://www.ietf.org/mailman/listinfo/i2rs> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > >> > > ------=_NextPart_000_018E_01D27706.A27E48E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lou: =

 

I am happy to receive your email as it demonstrates = misconceptions about what I stated.   The original topic of = this thread was the security considerations section regarding an I2RS = Topology model.  Due to my respect for you, I am going to provide = you a technical response on list.   I have labeled my = responses to respond to your points.  I have responded on l but I = will not follow-up on this thread.   I encourage you to = contact me directly via phone or email.   

 

Cheerily,

 

Sue =

 

----Original Message-----
From: Lou Berger = [mailto:lberger@labn.net]
Sent: Wednesday, January 25, 2017 7:27 = AM
To: Susan Hares
Cc: 'Martin Bjorklund'; i2rs@ietf.org; = draft-ietf-i2rs-yang-l3-topology@ietf.org; = j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; = Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; = kwatsen@juniper.net
Subject: RE: [i2rs] Kathleen Moriarty's No = Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

 

Sue,

 

In = short, I'm going to agree with Benoit - but for slightly different = reasons as I also co-chair TEAS, a group that is basing some of its work = on I2RS developed models.

 

>Lou 1:  As a WG chair, I have = always viewed the models being developed by I2RS as typical models that = are generally useful, and being defined by I2RS simply because they were = ahead of other groups that might otherwise define the >models -- and = I view this as a fine thing that has benefit for YANG users and other = WGs. As TEAS chair, this is what lead me to ensure that the models being = defined in TEAS built on the I2RS YANG modules vs their original path of = redefining >parallel function.

 

Sue = 1: I am pleased that TEAS WG and = other WG find the Topology models useful.   The topology model = design encompasses ephemeral state and security for ephemeral = state.  It was built to be a platform for topology models, and to = had early experimentation in the ODL models.   Perhaps you = missed the email on this thread where an insightful Martin asked = "Does this mean I2RS models cannot be used by Topology models in = other WGs?”

I responded "not really" and more = specifically " Most of the = topology models I have seen abide by the concepts found in the I2RS = topology model." 

Please see the mail at: =  https://www.ietf.org/mail-archive/web/i2rs/current/msg04231.html.&nb= sp;

 

The Topology models = really operate best in an ephemeral state environment.  Ephemeral = state is not a I2RS-only functionality.  Starting 4 years ago with = discussions with NETCONF/NETMOD at the NYC interim, =

It was indicated that ephemeral state would be = used by other WGs.  One of these key uses is the use for Topology = models.  Topology model’s ephemeral state allow operational = state learned from the routing system to be altered with writes from the = I2RS Client.    (Please note the security considerations = occur once read sensitive information or write sensitive information). =   This mixture of state does not really match the definition = of the

   o  configuration datastore: The = datastore holding the complete set of

      configuration data that = is required to get a device from its

      initial default state = into a desired operational state.

 

Let’s look at how = this applies to the draft-ietf-teas-yang-te-topo-06.txt in section 3.1: =

   

" TE topology is a = traffic engineering representation of one or = more

   layers of network topologies. TE = topology is comprised of TE nodes

   (TE graph = vertices) interconnected via TE links (TE graph edges). = A

   TE topology is mapped to a TE = graph."

 

TE topology model = defines: underlay TE topology, overlay TE topology, and Abstract TE = topology.    The model in = draft-ietf-teas-yang-te-topo-06.txt (ietf-te-topology) is technology = agnostic blending learned topology (underlay TE topology) and configured = topology to create an abstract TE topology.   This is a = wonderful use of the I2RS Topology model.  

 

Let’s look = what additional security is needed for Topology Models in Ephemeral = state:

 

Transport: =

Ephemeral state with topology models has security = risks which include topology information may be sensitive or allow DoS = attacks.  Based on this point, the I2RS WG spent time looking at = what protocol security and environment security is needed.  To = protect this information, I2RS WG decide the NETCONF/RESTCONF must run = over a transport that provide mutual authentication, data = confidentiality, data integrity and practical replay protections which = had structure to limit DoS attacks.  Mutual authentication requires = a key management system and the definition of what an I2RS identifier = is.   The security environment would need policy that = determine the interaction with other data stores, control plane = protocols, and dynamic configuration protocols.  These are = additions to the basic yang security considerations (sensitive/privacy = read nodes,  sensitive/privacy in write nodes, or sensitive/privacy = in rpc commands).  

 

I2RS allowed the = security association to exist without transport connections, or to have = multiple transport connections.  This mechanism provide better = bandwidth for accessing topology models.

 

AFAIK – the = NETCONF over SSH does not provide this level of security but NETCONF = over TLS with X.509v3 does and RESTCONF do.  If I NETCONF over SSH = (RFC4722) does provide this level of security, then please let me = know.   

 

Any data store must = solve the problem of multiple clients writing a data node. I2RS decided = multiple I2RS clients might want to write the topology in the I2RS = Agent, but defined the simultaneous write as an error (with priority = system as resolution).   This write contention is an = alternative to the configuration data store lock or the RESTCONF lock = for a single actions.  I2RS felt the speed choices on priority = (similar to BGP choices) were better for ephemeral state.   If = the priority system is used, then one priority must be assigned per user = identifier.  If TEAS or NETMOD wants to define another mechanism, = then this is a change from the I2RS protocol/ephemeral store = definitions.   It would be wonderful to have a discussion of = this in NETMOD since the ephemeral state requirement require it.  = It would be nice to have one multiple-write mechanism for a generalize = ephemeral state.

 

I2RS felt tracing, = better notification and pub/sub was necessary for I2RS.   TEAS = can refuse to import the trace, better notification or pub/sub work. =  

  

 

>Lou 2:  As part of my view of the = I2RS models being generally applicable to uses beyond I2RS together with = I2RS choosing YANG for modeling ephemeral data, I have always expected = that the I2RS WG would at some (perhaps as part of

>the I2RS protocol definition) define how any = YANG model can be used to support I2RS. This view certainly lead me to = conclude that having the I2RS models move forward, just like any other = YANG model, makes sense and would benefit the

> other models and WGs that reference this core = work. This view also allows for the relationship to the revised-data = store work, as well as the specification of which data

> store(s) I2RS uses, to be separately defined = -- and to not gate publication of these models. This separate = specification would be the location for any I2RS-specific transport and = security considers, so such would not belong in the

> generally reusable models developed by = I2RS.

 

>Essentially, As NETMOD co-chair, I concluded = that the revised data store work provided the direction on how ephemeral = would be supported in a general YANG context and, therefore, the major = open issue / gating impediment to >progressing I2RS models had been = removed and publication of these models were unblocked. This also = motivated my comments in the related discussions at the last = meeting.

 

Sue = 2:   Is the direction = for the ephemeral state concepts agreed upon?  The real test is if = we are able to define ephemeral state within the control plane data = store.  

 

You and I both thought = that the adoption of draft-ietf-netmod-ietf-revised-datastores-00.txt = completed this work on getting ephemeral data store concepts = completed.   You, I, Alia, Benoit thought progressing these = key models based on these concepts of ephemeral state in this document = seemed reasonable.   However, this discussion seems to be = stuck on what is ephemeral state and why is it different.  If so, = NETMOD does not have a clear ephemeral data store definition. =  

 

Let’s try 2 = tests:  a) did we get stuck on the security considerations = section?  (yes),   b) Is there general agreement and a = proposal for Yang modifications for ephemeral state? (no) =

 

Draft-ietf-netmod-ietf-revised-datastores-00.txt = suggest the Control Plane Data stores but there has been confusion on = this being an ephemeral data store with config=3Dtrue nodes and = operational state.  There document suggests a “<get-data = datastore>, but does not suggest a “write-data datastore> = command for ephemeral data store.  Perhaps based on the feedback from Juergen and = Martin, means we need to create: a) an I2RS ephemeral Control Plane data = store description, and b) create a document or a section in these = documents on the assumptions of data stores.

At the very least we = should add to this document what Martin’s suggests in the email = at:  

https://www.ietf.org/mail-archive/web/i2rs/current/msg04234.html

 

Which states: = 

“Yes, =
but (1) draft-ietf-netmod-ietf-revised-datastores-00 is =
clearly
work-in-progress, and (2) none of the topology =
drafts reference
draft-ietf-netmod-ietf-revised-datastores-00, so =
if they depend on a
solution in that draft, it is not very clear to =
the reader”.

 

The = draft-hares-i2rs-yang-sec-consider-00 suggests security considerations = need to indicate: mandatory transport, 4 features of the ephemeral data = store defined by I2RS, and whether any portion of the YANG model can = move over insecure transport.   Since these 4 features of I2RS = ephemeral data store set by the I2RS ephemeral state requirements = (draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed to in = draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not completed =  

 

Lou 3: If my understanding/view is correct, = i.e., that the topology models are just like any other YANG model, then = I think publication can and should proceed (with the appropriate text = for a typical YANG model).

 

Sue = 3: I hope that my explanation above indicates that the I2RS Topology = models are ephemeral models built for Topologies like TEAS.  It is = the very qualities you see in topology models that cause them to be = ephemeral in order to mix the operational state with configuration state = in a way that the configuration data store cannot.   If we = have a solid definition of Ephemeral data stores and Ephemeral Data = models, then these data models are like any other ephemeral YANG = model.  Any ephemeral model must choose a multiple client-write = design.   It would be lovely to have a single ephemeral data = store design.    

 

Lou = 4:  If I misunderstood something, and the models produced by = I2RS are limited to ephemeral representations/data stores as well as = specific YANG transport protocols -- then as TEAS chair, I have to hit = reset on the TEAS topology work, and as NETMOD chair I think the NETMOD = WG needs to discuss what it means for a YANG model to be = protocol/datastore specific and if any guidelines or other new NTEMOD = documents are need to support such.

 

Sue = 4: Perhaps the TEAS WG Chair = needs to discuss with the NETMOD WG Chair about completing the Ephemeral = data store work before coming to a conclusion.  =

 

Lou = 5: Less importantly, as = I2RS participant, I'd also ask for the documents to be sent back to the = WG for a new last call once the documents are updated to reflect their = narrow scope -- as I bet I'm not the only person who viewed this work = applicable to non-ephemeral uses.

 

Sue 5:  = As an I2RS Chair, I am not sure = you have correctly defined the narrow scope of the I2RS work or these = documents.  Of course, after we complete the revisions of these = documents if the ADs (Alia and Benoit) deem these need to go back to the = WG for another WG LC, then we will send the drafts for another WG = LC.   Right now, the only thing that the drafts have firmly to = revise is the Yang Security considerations define by =

 

htt= ps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines<= /span>

 

The rest of this list = discussion is simply a discussion of IESG members and people who did not = participate in the WG LC or the IETF LC regarding a proposal for = addition security considerations.   As Shepherd, = Kathleen’s questions about security consideration found missing = piece and I wrote a discussion document.  Unfortunately, the = discussion has not examined the document = (draft-hares-i2rs-yang-sec-consider) or the open issues in ephemeral = stsate.

 

Lou = 6: I hope this = helps.

 

Sue = 6: Was it meant to be helpful? =  I really, really hope you are engaging in a technical discussion = about ephemeral state and how we can move forward.  =

 

Two comments: =

·         = “then = as a TEAS chair, I have to hit rest on the TEAS topology work” or = as a

·         = “I2RS = participant, I’d also ask for the document to be sent to the WG = for a new last call once the documents are updated” =

 

seem to be making = conclusions without discussion. 

 

Cheerily, =

 

Sue =

 

 

On = January 24, 2017 11:56:32 AM "Susan Hares" <shares@ndzh.com> wrote:

 

> = To: Martin:

> 

> You have a reasonable request. If the NETMOD = WG Chairs confirm their

> = decision to make I2RS Yang Modules part of the Control Plane Datastore =

> then as shepherd/WG-chair I = will recommend these get added to the draft.

> 

> Note to authors :

> 

> As we wait for the NETMOD WG Chairs and Benoit = to deliver the decision

> on = Config/Control Plane datastore, the authors should work on:  Basic =

> Yang security considerations = and the other I2RS Yang Module information.

> 

> Sue Hares (Shepherd)

> -----Original Message-----

> From: Martin Bjorklund [mailto:mbj@tail-f.com]

> Sent: Tuesday, = January 24, 2017 10:39 AM

> To: = shares@ndzh.com

> Cc: i2rs@ietf.org;= draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

> = j.schoenwaelder@jacobs-un= iversity.de; i2rs-chairs@ietf.org;

> nite@hq.sk; = Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org;=

> lberger@labn.net; kwatsen@juniper.net

> Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on

> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

> 

> "Susan Hares" <shares@ndzh.com> wrote:

>> = Martin:

>> 

>> 

>> 

>> I'm sorry if misunderstood your comments = regarding the

>> = draft-ietf-netmod-revised-datastores-00.txt.  The reason the answer =

>> is unclear is that it = depends on the context of the question.

>> 

>> 

>> 

>> = .         If you ask if the = pre-standardization I2RS Yang Topology models

>> (basic and L3)  implemented are part = of the configuration data store,

>> the answer is yes - = AFAIK.

> 

> This is not my question.

> 

>> = .         If you ask if the WG = LC Topology models are approved to be part

> of

>> the configuration data store, my = understanding was no.   I2RS WG was to

>> abide by the decision of NETMOD WG on = which data store I2RS modules

>> were placed in.

> 

> Yes, this is my question.  And my concern = is that even if your

> = understanding is that they are not designed to be part of the =

> configuration datastores, = this fact is not mentioned in the drafts.

> 

>> If you are concerned the implementation = varies from the standardized,

> = please

>> express this to = Benoit Claise.   Based on your comments on my = email

> = thread,

>> I will be brief = in my answers today.

> 

> This is not my concern.

> 

> 

> /martin

> 

> 

> 

>> 

>> 

>> 

>> Sue

>> 

>> 

>> 

>> 

>> 

>> -----Original = Message-----

>> From: Martin = Bjorklund [mailto:mbj@tail-f.com]

>> Sent: Tuesday, = January 24, 2017 7:35 AM

>> = To: shares@ndzh.com

>> Cc: i2rs@ietf.org;= draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

>> j.schoenwaelder@jacobs-un= iversity.de; i2rs-chairs@ietf.org;

>> nite@hq.sk; = Kathleen.Moriarty.ietf@gm= ail.com; iesg@ietf.org;=

>> lberger@labn.net; kwatsen@juniper.net

>> Subject: Re: [i2rs] = Kathleen Moriarty's No Objection on

>> draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

>> 

>> 

>> 

>> "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:

>> 

>> > Martin:

>> 

>> >

>> 

>> > Your statement "One problem is = that relying on the solution in

>> 

>> > = draft-ietf-netmod-revised-datastores-00 is a bit premature - in =

>> > = fact,

>> 

>> > that document does not yet provide = any details at all on the I2RS

>> 

>> > ephemeral data store." This = statement is not what I understood from

>> > IETF

>> 98 or the netmod

>> 

>> > ADs.   I guess your = objection to this data model falls into Benoit

> Claise

>> 

>> > (AD) and the NETMOD folks to = answer.

>> 

>> 

>> 

>> Why do you think that I have any objection = to

>> = draft-ietf-netmod-revised-datastores-00.  Please re-read what I = wrote.

>> 

>> 

>> 

>> My objection regards your = statement:

>> 

>> 

>> 

>>    1) I2RS Data models do = not utilize the configuration data store,

>> 

>> 

>> 

>> If this is true it needs to be clarified = in the document.

>> 

>> 

>> 

>> After all these emails back and forth, it = is still not clear whether

>> this statement is true or = not.

>> 

>> 

>> 

>> 

>> 

>> /martin

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> >

>> 

>> > Sue Hares

>> 

>> >

>> 

>> > -----Original = Message-----

>> 

>> > From: i2rs [ <mailto:i2rs-bounces@ietf.= org>

>> > = mailto:i2rs-bounces@ietf.= org]

>> On Behalf = Of Martin

>> 

>> > Bjorklund

>> 

>> > Sent: Monday, January 23, 2017 5:26 = PM

>> 

>> > To:  <mailto:shares@ndzh.com> shares@ndzh.com

>> 

>> > Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;=

>> <mailto:draft-ietf-i2rs-ya= ng-l3-topology@ietf.org>

>> draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

>> 

>> >  <mailto:j.schoenwaelder@ja= cobs-university.de>

>> j.schoenwaelder@jacobs-un= iversity.de;  <mailto:i2rs-chairs@ietf.o= rg>

>> i2rs-chairs@ietf.org;

>> 

>> >  <mailto:nite@hq.sk<= /a>> nite@hq.sk;

>> <mailto:Kathleen.Moriarty.= ietf@gmail.com>

>> Kathleen.Moriarty.ietf@gm= ail.com; <mailto:iesg@ietf.org>

>> iesg@ietf.org<= o:p>

>> 

>> > Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

>> 

>> > draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)

>> 

>> >

>> 

>> > "Susan Hares" < <mailto:shares@ndzh.com> shares@ndzh.com> wrote:

>> 

>> > > Robert and = Martin:

>> 

>> > >

>> 

>> > > I agree with Robert that the = current implementations of the ODL

>> 

>> > > topology models are handled as = part of the configuration data

>> > > store

>> 

>> > > with

>> 

>> > ephemeral

>> 

>> > > state.   I will point = out that these implementation are pre-standards

>> 

>> > > implementations of the I2RS YANG = Data model.

>> 

>> > >

>> 

>> > > While standardizing the topology = data models, the I2RS WG have

>> > > been

>> 

>> > > asked to align with = the

>> > > = draft-ietf-netmod-revised-datastores-00.txt

>> 

>> > > NETMOD WG document.  This = NETMOD WG document moves the I2RS

>> 

>> > > ephemeral data

>> 

>> > store from

>> 

>> > > configuration data store to a = Control Plane data store.   If we follow

>> 

>> > this

>> 

>> > > draft, the I2RS Topology models = are part of the I2RS ephemeral

>> > > data

>> store.

>> 

>> > > If you disagree with the = placement of the Topology data models,

>> 

>> > > please indicate this to the = NETMOD WG and to Benoit.  Could you

>> 

>> > > propose a way that you would see = the ephemeral state working with

>> 

>> > > the configuration = data

>> 

>> > store

>> 

>> > > to the NETMOD = WG?

>> 

>> > >

>> 

>> > > Quite frankly, I feel a bit of = whip-lash on this topic.   NETMOD WG

> asks

>> 

>> > for

>> 

>> > > Control Plane Data store.  = You ask for configuration data store

>> 

>> > > (which was the I2RS initial = proposal).

>> 

>> >

>> 

>> > Not really; I ask for = clarification.

>> 

>> >

>> 

>> > > It is possible for either one to = work for I2RS

>> 

>> > > Topology models - if the right = details are taken care of.   How do we

>> make

>> 

>> > > progress on choosing one method = so we can write the I2RS Topology

>> 

>> > > Models security = considerations.?

>> 

>> >

>> 

>> > One problem is that relying on the = solution in

>> 

>> > = draft-ietf-netmod-revised-datastores-00 is a bit premature - in =

>> > = fact,

>> 

>> > that document does not yet provide = any details at all on the I2RS

>> 

>> > ephemeral datastore.

>> 

>> >

>> 

>> > So I see two alternatives.  = Either wait with these documents, or

>> 

>> > publish them with their datamodels as = is (i.e., no new additional

>> 

>> > notes), for the existing protocols = and architecure.  This would

>> > allow

>> 

>> > them to be implemented just like any = other YANG data model.  This

>> 

>> > would mean that the normal YANG = security considerations guidelines

>> > should

>> be followed.

>> 

>> >

>> 

>> >

>> 

>> >

>> 

>> > /martin

>> 

>> >

>> 

>> > >

>> 

>> > > Sue

>> 

>> > >

>> 

>> > > -----Original = Message-----

>> 

>> > > From: Robert Varga [ <mailto:nite@hq.sk<= /a>> mailto:nite@hq.sk<= /a>]

>> 

>> > > Sent: Monday, January 23, 2017 = 4:11 PM

>> 

>> > > To: Martin Bjorklund;  = <mailto:shares@ndzh.com> shares@ndzh.com

>> 

>> > > Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;=

>> <mailto:draft-ietf-i2rs-ya= ng-l3-topology@ietf.org>

>> draft-ietf-i2rs-yang-l3-t= opology@ietf.org;

>> 

>> > >  <mailto:j.schoenwaelder@ja= cobs-university.de>

>> j.schoenwaelder@jacobs-un= iversity.de;  <mailto:i2rs-chairs@ietf.o= rg>

>> i2rs-chairs@ietf.org;

>> 

>> > >  <mailto:Kathleen.Moriarty.= ietf@gmail.com>

>> Kathleen.Moriarty.ietf@gm= ail.com;  <mailto:iesg@ietf.org>

>> iesg@ietf.org<= o:p>

>> 

>> > > Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on

>> 

>> > > = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

>> 

>> > >

>> 

>> > > On 01/23/2017 09:26 PM, Martin = Bjorklund wrote:

>> 

>> > > >> I'm pulling your = questions to the top of this email.

>> 

>> > > >>

>> 

>> > > >>

>> 

>> > > >>

>> 

>> > > >> Question 1: Ok.  = Just to make sure I understand this correctly

>> > > >> -

>> 

>> > > >> these topology models = are intended to be I2RS-specific, and

>> > > >> they

>> 

>> > > >> cannot be used for any = other purpose.  If anyone needs a

>> > > >> = general

>> 

>> > > >> topology model outside = of the I2RS protocol, they will have to

>> 

>> > > >> design their own = model.  Is this correct?

>> 

>> > > >>

>> 

>> > > >>

>> 

>> > > >>

>> 

>> > > >> Response 1:  Not = really.

>> 

>> > > > Ok, so are you saying that = the models are in fact generic, and

>> > > > can

>> 

>> > > > be used outside of = I2RS?  I.e., they *can* be used with the

>> > > > normal

>> 

>> > > > configuration = datastores?

>> 

>> > > >

>> 

>> > >

>> 

>> > > From implementation experience, = yes, they can be used for storing

>> 

>> > > configuration. OpenDaylight uses = (an ancient predecessor of)

>> 

>> > > yang-network-topo to store = configure details about devices in its

>> 

>> > > managed = networks.

>> 

>> > >

>> 

>> > > Regards,

>> 

>> > > Robert

>> 

>> > >

>> 

>> > >

>> 

>> >

>> 

>> > = _______________________________________________

>> 

>> > i2rs mailing list

>> 

>> >  <mailto:i2rs@ietf.org> i2rs@ietf.org<= o:p>

>> 

>> >  <https://www.ietf.org/mail= man/listinfo/i2rs>

>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>> >

>> 

> 

> 

 

------=_NextPart_000_018E_01D27706.A27E48E0-- From nobody Wed Jan 25 09:57: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 15A72129AA2; Wed, 25 Jan 2017 09:57:20 -0800 (PST) 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 yRJYJaXN3AAQ; Wed, 25 Jan 2017 09:57:19 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6B7129A9B; Wed, 25 Jan 2017 09:57:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Giles Heron'" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> In-Reply-To: <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> Date: Wed, 25 Jan 2017 12:52:47 -0500 Message-ID: <01b101d27733$d7826490$86872db0$@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: AQDMDDOlqUr6NUq+FONL11ADZxeNCgGvnhE+AZ//NCkDIpJlDQJvvn+6AfFrv3ei/7PQ8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Lou Berger' , iesg@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 17:57:20 -0000 Juergen:=20 =20 "And with the revised datastore model it will also be straight forward = to have an implementation that just exposes topological data via the = operational state datastore. And the revised datastore model also paves = the path to support datastores that can also inject ephemeral data." Where do you believe the revised data store model suggest ephemeral data = can be injected - (?written)?=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder Sent: Wednesday, January 25, 2017 10:33 AM To: Giles Heron Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou = Berger; iesg@ietf.org; Alia Atlas Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: >=20 > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder = wrote: > >=20 > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > >>=20 > >> So - if one has models - such as a writable topology - where there=20 > >> can be dependencies on dynamic data, then those models can't be in=20 > >> the configuration data-store as currently defined. > >>=20 > >=20 > > Yes >=20 > but isn=E2=80=99t this confusing models and implementation? I just confirmed that the old datastore model does not support writable = ephemeral datastores. No more no less. And there is work in NETMOD (and = NETCONF) to revise the datastore model and to make data model reuse in = different datastores even simpler. =20 > if you have a case where you have a dependency on dynamic data then = you can=E2=80=99t put that instantiation of the model in the = configuration data-store. >=20 > but if your implementation never depends on dynamic data then it ought = to be fine. Yes. This should be fine. And with the revised datastore model it will also be straight forward to = have an implementation that just exposes topological data via the = operational state datastore. And the revised datastore model also paves = the path to support datastores that can also inject ephemeral data. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jan 25 10:23: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 31B54129AD5 for ; Wed, 25 Jan 2017 10:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 9l-PxwRICC8i for ; Wed, 25 Jan 2017 10:23:22 -0800 (PST) Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4246129AC8 for ; Wed, 25 Jan 2017 10:23:21 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 441091E0DC8 for ; Wed, 25 Jan 2017 11:23:21 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ciPH1u00X2SSUrH01iPLUF; Wed, 25 Jan 2017 11:23:21 -0700 X-Authority-Analysis: v=2.1 cv=JsBi8qIC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=OUXY8nFuAAAA:8 a=1sjgXBK7AAAA:8 a=u07AKapRAAAA:8 a=6CUQYUxTYoShYv8To3UA:9 a=AOTBNU1Be9v6Qw-5:21 a=xEVkIHHTQApZt2Wj:21 a=pILNOxqGKmIA:10 a=hvAExEulOBQA:10 a=GMDvBvxVTm0A:10 a=REbz-vg_6-IA:10 a=6jSAqOTSWgsA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=cAcMbU7R10T-QSRYIcO_:22 a=qowbMnUzjQcM5iyYROrS:22 a=SkebfZ6J2Mmvk2rLHZle:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Z+bEyG5cP1MrlFRnPSMws7TQsXr+8eZHPIquZ+ath7M=; b=gOQxbAxf1Bf0o3txZbLtgMbhVa Aci5MKESWPSgNP2SCNBQr+0wMVrXxvb/+XhF9qYstMn5JHtWzVKhwNORggjSMGA1Duzw3QlTxlXKK 5w//NZR+YOrJ57uu1eyih3Fr5; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:52624 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cWSE0-0006PY-Uo; Wed, 25 Jan 2017 11:23:17 -0700 To: Susan Hares References: <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> <20170124.163910.1660442168342299903.mbj@tail-f.com> <000d01d27662$0216d8d0$06448a70$@ndzh.com> <8fca02ad-b589-a77e-0ed9-c12796dc47c3@labn.net> <018d01d27730$8b4b7740$a1e265c0$@ndzh.com> From: Lou Berger Message-ID: <4940e866-13dc-5955-5ae9-27bd1b49a1e5@labn.net> Date: Wed, 25 Jan 2017 13:23:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <018d01d27730$8b4b7740$a1e265c0$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cWSE0-0006PY-Uo X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:52624 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: i2rs@ietf.org, 'Martin Bjorklund' , kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 18:23:25 -0000 Hi Sue, On 1/25/2017 12:29 PM, Susan Hares wrote: > > Lou: > > > > I am happy to receive your email as it demonstrates misconceptions > about what I stated. The original topic of this thread was the > security considerations section regarding an I2RS Topology model. > Understood. > > Due to my respect for you, I am going to provide you a technical > response on list. > Thank you (I think). > I have labeled my responses to respond to your points. I have > responded on l but I will not follow-up on this thread. I encourage > you to contact me directly via phone or email. > > > okay - but I'm not sure if you want me to address the comments below here or wait for an off-line call. I guess I'll wait for a one-on-one discussion. one point I think I need to clarify for everyone is in response to: > seem to be making conclusions without discussion. To be clear my statements on what's next had caveats that were based on what you/I2RS/the IESG decide - it was not stating a definitive conclusion or direction, but rather possibilities based on a decision that I expect to happen in the context of I2RS. Lou > Cheerily, > > > > Sue > > > > ----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 25, 2017 7:27 AM > To: Susan Hares > Cc: 'Martin Bjorklund'; i2rs@ietf.org; > draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; > nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; > kwatsen@juniper.net > Subject: RE: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Sue, > > > > In short, I'm going to agree with Benoit - but for slightly different > reasons as I also co-chair TEAS, a group that is basing some of its > work on I2RS developed models. > > > > *>Lou 1:* As a WG chair, I have always viewed the models being > developed by I2RS as typical models that are generally useful, and > being defined by I2RS simply because they were ahead of other groups > that might otherwise define the >models -- and I view this as a fine > thing that has benefit for YANG users and other WGs. As TEAS chair, > this is what lead me to ensure that the models being defined in TEAS > built on the I2RS YANG modules vs their original path of redefining > >parallel function. > > > > *Sue 1:*I am pleased that TEAS WG and other WG find the Topology > models useful. The topology model design encompasses ephemeral state > and security for ephemeral state. It was built to be a platform for > topology models, and to had early experimentation in the ODL models. > Perhaps you missed the email on this thread where an insightful > Martin asked "Does this mean I2RS models cannot be used by Topology > models in other WGs? > > I responded "not really" and more specifically " Most of the topology > models I have seen abide by the concepts found in the I2RS topology > model." > > Please see the mail at: > https://www.ietf.org/mail-archive/web/i2rs/current/msg04231.html. > > > > The Topology models really operate best in an ephemeral state > environment. Ephemeral state is not a I2RS-only functionality. > Starting 4 years ago with discussions with NETCONF/NETMOD at the NYC > interim, > > It was indicated that ephemeral state would be used by other WGs. One > of these key uses is the use for Topology models. Topology models > ephemeral state allow operational state learned from the routing > system to be altered with writes from the I2RS Client. (Please note > the security considerations occur once read sensitive information or > write sensitive information). This mixture of state does not really > match the definition of the > > o configuration datastore: The datastore holding the complete set of > > configuration data that is required to get a device from its > > initial default state into a desired operational state. > > > > Lets look at how this applies to the > draft-ietf-teas-yang-te-topo-06.txt in section 3.1: > > > > " TE topology is a traffic engineering representation of one or more > > layers of network topologies. TE topology is comprised of TE nodes > > (TE graph vertices) interconnected via TE links (TE graph edges). A > > TE topology is mapped to a TE graph." > > > > TE topology model defines: underlay TE topology, overlay TE topology, > and Abstract TE topology. The model in > draft-ietf-teas-yang-te-topo-06.txt (ietf-te-topology) is technology > agnostic blending learned topology (underlay TE topology) and > configured topology to create an abstract TE topology. This is a > wonderful use of the I2RS Topology model. > > > > *Lets look what additional security is needed for Topology Models in > Ephemeral state: * > > > > *Transport: * > > Ephemeral state with topology models has security risks which include > topology information may be sensitive or allow DoS attacks. Based on > this point, the I2RS WG spent time looking at what protocol security > and environment security is needed. To protect this information, I2RS > WG decide the NETCONF/RESTCONF must run over a transport that provide > mutual authentication, data confidentiality, data integrity and > practical replay protections which had structure to limit DoS attacks. > Mutual authentication requires a key management system and the > definition of what an I2RS identifier is. The security environment > would need policy that determine the interaction with other data > stores, control plane protocols, and dynamic configuration protocols. > These are additions to the basic yang security considerations > (sensitive/privacy read nodes, sensitive/privacy in write nodes, or > sensitive/privacy in rpc commands). > > > > I2RS allowed the security association to exist without transport > connections, or to have multiple transport connections. This > mechanism provide better bandwidth for accessing topology models. > > > > AFAIK the NETCONF over SSH does not provide this level of security > but NETCONF over TLS with X.509v3 does and RESTCONF do. If I NETCONF > over SSH (RFC4722) does provide this level of security, then please > let me know. > > > > Any data store must solve the problem of multiple clients writing a > data node. I2RS decided multiple I2RS clients might want to write the > topology in the I2RS Agent, but defined the simultaneous write as an > error (with priority system as resolution). This write contention is > an alternative to the configuration data store lock or the RESTCONF > lock for a single actions. I2RS felt the speed choices on priority > (similar to BGP choices) were better for ephemeral state. If the > priority system is used, then one priority must be assigned per user > identifier. If TEAS or NETMOD wants to define another mechanism, then > this is a change from the I2RS protocol/ephemeral store definitions. > It would be wonderful to have a discussion of this in NETMOD since > the ephemeral state requirement require it. It would be nice to have > one multiple-write mechanism for a generalize ephemeral state. > > > > I2RS felt tracing, better notification and pub/sub was necessary for > I2RS. TEAS can refuse to import the trace, better notification or > pub/sub work. > > > > > > *>Lou 2:* As part of my view of the I2RS models being generally > applicable to uses beyond I2RS together with I2RS choosing YANG for > modeling ephemeral data, I have always expected that the I2RS WG would > at some (perhaps as part of > > >the I2RS protocol definition) define how any YANG model can be used > to support I2RS. This view certainly lead me to conclude that having > the I2RS models move forward, just like any other YANG model, makes > sense and would benefit the > > > other models and WGs that reference this core work. This view also > allows for the relationship to the revised-data store work, as well as > the specification of which data > > > store(s) I2RS uses, to be separately defined -- and to not gate > publication of these models. This separate specification would be the > location for any I2RS-specific transport and security considers, so > such would not belong in the > > > generally reusable models developed by I2RS. > > > > >Essentially, As NETMOD co-chair, I concluded that the revised data > store work provided the direction on how ephemeral would be supported > in a general YANG context and, therefore, the major open issue / > gating impediment to >progressing I2RS models had been removed and > publication of these models were unblocked. This also motivated my > comments in the related discussions at the last meeting. > > > > *Sue 2:* Is the direction for the ephemeral state concepts agreed > upon? The real test is if we are able to define ephemeral state > within the control plane data store. > > > > You and I both thought that the adoption of > draft-ietf-netmod-ietf-revised-datastores-00.txt completed this work > on getting ephemeral data store concepts completed. You, I, Alia, > Benoit thought progressing these key models based on these concepts of > ephemeral state in this document seemed reasonable. However, this > discussion seems to be stuck on what is ephemeral state and why is it > different. If so, NETMOD does not have a clear ephemeral data store > definition. > > > > Lets try 2 tests: a) did we get stuck on the security considerations > section? (yes), b) Is there general agreement and a proposal for > Yang modifications for ephemeral state? (no) > > > > Draft-ietf-netmod-ietf-revised-datastores-00.txt suggest the Control > Plane Data stores but there has been confusion on this being an > ephemeral data store with config=true nodes and operational state. > There document suggests a , but does not suggest > a write-data datastore> command for ephemeral data store. Perhaps > based on the feedback from Juergen and Martin, means we need to > create: a) an I2RS ephemeral Control Plane data store description, and > b) create a document or a section in these documents on the > assumptions of data stores. > > At the very least we should add to this document what Martins > suggests in the email at: > > https://www.ietf.org/mail-archive/web/i2rs/current/msg04234.html > > > > Which states: > > /Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly/ > /work-in-progress, and (2) none of the topology drafts reference/ > /draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a/ > /solution in that draft, it is not very clear to the reader./ > > > > The draft-hares-i2rs-yang-sec-consider-00 suggests security > considerations need to indicate: mandatory transport, 4 features of > the ephemeral data store defined by I2RS, and whether any portion of > the YANG model can move over insecure transport. Since these 4 > features of I2RS ephemeral data store set by the I2RS ephemeral state > requirements (draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed > to in draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not > completed > > > > *Lou 3:* If my understanding/view is correct, i.e., that the topology > models are just like any other YANG model, then I think publication > can and should proceed (with the appropriate text for a typical YANG > model). > > > > *Sue 3:* I hope that my explanation above indicates that the I2RS > Topology models are ephemeral models built for Topologies like TEAS. > It is the very qualities you see in topology models that cause them to > be ephemeral in order to mix the operational state with configuration > state in a way that the configuration data store cannot. If we have > a solid definition of Ephemeral data stores and Ephemeral Data models, > then these data models are like any other ephemeral YANG model. Any > ephemeral model must choose a multiple client-write design. It would > be lovely to have a single ephemeral data store design. > > > > *Lou 4*: If I misunderstood something, and the models produced by > I2RS are limited to ephemeral representations/data stores as well as > specific YANG transport protocols -- then as TEAS chair, I have to hit > reset on the TEAS topology work, and as NETMOD chair I think the > NETMOD WG needs to discuss what it means for a YANG model to be > protocol/datastore specific and if any guidelines or other new NTEMOD > documents are need to support such. > > > > *Sue 4:*Perhaps the TEAS WG Chair needs to discuss with the NETMOD WG > Chair about completing the Ephemeral data store work before coming to > a conclusion. > > > > *Lou 5:*Less importantly, as I2RS participant, I'd also ask for the > documents to be sent back to the WG for a new last call once the > documents are updated to reflect their narrow scope -- as I bet I'm > not the only person who viewed this work applicable to non-ephemeral uses. > > > > *Sue 5: *As an I2RS Chair, I am not sure you have correctly defined > the narrow scope of the I2RS work or these documents. Of course, > after we complete the revisions of these documents if the ADs (Alia > and Benoit) deem these need to go back to the WG for another WG LC, > then we will send the drafts for another WG LC. Right now, the only > thing that the drafts have firmly to revise is the Yang Security > considerations define by > > > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > > > The rest of this list discussion is simply a discussion of IESG > members and people who did not participate in the WG LC or the IETF LC > regarding a proposal for addition security considerations. As > Shepherd, Kathleens questions about security consideration found > missing piece and I wrote a discussion document. Unfortunately, the > discussion has not examined the document > (draft-hares-i2rs-yang-sec-consider) or the open issues in ephemeral > stsate. > > > > *Lou 6:*I hope this helps. > > > > *Sue 6:*Was it meant to be helpful? I really, really hope you are > engaging in a technical discussion about ephemeral state and how we > can move forward. > > > > Two comments: > > then as a TEAS chair, I have to hit rest on the TEAS > topology work or as a > > I2RS participant, Id also ask for the document to be sent > to the WG for a new last call once the documents are updated > > > > seem to be making conclusions without discussion. > > > > Cheerily, > > > > Sue > > > > > > On January 24, 2017 11:56:32 AM "Susan Hares" > wrote: > > > > > To: Martin: > > > > > > You have a reasonable request. If the NETMOD WG Chairs confirm their > > > decision to make I2RS Yang Modules part of the Control Plane Datastore > > > then as shepherd/WG-chair I will recommend these get added to the draft. > > > > > > Note to authors : > > > > > > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision > > > on Config/Control Plane datastore, the authors should work on: Basic > > > Yang security considerations and the other I2RS Yang Module information. > > > > > > Sue Hares (Shepherd) > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, January 24, 2017 10:39 AM > > > To: shares@ndzh.com > > > Cc: i2rs@ietf.org ; > draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > > > j.schoenwaelder@jacobs-university.de > ; i2rs-chairs@ietf.org > ; > > > nite@hq.sk ; Kathleen.Moriarty.ietf@gmail.com > ; iesg@ietf.org > ; > > > lberger@labn.net ; kwatsen@juniper.net > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" > wrote: > > >> Martin: > > >> > > >> > > >> > > >> I'm sorry if misunderstood your comments regarding the > > >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer > > >> is unclear is that it depends on the context of the question. > > >> > > >> > > >> > > >> . If you ask if the pre-standardization I2RS Yang Topology > models > > >> (basic and L3) implemented are part of the configuration data store, > > >> the answer is yes - AFAIK. > > > > > > This is not my question. > > > > > >> . If you ask if the WG LC Topology models are approved to > be part > > > of > > >> the configuration data store, my understanding was no. I2RS WG was to > > >> abide by the decision of NETMOD WG on which data store I2RS modules > > >> were placed in. > > > > > > Yes, this is my question. And my concern is that even if your > > > understanding is that they are not designed to be part of the > > > configuration datastores, this fact is not mentioned in the drafts. > > > > > >> If you are concerned the implementation varies from the standardized, > > > please > > >> express this to Benoit Claise. Based on your comments on my email > > > thread, > > >> I will be brief in my answers today. > > > > > > This is not my concern. > > > > > > > > > /martin > > > > > > > > > > > >> > > >> > > >> > > >> Sue > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Martin Bjorklund [mailto:mbj@tail-f.com] > > >> Sent: Tuesday, January 24, 2017 7:35 AM > > >> To: shares@ndzh.com > > >> Cc: i2rs@ietf.org ; > draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > > >> j.schoenwaelder@jacobs-university.de > ; i2rs-chairs@ietf.org > ; > > >> nite@hq.sk ; Kathleen.Moriarty.ietf@gmail.com > ; iesg@ietf.org > ; > > >> lberger@labn.net ; kwatsen@juniper.net > > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > >> > > >> "Susan Hares" < shares@ndzh.com > > wrote: > > >> > > >> > Martin: > > >> > > >> > > > >> > > >> > Your statement "One problem is that relying on the solution in > > >> > > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > > >> > fact, > > >> > > >> > that document does not yet provide any details at all on the I2RS > > >> > > >> > ephemeral data store." This statement is not what I understood from > > >> > IETF > > >> 98 or the netmod > > >> > > >> > ADs. I guess your objection to this data model falls into Benoit > > > Claise > > >> > > >> > (AD) and the NETMOD folks to answer. > > >> > > >> > > >> > > >> Why do you think that I have any objection to > > >> draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. > > >> > > >> > > >> > > >> My objection regards your statement: > > >> > > >> > > >> > > >> 1) I2RS Data models do not utilize the configuration data store, > > >> > > >> > > >> > > >> If this is true it needs to be clarified in the document. > > >> > > >> > > >> > > >> After all these emails back and forth, it is still not clear whether > > >> this statement is true or not. > > >> > > >> > > >> > > >> > > >> > > >> /martin > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > Sue Hares > > >> > > >> > > > >> > > >> > -----Original Message----- > > >> > > >> > From: i2rs [ > > >> > mailto:i2rs-bounces@ietf.org] > > >> On Behalf Of Martin > > >> > > >> > Bjorklund > > >> > > >> > Sent: Monday, January 23, 2017 5:26 PM > > >> > > >> > To: shares@ndzh.com > > > >> > > >> > Cc: i2rs@ietf.org ; > > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > > >> > > >> > > > >> j.schoenwaelder@jacobs-university.de > ; > > > >> i2rs-chairs@ietf.org ; > > >> > > >> > nite@hq.sk ; > > >> > > >> Kathleen.Moriarty.ietf@gmail.com > ; > > >> iesg@ietf.org > > >> > > >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> > > >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > > >> > > >> > "Susan Hares" < shares@ndzh.com > > wrote: > > >> > > >> > > Robert and Martin: > > >> > > >> > > > > >> > > >> > > I agree with Robert that the current implementations of the ODL > > >> > > >> > > topology models are handled as part of the configuration data > > >> > > store > > >> > > >> > > with > > >> > > >> > ephemeral > > >> > > >> > > state. I will point out that these implementation are > pre-standards > > >> > > >> > > implementations of the I2RS YANG Data model. > > >> > > >> > > > > >> > > >> > > While standardizing the topology data models, the I2RS WG have > > >> > > been > > >> > > >> > > asked to align with the > > >> > > draft-ietf-netmod-revised-datastores-00.txt > > >> > > >> > > NETMOD WG document. This NETMOD WG document moves the I2RS > > >> > > >> > > ephemeral data > > >> > > >> > store from > > >> > > >> > > configuration data store to a Control Plane data store. If we > follow > > >> > > >> > this > > >> > > >> > > draft, the I2RS Topology models are part of the I2RS ephemeral > > >> > > data > > >> store. > > >> > > >> > > If you disagree with the placement of the Topology data models, > > >> > > >> > > please indicate this to the NETMOD WG and to Benoit. Could you > > >> > > >> > > propose a way that you would see the ephemeral state working with > > >> > > >> > > the configuration data > > >> > > >> > store > > >> > > >> > > to the NETMOD WG? > > >> > > >> > > > > >> > > >> > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG > > > asks > > >> > > >> > for > > >> > > >> > > Control Plane Data store. You ask for configuration data store > > >> > > >> > > (which was the I2RS initial proposal). > > >> > > >> > > > >> > > >> > Not really; I ask for clarification. > > >> > > >> > > > >> > > >> > > It is possible for either one to work for I2RS > > >> > > >> > > Topology models - if the right details are taken care of. How > do we > > >> make > > >> > > >> > > progress on choosing one method so we can write the I2RS Topology > > >> > > >> > > Models security considerations.? > > >> > > >> > > > >> > > >> > One problem is that relying on the solution in > > >> > > >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in > > >> > fact, > > >> > > >> > that document does not yet provide any details at all on the I2RS > > >> > > >> > ephemeral datastore. > > >> > > >> > > > >> > > >> > So I see two alternatives. Either wait with these documents, or > > >> > > >> > publish them with their datamodels as is (i.e., no new additional > > >> > > >> > notes), for the existing protocols and architecure. This would > > >> > allow > > >> > > >> > them to be implemented just like any other YANG data model. This > > >> > > >> > would mean that the normal YANG security considerations guidelines > > >> > should > > >> be followed. > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > /martin > > >> > > >> > > > >> > > >> > > > > >> > > >> > > Sue > > >> > > >> > > > > >> > > >> > > -----Original Message----- > > >> > > >> > > From: Robert Varga [ mailto:nite@hq.sk] > > >> > > >> > > Sent: Monday, January 23, 2017 4:11 PM > > >> > > >> > > To: Martin Bjorklund; shares@ndzh.com > > > >> > > >> > > Cc: i2rs@ietf.org ; > > >> > > >> draft-ietf-i2rs-yang-l3-topology@ietf.org > ; > > >> > > >> > > > > >> j.schoenwaelder@jacobs-university.de > ; > > > >> i2rs-chairs@ietf.org ; > > >> > > >> > > > > >> Kathleen.Moriarty.ietf@gmail.com > ; > > >> iesg@ietf.org > > >> > > >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> > > >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > > > >> > > >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: > > >> > > >> > > >> I'm pulling your questions to the top of this email. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Question 1: Ok. Just to make sure I understand this correctly > > >> > > >> - > > >> > > >> > > >> these topology models are intended to be I2RS-specific, and > > >> > > >> they > > >> > > >> > > >> cannot be used for any other purpose. If anyone needs a > > >> > > >> general > > >> > > >> > > >> topology model outside of the I2RS protocol, they will have to > > >> > > >> > > >> design their own model. Is this correct? > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Response 1: Not really. > > >> > > >> > > > Ok, so are you saying that the models are in fact generic, and > > >> > > > can > > >> > > >> > > > be used outside of I2RS? I.e., they *can* be used with the > > >> > > > normal > > >> > > >> > > > configuration datastores? > > >> > > >> > > > > > >> > > >> > > > > >> > > >> > > From implementation experience, yes, they can be used for storing > > >> > > >> > > configuration. OpenDaylight uses (an ancient predecessor of) > > >> > > >> > > yang-network-topo to store configure details about devices in its > > >> > > >> > > managed networks. > > >> > > >> > > > > >> > > >> > > Regards, > > >> > > >> > > Robert > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > _______________________________________________ > > >> > > >> > i2rs mailing list > > >> > > >> > i2rs@ietf.org > > >> > > >> > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > >> > > > >> > > > > > > > > > From nobody Wed Jan 25 10:53:35 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 5FE76129AD3; Wed, 25 Jan 2017 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGfuHwXIq4SA; Wed, 25 Jan 2017 10:53:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD1A129AE4; Wed, 25 Jan 2017 10:53:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A3A0F6A2; Wed, 25 Jan 2017 19:53:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vtD8qBUnlfx9; Wed, 25 Jan 2017 19:53:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 19:53:29 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28CAF200AD; Wed, 25 Jan 2017 19:53:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XbMunJwueqeW; Wed, 25 Jan 2017 19:53:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70ED6200AC; Wed, 25 Jan 2017 19:53:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 904883E4C0F2; Wed, 25 Jan 2017 19:53:30 +0100 (CET) Date: Wed, 25 Jan 2017 19:53:30 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170125185330.GC41811@elstar.local> Mail-Followup-To: Susan Hares , 'Giles Heron' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Lou Berger' , iesg@ietf.org, 'Alia Atlas' References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <01b101d27733$d7826490$86872db0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:53:33 -0000 Sue, the current thinking is documented in draft-ietf-netmod-revised-datastores-00.txt. /js On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > Juergen: > > "And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data." > > Where do you believe the revised data store model suggest ephemeral data can be injected - (?written)? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, January 25, 2017 10:33 AM > To: Giles Heron > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou Berger; iesg@ietf.org; Alia Atlas > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder wrote: > > > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > >> > > >> So - if one has models - such as a writable topology - where there > > >> can be dependencies on dynamic data, then those models can't be in > > >> the configuration data-store as currently defined. > > >> > > > > > > Yes > > > > but isn’t this confusing models and implementation? > > I just confirmed that the old datastore model does not support writable ephemeral datastores. No more no less. And there is work in NETMOD (and NETCONF) to revise the datastore model and to make data model reuse in different datastores even simpler. > > > if you have a case where you have a dependency on dynamic data then you can’t put that instantiation of the model in the configuration data-store. > > > > but if your implementation never depends on dynamic data then it ought to be fine. > > Yes. This should be fine. > > And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 11:02:46 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 2D4B0129AE9; Wed, 25 Jan 2017 11:02:41 -0800 (PST) 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 ucE6OwX1U169; Wed, 25 Jan 2017 11:02:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A23129AE5; Wed, 25 Jan 2017 11:02:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> <20170125185330.GC41811@elstar.local> In-Reply-To: <20170125185330.GC41811@elstar.local> Date: Wed, 25 Jan 2017 13:58:13 -0500 Message-ID: <01c601d2773c$fb26c1d0$f1744570$@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: AQDMDDOlqUr6NUq+FONL11ADZxeNCgGvnhE+AZ//NCkDIpJlDQJvvn+6AfFrv3cCLl/QqwD/niYAouZWo+A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 19:02:41 -0000 Juergen:=20 Where do you think the revised data store model in that draft suggests = ephemeral data stores live?=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder Sent: Wednesday, January 25, 2017 1:54 PM To: Susan Hares Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia = Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Sue, the current thinking is documented in draft-ietf-netmod-revised-datastores-00.txt. /js On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > Juergen:=20 > =20 > "And with the revised datastore model it will also be straight forward = to have an implementation that just exposes topological data via the = operational state datastore. And the revised datastore model also paves = the path to support datastores that can also inject ephemeral data." >=20 > Where do you believe the revised data store model suggest ephemeral = data can be injected - (?written)?=20 >=20 > Sue >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Wednesday, January 25, 2017 10:33 AM > To: Giles Heron > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou=20 > Berger; iesg@ietf.org; Alia Atlas > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > >=20 > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder = wrote: > > >=20 > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > >>=20 > > >> So - if one has models - such as a writable topology - where=20 > > >> there can be dependencies on dynamic data, then those models=20 > > >> can't be in the configuration data-store as currently defined. > > >>=20 > > >=20 > > > Yes > >=20 > > but isn=E2=80=99t this confusing models and implementation? >=20 > I just confirmed that the old datastore model does not support = writable ephemeral datastores. No more no less. And there is work in = NETMOD (and NETCONF) to revise the datastore model and to make data = model reuse in different datastores even simpler. > =20 > > if you have a case where you have a dependency on dynamic data then = you can=E2=80=99t put that instantiation of the model in the = configuration data-store. > >=20 > > but if your implementation never depends on dynamic data then it = ought to be fine. >=20 > Yes. This should be fine. >=20 > And with the revised datastore model it will also be straight forward = to have an implementation that just exposes topological data via the = operational state datastore. And the revised datastore model also paves = the path to support datastores that can also inject ephemeral data. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jan 25 11:05:10 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 5E2B5129AFD; Wed, 25 Jan 2017 11:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7i1Mg7DHTw5; Wed, 25 Jan 2017 11:05:05 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C0D129AE4; Wed, 25 Jan 2017 11:05:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6FE3F6BF; Wed, 25 Jan 2017 20:05:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A4gKHgEs6m6m; Wed, 25 Jan 2017 20:05:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jan 2017 20:05:02 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A6C1200AC; Wed, 25 Jan 2017 20:05:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ylTbyoI4xctn; Wed, 25 Jan 2017 20:05:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C4AD200AB; Wed, 25 Jan 2017 20:05:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0DE103E4C1E2; Wed, 25 Jan 2017 20:05:03 +0100 (CET) Date: Wed, 25 Jan 2017 20:05:03 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170125190503.GD41811@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> <20170125185330.GC41811@elstar.local> <01c601d2773c$fb26c1d0$f1744570$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <01c601d2773c$fb26c1d0$f1744570$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:05:06 -0000 Just search for ephemeral in the document and you will hit this: The model foresees control-plane datastores that are by definition not part of the persistent configuration of a device. In some contexts, these have been termed ephemeral datastores since the information is ephemeral, i.e., lost upon reboot. The control-plane datastores interact with the rest of the system through the or datastores, depending on the type of data they contain. Note that the ephemeral datastore discussed in I2RS documents maps to a control-plane datastore in the revised datastore model described here. /js On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote: > Juergen: > > Where do you think the revised data store model in that draft suggests ephemeral data stores live? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, January 25, 2017 1:54 PM > To: Susan Hares > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Sue, > > the current thinking is documented in > draft-ietf-netmod-revised-datastores-00.txt. > > /js > > On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > > Juergen: > > > > "And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data." > > > > Where do you believe the revised data store model suggest ephemeral data can be injected - (?written)? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, January 25, 2017 10:33 AM > > To: Giles Heron > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou > > Berger; iesg@ietf.org; Alia Atlas > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > > > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder wrote: > > > > > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > > >> > > > >> So - if one has models - such as a writable topology - where > > > >> there can be dependencies on dynamic data, then those models > > > >> can't be in the configuration data-store as currently defined. > > > >> > > > > > > > > Yes > > > > > > but isn’t this confusing models and implementation? > > > > I just confirmed that the old datastore model does not support writable ephemeral datastores. No more no less. And there is work in NETMOD (and NETCONF) to revise the datastore model and to make data model reuse in different datastores even simpler. > > > > > if you have a case where you have a dependency on dynamic data then you can’t put that instantiation of the model in the configuration data-store. > > > > > > but if your implementation never depends on dynamic data then it ought to be fine. > > > > Yes. This should be fine. > > > > And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 11:12:55 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 907B3129B15 for ; Wed, 25 Jan 2017 11:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3QyG7uz39sP for ; Wed, 25 Jan 2017 11:12:51 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A5592129B13 for ; Wed, 25 Jan 2017 11:12:48 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id x49so33356924qtc.2 for ; Wed, 25 Jan 2017 11:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eqpQNVpscvexTrQWqazN7DycOEjonog9XAMXMQ3vzbQ=; b=f7Z9FEJDzqaY7X4NdQwZmGfDmZKzYuzXA6H70laEK/jpD1jfDRrN2NpiBy5ubQJDCr tckSg8nRUhOyh8QenB8xzOKChUMYrc38ivLdKXWxlVcYs5eUujRiARHSkSDDVeP4DxAF BbUCmBzwAxi9M4M4hXC5wXIlwLO0/KGGXbMSfeRQ+vwB6KNE5EhxDt5Vuldd43VptGAw 2sFdXCxe7qMcx2kxl8VW7vRZj81Iee8uklD9Iu8nB1F3PYN8SuJBtidsWgZQP/eY+zlD 69Tn/zJ7FneYGcYSY/QZJUA2jnfxp1OKz4196/hNDxTjrUp2veZ97oWGpbeCS8vjkJZ6 TrTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eqpQNVpscvexTrQWqazN7DycOEjonog9XAMXMQ3vzbQ=; b=Gih4hOt/Z4xMK68X6Pw+iOChi/zaJ40ldHQsoP+Tur9eqJ7DxUgq/CEe2UcSD3mGCf RaTYFpehYEIcJ1Hl3PmVGEt41cb/6gf8+8g37EnpFsbH0+lFhsIGQkSnbFfyqzDYucjn kh1rmCkrpchu3DcBrdzCMjC1IIKcwU2Ss92lRjjGSZnSuGC7CARke/BU3CHytKol4+QZ 7afhvr0P1UTz9jnF9uID9GmJBHsAvBUbvk0A0cL2SgZdMrYwK+86vLcbUhDPGVpQyLgC Kwp0447ONn6ZOx6pTo35gldBGc685d+SXkipofd36y4B1rqbyo4KdihdD9Ey0EAbPUVS dufg== X-Gm-Message-State: AIkVDXJJxKoVbobhWNbK1iYGxH+ft/upFgKfIOazsuSXqRhHrYl/47Oaq2tuFEJv4cx136GL7A+LItCThnnaoQ== X-Received: by 10.200.48.235 with SMTP id w40mr37822622qta.72.1485371567423; Wed, 25 Jan 2017 11:12:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Wed, 25 Jan 2017 11:12:46 -0800 (PST) In-Reply-To: <20170125190503.GD41811@elstar.local> References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> <20170125185330.GC41811@elstar.local> <01c601d2773c$fb26c1d0$f1744570$@ndzh.com> <20170125190503.GD41811@elstar.local> From: Andy Bierman Date: Wed, 25 Jan 2017 11:12:46 -0800 Message-ID: To: Juergen Schoenwaelder , Susan Hares , "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org, Alia Atlas , Giles Heron , The IESG , Lou Berger Content-Type: multipart/alternative; boundary=001a11404a48a2dd050546f0047d Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 19:12:52 -0000 --001a11404a48a2dd050546f0047d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2017 at 11:05 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Just search for ephemeral in the document and you will hit this: > > The model foresees control-plane datastores that are by definition > not part of the persistent configuration of a device. In some > contexts, these have been termed ephemeral datastores since the > information is ephemeral, i.e., lost upon reboot. The control-plane > datastores interact with the rest of the system through the > or datastores, depending on the type of data they > contain. Note that the ephemeral datastore discussed in I2RS > documents maps to a control-plane datastore in the revised datastore > model described here. > > The modules in draft-ietf-i2rs-yang-l3-topology-08 and draft-ietf-i2rs-yang-network-topo-10 appear to contain only configuration data nodes. They are mandatory to implement. >From RFC 7950: 7.21.1. The "config" Statement The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration are part of configuration datastores. If "config" is "false", the definition represents state data. Data nodes representing state data are not part of configuration datastores. If these nodes are not intended to be part of configuration datastores, then the nodes need to marked as "config false". > /js > > Andy > On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote: > > Juergen: > > > > Where do you think the revised data store model in that draft suggests > ephemeral data stores live? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > Sent: Wednesday, January 25, 2017 1:54 PM > > To: Susan Hares > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia > Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Sue, > > > > the current thinking is documented in > > draft-ietf-netmod-revised-datastores-00.txt. > > > > /js > > > > On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > > > Juergen: > > > > > > "And with the revised datastore model it will also be straight forwar= d > to have an implementation that just exposes topological data via the > operational state datastore. And the revised datastore model also paves > the path to support datastores that can also inject ephemeral data." > > > > > > Where do you believe the revised data store model suggest ephemeral > data can be injected - (?written)? > > > > > > Sue > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Wednesday, January 25, 2017 10:33 AM > > > To: Giles Heron > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou > > > Berger; iesg@ietf.org; Alia Atlas > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > > > > > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > > > >> > > > > >> So - if one has models - such as a writable topology - where > > > > >> there can be dependencies on dynamic data, then those models > > > > >> can't be in the configuration data-store as currently defined. > > > > >> > > > > > > > > > > Yes > > > > > > > > but isn=E2=80=99t this confusing models and implementation? > > > > > > I just confirmed that the old datastore model does not support > writable ephemeral datastores. No more no less. And there is work in NETM= OD > (and NETCONF) to revise the datastore model and to make data model reuse = in > different datastores even simpler. > > > > > > > if you have a case where you have a dependency on dynamic data then > you can=E2=80=99t put that instantiation of the model in the configuratio= n > data-store. > > > > > > > > but if your implementation never depends on dynamic data then it > ought to be fine. > > > > > > Yes. This should be fine. > > > > > > And with the revised datastore model it will also be straight forward > to have an implementation that just exposes topological data via the > operational state datastore. And the revised datastore model also paves > the path to support datastores that can also inject ephemeral data. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11404a48a2dd050546f0047d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 25, 2017 at 11:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Just search for ephemeral in the document and you will hit this:<= br>
=C2=A0 =C2=A0The model foresees control-plane datastores that are by defini= tion
=C2=A0 =C2=A0not part of the persistent configuration of a device.=C2=A0 In= some
=C2=A0 =C2=A0contexts, these have been termed ephemeral datastores since th= e
=C2=A0 =C2=A0information is ephemeral, i.e., lost upon reboot.=C2=A0 The co= ntrol-plane
=C2=A0 =C2=A0datastores interact with the rest of the system through the &l= t;applied>
=C2=A0 =C2=A0or <operational-state> datastores, depending on the type= of data they
=C2=A0 =C2=A0contain.=C2=A0 Note that the ephemeral datastore discussed in = I2RS
=C2=A0 =C2=A0documents maps to a control-plane datastore in the revised dat= astore
=C2=A0 =C2=A0model described here.




The modu= les in draft-ietf-i2rs-yang-l3-topology-08 and=C2=A0draft-ietf-i2rs-yang-ne= twork-topo-10
appear to contain only configuration data nodes. Th= ey are mandatory to implement.


From= RFC 7950:
7.21.1.  The "config" Statement

   The "config" statement takes as an argument the string "t=
rue" or
   "false".  If "config" is "true", the defin=
ition represents
   configuration.  Data nodes representing configuration are part of
   configuration datastores.

   If "config" is "false", the definition represents st=
ate data.  Data
   nodes representing state data are not part of configuration
   datastores.

If these nodes are not intended to be part = of configuration datastores,
then the nodes need to marked as &qu= ot;config false".


=C2=A0
=
/js


Andy

=C2=A0
On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote:
> Juergen:
>
> Where do you think the revised data store model in that draft suggests= ephemeral data stores live?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, January 25, 2017 1:54 PM
> To: Susan Hares
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger'
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf= -i2rs-yang-l3-topology-08: (with COMMENT)
>
> Sue,
>
> the current thinking is documented in
> draft-ietf-netmod-revised-datastores-00.txt.
>
> /js
>
> On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote:
> > Juergen:
> >
> > "And with the revised datastore model it will also be straig= ht forward to have an implementation that just exposes topological data via= the operational state datastore.=C2=A0 And the revised datastore model als= o paves the path to support datastores that can also inject ephemeral data.= "
> >
> > Where do you believe the revised data store model suggest ephemer= al data can be injected - (?written)?
> >
> > Sue
> >
> > -----Original Message-----
> > From: i2rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Wednesday, January 25, 2017 10:33 AM
> > To: Giles Heron
> > Cc: = draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou
> > Berger; iesg@ietf.org; Alia = Atlas
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >
> > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote:
> > >
> > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder <j.schoenwaelder@jacobs= -university.de> wrote:
> > > >
> > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wr= ote:
> > > >>
> > > >> So - if one has models - such as a writable topolog= y - where
> > > >> there can be dependencies on dynamic data, then tho= se models
> > > >> can't be in the configuration data-store as cur= rently defined.
> > > >>
> > > >
> > > > Yes
> > >
> > > but isn=E2=80=99t this confusing models and implementation?<= br> > >
> > I just confirmed that the old datastore model does not support wr= itable ephemeral datastores. No more no less. And there is work in NETMOD (= and NETCONF) to revise the datastore model and to make data model reuse in = different datastores even simpler.
> >
> > > if you have a case where you have a dependency on dynamic da= ta then you can=E2=80=99t put that instantiation of the model in the config= uration data-store.
> > >
> > > but if your implementation never depends on dynamic data the= n it ought to be fine.
> >
> > Yes. This should be fine.
> >
> > And with the revised datastore model it will also be straight for= ward to have an implementation that just exposes topological data via the o= perational state datastore.=C2=A0 And the revised datastore model also pave= s the path to support datastores that can also inject ephemeral data.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs<= /a>
> >
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs >

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11404a48a2dd050546f0047d-- From nobody Wed Jan 25 14:37:00 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 B13AB126BF6; Wed, 25 Jan 2017 14:36:53 -0800 (PST) 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 PZtPHlfQFSzM; Wed, 25 Jan 2017 14:36:52 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433DF1289C4; Wed, 25 Jan 2017 14:36:52 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.13.195; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> <20170125185330.GC41811@elstar.local> <01c601d2773c$fb26c1d0$f1744570$@ndzh.com> <20170125190503.GD41811@elstar.local> In-Reply-To: <20170125190503.GD41811@elstar.local> Date: Wed, 25 Jan 2017 17:32:22 -0500 Message-ID: <022301d2775a$e5fbeba0$b1f3c2e0$@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: AQDMDDOlqUr6NUq+FONL11ADZxeNCgGvnhE+AZ//NCkDIpJlDQJvvn+6AfFrv3cCLl/QqwD/niYAAbSWsOsCLG1NeKLHh2wg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 22:36:53 -0000 Juergen : OK - I agree with the document section you've quoted. Are there other = ephemeral data stores? Is and a reasonable extension of NETCONF to read/write from these = datastores?=20 Sue =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder Sent: Wednesday, January 25, 2017 2:05 PM To: Susan Hares Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia = Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Just search for ephemeral in the document and you will hit this: The model foresees control-plane datastores that are by definition not part of the persistent configuration of a device. In some contexts, these have been termed ephemeral datastores since the information is ephemeral, i.e., lost upon reboot. The control-plane datastores interact with the rest of the system through the or datastores, depending on the type of data they contain. Note that the ephemeral datastore discussed in I2RS documents maps to a control-plane datastore in the revised datastore model described here. /js On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote: > Juergen:=20 >=20 > Where do you think the revised data store model in that draft suggests = ephemeral data stores live?=20 >=20 > Sue >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Wednesday, January 25, 2017 1:54 PM > To: Susan Hares > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia = Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >=20 > Sue, >=20 > the current thinking is documented in > draft-ietf-netmod-revised-datastores-00.txt. >=20 > /js >=20 > On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > > Juergen:=20 > > =20 > > "And with the revised datastore model it will also be straight = forward to have an implementation that just exposes topological data via = the operational state datastore. And the revised datastore model also = paves the path to support datastores that can also inject ephemeral = data." > >=20 > > Where do you believe the revised data store model suggest ephemeral = data can be injected - (?written)?=20 > >=20 > > Sue > >=20 > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > > Schoenwaelder > > Sent: Wednesday, January 25, 2017 10:33 AM > > To: Giles Heron > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou=20 > > Berger; iesg@ietf.org; Alia Atlas > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > >=20 > > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > >=20 > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder = wrote: > > > >=20 > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > > >>=20 > > > >> So - if one has models - such as a writable topology - where=20 > > > >> there can be dependencies on dynamic data, then those models=20 > > > >> can't be in the configuration data-store as currently defined. > > > >>=20 > > > >=20 > > > > Yes > > >=20 > > > but isn=E2=80=99t this confusing models and implementation? > >=20 > > I just confirmed that the old datastore model does not support = writable ephemeral datastores. No more no less. And there is work in = NETMOD (and NETCONF) to revise the datastore model and to make data = model reuse in different datastores even simpler. > > =20 > > > if you have a case where you have a dependency on dynamic data = then you can=E2=80=99t put that instantiation of the model in the = configuration data-store. > > >=20 > > > but if your implementation never depends on dynamic data then it = ought to be fine. > >=20 > > Yes. This should be fine. > >=20 > > And with the revised datastore model it will also be straight = forward to have an implementation that just exposes topological data via = the operational state datastore. And the revised datastore model also = paves the path to support datastores that can also inject ephemeral = data. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jan 25 23:48:40 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 D1E561294BD; Wed, 25 Jan 2017 23:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 df2pftdjvEZ1; Wed, 25 Jan 2017 23:48:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C2D1294B8; Wed, 25 Jan 2017 23:48:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C1A5E6E7; Thu, 26 Jan 2017 08:48:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JnfkH6l2MxMY; Thu, 26 Jan 2017 08:48:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jan 2017 08:48:30 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECB90200AC; Thu, 26 Jan 2017 08:48:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Pv9vGwINWwL; Thu, 26 Jan 2017 08:48:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB681200AB; Thu, 26 Jan 2017 08:48:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 955E23E4C95C; Thu, 26 Jan 2017 08:48:32 +0100 (CET) Date: Thu, 26 Jan 2017 08:48:32 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170126074832.GA42889@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <733F61EE-456C-4F71-B7B4-D1965BDCC36C@gmail.com> <20170125153326.GH41033@elstar.jacobs.jacobs-university.de> <01b101d27733$d7826490$86872db0$@ndzh.com> <20170125185330.GC41811@elstar.local> <01c601d2773c$fb26c1d0$f1744570$@ndzh.com> <20170125190503.GD41811@elstar.local> <022301d2775a$e5fbeba0$b1f3c2e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <022301d2775a$e5fbeba0$b1f3c2e0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, 'Alia Atlas' , 'Giles Heron' , iesg@ietf.org, 'Lou Berger' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 07:48:35 -0000 It will be up to the NETCONF WG to define the name and the semantics of the operations needed. /js On Wed, Jan 25, 2017 at 05:32:22PM -0500, Susan Hares wrote: > Juergen : > > OK - I agree with the document section you've quoted. Are there other ephemeral data stores? Is and a reasonable extension of NETCONF to read/write from these datastores? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, January 25, 2017 2:05 PM > To: Susan Hares > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > Just search for ephemeral in the document and you will hit this: > > The model foresees control-plane datastores that are by definition > not part of the persistent configuration of a device. In some > contexts, these have been termed ephemeral datastores since the > information is ephemeral, i.e., lost upon reboot. The control-plane > datastores interact with the rest of the system through the > or datastores, depending on the type of data they > contain. Note that the ephemeral datastore discussed in I2RS > documents maps to a control-plane datastore in the revised datastore > model described here. > > /js > > On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote: > > Juergen: > > > > Where do you think the revised data store model in that draft suggests ephemeral data stores live? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, January 25, 2017 1:54 PM > > To: Susan Hares > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; 'Alia Atlas'; 'Giles Heron'; iesg@ietf.org; 'Lou Berger' > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Sue, > > > > the current thinking is documented in > > draft-ietf-netmod-revised-datastores-00.txt. > > > > /js > > > > On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote: > > > Juergen: > > > > > > "And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data." > > > > > > Where do you believe the revised data store model suggest ephemeral data can be injected - (?written)? > > > > > > Sue > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Wednesday, January 25, 2017 10:33 AM > > > To: Giles Heron > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; Lou > > > Berger; iesg@ietf.org; Alia Atlas > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > On Wed, Jan 25, 2017 at 03:19:58PM +0000, Giles Heron wrote: > > > > > > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder wrote: > > > > > > > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: > > > > >> > > > > >> So - if one has models - such as a writable topology - where > > > > >> there can be dependencies on dynamic data, then those models > > > > >> can't be in the configuration data-store as currently defined. > > > > >> > > > > > > > > > > Yes > > > > > > > > but isn’t this confusing models and implementation? > > > > > > I just confirmed that the old datastore model does not support writable ephemeral datastores. No more no less. And there is work in NETMOD (and NETCONF) to revise the datastore model and to make data model reuse in different datastores even simpler. > > > > > > > if you have a case where you have a dependency on dynamic data then you can’t put that instantiation of the model in the configuration data-store. > > > > > > > > but if your implementation never depends on dynamic data then it ought to be fine. > > > > > > Yes. This should be fine. > > > > > > And with the revised datastore model it will also be straight forward to have an implementation that just exposes topological data via the operational state datastore. And the revised datastore model also paves the path to support datastores that can also inject ephemeral data. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 31 15:59:15 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 06D7812967D for ; Tue, 31 Jan 2017 15:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, 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 MJSDqx2waNZB for ; Tue, 31 Jan 2017 15:59:12 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 18C9112967C for ; Tue, 31 Jan 2017 15:59:12 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id u68so52013634ywg.0 for ; Tue, 31 Jan 2017 15:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d/3swbD/qubYlt0RXbm4nuyUzd92BGFFEMrDs+ANA9g=; b=Y4uz9rtJnhDa7Lvi17jQkqLKRZq1BWNQxx1RnOa+iSfkEBf5JjOiiRVBT4y9AjYcQ6 boRMnBtYFsXBfKVpsnbYVnin9lTsx+66wvLPOlOLvFSnqIA8OpS4s/Hf2LPQXoZnLpn8 9t4hZiT9zs2n/+1q3JJoEBL1KHKp0fUww8GaqU65B9L7ptwLV75fHaqedcTXyxE9wU+6 zvTYPRuJchd494RywNTPG/V+N8sTX7RFR2t4weRK+AH3lrauzcEzYWQzV72yYaH+N/xf lqZ4V39QgTB0GfyDAjUl7s+R4GlIMgKv9gL2rChu5Dbv7pvTR+w4V8z9nr2J/fBQGfgd N1LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d/3swbD/qubYlt0RXbm4nuyUzd92BGFFEMrDs+ANA9g=; b=XbXU4Nc7v6OKxXsDz/zLs8xoQO45V3vxZTXQk9VTYqxmL6WmWN5K8zmR2eXyTwfexE P+ohL9winJC+XM3o+AcIfE0Yj4eMVEgPURa55AEqD6UURswSrLctFbGAy7LsFEIlc3a5 AB9tVjopfNnyWNtJA/ULGLlYGTdzv5Xyuorj3a/qiVKJvXMHjFW3WyljjslJUzIm52lN 8khotoiRtWY1vb75UALpKtHeqAg/sjSBUU4YAZJtz1JCTbfDP1pQJSzM1wJKaMG0ftEW T9XTHDBaDKfYwhFvFE1D+OOF60Z6QQjoNZEnR+QwpEl9z158bzXRuBK5AeS4gB4LRIJ0 e0JA== X-Gm-Message-State: AIkVDXK4h8qCbPj/ae02mtgv/373OLusaaaFijTpOa1xzJ9eKhOPuSsahSqIcePcV3xSZQqPL7OvQKSQb4UNjw== X-Received: by 10.129.118.4 with SMTP id r4mr20453290ywc.85.1485907150932; Tue, 31 Jan 2017 15:59:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Tue, 31 Jan 2017 15:59:10 -0800 (PST) From: Alia Atlas Date: Tue, 31 Jan 2017 18:59:10 -0500 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=f403045ef482e69b7b05476cb785 Archived-At: Subject: [i2rs] Handling technical concerns and progressing topology models X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 23:59:14 -0000 --f403045ef482e69b7b05476cb785 Content-Type: text/plain; charset=UTF-8 Dear I2RS Working Group, There has been significant discussion around draft-ietf-i2rs-yang- network-topo-10 as a side-effect of IESG balloting. While the focus of the IESG concerns was on having clearly written security considerations, the active discussion clearly demonstrated both different perspectives on how the model could be used and specific technical concerns that were not adequately clear in the draft or adequately handled to conform with the existing standardized YANG work. As a vital part of the IETF process, when there are valid technical concerns that haven't been addressed, it is necessary to handle them. Therefore, I am returning both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology-08 to the WG. The specific technical concern is around the model defining a 'server-provided' flag to indicate when configuration (config true) nodes actually contain and should be treated like operation state (config false) nodes, which overrides normal YANG behavior. >From discussions among the authors, NETMOD Chairs, I2RS Chairs, TEAS Chairs, and myself, the best long-term technical solution continues to be based upon use of the active work in NetMod that is draft-ietf-netmod-revised-datastores-00 . Alex Clemm and Xufeng Liu, with Pavan Beeram's and Kent Watsen's kind assistance, will be writing the details of the specific issues and use-cases and proposed solutions to send to the list in the next couple weeks. I anticipate that the draft-ietf-i2rs-yang-network-topo will have a new appendix that will describe the applicability and give examples, based upon use of the WG-selected solution. This is for clarity because it is clear that there are nuances here that are not universally understood in the WG. Both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology provide models that can be generally used. However the details of applicability are complex for a number of reasons. The model is intended for use by both routers and controllers. The data can come from different sources and the relationships between that data is an important part of that model. The particular data domain being modeled has natural complexities. A key question that I am looking to the WG to answer is what is the time-criticality of getting these drafts published soon versus when draft-ietf-netmod-revised-datastores completes (which may be a while)? If urgent, the WG may need to examine short-term solutions. Since the initial trigger for this discussion was around the Security Considerations, I know that Alex will be shortly publishing an updated draft-ietf-i2rs-yang-network-topo that is based on the existing yang security considerations recommendations (though updated to reflect multiple protocols may be used). Moving forward, as more features are available in YANG models, I expect those aspects, when used, to also potentially impact security considerations. The silence on the list since last week has been due to very active discussion trying to clarify and articulate the technical concerns and determine potential solutions. Regards, Alia --f403045ef482e69b7b05476cb785 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear I2RS Working Group,
There has been significant discussion around=C2=A0draft-ietf-i2rs-yang-networ= k-topo-10=C2=A0as a side-effect of IESG balloting.=C2=A0 While the focu= s of the IESG concerns was on having clearly written security consideration= s, the active discussion clearly demonstrated both different perspectives o= n how the model could be used and specific technical concerns that were not= adequately clear in the draft or adequately handled to conform with the ex= isting standardized YANG work.=C2=A0 As a vital part of the IETF process, w= hen there are valid technical concerns that haven't been addressed, it = is necessary to handle them.=C2=A0 Therefore, I am returning both draft-iet= f-i2rs-yang-network-topo and=C2=A0draf= t-ietf-i2rs-yang-l3-topology-08=C2=A0to the WG.

The specifi= c technical concern is around the model defining a 'server-provided'= ; flag to indicate when configuration (config true) nodes actually contain = and should be treated like operation state (config false) nodes, which over= rides normal YANG behavior.

From discus= sions among the authors, NETMOD Chairs, I2RS Chairs, TEAS Chairs, and mysel= f, the best long-term technical solution continues to be based upon use of = the active work in NetMod that is=C2=A0draft-ietf-netmod-revised-datastores= -00. =C2=A0 Alex Clemm and Xufeng Liu, with Pavan Beeram's and Kent= Watsen's kind assistance, will be writing the details of the specific = issues and use-cases and proposed solutions to send to the list in the next= couple weeks.

I anticipate that the draft-ietf-i2rs-yang-network-topo will have a new appendix that will describe the applicability and g= ive examples, based upon use of the WG-selected solution.=C2=A0 This is for= clarity because it is clear that there are nuances here that are not unive= rsally understood in the WG.=C2=A0 Both draft-ietf-i2rs-yang-network-t= opo and=C2=A0draft-ietf-i2rs-yang-l3-t= opology=C2=A0provide models that can be generally used. However the det= ails of applicability are complex for a number of reasons. The model is int= ended for use by both routers and controllers.=C2=A0 The data can come from= different sources and the relationships between that data is an important = part of that model.=C2=A0 The particular data domain being modeled has natu= ral complexities.

A key question that I= am looking to the WG to answer is what is the time-criticality of getting = these drafts published soon versus when=C2=A0draft-ietf-netmod-revised-data= stores=C2=A0completes (which may be a while)? =C2=A0 If urgent, the WG = may need to examine short-term solutions.

Since the initial trigger = for this discussion was around the Security Considerations, I know that Ale= x will be shortly publishing an updated draft-ietf-i2rs-yang-network-t= opo that is based on the existing yang security considerations recommendati= ons (though updated to reflect multiple protocols may be used).=C2=A0 Movin= g forward, as more features are available in YANG models, I expect those as= pects, when used, to also potentially impact security considerations.
The silence on the list since last week has been due to very active discu= ssion trying to clarify and articulate the technical concerns and determine= potential solutions.

Regards,
Alia
--f403045ef482e69b7b05476cb785--