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

[Mark Ellison <ellison at ieee.org>]

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.

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.

> 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

>
>> -----Original Message-----
>> From: netconf-bounces at ietf.org
>> [mailto:netconf-bounces at ietf.org] On Behalf Of ext Andy Bierman
>> Sent: Friday, October 02, 2009 2:13 AM
>> To: Mark Scott
>> Cc: netconf at ietf.org
>> Subject: Re: [Netconf] [NETCONF] <get-schema> mandatory parms
>> discussion
>>
>> Mark Scott wrote:
>> > Andy,
>> >
>> > A rationale for not modifying the mandatory parameters in
>> <get-schema>
>> > was posted to the ML on Sept 16th.
>> >
>> > I suspect you missed that based on the comment below so I
>> am repeating
>> > it here for further discussion:
>> >
>> >     "2.  <get-schema> mandatory parameters:  Initially <identifier>
>> > was the only mandatory parameter in the <get-schema>
>> operation, however
>> > after we agreed to expand the key definition in the schema
>> list we made
>> > <version> and <format> mandatory parameters in the operation.  My
>> > preference would be to keep this alignment between the key and
>> > <get-schema> mandatory parms.  I agree in cases where only
>> 1 revision
>> > and/or 1 format exists this is heavy-handed but it protects against
>> > agents returning schema a manager may not have intended since
>> > <identifier> is not unique in schema list and the logic on agent to
>> > select the default revision may differ from what the
>> manager would have
>> > selected (esp. if more than 1 version exists)."
>> >
>> > Previously no one else had objected to these being
>> mandatory parameters
>> > and no ML consensus had been reached to modify it.
>> >
>>
>> I don't understand why the <get-schema> RPC
>> is coupled to the /netconf-state/schemas data structure.
>>
>> Revisions are optional in YANG.  A valid module
>> can exist without a <version>.  This module forces
>> a YANG module to use the empty string as the
>> version, which is somewhat of a hack.
>>
>>
>> > I have changed the subject header of this email in an attempt to
>> > initiate a ML discussion and will update the draft based on
>> consensus.
>> >
>> > Mark
>> >
>>
>> Andy
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf at ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> _______________________________________________
> Netconf mailing list
> Netconf at ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>