Subject: RE: no NETCONF WG meeting planned for Paris

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 26 May 2005 14:05:46 -0400

hi

Actually, my remembrance is that a number of items were dropped solely as a
scoping exercise. Note because they were not felt to be achievable or
necessary. 

If there is working group consensus to take on additional work and the AD is
sufficiently convinced of its value and achievability, are we then all on
board?

Just a note that the current Netmod work provides a framework to define
content but does not actually define any content.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 26, 2005 12:19 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: netconf
Subject: Re: no NETCONF WG meeting planned for Paris

Sharon Chisholm wrote:

>hi
>
>So, as I indicated in Minneapolis, I plan two presentations into the 
>Paris meeting. One on the Netmod work proposing that gets added to the 
>charter and another on asynchronous messaging with a similar 
>objectives. The technical work is being progressed as we speak.
>
>Are you suggesting that you would like to see the proposed updated 
>charter before Paris?
>  
>
Simon and I both agree that the NETCONF WG should concentrate on finishing
the 1.0 document set and then take a little break -- like until the RFCs are
actually published -- before charging ahead with more features. We would
like to make sure the IESG approves the work we've done so far before
building on that work.  A little time for implementation, inter-operability
testing, and deployment would be a good idea as well.

Before this new work, we would of course need to update the WG charter, and
to do that, we need consensus on that charter.  Neither Simon or myself is
eager to take on the NETMOD work in its current form.  The deferred protocol
features like notifications can be started if there if WG 
consensus.

Of course, every feature on that list is there because it is difficult, 
contentious,
and the WG couldn't reach agreement on it.  I'm not convinced we will do any
better the second time around.  (Prove me wrong -- write a great draft that
wins the WG over.)  Solution proposals full of the same holes as the first
time around aren't going to become WG drafts just because they exist.

More on NETMOD:  My preference is for NETCONF to be content-neutral,
like the document claims.   I would like to see other SDOs and even a 
NETMOD
WG in the IETF define mappings between their data modeling constructs and
the NETCONF protocol (operations and transaction model).   I do not think
a one-size-fits-all solution will ever work, or that the first cut at a 
data modeling
standard will be long-lasting.  Personally, I haven't seen anything yet 
that really
removes enough complexity to be interesting, but I'm confident in the 
next few
years somebody will figure it all out.

>Sharon
Andy

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Andy Bierman
>Sent: Tuesday, May 10, 2005 12:08 PM
>To: netconf
>Subject: no NETCONF WG meeting planned for Paris
>
>
>Hi,
>
>At this time, it appears all WG milestones will be completed before the 
>next IETF, so there are no plans to hold a NETCONF WG meeting at the 
>Paris IETF.
>
>We understand that some people want to continue adding features to the 
>protocol and/or work on standard data models, but this work would need 
>to be chartered first -- a process that has not been started, and not 
>likely to be completed before the next IETF.
>
>
>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: Eliot Lear <[email-masked]>
Date: Thu, 26 May 2005 20:17:17 +0200

I think it's important to do at least one of the extensions so we know 
we have it right.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 26 May 2005 15:03:43 -0400

Hi,

To me, a protocol with no data modeling language and no data models is
close to worthless as a standard. It provides only a "bucket
transport" protocol where the contents of the bucket are proprietary.

I agree the netconf WG needs to focus on the protocol issues,
motivating independent implementations, and starting discussions on
partial locking and other issues that were punted to get 1.0 out the
door. I support Andy and Simon in this.

A Netconf SMI is necessary to allow the development of standards-based
data models, and a NETMOD SMI should be done in a separate WG from the
protocol. If the Netconf WG decided to not try to start a NETMOD WG, I
think that is a mistake.

I recommend starting with an SMI that can map to existing SNMP
information, since there is a wealth of data models already available,
researchers have already developed tools that automate the
translation, and Netconf implementations could use these data models
to demonstrate that the Netconf protocol works properly. SNMP and
SMIv2 are showing their 1980's roots, so we should work on defining a
Netconf SMI in XML to provide additional capabilities, such as nested
data structures. As the SMIv3 effort showed, the SNMP-adapted ASN.1
SMI has too much baggage to be able to design a backwards-compatible
SMIv3 easily. Developing a new SMI in XML will give us a better chance
of advancing the state of the art in NM data modeling.

I also believe that we should start work on SNMPv4 - a version of SNMP
based on XML messaging rather than ASN.1 messaging, leveraging
existing transport layer message security, using an XML-based data
modeling language, and using an access control method that is easier
to read than VACM's OID hierarchies and can be utilized by SNMP and
Netconf, thus sharing many ease-of-use design decisions between the
monitoring and the (separate) configuration protocol standards.

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Thursday, May 26, 2005 2:06 PM
> To: netconf
> Subject: RE: no NETCONF WG meeting planned for Paris
> 
> hi
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2005 18:22:16 -0700

>transport" protocol where the contents of the bucket are proprietary.

There are some pretty powerful features within a
decent transaction model to act on that bucket of XML content.
I know some of us on the design team we're really just
trying to eliminate screen-scraping the CLI with 1.0.
Even if NETCONF is just used as a programmatic interface
to the CLI at first, this is better than screen-scraping.

We've had a mix of proprietary and standard SNMP data from
day one, and it will be no different for NETCONF.

>protocol. If the Netconf WG decided to not try to start a NETMOD WG, I

I don't remember the WG agreeing to work on specific features in the future,
just that work should continue in the WG on protocol features.  I do 
remember
that we were very concerned not to get in the same "SMING/EOS" deadlock,
where each WG wouldn't do work the other one needed.

I'm not against doing the NETMOD work in the NETCONF WG if that's
the WG consensus.  I don't see a lot of energy and momentum around the
current proposal based on the lack of email comments on the NETMOD list.

>of advancing the state of the art in NM data modeling.

I think you are proving my point about the one-size-fits-all myth.
I agree that this could be one of several data modeling approaches
that can be mapped to the NETCONF protocol. 

>monitoring and the (separate) configuration protocol standards.

This sounds interesting (do you mean s/messaging/encoding/ in line 2?)

Andy

>>scoping exercise. Note because they were not felt to be achievable
>>    
>>
>or
>  
>
>>necessary. 
>>
>>>So, as I indicated in Minneapolis, I plan two presentations into
>>>      
>>>
>the 
>  
>
>>>Paris meeting. One on the Netmod work proposing that gets 
>>>      
>>>
>>added to the 
>>    
>>
>>like to make sure the IESG approves the work we've done so far
>>    
>>
>before
>  
>
>>time around aren't going to become WG drafts just because they
>>    
>>
>exist.
>  
>
>>like the document claims.   I would like to see other SDOs and even
>>    
>>
>a 
>  
>
>>NETMOD
>>removes enough complexity to be interesting, but I'm confident in
>>    
>>
>the 
>  
>
>>next few
>>[mailto:[email-masked]] On 
>>    
>>
>>>Behalf Of Andy Bierman
>>>At this time, it appears all WG milestones will be completed 
>>>      
>>>
>>before the 
>>    
>>
>>>next IETF, so there are no plans to hold a NETCONF WG meeting at
>>>      
>>>
>the 
>  
>
>>>Paris IETF.
>>>
>>>We understand that some people want to continue adding 
>>>      
>>>
>>features to the 
>>    
>>
>>>protocol and/or work on standard data models, but this work 
>>>      
>>>
>>would need 
>>    
>>
>>>to be chartered first -- a process that has not been 
>>>      
>>>
>>started, and not 
>>    
>>
>>>to unsubscribe send a message to 
>>>      
>>>
>>[email-masked] with the 
>>    
>>
>>>to unsubscribe send a message to 
>>>      
>>>
>>[email-masked] with the 
>>    
>>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 26 May 2005 22:51:52 -0400

Hi Andy 

> to the CLI at first, this is better than screen-scraping.

And I strongly support that vision. Screen-scraping needs to go. 

But we also need to move past the constraint that any operator must be
able to lock the whole configuration to modify it, and a large number
of other issues that you have collected during the development of
netconf 1.0. Just changing from screen-scraping to XML isn't enough to
meet operators' needs, even if it is a big step in the right
direction.

> day one, and it will be no different for NETCONF.

True, but the SMI and the OID hierarchy allowed us to develop mib
modules in a relatively consistent manner, in a standard format, by
providing an explicit mechanism for defining mibs independent of
vendor, and to identify enterprise mibs versus standard mibs. Netconf
doesn't yet have a standard language for defining schemas, or a
mechanism to identify enterprise schemas versus standard schemas.
Also, SNMP really got a foothold when mib-I and mib-II gave the
industry something solid to build upon, and netconf has not yet done
that.

> where each WG wouldn't do work the other one needed.

I share the concern that different WGs working on interlocking
technologies can hold each other back. I think that is a very bad
trend to support, but as much as I love Bert, I think he is too tied
to breaking the work into smaller units that cannot be accomplished on
their own without the corresponding pieces being able to be worked on
together. EOS/SMIv3 proved the point that the pieces must be worked on
together, and trying to "lock them apart" just doesn't cut it. I
understanbd Bert's concerns about the community's history of not
completing things, but not allowing any flexibility around the SNMPv3
architecture makes it harder than necessaruy to make progress.

But if that is the reality we must deal with, then we should deal with
it aggressively, and at least start work on an SMI, which is a key
element betwen the protocol and the data models. That said, I am a
strong supporter of modularity, where there can be multiple models to
plug into a given subsystem, so I don't have a problem with competing
SMIs or competing data models to make forward progress.

> current proposal based on the lack of email comments on the 

I hear ya. It's hard to get energetic about anything when the politics
discourage WG creation, and it's hard to carry on conversations
effectively on private email lists. I'm not sure how to make progress
in the IETF O&M area given the obstacles that must be overcome in
dealing the "SNMP old dogs" like myself, and WBEM proponents, and XML
proponents that know XML but don't understand device/network
management.

> that can be mapped to the NETCONF protocol. 

Yup. SNMP mib modules are just one approach to data modeling, but mib
modules are fairly ubiquitous and accepted as important by vendors,
and could be a reasonable starting point to prove the protocol works,
then we can work on new data and/or information models more suited to
the XML world, such as the things that we tried to do with SMIv3 but
couldn't get past the SMIv2 backwards-compatibility constraints.

> This sounds interesting (do you mean s/messaging/encoding/ in line
2?)

Yes, the encoding of the messages would be the starting point. But I
also think the richness of RPC messaging could allow us to expand
beyond SNMP's limited operations, while still keeping some simplicty
to the design.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 May 2005 06:22:52 -0700

>meet operators' needs, even if it is a big step in the right

I disagree.
The 2 main deferred features -- partial locking and notifications --
are both simply speed optimizations, which impact a relatively small
number of use cases.   We don't have any serialization in SNMP or
CLI at all!  Concurrent writes can clobber config now, but this
doesn't seem to be a big problem.  I'm not convinced the lack
of locked concurrent writes in NETCONF is a problem yet.

Notifications essentially provide a speed improvement over polling
techniques.  Currently, many CLI applications use SNMP notifications
and SYSLOG for this purpose.  The convenience of receiving async
messages within a NETCONF session is probably balanced out by
the increased localized cost of the NETCONF implementation, and
most likely does not represent a significant percentage of either
the implementation or deployment complexity.

IMO, the lack of these deferred features has no significant impact
on the usefulness of NETCONF 1.0.

As for NETMOD -- I don't see much hope of a WG agreeing on the
one true NETCONF data modeling language.  I agree that would
be the ideal from a standards-POV, but not realistic or even
close to operationally optimal.  E.g., A scheme tuned for SNMP
integration isn't going to work well for CLI-oriented configuration.

Andy