> On 09 Dec 2015, at 17:41, Robert Wilton <[email protected]> wrote: > > Hi Lada, > > On 09/12/2015 15:56, Ladislav Lhotka wrote: >>> 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. > I would think that in a tightly constrained environment (e.g. an ISP that is > controlling all the network mgmt clients and network device > implementations/versions) might just have specific schemas defined and > supported on the clients. > > But I can also quite easily imagine other off the shelf clients that have > been written to be more flexible. I.e. they will handle the specific nodes > that they are interested in but otherwise ignore other unknown nodes that may > be due to vendor specific augmentations or future version upgrades. > >> 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? > OK, I'm not actually convinced this specific example is a problem, if > launching missiles is the correct/normal default behaviour for the new > version of the YANG module! > > But I agree with you that this isn't necessarily exactly the same > service/support. Perhaps a better way that I could have express this would > be along the lines of: "The existing nodes used by an old client should still > provide a consistent service inline with the documented description of the > older version of the YANG module". I.e. a updated module should be allowed to > provide new optional functionality which may also include appropriate > defaults, but it shouldn't be changing the semantics of the existing > functionality specified in the older version (excluding bug fixes). > > But I do get your general point that the YANG language can't really prevent > someone from doing something silly or naughty when either augmenting or > upgrading a module, and I also agree with you that there is a limit to how > much we should be trying to prevent this. For me, the compromise is that we > should try and make it hard to have accidental violations, but not try overly > hard to prevent the wilful violations.
Yes, exactly! I do agree it is useful to be able to upgrade a network gradually without breaking management tools but it's IMO a matter of data-modelling discipline and careful planning. So everybody should read 6087bis to be aware of the potential problems for backward compatibility, but cluttering the specification of a data modelling language with convoluted CLRs in order to prevent incompatible updates of the data model is IMO wrong. Lada > > Thanks, > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
