Subject: [NGO] Re: BOF Comments: CANMOD

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 29 Jan 2008 11:42:32 -0800

Hi -

> From: Eric Rescorla [mailto:ekr at networkresonance.com] 
> Sent: Monday, January 28, 2008 8:07 PM
> To: iab at ietf.org; iesg at ietf.org
> Subject: BOF Comments: CANMOD
...
> 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.
...

To the point of the first question: none of the obvious candidates,
CMIP's GDMO (with GRM extensions), SNMP's SMI, or DMTF's CIM, seems
to have gotten any traction or interest in this context, perhaps (I speculate)
because all are tied to specific data modeling approaches that would
constrain model designers in ways that would be incompatible with the
netconf ideal of encapsulating CLI.  With the less obvious candidates,
such as RelaxNG, XML Schema, and so on, there is the question of how to
provide the necessary semantics required for the problem space
of network configuraion management.  And of course all sorts of
questions arise when one tries to build a brand new language.

To the point of the second question, everyone on the design team would
be delighted if a solution can be found that is independent of netconf.
However, due to the way netconf has (not) been specified, at the
very least a solution proposal will need to include a substantial
amount of material that provides a "binding" to the netconf
environment, if the complete solution is going to even begin to
address the operator requirements from the IAB workshop.  We differ
in the extent to which we believe the netconf tail will wag the
data model dog - ultimately it's an engineering tradeoff.

Randy

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jan 2008 12:14:53 -0800

> data model dog - ultimately it's an engineering tradeoff.

Don't count me in the camp looking for a protocol independent solution.
I am focused on making NETCONF work as a standard,
which means a complete solution for real configuration management on
real NE products.

Some of the toughest challenges to standardized
network configuration have nothing to do with the DML,
but rather the process in which competing vendors will agree upon
standard configuration knobs in standard NETCONF data models.

The first step is standardizing the NETCONF content layer
is the creation of a DML that is expressive enough to support
transition from complex CLI models to complex XML models.
Expertise in NE configuration management is rather important here.

At the same time, the DML needs to be simple enough to read
that WG participants developing a new data model can understand
complex data models without additional documentation and lots
of examples.  WGs outside the OPS-NM area need to be able
to easily understand how to define NETCONF content, and a DML
that is designed for that purpose is needed to allow that to happen.

Last time I checked, the NETCONF WG was the only WG in the IETF
chartered to develop standards-based network configuration management.
(Except maybe FORCES, but that is not generalized CM.)
After almost zero progress in twenty years in this area, the NETCONF WG
deserves a chance to 'do what it takes' to get some deployment
of standard content.  If successful, then larger applicability
beyond the original NETCONF charter might be appropriate.

> Randy

Andy