Subject: [netmod] NETMOD framework

From: Andy Bierman <[email-masked]>
Date: Fri, 01 Aug 2008 09:40:32 -0700

Hi,

It seems to me there isn't much agreement on a common
framework for NETMOD, in areas such as builtin data types,
SMI integration, version identification, version management,
OO vs. procedural, 80/20 rule vs. machine-readable-everything,
and on and on.

One example, namespace URIs:
I am with the camp that sets this field once for a module,
and never changes it -- ever.  (BTW, is there a need to
mark an entire module namespace as deprecated or obsolete?)
Instead, the revision-stmt is rigorously used to provide
an incrementing version field for every module.

Another example, yang-types:
I do not understand why I need ZeroBasedCounter32 from
smidump -f yang, zero-based-counter32 from yang-types,
and I can't use this type at all in SMI-to-XSD.  I strongly
suggest gaining control of the data type landscape
sooner rather than later.  I hope Juergen's plan
of documenting all the differences in yang-types is good
enough.  I agree that encodings should favor XML tools,
not legacy SMI tools, but what do the DM readers really
gain by having duplicates of Counter32?

I understand the need to get data types in use before
NETMOD is done.  I suggest that the highly integrated
approach in smidump be followed.  For immediate standards
purposes, that simply means use the correct names and
modules.

Instead of importing counter32 from yang-types, I would
rather import Counter32 from SNMPv2-SMI.   Types that
are different than the SMIv2 versions should remain in
yang-types.yang.   Types that are exactly the same as
the SMIv2 types should use the SMIv2 name and module location.

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 02 Aug 2008 22:59:07 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> and never changes it -- ever.

This has always been the intention.  But since we don't have the
change control rules written down in the spec yet, it's not obvious.
So I guess I agree with you that the change control rules are really
needed.

> rather import Counter32 from SNMPv2-SMI.

Do you suggest that we should write a standards track document that
specifies how SMIv2 is translated into YANG?  If we don't have such a
standard translation I don't see how a standard YANG module can import
SNMPv2-SMI (or any other module).

> I hope Juergen's plan
> enough.  

That's my hope as well.  Then when we eventually do write SMIv2->YANG
rules, Counter32 can be translated into yang:counter23.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 02 Aug 2008 14:09:42 -0700

> SNMPv2-SMI (or any other module).

No.  I am suggesting that the selected SMI data types
be translated to YANG in modules that mimic their
SMI location, instead of lumping them in a new namespace
and a new module.

> rules, Counter32 can be translated into yang:counter23.

I do not see the need to rename Counter32 to counter32, etc.
There could be a SNMPv2-SMI.yang that was faithful to the
SMIv2 base types in semantics and syntax, and used the SMIv2 names.

The types that are different than SMIv2 for whatever reason
would stay in yang-types, inet-types, etc.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Aug 2008 08:44:58 +0200

> This has always been the intention.  But since we don't have the

This approach has two related drawbacks:

1. NETCONF hello message carries URIs, so if a URI uniquely identifies
the data model, this is all what's needed. Another method will have to
be invented in order to communicate the revision between the agent and
manager.

2. The namespace URI will be present in all instance XML documents such
as NETCONF PDU whereas the revision string currently needn't be.

Why is it a problem to have the namespace URI as the only one identifier
of the data model, including its version?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 07:27:52 -0700

> of the data model, including its version?

Because we don't want to manage 10X more namespaces than
we really need, and because the revision date is a separate
field with its own semantics.  I prefer using 2 distinct fields
rather than create a standard format for stuffing extra data
into the namespace URI.  Standard modules use a URN format, while
vendors are expected to use a URL format.  The namespace
field is not uniformly structured, which is intended as a feature.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Aug 2008 16:52:18 +0200

> into the namespace URI.  Standard modules use a URN format, while

So what's your proposal for solving the problems 1 and 2 above?

> field is not uniformly structured, which is intended as a feature.

YANG or other NETMOD draft can define a recommended structure of both
URNs and URLs, no big deal. And if a silly vendor decides to use another
format, the manager will at least be able to decide whether the data
model is exactly the same on both sides or not, based on string
equality.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 07:58:24 -0700

> So what's your proposal for solving the problems 1 and 2 above?

New protocol mechanisms already defined in
draft-ietf-netconf-monitoring-02

> model is exactly the same on both sides or not, based on string

YANG should not reinvent the URI syntax for use in NETCONF.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Aug 2008 22:37:15 +0200 (CEST)

Hi,

> be invented in order to communicate the revision between the agent and

The revision is sent in the hello exchange as well, like this:

  namespace-uri "?" revision

It is also available from the schema discovery mechanism defined by
the NETCONF WG.

> as NETCONF PDU whereas the revision string currently needn't be.

The revision in the hello msg specifies to the client which version of
a module the server implements.  The URI in the XML encoding is
there to identify the XML namespace of the XML elements, and avoids
name clashes.  It is a feature that the revision is NOT part of the
encoding, since it thus makes it possible for an old client to talk to
a new server (or maybe upload an old backup of (parts of) the config
after a software upgrade).

/martin