Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal

["tom.petch" <[e-mail]>]

Uh huh.

Andy,

I agree with you that XML/XSD is the only realistic alternative.  I have
immersed myself in it over the life of NETCONF and the more I learn the less I
like; the fundamentals are plain wrong (IMnotsoHO).

But, like other not quite perfect pieces of technology in the past, it has swept
most before it so I think it the only choice.

That said, I hope that XPath (even more fundamentally unsound I...) might get
improved so I would make XML a must but try to leave wiggle room for a better
select/filter operation.

Also, I think your initial proposal too all embracing and would rather see it
nailed down more precisely - even at this stage - eg flexible conformance is a
right can of worms whereas the more limited base and towers of SMIv2 should be
enough; while I see nothing that relates to tables and think that while SMIv2
gets tables wrong, it is right to nail the topic down.  I would like a closed
list of bullet items, a sentence each, of what will be covered.  We have
lightyears of experience with MIB modules of what it takes to operate and manage
everything under the sun and so should be capable of reverse engineering that
experience into the topic/concept/... list that this new effort needs to
embrace.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[e-mail]>
To: "Phil Shafer" <[e-mail]>
Cc: "NETCONF Goes On" <[e-mail]>
Sent: Monday, September 10, 2007 4:49 PM
Subject: Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal


> Phil Shafer wrote:
> > Andy Bierman writes:
> >> There are tools that help do it for you, just
> >> like there are C compilers that do the ASM for you.
> >
> > Which is why we standardize C, not ASM.
>
> C is even more powerful than ASM, not less.
> My goal is to have a single language to
> specify everything we do with NETCONF data,
> which provides all the features from XSD that
> we rely on, but in a manner usable by mere mortals.
>
> Unless the new DML covers everything we currently do with XSD,
> then part of the XSD is never going away.  This is a worst-case
> scenario, where we need to learn XSD for part of the NETCONF PDU,
> and another DML for the rest of the PDU, since the 'MIB document'
> will need to contain an XSD for the parts not covered by the new DML.
>
>
> >
> >> BTW, I have 24 years, and a few of them writing
> >> device drivers in x86 ASM.
> >
> > So you grok why only device drivers are written in ASM ;^)
> > (And gcc asm hooks mean you don't even need to do that)
>
> Of course -- total control over the runtime and optimized performance
>
> But my analogy is intended to point out that CPUs still
> need the ASM to work.  They don't run C directly.
> We trust the C compiler to deal with it, but it didn't go away.
>
> >
> >> If people are not willing or able to learn XSD,
> >> then no WGs can ever really effectively standardize
> >> data models that use XSD to define the XML syntax.
> >
> > Given the number of errors and surprises in the netconf
> > xsd (where people _were_ willing or able to learn XSD),
> > how can we inflict this on the rest of the ietf?
>
> You can still introduce bugs into the 'C' version of the data model.
> (Or at least I can, and anybody else who doesn't write perfect code
> all the time  ;-)
>
> >
> >> (That's the Requirements Phase -- the
> >> first 18 months of the 5 year plan.)
> >
> > Are you just trying to make me cry?
>
> Look how long it takes to do anything significant in the IETF and do the math.
> I don't want to put all data modeling on hold until a new DML is
> done, which means limping along with XSD for 5 more years at least.
>
> I would prefer that people learn XSD or invest in tools that
> help them understand XSD files.  However, this does not
> seem to be happening in large enough numbers to reach critical mass.
>
>
> >
> >> Why can't max-access be a property of the data, which is realized
> >> in different ways.  In XSD, it would be an <appinfo> extension.
> >
> > So you need extensions to your lower-level language to handle
> > high-level concepts?
>
> You need to convey high-level info to other applications,
> through the low-level language.  <appInfo> is outside XSD,
> meaning XSD ignores it and just makes it available to higher layers.
>
> XSD-based tools are able to use the <appInfo>, if they are
> extended by programmers to do so.  This is going to be easier
> than rewriting all the XSD tools to use a new DML instead.
>
> IMO, XSD does not go away.  I am trying to generate WSDL and XSD
> so it is 100% write-only.  Human groking of XSD will hopefully go
> away, just like with C and ASM.
>
>
> >
> >> You're right that I don't use XSD to write data models.
> >> I am trying to refine my DML to optimize tool automation.
> >> I think it's way easier to use than XSD, but my language
> >> preference is for a C-like syntax (like SMIng).
> >
> > Amen.
> >
> >> Can agreement on a new DML really be reached in the IETF?
> >> A giant, complicated, "let's do everybody's idea" approach (ala DIFFSERV)
> >> is not going to work.  I am skeptical the WG result will be
> >> better and simpler than XSD.
> >
> > The all-singing-all-dancing approach won't fly, but that doesn't
> > mean we're stuck w/ XSD.  I favor an incremental approach, starting
> > with a small number of important things, getting something working,
> > building trust, and then moving on to other issues.  This approach
> > works well, if future work builds on the initial work, rather than
> > recreating it.
> >
> >> I completely agree that XSD is not the long term solution.
> >
> > My opinion is that the IETF isn't a good place for short term solutions.
>
> A long term solution takes a long time to standardize.
> Something better than XSD, that is as widely supported
> as XSD, would deserve to be the long term solution.
> Just declaring many XSD features "too hard" or "not important"
> is not going to be a long term solution either.
>
> >
> >> I am quite frustrated with the progress that we have had using XSD.
> >> At a previous WG meeting, Simon asked people who did not understand XSD
> >> to abstain from a straw poll.  The count was 3 for, 3 against, 40+ abstain.
> >
> > But _all_ the votes where single digit for/against.  My worry is
> > that this is a sign that folks have completely lost interest.  Which
> > would be very bad news.
>
> The patient is not dead yet.
> The Notification work has been a detour that many WG members
> have largely ignored, for various reasons.  I think there
> is interest in standard data models for NETCONF.  BTW, the
> latest Notification draft is pretty good, and I think we will
> be glad we have the ability to define NETCONF notifications
> along with configuration data, as feature-specific data models
> are standardized in the future.
>
>
> >
> > Thanks,
> >  Phil
> >
> >
>
>
> Andy
>
>
>
> _______________________________________________
> NGO mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ngo



_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo