subject:"\[onap\-discuss\] \[modeling\] Network Service Descriptor model"

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-24 Thread Xu Yang

Hi Jessie,

Thanks for the update and explanation, it’s clear to me now.

BR,
Xu

From: jessie jewitt [mailto:jessie.jew...@oamtechnologies.com]
Sent: Saturday, August 25, 2018 12:59 AM
To: onap-discuss ; yangxu (H) 
Cc: 郭楚怡 ; denglingli ; 
zhang.maopeng1 ; zhan.jie1 
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
If I understand you correctly, you mean you are not seeing an attribute on 
the diagram that has type "ConnectivityType"? You see it in the table because 
NsVirtualLinkDesc inherits from VirtualLinkDesc which contains the attribute 
called "connectivityType" of type "ConnectivityType". I updated the diagram to 
show this inheritance relationship, so you should see it now. Let me know if 
that is satisfactory to you.
-Jessie

On Thu, Aug 23, 2018 at 7:19 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Thanks for updating.
A quick comment, the diagram is too vague, would you please help update it?

BR,
Xu

From: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 
[mailto:onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>] On 
Behalf Of Jessie Jewitt
Sent: Friday, August 24, 2018 1:39 AM
To: onap-discuss 
mailto:onap-discuss@lists.onap.org>>; 
jessie.jew...@oamtechnologies.com<mailto:jessie.jew...@oamtechnologies.com>
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; denglingli 
mailto:denglin...@chinamobile.com>>; zhang.maopeng1 
mailto:zhang.maope...@zte.com.cn>>; zhan.jie1 
mailto:zhan.j...@zte.com.cn>>

Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

I have updated the Network Service Descriptor 
<https://wiki.onap.org/display/DW/Network+Service+Descriptor+Model+-+Based+on+R2>
 model on the wiki based on recommendations from this team to align with R2.
Two notes:
1. NSD was missing in R2 a nsdIdentifier. This is a must have.
2. Some of the types are empty. I'll fill those in next week.

-Jessie

On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt 
mailto:jessie.jew...@oamtechnologies.com>> 
wrote:
Hi Xu-
Two comments:
1. I will mark association member ends and referenced classes as experimental 
and put them in the output.
2. You don't see things like ConnectivityType on the diagram because it is a 
class diagram and ConnectivityType is a datatype.

-Jessie

On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Please see inline.

Best regards,
Xu

From: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 
[mailto:onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>] On 
Behalf Of Jessie Jewitt
Sent: Thursday, August 23, 2018 1:44 AM
To: yangxu (H) mailto:yang...@huawei.com>>
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; 
onap-discuss mailto:onap-discuss@lists.onap.org>>; 
denglingli mailto:denglin...@chinamobile.com>>; 
zhang.maopeng1 mailto:zhang.maope...@zte.com.cn>>; 
zhan.jie1 mailto:zhan.j...@zte.com.cn>>
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my 
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.
Jessie: Yes, agree

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model.
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD 
model in Papyrus with the R2 model, but fix the issues and prepare this to go 
in clean. I can have it ready by next Monday, hopefully, though I won't be on 
the call.
Further improvement and alignment with ETSI specs are better to be put into R4 
as we are coming to the deadline for the final draft.
Jessie: Agree.
Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.
Jessie: The "attributes" that are not defined are member ends of associations. 
We need to either remove the associations, or add the referenced classes in the 
model. I personally don't think it would be correct to mark them as 
"experimental" as they would be incomplete definitions. For example, you 
reference a Sapd, but don't define the Sapd class? It wouldn't be possible to 
implement something like that.
[xy] I agree, I’m suggesting either we remove t

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-24 Thread Jessie Jewitt

Hi Xu-
If I understand you correctly, you mean you are not seeing an attribute
on the diagram that has type "ConnectivityType"? You see it in the table
because NsVirtualLinkDesc inherits from VirtualLinkDesc which contains the
attribute called "connectivityType" of type "ConnectivityType". I updated
the diagram to show this inheritance relationship, so you should see it
now. Let me know if that is satisfactory to you.
-Jessie

On Thu, Aug 23, 2018 at 7:19 PM, Xu Yang  wrote:

> Hi Jessie,
>
>
>
> Thanks for updating.
>
> A quick comment, the diagram is too vague, would you please help update it?
>
>
>
> BR,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Friday, August 24, 2018 1:39 AM
> *To:* onap-discuss ;
> jessie.jew...@oamtechnologies.com
> *Cc:* 郭楚怡 ; denglingli <
> denglin...@chinamobile.com>; zhang.maopeng1 ;
> zhan.jie1 
>
> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> I have updated the Network Service Descriptor
> <https://wiki.onap.org/display/DW/Network+Service+Descriptor+Model+-+Based+on+R2>model
> on the wiki based on recommendations from this team to align with R2.
>
> Two notes:
>
> 1. NSD was missing in R2 a nsdIdentifier. This is a must have.
>
> 2. Some of the types are empty. I'll fill those in next week.
>
>
>
> -Jessie
>
>
>
> On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt  oamtechnologies.com> wrote:
>
> Hi Xu-
>
> Two comments:
>
> 1. I will mark association member ends and referenced classes as
> experimental and put them in the output.
>
> 2. You don't see things like ConnectivityType on the diagram because it is
> a class diagram and ConnectivityType is a datatype.
>
>
>
> -Jessie
>
>
>
> On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang  wrote:
>
> Hi Jessie,
>
>
>
> Please see inline.
>
>
>
> Best regards,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Thursday, August 23, 2018 1:44 AM
> *To:* yangxu (H) 
> *Cc:* 郭楚怡 ; onap-discuss <
> onap-discuss@lists.onap.org>; denglingli ;
> zhang.maopeng1 ; zhan.jie1 <
> zhan.j...@zte.com.cn>
> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> Hi Xu-
>
>I hadn't seen your response when I answered Chuyi's email. Please see
> my comments embedded below...
>
> Thanks,
>
> Jessie
>
>
>
> On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H)  wrote:
>
> Hi Jessie,
>
>
>
> In R2, we did have a call for approval for the NSD model, as shown in
> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on
> that anymore and focus on improving the current model.
>
> Jessie: Yes, agree
>
>
>
> It’s true that we don’t have a UML diagram for the NSD model on the wiki
> page I give, the proposal from my side is that we create a Papyrus model
> for the NSD (as we are doing it now) and align it with the R2 wiki page,
> fix issues and put it into R3 clean model.
>
> Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD
> model in Papyrus with the R2 model, but fix the issues and prepare this to
> go in clean. I can have it ready by next Monday, hopefully, though I won't
> be on the call.
>
> Further improvement and alignment with ETSI specs are better to be put
> into R4 as we are coming to the deadline for the final draft.
>
> Jessie: Agree.
>
> Regarding the issues, I think you are right the current model is not
> complete, we can either remove those attributes that are not defined or
> mark them as experimental like what we have done for the VNFD model.
>
> Jessie: The "attributes" that are not defined are member ends of
> associations. We need to either remove the associations, or add the
> referenced classes in the model. I personally don't think it would be
> correct to mark them as "experimental" as they would be incomplete
> definitions. For example, you reference a Sapd, but don't define the Sapd
> class? It wouldn't be possible to implement something like that.
>
> [xy] I agree, I’m suggesting either we remove those
> attributes/associations or add the referenced classes and mark those
> classes as “experimental”. For example, either we don’t have any
> attributes/classes called Sapd in the model, or we add an empty Sapd class
> marked as “experimental”. The reason why I’m suggesting to mark the class
> as “experimental” is that

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-23 Thread Xu Yang

Hi Jessie,

Thanks for updating.
A quick comment, the diagram is too vague, would you please help update it?

BR,
Xu

From: onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt
Sent: Friday, August 24, 2018 1:39 AM
To: onap-discuss ; 
jessie.jew...@oamtechnologies.com
Cc: 郭楚怡 ; denglingli ; 
zhang.maopeng1 ; zhan.jie1 
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

I have updated the Network Service Descriptor 
<https://wiki.onap.org/display/DW/Network+Service+Descriptor+Model+-+Based+on+R2>
 model on the wiki based on recommendations from this team to align with R2.
Two notes:
1. NSD was missing in R2 a nsdIdentifier. This is a must have.
2. Some of the types are empty. I'll fill those in next week.

-Jessie

On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt 
mailto:jessie.jew...@oamtechnologies.com>> 
wrote:
Hi Xu-
Two comments:
1. I will mark association member ends and referenced classes as experimental 
and put them in the output.
2. You don't see things like ConnectivityType on the diagram because it is a 
class diagram and ConnectivityType is a datatype.

-Jessie

On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Please see inline.

Best regards,
Xu

From: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 
[mailto:onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>] On 
Behalf Of Jessie Jewitt
Sent: Thursday, August 23, 2018 1:44 AM
To: yangxu (H) mailto:yang...@huawei.com>>
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; 
onap-discuss mailto:onap-discuss@lists.onap.org>>; 
denglingli mailto:denglin...@chinamobile.com>>; 
zhang.maopeng1 mailto:zhang.maope...@zte.com.cn>>; 
zhan.jie1 mailto:zhan.j...@zte.com.cn>>
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my 
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.
Jessie: Yes, agree

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model.
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD 
model in Papyrus with the R2 model, but fix the issues and prepare this to go 
in clean. I can have it ready by next Monday, hopefully, though I won't be on 
the call.
Further improvement and alignment with ETSI specs are better to be put into R4 
as we are coming to the deadline for the final draft.
Jessie: Agree.
Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.
Jessie: The "attributes" that are not defined are member ends of associations. 
We need to either remove the associations, or add the referenced classes in the 
model. I personally don't think it would be correct to mark them as 
"experimental" as they would be incomplete definitions. For example, you 
reference a Sapd, but don't define the Sapd class? It wouldn't be possible to 
implement something like that.
[xy] I agree, I’m suggesting either we remove those attributes/associations or 
add the referenced classes and mark those classes as “experimental”. For 
example, either we don’t have any attributes/classes called Sapd in the model, 
or we add an empty Sapd class marked as “experimental”. The reason why I’m 
suggesting to mark the class as “experimental” is that we don’t have a 
discussion on those classes before (and not likely to have before the 
deadline), marking them as “experimental” shows further discussion and 
refinement are needed.

And as Chuyi pointed out, there’s something on the wiki that are not shown in 
the Papyrus model, update is needed to keep them aligned.

Jessie: I didn't catch what was on the wiki, but not in the model. Can you 
remind me what that is?
[xy] For example, I think several attributes (testAccess, connectivityType, 
etc.) of the NsVirtualLinkDesc class are not shown in the diagram.
Best regards,
Xu

From: 郭楚怡 [mailto:guoch...@chinamobile.com<mailto:guoch...@chinamobile.com>]
Sent: Wednesday, August 22, 2018 1:38 PM
To: jessie.jewitt 
mailto:jessie.jew...@oamtechnologies.com>>
Cc: onap-discuss 
mailto:onap-discuss@lists.onap.org>>; yangxu (H) 
mailto:yang...@huawei.com>>; denglingli 
mailto:denglin..

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-23 Thread Xu Yang

Hi Jessie,

On bullet 2, I mean I don’t see an attribute which is using the datatype in the 
diagram, not sure if it’s omitted because I noticed it in the tables below.

BR,
Xu

From: jessie jewitt [mailto:jessie.jew...@oamtechnologies.com]
Sent: Friday, August 24, 2018 12:41 AM
To: onap-discuss ; yangxu (H) 
Cc: 郭楚怡 ; denglingli ; 
zhang.maopeng1 ; zhan.jie1 
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
Two comments:
1. I will mark association member ends and referenced classes as experimental 
and put them in the output.
2. You don't see things like ConnectivityType on the diagram because it is a 
class diagram and ConnectivityType is a datatype.

-Jessie

On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Please see inline.

Best regards,
Xu

From: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 
[mailto:onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>] On 
Behalf Of Jessie Jewitt
Sent: Thursday, August 23, 2018 1:44 AM
To: yangxu (H) mailto:yang...@huawei.com>>
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; 
onap-discuss mailto:onap-discuss@lists.onap.org>>; 
denglingli mailto:denglin...@chinamobile.com>>; 
zhang.maopeng1 mailto:zhang.maope...@zte.com.cn>>; 
zhan.jie1 mailto:zhan.j...@zte.com.cn>>
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my 
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.
Jessie: Yes, agree

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model.
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD 
model in Papyrus with the R2 model, but fix the issues and prepare this to go 
in clean. I can have it ready by next Monday, hopefully, though I won't be on 
the call.
Further improvement and alignment with ETSI specs are better to be put into R4 
as we are coming to the deadline for the final draft.
Jessie: Agree.
Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.
Jessie: The "attributes" that are not defined are member ends of associations. 
We need to either remove the associations, or add the referenced classes in the 
model. I personally don't think it would be correct to mark them as 
"experimental" as they would be incomplete definitions. For example, you 
reference a Sapd, but don't define the Sapd class? It wouldn't be possible to 
implement something like that.
[xy] I agree, I’m suggesting either we remove those attributes/associations or 
add the referenced classes and mark those classes as “experimental”. For 
example, either we don’t have any attributes/classes called Sapd in the model, 
or we add an empty Sapd class marked as “experimental”. The reason why I’m 
suggesting to mark the class as “experimental” is that we don’t have a 
discussion on those classes before (and not likely to have before the 
deadline), marking them as “experimental” shows further discussion and 
refinement are needed.

And as Chuyi pointed out, there’s something on the wiki that are not shown in 
the Papyrus model, update is needed to keep them aligned.

Jessie: I didn't catch what was on the wiki, but not in the model. Can you 
remind me what that is?
[xy] For example, I think several attributes (testAccess, connectivityType, 
etc.) of the NsVirtualLinkDesc class are not shown in the diagram.
Best regards,
Xu

From: 郭楚怡 [mailto:guoch...@chinamobile.com<mailto:guoch...@chinamobile.com>]
Sent: Wednesday, August 22, 2018 1:38 PM
To: jessie.jewitt 
mailto:jessie.jew...@oamtechnologies.com>>
Cc: onap-discuss 
mailto:onap-discuss@lists.onap.org>>; yangxu (H) 
mailto:yang...@huawei.com>>; denglingli 
mailto:denglin...@chinamobile.com>>; zhang.maopeng1 
mailto:zhang.maope...@zte.com.cn>>; zhan.jie1 
mailto:zhan.j...@zte.com.cn>>
Subject: Re:Re: [onap-discuss] [modeling] Network Service Descriptor model






Hello, Jessie,

  The Network Service model corresponds to the link is not only NSD, it 
includes different classes, and has been discussed and voted in Service IM 
call, I'm sorry you didn't catch the call.

The current NS model is coordinat

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-23 Thread Jessie Jewitt

I have updated the Network Service Descriptor
<https://wiki.onap.org/display/DW/Network+Service+Descriptor+Model+-+Based+on+R2>model
on the wiki based on recommendations from this team to align with R2.
Two notes:
1. NSD was missing in R2 a nsdIdentifier. This is a must have.
2. Some of the types are empty. I'll fill those in next week.

-Jessie

On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt <
jessie.jew...@oamtechnologies.com> wrote:

> Hi Xu-
> Two comments:
> 1. I will mark association member ends and referenced classes as
> experimental and put them in the output.
> 2. You don't see things like ConnectivityType on the diagram because it is
> a class diagram and ConnectivityType is a datatype.
>
> -Jessie
>
> On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang  wrote:
>
>> Hi Jessie,
>>
>>
>>
>> Please see inline.
>>
>>
>>
>> Best regards,
>>
>> Xu
>>
>>
>>
>> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
>> Behalf Of *Jessie Jewitt
>> *Sent:* Thursday, August 23, 2018 1:44 AM
>> *To:* yangxu (H) 
>> *Cc:* 郭楚怡 ; onap-discuss <
>> onap-discuss@lists.onap.org>; denglingli ;
>> zhang.maopeng1 ; zhan.jie1 <
>> zhan.j...@zte.com.cn>
>> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>>
>>
>>
>> Hi Xu-
>>
>>I hadn't seen your response when I answered Chuyi's email. Please see
>> my comments embedded below...
>>
>> Thanks,
>>
>> Jessie
>>
>>
>>
>> On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H)  wrote:
>>
>> Hi Jessie,
>>
>>
>>
>> In R2, we did have a call for approval for the NSD model, as shown in
>> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on
>> that anymore and focus on improving the current model.
>>
>> Jessie: Yes, agree
>>
>>
>>
>> It’s true that we don’t have a UML diagram for the NSD model on the wiki
>> page I give, the proposal from my side is that we create a Papyrus model
>> for the NSD (as we are doing it now) and align it with the R2 wiki page,
>> fix issues and put it into R3 clean model.
>>
>> Jessie: Agree. That's what I proposed to Chuyi. I'll align the current
>> NSD model in Papyrus with the R2 model, but fix the issues and prepare this
>> to go in clean. I can have it ready by next Monday, hopefully, though I
>> won't be on the call.
>>
>> Further improvement and alignment with ETSI specs are better to be put
>> into R4 as we are coming to the deadline for the final draft.
>>
>> Jessie: Agree.
>>
>> Regarding the issues, I think you are right the current model is not
>> complete, we can either remove those attributes that are not defined or
>> mark them as experimental like what we have done for the VNFD model.
>>
>> Jessie: The "attributes" that are not defined are member ends of
>> associations. We need to either remove the associations, or add the
>> referenced classes in the model. I personally don't think it would be
>> correct to mark them as "experimental" as they would be incomplete
>> definitions. For example, you reference a Sapd, but don't define the Sapd
>> class? It wouldn't be possible to implement something like that.
>>
>> [xy] I agree, I’m suggesting either we remove those
>> attributes/associations or add the referenced classes and mark those
>> classes as “experimental”. For example, either we don’t have any
>> attributes/classes called Sapd in the model, or we add an empty Sapd class
>> marked as “experimental”. The reason why I’m suggesting to mark the class
>> as “experimental” is that we don’t have a discussion on those classes
>> before (and not likely to have before the deadline), marking them as
>> “experimental” shows further discussion and refinement are needed.
>>
>>
>>
>> And as Chuyi pointed out, there’s something on the wiki that are not
>> shown in the Papyrus model, update is needed to keep them aligned.
>>
>>
>>
>> Jessie: I didn't catch what was on the wiki, but not in the model. Can
>> you remind me what that is?
>>
>> [xy] For example, I think several attributes (testAccess,
>> connectivityType, etc.) of the NsVirtualLinkDesc class are not shown in the
>> diagram.
>>
>> Best regards,
>>
>> Xu
>>
>>
>>
>> *From:* 郭楚怡 [mailto:guoch...@chinamobile.com]
>> *Sent:* Wednesday, August 22, 2018 1:38 PM
>>

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-23 Thread Jessie Jewitt

Hi Xu-
Two comments:
1. I will mark association member ends and referenced classes as
experimental and put them in the output.
2. You don't see things like ConnectivityType on the diagram because it is
a class diagram and ConnectivityType is a datatype.

-Jessie

On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang  wrote:

> Hi Jessie,
>
>
>
> Please see inline.
>
>
>
> Best regards,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Thursday, August 23, 2018 1:44 AM
> *To:* yangxu (H) 
> *Cc:* 郭楚怡 ; onap-discuss <
> onap-discuss@lists.onap.org>; denglingli ;
> zhang.maopeng1 ; zhan.jie1 <
> zhan.j...@zte.com.cn>
> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> Hi Xu-
>
>I hadn't seen your response when I answered Chuyi's email. Please see
> my comments embedded below...
>
> Thanks,
>
> Jessie
>
>
>
> On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H)  wrote:
>
> Hi Jessie,
>
>
>
> In R2, we did have a call for approval for the NSD model, as shown in
> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on
> that anymore and focus on improving the current model.
>
> Jessie: Yes, agree
>
>
>
> It’s true that we don’t have a UML diagram for the NSD model on the wiki
> page I give, the proposal from my side is that we create a Papyrus model
> for the NSD (as we are doing it now) and align it with the R2 wiki page,
> fix issues and put it into R3 clean model.
>
> Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD
> model in Papyrus with the R2 model, but fix the issues and prepare this to
> go in clean. I can have it ready by next Monday, hopefully, though I won't
> be on the call.
>
> Further improvement and alignment with ETSI specs are better to be put
> into R4 as we are coming to the deadline for the final draft.
>
> Jessie: Agree.
>
> Regarding the issues, I think you are right the current model is not
> complete, we can either remove those attributes that are not defined or
> mark them as experimental like what we have done for the VNFD model.
>
> Jessie: The "attributes" that are not defined are member ends of
> associations. We need to either remove the associations, or add the
> referenced classes in the model. I personally don't think it would be
> correct to mark them as "experimental" as they would be incomplete
> definitions. For example, you reference a Sapd, but don't define the Sapd
> class? It wouldn't be possible to implement something like that.
>
> [xy] I agree, I’m suggesting either we remove those
> attributes/associations or add the referenced classes and mark those
> classes as “experimental”. For example, either we don’t have any
> attributes/classes called Sapd in the model, or we add an empty Sapd class
> marked as “experimental”. The reason why I’m suggesting to mark the class
> as “experimental” is that we don’t have a discussion on those classes
> before (and not likely to have before the deadline), marking them as
> “experimental” shows further discussion and refinement are needed.
>
>
>
> And as Chuyi pointed out, there’s something on the wiki that are not shown
> in the Papyrus model, update is needed to keep them aligned.
>
>
>
> Jessie: I didn't catch what was on the wiki, but not in the model. Can you
> remind me what that is?
>
> [xy] For example, I think several attributes (testAccess,
> connectivityType, etc.) of the NsVirtualLinkDesc class are not shown in the
> diagram.
>
> Best regards,
>
> Xu
>
>
>
> *From:* 郭楚怡 [mailto:guoch...@chinamobile.com]
> *Sent:* Wednesday, August 22, 2018 1:38 PM
> *To:* jessie.jewitt 
> *Cc:* onap-discuss ; yangxu (H) <
> yang...@huawei.com>; denglingli ;
> zhang.maopeng1 ; zhan.jie1 <
> zhan.j...@zte.com.cn>
> *Subject:* Re:Re: [onap-discuss] [modeling] Network Service Descriptor
> model
>
>
>
>
>
>
>
> Hello, Jessie,
>
>   The Network Service model corresponds to the link is not only NSD, it
> includes different classes, and has been discussed and voted in Service IM
> call, I'm sorry you didn't catch the call.
>
> The current NS model is coordinated with the requirements of VF-C, not
> simply copy the ETSI specifications. Since the scope of development plan
> for C-release has been settled, other specific requirements should be
> proposed and discussed in the later releases.
>
>As for the issues you mentioned,  I think you are right about
> the NsVirtualLink, the type of VirtualLinkD

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-23 Thread Chuyi Guo



Hello, Jessie,

About for the #3, I agree with Xu39s suggestion. I think Sapd, Vnffgd and 
etc. should keep, and add the referenced classes in the model. And for the 
papyrus diagram, there should add corresponding empty classes and  their 
associations.



Best Regards,

Chuyi.











邮件原文发件人：jessie jewitt  
收件人：onap-discuss  
,"郭楚怡" 抄　送: "yangxu (H)" 
,denglingli  ,"zhang.maopeng1" 
,"zhan.jie1" 发送时间：2018-08-23 
01:31:53主题：Re: [onap-discuss] [modeling] Network Service Descriptor modelHi 
Chuyi- Yes, it39s my fault for not having reviewed this model when it was 
originally proposed. What I would like to see for Casablanca is that we at 
least "fix" it by doing the following:
1. Use a "pared down" version of the Papyrus NSD model that corresponds to what 
was agreed, so we can output it from there on "clean", using the correct 
associated class diagram.
2. Create the correct classes, and references to other classes and datatypes 
that are already in the model (i.e. ConnectivityType is in our common model)
3. Suppress the references (and associations) that are not desired (meaning 
there is no associated class in the model, i.e. Sapd, Vnffgd) You say they 
haven39t been discussed yet, so I39m curious how the model was approved for R2? 
If you prefer to keep these references, then we need to include the associated 
classes that are referenced in the model.
4. I39m still not seeing a reference to VnfExtCp. Who is referencing that and 
where?

I can prepare a new discussion wiki with what I39m proposing for next Monday39s 
RM call. However, I would need an answer to #3 above. Do you want to remove the 
references to classes that aren39t in your model, or do you want to add the 
classes that are referenced. It would not be a good thing to reference them, 
without defining them, which is currently the case in the model.

-Jessie

On Tue, Aug 21, 2018 at 10:38 PM, Chuyi Guo  wrote: 

 

 

Hello, Jessie,

  The Network Service model corresponds to the link is not only NSD, it 
includes different classes, and has been discussed and voted in Service IM 
call, I39m sorry you didn39t catch the call.

The current NS model is coordinated with the requirements of VF-C, not 
simply copy the ETSI specifications. Since the scope of development plan for 
C-release has been settled, other specific requirements should be proposed and 
discussed in the later releases.

   As for the issues you mentioned,  I think you are right about the 
NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.

   For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven39t been discussed 
yet, so is for VnfExtCp.

   From my understanding, ConnectivityType should be in the NsVirtualLinkDesc, 
which hasn39t been put in the papyrus class diagram , I think it is the point 
where should update.







BR,

Chuyi.







 

 




 
邮件原文发件人：Jessie Jewitt 收件人："yangxu 
(H)" 抄　送: "onap-discuss@lists.onap.org" 
发送时间：2018-08-21 00:41:12主题：Re: [onap-discuss] 
[modeling] Network Service Descriptor model
Hi Xu- The link you refer to in your email to Network Service (which I 
assume is Descriptor) is not a model that is acceptable to me. I certainly 
don39t remember voting on this in R2. Here are some of the reasons I personally 
cannot accept it:
1. There is no class diagram showing the relationships between entities, so I 
don39t really know what concepts you are trying to model. 
2. The relationship that should exist is between NSD and VirtualLinkDesc, and 
not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which should be 
the endpoint of the association) is of type string. That is incorrect.
3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first attribute 
is virtualLinkDescId.
4. Many of the attributes in NSD refer to types that are not defined in the 
model (Sapd, Vnffgd, NsDf...)
5. Same comment above regarding NsVirtualLink. It contains types that are not 
in your model, like SecurityParameters
6. ConnectivityType, as a datatype, has been moved to our Common model, which 
we will need to define as part of our final resource IM in clean, and not a NSD 
model. The benefit of putting datatypes like these in "Common" is that we 
define them once, and then reference them from multiple models, like Resource 
(where NSD lives) and VNF.
7. There is nothing in the model that refers to a VnfExtCp and its relationship 
to NSD.

These are just some of the issues.
I believe a better approach is to take the NSD model defined that is based on 
ETSI (that addresses the above issues) and pare it down to something 
equivalent, if you want.  I39d be happy to update the NSD model to show what it 
would look like.

-Jessie




On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H)  wrote:

Hi All,


 


Thank you for joining today’s resource IM call and having the meaningful 
discussion.


My apologize for

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-22 Thread Xu Yang

Hi Jessie,

Please see inline.

Best regards,
Xu

From: onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt
Sent: Thursday, August 23, 2018 1:44 AM
To: yangxu (H) 
Cc: 郭楚怡 ; onap-discuss ; 
denglingli ; zhang.maopeng1 
; zhan.jie1 
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my 
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.
Jessie: Yes, agree

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model.
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD 
model in Papyrus with the R2 model, but fix the issues and prepare this to go 
in clean. I can have it ready by next Monday, hopefully, though I won't be on 
the call.
Further improvement and alignment with ETSI specs are better to be put into R4 
as we are coming to the deadline for the final draft.
Jessie: Agree.
Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.
Jessie: The "attributes" that are not defined are member ends of associations. 
We need to either remove the associations, or add the referenced classes in the 
model. I personally don't think it would be correct to mark them as 
"experimental" as they would be incomplete definitions. For example, you 
reference a Sapd, but don't define the Sapd class? It wouldn't be possible to 
implement something like that.
[xy] I agree, I’m suggesting either we remove those attributes/associations or 
add the referenced classes and mark those classes as “experimental”. For 
example, either we don’t have any attributes/classes called Sapd in the model, 
or we add an empty Sapd class marked as “experimental”. The reason why I’m 
suggesting to mark the class as “experimental” is that we don’t have a 
discussion on those classes before (and not likely to have before the 
deadline), marking them as “experimental” shows further discussion and 
refinement are needed.

And as Chuyi pointed out, there’s something on the wiki that are not shown in 
the Papyrus model, update is needed to keep them aligned.

Jessie: I didn't catch what was on the wiki, but not in the model. Can you 
remind me what that is?
[xy] For example, I think several attributes (testAccess, connectivityType, 
etc.) of the NsVirtualLinkDesc class are not shown in the diagram.
Best regards,
Xu

From: 郭楚怡 [mailto:guoch...@chinamobile.com<mailto:guoch...@chinamobile.com>]
Sent: Wednesday, August 22, 2018 1:38 PM
To: jessie.jewitt 
mailto:jessie.jew...@oamtechnologies.com>>
Cc: onap-discuss 
mailto:onap-discuss@lists.onap.org>>; yangxu (H) 
mailto:yang...@huawei.com>>; denglingli 
mailto:denglin...@chinamobile.com>>; zhang.maopeng1 
mailto:zhang.maope...@zte.com.cn>>; zhan.jie1 
mailto:zhan.j...@zte.com.cn>>
Subject: Re:Re: [onap-discuss] [modeling] Network Service Descriptor model






Hello, Jessie,

  The Network Service model corresponds to the link is not only NSD, it 
includes different classes, and has been discussed and voted in Service IM 
call, I'm sorry you didn't catch the call.

The current NS model is coordinated with the requirements of VF-C, not 
simply copy the ETSI specifications. Since the scope of development plan for 
C-release has been settled, other specific requirements should be proposed and 
discussed in the later releases.

   As for the issues you mentioned,  I think you are right about the 
NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.

   For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven't been discussed 
yet, so is for VnfExtCp.

   From my understanding, ConnectivityType should be in the NsVirtualLinkDesc, 
which hasn't been put in the papyrus class diagram , I think it is the point 
where should update.







BR,

Chuyi.













邮件原文
发件人：Jessie Jewitt 
mailto:jessie.jew...@oamtechnologies.com>>
收件人："yangxu (H)" mailto:yang...@huawei.com>>
抄　送: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" 
mailto:onap-discuss@lists.onap.org>>
发送时间：2018-08-21 00:41:12
主题：Re: [onap-discuss] [modeling] Network Service Descriptor model
Hi Xu-
 The link you refer to in your email to Net

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-22 Thread Jessie Jewitt

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H)  wrote:

> Hi Jessie,
>
>
>
> In R2, we did have a call for approval for the NSD model, as shown in
> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on
> that anymore and focus on improving the current model.
>
Jessie: Yes, agree

>
>
> It’s true that we don’t have a UML diagram for the NSD model on the wiki
> page I give, the proposal from my side is that we create a Papyrus model
> for the NSD (as we are doing it now) and align it with the R2 wiki page,
> fix issues and put it into R3 clean model.
>
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD
model in Papyrus with the R2 model, but fix the issues and prepare this to
go in clean. I can have it ready by next Monday, hopefully, though I won't
be on the call.

> Further improvement and alignment with ETSI specs are better to be put
> into R4 as we are coming to the deadline for the final draft.
>
Jessie: Agree.

> Regarding the issues, I think you are right the current model is not
> complete, we can either remove those attributes that are not defined or
> mark them as experimental like what we have done for the VNFD model.
>
Jessie: The "attributes" that are not defined are member ends of
associations. We need to either remove the associations, or add the
referenced classes in the model. I personally don't think it would be
correct to mark them as "experimental" as they would be incomplete
definitions. For example, you reference a Sapd, but don't define the Sapd
class? It wouldn't be possible to implement something like that.

>
>
> And as Chuyi pointed out, there’s something on the wiki that are not shown
> in the Papyrus model, update is needed to keep them aligned.
>
>
>
Jessie: I didn't catch what was on the wiki, but not in the model. Can you
remind me what that is?

> Best regards,
>
> Xu
>
>
>
> *From:* 郭楚怡 [mailto:guoch...@chinamobile.com]
> *Sent:* Wednesday, August 22, 2018 1:38 PM
> *To:* jessie.jewitt 
> *Cc:* onap-discuss ; yangxu (H) <
> yang...@huawei.com>; denglingli ;
> zhang.maopeng1 ; zhan.jie1 <
> zhan.j...@zte.com.cn>
> *Subject:* Re:Re: [onap-discuss] [modeling] Network Service Descriptor
> model
>
>
>
>
>
>
>
> Hello, Jessie,
>
>   The Network Service model corresponds to the link is not only NSD, it
> includes different classes, and has been discussed and voted in Service IM
> call, I'm sorry you didn't catch the call.
>
> The current NS model is coordinated with the requirements of VF-C, not
> simply copy the ETSI specifications. Since the scope of development plan
> for C-release has been settled, other specific requirements should be
> proposed and discussed in the later releases.
>
>As for the issues you mentioned,  I think you are right about
> the NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.
>
>For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven't been
> discussed yet, so is for VnfExtCp.
>
>From my understanding, ConnectivityType should be in the
> NsVirtualLinkDesc, which hasn't been put in the papyrus class diagram , I
> think it is the point where should update.
>
>
>
>
>
>
>
> BR,
>
> Chuyi.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 邮件原文
> *发件人：*Jessie Jewitt 
> *收件人：*"yangxu (H)" 
> *抄 送: *"onap-discuss@lists.onap.org" 
> *发送时间：*2018-08-21 00:41:12
> *主题：*Re: [onap-discuss] [modeling] Network Service Descriptor model
>
> Hi Xu-
>
>  The link you refer to in your email to Network Service (which I
> assume is Descriptor) is not a model that is acceptable to me. I certainly
> don't remember voting on this in R2. Here are some of the reasons I
> personally cannot accept it:
>
> 1. There is no class diagram showing the relationships between entities,
> so I don't really know what concepts you are trying to model.
>
> 2. The relationship that should exist is between NSD and VirtualLinkDesc,
> and not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which
> should be the endpoint of the association) is of type string. That is
> incorrect.
>
> 3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first
> attribute is virtualLinkDescId.
>
> 4. Many of the attributes in NSD refer to types that are not defined in
> the model (Sapd, Vnffgd, NsDf...)
>
> 5. Same comment above regarding NsVirtualLink. It contains types that are
> not in your model, lik

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-22 Thread Jessie Jewitt

Hi Chuyi-
 Yes, it's my fault for not having reviewed this model when it was
originally proposed. What I would like to see for Casablanca is that we at
least "fix" it by doing the following:
1. Use a "pared down" version of the Papyrus NSD model that corresponds to
what was agreed, so we can output it from there on "clean", using the
correct associated class diagram.
2. Create the correct classes, and references to other classes and
datatypes that are already in the model (i.e. ConnectivityType is in our
common model)
3. Suppress the references (and associations) that are not desired (meaning
there is no associated class in the model, i.e. Sapd, Vnffgd) You say they
haven't been discussed yet, so I'm curious how the model was approved for
R2? If you prefer to keep these references, then we need to include the
associated classes that are referenced in the model.
4. I'm still not seeing a reference to VnfExtCp. Who is referencing that
and where?

I can prepare a new discussion wiki with what I'm proposing for next
Monday's RM call. However, I would need an answer to #3 above. Do you want
to remove the references to classes that aren't in your model, or do you
want to add the classes that are referenced. It would not be a good thing
to reference them, without defining them, which is currently the case in
the model.

-Jessie

On Tue, Aug 21, 2018 at 10:38 PM, Chuyi Guo 
wrote:

>
>
>
>
> Hello, Jessie,
>
>   The Network Service model corresponds to the link is not only NSD, it
> includes different classes, and has been discussed and voted in Service IM
> call, I'm sorry you didn't catch the call.
>
> The current NS model is coordinated with the requirements of VF-C, not
> simply copy the ETSI specifications. Since the scope of development plan
> for C-release has been settled, other specific requirements should be
> proposed and discussed in the later releases.
>
>As for the issues you mentioned,  I think you are right about
> the NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.
>
>For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven't been
> discussed yet, so is for VnfExtCp.
>
>From my understanding, ConnectivityType should be in the
> NsVirtualLinkDesc, which hasn't been put in the papyrus class diagram , I
> think it is the point where should update.
>
>
>
>
> BR,
>
> Chuyi.
>
>
>
>
>
>
>
>
>
>
>
> 邮件原文
> *发件人：*Jessie Jewitt 
> *收件人：*"yangxu (H)" 
> *抄 送: *"onap-discuss@lists.onap.org" 
> *发送时间：*2018-08-21 00:41:12
> *主题：*Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
> Hi Xu-
>  The link you refer to in your email to Network Service (which I
> assume is Descriptor) is not a model that is acceptable to me. I certainly
> don't remember voting on this in R2. Here are some of the reasons I
> personally cannot accept it:
> 1. There is no class diagram showing the relationships between entities,
> so I don't really know what concepts you are trying to model.
> 2. The relationship that should exist is between NSD and VirtualLinkDesc,
> and not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which
> should be the endpoint of the association) is of type string. That is
> incorrect.
> 3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first
> attribute is virtualLinkDescId.
> 4. Many of the attributes in NSD refer to types that are not defined in
> the model (Sapd, Vnffgd, NsDf...)
> 5. Same comment above regarding NsVirtualLink. It contains types that are
> not in your model, like SecurityParameters
> 6. ConnectivityType, as a datatype, has been moved to our Common model,
> which we will need to define as part of our final resource IM in clean, and
> not a NSD model. The benefit of putting datatypes like these in "Common" is
> that we define them once, and then reference them from multiple models,
> like Resource (where NSD lives) and VNF.
> 7. There is nothing in the model that refers to a VnfExtCp and its
> relationship to NSD.
>
> These are just some of the issues.
> I believe a better approach is to take the NSD model defined that is based
> on ETSI (that addresses the above issues) and pare it down to something
> equivalent, if you want.  I'd be happy to update the NSD model to show what
> it would look like.
>
> -Jessie
>
>
> On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H)  wrote:
>
>> Hi All,
>>
>>
>>
>> Thank you for joining today’s resource IM call and having the meaningful
>> discussion.
>>
>> My apologize for not allocating much time reviewing the NSD model, as M3
>> is approa

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-22 Thread Xu Yang

Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model. Further improvement and alignment with ETSI specs are 
better to be put into R4 as we are coming to the deadline for the final draft.

Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.

And as Chuyi pointed out, there’s something on the wiki that are not shown in 
the Papyrus model, update is needed to keep them aligned.

Best regards,
Xu

From: 郭楚怡 [mailto:guoch...@chinamobile.com]
Sent: Wednesday, August 22, 2018 1:38 PM
To: jessie.jewitt 
Cc: onap-discuss ; yangxu (H) 
; denglingli ; zhang.maopeng1 
; zhan.jie1 
Subject: Re:Re: [onap-discuss] [modeling] Network Service Descriptor model






Hello, Jessie,

  The Network Service model corresponds to the link is not only NSD, it 
includes different classes, and has been discussed and voted in Service IM 
call, I'm sorry you didn't catch the call.

The current NS model is coordinated with the requirements of VF-C, not 
simply copy the ETSI specifications. Since the scope of development plan for 
C-release has been settled, other specific requirements should be proposed and 
discussed in the later releases.

   As for the issues you mentioned,  I think you are right about the 
NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.

   For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven't been discussed 
yet, so is for VnfExtCp.

   From my understanding, ConnectivityType should be in the NsVirtualLinkDesc, 
which hasn't been put in the papyrus class diagram , I think it is the point 
where should update.







BR,

Chuyi.













邮件原文
发件人：Jessie Jewitt 
mailto:jessie.jew...@oamtechnologies.com>>
收件人："yangxu (H)" mailto:yang...@huawei.com>>
抄　送: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" 
mailto:onap-discuss@lists.onap.org>>
发送时间：2018-08-21 00:41:12
主题：Re: [onap-discuss] [modeling] Network Service Descriptor model
Hi Xu-
 The link you refer to in your email to Network Service (which I assume is 
Descriptor) is not a model that is acceptable to me. I certainly don't remember 
voting on this in R2. Here are some of the reasons I personally cannot accept 
it:
1. There is no class diagram showing the relationships between entities, so I 
don't really know what concepts you are trying to model.
2. The relationship that should exist is between NSD and VirtualLinkDesc, and 
not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which should be 
the endpoint of the association) is of type string. That is incorrect.
3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first attribute 
is virtualLinkDescId.
4. Many of the attributes in NSD refer to types that are not defined in the 
model (Sapd, Vnffgd, NsDf...)
5. Same comment above regarding NsVirtualLink. It contains types that are not 
in your model, like SecurityParameters
6. ConnectivityType, as a datatype, has been moved to our Common model, which 
we will need to define as part of our final resource IM in clean, and not a NSD 
model. The benefit of putting datatypes like these in "Common" is that we 
define them once, and then reference them from multiple models, like Resource 
(where NSD lives) and VNF.
7. There is nothing in the model that refers to a VnfExtCp and its relationship 
to NSD.

These are just some of the issues.
I believe a better approach is to take the NSD model defined that is based on 
ETSI (that addresses the above issues) and pare it down to something 
equivalent, if you want.  I'd be happy to update the NSD model to show what it 
would look like.

-Jessie


On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi All,

Thank you for joining today’s resource IM call and having the meaningful 
discussion.
My apologize for not allocating much time reviewing the NSD model, as M3 is 
approaching, I think we need to trigger offline discussion to help accelerate  
the progress.

The main issue I see for the NSD model is the scope for R3 documentation. The 
current proposal from Jessie is based on IFA014 spec, while the model  agreed 
in R2 (https://wiki.onap.org/display/DW/NetworkService) is only subset of the 
spec. And whether we need to include PNFD model as part of the NSD model (like 
ETSI does), and how we document  the PNFD model in R3 remains a question.

My sugg

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-21 Thread Chuyi Guo



 

 

Hello, Jessie,

  The Network Service model corresponds to the link is not only NSD, it 
includes different classes, and has been discussed and voted in Service IM 
call, I39m sorry you didn39t catch the call.

The current NS model is coordinated with the requirements of VF-C, not 
simply copy the ETSI specifications. Since the scope of development plan for 
C-release has been settled, other specific requirements should be proposed and 
discussed in the later releases.

   As for the issues you mentioned,  I think you are right about the 
NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.

   For 4 and 5, the details of Sapd, Vnffgd and etc.,  haven39t been discussed 
yet, so is for VnfExtCp.

   From my understanding, ConnectivityType should be in the NsVirtualLinkDesc, 
which hasn39t been put in the papyrus class diagram , I think it is the point 
where should update.







BR,

Chuyi.







 

 




 
邮件原文发件人：Jessie Jewitt 收件人："yangxu 
(H)" 抄　送: "onap-discuss@lists.onap.org" 
发送时间：2018-08-21 00:41:12主题：Re: [onap-discuss] 
[modeling] Network Service Descriptor modelHi Xu- The link you refer to in 
your email to Network Service (which I assume is Descriptor) is not a model 
that is acceptable to me. I certainly don39t remember voting on this in R2. 
Here are some of the reasons I personally cannot accept it:
1. There is no class diagram showing the relationships between entities, so I 
don39t really know what concepts you are trying to model. 
2. The relationship that should exist is between NSD and VirtualLinkDesc, and 
not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which should be 
the endpoint of the association) is of type string. That is incorrect.
3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first attribute 
is virtualLinkDescId.
4. Many of the attributes in NSD refer to types that are not defined in the 
model (Sapd, Vnffgd, NsDf...)
5. Same comment above regarding NsVirtualLink. It contains types that are not 
in your model, like SecurityParameters
6. ConnectivityType, as a datatype, has been moved to our Common model, which 
we will need to define as part of our final resource IM in clean, and not a NSD 
model. The benefit of putting datatypes like these in "Common" is that we 
define them once, and then reference them from multiple models, like Resource 
(where NSD lives) and VNF.
7. There is nothing in the model that refers to a VnfExtCp and its relationship 
to NSD.

These are just some of the issues.
I believe a better approach is to take the NSD model defined that is based on 
ETSI (that addresses the above issues) and pare it down to something 
equivalent, if you want.  I39d be happy to update the NSD model to show what it 
would look like.

-Jessie




On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H)  wrote:

Hi All,


 


Thank you for joining today’s resource IM call and having the meaningful 
discussion.


My apologize for not allocating much time reviewing the NSD model, as M3 is 
approaching, I think we need to trigger offline discussion to help accelerate  
the progress.


 


The main issue I see for the NSD model is the scope for R3 documentation. The 
current proposal from Jessie is based on IFA014 spec, while the model  agreed 
in R2 (https://wiki.onap.org/display/DW/NetworkService) is only subset of the 
spec. And whether we need to include PNFD model as part of the NSD model (like 
ETSI does), and how we document  the PNFD model in R3 remains a question.


 


My suggestion is we keep aligned with the previous agreement and implementation 
in R3. Which means we only document the trimmed NSD in R3 and try  to capture 
the PNFD model which would be implemented by the SDC team.


 


Please share your opinions on this issue and let’s try to finalize the clean 
model before the deadline, thanks.


 


Best regards,


Xu


 


From: onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt Sent: Tuesday, August 7, 2018 3:09 AM To: onap-discuss 
 Subject: [onap-discuss] [modeling] Network 
Service Descriptor model


 


Please review and provide comments by 8/13 (on the wiki) for the proposed 
Network Service Descriptor model. It was aligned with ETSI IFA014 v2.4.4.


 



Thanks,



Jessie




 








 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11994): https://lists.onap.org/g/onap-discuss/message/11994
Mute This Topic: https://lists.onap.org/mt/24212025/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-20 Thread Jessie Jewitt

Hi Xu-
 The link you refer to in your email to Network Service (which I assume
is Descriptor) is not a model that is acceptable to me. I certainly don't
remember voting on this in R2. Here are some of the reasons I personally
cannot accept it:
1. There is no class diagram showing the relationships between entities, so
I don't really know what concepts you are trying to model.
2. The relationship that should exist is between NSD and VirtualLinkDesc,
and not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which
should be the endpoint of the association) is of type string. That is
incorrect.
3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first
attribute is virtualLinkDescId.
4. Many of the attributes in NSD refer to types that are not defined in the
model (Sapd, Vnffgd, NsDf...)
5. Same comment above regarding NsVirtualLink. It contains types that are
not in your model, like SecurityParameters
6. ConnectivityType, as a datatype, has been moved to our Common model,
which we will need to define as part of our final resource IM in clean, and
not a NSD model. The benefit of putting datatypes like these in "Common" is
that we define them once, and then reference them from multiple models,
like Resource (where NSD lives) and VNF.
7. There is nothing in the model that refers to a VnfExtCp and its
relationship to NSD.

These are just some of the issues.
I believe a better approach is to take the NSD model defined that is based
on ETSI (that addresses the above issues) and pare it down to something
equivalent, if you want.  I'd be happy to update the NSD model to show what
it would look like.

-Jessie

On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H)  wrote:

> Hi All,
>
>
>
> Thank you for joining today’s resource IM call and having the meaningful
> discussion.
>
> My apologize for not allocating much time reviewing the NSD model, as M3
> is approaching, I think we need to trigger offline discussion to help
> accelerate the progress.
>
>
>
> The main issue I see for the NSD model is the scope for R3 documentation.
> The current proposal from Jessie is based on IFA014 spec, while the model
> agreed in R2 (https://wiki.onap.org/display/DW/NetworkService) is only
> subset of the spec. And whether we need to include PNFD model as part of
> the NSD model (like ETSI does), and how we document the PNFD model in R3
> remains a question.
>
>
>
> My suggestion is we keep aligned with the previous agreement and
> implementation in R3. Which means we only document the trimmed NSD in R3
> and try to capture the PNFD model which would be implemented by the SDC
> team.
>
>
>
> Please share your opinions on this issue and let’s try to finalize the
> clean model before the deadline, thanks.
>
>
>
> Best regards,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Tuesday, August 7, 2018 3:09 AM
> *To:* onap-discuss 
> *Subject:* [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> Please review and provide comments by 8/13 (on the wiki) for the proposed 
> Network
> Service Descriptor
> <https://wiki.onap.org/display/DW/Proposed+Network+Service+Descriptor+Model>
> model. It was aligned with ETSI IFA014 v2.4.4.
>
>
>
> Thanks,
>
> Jessie
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11952): https://lists.onap.org/g/onap-discuss/message/11952
Mute This Topic: https://lists.onap.org/mt/24212025/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [modeling] Network Service Descriptor model

2018-08-20 Thread Xu Yang

Hi All,

Thank you for joining today’s resource IM call and having the meaningful 
discussion.
My apologize for not allocating much time reviewing the NSD model, as M3 is 
approaching, I think we need to trigger offline discussion to help accelerate 
the progress.

The main issue I see for the NSD model is the scope for R3 documentation. The 
current proposal from Jessie is based on IFA014 spec, while the model agreed in 
R2 (https://wiki.onap.org/display/DW/NetworkService) is only subset of the 
spec. And whether we need to include PNFD model as part of the NSD model (like 
ETSI does), and how we document the PNFD model in R3 remains a question.

My suggestion is we keep aligned with the previous agreement and implementation 
in R3. Which means we only document the trimmed NSD in R3 and try to capture 
the PNFD model which would be implemented by the SDC team.

Please share your opinions on this issue and let’s try to finalize the clean 
model before the deadline, thanks.

Best regards,
Xu

From: onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt
Sent: Tuesday, August 7, 2018 3:09 AM
To: onap-discuss 
Subject: [onap-discuss] [modeling] Network Service Descriptor model

Please review and provide comments by 8/13 (on the wiki) for the proposed 
Network Service 
Descriptor<https://wiki.onap.org/display/DW/Proposed+Network+Service+Descriptor+Model>
 model. It was aligned with ETSI IFA014 v2.4.4.

Thanks,
Jessie


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11949): https://lists.onap.org/g/onap-discuss/message/11949
Mute This Topic: https://lists.onap.org/mt/24212025/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] [modeling] Network Service Descriptor model

2018-08-06 Thread Jessie Jewitt

Please review and provide comments by 8/13 (on the wiki) for the
proposed Network
Service Descriptor

model. It was aligned with ETSI IFA014 v2.4.4.

Thanks,
Jessie

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11691): https://lists.onap.org/g/onap-discuss/message/11691
Mute This Topic: https://lists.onap.org/mt/24212025/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

Re: [onap-discuss] [modeling] Network Service Descriptor model

[onap-discuss] [modeling] Network Service Descriptor model

15 matches

Site Navigation

Mail list logo

Footer information