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.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
