[Adding BFD mailing list back because this decision affects them] Tom,
I was hoping for a rational that went beyond “and you shall …” Something along the lines of why /lime/bfd is better than /lime -> /bfd. Or why almost all configuration models for BFD that currently work just fine, now have to start supporting CFM like semantics in Maintenance Domain (MD), Maintenance Association (MA) or Maintenance Endpoint (MEP) configuration to realize a BFD session. You might find a similar discussion around the devices YANG model germane to this thought process. In particular, the thread titled "issue Y34 - root node" on the netmod mailing list. Cheers. > On Aug 24, 2015, at 6:10 PM, Tom Taylor <[email protected]> wrote: > > It comes from making the making the draft Standards Track. If you claim to > implement the ultimate RFC, this is a logical consequence, just as for any > other Standards Track RFC. > > Tom Taylor > > On 24/08/2015 8:41 PM, Mahesh Jethanandani wrote: >> Agree with Greg. >> >> I have particular concern about this statement in the draft: >> >> All implementations that follow the YANG framework presented in this >> document MUST implement the generic YANG model presented here. >> >> >> This seems to stipulate a requirement that neither YANG as a language >> nor any existing technology requires, except maybe CFM itself. Where is >> this stipulation coming from and why is it a MUST? >> > > _______________________________________________ > Lime mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lime Mahesh Jethanandani [email protected]
