Subject: [NGO] comments on draft-presuhn-rcdml-01

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Feb 2008 11:21:52 -0800

Hi,

I appreciate the effort to capture a lot of details,
including NETCONF-specific requirements.  But there seems to be
all kinds of requirements mixed in, not really related to the DML.

I do not think it will be productive to reach agreement on all
these requirements, or to prioritize them for some sort of
weighted-scoring system for the solution proposals.  The
use-cases approach that Dave Harrington suggested is the best
idea I've seen so far for proceeding with NETMOD.

General Comments:

    IMO, it is a huge mistake to make assumptions (buried or implied by
    a feature requirement) about the architecture of a NETCONF-managed
    system, or a NETCONF agent.  Eventually, if NETCONF really can be
    used for standards-based CM, then some some standard
    definition of these concepts needs to exist.

3.1.3.  Define Actions (NOT Agreed)

    The NETCONF protocol does not have actions.
    It has RPC methods.  The DML needs to align with
    the protocol, and not extend or modify it.

3.2.10.  Model Equivalence #42 (NOT agreed)

    This is really an application requirement.
    There are dozens, if not hundreds of corner-cases, in which
    different DML files can represent the same conceptual model.
    Obviously, a tool is needed to generate 'canonical DML' format,
    so that file can be archived and later diffed with other DM files.

    If there was a canonical format for the DML, then diffs could
    be done which are not tool-specific.

3.4.2.2.  Order within Containers (NOT Agreed)
3.4.2.3.  Interleaving (NOT Agreed)

    These requirements would really make NETCONF incompatible with
    existing XML tools.  XSD does not allow nested element definitions
    to appear in any order.

3.5.5.  Handling Non-Opaque Data #51 (NOT Agreed)

    I don't know how this one would even be possible to achieve.
    By definition, certain clauses are needed to unambiguously
    specify how NETCONF operations work on data definitions.
    It doesn't make sense to consider how an agent will apply
    NETCONF operations to data it doesn't know about.  What is
    the agent supposed to do with this data?  The agent has
    schema-awareness of all the data it supports.  On the
    manager side, without a schema, what interesting work
    can be done without knowing anything about the data model?
    (A mibdump kind of application doesn't edit data.)

3.5.7.2.  Many-to-Many Relationships #8 (NOT Agreed)
3.5.7.3.  Retrieve Relationships instance #52 (NOT Agreed)
3.5.7.4.  Retrieve Relationships - qualified (NOT Agreed)

    These seem to be extending the protocol.
    The agent should not be required to store information that
    is available in the DM file.  Like many requirements in
    the draft, there is no explanation of a use-case, or what NETCONF
    problem this solves.

3.5.8.1.  Referential Integrity #25 (NOT Agreed)
3.5.8.2.  Extended Referential Integrity #58 (NOT Agreed)
3.5.8.3.  Referential Integrity Recovery #73 (NOT Agreed)

    There is always a trade-off between complexity and a complete
    machine-readable description of the model.  It seems to be
    accepted that this is not 100% achievable, and it is not
    worth the complexity -- some details need to be handled
    with a description clause.  (Future work could change my
    opinion, but for now this is too hard.)

3.5.10.1.  Default Values #10 (NOT Agreed)

   There needs to be agreement on the NETCONF agent architecture
   to resolve this requirement.

3.5.10.2.  Dynamic Defaults #44 (NOT Agreed)

    This is done all the time in description clauses only.
    After more R&D, this would be a good feature to support,
    but it is too complex now.

3.6.1.3.  Mandatory Extensions #57 (NOT Agreed)
3.6.1.4.  Must-Understand Extensions #70 (NOT Agreed)

   I disagree with this requirement.  It is a protocol extension,
   and has little to do with the DML.

3.6.3.1.   Schema Version of Instance # (NOT Agreed)

     This is a schema discovery requirement for the protocol,
     and not part of the DML.

3.6.3.5.  Must-Understand Model Extensions #77 (NOT Agreed)

    This is a protocol extension, not a DML requirement

3.7.2.1.  Conditional Conformance #65 (NOT Agreed)

    This is very useful in SMIv2.  It should be possible to
    precisely align conditional conformance of protocol or
    data model definitions with NETCONF <capability> elements.

Andy
_______________________________________________
NGO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ngo

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 22:49:14 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "NETCONF Goes On" <[email-masked]>
> Sent: Tuesday, February 12, 2008 11:21 AM
> Subject: [NGO] comments on draft-presuhn-rcdml-01
...
> all kinds of requirements mixed in, not really related to the DML.

We used the material gathered at previous IETF meetings.  If we
were just defining a data modeling language, some of it would be
quite irrelevant.  However, due to the way netconf was defined,
we had to go into stuff that properly shouldn't be in a data model
per se, but rather in a protocol-specific mapping specification.

> weighted-scoring system for the solution proposals. 

Agreed.  FWIW, I don't think anyone has suggested either of those
approaches.

> The

While use cases are useful, the experience with the various approaches
perferred by various members of the design team leads me to think
that it's not just a question of *whether* a solution can handle a particular
use case, but *how* it does.  This will perhaps lead to a lot of relatively
subjective judgements about readability, usability, and elegance, but
I think we're going to find ourselves in a position comparable to
comparing LISP, COBOL (and, if we're lucky, C) with the objective of
finding a good tool for writing device drivers.

> General Comments:

Note that *all* of the items you respond to were "not agreed" by the design
team.  This means that at least one person thought there was value to it,
but that there was not agreement that the item should be a requirement.

Looking ahead to the canmod BOF, I think the "not agreed" items are
ones we should *not* spend much time on - if the design team was unable
to reach consensus that the item should be made a requirement, it's
highly unlikely that agreement would suddenly emerge at the BOF.

>     definition of these concepts needs to exist.

:-)  I appreciate the irony in the juxtaposition of these two statements.
:-|  We found that agreement we though we might have on some items
     quickly melted if we didn't make very strong assumptions about
     the architecture of a netconf-managed system or agent.  Consequently,
     some items that at first glance might seem obvious candidates for
     agreement weren't.
 
>     the protocol, and not extend or modify it.

The long-standing complaints about using SNMP set-requests to effect
actions by setting "button" objects run counter to this argument.  Its up to
those proposing a solution to decide whether they want to associate these
things with particular objects (which makes them into actions) or not.  I
agree it makes no difference on the wire with netconf, but *if* anyone
brought these into a fine-grained access control model, the distinction
does make a difference.

>     be done which are not tool-specific.

While I agree with this line of reasoning, I'm not a proponent of any
particular approach, and this requirement has been dropped from
the -02 spin of the i-d.

>     existing XML tools.  XSD does not allow nested element definitions

I found the whole discussion of (dis)order to be very messy and confusing.
Since I consider being able to compare instance documents essential to
addressing the problems of configuration management, canonicalization,
and consequently being able to produce a deterministic order, is very
important to me.  I *think* (pardon my bad terminology here) the problem
is made harder than it needs to be by having "anonymous" nodes (i.e.,
no key or other uniqueifier) in the instance document.  If everything has
a name, and if the order is fixed (even if not semantically significant),
I think things become *much* simpler for both humans and tools.

>     (A mibdump kind of application doesn't edit data.)

You understand why this requirement was not agreed.  :-)
 
>     These seem to be extending the protocol.

Not at all.  These are about what a model can represent.
Many-to-many is trivial to construct from one-to-many.
Retrieve Relationship instance (we've put in a difference
description) is exemplified by uses of ifIndex.
 Retrieve Relationships - qualified is exemplified by
an use of the RowPointer TC

>     is available in the DM file.

This is the point of "Retrieve Relationships instance".

>  Like many requirements in

We hope the revised i-d is clearer in this regard.

>     opinion, but for now this is too hard.)

We've added some text that might be helpful for solution developers
trying to figure out when to say "enough".
 
>    to resolve this requirement.

Care to elaborate?

>     but it is too complex now.

My own opinion is that this might be useful at the UI level, but that it's
a bad idea if one of the goals of using a configuration management
solution is to bring a system to a *known* desired state.
 
>    and has little to do with the DML.

Though I disagree with the requirement as well, it is limited
to the modeling language, not the protocol.  (latest i-d text is
a bit better)  This is a *language* extensibility issue.  The
idea is that if a tool encounters a "must-understand" extension
which it doesn't understand in a model, it MUST treat that
as an error.

>      This is a schema discovery requirement for the protocol,

However, the modeling environment needs (someone thought)
to provide a way of identifying the version, and mapping that
to whatever mechanism the protocol provides for conveying the
information.

>     This is a protocol extension, not a DML requirement

No, it sets the limits of "compatible" versions.  Most of us don't
agree with this as a requirement, given bad experiences with
"must-understand" in both modeling and in protocols.  The
tradeoff is between the kinds of extensions one allows to
a model while still calling it (different versions of)"the same
model" and developing a new model that just happens to
bear a striking resemblence to an existing one.
 
>     data model definitions with NETCONF <capability> elements.

FWIW, the members of the design team were less enamored with
how conformance works in SMIv2.  I do agree that there are cases
where conditional conformance seems useful.  However, I lack
the imagination to know how to make it work with <capability>
elements in a system where multiple vendors provide components
implementing instances of the same standard model, or where
difference instances of the same model in a system correspond
to different resources for which the relevant condition is different.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 Feb 2008 09:04:17 -0800

> Hi -

You are right about the need to compare how DML proposals
accomplish various tasks.  If one DML uses 10 easy-to-read
lines and another uses 75 lines of not-easy-to-read, how much
does that matter towards some sort of decision?

If one prioritizes 'easy to read' higher than other people,
this will affect their overall preference.   Ignoring the
priority of a requirement is not possible.

The WG will need to consider NETCONF architecture,
all the way down to how 'defaults' works.  Let's
say 'foo-knob' has a default of '7':

Camp A believes:

    - if the manager does not provide a value for 'foo-knob'
      it does not exist, even though the agent will use the
      value 7 internally.

    - The foo-knob object is not returned in any get operations
      because it doesn't exist

    - if the manager sets 'foo-knob' to 7, then it is created
      and maintained in the database, any will be returned in
      get operations

Camp B believes:

   - if the manager does not provide a value, the agent makes a choice:
     Either the node does not exist (internally or in the database),
     or some default picked by the agent (or defined in the DM) is
     used, and the 'foo-knob' does exist.

   - It does not matter whether the agent created foo-knob or if
     the manager created it -- if the agent is using foo-knob, then
     some value exists and it is accessible in the database.

These are clearly different database architectures.
IMO, the latter approach is much better for interoperability,
and since this is a standards-track protocol, that matters.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 Feb 2008 10:07:06 -0800

> brought these into a fine-grained access control model, the distinction

In the NETCONF WG, 'action' vs. 'rpc' vs. both of them, has been debated
and there is no explicit 'action' operation, because it was
deemed to be redundant.

IMO, a classification for RPC methods would be useful,
just as the event classification that Sharon wants would be useful
(except this one is not used on the wire).  Sometimes an RPC or
notification fits in multiple classes, and this seems to have
derailed efforts to standardize eventClass in the Notification drafts.

E.g.:

    typedef RpcClassType {
      description "RPC class types for use in the rpc-class-stmt.";
      bits {
        bit config {
          description
            "This RPC method can (or does) modify a configuration database.";
        }

        bit monitor {
          description
            "This RPC method can (or does) read from a configuration database.";
        }

        bit device-action {
          description
            "This RPC method can (or does) modify the device behavior is some manner,
             in addition, or instead of configuration data.";
        }

        bit network-action {
          description
           "This RPC method can (or does) modify the network behavior is some manner,
            in addition, or instead of configuration data.";
        }

        bit general-action {
          description
           "This RPC method can (or does) perform some general action.";
        }

        bit device-debug {
          description
           "This RPC method controls a device diagnostic procedure.";
        }

        bit network-debug {
          description
           "This RPC method controls a network diagnostic procedure.";
        }

        bit other {
          description
           "This RPC method performs some purpose not covered in any other
            classification.";
        }
     }

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 16 Feb 2008 11:24:34 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "NETCONF Goes On" <[email-masked]>
> Sent: Saturday, February 16, 2008 9:04 AM
> Subject: Re: [NGO] comments on draft-presuhn-rcdml-01
...
>      used, and the 'foo-knob' does exist.

I think this THREE-way split is at the heart of the problem, and
perhaps a solution.  When you think about it a bit, it's really just
like the interactions described in the RowStatus TC.  To avoid
all that groping around, perhaps the modeling environment
might provide a means to specify whether:
  - a piece of information MUST be supplied by the client before
    the configuration can be considered valid
  - a piece of information has a specified default in the model,
    and if no value is supplied by the client, the server MUST
    use that value
  - if the piece of information is not supplied by the client, the
    server SHALL instantiate it with a value of its choosing
  - if none of the above, it's not instantiated.

How a bit of configuration data came to be should have no bearing
on what the server sends to the client, IMO.

I think this also fits well with the way netconf is supposed to work.

...

Although we looked at it in different terms, the design team came
to a similar conclusion.  From the perspective of "doing" configuration
management, treating "defaults" as a contract between client and
server was the only useful way to "do" defaults at all.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 16 Feb 2008 11:42:17 -0800

Hi -

> Sent: Saturday, February 16, 2008 10:07 AM
....
> and there is no explicit 'action' operation, because it was

At a protocol level, I agree.

...
...
...
...
...
...
...
...
...

Those are all good examples of things for which RPC seems the appropriate
modeling tool.  There are other cases where the action is tightly associated
with instances of specific classes, and for which actions (which simply appear
as RPCs on the wire) make more sense:
  - eject medium
  - rewind medium
  - reboot
  - erase

At a protocol level, it *might* make sense to wrap all actions in a specific RPC
(perhaps the one you call "some general action).  Part of it is a question of
demultiplexing philosophy.  Do you organize things in terms of what will
carry out the activity, or in terms of the kind of activity that will be carried out?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Feb 2008 11:46:18 -0800

Juergen Schoenwaelder wrote:
> On Sat, Feb 16, 2008 at 10:07:06AM -0800, Andy Bierman wrote:
>  
> [...]
> Can you tell me what this classification is good for? How is it going
> to be used to simply things?
> 

It can be used to simplify access control by creating policies
that permit or deny certain types of RPC operations.  It can
be used in help system tools to narrow searches if the operator
is looking for 'debug' commands (in RPC form).

> /js

Andy

> 
> PS: I think the correct NETCONF term for these things is "operations",
>     not RPC, not action, not method - lets just stick to it.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 17 Feb 2008 20:37:07 +0100

[...]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Feb 2008 09:00:55 +0100

> is looking for 'debug' commands (in RPC form).

Sounds like YANG 2.0 to me.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 18 Feb 2008 18:10:52 +0100

Hello,
I was not present at these earlier debates, but I feel that actions would be useful. I even 
wrote a draft about them. Actions could be easily added to YANG if we decide to.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 18 Feb 2008 18:14:58 +0100

Another example for action could be
reset
- interface
- node
- ospf
- management password

All are the same verb connected to very different objects.

But I think our FIRST issue is to CHOOSE a MODELING LANGUAGE. Deciding on individual features 
must come after that.
Balazs

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