Subject: [netmod] deviation-stmt

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Dec 2008 17:57:09 -0800

Hi,

5.9.4:

The <capability> encoding examples are pretty weak
and confusing.  Perhaps they could match examples later in
the draft.

7.18.3, para 5:

    However in some cases the cost of following the standard is heavy and
    the payoff may be small.

I suggest removing this sentence before the IESG sees it.
Including this mechanism is bad enough -- there is no need
to explore the motivations of the vendors who use it.

7.18.3.1:

Why isn't there any status-stmt (just description and reference)?

General:

There is very little discussion of how these deviations are managed.
The target platform(s) associated with the deviations are
completely left out of the data model.  It is expected that
a vendor will create a different module name for each set of
deviations.  All deviations within a module are assumed
to apply to all platforms that 'support' the module.

I strongly suggest adding a standard way to associate vendor
platform identifier(s) (URI leaf-list?) with a set of deviations,
instead of magically figuring it out from the module name.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Dec 2008 23:05:18 +0100 (CET)

> and confusing.  Perhaps they could match examples later in

Agreed.  I have reworked them a bit, and I used the "local-storage"
feature from another example in the text.

> to explore the motivations of the vendors who use it.

I'm fine w/ removing this sentence.

> Why isn't there any status-stmt (just description and reference)?

B/c a deviatation doesn't have the same life span as the other
definitions.  What does it mean to tell a client that I have an
obsolete deviation of an object?

> instead of magically figuring it out from the module name.

I'm not sure where the magic is today?  Can you make a proposal for
something better than what we have now?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2008 15:46:56 -0800

> Andy Bierman <[email-masked]> wrote:
....
> something better than what we have now?

I am understanding deviations a bit more now.
If there is any magic, then it would have to
be encoded into the module name of the deviations module.

module foo { }

module dev-foo-platform-A { }

module dev-foo-platform-B { }

If we had some NETMOD content, then we might have
a standard way to distinguish platform A from B,
but without that, there isn't much that can be done
to make this better.

IMO it would be better to provide some guidance in
this area, so people understand at least one of the
potentially many use-cases.

A compiler also may need to special-case a deviations-only
module.  It is not clear if these modules should be
included in the <hello> PDU.  The namespace-stmt has no
other purpose in this kind of module.

It is not clear at all why the NETMOD WG has decided
(within the syntax on the capability-URI) that all
deviations are grouped by module in a tight 1:1 mapping.

It might make better sense for some vendors to maintain
one deviations file per platform.  The deviation target
implicitly specifies the module, so there is no need
for a CLR to prevent this:

module dev-platform-A {

   namespace "does-not-matter";
   prefix "not-used";

   revision 2008-12-16;

   import foo {
     prefix foo;
     revision 2008-12-01;
   }

   import bar {
     prefix bar;
     revision 2008-11-14;
   }

   deviation /foo:some-leaf { ... }

   deviation /bar:some-container { ... }

}

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Dec 2008 10:01:36 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> It is not clear if these modules should be

That is the idea.  The text is reworked to make this more clear in the
upcoming -03 draft.

> one deviations file per platform.

This is supported already, see below.  The mapping between modules and
deviations is actually N:M.

> The deviation target

So in this case, the <hello> would include:

  <capability>http://example.com/foo?deviations=dev-platform-A</capability>
  <capability>http://example.com/bar?deviations=dev-platform-A</capability>
  <capability>does-not-matter?module=dev-platform-A</capability>

Also note that a module can have multiple deviations:

  <capability>
    http://example.com/foo?deviations=dev-platform-A,dev-common
  </capability>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Dec 2008 03:27:36 -0800

>     http://example.com/foo?deviations=dev-platform-A,dev-common

Also note that the ?deviatations=a,b,c encoding is
completely redundant and pointless.

The namespace URI of the deviations module does matter.
It is just one more capability getting advertised:

    <capability>http://example.com/foo</capability>
    <capability>http://example.com/bar</capability>
    <capability>does-not-matter</capability>

Simply advertising the deviations module is enough.
Since any module can contain any deviation
(they are not constrained to local objects),
the only way to gather all of them is to read in
all the modules anyway.   The deviation target
completely identifies the object being altered.
The extra "deviations=blah,blah" is completely useless.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Dec 2008 13:26:47 +0100 (CET)

> Simply advertising the deviations module is enough.

So when I am a client, I read this advertisement, and I know that
understad http://example.com/bar.  I even have this standard data
model locally.  But I don't understand the data model
http://example.com/foo, so I skip it.  I also don't understand
does-not-matter, so I skip it as well.  Now I just missed the device's
deviations.

If we don't encode the deviations a client will have to check all
modules in the schema discovery list, download them all, and search
for deviations.  In most cases it won't even find any.  With the
explicit encoding, a client can immediately tell when the device does
not have any deviations, and easily find them when it does.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Dec 2008 07:26:44 -0800

> does-not-matter, so I skip it as well.  Now I just missed the device's

  <capability>http://example.com/foo?module=foo&revision=2008-12-01</capability>
  <capability>http://example.com/bar?module=bar&revision=2008-01-04</capability>
  <capability>does-not-matter</capability>

Huh?  How does "deviations=blah" get understood but
the base URI "blah-namespace" does not?
Why can't the implementation search around
using the base URI instead of just a parameter
attached to the base URI?  That's what they did
before YANG invented this new cruft.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Dec 2008 08:02:29 -0800

Hi,

Here is the revised capability encoding.
All YANG modules are the same.  They all
begin with the keyword 'module'.  They can can
contain an arbitrary mix of any YANG body-stmts.

A deviations-only module is just a corner-case.
Why doesn't the agent advertise every module that
has a deviation-stmt in it as a deviation?
Because it is not needed.  Neither is deviations=blah

Why not just advertise the deviations module just like
any other module?

  <capability>
    http://example.com/foo?module=foo&revision=2008-12-01
  </capability>
  <capability>
    http://example.com/bar?module=bar&revision=2008-01-04
  </capability>
  <capability>
    http://example.com/dev-pA?module=dev-platform-A&revision=2008-12-16
  </capability>

What happens if the vendor adds a leaf to module dev-platform-A?
Does the 'deviations=dev-module-A' get dropped from all the other
capability URIs at that point, and the module get advertised instead?
This seems unstable to me.  Advertising the module capability
would be stable and consistent, instead of creating special
capability URI parameters, based on the current contents of the module.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Dec 2008 23:09:59 +0100 (CET)

> has a deviation-stmt in it as a deviation?

It would.

> Why not just advertise the deviations module just like

I tried to explain that in my earlier email.  I will try to rephrase:

If we don't specify the deviations=..., the client will not know if
there are any deviations in place for a particular module.  So it has
to assume that there might be deviations.  Thus, it would have to
download all modules found in the schema discovery list, and scan them
all for deviation statetements for the particular module.

> capability URIs at that point, and the module get advertised

No, the deviations=... will not be dropped, and the module is
advertised already in your example.  So nothing changes in the
hello message.

The deviations=<devs> tells a client that the module being advertised has
some deviation statements in the modules in the <devs> list.   It does
not say that the modules in the <devs> list *only* has deviations.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Dec 2008 14:51:10 -0800

> not say that the modules in the <devs> list *only* has deviations.

I do not think the draft explains much of this procedure.
The manager is going to get N module capabilities from
the agent, processed by a machine.  Why would the manager
ignore some modules and not others?

As soon as the manager does a <get> or <get-config> it
is going to want all the modules anyway, so it recognizes
the nodes in the reply.

A list of deviation module names (maybe the same one)
attached to potentially many capability URIs is complicated.
There is no way to get some of the capabilities but not
all of them.  There seems to be no reason to optimize
for something not even supported by NETCONF anyway.

Since the <hello> message is the only opportunity
for the manager to process agent capabilities,
I suggest not ignoring some of them.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Dec 2008 00:03:07 +0100 (CET)

> ignore some modules and not others?

It all depends on the client application.  Suppose I write a little
management application that configures ipfix on devices.  My app
connects to the device, parses the <hello> and scans for the ipfix
URI, ignoring the other capabilities.  If the ipfix URI is not found,
my app disconnects.  If it is found, and does not have any deviations,
my app will do its normal job.  However, if the ipfix URI has a
deviation statement, my app will try to download the modules with
deviation statements, parse them and apply the deviations (e.g. it
might make sure that the user does not try to create more
observationPoints than the device support).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Dec 2008 15:58:40 -0800

> observationPoints than the device support).

You should look at all the modules in case any of them augment
the ipfix model.  I do not think this is a strong use-case.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Dec 2008 08:54:17 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> the ipfix model.

Why would I do that.   My app doesn't care about them anyway.  It can
configure standard ipfix.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Dec 2008 04:28:21 -0800

> configure standard ipfix.

Because YANG is too complicated already, and stuff like
this makes it even more complicated.

I strongly object to the mandatory ?deviations=blah
change to the capability exchange defined in 4741.
I do not think YANG has the right to change it.
This should be done in 4741-bis, if at all.

The deviations=blah is not only redundant, it
puts a huge maintenance burden on the agent developer
to track down every single deviation-stmt is every module,
find the target (in perhaps another module) and adjust
the capability URI for that module.

All this, instead of simply advertising a list of modules
that the NMS can choose to use or choose to ignore.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Dec 2008 13:42:38 +0100 (CET)

> This should be done in 4741-bis, if at all.

I disagree.  This is not a violation of rfc4741.  4741 says that the
capability to advertise is a URI.  This is a URI.  4741 actually
uses the "query parameter" in the :url capability.

> the capability URI for that module.

This can be done once in the agent.  The alternative of not specifying
this puts the huge burden on the manager, and the manager must do this
dynamically!

> that the NMS can choose to use or choose to ignore.

The point is that unless the deviations parameter is advertised, an
NMS cannot choose to ignore unknown capabilities!  It must download
and parse the modules b/c they might contain a deviation statament.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 19 Dec 2008 09:55:26 -0500

>This should be done in 4741-bis, if at all.

This is nonsense, since 4741 says capability strings are URIs and
even contains an example for using the query mechanism in URIs.
This is not a change to 4741.  We are following both the intent
and the example of the NETCONF spec.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 19 Dec 2008 10:04:21 -0500

>I suggest not ignoring some of them.

IMHO these arguments against the deviation parameter don't hold
water.  Working backwards:

- Clients are free to ignore any or all capabilities about which
  they do not care.  This is goodness.
- NETCONF supports this.
- We optimize for real world scenarios, and I consider deviations
  a part of the real world.
- A client can "get" any subset of capabilities that it care about.
  It can completely ignore the entire <hello> message as opaque
  data, if it knows it doesn't care about any of the capabilities
  expressed by the device (e.g. an config backup program).
- Tying the deviations to the affected module allows the client
  to _avoid_ downloading every module in order to learn which ones
  affect the capability they _do_ care about.  If I care about IPFIX
  and no deviations are reported, I know I'm golden without running
  down the other 150 modules the device supports.
- This isn't complicated.  It serves to localize the complexity, making
  only those who care about the deviations bear their expense.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Dec 2008 07:26:24 -0800

>   only those who care about the deviations bear their expense.

I think this use case is nonsense.
I seriously doubt any application developer
would write code to handle just one capability URI.

Since Martin is suggesting that all modules (even deviation-only)
get advertised along with the 'plain' modules, the manager clearly
has the code to parse a module capability URI.

There is no text in 4741 about "free to ignore"
the capabilities.  On the contrary, all the text
related to capabilities suggests that an application
which ignores them will not work too well.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 19 Dec 2008 10:50:28 -0500

>would write code to handle just one capability URI.

An IPFIX config app that uses only the standard IPFIX
module is free to ignore non-IPFIX modules.

>which ignores them will not work too well.

There is no text in 4741 mandating what a client need do with the
contents of the hello message, beyond some error handling with the
session-id element.  You are free to ignore the capabilities
completely.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Dec 2008 08:49:02 -0800

> session-id element.  You are free to ignore the capabilities

OK -- this is too minor a feature (or cruft depending on POV).
Only 3 people care about it, and 2 of them think ignoring
the agent capabilities is a good idea.
(except :candidate, :writable-running, and :startup I hope;
good luck ignoring those capabilities).

Andy