Oscar González de Dios <oscar.gonzalezded...@telefonica.com> wrote: > > > -----Mensaje original----- > De: Martin Bjorklund <m...@tail-f.com> > Enviado el: martes, 11 de febrero de 2020 11:00 > Para: Oscar González de Dios <oscar.gonzalezded...@telefonica.com> > CC: ops...@ietf.org; netmod@ietf.org > Asunto: Re: [netmod] Question on how to design a Yang model to reflect > auto-asignment of a give leaf > > Hi, > > Oscar González de Dios <oscar.gonzalezded...@telefonica.com> wrote: > > Dear OPSAWG and Netmod colleagues, > > > > During last IETF Opsawg meeting we raised a question (and > > there was some discussion during the meeting) that we have > > found yet no good answer and we would like to discuss it > > with > > operations and Yang experts. > > > > The use case is the following: We have a yang module which > > holds certain optional leafs. The behaviors that we would > > like > > to have (and distinguish between them) are: > > > > > > a) The user does not provide the value and such value is auto-assigned > > by the system (a device (if it is a device module) or a controller (if > > it is a network/service module)). > > I assume that this value not a static default value? > > [Oscar] True. Should the leaf have a default value, it implies that > "if the value is not set, the default value is taken". > > > b) The user does not provide a value and wants that such value IS NOT > > set by the system (as assigning a value has implications). That is, > > intentionally it is aimed at being left "empty" and should not be > > expanded. So, either the value is set or should remain empty > > Do you mean that you want (a) and (b) at the same time for the same > leaf? > > [Oscar] No. Depending on the leaf, we would like to specify behavior a > or behavior b. Behavior a is ok for most of the cases. The problem is > that in some cases, assigning a value has way more implications and > the service will not work properly. Those case are the ones we wanted > to specifically tackle.
Ok. See below. > > What is the best way to model this behavior? I see that some yang > > modules have added an "auto-assignment" leaf to express if > > auto-assignment is desired or not. (hence, auto-assignment false, and > > leaf not set, would do not assign). > > > > Which is the "default" rule for a leaf that is not set? It is that the > > system is free to create it (via template or any means of > > auto-assignment) or should leave it as is, that is, empty? > > > > In NMDA, the system is allowed to expand a given configuration. This > > fact, in my personal view, implies that by "default" any system could > > implement the "auto-assignment" behavior being compliant with > > Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is > > correct). > > There are (at least) three ways to interpret "auto-assign". The > client writes to running, and then the server auto-assigns X: > > (a) in running > (b) in intended > (c) in the operational state > > (c) is uncontroversial and simple to implement in all servers, and > simple to understand. > [Oscar] agree > > (b) is allowed by NMDA but requires more of the server implementation; > specifically it requires the server to support that intended is > different from running. > [Oscar] Agree . "Theoretically speaking" this is the behavior I would > consider strictly follows NMDA guidelines. Reality is implementations > are yet far from this... > > (a) is not recommended in general; running should be fully owned by > the client(s) and not modified by the server. > [Oscar] Agree. > > [Oscar] So... what would be the best way to specify the behavior? > Explicitly adding an auto-assign leaf to identify the behavior? Just > "obey" NMDA rules? For your "auto-assignment" case, I would describe the behaviour in the description statement. Something like: "If this leaf has not been configured, the server will calculate a value [... specify how ... ] and use that value operationally. This calculated value is available in the operational state." For your other case (the user really doesn't want a value) I also would document this in the description (unless it's obvious). /martin > > > /martin > > > > > > > Best Regards, > > > > Óscar > > > > ________________________________ > > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > > destinatario, puede contener información privilegiada o confidencial y > > es para uso exclusivo de la persona o entidad de destino. Si no es > > usted. el destinatario indicado, queda notificado de que la lectura, > > utilización, divulgación y/o copia sin autorización puede estar > > prohibida en virtud de la legislación vigente. Si ha recibido este > > mensaje por error, le rogamos que nos lo comunique inmediatamente por > > esta misma vía y proceda a su destrucción. > > > > The information contained in this transmission is privileged and > > confidential information intended only for the use of the individual > > or entity named above. If the reader of this message is not the > > intended recipient, you are hereby notified that any dissemination, > > distribution or copying of this communication is strictly prohibited. > > If you have received this transmission in error, do not read it. > > Please immediately reply to the sender that you have received this > > communication in error and then delete it. > > > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > > destinatário, pode conter informação privilegiada ou confidencial e é > > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa > > senhoria o destinatário indicado, fica notificado de que a leitura, > > utilização, divulgação e/ou cópia sem autorização pode estar proibida > > em virtude da legislação vigente. Se recebeu esta mensagem por erro, > > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > > proceda a sua destruição > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener información privilegiada o confidencial y > es para uso exclusivo de la persona o entidad de destino. Si no es > usted. el destinatario indicado, queda notificado de que la lectura, > utilización, divulgación y/o copia sin autorización puede estar > prohibida en virtud de la legislación vigente. Si ha recibido este > mensaje por error, le rogamos que nos lo comunique inmediatamente por > esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual > or entity named above. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly > prohibited. If you have received this transmission in error, do not > read it. Please immediately reply to the sender that you have received > this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinatário, pode conter informação privilegiada ou confidencial e é > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa > senhoria o destinatário indicado, fica notificado de que a leitura, > utilização, divulgação e/ou cópia sem autorização pode estar proibida > em virtude da legislação vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destruição > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod