Subject: [netmod] conformance

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Oct 2008 08:54:50 +0200 (CEST)

Hi,

As input to the discussions next week, we have written down a proposal
for how to handle conformance in YANG. 

Most of the proposal is included below.  For all the details,
including new ABNF rules, see:

http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt

or the diff to the current version:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt

Martin & Phil

------------------------

** Conformance @conformance@

Conformance is a measure of how accurately a device follows the
model.  Generally speaking, devices are responsible for implementing
the model faithfully, allowing applications to treat devices which
implement the model identically.  Deviations from the model can reduce
the utility of the model and increase fragility into applications
that use it.

YANG modelers have three levels of conformance:
- the basic behavior of the model
- optional features that are part of the model
- deviations from the model

We will consider each of these in sequence.

*** Basic Behavior

The model defines a contract between the client and server, which
allows both parties to have faith the other knows the syntax and
semantics behind the modeled data.  The strength of YANG lies in the
strength of this contract and the mindless devotion with which
implementers follow it.

*** Optional Features

In many models, the modeler will allow sections of the model to be
conditional, based on the device.  The device controls whether these
conditional portions of the model are supported or valid for that
particular device.

For example, a syslog data model may choose to include the ability to
save logs locally, but the modeler will realize that this is only
possible if the device has local storage.  If there is no local
storage, an application should not tell the device to save logs.

YANG supports this conditional mechanism using a construct called
"features".  A module may declare any number of features, identified
by simple strings, and may make portions of the module optional based on
those feature.  If the device supports a feature, then the corresponding
portions of the module are valid for that device.  If the device
doesn't support the feature, those parts of the module are not valid,
and applications should behave accordingly.

Features give the modeler a mechanism for making portions of the
module conditional in a manner that is controlled by the device.  The
model can express constructs which are not universally present in all
devices.  These features are included in the model definition,
allowing a consistent view and allowing applications to learn which
features are supported and tailor their behavior to the device.

Features are defined using the "feature" statement.  Definitions in
the module that are conditional to the feature are noted by the
"if-feature" statement with the name of the feature as its argument.

Further details are available in ^feature^.

*** Deviations

In an ideal world, all devices would be required to implement the
model exactly as defined, and deviations from the model would not be
allowed.  But in the real world, devices are often not able or
willing to implement the model as written.  For YANG-based
automation to deal with these device deviations, a mechanism must
exist for devices to inform applications of the specifics of such
deviations.

For example, a BGP module may allow any number of BGP peers, but a
particular device may only support 16 BGP peers.  Any application
configuring the 17th peer will receive an error.  While an error may
suffice to let the application know it cannot add another peer, it
would be far better if the application had prior knowledge of this
limitation and could prevent the user from starting down the path that
could not succeed.

Device deviations are declared using the "deviation" statement, which
takes as its argument a string which identifies a node in the schema tree.
The contents of the statement details the manner in which the device
implementation deviates from the contract as defined in the module.

*** Announcing Conformance Information in the <hello> Message

Devices indicate the names of supported features and device deviations
via the <hello> message.  In hello messages, the features are encoded
in the "features" parameter within the URI.  The value of this
parameter is a comma-separated list of feature names which the device
supports for the specific module.

    <hello>
      <capability>
        http://example.com/mod/mcp?features=feat1&module=mcp
      </capability>
      <capability>
        http://example.com/mod/some?module=some&features=one,two,three
      </capability>
    </hello>

Device deviations are announced via the "deviations" parameter.
The value of the deviations parameter is a comma-separated list of
modules containing deviations from the capability's module.

    <hello>
      <capability>
        http://example.com/abc?deviations=my-devs
      </capability>
    </hello>

** Conformance-related Statements @conformance-stmts@

This section defines statements related to conformance, as described
in ^conformance^.

*** The feature Statement @feature@

The "feature" statement is used to define a mechanism by which
portions of the schema are marked as conditional.  A feature name is
defined that can later be referenced using the "if-feature" statement
(see ^if-feature^).  Schema nodes tagged with a feature are ignored
unless the device supports the given feature.  This allows portions of
the YANG module to be conditional based on conditions on the device.
The model can represent the abilities of the device within the model,
giving a richer model that allows for differing device abilities and
roles. 

The argument to the "feature" statement is the name of the new
feature, and follows the rules for identifiers in ^identifiers^.  This
name is used by the "if-feature" statement to tie the schema nodes to
the feature.

In this example, a feature called "local-storage" represents the
ability for a device to store syslog messages on local storage of some
sort.  This feature is used to make the "local-storage-limit" leaf
conditional on the presence of some sort of local-storage.  If the
device does not report that it supports this feature, the
local-storage-limit node is not supported.

    module my-syslog {
        ...
        feature local-storage {
            description "This feature means the device supports local
                storage (memory, flash or disk) that can be used to
                store syslog messages.";
        }

        container syslog {
            leaf local-storage-limit {
                if-feature local-storage;
                config false;
                description "The amount of local storage that can be
                    used to hold syslog messages.";
            }
        }
    }

The "if-feature" statement can be used in many places within the YANG
syntax.  Definitions tagged with "if-feature" are ignored when the
device does not support that feature.

In this example, a type definition is built based on features.  If the
feature "v4-support" is present, the application can know that the
device will include support for addresses in the IPv4 notation, and if
the "v6-support" feature is present, it can know there is support for
IPv6 addresses.

    typedef peer-address {
        description "Address of a peer";
        type union {
            type inet:ipv4address { if-feature v4-support; }
            type inet:ipv6address { if-feature v6-support; }
        }
    }

**** The feature's Substatements

!! table
!! head ! substatement      ! section             ! cardinality
!! row  ! description       ! ^description^       ! 0..1
!! row  ! if-feature        ! ^if-feature^        ! 0..n
!! row  ! status            ! ^status^            ! 0..1
!! row  ! reference         ! ^reference^         ! 0..1

*** The if-feature Statement @if-feature@

The "if-feature" statement is used to mark portions of the model as
conditional.  The argument is the name of a feature, as defined by a
"feature" statement.  If a prefix is present on the feature name, it
refers to a feature defined the module which was imported with that
prefix.  Otherwise a feature with the matching name must be defined in
the current module or an included submodule.

Since submodules cannot include the parent module, any features in the
module which need to be exposed to submodules must be defined in a
submodule.  Submodules can then include this submodule to find the
definition of the feature.

*** The deviation Statement @deviation@

The deviation statement defines a hierarchy of the module which the
device does not implement faithfully.  The argument is a string that
identifies the node in the schema tree where a deviation from the
module occurs.  This node is called the deviation's
target node.  The contents of the deviation statement give details
about the deviation.

The argument's syntax is formally defined by the rule "deviation-arg"
in ^grammar^.

Deviations define the way a device or class of devices deviate from
the standard.  This means that deviations MUST never be part of a
published standard, since they are the mechanism for learning how
implementations vary from the standards.

Device deviations are strongly discouraged and should only be used as
a last resort.  Telling the application how a device fails to follow
the standard is no substitute for implementing the standard directly.

However in many cases the cost of following the standard is heavy and
the payoff may be small.  A particular device may not have the
hardware or software ability to support parts of a standard module.
When this occurs, the device makes a choice to treat attempts to
configure unsupported parts of the module as either an error that is
reported back to the unsuspecting application, or ignore that incoming
requests.  Neither choice is acceptable.

Instead, YANG allows devices to document portions of the base module
which are not supported or supported but with different syntax, by
using the "deviation" statement.

**** The deviation's Substatements

!! table
!! head ! substatement      ! section             ! cardinality
!! row  ! description       ! ^description^       ! 0..1
!! row  ! deviate           ! ^deviate^           ! 0..n
!! row  ! reference         ! ^reference^         ! 0..1

**** The deviate Statement @deviate@

The "deviate" statement defines how the device's implementation of the
target node deviates from its original definition.  The argument is
one of the strings "not-supported", "add", "replace", or "delete".

The argument "not-supported" indicates that the target node is not
implemented by this device.

The argument "add" adds properties to the target node.  The properties
to add are identified as a substatement to the "deviate" statement.
If the property can only appear once, the property MUST NOT exist in
the target node.

The argument "replace" replaces properties of the target node.  The
properties to replace are identified by substatements to the "deviate"
statement.  The property to replace MUST NOT exist in the target node.

The argument "delete" deletes properties from the target node.  The
properties to delete are identified by substatement to "delete".  The
substatement's keyword MUST match a corresponding keyword in the
target node, and the argument's string MUST be equal to the
corresponding keyword's argument string in the target node.

!! table The deviates's Substatements
!! head ! substatement      ! section             ! cardinality
!! row  ! config            ! ^config^            ! 0..1
!! row  ! default           ! ^leaf-default^      ! 0..1
!! row  ! mandatory         ! ^mandatory^         ! 0..1
!! row  ! max-elements      ! ^max-elements^      ! 0..1
!! row  ! min-elements      ! ^min-elements^      ! 0..1
!! row  ! must              ! ^must^              ! 0..n
!! row  ! type              ! ^type^              ! 0..1
!! row  ! unique            ! ^unique^            ! 0..n
!! row  ! units             ! ^units^             ! 0..1

**** Usage Example

In this example, the device is informing client applications that it
does not support the old RFC867-style "daytime" service.

    deviation /base:system/base:daytime {
        deviate not-supported;
    }

The following example sets a device-specific default value to a leaf
that does not have a default value defined:

  deviation /base:system/base:user/base:type {
      deviate add {
          default "admin"; // new users are 'admin' by default
      }
  }

In this example, the device limits the number of name servers to 3:

    deviation /base:system/base:name-server {
        deviate replace {
            max-elements 3;
        }
    }

If the original definition is:

  container system {
      must "daytime or time";
      ...
  }

a device might remove this must constraint by doing:

  deviation "/base:system" {
      deviate delete {
          must "daytime or time";
      }
  }

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 03 Oct 2008 07:46:43 -0700

> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt

This proposal has been expanded from the original feature request
from the IPFIX WG.

I strongly oppose the deviation features such as
add, replace, and delete.  There seems to be an underlying
assumption that a vendor cannot implement a standard as specified,
and should be able to add, delete, and replace the data model
defined in the standard with different semantics.
I do not think this is what an application developer
has in mind when utilizing standard agent technology.

I thought the 'if-feature' proposal was simply to partition
a module into a flat set of non-overlapping conformance packages,
called features.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 03 Oct 2008 15:49:12 -0400

>This proposal has been expanded from the original feature request

Both proposals come from discussions in Dublin.  The two are related
pieces of the conformance story, so we worked them up together.

>There seems to be an underlying

Assumption or fact?  We have lots of historical examples.

>has in mind when utilizing standard agent technology.

The choice is to let these deviations be published and documented
or to let them be discovered by each app writer anew.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Oct 2008 22:25:33 +0200 (CEST)

> has in mind when utilizing standard agent technology.

We're trying to attack the whole conformance / compliance /
agent-capabilities problem.  This proposal is essentially a YANG
version of rfc 2580.

> a module into a flat set of non-overlapping conformance packages,

It is.  That's one part of the solution.  The other part is the device
deviations (~= AGENT-CAPABILITIES).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 03 Oct 2008 13:53:59 -0700

> or to let them be discovered by each app writer anew.

These device deviations should be in a separate document,
not tied to the release of YANG 1.0.

IMO, a standard for configuration management needs a stable
and uniform API.  If you cannot use the standard data model
to do a particular function, then you need to use a proprietary
data model, or something other than NETCONF.

The success of SNMP conformance is varied, and since most of
the conformance data gathered by the IETF has been for monitoring
MIBs, the experience may not really apply to NETCONF.

It is possible to write reasonable monitoring applications
for standard MIB modules that have missing or proprietary data,
because an agent can overlay as many monitoring MIBs on top
of the same underlying data-store as needed.

It is not possible to write reasonable applications
for standard configuration data models if arbitrary pieces
of the API have been changed in almost arbitrary ways
by every device that implements the 'standard'.

The reason I supported the if-feature partitioning is that
it is 'all-or-nothing' conformance.  If you advertise the
feature 'foo', then you implement everything scoped by
an 'if-feature foo;' statement;

IMO, standards based configuration cannot work unless
vendors implement the data models correctly, using features
to partition the data model into as many pieces as
needed to reach consensus in the WG creating the data model.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 03 Oct 2008 23:01:39 -0400

>not tied to the release of YANG 1.0.

That would require a rev of YANG (1.1?) which would
be a tremendous cost for a new language.  Incorporating
this into the language from the start seems like a better
path if we want it to succeed.

>and uniform API.

I think this would be grand, but I'm not prepared to bet
the success of YANG on it.  There are always justifications
for nonconformance.  To pretend that it won't happen is
wishful thinking.

So the question is will we deal with it by giving apps the
tools to deal with it, or will we simply say that's not
our problem and live in denial?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 03 Oct 2008 21:28:45 -0700

> path if we want it to succeed.

I do not think the 'deviation' stuff belongs on
the standards track at all.  IMO you cannot just
mix and match config data structure members or RPC method parameters.
You can't trade 2 standard leafs for 3 proprietary leafs,
remove a few standard knobs, change a few more, etc.,
and have any hope of multi-vendor interoperability.

Even if this work is pursued in the IETF, then this sort of meta-data
needs to be specified in separate files from the data model
definition.  Maintaining vendor-specific standard variance
in the data model file is not going to work.  It is easy to
decouple the data model variance language from the
data modeling language.  There is no reason at all
that YANG 1.0 would need to reference the other document,
or any reason to change it in order to specify a companion
DM variance language.

IMO, the requirements for NETCONF-based configuration management
data model variance and conformance are not well understood,
or agreed upon.  It will delay YANG 1.0 significantly if
this extra work is undertaken now.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 04 Oct 2008 08:55:08 +0200

Hi,

1. Could the functionality of "non-local" top-level augment perhaps be
moved under "deviation"?. It has the same purpose, if I understand it
correctly.

2. The example

deviation "/base:system" { deviate delete { must "daytime or time"; } }

again raises the question whether the identification of the node
addressed by the deviation is based on matching in the lexical or value
space. What if the original module has the condition expressed as

must "(daytime) or time";

or

must "base:daytime or base:time";

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 04 Oct 2008 09:36:47 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> in the data model file is not going to work.

By just adding the deviation statement to our normal module framwork,
we keep things simple.  No need to invent some other kind of language,
or top-level keyword, and rules for how this would work.

Obviously, you will never find deviation statements in standard data
data modules.  But if a vendor writes a module for how it augments a
standard module, it can choose to put deviation stataments in the same
module.

> It is easy to

If we did this, what should be said about conformance in the main
document?  How can we write the text so that it allows some other
document in the future to add deviations?  Should we be silent on the
issue, or should we say that in order to claim conformance to a module
you MUST implement everything exactly as written?  Or maybe that you
MAY implement everything exactly as written?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 04 Oct 2008 09:40:55 +0200 (CEST)

> moved under "deviation"?. It has the same purpose, if I understand it

Not really.  Top-level augment adds new definitions to an existing
hierarchy.  This is normal and good.

But deviations are strongly discouraged, since they specifiy how you
break the contract defined in a standard module.

> space.

The idea is that in order to identify statements in the "deviate
delete", the identification is done in the lexical space.  Anything
else would be too complicated, as shown in your examples.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 04 Oct 2008 09:52:44 +0200

> break the contract defined in a standard module.

But in fact the effect is the same - change in a foreign module. I
actually like the way how the deviation is explicitly attached to the
target module in the hello message. In contrast, the non-local augment
is sort of open-ended in that it relies on the fact that the foreign
module is negotiated separately.

> else would be too complicated, as shown in your examples.

I guess at least whitespace normalization must be done otherwise it
would be very fragile.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sat, 04 Oct 2008 07:25:44 -0700

> or top-level keyword, and rules for how this would work.

I disagree. The deviation-stmt makes YANG much more complicated.

But I don't want to discuss the solution because I do not
agree with the problem statement.  I think the very idea
of allowing vendors to change the data model contract in
arbitrary ways is harmful to interoperability.  This will
not work for configuration management.  It doesn't even work
for monitoring.

> standard module, it can choose to put deviation stataments in the same

This is something harmful to interoperability, so it does
not belong in the IETF at all.  Vendors should reach agreement
on a language separately to specify all the ways they
do not implement a data model correctly.

> MAY implement everything exactly as written?

You MUST implement everything in the feature to advertise the feature
as 'supported'.  You need to define lots of features if you plan
to leave out various pieces on various platforms.

There are no excuses for replacing, modifying, and otherwise
rewriting the data model API via deviation statements.
The CLI 'anything goes' mentality will not work for
standards-based configuration management.  The IETF should
be spending energy on promoting interoperability, not
on more and more clever ways for vendors to avoid implementing
a standard data model correctly.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 04 Oct 2008 21:54:10 -0400

Andy Bierman writes:
>I think the very idea
>arbitrary ways is harmful to interoperability.

Or, viewed the other way, the assumption that vendors will faithfully
implement data models as specified has been harmful to the adoption
of network management.  It's not a lily-white world.  Admit it and
brace yourself to handle it.

>Vendors should reach agreement

A non-standard mechanism for announcing deviations will
be harmful to interoperability.

>to leave out various pieces on various platforms.

Features are defined by the modeler.  They are part of the model
and are useful for expressing optional facets of the model.  Deviations
are for the implementor to admit their issues in failing to implement
the data model as written.  These are two very different sources of
information.

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 5 Oct 2008 08:37:10 +0200

Here is my opinion as a contributor and implementer of many agents with
various degrees of deviations who at some point in time jumped over the
fence to develop management applications that had to deal with
deviations in agents codes. 

1. I fully agree with Andy that deviations will make interoperability
between agents and managers difficult and probably impossible in many
cases. Standards compliance to YANG data model means that all features
in the data model MUST be implemented as written. Period. 

2. Variants to standard data models are facts of life. If they can be
described in standard language this is useful. Managers have a chance to
cope with specific variant agents. Interoperating with one specific
variant agent does not guarantee that the manager will be able to
interoperate with any other variant agent. 

3. I cannot judge to what degree the deviation-stmt makes the YANG 1.0
more complicated. I believe that having this statement in one form or
another within the language would be very useful, if marked clearly as a
mean to describe variants that make the agents not compliant with the
standard data model. 

In other words, implementing all features in the data model as written
is the only way to achieve compliance. Describing variants by using the
deviation-stmt is a tool that agents developers can use to help
management applications deal with their non-compliant implementations on
a case to case basis. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Saturday, October 04, 2008 5:26 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [netmod] conformance
> 
> Martin Bjorklund wrote:
> >> definition.  Maintaining vendor-specific standard variance in the 
> >> data model file is not going to work.
> > 
> agree with the problem statement.  I think the very idea of 
> allowing vendors to change the data model contract in 
> arbitrary ways is harmful to interoperability.  This will not 
> work for configuration management.  It doesn't even work for 
> monitoring.
> 
> 
> This is something harmful to interoperability, so it does not 
> belong in the IETF at all.  Vendors should reach agreement on 
> a language separately to specify all the ways they do not 
> implement a data model correctly.
> 
> 
> >> It is easy to
> >> decouple the data model variance language from the data modeling 
> >> language.  There is no reason at all that YANG 1.0 would need to 
> >> reference the other document, or any reason to change it 
> in order to 
> >> specify a companion DM variance language.
> > 
> You MUST implement everything in the feature to advertise the 
> feature as 'supported'.  You need to define lots of features 
> if you plan to leave out various pieces on various platforms.
> 
> standards-based configuration management.  The IETF should be 
> spending energy on promoting interoperability, not on more 
> and more clever ways for vendors to avoid implementing a 
> standard data model correctly.
> 
> 
> > 
> > /martin
> > 
> > 
> > 
> 
> Andy
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Oct 2008 00:22:39 -0700

> management applications deal with their non-compliant implementations on

If the agent could replace a standard leaf with a proprietary leaf
in such a way that the derivation-stmt could solve the variation,
then why can't the agent implement the standard leaf correctly,
and simply translate the proprietary leaf into the standard leaf
within the agent itself?  Why move that automatic translation
to the manager?  If it isn't automatic, then it isn't any better
than the DESCRIPTION clause approach we have now.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 5 Oct 2008 09:36:24 +0200

> From: Andy Bierman [mailto:[email-masked]] 
> > 
> 
> If the agent could replace a standard leaf with a proprietary 
> leaf in such a way that the derivation-stmt could solve the 
> variation, then why can't the agent implement the standard 
> leaf correctly, and simply translate the proprietary leaf 
> into the standard leaf within the agent itself?  Why move 
> that automatic translation to the manager?  If it isn't 
> automatic, then it isn't any better than the DESCRIPTION 
> clause approach we have now.
> 
> 
> > Dan
> 
> Andy
> 

Let me try to answer with a couple of examples based on my experience
with AGENT-CAPABILITIES (allow me to acronym this by A-C). I should say
that in the old days many vendors were reluctant to use A-C because it
was documenting their holes in implementations that were supposed to
claim standards compliance. This should be made even more clear and
crisp if we do agree to define something like this in YANG. One of the
reasons in SMI we used A-C was that agents were dealing with sub-agents
that were not under their control and came with their own variants that
had to be dealt with and exposed to managers using SMUX or Emanate or
AGENTX. In such cases a manager could deal with situations like 'in this
enumerated object only five of the seven enumerated values are
implemented, but we added this other three' and 'I am not implementing
this standard knob, but my older proprietary knob with identical
semantics'. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Oct 2008 07:07:28 -0700

> this standard knob, but my older proprietary knob with identical

If the YANG proposal was constrained like AGENT-CAPABILITIES,
then I would not object to it.  It is one thing to implement
the range 1-8 when the real knob is 1-10, or subset the
number of buffers requested.  It is quite another to replace
the standard knob when N vendor knobs that may or may not
have anything to do with the original semantics.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 06 Oct 2008 16:39:15 +0200

> moved under "deviation"?. It has the same purpose, if I understand it
BALAZS: NO. Top level conformance is not a deviation it is an extension mechanism. I have a 
base model, and I want to extend it with some additional stuff that might be proprietary or 
even standard according to a separate RFC. So augment is NEEDED.
Augment does not break the original contract (module definition), deviations usually do.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 06 Oct 2008 16:43:20 +0200

Hello,
A simple question/example:
If we do not specify the cardinality of a list, the upper bound is infinite. If we allow the 
device to specify a real limit that is:
- good because at least we know what we get
- bad because every module will have some deviations, as no one really implements infinity
- is not a deviation, because there is no limitation just a resource-temporarily-not-available 
error :-) always

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 06 Oct 2008 16:43:57 +0200

IMHO if you claim conformance you can say:
- I claim full conformance- means NO deviations are allowed
- I claim partial conformance with the deviations documented in ...

Is it so?

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 06 Oct 2008 16:57:46 +0200

> Augment does not break the original contract (module definition), deviations usually do.

I don't want to advocate deviations, my main point was that the proposed
mechanism how deviations are applied is IMO better than the one for
non-local augment: the base module is advertised together with a "patch
module". The module that augments a foreign module is probably never
intended to be used without the foreign module, so this relationship
should be explicitly stated.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 06 Oct 2008 17:30:59 +0200

Hello,
IMHO by using the same statements in base YANG and inside the deviation statement the rules 
become understandable.

However what is the difference between not-supported and delete in deviations. In both cases 
the addressed statement is considered to be non-existent, as I understand.
Balazs

Andy Bierman wrote:
>>> From: Andy Bierman [mailto:[email-masked]] If the agent 
>>> could replace a standard leaf with a proprietary leaf in such a way 
>>> that the derivation-stmt could solve the variation, then why can't 
>>> the agent implement the standard leaf correctly, and simply translate 
>>> the proprietary leaf into the standard leaf within the agent itself?  
>>> Why move that automatic translation to the manager?  If it isn't 
>>> automatic, then it isn't any better than the DESCRIPTION clause 
>>> approach we have now.
>>>
>>>
>>>> Dan
>>> Andy
>>>
>>

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Oct 2008 08:48:00 -0700

Balazs Lengyel wrote:
> Hello,
> IMHO by using the same statements in base YANG and inside the deviation 
> statement the rules become understandable.
> 

There is a big difference between using compatible syntax
and having the deviation-stmt inside the YANG module.

Most vendors understand that maintaining the platform-specific
and even platform/version/hw-option specific deviations is
best done with separate files, rather than polluting the
data model source file.

I agree that a mechanism similar to AGENT-CAPABILITIES,
but better, would help YANG deployment.

I also think the IETF needs to take a real hard look
at how it thinks standards-based configuration management
is supposed to work.  Without that common understanding,
arguing over the details of this proposal is mostly worthless.

There is a huge difference between a missing or restricted knob,
and an architecture that presumes to patch and plug the API
with a secondary transform layer.  If each implementor of
the ipfix-psamp data model can decide they do not like
the 'tcpReceiver' container that the WG defined, so they replace it
with their own 'acmeTcpSuperRcv' container -- I just don't see
the standards value in that.  I see standards value preserved
in the old school AUGMENT model, but not this one.

> However what is the difference between not-supported and delete in 
> deviations. In both cases the addressed statement is considered to be 
> non-existent, as I understand.
> Balazs

Andy

>>>> the agent implement the standard leaf correctly, and simply 
>>>> translate the proprietary leaf into the standard leaf within the 
>>>> agent itself?  Why move that automatic translation to the manager?  
>>>> If it isn't automatic, then it isn't any better than the DESCRIPTION

---

From: Phil Shafer <[email-masked]>
Date: Mon, 06 Oct 2008 12:19:27 -0400

>best done with separate files, rather than polluting the

I think you are missing something here.  A vendors doesn't change
the data model source file.  They publish their deviations in a
distinct vendor-specific module.

Trying to republish a standard module is unworkable, as is having
the standard modeler track all vendor deviations.

Instead, we have the vendor publish a distinct module containing
their deviations, and have a mechanism for attaching these modules
to the base module via the <hello> message.

Please reread the spec and let me know if this isn't clear.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 06 Oct 2008 12:20:58 -0400

>- I claim partial conformance with the deviations documented in ...

Yes, exactly.  And the buyer can examine the deviations and
say "this is hokey; you dudes are snakes and I'm not buying
your products" if the "partial" claim in nonsense.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Oct 2008 09:40:21 -0700

> Please reread the spec and let me know if this isn't clear.

I have some concerns with the NETMOD WG process here.
Integrating your solution proposal into the WG draft
presumes the WG understands and has agreed upon
the problem that needs to be solved.

I do not agree that there is any standards value in an
approach that assumes vendors will not implement the
standard data model faithfully, so they should be able
to change and replace the standard however they choose.
I don't think this approach will ever work for standards-based
configuration management.

I think the WG would better serve the standards community
by improving data modeling practices and even WG data model
development processes, so that vendors can more easily
comply with the standard.

For example, you should never hard-wire memory requirements
into the API if there is any concern over resources on
any possible platform.  Use a buffersRequested/buffersGranted
design (like RMON) instead.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Oct 2008 18:49:28 +0200 (CEST)

> the problem that needs to be solved.

We will of course not publish anything that the WG does not decide to
publish.  We wrote it in this form (as a diff to -01) to make the
proposal complete and hoped it would be easier to understand this way.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Oct 2008 09:57:26 -0700

> proposal complete and hoped it would be easier to understand this way.

Of course, but the WG discussed the if-feature part of the proposal,
and (I think) has consensus on that part.  But the deviation stuff
has not been discussed by the WG.

I do not agree that the "DM + DM-patch" approach is going
to work.  I do not think semantic equivalence will be preserved,
and if the problem is purely semantic, then the agent should
handle the patch in the NETCONF implementation.

Presuming that every application should use a different foo.yang
for every single platform it wants to manage doesn't seem like
"standards-based" to me.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 06 Oct 2008 13:48:40 -0400

>has not been discussed by the WG.

Can we call for concensus?  The architecture on the table allows
for three levels of conformance:

- basic modeling
- modeler-defined options (features)
- vendor deviations from the standard model (deviations)

IMHO assuming all vendors faithfully implement standards flies in
the face of historical evidence.  Even for the normal "I don't
implement that" and "my default isn't the standards" and "I only
support 15 peers instead of an unlimited number" sorts of deviations,
it is incredibly valuable to have this knowledge at hand.

>I do not think semantic equivalence will be preserved,

It's not equivance.  We're not talking about removing leafs and
replacing them with proprietary clones.  We're talking about what
to do when you can't, say, support the byte counter because your
hardware doesn't have byte counters, or you can't support the unix
permission bits because some architect decided to base your router-os
on windows.  Or you support a "better" way of storing your arp cache
that the standard doesn't allow for.  Or you have a fixed number
of BGP peers instead of infinite.  Or you only support one user
login.  Or your interfaces are fixed.  Or anyone of a thousand
realities that might lie outside the standard model.

Sorry, but the world aighn't flat.  We can bend to match the curve
or we can decide not to solve a very real problem.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Oct 2008 11:14:17 -0700

> realities that might lie outside the standard model.

I think data model design and feature-based conformance
can be used to address these issues.  Documenting
the platform restrictions wrt/ data model is fine.
I think the ABNF in the proposal allows for fairly
arbitrary 'adjustment' to the data model, which goes
beyond missing or restricted knobs.  Replacing parts
of the standard with your 'better' proprietary solution
is not OK.  Augmenting the standard solution with your
better solution, so both are available, is OK.

> or we can decide not to solve a very real problem.

Several years ago, during the OPS-NM road-show phase of
requirements gathering, one clear message seemed to have
consensus -- which is that "standards-based" means
"doing common things in a common way".

There aren't any standard NETCONF config models yet,
and it seems premature to conclude that vendors will
not be able to implement the YANG data models that WGs
produce in the future.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 06 Oct 2008 22:51:29 -0400

>the platform restrictions wrt/ data model is fine.

Deviations document the platform restrictions wrt/ data models in
a formal grammar that allows apps to learn these restrictions.

>better solution, so both are available, is OK.

I'm not saying if it's okay or not.  I'm not making value judgements.
I'm saying that these sorts of engineering trade-offs are made all
the time and compliance to standards is not always the winner.  This
has certainly been the way the world worked in the past, it's
definitely the way the world works now, and as much as I see goodness
and light in a YANG/NETCONF world, I don't see it changing the basic
calculus that "time to market", "cost of goods", and plain ole
dumbness aren't going to be vanquished by our specs.

This is a real problem.  Are we going to solve it?  Are we going
to avoid it?  If we avoid it, are we really helping interoperability
by not equiping apps with the tools needed for the real world?

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Tue, 7 Oct 2008 11:55:50 -0400

Hi,

My real world experience says that vendors don't want to publish how
their implementations differ from the standard; that could hurt their
ability to sell their products and you don't market your "flaws". 

AGENT-CAPABILITIES in SNMPv3 went nowhere.

dbh

> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Monday, October 06, 2008 10:51 PM
> To: Andy Bierman
> Cc: [email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Tue, 07 Oct 2008 12:57:09 -0400

>ability to sell their products and you don't market your "flaws". 

Wise app writers would arrange an "out of band" mechanism for
associating deviations modules with devices.  But the standard
should still have a proper mechanism for doing this.

Thanks,
 Phil