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

RE: url clarification



Hi,

Good idea.  In IPP/1.1 (RFC 2911), we have an operation called 
'Validate-Job' that has the same parameters and semantics as 
'Create-Job' but does NOT change anything on the server (or 
create an actual job).  But all the inter-attribute constraints
are checked.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Balazs Lengyel
> Sent: Friday, February 24, 2006 5:14 AM
> To: netconf@ops.ietf.org
> Subject: Re: url clarification
> 
> 
> Hello
> Is it possible or allowed in Netconf to send in a partial 
> config in a validate operation 
> and ask the node to validate this subtree in the context of 
> the current running 
> configuration. That would be more then validating just the 
> subtree as we could consider 
> broader dependencies.
> I would like a validation saying that if I issue these 
> changes will the running config 
> still be valid ? It would be something like an edit-config 
> operation wit h a test-option 
> set to <test-only>.
> 
> Is there a standard way to do this ?
> (I could do a copy-config to candidate; then edit-config on 
> candidate; then validate, but 
> I am looking for a simpler solution without candidate config.)
> 
> Balazs
> 
> Andy Bierman wrote:
> > Martin Bjorklund wrote:
> >> Andy Bierman <ietf@andybierman.com> wrote:
> >>  
> >>> Martin Bjorklund wrote:
> >>>    
> >>>>> ....
> >>>>>        
> >>>>>>                   
> >>>>> I disagree.
> >>>>> This is in there by design to support configuration servers.
> >>>>> For example:
> >>>>>
> >>>>>   <edit-config>
> >>>>>     <target><running/></target>
> >>>>>     <default-operation>none</default-operation>
> >>>>>     <test-option>test-then-set</test-option>
> >>>>>     <error-option>rollback-on-error</error-option>
> >>>>>     <url>https://example.com/config/myConfig.xml</url>
> >>>>>   </edit-config>
> >>>>>             
> >>>> I agree with you that this would be useful.  But the 
> text in 8.8.5.1
> >>>> says that the url should specfiy a local file.  Maybe 
> that sentence
> >>>> just should be removed?  I don't quite see the point of that
> >>>> restriction.
> >>>>         
> >>> To be picky, it says should instead of SHOULD.
> >>> It really doesn't mean anything normative.
> >>>     
> >>
> >> Yes I noticed that.  Ok, so the intention is that the url can be
> >> remote in this case.  This makes perfect sense to me.
> >>
> >>  
> >>>> Phil's reply was that <validate> needs a complete 
> configuration.  Are
> >>>> you saying that it doesn't?  The text says  "... the 
> <config> element
> >>>> containing the configuration subtree to validate."
> >>>>         
> >>> I don't think the text says that anywhere.
> >>>     
> >>
> >> I should have mentioned the reference, sorry, it's in 8.6.4.1. (My
> >> point here was that the term "configuration subtree" can be
> >> interpreted as a partial config.)
> >>
> >>  
> >>> Certainly, the inline config XML does not have to be a complete 
> >>> configuration.
> >>>     
> >>
> >> Ok.  But then the validation doesn't give you much more 
> than syntactic
> >> checks.  If you first validate a partial config and then 
> try to apply
> >> it with edit-config, the resulting configuration might be invalid.
> >>   
> > 
> > It depends on the data model!
> > In my models, there is a conceptual difference between
> > parameter sets and mere complexTypes (unlike XSD BTW).
> > A parameter set can be validated for referential integrity, but
> > not external dependencies.
> > This is more than syntax-check but less than full-config validate.
> > 
> > BTW, it doesn't say anywhere in the spec that the agent guarantees
> > the input that passed a <validate> will always work in a subsequent
> > <edit-config> or <commit>.  It is a best-effort feature.
> > 
> >> So if you do <validate> on the candidate, it will validate the full
> >> config. 
> > 
> > Yes
> > 
> >>  And <validate> on inline config will validate a partial
> >> config (e.g. it must allow incomplete relations). 
> > 
> > Yes
> > 
> >>  Then the question
> >> is what should <validate> on a local file do?  Should it 
> treat it as a
> >> full config or partial?
> >>   
> > 
> > IMO, it doesn't really matter where the input comes from.
> > The agent can validate what it gets against what it has, 
> the best it can.
> > 
> > To repeat myself -- it doesn't really say anywhere in the spec
> > that URL means MUST be a complete config file, or MUST be
> > same or different format than the representation of the built-in
> > configuration datastores.
> > 
> > The <url> feature is just supposed to be input redirection 
> (in this case).
> > 
> >>
> >> /martin
> >>   
> > 
> > Andy
> > 
> > 
> > 
> > -- 
> > 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/>
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager
> ECN: 831 7320                        Fax: +36 1 4377792
> Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com
> 
> --
> 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/>