[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Decision on NETCONF charter extensions
Romascanu, Dan (Dan) wrote:
I have repeatedly stated my opinion, based also on what we hear from our
customers that in the absence of a standard data model the NETCONF work
is not complete, and cannot offer the level of interoperability that is
expected from an IETF protocol. I believe that the WG chairs are raising
the threshold at an level that is unprecedented high in the IETF asking
for data modeling specifications to be written and prototype
implementations be shown as a condition for the work being chartered. I
respectfully disagree with this position, and I believe that the SMIng
example that they are bringing as the precedent to avoid does not apply,
because SMIng was a refinement, actually a third version of the SMI for
SNMP, long after SNMP had a chance to reach standard interoperability
because both the protocol and the data model were defined from the
start. To use a aeronautics metaphor, while SMIng may have been a raise
in altitude from 30,000 to 39,000 feet NETCONF is not even given a
chance to take off in the absence of a standard data model.
I disagree that we are starting from zero wrt/ data modeling.
1) Language
There are existing languages (XSD, RelaxNG) for defining
templates for valid XML instance documents. There may be
standard 'appinfo' extensions, and other usage conventions
that may be helpful, but the WG should not reinvent XSD
or something like it.
2) Data Models
We started SNMP with little more than a handful of counters
for the protocol itself. We could finish the netconf-state data
model that was pulled from the PROT spec, as a separate effort.
Somebody could publish an Interfaces data model as well.
Somebody could publish a standard for converting SMIv2 MIBs
and SNMP PDU payloads to an XML syntax, which happens
to comply with NETCONF payload requirements. None of
these things have to be done in the NETCONF WG.
The NETCONF protocol is intentionally content-neutral.
We aren't going to define any CLRs for this content.
(There are already people defining CLRs for XML, so we
don't need to duplicate that work.)
The NETCONF WG is never going to attempt the create
technology-specific data models -- these will need to be
developed within WGs close to the particular technology being modeled.
3) Raising The Bar
Yes indeed, the bar is being raised for introduction of new work.
The ADs and co-Chairs want people to do the "sandbox" phase
on their own and bring somewhat-proven (I say 'somewhat'
because there are no rigid standards to meet). If you can say
"we've implemented this and network operators have used it and like it",
then you can also say "I think the WG should standardize it."
As previously stated, we want to see some proof that
operators will use NETCONF before we invest more standards
effort in it. IMO, the old argument "there are no standard data
models for configuration" is not very compelling because operators
have never had that, and aren't really expecting it very soon.
Clueful developers and operators will be able to evaluate the protocol
wrt/ ease-of-use, standard and proprietary RPC calls, and error responses.
We're just looking for people to put the protocol to *some* useful work.
We don't expect full-blown management of anything right away.
Regards,
Dan
Andy
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
Sent: Monday, September 12, 2005 6:23 PM
To: netconf
Subject: RE: Decision on NETCONF charter extensions
hi
Actually, I don't believe we were done defining the charter
updates either. I had planed one more rewrite after Paris
before submitting again. But that likely doesn't have much
bearing on this discussion, so let me ask a question and make
a couple points.
Netconf Events does not require an extension to the charter.
Should we assume then that work is still a candidate for
short term inclusion in the charter?
Those of us working on various bits of netconf phase 2 still
feel the current gaps are critical to be addressed and will
continue to progress that work to support our Netconf
implementations. Please let me know if you are interested in
participating in discussions.
I have heard a lot of offline support for the netconf phase 2
work, but people have not echoed that support to the mailing
list. This understandably gets interpreted badly by the chairs.
Just a note though that from the bakeoff we saw that
ambiguities in the data model specification framework led to
non-interoperable implementations. Also note that there was
at least one operator who strongly supported Netconf Events
in the face to face meeting in Paris.
Sharon
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, August 18, 2005 11:37 AM
To: netconf
Subject: Decision on NETCONF charter extensions
Hi,
Simon and I have been discussing the status of the WG with
our ADs. The four of us do not believe that the charter
extension proposals presented to date are sufficiently
complete, or widely accepted by the WG, to justify new
NETCONF work at this time.
As Bert stated at the WG meeting in Paris, the following
goals have much higher priority:
- getting more implementations of the current document set
- getting a show of buy-in from operators that they are
indeed playing/testing with implementations
- getting a nod/ack from operators that the protocol
makes sense and will be used
We need to see operator buy-in before we go too far down this
path, and end up in the same situation as we ended up with
SNMP. W.r.t. new work by this WG, the ADs would like to see
the proponents of such new work:
- work hard on implementations of the current specs
- show prototypes of implementations of the suggested
enhancements
- work hard on initial data modeling specs and show that
there is convergence in thinking before we charter it.
(remember the SMIng efforts? we do not want to end
up in the same deadlock)
- show prototype implementations of such data modeling work
so we get a feel of what it is.
For all of the above, get operators to show interest and buy-in.
Andy and Simon
--
to unsubscribe send a message to netconf-request@ops.ietf.org
with the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org
with the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>