On Tue, Dec 22, 2015 at 5:07 AM, 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 > conclude on a more elegant solution, it would be great to avail ourselves > to that solution. > > At the last IETF, the consensus in the room was to use an RPC-based solution. Has that changed? What aspect of the RPC-based solution is blocking data model development? > Thanks, > Acee > Andy > > > > > > >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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
