Re: url clarification

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Hi,
> >
> >
> > Andy Bierman <ietf@andybierman.com> wrote:
> >   
> >> Martin Bjorklund wrote:
> >>     
> >>> It says (8.8.5.1) that <url> must be accepted as an alternative to
> >>> <config>, i.e. as the "source" of the edit-config command.  And it
> >>> must be a local file (for some reason).  The <target> parameter cannot
> >>> be an url.
> >>>
> >>>   
> >>>       
> >> oops -- you're right.
> >>
> >> So the text is right and the XSD is wrong.
> >> The "rpcOperationTargetType" needs to be changed
> >> to "configNameType" for edit-config, lock, and unlock.
> >> End of problem.
> >>     
> >
> > I still think that allowing a url as "source" to <edit-config> is a
> > problem, or at least quite limited.  If it has to be a local file (as
> > it is now), this file must be created somehow.  D.1.2 shows an example
> > where the file is created by doing a <copy-config> to the file.  Then
> > in D.1.5 the file is used in <edit-config>.  This is a "type-mismatch"
> > problem.  The <config> parameter of <copy-config> is a "complete
> > configuration datastore", but the <config> parameter of <edit-config>
> > is not - it's "all or part" of a configuration.
> >   
> 
> 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.

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


> > 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."



/martin

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