Re: 8.1) <get-all>

[Andy Bierman <abierman@cisco.com>]

At 07:11 AM 2/25/2004, Phil Shafer wrote:
>I'm just confused about whether you are saying you see a group of
>folks who are concerned about an issue or whether there's a real
>concensus that this is an issue.  I see some discussion but not a
>consensus.

Agreed -- there's enough interest to continue the discussion
to some resolution.


>Anyway, I see the issue as more style than anything.  As a programmer,
>I see the rpc methods as functions in an API.  A get_config()
>function sits well with my view.  Putting everything under a single
>get() function doesn't.  I think it fits better with the netconf
>idea of solving real problems in real terms, rather than generic
>ones in generic terms.  We want to deal with configuration in a
>specific sense, just as we deal with running configurations and
>candidate configurations as specific datastores with specific,
>well-known behaviors.
>
>This also fits with the design goal that the API should say what
>it means, rather than allow important operations to happens as
>side-effects of generic operations.  For example, we have a 'commit'
>operation, not a commit operation that happens as a side-effect of
>copying files.

I agree 100% with Phil.  It's been my experience that 
well-constrained APIs are easier to maintain over time. 
The gateway design, e.g., get(...) assumes that all variants
will need the same set of parameters.  This is usually not 
the case, over time.  You end complicating all of your
API sub-functions, and adding dummy parameters to pass, 
touching code that really shouldn't be affected, etc.
The localized cost of adding a new parameter or a new
sub-function becomes too high.

In I-D and XSD terms, it's easier and better to have a
well-defined set of stable interfaces.  It's easier in
the I-D to avoid unintended consequences and complicated
conditional text.  It's important in the XSDs to represent
the true set of possible instance documents. XSD can't
encode restriction semantics such as "if parameter 2 is 
'config' then parameter 4 is mandatory, otherwise it's not allowed".

Once we have instance naming, access control granularity,
wildcard expressions, instance and object aggregation, 
meta-data filtering, and other fun topics worked out, we 
will be able to consider adding powerful new protocol operations
that provide more than simple element sub-tree filtering.  Until then, 
we should just focus on configuration, and leave potential feature
additions out of the document.

Currently, we have no direct support for <edit-state> (e.g.,
clear entry X in the ARP cache).  We had this operation in
the draft for awhile, but removed it because there were
too many unresolved data-model-relate issues.  You have to 
use <rpc> directly for now for 'exec' operations. 

Since we already know that the parameter set for <edit-config>
is going to be different than the set for <edit-state>, why 
would we want to combine them into one <edit> operation?
  

>The unix syscall API could have been reduced to the simple, generic,
>easily documentable function 'syscall()', but think of the utility
>that would have been lost.  Specificity wins for developers on
>both sides of the netconf.
>
>Thanks,
> Phil

Andy




>P.s.: And trust me, I never pick on _anyone's_ speling. ;^)
>
>
>
>"Tim Stoddard" writes:
>>Phil,
>>
>>see 2, add the word growing before it. Then show me a political group
>>without a single dissenter, see 1.
>>
>>
>>1. An opinion or position reached by a group as a whole: ?Among political
>>women... there is a clear consensus about the problems women candidates have
>>traditionally faced? (Wendy Kaminer). See Usage Note at redundancy.
>>
>>2. General agreement or accord
>>
>>sorry about the spelling if that was your point.
>>
>>thanks,
>>
>>Tim
>>
>>-----Original Message-----
>>From: Phil Shafer [mailto:phil@juniper.net]
>>Sent: Wednesday, February 25, 2004 9:24 AM
>>To: tstoddar@utstar.com
>>Cc: 'Randy Presuhn'; netconf@ops.ietf.org
>>Subject: Re: 8.1) <get-all>
>>
>>
>>"Tim Stoddard" writes:
>>>I want to re-emphasize that I believe there is growing concensus (I never
>>>said majority) that understands ....
>>
>>Huh?
>>
>>xhttp://dictionary.reference.com/search?r=2&q=consensus
>>
>>Thanks,
>> Phil
>>
>
>--
>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/>