Subject: [NGO] max-access clause

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Dec 2006 09:54:58 -0800

Hi,

It has been suggested that we can agree on the enumerations
for the max-access clause, without actually defining an ACM first.
I am skeptical, but we haven't discussed this topic in a month,
and it would be nice to settle the issue.

Q1:  Is there ever a case where a read-only data node could be
     classified as a 'config' object instead of a 'non-config' object?
   
Q2:  What classification syntax should be used to identify the allowed 
operations?

      a - enum string
          <max-access>read-only</max-access>
          <max-access>read-write</max-access>

      b - Unix style permission strings
          <max-access>rwx</max-access>

      c - list of operation types (all possible permutations)
          <max-access>read write exec</max-access>

      d - sequence of empty elements of operation types (all possible 
permutations)
          <max-access>
            <read/>
            <write/>
          </max-access>

      e - something else

Q3: What classification values should be used?

    a - ( read-only, read-write, read-create }
    b - { read, write }
    c - { read write create delete }
    d - { read write exec }
    e - something else

Q4: What does it mean to execute configuration or monitoring data?
    Why would anything under <config> or <data> be executable?
    IMO, RPC method definitions are executable, and nothing else,
    in the NETCONF protocol.

Q5: Are there use cases where an operator would get 'create' access rights
    but not get 'delete' access rights (or vice versa)?

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 06 Dec 2006 13:01:06 +0100

Hello,
- We are currently using write-only semantics for passwords. The user can update it, but it is 
only stored in an encrypted form so it is not available for reading. This also means that I 
vote against a hierarchical list; rather I would like all permutations.
- for me create and delete are not really important. I need only one write right that includes 
create and delete. While there might be cases where the distinction between delete and write 
might be important I believe these are rare so I feel we add complexity for little gain.
- I don't see what execute would mean for data
- On Q2 I would vote for b or d
- For actions like ping/restart etc. I propose 3 max-access values read/write/disturbTraffic as 
IMHO these are the 3 things that operators really care for.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Dec 2006 14:51:29 +0100 (CET)

>      classified as a 'config' object instead of a 'non-config' object?

I don't think so.

How would you classify the 'top' and 'interface' nodes in the examples
in the spec, e.g:

  <top xmlns="http://example.com/schema/1.2/config">
    <interfaces>

config or non-config?  Are they read-only?

(We classify them as config, and writable, but they may be required.)

>       d - sequence of empty elements of operation types (all possible 

I'd prefer one of b/c/d.

>     c - { read write create delete }

I think b is sufficient.  Maybe c, since it means the you can model
e.g. an object which can be created, but not modified after creation.

(We don't make this distinction today - if an element is optional or
may exist in multiple instances, the max-access is read/write/delete.
Also, we just mark objects as config or non-config.)

>     IMO, RPC method definitions are executable, and nothing else,

I agree that exec doesn't make sense here.

>     but not get 'delete' access rights (or vice versa)?

Does it matter for this discussion?  Isn't that a question for the
access control mechanism?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Dec 2006 08:29:54 -0800

Balazs Lengyel wrote:
> Hello,
> - We are currently using write-only semantics for passwords. The user 
> can update it, but it is only stored in an encrypted form so it is not 
> available for reading. This also means that I vote against a 
> hierarchical list; rather I would like all permutations.

This is exactly why my original proposal had 'write-only'.
It is unclear whether NMS applications would rather get an
access-denied error than an empty string.  I think it is better
if the ACM can articulate this condition, rather than just
assuming an empty string on a read operation means 'write-only';

> - for me create and delete are not really important. I need only one 
> write right that includes create and delete. While there might be cases 
> where the distinction between delete and write might be important I 
> believe these are rare so I feel we add complexity for little gain.

These have very different syntax, but it is clear you
prefer a list of independent access rights instead of a hierarchical
list, like SMIv2 has.

> - For actions like ping/restart etc. I propose 3 max-access values 
> read/write/disturbTraffic as IMHO these are the 3 things that operators 
> really care for.

IMO, it is a bad idea to make the ACM "router-centric" by having
an enumeration for 'disturbTraffic'.  Too many times the answer
is "it depends" on whether this is even the case.  The ACM should
focus on access to the conceptual data on a NETCONF device.

I use the 'appinfo' clause to store data that might be interesting
to applications.  I would put 'mayDisturbTraffic' in there, not
in the ACM.

Andy

>>   Q2:  What classification syntax should be used to identify the 
>> allowed operations?
>>
>>      a - enum string

---

From: Phil Shafer <[email-masked]>
Date: Wed, 06 Dec 2006 11:49:05 -0500

Andy Bierman writes:
>> available for reading. ...
>... I think it is better

Definitely better to make is explicit, but is that enough?  I'm
thinking about the operator requirement for being about to backup
and restore the entire configuration for a device.  If you can't 
get it, you can't restore it.

>> believe these are rare so I feel we add complexity for little gain.

We see cases where this is useful, such as a logical/virtual router,
where a user is allowed to modify them, but not to make a new one.

>focus on access to the conceptual data on a NETCONF device.

Also the idea of "disturbTraffic" tells about the (possible)
impact of changing the data, not the ability to change the
data.  So it seems more of a ddl/modeling issue than an acm one.

I'm still wondering why we're hitting acm before data modeling, since
the combination of pre-defined and radius-based apply/deny mechanisms
make this a much more dynamic problem.  Any particular user at any
particular time may have distinct permissions.  Is the acm discussion
a warm-up for higher/future things?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Dec 2006 08:50:44 -0800

> config or non-config?  Are they read-only?

I don't use a real node called 'top'.
The <config> or <data> node is the conceptual 'top'.
But it needs to be writable if anything but an empty config
is supported.

The interfaces (or any intermediate node) can be both config
and non-config, depending on the classification of the child nodes.
That's why I've concluded this config/not-config classification
doesn't help.  I think you have to distinguish between write and
create/delete if you want to prevent users from deleting containers
that are expected to be present (in the application design).

However, it must be writable if it contains any writable child nodes.

> (We classify them as config, and writable, but they may be required.)

agreed

> access control mechanism?

It only matters if we have a hierarchical access rights list
instead of a permutation type of list.

IMO, access clauses such as { read, delete } are never going to
happen in real networks.

Having to list all the operations that are supported seems verbose.
The most common use cases should be easy to specify and
the most rare use cases should be harder to specify, not the other
way around.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 06 Dec 2006 12:00:05 -0500

Andy Bierman writes:
>>>       d - sequence of empty elements of operation types (all possible permutations)
>>>           <max-access>
>>>             <read/>
>>>             <write/>
>>>           </max-access>
>>
>>>       e - something else
>> 
>> I'd prefer one of b/c/d.

(b) and (c) are painful to work with in xslt, since you can't test for
explicit nodes.  IMHO, direct contents are preferred.

(a) allows "if (max-access == 'read-only') { ... }" and
"for-each (max-access) { ... }"

(d) allows "if (max-access/read && not(max-access/write)) { ... }"
and "for-each (max-access/*) { ... }"

(e) is, well, underdefined ;^)

(d) also allows future expansion:

    <max-access>
       <read>
          <only-during-eclipse/>
       </read>
       <write>
          <supervisor-approval-required/>
       </write>
    </max-access>

So I'd vote for (d).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Dec 2006 09:26:18 -0800

> get it, you can't restore it.

Yes -- that is why 1-way-transformed password strings are
saved in config files.  In MIBs it is common to say that
a zero-length string always returned.

> where a user is allowed to modify them, but not to make a new one.

Also something as basic as the interfaces table.
You may be able to create/delete optional features
that a rooted in an interface instance, but not
create/delete interfaces.  And of course,
you may be able to create/delete the items in a container,
but not the container itself (e.g., interfaces/interface).

> a warm-up for higher/future things?

In a data model definition such as a MIB, it is customary to define
the maximum possible access that can ever be allowed for an object.
In the absence of an ACM (like we officially have now), the agent still
needs to check if somebody is trying to change the value of a counter,
or create a row in a table that is read-write (i.e. only the agent can
create/delete rows).

The data modeling work is a big problem or it's no problem
at all, depending on your POV.  XSD already exists, and
so does RelaxNG.  We're waiting to see some examples of
data models I guess.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Dec 2006 22:55:48 +0100

> for the max-access clause, without actually defining an ACM first.

In the SNMP world, SMI's max-access has nothing to do with an access
control (assuming this is what you mean with ACM). RFC 2578 says:

   The MAX-ACCESS clause, which must be present, defines whether it
   makes "protocol sense" to read, write and/or create an instance of
   the object, or to include its value in a notification.  This is the
   maximal level of access for the object.  (This maximal level of
   access is independent of any administrative authorization policy.)

I believe SMIv2 got this right. But perhaps NETCONF wants something
else...

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Peder Chr. Norgaard" <[email-masked]>
Date: Thu, 7 Dec 2006 10:52:12 +0100 (CET)

> I believe SMIv2 got this right. But perhaps NETCONF wants something

I would like to add completely different opinion to this dicussion.

It seems from the discussion so far that it will be very hard to agree 
upon a satisfying mechanism equivalent to SMIv2 MAX-ACCESS.  And it makes 
me think that maybe we should not do it at all.

There are two reasons for this.

First, the SMIv2 MAX-ACCESS is not all that smart in real-life.  The 
number of times I've had to define a parallel private MIB object to allow 
configuration of a parameter that the standard MIB has decided to be 
read-only is only beaten by the number of times I've had to write a note 
in AGENT-CAPABILITY stating that a createable or writeable object is 
read-only in this specific agent.  Not mention the few, but significant 
number of times the writeability of an object has turned out to depend on 
the value of other objects - say, you can configure MTU on a PPP interface 
but not on an Ethernet interface.  (Yes, I do know that MTU is 
configurable on some kinds of Ethernet interfaces - it is just an 
example.)

My total experience is that the existence of the MAX-ACCESS clause in 
standard MIBs has helped neither me, as an implementor of SNMP agents, nor 
the implementor of management applications; it has actually made the life 
of both parties more complex.

Second, the (IMHO) most significant new concept in NETCONF is the 
<get>/<get-config> dichotomy.  It allows the server to tell the client 
exactly which elements the server views as configurable.  It allows the 
server to respond to a <get> with an MTU element for both PPP and Ethernet 
interfaces, but drop the MTU element from the Ethernet element when 
responding to a <get-config>, thereby hinting that MTU can be changed 
with, say, <edit-config> for PPP but not for Ethernet.  And that is how it 
should be - the server is, after all, the only entity that knows what is 
writeable and what is not.

I would urge the group to consider not copying the MAX-ACCESS concept from 
SMIv2 into whatever data model solution is created for NETCONF.  The 
concept was not all that successfull in SMIv2, and the need for it is 
considerably less in NETCONF.

Thank you for reading so far.

best regards
--
Peder Chr. Nørgaard        	Senior System Developer, M. Sc.
Ericsson Denmark A/S, Telebit Division
Skanderborgvej 232         	tel: +45 30 91 84 31
DK-8260 Viby J, Denmark         fax: +45 89 38 51 01
         e-mail: [email-masked]
(old e-mail 2000-2003: [email-masked])
          (old e-mail 1992-2000: [email-masked])
----------------------------------------------------------------
OBS: The opinions in this mail are personal and should not be taken
for opinions of Ericsson.
----------------------------------------------------------------
This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
error, please notify the sender by replying to this transmission and
delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we
only send and receive e-mails on the basis that we are not liable for
any such corruption, interception, amendment, tampering or viruses or
any consequences thereof.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Dec 2006 06:39:06 -0800

> I would like to add completely different opinion to this dicussion.

These are very good comments.
You convinced me that we should not simply follow SMIv2
to be consistent with SNMP.

Do you think we should:
   1) have a different (better) max-access clause than SMIv2
   2) not have a max-access clause in data models at all
   3) replace (or enhance) max-access with run-time conformance
      info as it relates to that particular agent implementation

Note that I proposed a MIB that did (3) about 5 years in
the EOS WG.  Vendors thought it was "too revealing" to
clearly indicate at runtime which objects they fully or only
partially supported.  They much preferred to let customers
think all their products implement consistent NM interfaces.
The very existence of a MIB to indicate otherwise was a non-starter.

Andy

> upon a satisfying mechanism equivalent to SMIv2 MAX-ACCESS.  And it 
> makes me think that maybe we should not do it at all.
> 
> number of times I've had to define a parallel private MIB object to 
> allow configuration of a parameter that the standard MIB has decided to 
> be read-only is only beaten by the number of times I've had to write a 
> note in AGENT-CAPABILITY stating that a createable or writeable object 
> is read-only in this specific agent.  Not mention the few, but 
> significant number of times the writeability of an object has turned out 
> to depend on the value of other objects - say, you can configure MTU on 
> a PPP interface but not on an Ethernet interface.  (Yes, I do know that 
> MTU is configurable on some kinds of Ethernet interfaces - it is just an 
> example.)
> 
> standard MIBs has helped neither me, as an implementor of SNMP agents, 
> nor the implementor of management applications; it has actually made the 
> life of both parties more complex.
> 
> server to respond to a <get> with an MTU element for both PPP and 
> Ethernet interfaces, but drop the MTU element from the Ethernet element 
> when responding to a <get-config>, thereby hinting that MTU can be 
> changed with, say, <edit-config> for PPP but not for Ethernet.  And that 
> is how it should be - the server is, after all, the only entity that 
> knows what is writeable and what is not.
> 
> I would urge the group to consider not copying the MAX-ACCESS concept 
> from SMIv2 into whatever data model solution is created for NETCONF.  
> The concept was not all that successfull in SMIv2, and the need for it 
> is considerably less in NETCONF.
> 
> ------------------------------------------------------------------------
>

---

From: Tomoyuki Iijima <[email-masked]>
Date: Fri, 08 Dec 2006 17:08:31 +0900

Hi,

Regarding the Q2, I'm for (d), too.
The expression of 'read' or 'write' are fixed patterns. So those words
should be defined as a tag name and save parsing of 'read' or 'write'.
In other cases, we need to parse 'read' or 'write' as a text message.

>           <supervisor-approval-required/>

Best regards,

-- 
Tomoyuki Iijima
Hitachi, Ltd., Central Research Laboratory
1-280, Higashi-koigakubo Kokubunji-shi,
Tokyo 185-8601, Japan
Tel:+81-42-323-1111 ext.3579
Fax:+81-42-327-7868
E-mail:[email-masked]

---

From: "Peder Chr. Norgaard" <[email-masked]>
Date: Wed, 13 Dec 2006 10:47:51 +0100 (CET)

> to be consistent with SNMP.

Why, thanks for the appreciation.

>     info as it relates to that particular agent implementation

Mostly I think that the discussion is premature.  There is no consensus on 
the techniques used to standardize NETCONF content (SMI equivalent). 
There is not even consensus on a prototype example of actual NETCONF 
content - given that I am not surprised that the discussion of a detail 
like max-access is becoming just a bit far away from reality.

But if I must answer, I think I tend to prefer (2).  As should be 
clear from my first mail in this thread, I do not find the track record 
for use of SMIv2 MAX-ACCESS clause in IETF standards very impressive.

That being said, if a useful formalism for (1) can be found, I will only 
be happy to see it standardized.  But it has to be a whole lot more 
flexible than the SMIv2 technique.

> The very existence of a MIB to indicate otherwise was a non-starter.

Good grief, I certainly do not hope that the company I work for was among 
those vendors.  When we deliver products, an important part of the 
finalization of the products is the "Statement of Compliance" where we 
painstakingly details all known deviations from standards. That is how a 
serious vendor works...

On a more practical level, I actually do imagine a way of using NETCONF 
without MAX-ACCESS to implement something that is a significantly more 
user- and programmer-friendly than is possible with SNMP. Of course it is 
"revealing" in a sense, but it is really no more "revealing" than is a CLI 
management interface that prevents the operator from specifying the MTU at 
some interfaces and not other.

So I am returning to my MTU example.  Say, you are implementing a user 
interface for configuring interfaces on a router, a GUI or a CLI, it 
doesn't matter.  Imagine the operator is creating an interface, Ethernet 
or PPP; this is realized by one <edit-config> to the server, without 
specifying an MTU.  Immediately after that the program performs both a 
<get> and a <get-config> on the resulting element;  the elements contained 
in the response to the <get-config> are the ones that this particular 
agent will accept changes on.  For MTU it means that the program can 
present an updatable field for the PPP interface (of course primed with 
the default value assigned by the server), and a read-only field for the 
Ethernet interface.

To make it possible to implement such a mechanism that will work against 
many different vendors' NETCONF servers, it is necessary to standardize 
the structure of the elements in the interface elements, their names and 
types etc and the placement in the entire server hierarchy; but it is not 
necessary to specify anything about accessability.

MAX-ACCESS clause or not, SNMP does not offer you anything like this.

best regards

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Dec 2006 12:38:07 +0100

> MAX-ACCESS clause or not, SNMP does not offer you anything like this.

The SNMP way of doing this is to try a set operation and to be
prepared to understand the return code. Ugly, but possible.

Sure, it would be nice if the agent/server can indicate without a
write attempt what is writable.  NETCONF perhaps allows to do this
without a real write if you use the #validate noption.

But yes, having a mechanism to do this properly would help.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Dec 2006 05:46:17 -0800

Peder Chr. Norgaard wrote:
>...
> Mostly I think that the discussion is premature.  There is no consensus 
> on the techniques used to standardize NETCONF content (SMI equivalent). 

This mailing list is for throwing out ideas, to
find out if there is interest in the problem and
some hope of WG consensus in a solution.

I just wanted to see if the max-access clause was something
with lots of agreement because it keeps showing up in Sharon's
data models, and it seemed there was agreement on the clause
but not the contents.   Now it is not clear that is even true.

I agree 100% that data organization, namespace usage, instance naming,
common RPC method and notification template definitions, modularity,
object lifecycle, vendor augmentation of standard data models,
user documentation, etc. are the critical issues.  The TLA 'SMI'
stands for the Structure of Management Information.  That phrase
says it all.

Well Formed XML does not equate to Structured Management Information.

The WG could not even agree on how to construct a tiny data model
to return some NETCONF session info.  I don't see how the WG is
going to agree how a DIFFSERV or other huge data model should be done.

> But if I must answer, I think I tend to prefer (2).  As should be clear 
> from my first mail in this thread, I do not find the track record for 
> use of SMIv2 MAX-ACCESS clause in IETF standards very impressive.
> 
> Good grief, I certainly do not hope that the company I work for was 
> among those vendors.  When we deliver products, an important part of the 
> user- and programmer-friendly than is possible with SNMP. Of course it 
> is "revealing" in a sense, but it is really no more "revealing" than is 
> a CLI management interface that prevents the operator from specifying 
> the MTU at some interfaces and not other.
> 
> <get> and a <get-config> on the resulting element;  the elements 
> contained in the response to the <get-config> are the ones that this 
> particular agent will accept changes on.  For MTU it means that the 
> program can present an updatable field for the PPP interface (of course 
> primed with the default value assigned by the server), and a read-only 
> field for the Ethernet interface.

I like this idea, but I think a special RPC method or
special metadata (attribute tags) should be used instead.
As Phil and Martin have pointed out, you need a 'plain' <get-config> to
always return a complete config, so the output of a <get-config>
could be used to reload an agent after a reboot.

This is like the 'container' problem that Martin has brought up
in the past.  There are config nodes that the agent is expected to create
and will not let the manager edit, such as the <interfaces> container
or the 'ifMtu' object in your Ethernet case.

A comprehensive, coherent access control model is needed here,
not merely a max-access clause.

> types etc and the placement in the entire server hierarchy; but it is 
> not necessary to specify anything about accessability.
> 

I don't agree.
Even your get-config idea required some standardization
wrt/ accessibility.  It's a great idea though, so
it should be standardized.

> MAX-ACCESS clause or not, SNMP does not offer you anything like this.

No it doesn't.
It doesn't have a 'set' command that can return data
either like an RPC can.  IMO, we should be fully utilizing the
features in NETCONF, even though they will never be supportable
in SNMP.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 13 Dec 2006 15:11:41 +0100

In Ericsson we plan to have a qualifier for certain parts of the data model (like the container 
elements mentioned earlier) called <system-created>. This would mean that while the respective 
object is a configuration object it will be created by the managed node and can not be created 
or deleted by the operator. It would ensure that these objects are always there where they 
should. Could be used for container elements or element like a HW card. If it is inserted it 
should just appear in the model regardless of operator interaction.

We also support the idea that if you do a get-config, you should be able to reload the stuff 
that came out of the node.

My idea is that such system created nodes should allow the Netconf operation to exactly 
recreate them not just with edit-config-merge but maybe with other operations like 
edit-config-replace or copy-config as well.

Comments?

Balazs

---

From: "Peder Chr. Norgaard" <[email-masked]>
Date: Tue, 19 Dec 2006 21:45:03 +0100 (CET)

On Wed, 13 Dec 2006, Andy Bierman wrote:

>> the techniques used to standardize NETCONF content (SMI equivalent). There 
>> is not even consensus on a prototype example of actual NETCONF content - 
>> given that I am not surprised that the discussion of a detail like 
>> max-access is becoming just a bit far away from reality.
>> 
>

I agree with that; I did not in any way mean to criticize you for raising 
the question.  In a certain sense you have got your answer for now.

> going to agree how a DIFFSERV or other huge data model should be done.

That is what saddens me, too, when I follow the NETCONF lack 
of progress in data modelling.

(Now is perhaps a good time to emphasize, that I, being an employee of 
Ericsson, am not in any way involved in Ericsson-based NETCONF 
development.  My input to the discussion here is purely personal, based on 
a interest in network management techniques covering 20+ years.  So I 
speak for myself in this context, not for Ericsson.)

There has been a lot of discussion about the information models - should 
one use XML Schemas or Relax NG or something else - but almost nothing 
about data models - what is it that we wish to limit using the information 
models (I am taking the terms information and data model, here, from RFC 
3444).  Are we not approaching this backwards?  After all, the purpose of 
the whole exercise must be to develop techniques (preferably formal) that 
allow you to restrict (preferably in a formal way) the Well Formed XML 
expressions that may occur within the various NETCONF operations - the 
actual content-on-the-wire.

Why are we starting with the information models?  Actually, why are we 
disappointed that we are not discussing data models?  The interesting 
thing, the place where we should start because it is where we really can 
evaluate the proposals, must necessarily be actual content.

Here is my proposal for progress:  I would suggest that a few simple nodes 
be described informally, say, a simple router, an Ethernet switch doing 
802.1D, and a host with a few applications that lends itself to 
standardized network management - the host could be a DHCP server.  These 
three nodes will have something in common, such as interfaces and 
addressing, but other aspects would differ.

Then we proceed to describe an example of return value for a <get-config> 
and a <get> on the whole tree.

Only if agreement on such an example can be reached are we ready for 
defining the data model - an informal restriction on possible XML 
expressions.  The restriction should be as precise as possible - 
definitely not preventing something that makes sense, on the other hand, 
preferably allowing as little as possible that makes no sense.

And only then time is ripe for debating formal techniques for the 
information and data model definition.

If it turns out that agreement on such a few examples cannot be obtained, 
we might just as well call it a day and proceed to more productive 
areas...  This is a serious risk, you know, that is about what happened a 
few years ago with the attempt to do progress on RFC 1812, "Router 
5BRequirements".  If a standardization attempt hits the battle field 
between major vendors, standardization has a hard time.

 	:
>> will accept changes on.  For MTU it means that the program can present an 
>> updatable field for the PPP interface (of course primed with the default 
>> value assigned by the server), and a read-only field for the Ethernet 
>> interface.
>

This is one of the few areas where I feel that the NETCONF protocol, as it 
stands today, lacks an important feature.  As I read the text, the return 
of <get-config> is maximal, in the sense that all configurable elements 
are mentioned with their value, regardless of whether the values are 
default or not.  But when I do a "write configuration" on a Cisco-style 
router I normally get a *minimal* configuration - a configuration that is 
sufficient to recreate the current configuration from a restarted node, 
but which leaves out all the objects that have default value (the vast 
majority of objects, in practice).  Such a minimal configuration is much 
easier for a human user to read and understand.

I think it might make sense to add an attribute tag to the <get-config> 
that tells the implementation which of these two variant you want..

> not merely a max-access clause.

I agree totally with you in this.  Taking the proposal for progress 
mentioned above a step further, this would call for some examples of 
on-the-wire <edit-config>s against the examples, some of which should 
succeed and some of which shouldn't.  With such examples on the table, 
with informal reasons, the time is ripe for debating techniques to 
formally describing the restrictions.

best regards

---

From: "Peder Chr. Norgaard" <[email-masked]>
Date: Tue, 19 Dec 2006 21:46:44 +0100 (CET)

> prepared to understand the return code. Ugly, but possible.

Sorry to contradict, but in SNMP this is not just ugly; it is also not 
possible.

Actually, I have a precise example from an agent I myself implemented, and 
it even pertains to the MTU example that I am using.  If you try to do a 
set operation on the (private MIB) MTU object to the current value you get 
a failure 'notWritable', regardless of whether the interface is Ethernet 
or PPP.  You need to have a human being read the AGENT-CAPABILITY 
statement to figure out that for PPP it is because you have to stop the 
interface to change the MTU - whereas for Ethernet it does not help to 
stop, the object is simply not configurable.  No way you a program can 
figure that out by itself.

My point is that the return codes of SNMPv2-PDU are not specific enough to 
make the distinction that NETCONF is born with - the distinction between 
configurable and fixed objects.  An SNMP object can be non-writable for 
any number of reasons.

> But yes, having a mechanism to do this properly would help.

I feel that you are not getting my point.  NETCONF *does* in many cases 
indicate what is writable.  If it is a leaf element returned in a 
<get-config> - why, then it is writable.  Why else would it be part of the 
configuration?

I realize that the mechanism is not perfect; as Balasz writes about 
elsewhere non-leaf elements in <get-config> responses may have been 
created by system, thus not being writable as whole elements.  But just 
being able to deduce the writability of leaf elements is a big step 
forward, relative to SNMP.

best regards

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Dec 2006 22:26:24 +0100

> configurable and fixed objects.  An SNMP object can be non-writable for 

In general, if the behaviour of objects depend on the existance or
value of other objects, the chances to deal with this without hard
coding logic on the manager side are small, whatever the protocol
between the device and the manager will look like (unless AI finally
delivers truely intelligent computers).

How do you think NETCONF tells my manager that I first have to tear
down an interface in order to change its MTU? At best, it can tell me
that the MTU is part of the startup configuration but not of the
running configuration (but this is not really exactly the same as
telling me that turning off this particular interface makes the MTU
writable in the running configuration).

Note, I am not trying to defend SNMP here; the lack of a mechanism to
retrieve configuration state has been discussed during the first NMRG
meeting back in 1998 and even back then this was not really shocking
news.  But even with NETCONF, I expect that manager code will contain
some hard wired knowledge about devices, whether we like it or not.

I would love to be proven wrong about this statement.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Dec 2006 10:08:09 -0800

Peder Chr. Norgaard wrote:
> about data models - what is it that we wish to limit using the 
> information models (I am taking the terms information and data model, 
> here, from RFC 3444).  Are we not approaching this backwards?  After 
> all, the purpose of the whole exercise must be to develop techniques 
> (preferably formal) that allow you to restrict (preferably in a formal 
> way) the Well Formed XML expressions that may occur within the various 
> NETCONF operations - the actual content-on-the-wire.
> 

I think there are efforts in progress to implement NETCONF
for proprietary data models, and the content and function
are more important than the schema details.

IMO, we have to formulate a phased approach.
My immediate concern is basic -- use of a common XSD
for SMIv2 data types and important TCs.  Beyond that,
things are not so clear.

I'm spending a lot of time trying to understand how special RPCs
which interact with the config data can be handled automatically.
The current operational model for many networks is a combination
of automated and manual CLI procedures, which manipulate the device,
and possibly the (document-based) configuration datastore.

We have covered the document model half of the problem with <edit-config>
and the other <foo-config> operations, but the procedural half
is left as a vendor extension (via new RPC methods).

The biggest request from NMS developers (when I used to write SNMP agent
code for a living) was for higher-level, more procedural MIBs.
We used to joke that they wanted a "do the work" button, and that
was the whole MIB.

The mindset in the IETF at the time (and still is)
that procedures should be descriptive or even removed, and *never* normative.
SNMP had tables of data and 1 write operation, and suggesting any
other procedure than "snmp-set(varbind-list)" would influence or
constrain implementations.

Boy, were we wrong.

> Here is my proposal for progress:  I would suggest that a few simple 
> nodes be described informally, say, a simple router, an Ethernet switch 
> doing 802.1D, and a host with a few applications that lends itself to 
> standardized network management - the host could be a DHCP server.  
> These three nodes will have something in common, such as interfaces and 

Routers aren't simple anymore (if they ever were).

Personally, I'm starting small, with the IF*-MIB modules and the REMOPS-MIB,
trying to create procedural APIs out of data-driven APIs.  But the
document model (get-config representation) must still work,
and fall out for free.

The RMON MIB modules would clearly be easier to use with procedures
For example,

    ProtocolDirIDType add-prococol (ProtocolDirEntryType entry);

    "Add this protocol to the directory, unless it already exists,
    and return the agent-assigned protocolDirID object value in either case".

This requires a massive amount of SNMP PDUs (~10000) on real RMON agents.
This is the same use case as for 'create-loopback-interface' and other multi-step
operations.

 >...
> This is one of the few areas where I feel that the NETCONF protocol, as 
> it stands today, lacks an important feature.  As I read the text, the 
> return of <get-config> is maximal, in the sense that all configurable 
> elements are mentioned with their value, regardless of whether the 
> values are default or not.  But when I do a "write configuration" on a 
> Cisco-style router I normally get a *minimal* configuration - a 
> configuration that is sufficient to recreate the current configuration 
> from a restarted node, but which leaves out all the objects that have 
> default value (the vast majority of objects, in practice).  Such a 
> minimal configuration is much easier for a human user to read and 
> understand.
> 

I like this idea.
The options go the other way too.
What if you want the config fully loaded with metadata such
as the last-modify-time, last-modify-user, set-by(user/default/agent)?

One could argue that the current <get-config> behavior is not broken.
It returns everything that is a config node.  Using a tag like 'set-by="default"'
would allow the NMS to run a simple Xpath filter to produce the desired
minimal configuration.

> formally describing the restrictions.

IMO, the ACM starts with the RPC method, and may also include
the restricted access to conceptual data, depending on the RPC method.
A simple ACM is then possible by only granting access to the
<get>, <get-config>, and <close-session> RPC methods to "read-only" users.

Andy