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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Aug 2009 11:47:46 +0200

Hi,

thanks to Phil for useful comments, see below.

Cheers,
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Martin Bjorklund
> Sent: Friday, July 31, 2009 4:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] Comments on 
> draft-ietf-netconf-monitoring-06.txt
> 
> Phil Shafer <[email-masked]> wrote:
> > 2. XML Schema to Monitor NETCONF
> > 
> > s/XML Schema to Monitor NETCONF/Information Model/
> > 
> > Or is "Data Model"?  Ask Juergen.
> 
> Data Model.

I would suggest to
s/XML Schema to Monitor NETCONF/Data Model used to Monitor NETCONF/
 
> > 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
> 
> 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.

I think both approaches work. My personal preference 
would be to stick to the approach already discussed 
in the maillist. 

> > 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"?
> 
> 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.
> 
> > (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.
> 
> The model in this draft does not mix config and state, so I am not
> sure what we need to think about?
> 
> > 2.1.3.  The /netconf-state/schemas Subtree
> > 
> > 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).
> 
> > 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.

I agree with Andy. The data model is not YANG-only and 
the terminology should be more generic.
 
> 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.

Agree, we should add text and highlight what the leaf 
contains in a YANG module.
 
> > 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.
> 
> Maybe it should say "network management subsystem" or something, like
> sysUpTime.
> 
> > 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.
> 
> 'invalid-value' is fine, assuming that 'data-missing' MUST only be
> used for errors coupled to data store content.

'invalid-value' looks fine. 
 
> /martin
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Phil Shafer <[email-masked]>
Date: Sat, 8 Aug 2009 10:26:42 -0400

>version number.  We have the revision statement in YANG modules to

The YANG module is non-normative, so implementations won't announce
the capability with YANG style (and panache), so you need another
mechanism for versioning.

Another reason to wait for YANG, IMHO.

>provides the context for the top-level node.

These "unnecessary containers" provide an organizational hierarchy.
Without this, all modules will appear at the top level.  This would
be an unbearable bad decision.

If there are 10 bgp yang modules, how do I say "give me all your
bgp config" to a device?  I can't just ask for the
/ietf/protocols/routing/bgp hiearchy and get all 10 overlapping
(augmented) module contents.

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

This is an early data model, and will be used as a precedent.  Adding
the "-state" suffix means when someone adds config, you'll need a new
hierarchy instead of augmenting the existing /ietf/management/netconf
one.

>(and equivalent for XSD and RNG).

Shouldn't these be organized in a hierarchical manner, so submodules
appear under modules?

>Some XML schemas use that, and some encode the version in the URI.

Given that we hope/expect YANG to take over the world, using "version"
when we clearly mean "revision" is an unnecessary translation that
is annoying at best, confusing at worst.

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

What's the value of this field?  Why would anyone use it?
What would they use it for?  If you want to have it in the
module, it needs a convincing use case, imho.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 08 Aug 2009 08:01:18 -0700

> Martin Bjorklund writes:
...
> (augmented) module contents.

I brought up the data hierarchy issue about 4 years ago
at the Santa Clara interim.  Glad to see the issue again.
Sorry the situation has only got worse.

I agree that we should have top level classes.
I am so sick of this ad-hoc, kitchen-sink design focus,
that almost anything at all would be better.

But /ietf will get huge over time.  So each WG should
decide its own container names, and not be forced to
use a simple formula like ietf-<WG-name>.

   /ietf-bgp/
   /ietf-netconf/

So why don't we have any sort of data organization in NETCONF,
so other WGs can follow our good example?  Why
don't we start organizing and structuring data
so we stop setting such a bad example?

> ...

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2009 21:05:10 +0200

> so we stop setting such a bad example?

Using <WG-name> is a choice but IMHO not a very good choice; WGs are
means to organize work and they not necessarily provide good and
organized and long lasting names we are looking for.

/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: Andy Bierman <[email-masked]>
Date: Sun, 09 Aug 2009 12:18:03 -0700

> organized and long lasting names we are looking for.

but this is protocol name, not WG name.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Aug 2009 11:16:55 +0200

> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Sunday, August 09, 2009 10:18 PM
> To: Andy Bierman; Phil Shafer; [email-masked]
> decide its own 
> >> container names, and not be forced to use a simple formula like 
> >> ietf-<WG-name>.
> >>
> >>    /ietf-bgp/
> >>    /ietf-netconf/
> >>
> >> So why don't we have any sort of data organization in NETCONF, so 
> >> other WGs can follow our good example?  Why don't we start 
> organizing 
> >> and structuring data so we stop setting such a bad example?
> > 

Right. These names may be different, as for example in the ietf the name
of the wg dealing with bgp nowadays is idr, radext takes care of radius,
and netmod is in charge with yang. 

Dan

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 09:21:59 -0400

>but this is protocol name, not WG name.

There should be an organization above the protocol name containing
the area on which the protocol works.  At a minimum, this could be
the ietf area, but something better (perhaps determined by the
area directors for that area?) should be easily possible.

A strawman:

/ietf
  + /protocols
    + /management
      + /snmp
      + /netconf
    + /routing
      + /bgp
      + /ospf
    + /layer-2
      + /spanning-tree
    + /mpls
      + /path-management
        + /rvsp
        + /ldp
    + /security
      + /ipsec
        + /eap
  + /ipr
    + /lawyer-fodder

Or:

/ietf
  + /area
    + /applications
    + /general
    + /internet
    + /oam
      + /netconf
      + /snmp
    + /real-time
    + /routing
      + /mpls
        + /rsvp
        + /ldp
      + /bgp
    + /security
    + /transport
  + /other

Or perhaps put bgp under "egp" and "ospf" and "isis" under "igp".

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Aug 2009 15:50:44 +0200 (CEST)

> area directors for that area?) should be easily possible.

I am concerned that this approach is over-designed.

This means that this hierarchy must be defined in one or more YANG
modules, defining one or more XML namespaces.  Every other module must
augment this (or of these) module(s).

module ietf-general {

  namespace "urn:ietf:params:general";
  prefix ietf;

  container ietf;

}

module ietf-protocols {

  namespace "urn:ietf:params:protocols";
  prefix proto;

  import ietf-general {
    prefix ietf;
  }

  augment "/ietf:ietf" {
    container protocols;
  }
}

...

module ietf-netconf-state {
  
  namespace "urn:ietf:params:xml:ns:netconf:state";
  prefix ns;

  // a couple of imports here...

  augment "/ietf:ietf/proto:protocols/mgmt:management" {
    container netconf { ... }
 }

}

And then the XML will have to get the namespaces right:

  <edit-config>
    ...
    <config>
      <ietf "urn:ietf:params:general">
        <protocols "urn:ietf:params:protocols">
          <management "urn:ietf:params:management">
            <netconf "urn:ietf:params:xml:ns:netconf:state">
               ...
            </netconf>
          </management>
        </protocols>
       ...

If the complete structure (down to individual protocols etc) is
defined in one ietf-hierarchy module, which is "often" updated as
needed, things would be a bit simpler.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 10:13:55 -0400

>augment this (or of these) module(s).

I'm advocating an organizational hierarchy, not a ton of modules.  I've
no issue with this being in one "ietf.yang" module.

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Mon, 10 Aug 2009 18:21:36 +0200

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 08, 2009 5:01 PM

> so we stop setting such a bad example?

With yang, I thought that, implicitly, we had had this discussion, but perhaps
not.

XPath absolute expressions need to know where the root is and currently, this
does not make any allowance for /ietf/bgp/..., rather placing it above 'all
top-level data nodes in all modules'

Which is ok, as long as we never need an XPath expression which takes cognizance
of /ietf/bgp/..; at which point, my crystal ball goes a little hazy.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Aug 2009 16:25:14 +0200

> Or perhaps put bgp under "egp" and "ospf" and "isis" under "igp".

Areas come and go, protocols move between areas, everything is
tunneled on top and below everything else (almost). So I believe
the only sensible long lasting structure is

/ietf/snmp
      netconf
      bgp
      mpls
      ...

and since we use proper namespaces, even the /ietf is not really
adding much in terms of XML processing.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 11 Aug 2009 10:40:09 -0400

Juergen Schoenwaelder writes:
>tunneled on top and below everything else (almost).

Surely there's some organizational approach that makes sense.
A "flat earth" view where thousands of namespaces live at one
layer can't survive the sniff test.

snmp and netconf are management protocols.  bgp and ospf are
routing protocols.  mpls is a switching protocol.  These aren't
fluid.  Sure, you can run http over dns or use bgp to calculate
the shortest path from your house to your office, but that doesn't
change their principle use.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Aug 2009 17:11:45 +0200

> change their principle use.

These were the simple examples - there is other stuff I do not find so
clear cut.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Aug 2009 10:41:42 -0700

> layer can't survive the sniff test.

I like the organization that Juergen proposed.
I have to type XPath absolute path expressions
a lot, and the extra containers do not add value.

> change their principle use.

I think if (by some miracle) the IDR WG decides to standardize
an ietf-bgp.yang module, then they can decide how many top-level
elements in how many XML namespaces -- or maybe they will want
to use submodules and have a giant ietf-routing.yang main module.
I don't think the NETCONF or NETMOD WGs should make this decision
for them.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Aug 2009 21:36:10 +0200 (CEST)

> I like the organization that Juergen proposed.

With or without /ietf?

> a lot, and the extra containers do not add value.

I agree.  We need to decide what we should do for the monitoring
module and other netconf modules.  We already have:

  {urn:ietf:params:xml:ns:netmod:notification}netconf  (RFC 5277)
  
and currently in the monitoring draft:

  {urn:ietf:params:xml:ns:netconf:state}netconf-state

Maybe the next module will be ietf-netconf-acm, which actually will
provide some configuration knobs!

I don't think we can do much about 5277 at this point, but we should
think about if we need a 'netconf' container under which we can put
the current monitoring and future config models.

Do we want to use many namespaces, or should we try to partition one
namespace with submodules?  Can we make one ietf-netconf module which
defines the '/netconf' container and then publish the monitoring as a
submodule and a future access control module as another submodule?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Aug 2009 12:57:46 -0700

>> I like the organization that Juergen proposed.

without

> submodule and a future access control module as another submodule?

We should not change published URIs, so the old format
in RFC 5277 is 'legacy'.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Aug 2009 09:51:48 -0400

Hi,

I recommend against a hierarchy based on IETF area. Operators don't
care about IETF areas; they care about protocols and functionality.

should we learn from experience? IANA already defines a hierarchy for
NM information:

MIBs are organized into 
	internet/mgmt/mib-2 (ietf mib modules)
	internet/experimental
	internet/private/enterprise

we might want 
	/ietf
	/experimental
	/enterprise
	/<other standards body, such as IEEE>

we learned that having an snmpv2-specific subtree didn't help much,
but serves to provide a common registration point for things like snmp
domains, proxies, and modules. We might want a /netconf subtree for
registering netconf-specific things, such as capabilities, but that
should work just as well in an ietf subtree
	/ietf/netconf
	
we learned that some things that need easy registration changes, such
as ifTypes, should be handled by IANA directly, so maybe we want to
define an /iana subtree.

we learned that allowing WGs (e.g., RMON and MPLS) to define their own
sub-trees became problematic. The preferred hierarchy now is to use a
relatively flat approach, with most mib modules being registered
directly under mib-2. Bert and Dan can talk to that point. 

we learned that mib modules for transmission protocols are common, and
there is a separate subtree for transmission mib modules. Monitoring
the transmission protocols has been important during the growth of
SNMP, but it might be less important for netconf.

The experimental branch was not very useful because it was too
difficult to migrate such a MIB registration afterwards, due to SMI
rules that required changing the descriptors, but this might be easier
in netconf. If we are going to permit extensibility of capabilities,
we might want to be able to use them in an experimental mode first. We
do have versioning, so that might make experimental less important,
but once published the subtree stays forever.

Having some consistency in the top-level organization for MIB modules
and YANG modules will probably make it easier to implement
applications and instrumentation that use both SNMP and Netconf
interfaces. Most operators will want to see some similarity in the
data and information models used for configuration and for monitoring.
If we design totally different hierarchies, we would likely make it
harder and more costly to implement and use, which will not help to
encourage adoption of the new standards.

So I suggest
	/ietf
	/enterprise
	/iana
and maybe
	/experimental
	/ietf/transmission
	/ietf/netconf

dbh

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 11, 2009 10:25 AM
> To: Phil Shafer
> Cc: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Aug 2009 16:18:38 +0200 (CEST)

Hi,

> 	/ietf/netconf

One difference if compared to SNMP is that in SNMP there is one single
hierarchy, whereas in NETCONF we have a 2-dimensional matrix, or maybe
a collection of hierarchies, due to the XML namespace and element
names.  So in NETCONF, it is perfectly legal to have

  /ietf  in the namespace  "urn:ietf:params:xml:ns:ietf"
  /ietf  in the namespace  "http://example.com"

One consequence of this is that the /experimental subtree is not
really needed - one can use the same hierarchy in a different
namespace instead (as has been discussed on the NETMOD ML for YANG
modules in I-Ds). 

Another consequence is that the /enterprise subtree is not needed -
the enterprise controls its own namespace.

If we have an hierarchy starting from /ietf, what will the namespaces
be?  I would like to avoid extra namespaces as much as possible b/c
they get cumbersome to use and get right.

/martin