Juergen: 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.
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. 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. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: Monday, January 23, 2017 2:15 PM To: Susan Hares Cc: 'Giles Heron'; [email protected]; [email protected]; 'Kathleen Moriarty'; 'The IESG'; [email protected] 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: > > 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. > > 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. > > > 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. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:[email protected]] > Sent: Monday, January 23, 2017 1:34 PM > To: Susan Hares > Cc: 'Giles Heron'; [email protected]; > [email protected]; 'Kathleen Moriarty'; 'The IESG'; [email protected] > 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: > > > > > > > > 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). > > > > > > > > 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: > > > > > > > > 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) > > > > > > > > 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. > > > > > > > > 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: > > > > > > > > “The 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. “ > > > > > > > > For the L3 topology data models (ietf-l3-unicast-topology), the paragraph > > could be: > > > > > > > > “The 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. “ > > > > > > > > > > > > Hopefully, this makes the suggestion for I2RS security policy a bit more > > concrete. > > > > > > > > Sue Hares > > > > > > > > > > > > =========================================================== > > > > > > > > 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 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=current()/+ > > > > | ../source-node]/termination-point/tp-id > > > > +--rw destination > > > > | +--rw dest-node? -> ../../../nd:node/node-id > > > > | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ > > > > | ../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=current()/../network-ref]/+ > > > > link/link-id > > > > > > > > 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=+ > > > > current()/../network-ref]/node+ > > > > [nd:node-id=current()/../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: > > > > +--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 > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Giles Heron [mailto:[email protected]] > > Sent: Monday, January 23, 2017 6:45 AM > > To: Juergen Schoenwaelder > > Cc: Susan Hares; [email protected]; > > [email protected]; Kathleen Moriarty; The IESG; [email protected] > > 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’m not sure how that fits with > > “designed for the I2RS ephemeral control plane data store” - since users > > don’t write to the models directly (making validation, priority etc. > > non-issues). > > > > > > > > > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder > > > <[email protected]> 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:[email protected]> > > >> mailto:[email protected]] > > > > >> Sent: Monday, January 23, 2017 3:39 AM > > > > >> To: Susan Hares > > > > >> Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > >> <mailto:[email protected]> > > >> [email protected]; > > >> <mailto:[email protected]> [email protected]; > > > > >> <mailto:[email protected]> [email protected] > > > > >> 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> > > >>> 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:[email protected]> > > >>> mailto:[email protected]] > > > > >>> Sent: Thursday, January 19, 2017 10:34 AM > > > > >>> To: Susan Hares > > > > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > >>> <mailto:[email protected]> > > >>> [email protected]; > > >>> <mailto:[email protected]> [email protected]; > > > > >>> <mailto:[email protected]> [email protected] > > > > >>> 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-con > > >>>> si > > >>>> der> > > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons > > >>>> id > > >>>> er > > > > >>>> / > > > > >>>> > > > > >>>> 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:[email protected]> > > >>>> mailto:[email protected]] > > > > >>>> Sent: Wednesday, January 18, 2017 9:44 PM > > > > >>>> To: The IESG > > > > >>>> Cc: <mailto:[email protected]> > > >>>> [email protected]; > > >>>> <mailto:[email protected]> [email protected]; > > > > >>>> <mailto:[email protected]> [email protected]; > > >>>> <mailto:[email protected]> [email protected]; > > >>>> <mailto:[email protected]> [email protected] > > > > >>>> 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-topol > > >>>> og > > >>>> y/> > > >>>> 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 > > > > >>>> <mailto:[email protected]> [email protected] > > > > >>>> <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/> > > > > >> > > > > > > > > > > -- > > > > > 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:[email protected]> [email protected] > > > > > <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/> > -- 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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs
