> On 09 Dec 2015, at 16:24, Robert Wilton <[email protected]> wrote:
>
> Hi Lada,
>
> Please see inline [RW] ...
>
> On 09/12/2015 15:02, Ladislav Lhotka wrote:
>>> On 09 Dec 2015, at 15:28, Martin Bjorklund <[email protected]> wrote:
>>>
>>> Ladislav Lhotka <[email protected]> wrote:
>>>>> On 09 Dec 2015, at 12:52, Martin Bjorklund <[email protected]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> It seems we will not reach full agreement on some of the remaining
>>>>> issues in 6020bis. Re-opening Y26 is one of them. I don't think this
>>>>> is a good idea, but I realize that the consensus is to relax the "MUST
>>>>> NOT augment mandatory nodes" rule.
>>>>>
>>>>> Here is my proposal for new text. Most of this text is copied from
>>>>> 6087bis, so if we add this to 6020bis, 6087bis should probably be
>>>>> updated as well.
>>>> I'd prefer to keep it simple, e.g. as in Rob's proposal:
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU
>>> I don't want to refer to 6087bis here. Note that 6087bis is
>>> Informational. So I basically copied the text from 6087bis.
>> OK, right. In this case I would simply change "MUST NOT" to "SHOULD NOT".
>>
>>>> Your text is rather complicated to understand but
>>>>
>>>> 1. added nodes can be made mandatory using a "must" statement, to
>>>> the same effect.
>>> Yes, and we won't do anything about that. This isn't handled by Robs
>>> text / the reference in 6087bis.
>> Sure, I just don't understand why it is so critical to bother with
>> "mandatory true" if another door for achieving the same is wide open.
>>
>> I believe your main concern (and mine as well) is that rogue vendors may try
>> to create silos by augmenting standard modules with mandatory proprietary
>> stuff. This is a real danger but we can't avoid it anyway.
> [RW]
> Personally I think that there are two areas of concern. The one that you
> have listed above, and also the module upgrade case. E.g. a server has been
> upgraded to a new module version but a client is still coded to an older
> version. The client should continue to have the same service/support
> available as they had previously even though they are not using the latest
> module version.
The service will be different anyway because the server may send the client
unknown data installed by another client that happens to be new. I wonder how
many client implementations are resilient to such schema violations. A
situation where the server and client work with different data models is IMO
extremely problematic and we can't pretend that some CLRs make it safe.
My favorite example is this *non-mandatory* node:
leaf launch-missiles {
type boolean;
default true;
}
If an old client isn't aware of this leaf, it won't encounter any syntactic
problems but is it still the same service/support?
>
>>
>>>> 2. there may be other "safe augments", for example via if-feature,
>>> No, if-feature is NOT safe. See Andy's text in 6087bis.
>> Hmm, section 11 permits a module to be updated with mandatory nodes "if they
>> are conditionally dependent on a new feature". Why is the augment case
>> different?
> [RW]
> I would think that augmenting with if-feature can't be safe because it is
> only the server that chooses whether a feature is enabled, not the client.
Sure, but the same happens if the server advertises a new revision of a module
along with a feature that's defined in that new revision.
Lada
>
> Thanks,
> Rob
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
