> On Feb 7, 2017, at 8:45 PM, Tianran Zhou <zhoutian...@huawei.com> wrote: > > Hi Dean, > > >> -----Original Message----- >> From: Dean Bogdanovic [mailto:ivand...@gmail.com] >> Sent: Monday, January 30, 2017 7:53 PM >> To: Tianran Zhou >> Cc: adr...@olddog.co.uk; net...@ietf.org; opsawg@ietf.org; >> draft-ietf-netmod-yang-model-classificat...@ietf.org >> Subject: Re: [netmod] [OPSAWG] Question on >> draft-ietf-netmod-yang-model-classification >> >> >>> On Jan 23, 2017, at 9:32 AM, Tianran Zhou <zhoutian...@huawei.com> wrote: >>> >>> To add more comments: >>> >>> On the L2SM meeting, several people (4 or more) believed the 3 service >> delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], >> [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually >> device models. >>> >>> I think both of the two I-Ds >> ([draft-ietf-netmod-yang-model-classification] and >> [draft-wu-opsawg-service-model-explained]) can check if those YANG models >> are device models or service models. >> >> The idea is that the classification drafts will provide guidelines for the >> authors to do their own classification. As mentioned in my previous email, >> the only people who will be able to do the right classification, are the >> module authors. > > But you list some examples in each category. If those example modules are > actually not fit in, I think it will mislead and confuse the readers.
Good point. > >> >> Please see I’m using distinction between module and model. Model can consist >> of multiple modules and in models you can get classification ambiguity. >> Modules are much more clear to classify. > > Do you mean usually it's hard to classify the "model"? Because it may contain > many "modules" for different use. Yes. Dean > >> Dean >> >>> >>> Regards, >>> Tianran >>> >>>> -----Original Message----- >>>> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian >>>> Farrel >>>> Sent: Friday, January 20, 2017 12:25 AM >>>> To: net...@ietf.org >>>> Cc: opsawg@ietf.org; >>>> draft-ietf-netmod-yang-model-classificat...@ietf.org >>>> Subject: [OPSAWG] Question on >>>> draft-ietf-netmod-yang-model-classification >>>> >>>> Hi, >>>> >>>> We've been trying to ensure that >>>> draft-wu-opsawg-service-model-explained >>>> is consistent with the latest version of >>>> draft-ietf-netmod-yang-model-classification. In discussions with >>>> Tianran a question has come up. >>>> >>>> In section 2 you have a nice definition of Network Service YANG >>>> Modules and this definition maps nicely to our definition of "service >>>> delivery models". >>>> Furthermore, your figure 1 shows Network Service YANG Modules on the >>>> interface between OSS/BSS and the various network services. >>>> >>>> We have further defined "customer service models" at a higher layer still. >>>> That is, on the interface to the customer. This (of course?) assumes >>>> that the OSS/BSS is not customer code :-) >>>> >>>> However, your discussion of Network Service YANG Modules in section >>>> 2.1 seems slightly at odds, although this may be just ambiguity. >>>> >>>> For example, when you say, "Network Service YANG Modules describe the >>>> characteristics of a service, as agreed upon with consumers of that >> service," >>>> this is not the same as, "This model is used in the discussion >>>> between a customer and a service provide to describe the characteristics >> of a service." >>>> That is, the former case could be arrived at after processing based >>>> on the latter case - processing that we have called "service >>>> orchestration" but might (of course) be what leads to the operator poking >> the OSS/BSS. >>>> >>>> This might all be fine and good, but later in the same section you >>>> say "Network Service YANG Modules define service models to be >>>> consumed by external systems. >>>> These modules are commonly designed, developed and deployed by >>>> network infrastructure teams." And there you introduce two terms that >>>> are previously undefined and only server to add ambiguity. Specifically >> "external to what?" >>>> I could make and argument that the OSS is developed and deployed by >>>> network infrastructure teams, ad also that the OSS is external to the >> network itself. >>>> >>>> And, in between these two quoted pieces of text, you have... >>>> >>>> As an example, the Network Service YANG Module defined in >>>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>>> model for Layer 3 IP VPN service configuration. >>>> >>>> Per my other email, this reference needs to be fixed. But I struggle >>>> to see the L3SM module as consistent with your figure. It may or may >>>> not be consistent with your text dependent on the interpretation. >>>> >>>> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to >>>> show how we (the authors) think L3SM fits into your classification. >>>> Here we place L3SM further up the layering stack. >>>> >>>> [Apologies for not spotting this sooner. The citation >>>> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term >>>> "service delivery" which I took to imply a different module.] >>>> >>>> Thanks, >>>> Adrian >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>> >>> _______________________________________________ >>> netmod mailing list >>> net...@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
