[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: no NETCONF WG meeting planned for Paris
Hi Andy
> 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.
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.
> We've had a mix of proprietary and standard SNMP data from
> 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.
>
> 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 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.
> 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.
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.
> 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.
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.
>
> >I also believe that we should start work on SNMPv4 - a
> version of SNMP
> >based on XML messaging rather than ASN.1 messaging, leveraging
>
> 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.
>
> >David Harrington
> >dbharrington@comcast.net
> >
> >
>
> Andy
>
> >
> >
> >>-----Original Message-----
> >>From: owner-netconf@ops.ietf.org
> >>[mailto:owner-netconf@ops.ietf.org] 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
> >>
> >>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:ietf@andybierman.com]
> >>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: owner-netconf@ops.ietf.org
> >>>
> >>>
> >>[mailto:owner-netconf@ops.ietf.org] 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
> >>>
> >>>
> >>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/>
> >
> >
> >
> >
>
>
> --
> 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/>