Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

> On Feb 7, 2017, at 8:45 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> Hi Dean,
> 
> 
>> -----Original Message-----
>> From: Dean Bogdanovic [mailto:ivandean@gmail.com]
>> Sent: Monday, January 30, 2017 7:53 PM
>> To: Tianran Zhou
>> Cc: adrian@olddog.co.uk; netmod@ietf.org; opsawg@ietf.org;
>> draft-ietf-netmod-yang-model-classification@ietf.org
>> Subject: Re: [netmod] [OPSAWG] Question on
>> draft-ietf-netmod-yang-model-classification
>> 
>> 
>>> On Jan 23, 2017, at 9:32 AM, Tianran Zhou <zhoutianran@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-bounces@ietf.org] On Behalf Of Adrian
>>>> Farrel
>>>> Sent: Friday, January 20, 2017 12:25 AM
>>>> To: netmod@ietf.org
>>>> Cc: opsawg@ietf.org;
>>>> draft-ietf-netmod-yang-model-classification@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
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> 