Subject: RE: Decision on NETCONF charter extensions

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 14 Sep 2005 22:46:51 +0300

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. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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: [email-masked] 
> [mailto:[email-masked]] 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 [email-masked] 
> 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 [email-masked] 
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Sep 2005 14:06:03 -0700

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

>Dan

Andy