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 conclude on a more elegant solution, it would be great to avail ourselves to that solution. 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 > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
