Hi, Mahesh, Please find one comment inline.
> On Aug 26, 2015, at 9:56 PM, Qin Wu <[email protected]> wrote: > > Hi, Mahesh: > -----邮件原件----- > 发件人: Lime [mailto:[email protected]] 代表 Mahesh Jethanandani > 发送时间: 2015年8月27日 5:11 > 收件人: Tom Taylor > 抄送: [email protected]; [email protected] > 主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06 > > [Adding BFD mailing list back because this decision affects them] > > Tom, > > I was hoping for a rational that went beyond “and you shall …” In addition to what Qin said below, the main rational is to provide higher-level abstractions, beyond the specifics of configuring individual protocols. Thanks, — Carlos, as individual. > > 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. > > [Qin]: See > http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html > http://www.ietf.org/mail-archive/web/netmod/current/msg13113.html > > What device YANG model is applied to this WG is about the following > substructure: > +--rw device > +--rw logical-network-elements > +--rw networking-instances > +--rw networking-instance* [networking-instance-name] > +--rw oam-protocols > | +--rw bfd > | +--rw cfm > | +--rw twamp > Rather than the example quoted in Y-34 > (http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html) > +--rw device > +--rw info > | +--rw device-type? enumeration > +--rw hardware > +--rw interfaces > | +--rw interface* [name] > | ... > +--rw qos > > So In my understanding, device model is more focusing on discussing > organizing different type of models in a > comprehensive structure. For the same type of models(e.g., OAM type), we can > find common structure to make different technology specific OAM models with > same type (i.e.,OAM type)work together. The relationship between these models > are described as several models are extension to one base model. > > The debate on Y-34 is about whether we should add new top level node (device) > on top of another existing top level node(e.g., interface). Device and > interface are of two different types, > > One interesting proposal raised by Lada in > http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html is: > "Extend YANG so that a *specific* schema tree can be grafted at a given data > node." > One example given by Lada in the discussion is: > " > I believe there are other use cases in the existing modules. For > example, the ietf-routing module could simply define the data model for > a single routing instance (i.e. without "routing-instance" list at the > top), and it can be then used without changes on simple devices, and > more complex router implementations can graft it as a subtree under > "routing-instance", "networking-instance" or whatever. > > " > I think this is something more relevant to what we are doing. I think we > should consider to take this approach. > > 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] > > > > _______________________________________________ > Lime mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lime > _______________________________________________ > Lime mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lime
signature.asc
Description: Message signed with OpenPGP using GPGMail
