Subject: [Netconf] General MIDI and NETCONF

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jul 2010 09:50:42 -0700

Hi,

I wonder if the traditional device-centric approach is the best way
to achieve meaningful interoperability.

In the keyboard industry there is a standard called General MIDI.
This is a set of requirements that include instrument to program number
mappings, that all 'GM capable' vendors must support.  For example,
program 1 is an 'Acoustic Grand Piano' and program 2 is a 'Bright
Acoustic Piano'.

http://en.wikipedia.org/wiki/General_MIDI

Once the musician loads the GM program (think of it as a template),
then vendor/device-specific mechanisms need to be used to alter that
program and save it as a new program number.

The standards value is in the particular template itself, and there is no
attempt to standardize editing of a template.

How does this relate to NETCONF?

What if, instead of a bottom-up kitchen sink approach to
data model design, a common-deployment-scenario approach
was taken instead?  This may be too difficult for router vendors
to achieve because there is so much complexity, but
achieving standards convergence at the leaf-level in the
config database is the most difficult path, and not very realistic.

An RPC operation to put service X in default profile Y
is a lot easier to standardize than specifying every data node
and ignoring the fact that various proprietary data nodes already
exist to do the same thing.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Jul 2010 13:00:04 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "NETCONF" <[email-masked]>
> Sent: Wednesday, July 21, 2010 9:50 AM
> Subject: [Netconf] General MIDI and NETCONF
...
> exist to do the same thing.

On a related tangent....  recall that at the IAB workshop we also
talked about how, for example, vendor-specific XSLT could
serve to transform vendor-neutral configuration data (the content
of your "profile Y") to vendor-and-device-model-specific configuration
data.

Randy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jul 2010 13:40:04 -0700

> of your "profile Y") to vendor-and-device-model-specific configuration

+1.  This is the way to do it.  Publish an abstract data-model that vendors can then publish mappings for...or implement natively, in addition to their standard data model, as it would be distinct by the abstract model's namespace...

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jul 2010 14:17:38 -0700

On 07/21/2010 01:40 PM, Kent Watsen wrote:
> 
>> On a related tangent....  recall that at the IAB workshop we also talked about how, for example, vendor-specific XSLT could serve to transform vendor-neutral configuration data (the content of
>> your "profile Y") to vendor-and-device-model-specific configuration data.
> 

I am rather skeptical that it will be as trivial as mapping
one QName to another, and converting 1 simpleType to another.
This approach assumes that the data model semantics line up neatly,
and the whole problem is that the application needs to
know the vendor leaf that maps to each standard leaf.

This ignores contextual semantics and high-level procedures,
which are not likely to be the same in the std vs. vendor
data model.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Jul 2010 15:51:42 -0700

Hi -

> To: "Kent Watsen" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "NETCONF" <[email-masked]>
> Sent: Wednesday, July 21, 2010 2:17 PM
> Subject: Re: [Netconf] General MIDI and NETCONF
... 
> know the vendor leaf that maps to each standard leaf.

I don't think anyone is claiming that it would be *that* simple.
However...

> which are not likely to be the same in the std vs. vendor

The more peculiar a vendor's/device's configuration parameters,
the more work it is (whether for software or a human) to transform
a network-level goal (e.g., parameters needed to interoperate over
a particular link) into the peeks/pokes needed to bring that device
into the desired state.  There's no way around this.  

But a vendor should, IMO, be able to describe how to compute the
device configuration parameters given the desired network characteristics.
It would not surprise me if there were some device parameters that
ended up being "don't cares" in some situations.

The point is that rather than starting with the settings of the device,
we should start with the desired charactreristics of the link, peering
relationship, or network service, and look to how device settings
can be computed from these.  If the answer is that the device settings
are not computable, then we're already done and can go home.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jul 2010 10:23:53 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn

> The more peculiar a vendor's/device's configuration 
> parameters, the more work it is (whether for software or a 
> human) to transform a network-level goal (e.g., parameters 
> needed to interoperate over a particular link) into the 
> peeks/pokes needed to bring that device into the desired 
> state.  There's no way around this.  
> 
> But a vendor should, IMO, be able to describe how to compute 
> the device configuration parameters given the desired network 
> characteristics.
> It would not surprise me if there were some device parameters 
> that ended up being "don't cares" in some situations.
> 

Yes - I believe that this is one part of the problem that was never
(AFAIK) approached in standard models, and which is based on conversions
and operations that each vendor does one way or another. It's worth a
try. This can lead to a programmatic description of the managed device
as an execution point of a network-level configuration, much closer to
the reality than the rude models we have at hand today.  

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Jul 2010 10:57:14 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> +1.  This is the way to do it.  Publish an abstract data-model that
> vendors can then publish mappings for...or implement natively, in
> addition to their standard data model, as it would be distinct by the
> abstract model's namespace...

It is inevitable that when a new model gets standardized, some vendors
will already have their own proprietary versions implemented and
deployed.  These vendors can of course implement the new standard data
model as a mapping to their own proprietary model.  But at the same
time, the standard data model should be good enough for new
implementations to use as-is (with their own augmentations etc as
needed).

And I agree with Andy; the mapping is often non-trivial.

/martin