> On 17 Jun 2015, at 14:50, Juergen Schoenwaelder 
> <[email protected]> wrote:
> 
> On Wed, Jun 17, 2015 at 02:34:52PM +0200, Ladislav Lhotka wrote:
>> 
>>> On 17 Jun 2015, at 13:51, Juergen Schoenwaelder 
>>> <[email protected]> wrote:
>>> 
>>> On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote:
>>>> 
>>>> 
>>>> Well, but it is exactly what Kent objected against. It is the requirement 
>>>> to support “old clients” that causes the trouble here (and elsewhere). If 
>>>> client A sets “inactive” somewhere, then the datastore semantics will 
>>>> change also for client B that doesn’t understand “inactive” and may be 
>>>> wondering why the server ignores his edits.
>>>> 
>>>> I understand (although RFC 6241 doesn’t say it explicitly) that, unlike 
>>>> YANG extensions, a NETCONF capability advertised by the server can be 
>>>> mandatory for the client in the sense that it has to understand and honour 
>>>> it.
>>> 
>>> There is no way for a client to tell whether a certain capability URI
>>> (it has never seen before) is mandatory to understand or not. In fact,
>> 
>> So it means that, e.g. the annotations from
>> 
>> https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
>> 
>> cannot be safely used by the server even after advertising them via 
>> :conditional-enablement capability.
> 
> Yes, advertisement is not sufficient.
> 
>>> Without further protocol support to negotiate annotations, I think
>>> annotations must be limited to things that can be safely ignored by a
>>> client. I have not read the I-D yet but I would expect that it should
>>> say something like that. ;-)
>> 
>> But it’s not a specific problem of this draft, it would simply mean that 
>> annotations that cannot be ignored cannot be used at all, no matter what. 
>> However, some annotations that have been proposed (and probably used in the 
>> wild) are of that sort.
>> 
> 
> They cannot be used safely until there is an annotation negotiation
> mechanism, or as Martin indicated, a way for a client to explicitely
> enable the functionality associated with certain annotations.

Even this breaks down if an annotation has global side effects. This actually 
seems to be true for the whole idea of a client cherry-picking from the 
capabilities (and YANG modules) advertised by the server.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to