> On 22 Dec 2015, at 14:07, Acee Lindem (acee) <a...@cisco.com> wrote: > > Hi Lada, > > On 12/22/15, 7:25 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > >> Hi Acee, >> >>> On 22 Dec 2015, at 13:03, Acee Lindem (acee) <a...@cisco.com> wrote: >>> >>> Jurgen, Lada, >>> >>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka" >>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: >>> >>>> >>>>> On 22 Dec 2015, at 12:38, Benoit Claise <bcla...@cisco.com> wrote: >>>>> >>>>> Jürgen, >>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote: >>>>>> >>>>>>> I hope that nobody disagrees that the operational state design and >>>>>>> how >>>>>>> to structure the models are the two blocking factors to publish YANG >>>>>>> models. If you disagree or don't see this, let me know, I should >>>>>>> communicate better. >>>>>> Even if it may spoil your day, I disagree that there is a blocking >>>>>> factor that should stop us from publishing models. >>>>> Interestingly, I received that feedback again recently, this time from >>>>> the OSPF and ISIS YANG model authors. >>>> >>>> Did they mention any reason *why* it is a blocking factor for their >>>> modules? >>> >>> This should be obvious - the OSPF and IS-IS WG are not going to publish >>> YANG models that don’t meet the ops-state requirements. Why would we >> >> Can you please explain what specific ops-state requirements aren't met in >> those modules? I am interested because the same problem may possibly be >> present in our ietf-routing module. > > That’s easy - the requirements as stated in > https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ > > We could go back and reorganize the IGP models and add separate leaves for > intended and applied config and meet these requirements. However, if we
OK, so you probably already have a solution for implementing intended and applied configuration. In my view, since intended and applied configuration have identical schemas (Requirement 1C), there is no reason for repeating any leaves in the data model. > conclude on a more elegant solution, it would be great to avail ourselves > to that solution. I don't know whether it is more elegant but certainly a possible solution is to have a separate datastore for applied configuration and use the same data model (config true part) for both intended and applied configuration. Lada > > Thanks, > Acee > > > >> >> Thanks, Lada >> >>> publish standards that don’t meet the requirements and are, >>> consequently, >>> irrelevant? Failure to recognize this is a real blocking issue. >>> >>> Acee >>> >>> >>> >>> >>>> >>>> Thanks, Lada >>>> >>>>>> There seem to be >>>>>> ways to address the requirements without having to block all work or >>>>>> to redo what that we have published. >>>>> That's my hope too. >>>>>> But sure, if you make it a >>>>>> blocking factor, it will be one. >>>>> I'll chose to ignore this last sentence. >>>>> >>>>> Regards, Benoit >>>>>> >>>>>>> I hope that nobody really believes that because some people in IETF >>>>>>> (or >>>>>>> in any other SDOs) thinks that what those operators want is a bad >>>>>>> idea, >>>>>>> those operators will not get what they request/pay for from their >>>>>>> suppliers. >>>>>> To be fair, those operators also tell us that they use protocols that >>>>>> are not IETF protocols and it remains somewhat unclear what those >>>>>> protocols are we are expected to optimize data model solutions for. >>>>>> >>>>>> /js >>>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
