Subject: [netmod] #2: Rpcs and Notification inside lists

From: "netmod" <[email-masked]>
Date: Fri, 13 Jun 2008 11:52:45 -0000

Ticket #2: Rpcs and Notification inside lists

 Add the possibility to define notifications and custom-rpc inside a list.
 The XML encoding of the notification/rpc should include an instance-
 identifier pointing to the list(entry).

 This would make the object oriented usage of YANG much easier.

-----------------------------------------+----------------------------------
 Reporter:  [email-masked]  |       Owner:     
     Type:  enhancement                  |      Status:  new
 Priority:  critical                     |   Milestone:     
Component:  YANG                         |     Version:     
 Severity:  -                            |    Keywords:     
-----------------------------------------+----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netmod/trac/ticket/2>
netmod <http://tools.ietf.org/netmod/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2008 14:05:12 +0200

>  This would make the object oriented usage of YANG much easier.

Please explain why this is "much easier". Are you not just replacing
an explict argument with an implicit one? Or do you also want to do
magic name mangling of the rpc name itself? And if we were to do this,
then why only for list elements?

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jun 2008 14:50:35 +0200

Hello,
I think if we allow the agent to supply a default value even when there is no default value in 
the YANG model that might confuse people.

The whole aim of YANG is to specify the model formally. We have the default statement in YANG 
that can be used to specify the defaults. Why do we want to allow (or maybe even recommend) 
devices not to specify their default values? Are there simply to many defaults?

In some cases it might be important whether a leaf exist or the agent creates it with an 
agent-supplied default value.

Generally maintaining Andy's 'set-by' meta-variable is something I would like to avoid. Having 
multiple types of defaults (YANG documented and only agent supplied but not documented) is 
something I would also like to avoid if possible.

======================================================================================

I think if a leaf does not have a default statement that is part of the contract/model meaning 
that the leaf is NOT created/supplied with a value unless the operator really sets it.

If the agents want to supply a default, I think it should include this fact in it's model! Any 
reason not to do that?

If needed an an overlay module which specifices implementation-specific defaults might be a 
usable idea if we manage to keep it simple.

Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Jun 2008 15:17:48 +0200

> If the agents want to supply a default, I think it should include this fact in it's model! Any 

This would result into way too many data models differing just by
default values. That's why I still think it is better to keep the data
model and parameter defaults as two independent things.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2008 07:36:11 -0700

> then why only for list elements?

I agree with Juergen.
The NETCONF protocol is not object-oriented.
The <rpc> and <notification> messages are top-level elements, and the
name of the RPC method is the element name.  Allowing these constructs
to appear at arbitrary points in the data subtree can create naming conflicts.

The notification can always include a data node of type 'instance-identifier'
to identify the list entry that caused the notification.

> /js

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jun 2008 17:07:06 +0200

Hello Andy,
What specific naming conflicts do you have in mind?

On the general concept;

I agree that YANG is not object oriented, but many people will use object oriented programing 
languages to implement it. Also you can find object orientation in KALUA, the XSD proposal and 
in Ericssons original modeling language, so it seems quite some people would be happy to use 
YANG in an object oriented manner.

regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jun 2008 17:10:05 +0200

Hello,
In object orientation it is usual to define methods/procedures as part of an object, a model 
defined RPC can be used as an equivalent(near equivalent) of a procedure in the OO world. This 
has the advantages:
- the definition of the object and the procedure is kept in the same place.
- It tells the reader that this procedure is related to this object
- there is no need to define (or forget to define :-) an explicit references to the object
- This allows an easy mapping from object oriented analysis (e.g. UML). You don't have to lift 
all the procedures to the top level
- This allows an easy mapping to object oriented programming languages
As described in the YANG draft Chapter 5.3 objects can be represented as lists in YANG.

As for notifications: most notifications anyway have a source parameter pointing to a specific 
point (object) in the model. It would be easier if we could just define the notification inside 
an Object/list.
- no need to explicitly define that the object is the source of the notification
- the model shows which objects can be the source of which notifications. This is a bit of 
information our customers are frequently asking for.

By the way both in the XSD proposal 
(http://www.ietf.org/proceedings/08mar/slides/canmod-3/canmod-3.htm) and in the Ericsson 
internal modeling language it is possible to embed actions in a managed object/managed resource.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2008 08:16:25 -0700

> the YANG model that might confuse people.

I think we need to deal with the way real routers and other NE devices
actually work.

> devices not to specify their default values? Are there simply to many defaults?

The aim of NETCONF and YANG is to facilitate network configuration APIs
that actually work, in a cost-effective manner.

NE vendors cannot even agree on mandatory defaults within their own
company, let alone across the entire industry.  Agent-supplied defaults
are a reality, and a robust CM solution should deal with them directly.

Silent default changes across platforms and versions are also a reality.
Sometimes silent default changes do the right thing, as Juergen said,
and they are not a problem at all.

But sometimes an operator wants to upgrade just a subset of routers
to pick up some new features or bugfixes,
and some totally unrelated feature breaks because different boxes
in the same network are using different defaults.  Operators hate
to upgrade router code because of these types of surprises.

Bottom line: The 'CLI way' of hiding agent-supplied knobs from the operator
is broken, and a real CM solution will not be possible unless all
the agent-supplied knobs can be retrieved from the agent somehow.

> something I would also like to avoid if possible.

Simply declaring agent-supplied knobs illegal or out of scope
does not help.

What if the 4 different sw-dev groups in the same company
cannot agree on the default for their platform (happened
all the time where I used to work)?

The reality is that agents need to supply platform-specific
defaults, and sometimes the default value needs to change
over time. NETCONF needs a new verb to retrieve these settings.

This is not really a YANG problem at all.  If the designers
can agree on a default value, they will use a default-stmt.
End of problem from the YANG POV.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jun 2008 17:20:24 +0200

Hello Andy,
I agree with most of your mail, but I do not understand, why cant the designers specify in some 
YANG like format what their specific node is doing with the defaults? What do you think of 
Martin's overlay proposal?
regards Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Hello,
>> I think if we allow the agent to supply a default value even when 
>> there is no default value in the YANG model that might confuse people.
>>
> 
>> The whole aim of YANG is to specify the model formally. We have the 
>> default statement in YANG that can be used to specify the defaults. 
>> Why do we want to allow (or maybe even recommend) devices not to 
>> specify their default values? Are there simply to many defaults?
>>
> 
>> In some cases it might be important whether a leaf exist or the agent 
>> creates it with an agent-supplied default value.
>>
>> Generally maintaining Andy's 'set-by' meta-variable is something I 
>> would like to avoid. Having multiple types of defaults (YANG 
>> documented and only agent supplied but not documented) is something I 
>> would also like to avoid if possible.
>>
> 
>> I think if a leaf does not have a default statement that is part of 
>> the contract/model meaning that the leaf is NOT created/supplied with 
>> a value unless the operator really sets it.
>>
>> If the agents want to supply a default, I think it should include this 
>> fact in it's model! Any reason not to do that?
> 
>> If needed an an overlay module which specifices 
>> implementation-specific defaults might be a usable idea if we manage 
>> to keep it simple.
>>
>> Balazs
> 
> 
> Andy
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2008 17:20:42 +0200

On Fri, Jun 13, 2008 at 05:10:05PM +0200, Balazs Lengyel wrote:

> In object orientation it is usual to define methods/procedures as
> part of an object, a model defined RPC can be used as an
> equivalent(near equivalent) of a procedure in the OO world. This has
> the advantages:

Balazs, it will help me if you can outline a possible solution to see
how this maps to NETCONF (which is not OO and just has flat
rpc/notification namespaces). Consider this example:

container foo {
  notification failure { ... }
  rpc restart { ... }
}

list bar {
  notification failure { ... }
  rpc restart { ... }
}

What is the resulting XML shipped in NETCONF?

/js (who still believes rpc should be operation for RFC 4741 consistency ;-)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2008 08:30:35 -0700

> What specific naming conflicts do you have in mind?

What if I have in the same module:

  rpc foo {  ... }

  rpc X.foo { ... }

  list X {
     rpc foo { ... };

     list Y {
        rpc foo { ... };
     }
  }

How do I encode all these RPC method names in an <rpc> element?
They are all in the same namespace, and they are all named 'foo'?
Do you come up with some name-mangling hack, like X.foo, X.Y.foo, etc.?
Whatever scheme you use, a naming conflict could occur, since all
valid XML element names are also valid YANG identifiers (a mistake IMO).

The same problem exists for <notification>.

IMO, it really complicates the language to mix rpc and notification
constructs in with the config database definition.  You may want NETCONF
to be OO, but it isn't.  The verbs are notifications are procedural,
outside the NV-config datastore.  I prefer to have a clean definition
of the NV-config contents, and keep the protocol verbs separate.

Our conceptual NV-datastore should be rock-solid and need very few
design changes over the next 20 years.  Our set of verbs isn't
even stable over a 2 year span, let alone 20 years.

Andy

> On the general concept;
> 
> I agree that YANG is not object oriented, but many people will use 
> object oriented programing languages to implement it. Also you can find 
> object orientation in KALUA, the XSD proposal and in Ericssons original 
> modeling language, so it seems quite some people would be happy to use

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2008 08:38:42 -0700

Balazs Lengyel wrote:
> Hello Andy,
> I agree with most of your mail, but I do not understand, why cant the 
> designers specify in some YANG like format what their specific node is 
> doing with the defaults? What do you think of Martin's overlay proposal?

This is still an offline documentation solution, which has proven
with SNMP to be of little to no practical use whatsoever.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jun 2008 17:47:35 +0200

Andy,
I am not saying you should not be able to fetch the stuff on-line. I am rather arguing that it 
should ALSO be available off-line as well, as part of YANG. The whole of YANG is off-line :-)
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jun 2008 22:21:55 +0200 (CEST)

> with SNMP to be of little to no practical use whatsoever.

We can do better than that, since we can make the default-overlay spec
available using the schema discovery procedure.  There are also other
reasons that AGENT-CAPABILITIES are not being used (they are complex
and difficult to get right, they reveal sensitive information (for
vendors) etc).

I think there are two issues here.  The first is that is has to be
clear from the YANG document exactly where the agent is allowed to use
implementation-specific defaults.  I think we all agree that this has
to be solved, even though it seems we disagree on the solution
(e.g. should implementation-specific defaults be allowed for mandatory
leafs or not).

The second issue is that given that the agent can use
implementation-specific defaults, should we have a standard way of
making these defaults documented and available for the client?

I think that we should.  If soemone doesn't trust the default-spec,
feel free to ignore it.  Just like you will do if you don't trust the
YANG-spec that the agent claims conformance to.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2008 23:34:15 +0200

> YANG-spec that the agent claims conformance to.

I am not against documentation; I love documentation. But I feel
uncomfortable with the idea of having to "trust" documentation. If I
really need to know the default values (and this usually happens when
I am trying to solve a tricky problem and is not the standard
situation), then I prefer to ask the instrumentation since this is the
most authoritative source of information.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2008 16:37:21 -0700

> most authoritative source of information.

Diving into the technical issues (why not?), there are really 2 features
being discussed here.  The first is <get-settings>, which would be a
new verb that did what <get with-defaults='true'> is supposed to do,
which is to get all the values, including usually hidden default
settings.  This is the best way to find out what happened, after
the fact.  This is the easy part.

The second feature is the ability to predict the behavior and
new state of the device, given its current state and some
arbitrary set of config changes that an operator wants to make.
This is a much harder problem, but quite relevant to NETCONF.

What if you had a NETCONF API to turn on your laptop wireless card
during an IETF plenary?  Do you want to find out after the fact
that the default setting was 'ad-hoc mode'?  Sometimes you really
want to know what a config change operation will do beforehand.

The fatal flaw with the AGENT-CAPABILITIES approach is that
there is no way for a manager to know the entire set of platform/version
variants.  The 'variance identity matrix' and the location of
all the data is totally arbitrary.  Any real solution must
not require humans in the loop at all to identify, locate
or apply the agent variance information.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 14 Jun 2008 14:56:01 +0200 (CEST)

Hi,

> new verb that did what <get with-defaults='true'> is supposed to do,

I prefer standardizing the current with-defaults parameter.  The
with-defaults parameter works with get, get-config and copy-config.
It is also clear from the name what it does.  Having get, get-config
and get-settings might be more confusing.

> want to know what a config change operation will do beforehand.

It seems you are arguing *for* having a formal way of defining and
learning implementation-specific defaults.  If we don't do this, but
accept the fact that implementations will have their own defaults, we
will end up with the situation you just described.

> or apply the agent variance information.

So the idea with an implementation-specific default-overlay spec is
that the client can get it off the box and apply it to the standard
yang module, in order to get the agent-specific data.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Jun 2008 08:51:51 -0700

> will end up with the situation you just described.

I think that agent-supplied defaults is just one issue
within the larger data model conformance problem, and agent
variance from some conformance level for all aspects of
the protocol should be considered.

I am concerned that there are not enough people contributing
in the WG to add this complex problem to the YANG 1.0 plate.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Jun 2008 09:19:00 -0700

>...

I tend to agree with you, but either way has pros and cons.
It could be done with a capability either way, as well,
so managers will know if the with-defaults attribute will be accepted
(or if the <get-settings> verb will be accepted).

> yang module, in order to get the agent-specific data.

It seems like a good idea to me.
Have the agent return URLs or the actual YANG files
that precisely describe the data models currently supported
on that agent.

Actually, the term agent-supplied defaults is much better
marketing than agent conformance variance.  When I proposed
this same sort of thing to the SMING WG (10 years ago?)
the vendors hated it.  They said "there is no way we want
to let our customers know all the little ways our products
do not conform to the standard data models."

This feature cannot be perceived as a way to advertise
product defects. ;-)

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 16 Jun 2008 10:25:07 +0200

+1
Balazs