Re: url clarification

[Andy Bierman <ietf@andybierman.com>]

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.

It doesn't say you better hope nobody deletes the local or remote
file before the edit-config is done either.  (Since lock is disallowed,
all you can do is hope ;-)


>   
> > > So maybe copy-config to a file is just a dumb verbatim copy?
> > >
> > >       
> > Yes and No -- it depends on the URL scheme and the data models involved.
> >     
>
> When I wrote "copy-config to a file" I meant "copy-config to a local
> file as specified by an url with a 'file' scheme".
>
>   
> > I don't think the spec needs to get too detailed here.  There is already
> > plenty of documentation on URL schemes. 
> >     
>
> I'm not saying that the draft should be changed, I'm just looking for
> clarification.  However, the way the text is written for copy-config,
> this behaviour is not very obvious (from 7.3):
>
>       Create or replace an entire configuration datastore with the
>       contents of another complete configuration datastore.
>   

This means "copy-config is a replace (not a merge) edit operation".

>   
> > > Then in D.1.3, the incoming file (the "all or part" of a
> > > configuration), is validated.  Is this supposed to work?  I.e. is
> > > validate really supposed to validate anything that can be sent to
> > > <edit-config>?
> > >   
> > >       
> > Yes -- the <config> element just provides the config source
> > and the validate (via edit-config test-then-set) happens after
> > the config input is received.
> >     
>
> The example in D.1.3 uses the <validate> command, not edit-config
> test-then-set:
>
>        <validate>
>          <source>
>            <url>file://incoming.conf</url>
>          </source>
>        </validate>
>
> 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.
Certainly, the inline config XML does not have to be a complete 
configuration.
I don't think we can really say much (in the prot spec) about the content
derived from the URL dereference process.


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