Subject: [NGO] FW: BOF Comments: CANMOD

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 28 Jan 2008 19:28:27 +0100

Please see below comments from OAB member Eric Rescorla. 

Dan

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Monday, January 28, 2008 8:07 PM
To: [email-masked]; [email-masked]
Subject: BOF Comments: CANMOD

$Id: canmod-proposal.txt,v 1.1 2008/01/28 17:46:17 ekr Exp $

At the last IETF, a group of netconf people requested a BOF to discuss
YANG, a specific modelling language for NETCONF data. Instead, there was
discussion in the APPAREA meeting and a design team was formed to
discuss how to move forward. The design team produced a requirements doc
and there is now a request for a BOF to ask the broader "what to do"
question.

That's a good start, but unfortunately, when I read the BOF agenda, it
seems to rule out all the important high-level questions:

    The community is invited to propose (as an Internet Draft) specific
    concrete data modeling proposals that substantially address the
    requirements gathered by the design team. These proposals should
    explain any additional requirements or features which motivated the
    specific design, which requirements are not met, why, and to what
    extent the approach has been implemented or modeled. Each proposal
    should also include a data model definition for the example
annotated
    instance document.
    
    The BOF will only spend a short time on the requirements gathering
    work and will not debate the validity of the requirements. A case
for
    or against specific requirements may, however, be made during
    presentations of specific solutions.

    ...

    The Working Group is specifically NOT chartered to standardize a
    protocol-independent modeling language, but broader applicability
    of the language should not be needlessly hindered.

    The Working Group will use XX as the starting point for
    standardization. (where XX is the output of this BOF)

When this work was first proposed, the basic questions that were raised
were:

1. Does netconf need to define a new modelling language?
2. Should that language be specific to netconf?

The first question is fundamentally one of requirements, so I don't
really see how the BOF can explicitly rule requirements discussions out
of scope except for discussing individual proposals. I appreciate that
the design team met and came up with a requirements doc (more on that in
a minute) but that has no formal standing. To the extent to which
requirements are important, that discussion needs to be had in the BOF
prior to any beauty contest between various proposals.

If it is determined that a new language is required, whether that
language should be netconf specific is a fundamental policy question
that cannot be made purely by the netconf BOF and surely should not be
decided one way in the proposed charter. That's something that will need
to be discussed in the BOF and then in the broader IETF community.

A more useful BOF would start by exclusively discussing the problem
space and rather than going over detailed proposals, try to make a
determination whether existing technology can do the job (IMO with a
very strong bias towards not reinventing the wheel). If it's determined
that no existing technology can do the job (and confirmed by the IETF
community) then a WG can be chartered to either design a new netconf
specific or IETF-wide modelling language. 

Turning to the topic of the requirements document, this work strikes me
as of fairly minimal value. On the one hand, we have a set of trivial
consensus requirements [there should be a textual representation (18),
there should be a machine readable representation (2)] and on the other
hand we have a bunch of absurdly overspecified non-consensus
requirements [Mandatory extensions (57) and multi-element constraints
(24)]. Language design, even more than protocol design, is a balancing
act and doesn't benefit from this kind of fine-grained requirements
engineering. The useful purpose of a requirements doc would be to serve
as a guide to base language selection and as a general set of principles
for subsequent design. This document doesn't seem useful for either
purpose.

Obviously, there is enthusiasm for this work and so I support having
*some* BOF, but this isn't it. It's certainly not appropriate to have a
BOF which is intended to be the final beauty contest between a bunch of
documents that just showed up and have had no real WG discussion time.

-Ekr

This email was protected during delivery to Avaya with TLS encryption

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 28 Jan 2008 13:34:49 -0500

Hi

Just to answer one of the points. A number of people on the design team
do not feel there needs to be a NETCONF specific language invented and
the wording in the BOF was intended to reflect this. The idea being that
if we started with XML Schema or Relax NG that would qualify as a
NETCONF data modelling framework. Perhaps we need to work on the
phrasing if Eric got the wrong idea from the current text.

Sharon 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, January 28, 2008 1:28 PM
To: [email-masked]
Cc: Eric Rescorla
Subject: [NGO] FW: BOF Comments: CANMOD

Dan

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]]
Sent: Monday, January 28, 2008 8:07 PM
To: [email-masked]; [email-masked]
Subject: BOF Comments: CANMOD

    

    ...

-Ekr

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jan 2008 11:15:06 -0800

> phrasing if Eric got the wrong idea from the current text.

Without commenting on a requirements draft I have not read yet,
I think some criteria must be agreed upon before moving forward,
so the draft has an important purpose -- focusing the
requirements discussion.

On the other hand, since there are fundamental differences
between the priorities of different camps, I don't see how
this is going to happen.  The YANG design team is not creating
a new DML for the fun of it, but rather because a
system for NETCONF-based configuration management needs
the mechanisms and simplicity that YANG provides.

If the bias for the BoF is to hack XSD or RNG until it is simple
enough for humans and useful enough for NETCONF,
then that is likely to be the end result.

Of particular concern to me is the often touted claim that use
of XSD and RelaxNG for NETCONF data model definitions is
somehow ia 'big win' because of all the off-the-shelf tools
that exist for XSD and RNG.

My experience is that no off-the-shelf tools exist which
in anyway, shape, or form, validate NETCONF PDUs against
an internal database, and generate the appropriate <rpc-error>
responses if needed.  On the manager side, these DMLs
need multiple variants of each DM, according to the PDU
that is being generated.

> Sharon 

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 28 Jan 2008 14:23:53 -0500

<Andy>
On the other hand, since there are fundamental differences between the
priorities of different camps, I don't see how this is going to happen.
The YANG design team is not creating a new DML for the fun of it, but
rather because a system for NETCONF-based configuration management needs
the mechanisms and simplicity that YANG provides.
</Andy>

I don't think this has yet been demonstrated. Now that we've gone deeper
into the requirements, I'm still not seeing a compelling reason to
invent something new. We've seen some occasions where one solution meets
a requirement a bit better then another, but so far nothing that really
stands out. I'm hoping by the end of the work to indicate how each
proposal meets the agreed to requirements the way forward will be
clearer and less subjective.

Sharon

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Jan 2008 11:03:04 +0100

> that exist for XSD and RNG.

I think this argument is only secondary. The main advantage of both XSD
and RNG is that they have already been thoroughly tested on a variety of
data models, also in IETF (and yes, these real-life applications
revealed some problems, especially with XSD). Speaking of RNG, there is
sufficient evidence that its formalism and extensibility model is not
fundamentally broken. This can be hardly claimed about any new modelling
language that no one has really used yet.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: David Partain <[email-masked]>
Date: Wed, 30 Jan 2008 00:23:43 +0100

Greetings,

Thanks for your mail.  Sorry, but this mail's relatively long.

> At the last IETF, a group of netconf people requested a BOF to
> discuss YANG, a specific modelling language for NETCONF data.
> Instead, there was discussion in the APPAREA meeting and a design
> team was formed to discuss how to move forward.

Actually, just for clarification, the design team was
specifically tasked with putting together a requirements
document, not to discuss how to move forward.

> The design team produced a requirements doc and there is now a
> request for a BOF to ask the broader "what to do" question.

Yep.

> That's a good start, but unfortunately, when I read the BOF
> agenda, it seems to rule out all the important high-level
> questions:
[BOF proposal text deleted]
> When this work was first proposed, the basic questions that were
> raised were:
>

I agree that these are important questions.  For what it's
worth... Whatever the solution is, it must address the mapping to
the NETCONF environment.  If the solution should also turn out to
be useful elsewhere, that's excellent.  I'm not _opposed_ to that
at all; I simply want to solve the NETCONF problem and don't want
to constrain the solution by forcing its applicability elsewhere.

> The first question is fundamentally one of requirements, so I
> don't really see how the BOF can explicitly rule requirements
> discussions out of scope except for discussing individual
> proposals.

I suppose that the easiest answer is history. Within the network
management community, we've been talking about requirements for a
very very long time.  It all started back when Randy Bush was one
of our ADs and included, amongst other things, an IAB workshop on
network management where requirements were the soul of that
discussion.  In fact, the SMIng Objectives document dates back to
2001, so we were already discussing some of this seven years ago.
We've continued to talk about requirements since then.  My sense
is that there is a strong sense within the network management
community that we already understand the requirements and really
don't want to spend more cycles on that question.  This is my
take; I'm sure others will chime in to tell me I'm nuts.

The requirements design team has resulted in a relatively long
list of things we agree on as well as a not-insignificant list
where we don't.  Given the amount of discussion that has preceded
this over the last several years, I don't believe that additional
discussion in a BOF is going to change anyone's opinion about
what the requirements are or are not for NETCONF.  We need to
decide how we're going to move forward.

The _immediate_ problem we have is that we have a management
protocol we want to use for configuration but no standardized way
to model that configuration data.  The NETCONF community has been
talking about this a LOOOOOOONG time.  Multiple companies have
implemented solutions, all of them proprietary.  At least one of
those is based on XSD, whereas most of the others are languages
invented by the companies (the ones I know about, in any case).
I believe it's time for the IETF to fill this gap or simply say
we're going to leave this up to the vendors.

> I appreciate that the design team met and came up with
> a requirements doc (more on that in a minute) but that has no
> formal standing.

That's not, in my opinion, a proper characterization of what
happened.  The requirements come from the network management
community as a whole over a very long time, as well as from
multiple meetings at the last IETF with folks from the APPS area.
The design team was handed a "complete" list of requirements; we
have only added a small number of requirements in addition to
what was already given as input to the work.

No, it has no formal standing.

> To the extent to which requirements are important, that
> discussion needs to be had in the BOF prior to any beauty contest
> between various proposals.

I will admit that there's a sense of "When is enough enough?"
when I read that.  We've been talking and talking and talking...
and I don't think talking any more is going to change anything
about our understanding of the requirements.

> language should be netconf specific is a fundamental policy
> question that cannot be made purely by the netconf BOF and surely
> should not be decided one way in the proposed charter. That's
> something that will need to be discussed in the BOF and then in
> the broader IETF community.

Of course.  BOFs don't make decisions.  However, BOFs do
demonstrate community consensus (or lack thereof), which is very
important to IETF decision-making.  That's what I'm hoping we'll
achieve with this BOF: a clear consensus on what the network
management community wants (and other interested parties who
invest themselves in this).

> A more useful BOF would start by exclusively discussing the
> problem space and rather than going over detailed proposals, try
> to make a determination whether existing technology can do the
> job (IMO with a very strong bias towards not reinventing the
> wheel). If it's determined that no existing technology can do the
> job (and confirmed by the IETF community) then a WG can be
> chartered to either design a new netconf specific or IETF-wide
> modelling language.

Clearly, I have a different opinion.  I think the IETF's network
management community has talked about the problem space for a
long time -- from SMI to SMIv2 to SMIng to the IAB workshop to
years of the NETCONF working group, to now.  I think it's time to
make a decision and move on.

> Turning to the topic of the requirements document, this work
> strikes me as of fairly minimal value. On the one hand, we have a
> set of trivial consensus requirements [there should be a textual
> representation (18), there should be a machine readable
> representation (2)] and on the other hand we have a bunch of
> absurdly overspecified non-consensus requirements [Mandatory
> extensions (57) and multi-element constraints (24)].

I would note that at least one of the ones you list as "trivial"
(textual representation) is one of the things that operators were
MOST vocal about at the IAB workshop.  I think it'd be very
helpful for those who think that requirements are missing to
explain their requirements now.  Maybe we can deal with them
before the BOF.

> Language design, even more than protocol design, is a balancing
> act and doesn't benefit from this kind of fine-grained
> requirements engineering. The useful purpose of a requirements
> doc would be to serve as a guide to base language selection and
> as a general set of principles for subsequent design. This
> document doesn't seem useful for either purpose.

The design team, I believe, has done what it was asked to do by
our ADs: take the list of requirements, determine which ones had
rough consensus in the group, which ones only certain
constituencies support, and publish that so we'll have something
to demonstrate "compliance" with.

> Obviously, there is enthusiasm for this work and so I support
> having *some* BOF, but this isn't it. It's certainly not
> appropriate to have a BOF which is intended to be the final
> beauty contest between a bunch of documents that just showed up
> and have had no real WG discussion time.

Some of these documents have been around quite a while.  The YANG
draft certainly hasn't just shown up, and neither has the XSD
draft (it's been around for much longer than the YANG draft).
Yes, the others are going to be brand new.

In summary, you want to talk about the problem space and
requirements.  I believe we've done that for far too long
already and it's time to move on.

Cheers,

David

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 30 Jan 2008 11:10:41 +0100

How standard an XSD/RelaxNg based solution can be is one basic point of contention. When you 
put all the extras that are needed for configuration management into XSD/RelaxNg, and you 
remove a number of features that are dangerous or just unneeded, you end up with XSD+- or 
RelaxNg+-. While such a language claims to be a standard language it is debatable whether that 
is true.

Also the biggest part of the work lies outside the area where RelxNg or XSD can help us.

Just as an example: Lately our greatest debates about YANG were about what would a default 
value exactly mean. neither RelaxNg nor XSD tells us whether:
- 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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jan 2008 12:05:18 +0100

> RelaxNg+-. While such a language claims to be a standard language it is debatable whether that 

This very much depends on what you aim at. If your goal is just to
define hierarchical structure of the (entire) configuration & types and
ranges of individual parameters, and validate configurations against it,
then RNG and XSD are good choices and can be used NOW for developing
non-trivial NETCONF data models. However, if you aim at a configuration
data modelling language par excellence (heir of SNMP/SMI) that also
includes other aspects such as semantics related to behaviour of the
device and/or manager, then of course the XML schema languages may not
be sufficient. But: I have nothing aganst YANG, yet it is not mature
enough to be proclaimed now as THE data modelling language for NETCONF.

I agree that some (very few) extensions to RNG/XSD would be handy, but
in RNG such extensions are very natural and non-intrusive - essentially
only carry a different namespace prefix. The point is that the bulk of
RNG formalism, which is based on the theory of tree automata, remains as
sound and stable as before.

As for removals: It's like saying that a programming language with goto
statement is not suitable for a certain problem. Some guidelines for
NETCONF related data modelling will be necessary anyway, so there could
be a warning against mixed content etc. By the way, I can imagine cases
when mixed content might be useful even in a configuration.

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

Defaults are exactly one of the aspects that have no meaning in the
context of validating configurations: you only want to check that a
given parameter is in the right place, of the given type and within
prescribed limits.

Information about defaults may be important and could be formalised, but
it is IMO another level of semantics that should not be mixed together
with the rules that define valid content of configurations.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2008 06:57:04 -0800

> enough to be proclaimed now as THE data modelling language for NETCONF.

1) The NM community in the IETF has been working on this 'MIB stuff'
    for a long time, and there are many more properties needed for
    network management data than XSD/RNG support - which is what you
    would expect because XSD/RNG models XML instance documents,
    not conceptual network management data-stores.

2) The 2nd attempt at a DML for NM (SMIng) failed because the charter
    was fatally flawed from the start.  Combining SNMP and COPS-PR was
    a political decision, not a technical decision based on good engineering.
    Many technical advancements were made in SMIng and SMI-DS, but
    they were dropped along with everything else, when the SMING WG was closed.

3) Although YANG is the refined result of the SMING WG and lots
    of proprietary work, it is being offered as the starting point
    for a YANG WG to reach consensus on all the details.  Of course,
    the YANG design team thinks it is pretty close to done, but
    that will be up to the YANG WG to decide.  The -01 version
    (due very soon) has many bug-fixes and improvements.

4) At least 3 independent implementations of YANG are in development,
    and more NETCONF-specific tools based on YANG will be available soon.
    There has been a lot of traffic on the YANG mailing list.
    Usually, this would be enough to obtain permission to hold
    a 1 or 2 hour BoF, but not here.  I guess there won't
    be a YANG BoF at IETF #71 either.

5) Why is the concept of a NETCONF MIB language so hard to understand?
    We do not complain that SNMP is the protocol that is used for data
    models defined in SMIv2.  We don't let WGs say "We want to change
    the MIB language all around so we can use it for our protocol."
    We expect that if a MIB is needed to support a protocol, the
    WG will use SMIv2 to define it, and SNMP to access it.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Jan 2008 12:10:55 -0800

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Balazs Lengyel" <[email-masked]>
> Cc: <[email-masked]>; "Eric Rescorla" <[email-masked]>
> Sent: Wednesday, January 30, 2008 3:05 AM
> Subject: Re: [NGO] FW: BOF Comments: CANMOD
...
...

This sense of "validating" is *MUCH* weaker than how the term is
generally understood in the network management community.  This
sense is closer to what we'd probably call merely "well-formed".
Anyone who has done development of management infrastructure for
SNMP, CMIP, CIM or CLI can relate that the "interesting" part
of validating a configuration is not making sure that it
conforms to the grammar, or even type constraints, but
rather the inter-relationships among configuration parameters
that depend on their precise semantics and the quirks of
what a particular piece of hardware can do.

If "validating a configuration" could be done purely in terms of
syntax without worrying about things like defaults, then the
complaints about SNMP's "as if simultaneous" atomicity requirement
could have been rejected out of hand.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2008 17:41:57 -0800

> could have been rejected out of hand.

Thanks for emphasizing the point that I've been trying to make.
The MIB language for SNMP (SMIv2) is designed to describe precisely
what an SNMP manager can do with SNMP protocol operations, wrt/ to any
SNMP agent, and any MIB object maintained in its
conceptual database, as defined by the SNMP protocol.
Gee - this is *exactly* what NETCONF is missing.

The 'well-formed XML' and 'schema-valid XML' that relates to
NETCONF PDUs is not that relevant to the network management
problem that YANG is trying to solve.  An SMI for NETCONF
is needed -- that means the Structure of Management Information
within a NETCONF agent, not within an XML instance document.

As a bonus, the better the SMI is for NETCONF, the better tools
can automate the work of agent and manager application development.
YANG is full of these kinds of clauses (e.g., must, when, default,
mandatory, config, unique, key, presence) that are needed to describe
real-world NETCONF databases.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 Jan 2008 09:44:59 +0100

Defaults are interesting from another aspect.

Default is a concept that IS EXISTING. We might not like it, we might find it difficult to 
agree on its details; but it is out there in the real world, so if we don't provide this 
facility in our language we are ignoring reality.

And IMHO, they are important, just as Randy stated.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2008 09:51:48 +0100

>     not conceptual network management data-stores.

Absolutely, yet in a narrower sense NETCONF as a communication protocol
and contents of data stores utilize the XML paradigms, so a lot of
useful work can be done with the existing XML tools. Real-life data
models developed with RNG or XSD may not include everything that's
needed for network management but still can effectively test whether the
NETCONF infrastructure is sound and complete, whether vendors are really
willing to agree on a common set of knobs etc.

>     they were dropped along with everything else, when the SMING WG was closed.

Yes, I read Juergen's draft, it's a very instructive reading.

>     (due very soon) has many bug-fixes and improvements.

I think YANG is an interesting effort and a lot of work has been already
done, nonetheless I am not sure if it is wise to combine all the
different aspects (data store content, semantics, device behaviour)
under a single formal data model. This could make the data models much
less acceptable for a wide community and their standardisation difficult
- it would be already wonderful if the contents were somehow
standardised and formalised.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2008 10:33:54 +0100

> facility in our language we are ignoring reality.

Well, reality is that defaults are not standardised and IMO a
vendor-neutral mangement system can work well without them being
standardised - as long as the devices tell the manager what their
default values are. Prescribed defaults are just another requirement
that may force vendors to reject a data model and develop their own.
It's quite reasonable to allow a small WiFi router to set defaults
different from a big iron and still use the same data model for a
certain routing protocol.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 31 Jan 2008 10:45:31 +0100

> From: Ladislav Lhotka [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2008 11:34 AM
> To: [email-masked]
> > Default is a concept that IS EXISTING. We might not like 
> it, we might 
> > find it difficult to agree on its details; but it is out 
> there in the 
> > real world, so if we don't provide this facility in our 
> language we are ignoring reality.
> 
> vendor-neutral mangement system can work well without them 
> being standardised - as long as the devices tell the manager 
> what their default values are. Prescribed defaults are just 
> another requirement that may force vendors to reject a data 
> model and develop their own.
> It's quite reasonable to allow a small WiFi router to set 
> defaults different from a big iron and still use the same 
> data model for a certain routing protocol.
> 
> Lada
> 
> --
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C

I do not agree that defaults are just nice to have, and they are actually standardized in the current SMI. In some cases defaults are necessary for network (like in network-wide) management configuration. Many of the routing protocols for example define default values in their specifications for objects that represent timers, costs, etc. and 'return to default' is a common operator command in some situations. This needs to be reflected in the network management MIB and similar. 

Dan

(speaking as contributor)

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 Jan 2008 11:04:02 +0100

You may argue that too many standardized default values are a bad thing.
But do you really want to argue that we should not provide a DML mechanism to define default 
values in a standard way?
Companies have been doing this for ages. If you do not want to provide formalized standard 
methods for such a basic thing why should we do any modeling at all?
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2008 11:37:24 +0100

> values in a standard way?

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.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 Jan 2008 11:59:22 +0100

I think that the idea that standard track RFCs will never want to define a default value is 
somewhat in conflict with past experience.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2008 12:55:10 +0100

> somewhat in conflict with past experience.

RFCs can define whatever is necessary. My point is that the *formal*
specification of defaults be separate and independent from the content.
My approach can actually allow for formally specifying SHOULD and MAY
defaults as well - different devices may advertise the same content
model but different sets of default. Defaults specified in a YANG data
model are always a MUST.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jan 2008 13:52:50 +0100

> model but different sets of default. Defaults specified in a YANG data

It might be instructive to grep DEFVAL in the existing IETF SMIv2 MIB
modules to get an idea what type of defaults previously have been
found useful to standardize on (and many of them are pretty much non
contentious I believe).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Jan 2008 06:34:07 -0800

> willing to agree on a common set of knobs etc.

Well, RNG has been around the entire time NETCONF has existed,
yet so far, nothing has been done to extend RNG for NETCONF.
If RNG was such an obvious choice, it seems like this would
have happened already.

> standardised and formalised.

I disagree.
Many of the concepts in YANG look generic.
Any protocol could build stuff out of containers, lists, leafs, etc.
Big deal.  XSD or RNG could have added this sort of thing
but never did.  The interesting work is describing (as completely as
possible) how the NETCONF protocol can be used with the
NETCONF data on any arbitrary agent.

A different WG could easily reuse these generic concepts
when writing a separate document defining data modeling
for a another protocol.  A generic document that does
not map to any specific management protocol is a complete
waste of time, and there is no point in creating such
a DML for NETCONF.  (We already have XSD and RNG for that.)

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 Jan 2008 16:07:50 +0100

> willing to agree on a common set of knobs etc.
I think we agree on that in a narrower sense NETCONF as a communication protocol could use 
RelaxNg.

However my basic point is that this narrower sense NETCONF is by far NOT ENOUGH for my real 
configuration management use.

Just describing the containment hierarchy and data types, you have done only 50% of the work. 
Then come questions like the exact working of defaults, notification, rules for identifying and 
referencing management objects, custom rpcs, mandatory versus optional, documentation and 
compatibility rules, etc.

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).

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2008 17:01:57 +0100

> If RNG was such an obvious choice, it seems like this would

We actually use some extensions like "role" attribute to indicate list
item keys, wrappers (non-presence containers in YANG terms) etc. in the
schema for our flow monitoring probe, see
http://www.flowmon.org/flowmon-probe/devel/config/hints/

I also devised another RNG extension for schema annotations in
draft-lhotka-relaxng-to-rfc-00.

And I hope we will be able to come up with some extension proposals in
the RELAX NG draft for the BoF.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "David Harrington" <[email-masked]>
Date: Thu, 31 Jan 2008 13:54:59 -0500

Hi, 

> "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.

The IETF already offers mechanisms for standardizing management data,
and the SMI already offers more than what you are proposing as an
improvement. 

I don't agree that we want a DML that only serves one purpose when the
industry is already accustomed to a strategy that uses an SMI and MIB
definitions to serve multiple important purposes. We want to change to
using a DML that can support XML on-the-wire and offers all (or most)
of the benefits (and hopefully less of the disadvantages) of the
existing strategy.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 31 Jan 2008 13:58:04 -0500

I haven't read through YANG recently, but if designed similar to the
SMI, defaults defined in YANG are defaults, not MUSTs. 

If it makes better protocol-sense, implementations are free to apply
different defaults than specified in the standard (but then that
object would be non-standard vis-a-vis its default). 

dbh

> Sent: Thursday, January 31, 2008 6:55 AM
> To: Balazs Lengyel
> Cc: [email-masked]
> Balazs Lengyel píše v Ct 31. 01. 2008 v 11:59 +0100:
> > > Balazs Lengyel píše v Ct 31. 01. 2008 v 11:04 +0100:
> > >> But do you really want to argue that we should not 
> provide a DML mechanism to define default

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Jan 2008 11:33:34 -0800

> SMI, defaults defined in YANG are defaults, not MUSTs. 

defaults in YANG are MUST -- the agent is required to use a valid
default-stmt value, if a leaf is created by the agent that
has a default defined for it.

Do not define a default if it not appropriate to require its use.
Suggested defaults that a manager cannot rely on at all,
and therefore can never safely use, should go in the description clause.

Andy