Subject: [Netconf] Comments on draft-ietf-netconf-monitoring-06.txt

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Jul 2009 08:32:23 -0400

Here are my comments on the monitoring draft:

1. Introduction

s/content/data and operation definitions/

s/via XMLSchema//

s/protocol.  It provides/protocol and provide/

s/adjust their capabilities/adjust their understanding of
the server's capabilities/

Do you want to say something about the operational model here?  Should
the client re-fetch the data every five minutes?  On notifications?
On failure?  How will I know that I need to use this capability?

2. XML Schema to Monitor NETCONF

s/XML Schema to Monitor NETCONF/Information Model/

Or is "Data Model"?  Ask Juergen.

The URI ends on ":state".  If this is the "NETCONF Monitoring Schema",
this should be ":monitor".  It also should include a version number:

    urn:ietf:params:xml:ns:netconf:monitor:1.0

2.1 The /netconf-state Subtree

There are two "big picture" questions here:

(a) should ietf models be under a top-level "/ietf/" container?
We should have some hierarchy in our hierarchical data models.
If fact should this be under "/ietf/management/netconf"?

(b) Why is there a "-state" suffix?  Most of this isn't state data,
per se (schemas are not state data).  It seems like you need to
separate this.  But there is also some question about who we will
organize data.  There are many advocates of intermixing state data
without the same tree as configuration data, so config=false nodes
will intermix with config=true ones.  I'm not convinced that this
works well, but it's something we need to think about for this draft.

So should the subtree in 2.1 be under
"/ietf/management/netconf/monitor"?

2.1.1.  The /netconf-state/capabilities Subtree

Change:

   The /netconf-state/capabilibiles subtree contains the capabilities
   supported by the NETCONF server.  The list MUST include all
   capabilities exchanged during session setup still applicable at the
   time of the request.  This ensures consistency with the initial
   capabilities exchanged while allowing for potential modifications
   during a session.

to:

   The /netconf-state/capabilibiles subtree contains the capabilities
   supported by the NETCONF server.  The list MUST include all
   capabilities applicable at the time of the request, and MUST be
   identical to the list provided in the <hello> message if a new
   session were opened at the time of the <get> request.

Or something like that.  The key is that these aren't related to start
of this session as much as related to what a new session would get.

2.1.2.  The /netconf-state/datastores Subtree

-     |_name
+     |_name (key)

Add reference for partial-lock.

You have "the original intended scope of the lock".  This is a
confusing term.  I know there are subtleties and it's a rat hole, but
you should have some words about why "intended" is there.

You mix camel and low-with-dashes style.  I thought I recalled (from
Dublin) that we talked about moving away from camel.  This would be
a-good-thing.

2.1.3.  The /netconf-state/schemas Subtree

Why isn't "namespace" the key, instead of identifier?  YANG module
names are not unique (only SHOULD be), so they are not suitable
for keys.  More importantly, if I want to grab a schema for a chunk
of data I don't grok, I'm _much_ more likely to have the namespace,
not the YANG module name, especially since I don't have the YANG
module.

Shouldn't "version" be "revision"?  This is the right name for
YANG.  What does "version" mean for XSD?  The version has typically
been part of the namespace.

Are there other terms that need harmonized with YANG?

The organization here is flat, not hierarchical.  It should be:

    schema
      |_namespace    (key)
      |_revision     (key)
      |_identifier
      |_format
         |_ name     (key)
         |_location
           |- value

That is:

    list schema {
        key "namespace revision";
        leaf namespace { ... }
        leaf revision { .... }
        list format {
            key name;
            leaf name { ... }
            leaf-list location { ... }
        }
    }

You use upper case for netconf: "(xs:string value 'NETCONF')".  We
should stick with lower case.

2.1.4.  The /netconf-state/sessions Subtree

   sessionId (type: SessionId)
     Unique NETCONF identifier for the session, used for all
     supported operations (e.g. monitoring, session kill, lock
     release) regardless of protocol.

Does "protocol" mean "transport protocol" (the underlaying transport
protocol for NETCONF) or "management protocol" (NETCONF, SNMP, etc)?

So you want sentences that start with "MUST" ("MUST be a unique non-0
value")?

Does "username" needs some qualification to support TAC+ worlds, where
the login name and user name are not identical?

What's the value of the rpc counts?  Why are they worth the code?

Can we use YANG features to break the most important parts of the
netconf/monitor tree from these unimportant parts?

2.1.5.  The /netconf-state/statistics Subtree

"Statistical data pertaining to the NETCONF server" implies that there
is only one server.  Given that most of us will be using the openssh
code and the sshd_conf subsystem hook, there's not one single server.

In particular, start-time makes no sense.

3.1.  The <get-schema> Operation

s/When/If/
s/this new operation/the <get-schema> operation/

The namespace should be the key here.  Also s/version/revision/

The 'data-missing' error code sounds misleading.  If the client asks
for something that we don't have, it's a problem with the client.  We
should return invalid-value or something like that.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 08:38:26 -0700

> "/ietf/management/netconf/monitor"?

I think these issues were already discussed and resolved.
I do not wnt to move them, or to have all IETF standard
modules under one container.

> of this session as much as related to what a new session would get.

I disagree.
It should be up to the agent to decide which capabilities
to offer to a session.  There is no rule in NETCONF that says
every session MUST be given every available capability.

> not the YANG module name, especially since I don't have the YANG

The module names are unique within a single agent.
I think the indexing is fine.

> been part of the namespace.

The data model is not YANG-only, so the terminology does
not have to align with YANG.

I would like this leaf to be optional.
If the manager does not know or care which version
it gets, then it should be able to leave this
parameter out.  Instead, an empty string has to
be passed for this parameter to say "don't care which version".

>             leaf-list location { ... }

I object to this change.
The current indexing is fine and does not require nested lists.
The current [identifier, version, format] tuple is better
because it is simpler to understand and implement.

> netconf/monitor tree from these unimportant parts?

I do not think there is enough cost with a few counters
to justify making them optional.  There should not
be any optional objects in this module, other than
the <get-schema> capability.

> The namespace should be the key here.  Also s/version/revision/

I disagree.
The current indexing is fine.
Module names are easier to remember than namespace URIs.
The manager can look up the module name and revision
quite easily, since module capability URI strings
end with "?module=foo&revision=2009-01-01".

> ________________

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 16:54:52 +0200 (CEST)

> Or is "Data Model"?  Ask Juergen.

Data Model.

>     urn:ietf:params:xml:ns:netconf:monitor:1.0

s/state/monitor is fine with me, but I don't agree we should add a
version number.  We have the revision statement in YANG modules to
handle versioning.

> If fact should this be under "/ietf/management/netconf"?

As Andy said this has been discussed and resolved before.  Adding this
hierarchy would just add unnecessay containers.  The namespace URI
provides the context for the top-level node.

> works well, but it's something we need to think about for this draft.

The model in this draft does not mix config and state, so I am not
sure what we need to think about?

> Why isn't "namespace" the key, instead of identifier?

The current indexing allows you to list (and fetch) YANG submodules
(and equivalent for XSD and RNG).

> been part of the namespace.

In XSD, there is a 'version' attribute on the xs:schema element.
Some XML schemas use that, and some encode the version in the URI.

This leaf needs a data model mapping.  We should add text that says
that for YANG modules and submodules, this leaf contains the
(sub)module's revision.

> In particular, start-time makes no sense.

Maybe it should say "network management subsystem" or something, like
sysUpTime.

> should return invalid-value or something like that.

'invalid-value' is fine, assuming that 'data-missing' MUST only be
used for errors coupled to data store content.

/martin