Subject: [NGO] A reminder why we need an API

From: Andy Bierman <[email-masked]>
Date: Fri, 01 Feb 2008 15:48:44 -0800

Hi,

I think the YANG/DML discussions sometimes lose sight of
the bigger picture -- creating mistake-free, semi-automated
APIs for configuration management.

The revision, description, reference, units, default, config (max-access),
and other YANG clauses come directly from experience with SMIv2.
Of course we need this kind of clause, and not just a description
of schema-valid XML-on-the-wire.

Remember the Mars Climate Orbiter?
NASA would rather you didn't.
That's the one that crashed on landing because one software team
programmed the API function in meters, and the other team used
the API in feet.

How much was a 'units' clause worth that time? $300 million?

http://mars.jpl.nasa.gov/msp98/orbiter/

Andy
_______________________________________________
NGO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ngo

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 2 Feb 2008 16:41:42 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "NETCONF Goes On" <[email-masked]>
> Sent: Friday, February 01, 2008 3:48 PM
> Subject: [NGO] A reminder why we need an API
...
> Remember the Mars Climate Orbiter?
...

Huge agreement.

One loud and clear message from the operators is that configuration
errors are probably the most significant cause of outages.   Just
ensuring that things are syntactically well-formed simply isn't enough.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Feb 2008 09:28:50 +0100

> ensuring that things are syntactically well-formed simply isn't enough.

I don't think I ever claimed that it was enough, it would be silly. My
point is that it has been possible to start with developing the
structure of concrete data models and later refine them with additional
information (and perhaps rewrite the entire data models in YANG). Even
without knowing the semantic details, such models could have been useful
as the running code - test cases for the NETCONF infrastructure
(including YANG), for discussing vendor-independent representations etc.
Unfortunately, the data models that have been published so far are quite
trivial - is everyone waiting for the ultimate DML? Why?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 3 Feb 2008 00:34:45 -0800

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, February 04, 2008 12:28 AM
> Subject: Re: [NGO] A reminder why we need an API
...
...

A devil's advocate would ask a different question:
why is each of these existing data modeling approaches
(three of which were developed specifically for management
information, including configuration data) inadequate?
    - GDMO + GRM
    - CIM
    - SMIv2
    - UML

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Feb 2008 08:33:32 -0800

> trivial - is everyone waiting for the ultimate DML? Why?

WGs like IPFIX are already doing that, by defining info models
before they define data models:

    http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-15.txt

For each network management protocol that defines an implementation
of an info model, there needs to be a data modeling language that
expresses as much detail as possible, related to the protocol
operations that manipulate the data model.

A protocol API is an implementation of a data model, and details such as exact
data encoding, database operations allowed, persistence/defaults behavior,
etc., are needed to implement a robust API.

Andy