Subject: Re: [NGO] FW: BOF Comments: CANMOD

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 01 Feb 2008 10:18:58 +0100

Balazs Lengyel píše v Čt 31. 01. 2008 v 16:07 +0100:

> I would REALLY hate to have one language to describe the basics of my configuration and another 
> language to define some other aspects of my configuration. All the above an some others do 
> belong to y real world configuration. Also we have to have a fairly complete language that can 
> be used both for standards and for proprietary models as well (like we did with MIBS).

Specifically, defaults wouldn't need any special language, just a list
of parameter locations (perhaps expressed using XPath) and corresponding
default values.

In the design of programming languages, it is automatic that the
lexical, syntactic and semantic specifications are clearly separated. I
am now developing a schema for configuring packet filters that has
certain aspects of programming languages (subroutines etc.) and the
logic encoded in the XML structure is crucial. So I wonder why such a
separation for configuration languages is considered wrong and an
all-encompassing approach is absolutely preferred.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 01 Feb 2008 10:26:56 +0100

David Harrington píše v Čt 31. 01. 2008 v 13:54 -0500:
> > 
> > No, as I said, I am only objecting against specification of defaults
> > together with rules about content within the same data model (= same
> > URI). If they are handled separately, a device could subscribe to
> > (a) standard content model (e.g., "urn:ietf:protocol:content")
> > (b) proprietary defaults (e.g., "urn:vendor:protocol:defaults")
> > This is IMO much easier to achieve than forcing everybody to accept
> > "urn:ietf:protocol:everything" and still would be a big improvement.
> 
> A big improvement over what? I don't think we should reset the bar to
> nothing when we have worked years to raise the bar.
> 
Improvement over the existing CLI languages that are largely
incompatible. I am more interested in this area than in replacing ASN.1
with XML.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 01 Feb 2008 11:16:42 +0100

> of parameter locations (perhaps expressed using XPath) and corresponding
Sorry Lada but this is exactly what I want to avoid:

You already introduce a "simple" but separate method/language to describe defaults based on 
XPATH. It's format will need extra time to agree upon, so it will not be available at the same 
time as the modeling language, it will need a separate set of tools to handle etc.

Your simple list does not answer my questions about defaults:
- the default value is valid for the datastore or the individual operations?
- if you change a default value, does the data model stay compatible or not?
- is there a difference between a value set by default and the same value set by the user?
- should default values be returned in get-config or not (speaking of thousand of defaults)?

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 01 Feb 2008 12:04:19 +0100

> time as the modeling language, it will need a separate set of tools to handle etc.

XPath is quite a solid standard already. Of course, it doesn't mean that
the devices must necessarily implement XPath - YANG deals in the same
way with "must" asserts.

> Your simple list does not answer my questions about defaults:

Sure, but I guess these questions are valid even for the YANG's
definition of defaults.

> - the default value is valid for the datastore or the individual operations?

This is a good question, I don't know (but I don't advocate defaults).
For example, if I use a selection node in a subtree filter and this node
happens to have a default value, shall I get it or not? Does it depend
on the value of the with-defaults attribute?

> - if you change a default value, does the data model stay compatible or not?

I would prefer if it does.

> - is there a difference between a value set by default and the same value set by the user?

I would prefer to avoid this distinction.

> - should default values be returned in get-config or not (speaking of thousand of defaults)?

To remain consistent, I must say yes here. However, client-side
filtering of defaults could be applied to protect the human user from
excessive amounts of data. This approach needn't rely on common
standardised default values.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 31 Jan 2008 11:14:54 -0800

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Balazs Lengyel" <[email-masked]>
> Cc: <[email-masked]>; "Eric Rescorla" <[email-masked]>
> Sent: Friday, February 01, 2008 1:18 AM
> Subject: Re: [NGO] FW: BOF Comments: CANMOD
...
> all-encompassing approach is absolutely preferred.

That is how GDMO works.  The semantics are in the GDMO / GRM templates
and the syntax is confined to ASN.1 modules.  From the perspective of
a tool implementor, from the perspective of a standards developer, and
from the perspective of a users I can report that this was a serious
mistake.  Not only does such an approach make specifications unnecessarily
difficult to read, write, and understand, it also make specification
configuration management and conformance statements even more complicated
than they need to be.

We've had standardized formal notations for describing network management
configuration data for about twenty years now.  Perhaps it's time we
started to learn from the successes and failures of the past, rather
than pretending that we don't have any idea what the requirements are
and that we're starting with a blank slate.

Randy

---

From: "tom.petch" <[email-masked]>
Date: Mon, 4 Feb 2008 12:49:17 +0100

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Cc: "Eric Rescorla" <[email-masked]>
Sent: Thursday, January 31, 2008 8:14 PM
Subject: Re: [NGO] FW: BOF Comments: CANMOD

> configuration management and conformance statements even more complicated

I think that there is a balance to be struck here; I quite like getting to know
a topic by reading the semantics without having to delve into the formal syntax
or even, as I sometimes have to, reverse engineer that syntax in order to make
sense.  It does not mean that the semantics have to be in a separate document -
although that is convenient - but it does mean that they should be clearly
separable eg with DESCRIPTION clauses that can easily be picked out by eye - or
by machine - and are sufficiently detailed to be read standalone.

I think that this is something that RFC3216 missed.

Tom Petch