Re: url clarification

[Andy Bierman <ietf@andybierman.com>]

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>

*Note to Rob!!*
There is a bug in the example at the top of page 92 in prot-11.

It shows <url> being used the way it is in every other parameter,
as a child node instead of a replacement node.

 <edit-config>
   <target><running/></target>
   <config>
       <url>https://example.com/config/myConfig.xml</url>
   </config>
 </edit-config>


> 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.
I don't think the spec needs to get too detailed here.  There is already
plenty of documentation on URL schemes. 


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


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