Re: [Netconf] [NETCONF] <get-schema> mandatory parms discussion

[Andy Bierman <andy at netconfcentral.com>]

Mark Ellison wrote:
> On Fri, Oct 2, 2009 at 6:16 AM, Ersue, Mehmet (NSN - DE/Munich)
> <mehmet.ersue at nsn.com> wrote:
>> Hi Mark, Andy,
>>
>> modifying the the mandatory parameters in <get-schema>
>> has been proposed earlier in September. There were no
>> arguments against it at that time.
>>
>> In the sake of progress I would like to ask you to try
>> to converge on a solution.
>> OTHERS: PLEASE speak up if you agree or disagree with
>> any points made by either Mark or Andy.
>>
> 
> I do think the important aspect to a client would be the ability to
> use <get-schema> to retrieve the actual set of schemata in use by a
> server.  I do not think it should be necessary for a client to know a
> priori, or derive from the capabilities present in the server <hello>,
> the name and revision of each schema/YANG module.
> 
> When would a server actually have two revisions of the same schema
> module in concurrent use?  As long as the revision information is part
> of the retrieved schema and a server implements at most one revision
> of a schema, then I see no value in having a client ask for a schema
> by name and revision.
> 
> If the name+revision of each schema does not appear in the server
> <hello>, then maybe there could be a <list-schema> operation to get a
> list of name+revision of each schema utilized by a server and then it
> would be up to the client to get desired schemata from the retrieved
> list.
> 

The operative word is 'if'.
I'm sure these corner-cases are obvious to everyone,
but I'll list them anyway:

 * The module name may appear in a deviation and not
   appear in its own module capability.
 * A module 'A' can import 'B' without giving its revision,
   and there is no module capability for 'B'.
 * A submodule can be included without a revision date,
   and there is no module capability for the sub-module
   (this is not even supported in <hello>, let alone optional).
 * A module may not even have a revision.


> As an alternative to a <list-schema> operation, there could be a state
> data node containing this information, similar to the intent of the
> SNMPv2-MIB sysORTable.
> 

there is already <get select="/netconf-state/schemas"/>

no need for a special <get> operation

>> It would be good if we can bring this to a conclusion
>> and the draft one step further soon.
>>
>> Cheers,
>> Mehmet
>>
> 
> Just my attempt to be helpful.
> 
> Regards,
> 
> Mark
> 


Andy