Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-10

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Aug 2013 22:09:12 +0200 (CEST)

Hi,

I noticed that several of the configuraiton nodes are also reflected
in as operational state.  For example, there is:

   +--rw routing
      +--rw router* [name]
      |  +--rw interfaces
      |  |  +--rw interface* [name]
      |  |     +--rw v6ur:ipv6-router-advertisements
      |  |        +--rw v6ur:send-advertisements?    boolean

and

   +--ro routing-state
      +--ro router* [name]
      |  +--ro interfaces
      |  |  +--ro interface* [name]
      |  |     +--ro v6ur:ipv6-router-advertisements
      |  |        +--ro v6ur:send-advertisements?    boolean

Only the config false node has a reference to 

          "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
           AdvSendAdvertisements.";

But in 4861, AdvSendAdvertisements is listed as a Configuration
Variable.  So it seems to me that the reference should be on the
config node, not on the state node.  But I think that the config false
nodes in this case should be removed, since they would always reflect
the configured value 1-1.

In general, I think the description of the config false nodes should
indicate if it just reflects the configured value nor not.

Also, in some cases, the description of the config true node is less
descriptive than the config false node.  For example, list
route-filter.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Aug 2013 09:55:47 +0200

>       |  |        +--ro v6ur:send-advertisements?    boolean

Yes, this is is a good point, and I spent quite some time thinking about it before submitting -10.

> Variable.  So it seems to me that the reference should be on the

Right, but it doesn't say that it can be configured exclusively via NETCONF.

> the configured value 1-1.

I am not sure about this. I can imagine, for example, that an I2RS agent might want to stop the advertisements on its own.

> indicate if it just reflects the configured value nor not.

This is another interesting dilemma. In my view, the operational state node is the "real" parameter (or at least closer to it), and the config node is only a "proposal" of a NETCONF client, which the server needn't accept, or which may be overriden by other means.

>From this viewpoint, it makes more sense to bundle the descriptions and references with the state node because it is where any constraints really matter. All configuration interfaces (including NETCONF) that attempt to set the parameter have to follow these rules.

Lada  

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Aug 2013 07:42:51 -0700

> Right, but it doesn't say that it can be configured exclusively via NETCONF.

I don't think we should create data models for protocols that don't exist,
or unspecified proprietary mechanisms. We should avoid duplicate objects.
If there is little or no chance the operational values will be different,
then the operational duplicates should be removed.

> I am not sure about this. I can imagine, for example, that an I2RS agent might want to stop the advertisements on its own.

We should not speculate what I2RS will want.
Only NETCONF should be considered at this time.

> From this viewpoint, it makes more sense to bundle the descriptions and references with the state node because it is where any constraints really matter. All configuration interfaces (including NET…

IMO we have designed NETCONF/YANG so the constraints
are placed on config=true objects, because this is what clients
can control.

>> descriptive than the config false node.  For example, list

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Aug 2013 16:52:35 +0200 (CEST)

> then the operational duplicates should be removed.

+1

Further, I think it is not correct to think that the configuration
datastore that is manipulated via NETCONF is unique to NETCONF.
NETCONF is designed to be an interface to the device's configuration
datastore, and there may be other interfaces (CLI, SNMP, WebUI,
REST, ...) to the same datastore.  The YANG model is a concrete data
model of this datastore, that works for NETCONF.

> > I am not sure about this. I can imagine, for example, that an I2RS agent
> > might want to stop the advertisements on its own.
> 

Right, and it is easier to add these objects in the future, if
necessary, than to remove them if they turned out to be unnecessary.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Aug 2013 08:08:00 -0700

....
>...

This is really important because we are not following this design
in our standards, just in our code.  For example, NACM is written
to only provide access control for NETCONF, but of course we use
it for all protocol access to YANG content because that is what
customers expect.  The netconf monitoring module says session ID 0 is
for external sessions.  In implementation, it makes more sense
to assign every session a real ID and keep track of the protocol.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Aug 2013 17:44:38 +0200

>> then the operational duplicates should be removed.

How can you tell that there is little or no chance?

Let's take the "forwarding" flags in the "ietf-ip" module. I am now inclined to assume that your plan is to have them only as configuration nodes. However, on a Linux system that gives access to a standard shell, the user can always do, for example,

$ echo 1 > /proc/sys/net/ipv4/ip_forward

and make the operational value different from what's in "running". So, if the node is not in the -state tree, the NETCONF client has no chance to learn the value that the device is really using.  

> model of this datastore, that works for NETCONF.

Interfaces that bypass NETCONF do exist, and I2RS is going to be one of them. IMO we would be better off if we come up with a model allowing peaceful coexistence of NETCONF with other independent configuration interfaces.

There is also a big difference between closed devices where the vendor has full control of all the gates to the silo, and open systems where the power is on the user's side.
 
> necessary, than to remove them if they turned out to be unnecessary.

Following the action point from Berlin, the routing module should be aligned, as much as possible, with the needs of the I2RS WG.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Aug 2013 23:34:16 +0200 (CEST)

> How can you tell that there is little or no chance?

This will have to be done on a case-by-case basis.

> Let's take the "forwarding" flags in the "ietf-ip" module. I am now inclined to
> assume that your plan is to have them only as configuration nodes. However, on
> a Linux system that gives access to a standard shell, the user can always do,
> for example,
> 
> and make the operational value different from what's in "running".

In this particular case I think it makes sense to also reflect this in
the operational state.

> So, if the
> node is not in the -state tree, the NETCONF client has no chance to learn the
> value that the device is really using.

Right, but taking this to the extreme, we'd have to duplicate almost
everything in all configuration models.  As one example, it seems
unlikely that the NACM data should be modified by anything but through
the configuration.

> Interfaces that bypass NETCONF do exist, and I2RS is going to be one of
> them.

Well, I2RS is not a configuration interface.

> IMO we would be better off if we come up with a model allowing peaceful
> coexistence of NETCONF with other independent configuration interfaces.

Yes... that's what I wrote above.  There are other interfaces to the
configuration datastores than just NETCONF.

> There is also a big difference between closed devices where the vendor has full
> control of all the gates to the silo, and open systems where the power is on
> the user's side.

If you add NETCONF to an (open) linux host, your implementation will
have to interact with whatever ways there are to configure the
different subsystems, often plain config files with varying syntax.
It won't work if your implementation had its own 'running' datastore
separate from the config files of the system.

> Following the action point from Berlin, the routing module should be aligned,
> as much as possible, with the needs of the I2RS WG.

I support this, of course.  But do we know at this stage if I2RS has
requirements to modify these particular objects?  I.e.,
send-advertisements etc.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Aug 2013 08:44:13 +0200

On Wed, Aug 14, 2013 at 05:44:38PM +0200, Ladislav Lhotka wrote:
> 
> Following the action point from Berlin, the routing module should be
> aligned, as much as possible, with the needs of the I2RS WG.

My understanding is that there is an action item to figure out what
the differences are (if any) between "our" routing data model and the
proposed I2RS information model. Part of the exercise is to make sure
that players in both WGs take a detailed look at the other WGs work so
we can take informed decisions.

I do not think we decided that "the routing module should be aligned,
as much as possible, with the needs of the I2RS WG" because this
essentially means to wait until I2RS is finished. Instead, we give
this activity a timeout that will expire at the Vancouver meeting.

/js

-- 
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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Aug 2013 09:09:39 +0200

> This will have to be done on a case-by-case basis.

The result may differ from one implementation to another.

> In this particular case I think it makes sense to also reflect this in

Yes, and an additional benefit is that you get all info about interface state from one place.

> everything in all configuration models.  As one example, it seems

I agree it is not particularly elegant, but so far no solid shortcut has been proposed.

> unlikely that the NACM data should be modified by anything but through

Yes, but NACM is quite special in that it is related only to NETCONF stuff.

> Well, I2RS is not a configuration interface.

The point is that is can change the state so that it doesn't reflect what has been configured. For instance, a configured static route may not be present in the routing table.

> configuration datastores than just NETCONF.

But you assume that they all operate on a datastore that essentially is NETCONF's running. The problem with this is that running can be locked. IMO, the common playground should be "writable operational state", i.e. a conceptual datastore that cannot be locked and always reflects operational state 1:1 - like the /proc filesystem.

> separate from the config files of the system.

True, that's why it is rather difficult - you have to rewrite all the daemons.

> requirements to modify these particular objects?  I.e.,

Jan promised they would review the routing model and say where it doesn't match I2RS requirements. One case that I've already heard about is the "recursive next hop" - I understand it runs into the limitation that YANG cannot model recursive structures.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Aug 2013 13:30:38 +0200

> this activity a timeout that will expire at the Vancouver meeting.

Of course. We need to identify places where our routing model cannot be augmented to suit I2RS needs, due to either its current design or limitations in YANG. I hope the *needs* can be formulated soon.

Lada

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 16:12:28 +0000

Inline as [Alia]

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Thursday, August 15, 2013 7:31 AM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10

[Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is finished.  I do think that the routing model and the RIB info-model are trying to support different things.  It may make sense that the routing model has higher abstractions, does different or additional configuration, and so on.  That said, I do think the RIB info-model draft is fairly accurate in describing what is needed for the RIB - and that can support a wide range of static routes.  However, in routing, usually there are higher level abstractions that are applied for accuracy and ease; one can put an MPLS label on an outgoing packet - but this is frequently modeled as going into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on.

[Alia] What would be very interesting is the work that it sounds like Lada is already doing - investigating if there are missing features in YANG to support the types of info-models that I2RS
is working on producing.  At some point soon, I2RS will need to look at the requirements on data-modeling languages and understanding what is easy and hard to do in YANG and others.

Alia

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Aug 2013 13:44:05 +0200

Hi Alia,

Alia Atlas <[email-masked]> writes:

> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is finished.  I do think that the routing model and the RIB info-model are trying to support different things.  It may make sense that the routing model has higher abstractions, does different or additional configuration, and so on.  That said, I

Yes, NETCONF has configuration data that are not of direct interest to I2RS. On the other hand, the I2RS data store could IMO be pretty much the same as the operational state data in NETCONF (config false in YANG terms) - except that (parts of) it will be read-write for I2RS, whereas for NETCONF it will be by definition read-only. This could include routing tables, protocol databases etc.

> do think the RIB info-model draft is fairly accurate in describing what is needed for the RIB - and that can support a wide range of static routes.  However, in routing, usually there are higher level abstractions that are applied for accuracy and ease; one can put an MPLS label on an outgoing packet - but this is frequently modeled as going into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on.
>

I haven't started such an investigation yet but I am prepared to do so.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Aug 2013 10:23:20 +0200

> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is finished.  I do think that the routing model and the RIB info-model are trying to support different things.  It may make sen…

Alia, I think basic concepts and terminology should be aligned between
a standard routing configuration interface and a standard routing
state manipulation interface. I surely expect that the I2RS info model
goes beyond what we have in NETMOD but for the core bits and pieces
(basic concepts and in particular also terminology), I think the
industry will benefit if things turn out to be reasonably consistent.
I hope by Vancouver we are in a situation where basic concepts and
terminology have already started to converge. This would be great.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Aug 2013 10:37:11 +0200

+1

Lada

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Tue, 20 Aug 2013 00:41:27 +0000

On 8/16/13 4:44 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS
>>is finished.  I do think that the routing model and the RIB info-model
>>are trying to support different things.  It may make sense that the
>>routing model has higher abstractions, does different or additional
>>configuration, and so on.  That said, I
>
>Yes, NETCONF has configuration data that are not of direct interest to
>I2RS. On the other hand, the I2RS data store could IMO be pretty much the
>same as the operational state data in NETCONF (config false in YANG
>terms) - except that (parts of) it will be read-write for I2RS, whereas
>for NETCONF it will be by definition read-only. This could include
>routing tables, protocol databases etc.

I like the idea. Maybe we could define an 'access-rights' statement that
would determine whether a data node (or a subtree) is read-only or
read-write. 

A similar approach has been proposed by Rex Fernando et. al in
http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.4,
where they defined an 'ephemeral statement to address the same problem.

>
>> do think the RIB info-model draft is fairly accurate in describing what
>>is needed for the RIB - and that can support a wide range of static
>>routes.  However, in routing, usually there are higher level
>>abstractions that are applied for accuracy and ease; one can put an MPLS
>>label on an outgoing packet - but this is frequently modeled as going
>>into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on.
>>
>> [Alia] What would be very interesting is the work that it sounds like
>>Lada is already doing - investigating if there are missing features in
>>YANG to support the types of info-models that I2RS
>> is working on producing.  At some point soon, I2RS will need to look at
>>the requirements on data-modeling languages and understanding what is
>>easy and hard to do in YANG and others.
>

Some of this work has been done - please see
http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00.

Thanks,
Jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 20 Aug 2013 10:34:08 +0200

> would determine whether a data node (or a subtree) is read-only or

Yes, a simple YANG extension would do.
 
> where they defined an 'ephemeral statement to address the same problem.

Right, writable operational state data should probably be ephemeral by definition.

> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00.

We had a short meeting with the authors in Orlando, but a broader discussion (perhaps in the NETMOD mailing list) might be useful.

Ahoj, Lada

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Tue, 20 Aug 2013 22:55:06 +0000

Hello Lada,

Apart from the ability to write ephemeral data, I2RS also has a
requirement to associate client ownership to data injected by an external
client. In NETCONF, the stores are global.

I don't want to divert this discussion. Perhaps we should start another
thread on the draft:
http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00 ?

+Alex Clemm as well.

Thanks
- muthuu

On 8/20/13 1:34 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>We had a short meeting with the authors in Orlando, but a broader
>discussion (perhaps in the NETMOD mailing list) might be useful.
>
>Ahoj, Lada
>
>>
>>
>>
>> Thanks,
>> Jan
>>
>>>
>>>Lada
>>>
>>>>
>>>> Alia
>>>>
>>>>
>>>
>>>--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Aug 2013 06:49:57 +0200

> client. In NETCONF, the stores are global.

Well, this sounds like a NETCONF requirement, not a YANG requirement.

/js

---

From: David Harrington <[email-masked]>
Date: Wed, 21 Aug 2013 11:50:32 -0400

Hi,

I have some questions about this requirement to associate client ownership
to injected data.

1) at what level of detail is the data ownership?
Are we talking about specific subtrees in the datastore, or a complete
datastore (e.g., a variation on candidate)?
If we are talking ownership of a datastore, then this would seem to be a
netconf requirement.
If we are talking ownership of a row in a routing table, or something
similar, then the ownership probably needs to be part of the data model,
comparable to OwnerStrings in the MIB.

2) Can a client only assert their own ownership of a data subset, or can
they assert that somebody else is the owner?
For example, if an operator determines that a static route should be added
to a routing table, based on looking at the hosts file of another node,
can the operator set the ownership to be a URL to that file, or MUST the
ownership be the ID for the user/operator who is setting the information?

3) If #2 requires the client-as-owner, must the client ID be
authenticated? If the proposal uses NACM to perform the authentication,
then you would presumably create a binding between the ACM mechanism
(e.g., NACM) and the specific data model.

4) There has been discussion of trying to make YANG protocol independent.
To maintain such independence, would the data model need to be written
such that the user/client ID is protocol-independent? Could any ACM model
be used to provide the user identity and authentication, not just NACM
(and not just Netconf)? Compare for example, the ability for SNMPv3 to use
multiple co-existing security models. Is this the direction this proposal
would require?

--
David Harrington
[email-masked]
+1-603-828-1401

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Thu, 22 Aug 2013 16:57:45 +0000

Hello David,

Please see inline:

>comparable to OwnerStrings in the MIB.

The ownership is on a specific sub-tree and this is why we needed data
model 
to express it.
>they assert that somebody else is the owner?

Every subset created in runtime has an ownership tagged to it. Now, the
client that created the data is the owner. If this data model states that
the data subset is 'exclusive', then only the owner can modify or delete
that subset. Else other clients can get read-write access to that any
instance of the data sub-set created by another client.

>ownership be the ID for the user/operator who is setting the information?

As defined currently, it is the ID of the user/operator.

>(e.g., NACM) and the specific data model.

Yes, the intent was to tie NACM to do the authentication.

>multiple co-existing security models. Is this the direction this proposal

Any ACM should do. It was just easier to extend NACM group settings to add
a client priority.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Aug 2013 19:37:34 +0200

> As defined currently, it is the ID of the user/operator.

I am confused. Lets see. If an I2RS client creates a 'foo' in
operational state, then I think you want 'foo' associated with the
identifier 'joe' representing the identity of the client. Is that
automatic (the mere fact that the client authenticated as 'joe' means
'foo' belongs to 'joe') or do you want 'joe' to be explicit, that
is joe actually says "create 'foo' owned by 'joe'"?

> Yes, the intent was to tie NACM to do the authentication.

I am confused. NACM does authorization, not authentication. If you
want to restrict access to 'foo' to 'joe', NACM would need a rule that
says access to 'foo' is restricted to 'joe'. Depending on the answer
to 2), the question is how the rule is being injected into NACM (if
you were to use NACM and NACM would apply to writable operational
state). But then, NACM - as far as I understand it - can only perform
access decisions on data that is explicit in the data model. I am
actually not sure you want to 'clutter' all your data models with
additional leafs to express ownership - this really smells much more
like meta-data.

> Any ACM should do. It was just easier to extend NACM group settings to add

Hm. It might be good to work out a more detailed example of what I2RS
may want. Or can someone point to the parts of the architecture I-D
where this is clearly described?

/js

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Aug 2013 18:13:59 +0000

Hi Juergen,

I agree that the ownership of data seems more like meta-data to me than anything else.  I really would prefer not to clutter the data-models with it.

I think there are two (at least!) separate aspects that we need to figure out.  One is the permissions aspect - where we need to be able to clearly express what scope a particular role has.  The second is what an i2rs agent needs to store, manipulate, and report back.

For the latter, the basic concept is described in draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which discusses identity).  In Sec 5.2, it says:

   "The I2RS agent stores the set of
   operations it has applied.  Simply, the I2RS agent stores who did
   what operation to which entity.  New changes replace any data about
   old ones.  If an I2RS client does an operation to remove some state,
   that state is removed and the I2RS agent stores no more information
   about it.  This allows any interested party to determine what the
   current effect of I2RS on the system is, and why.  Meaningful logging
   is also recommended."

Alia

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 1:38 PM
To: Muthumayan Madhayyan (muthu)
Cc: David Harrington; [email-masked]; Nitin Bahadur; Alia Atlas; [email-masked]
Subject: Re: i2rs client ownership

On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) wrote:
> >I have some questions about this requirement to associate client 
> >ownership to injected data.
> >
> >Are we talking about specific subtrees in the datastore, or a 
> >complete datastore (e.g., a variation on candidate)?
> >If we are talking ownership of a datastore, then this would seem to 
> >be a netconf requirement.
> >similar, then the ownership probably needs to be part of the data 
> >model, comparable to OwnerStrings in the MIB.
> 
> model to express it.
> >2) Can a client only assert their own ownership of a data subset, or 
> >can they assert that somebody else is the owner?
> 
> 
> Every subset created in runtime has an ownership tagged to it. Now, 
> the client that created the data is the owner. If this data model 
> states that the data subset is 'exclusive', then only the owner can 
> modify or delete that subset. Else other clients can get read-write 
> access to that any instance of the data sub-set created by another client.
> 
> 
> >For example, if an operator determines that a static route should be 
> >added to a routing table, based on looking at the hosts file of 
> >another node, can the operator set the ownership to be a URL to that 
> >file, or MUST the ownership be the ID for the user/operator who is setting the information?
> 

I am confused. Lets see. If an I2RS client creates a 'foo' in operational state, then I think you want 'foo' associated with the identifier 'joe' representing the identity of the client. Is that automatic (the mere fact that the client authenticated as 'joe' means 'foo' belongs to 'joe') or do you want 'joe' to be explicit, that is joe actually says "create 'foo' owned by 'joe'"?

> >authenticated? If the proposal uses NACM to perform the 
> >authentication, then you would presumably create a binding between 
> >the ACM mechanism (e.g., NACM) and the specific data model.
> 

I am confused. NACM does authorization, not authentication. If you want to restrict access to 'foo' to 'joe', NACM would need a rule that says access to 'foo' is restricted to 'joe'. Depending on the answer to 2), the question is how the rule is being injected into NACM (if you were to use NACM and NACM would apply to writable operational state). But then, NACM - as far as I understand it - can only perform access decisions on data that is explicit in the data model. I am actually not sure you want to 'clutter' all your data models with additional leafs to express ownership - this really smells much more like meta-data.

> >To maintain such independence, would the data model need to be 
> >written such that the user/client ID is protocol-independent? Could 
> >any ACM model be used to provide the user identity and 
> >authentication, not just NACM (and not just Netconf)? Compare for 
> >example, the ability for SNMPv3 to use multiple co-existing security 
> >models. Is this the direction this proposal would require?
> 
> Any ACM should do. It was just easier to extend NACM group settings to 
> add a client priority.

Hm. It might be good to work out a more detailed example of what I2RS may want. Or can someone point to the parts of the architecture I-D where this is clearly described?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Aug 2013 20:48:02 +0200

On Thu, Aug 22, 2013 at 06:13:59PM +0000, Alia Atlas wrote:
> I think there are two (at least!) separate aspects that we need to figure out.  One is the permissions aspect - where we need to be able to clearly express what scope a particular role has.  

As defined in section 3.3.5 of RFC 6536, NACM has four types of access
control rules:

   module rule:  controls access for definitions in a specific YANG
      module, identified by its name.

   protocol operation rule:  controls access for a specific protocol
      operation, identified by its YANG module and name.

   data node rule:  controls access for a specific data node, identified
      by its path location within the conceptual XML document for the
      data node.

   notification rule:  controls access for a specific notification event
      type, identified by its YANG module and name.

What I hear you saying is that I2RS likes to have access control rules
based on the concept of 'ownership' of data (where a client creating a
piece of data implicitely gets the ownership over that piece of data).
If this is what I2RS indeed requires, I would say NACM does not yet
provide this and in general NETCONF does not provide a clean means to
deal with such metadata (although there seem to be proposals and
running code out there).

> The second is what an i2rs agent needs to store, manipulate, and report back.
>

Yep, but this thread is about ownership and permissions. And section
3.4 of the I2RS architecture could perhaps be a bit more explicit
concering state ownership and authorization.

/js

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 22 Aug 2013 21:08:42 +0000

Hi Alia,

On 8/22/13 11:13 AM, "Alia Atlas" <[email-masked]> wrote:

>Hi Juergen,
>
>I agree that the ownership of data seems more like meta-data to me than
>anything else.  I really would prefer not to clutter the data-models with
>it.

It depends. If ownership is coarse grained, then having the ownership
metadata in a separate tree is manageable. If it's fine-grained, having
the ownership metadata embedded in the data tree is easier - both for the
server as well as for the clients.

I think with I2RS, ownership will likely be fine-grained.

>
>I think there are two (at least!) separate aspects that we need to figure
>out.  One is the permissions aspect - where we need to be able to clearly
>express what scope a particular role has.

Agreed. 

>For the latter, the basic concept is described in
>draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which
>discusses identity).  In Sec 5.2, it says:
>

/Jan

>I am confused. Lets see. If an I2RS client creates a 'foo' in operational
>state, then I think you want 'foo' associated with the identifier 'joe'
>representing the identity of the client. Is that automatic (the mere fact
>that the client authenticated as 'joe' means 'foo' belongs to 'joe') or
>do you want 'joe' to be explicit, that is joe actually says "create 'foo'
>owned by 'joe'"?
>
>I am confused. NACM does authorization, not authentication. If you want
>to restrict access to 'foo' to 'joe', NACM would need a rule that says
>access to 'foo' is restricted to 'joe'. Depending on the answer to 2),
>the question is how the rule is being injected into NACM (if you were to
>use NACM and NACM would apply to writable operational state). But then,
>NACM - as far as I understand it - can only perform access decisions on
>data that is explicit in the data model. I am actually not sure you want
>to 'clutter' all your data models with additional leafs to express
>ownership - this really smells much more like meta-data.
>
>Hm. It might be good to work out a more detailed example of what I2RS may
>want. Or can someone point to the parts of the architecture I-D where
>this is clearly described?
>
>/js
>
>--

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Aug 2013 15:36:15 -0700

> I think with I2RS, ownership will likely be fine-grained.

I think this "owner" concept needs a lot more work.
If owner 1 has a higher priority than owner 2, then owner 1 can clobber
anything that owner 2 already created.  That doesn't sound fine-grained
to me.

The "first one wins" concept only applies to clients with the same priority.
The "last one wins" problem is addressed by assigning priorities to the clients.
Now it is "highest priority wins" which is what is desired.

If the client writing existing data has the same or lower priority as the owner
that set the data, then the access is denied.  (Problem solved, first one wins).
NACM would need some changes to support owner priority.
The augments that has been proposed is insufficient:
http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6

(IMO, only sec. 3.6 of this draft is needed.)

>>   current effect of I2RS on the system is, and why.  Meaningful logging

If a client is really a broker, then is the owner string going to be for the
upstream application or the broker?  Which clients are likely to
have the same priority and collide on the same data?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Aug 2013 07:25:42 -0700

+1

The owner is a property of the datastore, not the data model.
Ditto for the "ephemeral" YANG extension.  I don't see the need
for any YANG extensions, just protocol extensions.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 24 Aug 2013 05:31:34 -0400

For me, "ownership" of data is not a helpful way to think about this. 
(It is not incorrect, just unhelpful.)

Rather, the base concept is that two different clients should not be 
writing the same data in the same time period.  (i.e. from when the 
first one writes it until he removes his modification.)

When this fails, it is an error.
We need to detect this error.
So the I2RS Agent is required to keep track of enough information to 
detect and provide a predictable behavior in the event this occurs.
The priority mechanism is a mechanism for providing better 
predictability.  If we don't like it, we can ditch it.

In particular, one corrollary of this is that "ownership" does not, it 
seems to me, belong in the data model.  It is, as Alia and other said, 
metadata.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Sat, 24 Aug 2013 07:44:48 -0700

On Sat, Aug 24, 2013 at 2:31 AM, Joel M. Halpern <[email-masked]> wrote:
> For me, "ownership" of data is not a helpful way to think about this. (It is
> not incorrect, just unhelpful.)
>
> Rather, the base concept is that two different clients should not be writing
> the same data in the same time period.  (i.e. from when the first one writes
> it until he removes his modification.)
>

I am confused.  This implies that the clients are coordinated, but that
is clearly out of scope.  Do you mean 2 clients with the same priority?
The particular data model will have some "collision scope" which could
be 1 of [row, multiple rows, table, container, ad-hoc].  It seems very
likely that
2 clients could collide, especially if the scope was wider than per-row.

A low-priority client that gets over-written by a higher priority client will
get a notification that the data was deleted.

A low-priority client that attempts to over-write a same or higher priority
client will get an error response that the data was inserted.

> So the I2RS Agent is required to keep track of enough information to detect
> and provide a predictable behavior in the event this occurs.
> The priority mechanism is a mechanism for providing better predictability.
> If we don't like it, we can ditch it.
>
> In particular, one corrollary of this is that "ownership" does not, it seems
> to me, belong in the data model.  It is, as Alia and other said, metadata.
>

A YANG extension could be used if there was concern that maintaining
owner meta-data is too expensive for every resource, and only certain data
needs to maintain it. IMO this is not needed.

Andy

>>>>   The second is what an i2rs agent needs to store, manipulate, and
>>>> report
>>>> back.
>>>>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 26 Aug 2013 03:23:53 +0000

>first one writes it until he removes his modification.)

This is necessary, but not sufficient. If we allow multiple clients
(actually, identities, since the same identity can cover multiple clients)
to change state programmatically, we must allow for mechanisms for
programmatic state validation and troubleshooting.

For example, when there is a failover between a redundant pair of clients,
the newly active client instance must perform state synchronization, which
includes reading all the state that the previously active instance of the
client injected into the system. Therefore, the agent needs to know which
client injected which state into system (if the agent does not do that, we
need an external entity, such as the controller, to keep track of this).

Similarly for troubleshooting - when, for example, an operator wants to
purge state of a client that is/should not be active anymore, the system
should facilitate this action. A state purge for a client could happen,
for example, when an operator wants to shut down an application.

>predictability.  If we don't like it, we can ditch it.

Priority is useful - no reason to ditch it. But it is not sufficient :-)

>seems to me, belong in the data model.  It is, as Alia and other said,

Yes, it is metadata. But it would be premature to exclude the option to
provide metadata along with the data - there are plenty of systems out
there that implement this concept and work quite well.

Thanks,
Jan

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Mon, 26 Aug 2013 05:28:07 +0000

On 8/22/13 10:37 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>>can
>>added

i2rs at the time of writing had 'foo' belongs to 'joe' type of requirement
. So, assuming you have a global operational table, each row could be
potentially owned by different clients.

>I am confused. NACM does authorization, not authentication.

That is true. NACM RFC talks about use of RADIUS for authentication and
mapping users to user-groups. We could adopt the same or better approach
for i2rs.

> If you

NACM is used for mainly for specifying a relative priority for a
user-group. The reason for those additional ownership leaf objects is not
such much for the 'write'. During write, the owner field is actually
meta-data. But then there is a 'read' aspect as well. Any client should be
able to access data that was created by some other client. Client A wants
to know about routes injected by another Client B or C.

>>add

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Mon, 26 Aug 2013 05:40:23 +0000

>for any YANG extensions, just protocol extensions.

There is no central 'datastore' for those schema nodes marked ephemeral.
The i2rs client directly talks to an i2rs server that does not provide any
form of storage, but relays all requests to relevant backend applications
with adequate metadata like client identification and relative priority
etc to the backend. All data injected by i2rs clients are maintained by
the backend i2rs applications. In that sense this deviates a lot from
traditional NETCONF datastore. Hope that explains why an 'ephemeral'
extension is needed.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Aug 2013 10:06:35 +0200

> traditional NETCONF datastore. Hope that explains why an 'ephemeral'

I think we have to be careful with terminology because YANG is defined for the specific NETCONF context. My understanding is that the "I2RS data store" is (a subset of) operational state data in NETCONF/YANG terms, which are by definition read-only - but only for the NETCONF protocol! There can be (and usually are) other means for for changing directly the underlying parameters and structures, and I2RS will be one of them.

So, if YANG was to be used as the data modelling language for I2RS data, it IMO means that:

1. The YANG "config" statement is irrelevant because everything is essentially "config false".

2. A flag is needed to indicate the data that can be written by I2RS clients. A YANG extension can be used for this purpose.

3. The ownership information has to be managed by I2RS backend applications. There is no need to deal with it in the data model, and it is up to the I2RS protocol to define a way for attaching the ownership info to the data sent to the client (if it is needed).

Also, I understand that all changes performed by I2RS clients are ephemeral, so isn't the distinction really between read-only and read-write?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Aug 2013 07:13:19 -0700

> to know about routes injected by another Client B or C.

This seems like a security hole.
It may be be a good idea for all data to be readable
by all other clients.

There are ways to include meta-data in protocol responses.

Unless a router needs the owner name "fred" to forward packets,
then the owner name is not part of the routing table entry data.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Aug 2013 07:24:38 -0700

> traditional NETCONF datastore. Hope that explains why an 'ephemeral'

The datastore is conceptual  -- it is just an abstraction for the API.
None of the NETCONF datastores are required to be implemented
as a centralized tree.  All NETCONF 'running' datastore contents
have "back-end" components that translate the API data into
device behavior -- it is exactly the same for I2RS (except the
dynamic datastore has different ownership and validation requirements).

Andy

---

From: Alia Atlas <[email-masked]>
Date: Mon, 26 Aug 2013 11:08:44 -0400

On Mon, Aug 19, 2013 at 4:23 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Of course. We need to identify places where our routing model cannot be
> augmented to suit I2RS needs, due to either its current design or
> limitations in YANG. I hope the *needs* can be formulated soon.
> >
> > [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is
> finished.  I do think that the routing model and the RIB info-model are
> trying to support different things.  It may make sense that the routing
> model has higher abstractions, does different or additional configuration,
> and so on.  That said, I do think the RIB info-model draft is fairly
> accurate in describing what is needed for the RIB - and that can support a
> wide range of static routes.  However, in routing, usually there are higher
> level abstractions that are applied for accuracy and ease; one can put an
> MPLS label on an outgoing packet - but this is frequently modeled as going
> Juergen,

I agree that basic concepts and terminology should be aligned.  For the
RIB, many other routing concepts and abstractions are built on top of it
and it isn't usually exposed as such at the management interface.  For
instance, the RIB info model has the next-hop chains which are ways of
imposing additional headers and specifying their details.  At the network
management layer, those would be exposed as tunnels.  For different
routing, they might be exposed as MPLS out-segments, or LSPs or MPLS
tunnels.  Another example is the ability to specify load-balancing amounts
per next-hop.  At the management interface and for routing protocols,
multiple next-hops can be specified, but an even distribution of traffic
across the next-hops is assumed.   Different hardware may have different
ranges and precision for load-balancing.

So - I agree that converging common basic concepts and terminology is very
good.  I'm just concerned that the multiple abstractions built on top of
the RIB are not as clear in part because the initial focus for the YANG
routing model is on static routes.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 26 Aug 2013 11:12:46 -0400

> dynamic datastore has different ownership and validation requirements).

For what it's worth, I've been picturing that the I2RS agent stores the
ownership information and other I2RS-specific meta-data.  What is written
and read is pushed into the "back-end" components.  But I think this is
basically an implementation decision.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 26 Aug 2013 15:46:06 +0000

-----Original Message-----
From: Jan Medved (jmedved) [mailto:[email-masked]] 
Sent: Sunday, August 25, 2013 11:24 PM
To: Joel M. Halpern; Andy Bierman
Cc: [email-masked]; Nitin Bahadur; Alia Atlas; [email-masked]
Subject: Re: [netmod] i2rs client ownership

>first one writes it until he removes his modification.)

This is necessary, but not sufficient. If we allow multiple clients (actually, identities, since the same identity can cover multiple clients) to change state programmatically, we must allow for mechanisms for programmatic state validation and troubleshooting.

For example, when there is a failover between a redundant pair of clients, the newly active client instance must perform state synchronization, which includes reading all the state that the previously active instance of the client injected into the system. Therefore, the agent needs to know which client injected which state into system (if the agent does not do that, we need an external entity, such as the controller, to keep track of this).

[Alia] As Joel said, I don't think that the I2RS agent can or should be the only means of communication or coordination between the redundant pair of clients.  However, given that keeping client ownership information is needed anyway, this would be one way to learn this information.

Similarly for troubleshooting - when, for example, an operator wants to purge state of a client that is/should not be active anymore, the system should facilitate this action. A state purge for a client could happen, for example, when an operator wants to shut down an application.

[Alia] Absolutely - this is another good use-case for the ownership information.

Alia

>seems to me, belong in the data model.  It is, as Alia and other said, 

Yes, it is metadata. But it would be premature to exclude the option to provide metadata along with the data - there are plenty of systems out there that implement this concept and work quite well.

Thanks,
Jan

>>>> I agree that the ownership of data seems more like meta-data to me 
>>>>than  anything else.  I really would prefer not to clutter the 
>>>>data-models with  it.
>>>
>>> It depends. If ownership is coarse grained, then having the 
>>>ownership  metadata in a separate tree is manageable. If it's 
>>>fine-grained, having  the ownership metadata embedded in the data 
>>>tree is easier - both for the  server as well as for the clients.
>>>
>> If owner 1 has a higher priority than owner 2, then owner 1 can 
>> clobber anything that owner 2 already created.  That doesn't sound 
>> fine-grained to me.
>>
>> If the client writing existing data has the same or lower priority as 
>>the owner  that set the data, then the access is denied.  (Problem 
>>solved, first one wins).
>>>> I think there are two (at least!) separate aspects that we need to 
>>>>figure  out.  One is the permissions aspect - where we need to be 
>>>>able to clearly  express what scope a particular role has.
>>>
>>> Agreed.
>>>
>>>>report  back.
>>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 
>>>>(which  discusses identity).  In Sec 5.2, it says:
>>>>
>> If a client is really a broker, then is the owner string going to be 
>>for the  upstream application or the broker?  Which clients are likely 
>>to  have the same priority and collide on the same data?
>>
>>
>>>>
>>>> Alia
>>>
>>> /Jan
>>
>> Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Aug 2013 17:49:00 +0200

Hi Alia,

On Aug 26, 2013, at 5:08 PM, Alia Atlas <[email-masked]> wrote:

> On Mon, Aug 19, 2013 at 4:23 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> I agree that basic concepts and terminology should be aligned.  For the RIB, many other routing concepts and abstractions are built on top of it and it isn't usually exposed as such at the management interface.  For instance, the RIB info model has the next-hop chains which are ways of imposing additional headers and specifying their details.  At the network management layer, those would be exposed as tunnels.  For different routing, they might be exposed as MPLS out-segments, or LSPs or MPLS tunnels.  Another example is the ability to specify load-balancing amounts per next-hop.  At the management interface and for routing protocols, multiple next-hops can be specified, but an even distribution of traffic across the next-hops is assumed.   Different hardware may have different ranges and precision for load-balancing.
> 
> So - I agree that converging common basic concepts and terminology is very good.  I'm just concerned that the multiple abstractions built on top of the RIB are not as clear in part because the initial focus for the YANG routing model is on static routes.

The NETMOD WG deliberately didn't want to go into more complex routing stuff, but still - the aim of the routing data model is to create a framework into which routing components of any complexity can be inserted via augmentation. The framework - multiple routing tables, route filters etc. - by itself makes little sense for static routing only.

I think the fact that some concepts or abstractions are not exposed in existing management interfaces doesn't necessarily mean it is worthless to model them as a part of operational state data.

Of course, it is quite possible that the design of the framework in routing-cfg is not good enough to accomodate some of the advanced routing concepts, such as the next-hop chains, but then this is exactly what we would like to hear, preferably before the core routing data model becomes an RFC.

Lada

---

From: Alia Atlas <[email-masked]>
Date: Mon, 26 Aug 2013 17:04:55 +0000

In-line as [Alia]

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 6:36 PM
To: Jan Medved (jmedved)
Cc: Alia Atlas; Juergen Schoenwaelder; Muthumayan Madhayyan (muthu); Nitin Bahadur; [email-masked]; [email-masked]
Subject: Re: [netmod] i2rs client ownership

On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) <[email-masked]> wrote:
> metadata in a separate tree is manageable. If it's fine-grained, 
> having the ownership metadata embedded in the data tree is easier - 
> both for the server as well as for the clients.
>

I think this "owner" concept needs a lot more work.
If owner 1 has a higher priority than owner 2, then owner 1 can clobber anything that owner 2 already created.  That doesn't sound fine-grained to me.

If the client writing existing data has the same or lower priority as the owner that set the data, then the access is denied.  (Problem solved, first one wins).
NACM would need some changes to support owner priority.
The augments that has been proposed is insufficient:
http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6

>>figure out.  One is the permissions aspect - where we need to be able 
>>to clearly express what scope a particular role has.
>
> Agreed.
>

If a client is really a broker, then is the owner string going to be for the upstream application or the broker?  Which clients are likely to have the same priority and collide on the same data?

[Alia] I don't think it is an ownership string that would be stored.  There are several aspects that are important to store - client identity, secondary identity (for the broker case), transport session info (for troubleshooting), client role, client priority.  Again, implementation aspects can vary on how this is stored and indirectly referenced.

[Alia] As for which clients are likely to have the same priority, I don't see a reason to limit the size of the priority field so drastically that this is likely.  Policy in terms of write-scope could be specified so that clients with the same priority don't have access to write the same information.  Other external-to-I2RS mechanisms should be used to avoid collisions.

Alia

Andy

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Wed, 28 Aug 2013 00:37:22 +0000

>dynamic datastore has different ownership and validation requirements).

Correct. It would be great if data model can express which subset of nodes
at which ownership is client specific (and not global unlike config
store). Same goes for the 'exclusivity' requirements.