[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll for consensus on edit operations

On Thu, Apr 01, 2004 at 03:49:59PM -0800, Rob Enns wrote:
> 
> But this is big and unwieldy. Along the lines of one of Andy's
> suggestions, this kind of request:
> 
> <modify
> start-path="//chassis/slots/slot[instance-id='3']/ports/port[instance-id
> ='7']">
>   <duplex-mode>auto</duplex-mode>
> </modify>
> 
> is attractive. However this would make at least a subset of XPATH
> a requirement. Also once we've started moving down this road the next
> logical place to stop is XSLT. Why stop with just one memory hungry
> standard when you can have two?

Ignoring your polemic comments, I still wonder why parsing

    "//chassis/slots/slot[instance-id='3']/ports/port[instance-id='7']"

is more memory hungry than parsing the following XML fragment:

    <chassis>
      <slots>
        <slot instance-id="3">
          <port instance-id="7">
          </port>
        </slot>
      </slots>
    </chassis>

> I'd like NETCONF to be something that does not require a Ph.D. 
> in XML to understand and use. We should keep it simple. This protocol
> aims to replace screen-scraping, after all. It can replace floor wax
> and dessert toppings in version 2.0.

I think of real operators who are very well able to deal with all sorts
of different CLI interfaces out there in automated ways today (painful 
as it is) and these folks know perl, regular expressions, data bases and
query languages and many of them these days do know at least the basic 
of the core XML technologies (some might even excel in XSLT). If the
core market to get netconf deployed is not this group of operators, 
then we should stop talking to NANOG or RIPE folks and instead listen 
to the many enterprise operators that do not like to talk to us.

[I could not resist to also write a polemic response.]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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