Subject: Re: [Netconf] continue-on-error

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Thu, 4 Sep 2008 17:52:38 +0800

Surely we have to check the well-formedness of the XML before we execute
on it especially
for config. We are talking about applying configuration to a box. You
would think having 
valid XML framing would be critical in interpreting the context
correctly. When you are displaying
badly formed HTML what's the worst that can happen, it doesn't align on
screen properly,
but if you apply config to the wrong interface on a box because you
guessed the wrong XML context
you could seriously disrupt your network.

I assumed the continue-on-error would refer to semantic errors in the
config we are trying
to apply. e.g. lets say I configured a duplicate ip-address, I could
undo/ignore that one config
and just keep applying everything else, but the XML must be well formed.

James.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Thursday, 28 August 2008 9:51 PM
> To: Andy Bierman; Phil Shafer
> Cc: NETCONF
> Subject: Re: [Netconf] continue-on-error
> 
> ----- Original Message -----
> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: "NETCONF" <[email-masked]>
> Sent: Saturday, August 23, 2008 12:29 AM
> Subject: Re: [Netconf] continue-on-error
> 
> > Phil Shafer wrote:
> > > Andy Bierman writes:
> > >> But first, does anybody implement continue-on-error,
> > >> and if so, what does it really mean in your agent?
> > >
> > > "continue-on-error" means "do your best to keep going".
> > > "your best" can't be defined easily, since you're
> > > facing input that contains errors.
> >
> > pretty vague.
> > I used to think it meant there are no errors
> > detected in syntax or constraints, but if
> > an error occurred trying to apply the <edit-config>
> > (e.g., malloc failed), then try to continue.
> >
> > Clearly this is the intent if test-option 'test-then-set' is true.
> > (It actually requires more -- a <validate> must succeed too.)
> >
> > But for my internal <load-config> operation, using the
> > same infrastructure as <edit-config>, I want to
> > skip over syntax errors in one subtree if another subtree
> > is good.
> >
> > You are suggesting that even for <edit-config>, skipping
> > over invalid well-formed XML is OK for 'continue-on-error'.
> > Seems fine to me, since the spec doesn't really say.
> >
> 'continue-on-error' is what (almost?) every HTML browser 
> does.  Look at the
> source for web sites and many if not most is invalid, at 
> least in the sense of
> using mismatched start and end tags, eg for <DIV> <SPAN> <P> 
> <LI> etc so there
> seems a general implementation rule that if a </...> is 
> missing, supply it.
> 
> Easier to do for syntax errors than for misspelt QNaems.
> 
> The better systems I am used to have a classification of 
> errors - eg minor,
> severe, catastrophic - with different actions specifiable for 
> each.  The systems
> I dislike most are the ones that continue on catastrophic 
> errors thus generating
> hundreds or thousands of error messages for one typo 
> (something I see with SMI
> checkers:-(
> 
> Tom Petch
> 
> >
> > > Thanks,
> > >  Phil
> > >
> >
> > Andy
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Thu, 4 Sep 2008 17:52:38 +0800

James.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Sep 2008 06:49:48 -0700

> and just keep applying everything else, but the XML must be well formed.

Well-formed XML isn't very much at all.
Some library code (e.g., libxml2 xmlTextReader)
doesn't even deliver malformed XML to the application.
The parser can hit EOF looking for well-formed XML, etc.

Phil and I were referring to invalid-value and other errors
in well-formed XML.  Clearly, if 'test-then-set' is selected,
then no subset From [email-masked]  Thu Sep  4 06:50:24 2008
Date: Thu, 04 Sep 2008 06:49:48 -0700
From: Andy Bierman <[email-masked]>
To: "James Balestriere (jbalestr)" <[email-masked]>
Cc: NETCONF <[email-masked]>
Subject: Re: [Netconf] continue-on-error
Sender: [email-masked]

> and just keep applying everything else, but the XML must be well formed.

Well-formed XML isn't very much at all.
Some library code (e.g., libxml2 xmlTextReader)
doesn't even deliver malformed XML to the application.
The parser can hit EOF looking for well-formed XML, etc.

Phil and I were referring to invalid-value and other errors
in well-formed XML.  Clearly, if 'test-then-set' is selected,
then no subset of the config should be applied before all
of it passes all 'static' validation tests.  An invalid-value
should never succeed during the 'test phase' yet fail during
the 'apply phase'.

The original intent was to support the 'load startup config'
operation found in CLI.  Config file commands that cause errors
don't automatically crash a router.  This is not always the
case in other applications, such as Apache -- if httpd.conf
has unknown or invalid commands the WEB server will not start.

Andy

of the config should be applied before all
of it passes all 'static' validation tests.  An invalid-value
should never succeed during the 'test phase' yet fail during
the 'apply phase'.

The original intent was to support the 'load startup config'
operation found in CLI.  Config file commands that cause errors
don't automatically crash a router.  This is not always the
case in other applications, such as Apache -- if httpd.conf
has unknown or invalid commands the WEB server will not start.

Andy