Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Lou Berger <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, January 25, 2017 7:27 AM
> To: Susan Hares
> Cc: 'Martin Bjorklund'; [e-mail];
> [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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 “<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
>
>  
>
> 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" <[e-mail]
> <mailto:[e-mail]>> 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:[e-mail]]
>
> > Sent: Tuesday, January 24, 2017 10:39 AM
>
> > To: [e-mail] <mailto:[e-mail]>
>
> > Cc: [e-mail] <mailto:[e-mail]>;
> [e-mail]
> <mailto:[e-mail]>;
>
> > [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>;
>
> > [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>;
>
> > [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>
>
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>
> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> > 
>
> > "Susan Hares" <[e-mail] <mailto:[e-mail]>> 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:[e-mail]]
>
> >> Sent: Tuesday, January 24, 2017 7:35 AM
>
> >> To: [e-mail] <mailto:[e-mail]>
>
> >> Cc: [e-mail] <mailto:[e-mail]>;
> [e-mail]
> <mailto:[e-mail]>;
>
> >> [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>;
>
> >> [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>;
>
> >> [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>
>
> >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>
> >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> >> 
>
> >> 
>
> >> 
>
> >> "Susan Hares" < <mailto:[e-mail]> [e-mail]
> <mailto:[e-mail]>> 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:[e-mail]>
>
> >> > mailto:[e-mail]]
>
> >> On Behalf Of Martin
>
> >> 
>
> >> > Bjorklund
>
> >> 
>
> >> > Sent: Monday, January 23, 2017 5:26 PM
>
> >> 
>
> >> > To:  <mailto:[e-mail]> [e-mail]
> <mailto:[e-mail]>
>
> >> 
>
> >> > Cc:  <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>;
>
> >> <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>;
>
> >> 
>
> >> >  <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>; 
> <mailto:[e-mail]>
>
> >> [e-mail] <mailto:[e-mail]>;
>
> >> 
>
> >> >  <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>;
>
> >> <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>; <mailto:[e-mail]>
>
> >> [e-mail] <mailto:[e-mail]>
>
> >> 
>
> >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>
> >> 
>
> >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> >> 
>
> >> >
>
> >> 
>
> >> > "Susan Hares" < <mailto:[e-mail]> [e-mail]
> <mailto:[e-mail]>> 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:[e-mail]> mailto:[e-mail]]
>
> >> 
>
> >> > > Sent: Monday, January 23, 2017 4:11 PM
>
> >> 
>
> >> > > To: Martin Bjorklund;  <mailto:[e-mail]> [e-mail]
> <mailto:[e-mail]>
>
> >> 
>
> >> > > Cc:  <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>;
>
> >> <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>;
>
> >> 
>
> >> > >  <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>; 
> <mailto:[e-mail]>
>
> >> [e-mail] <mailto:[e-mail]>;
>
> >> 
>
> >> > >  <mailto:[e-mail]>
>
> >> [e-mail]
> <mailto:[e-mail]>;  <mailto:[e-mail]>
>
> >> [e-mail] <mailto:[e-mail]>
>
> >> 
>
> >> > > 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:[e-mail]> [e-mail] <mailto:[e-mail]>
>
> >> 
>
> >> >  <https://www.ietf.org/mailman/listinfo/i2rs>
>
> >> https://www.ietf.org/mailman/listinfo/i2rs
>
> >> 
>
> >> >
>
> >> 
>
> > 
>
> > 
>
>  
>