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

[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 we don’t have a discussion on those classes
> b

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

[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
>> *To:* jessie.jewitt 
>> *Cc:* onap-discuss ; yan

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

[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 VirtualLinkDesc is NsVirtualLinkDesc.
>
>For 4 and 5, the deta

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

[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, like SecurityParameters
>
> 6. ConnectivityType, as a datatype, has been

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

[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 approaching, I think we need to trigger offline discussion to help
>

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

[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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[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]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] [modeling] Creation of R3 IM Clean

[Jessie Jewitt]

Xu-
   As discussed in the meeting this morning, I propose that R3 IM Clean be
generated from Papyrus. The following activities would have to be done in
order to do this, if not already done:

Kevin: Update VNF model
- Add VnfInstance/VnfcInstance
- Align VNF model with IFA011 V2.5.1

(once
Jessie updates the wiki to 2.5.1)
- Add support for Scaling, Affinity/Anti-Affinity/InstantiationLevel
 to VnfDf
- Obsolete HPA attributes


Jessie: Resource Model
- Move PNFD related classes from "service" to "resource" model
- Move NetworkService related classes from "service" to "resource" model

Update to R3 IM Clean
- Remove existing content
- Kevin generates VNF model GenDoc and copies to wiki
-Jessie generates Resource model GenDoc and copies to wiki.

I believe that covers the items you mentioned for inclusion in R3 IM model.
If I missed anything, let me know.

-Jessie

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

View/Reply Online (#11529): https://lists.onap.org/g/onap-discuss/message/11529
Mute This Topic: https://lists.onap.org/mt/23860662/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] ONAP Information Model in Papyrus

[Jessie Jewitt]

We finally have a "draft" ONAP model in a working branch in Gerrit.
It contains modeling work that is in progress, and does not represent
anything committed yet to R3. When the model is approved, it will move to a
master branch.

If you would like to use Papyrus for viewing this model, you can follow the
instructions here


If you would like to be an official model editor, please let me know, as
you will need to undergo some training first.

You can do any work (i.e. create an input model proposal for discussion)
using Papyrus on your *local machine,* but only the model editors can
actually check-in model updates in Gerrit.

Many thanks to Deng Hui, Chris Donley, Kevin Skaggs, and Yang Xu for
helping us get the model up and running!

-Jessie

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

View/Reply Online (#11123): https://lists.onap.org/g/onap-discuss/message/11123
Mute This Topic: https://lists.onap.org/mt/23394659/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] ONAP R3 Modeling high level requirements

[Jessie Jewitt]

Hello DENG Hui,
  I think it has been beneficial to collect and review the modeling
requirements for R3. Thank you for doing this. I have a few questions for
you, if you would be so kind as to answer:

1. The requirements were supposed to be completed, according to the
Casablanca Release Calendar, on 5/25. I haven't seen a poll, or anything,
for the approval of these requirements. When do you anticipate they will be
officially approved? I didn't see anything in the meeting minutes from
today's meeting.

2. Again, according to the release calendar, we were to have established a
"modeling plan" by 6/28. Does such a plan exist? If so, could you point me
to where I can find it?

3. You indicated in the modeling subcommittee meeting this morning that our
"model freeze" is in 3 weeks. With the requirements not yet agreed, and
given the number of requirements currently specified, what is your
expectation of what can actually be accomplished in 3 week's time?

Thank you,
Jessie

On Mon, Jun 25, 2018 at 3:15 AM, denghui (L)  wrote:

> Hello Kevin and all
>
>
>
> I have created a high level requirements wiki page based on the input of
> Beijing event:
>
> https://wiki.onap.org/display/DW/ONAP+R3+Modeling+High+Level+Requirements
>
> Please help to contribute to the spreadsheet as soon as possible,
>
> I also moved Kevin’s draft proposal under this wiki page for your
> reference:
>
> https://wiki.onap.org/display/DW/Casablanca+High+Level+
> Modeling+Requirements+-+Draft
>
>
>
> We are going to go through this wiki page this Tuesday, as the basis for
> our release planning.
>
>
>
> I will create a separate wiki page for release planning of those
> requirements accordingly.
>
>
>
> Thanks a lot
>
>
>
> DENG Hui
> 
>
>

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

View/Reply Online (#10810): https://lists.onap.org/g/onap-discuss/message/10810
Mute This Topic: https://lists.onap.org/mt/22674361/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] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[jessie jewitt]

Hi Xu-
   Maybe we can discuss this next week. Our feedback is our recommendation
on what we would like to see done. You and others may not agree, in which
case perhaps we need to have a poll. I didn't see any other comments.
-Jessie

On Sat, Jun 16, 2018 at 8:01 AM, yangxu (H)  wrote:

> Hi Jessie,
>
> My view for the comment:
> The proposal is to mark some attributes/datatypes, for the readers of the
> spec to know they are recommended not to use these attributes/datatypes any
> more and these items are to be removed in the future releases.
> It's not about setting up a whole lifecycle of the model or to use a
> particular term to represent this intention. So I suggest we seperate the
> two things.
> What we need to decide is whether we accept the intention and find a
> proper way to mark it.
> It's suggested to adopt IISOMI definitions to represent the intention for
> the sake of convenience. But I'm not convinced we should adopt the whole
> IISOMI guidelines to use its terms.
> If the comment is that we couldn't use IISOMI term without first accepting
> the related definitions, maybe we could use other term or have our own
> definition to ease the discussion.
> If the comment is that we need to first mark these items as "deprecate"
> before "obsolete" as IISOMI suggest, (i.e. object directly remove items in
> the next release)I would suggest you to discuss with Alex whether he (and
> other interested people)could accept it.
> Anyway, I encourage the proposer to discuss with Jessie to address her
> comments. Or we need to discuss it the next week.
>
> Best regards,
> Xu Yang
> *发件人：*jessie jewitt
> *收件人：*yangxu (H),
> *抄 送：*denghui (L),onap-discuss@lists.onap.org,onap-tsc,
> *时间：*2018-06-16 02:03:57
> *主 题：*Re: [onap-discuss][modeling] Call for approval on the “obsolete
> legacy attributes/datatypes” proposal for the resource IM
>
> Here is our (ARM/OAM Technologies) feedback on this proposal:
>
> 1. Format - We're glad to see that ONAP is using the "Applied Stereotypes"
> column in their tables, even though this is only defined in IFA015 output
> and not IFA011. However, since you are choosing to use it, we'd like to
> recommend that it be used properly. The column is intended to show the
> applied stereotypes that they use in Papyrus, which are based on the IISOMI
> Open Model Profile. See Stereotype Usage
> <https://wiki.onap.org/display/DW/Stereotypes>   for an explanation of
> how these stereotypes are used.  "Obsolete" is a stereotype itself and
> not a valid enum for "support".  The proper format per IISOMI would be:
>
> OpenModelAttribute   (this is the applied stereotype)
> isInvariant: false
> support: MANDATORY
> Obsolete  (this is the applied stereotype, note there is no "d" on the end)
>
> 2. Artifact lifecycle:  The proposal to put an artifact in an "Obsolete"
> lifecycle state implies that we have agreed to implement artifact
> lifecycles in accordance with the IISOMI Guidelines
> <https://wiki.onap.org/pages/viewpage.action?pageId=20874416> . As far as
> we know, this is under discussion, but has not been accepted by the team.
> It seems a bit pre-mature, therefore, to jump straight to a proposal where
> we implement the "Obsolete" stereotype without having first accepted
> general use of the the lifecycle stereotypes.
>
> 3. Recommendation for moving forward on this proposal:
>  a. Implementing an artifact lifecycle, per this proposal, implies
> "agreement" that we will use artifact lifecycles in the model. If people
>agree to this proposal, then we have implicit agreement on
> using lifecycle stereotypes. No need for discussion. If this is not the
> case,
>  then we need to discuss and agree on usage of the lifecycle
> stereotypes before marking any artifact as "Obsolete".
>  b. Assuming it is agreed to use lifecycle stereotypes, all artifacts
> in the model should have a lifecycle phase associated to them, and not
>  just the proposed "Obsolete" lifecycle.
>  c.  The proposal to go from "nothing" to "Obsolete" is not in
> accordance with the
> <https://wiki.onap.org/display/DW/Stereotypes#Stereotypes-LifecycleStereotypes>lifecycle
> state machine
> <https://wiki.onap.org/display/DW/Stereotypes#Stereotypes-LifecycleStereotypes>
>   that
> proposes an artifact go from  "Mature"-> "Deprecated"->
> "Obsolete". Assuming, had we implemented lifecycles, and that these
> attributes would be in a "Mature"   phase, the next logical step would
> be then to transition them to "Deprecate

Re: [onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[jessie jewitt]

 Here is our (ARM/OAM Technologies) feedback on this proposal:

1. Format - We're glad to see that ONAP is using the "Applied Stereotypes"
column in their tables, even though this is only defined in IFA015 output
and not IFA011. However, since you are choosing to use it, we'd like to
recommend that it be used properly. The column is intended to show the
applied stereotypes that they use in Papyrus, which are based on the IISOMI
Open Model Profile. See Stereotype Usage
<https://wiki.onap.org/display/DW/Stereotypes>   for an explanation of how
these stereotypes are used.  "Obsolete" is a stereotype itself and not a
valid enum for "support".  The proper format per IISOMI would be:

OpenModelAttribute   (this is the applied stereotype)
isInvariant: false
support: MANDATORY
Obsolete  (this is the applied stereotype, note there is no "d" on the end)

2. Artifact lifecycle:  The proposal to put an artifact in an "Obsolete"
lifecycle state implies that we have agreed to implement artifact
lifecycles in accordance with the IISOMI Guidelines
<https://wiki.onap.org/pages/viewpage.action?pageId=20874416> . As far as
we know, this is under discussion, but has not been accepted by the team.
It seems a bit pre-mature, therefore, to jump straight to a proposal where
we implement the "Obsolete" stereotype without having first accepted
general use of the the lifecycle stereotypes.

3. Recommendation for moving forward on this proposal:
 a. Implementing an artifact lifecycle, per this proposal, implies
"agreement" that we will use artifact lifecycles in the model. If people
   agree to this proposal, then we have implicit agreement on
using lifecycle stereotypes. No need for discussion. If this is not the
case,
 then we need to discuss and agree on usage of the lifecycle
stereotypes before marking any artifact as "Obsolete".
 b. Assuming it is agreed to use lifecycle stereotypes, all artifacts
in the model should have a lifecycle phase associated to them, and not
 just the proposed "Obsolete" lifecycle.
 c.  The proposal to go from "nothing" to "Obsolete" is not in
accordance with the
<https://wiki.onap.org/display/DW/Stereotypes#Stereotypes-LifecycleStereotypes>lifecycle
state machine
<https://wiki.onap.org/display/DW/Stereotypes#Stereotypes-LifecycleStereotypes>
 that
proposes an artifact go from  "Mature"-> "Deprecated"->
"Obsolete". Assuming, had we implemented lifecycles, and that these
attributes would be in a "Mature"   phase, the next logical step would
be then to transition them to "Deprecated" and not "Obsolete", as proposed.
We are not in agreement
 that they directly be marked as "Obsolete".


On Wed, Jun 13, 2018 at 11:38 PM, yangxu (H)  wrote:

> Hi Jessie,
>
>
>
> Maybe I can help clarify this. Per the discussion of the resource IM
> interest group, the “obsolete” is intended to follow the definitions of the
> IISOMI modeling guidelines as you stated below for the time being.
>
> I think the intention of the proposal is to mark those
> attributes/datatypes as “obsolete” but not removed for R3, and perhaps
> remove them in R4, which fits the definition. Alex, you can confirm whether
> I interpreted it correctly.
>
>
>
> For others who haven’t attend the resource IM call, please noted that the
> “lifecycle” stereotype of the model is still under discussion. The interest
> group just agrees that the IISOMI definition of “obsolete” fits the current
> intention of the proposal and decides to use the term.
>
>
>
> BR,
>
> Xu
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *jessie jewitt
> *Sent:* Thursday, June 14, 2018 12:05 AM
> *To:* denghui (L) 
> *Cc:* onap-discuss@lists.onap.org; onap-tsc 
> *Subject:* Re: [onap-discuss] [modeling] Call for approval on the
> “obsolete legacy attributes/datatypes” proposal for the resource IM
>
>
>
> Hello Deng Hui-
>
>  Could you please clarify something for me. The ETSI "applied
> stereotype", on which this column in the wiki table is based, has
> "obsolete" as an artifact lifecycle option, with its definition supplied in
> the IISOMI Modeling Guidelines. This is the definition of "obsolete" in
> those guidelines. Is this what we should interpret this to mean? Will the
> entity be kept in the model for at least one further release?
>
> Thanks for your guidance,
>
> Jessie
>
> · *Obsolete*
> This stereotype indicates that the entity should not be used in new
> implementation and that attempts should be made to remove it from existing
> implem

Re: [onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[jessie jewitt]

Hello Deng Hui-
 Could you please clarify something for me. The ETSI "applied
stereotype", on which this column in the wiki table is based, has
"obsolete" as an artifact lifecycle option, with its definition supplied in
the IISOMI Modeling Guidelines. This is the definition of "obsolete" in
those guidelines. Is this what we should interpret this to mean? Will the
entity be kept in the model for at least one further release?
Thanks for your guidance,
Jessie

   -
*Obsolete *This stereotype indicates that the entity should not be used in
   new implementation and that attempts should be made to remove it from
   existing implementation. The entity should be kept in the model for at
   least one further release. The team has to decide on a case by case basis
   when to remove it from the model.



On Wed, Jun 13, 2018 at 8:23 AM, denghui (L)  wrote:

> Hello all,
>
>
>
> This is 1 week’s call for approval on the “obsolete legacy
> attributes/datatypes” proposal for the resource IM.
>
> The intention is to mark several attributes/datatypes of the current model
> as “obsoleted” as their functionalities are covered by some other
> attributes.
>
> Detailed information of the proposal can be found at:
> https://wiki.onap.org/display/DW/Obsolete+Legacy+Attributes , the
> proposed changes are marked in red.
>
>
>
> Thanks a lot for your review
>
> Best regards,
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Papyrus Training Session - Reminder and Bridge

[jessie jewitt]

Hello-
This is a reminder that the Papyrus training session will take place
today at
9am Eastern time. Bridge info:

https://zoom.us/j/746737796

Thank you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Papyrus Training Session

[jessie jewitt]

Sorry for the continued confusion about the bridge.
We will be using Kevin's bridge:

https://zoom.us/j/746737796
Thank you,
Jessie

On Mon, Jun 4, 2018 at 6:13 PM, jessie jewitt <
jessie.jew...@oamtechnologies.com> wrote:

> The VNFSDK Modeling team is hosting a Papyrus training session on
> Wednesday, June 13th at 6am Pacific / 9am Eastern / 9pm China time
> This session will cover:
>
> 1. How to install Papyrus
> 2. The value of using a modeling tool such as Papyrus within ONAP
> 3. How to use Papyrus alongside the wiki.
>
>
> We will be using Kevin's bridge:
> https://connect2.uc.att.com/attinc/meet/?ExEventID=81618271=M
>
> Please plan on attending.
> -Jessie
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Papyrus Training Session

[jessie jewitt]

There has been an update to the bridge, and I've asked Kenny to please
issue the invitation again.

The bridge we will use will be:
https://zoom.us/j/103916386

Please mark your calendars accordingly.

Jessie
p.s. Sorry for the confusion

On Wed, Jun 6, 2018 at 4:52 AM, SCAGGS, KEVIN  wrote:

> All,
>
>
>
> We will use the following zoom meeting instead.
>
>
>
> https://zoom.us/j/987452560
>
>
>
> Regards,
>
> Kevin
>
>
>
>
>
> *From:* jessie jewitt 
> *Sent:* Monday, June 04, 2018 8:14 PM
> *To:* onap-discuss 
> *Cc:* MAYER, ANDREW J ; SCAGGS, KEVIN ;
> Brian Hedstrom 
> *Subject:* [modeling] Papyrus Training Session
>
>
>
> The VNFSDK Modeling team is hosting a Papyrus training session on
> Wednesday, June 13th at 6am Pacific / 9am Eastern / 9pm China time
>
> This session will cover:
>
>
>
> 1. How to install Papyrus
>
> 2. The value of using a modeling tool such as Papyrus within ONAP
>
> 3. How to use Papyrus alongside the wiki.
>
>
>
>
>
> We will be using Kevin's bridge:
>
> https://co
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__co=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=gZVVoWy9KwtzjPbNdGg0fg=pLBx6YrBF1AzhF0QSCQjGO-BSesmGbWSKR24ag6vbiI=J3c8kuaKZaMwS4lW4J546x4qa3mIz6yqQyWHAGAQ8-o=>
> nnect2.uc.att.com/attinc/meet/?ExEventID=81618271=M
>
>
>
> Please plan on attending.
>
> -Jessie
>
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Papyrus Training Session

[jessie jewitt]

A meeting announcement was sent out that this meeting was today. It is NEXT
Wednesday June 13th at 6AM.
Sorry for the inconvenience.
-Jessie

On Wed, Jun 6, 2018 at 4:52 AM, SCAGGS, KEVIN  wrote:

> All,
>
>
>
> We will use the following zoom meeting instead.
>
>
>
> https://zoom.us/j/987452560
>
>
>
> Regards,
>
> Kevin
>
>
>
>
>
> *From:* jessie jewitt 
> *Sent:* Monday, June 04, 2018 8:14 PM
> *To:* onap-discuss 
> *Cc:* MAYER, ANDREW J ; SCAGGS, KEVIN ;
> Brian Hedstrom 
> *Subject:* [modeling] Papyrus Training Session
>
>
>
> The VNFSDK Modeling team is hosting a Papyrus training session on
> Wednesday, June 13th at 6am Pacific / 9am Eastern / 9pm China time
>
> This session will cover:
>
>
>
> 1. How to install Papyrus
>
> 2. The value of using a modeling tool such as Papyrus within ONAP
>
> 3. How to use Papyrus alongside the wiki.
>
>
>
>
>
> We will be using Kevin's bridge:
>
> https://co
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__co=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=gZVVoWy9KwtzjPbNdGg0fg=pLBx6YrBF1AzhF0QSCQjGO-BSesmGbWSKR24ag6vbiI=J3c8kuaKZaMwS4lW4J546x4qa3mIz6yqQyWHAGAQ8-o=>
> nnect2.uc.att.com/attinc/meet/?ExEventID=81618271=M
>
>
>
> Please plan on attending.
>
> -Jessie
>
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Papyrus Training Session

[jessie jewitt]

The VNFSDK Modeling team is hosting a Papyrus training session on
Wednesday, June 13th at 6am Pacific / 9am Eastern / 9pm China time
This session will cover:

1. How to install Papyrus
2. The value of using a modeling tool such as Papyrus within ONAP
3. How to use Papyrus alongside the wiki.


We will be using Kevin's bridge:
https://connect2.uc.att.com/attinc/meet/?ExEventID=81618271=M

Please plan on attending.
-Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Usage of Stereotypes in Modeling and Deprecating Attributes

[jessie jewitt]

1) Usage of Stereotypes in Modeling

 I took an action item from this morning's resource modeling call to write
up how stereotypes are used in modeling. The information can be found here:

https://wiki.onap.org/display/DW/Stereotypes

Please take a few moments to familiarize yourself with this material. It
will help you to appreciate how we can make better usage of stereotypes in
our models.

It compares and contrasts how stereotypes are used in Papyrus vs. how they
are currently used in the wiki model pages.

2) Deprecating Attributes

Related to the use of stereotypes, I noted in another meeting this morning
regarding the deprecation of attributes that using "support=DEPRECATED" as
an applied stereotype is not being correctly specified here:

https://wiki.onap.org/display/DW/Deprecate+Legacy+Attributes

Please refer to the Stereotype wiki mentioned above to see how this should
be specified. Also note the following lifecycle state stereotyopes as
defined by IISOMI:

 *Deprecated*
This stereotype indicates that the entity may become obsolete in the near
future. It may still be used in new implementation. The entity should be
kept in this state for one further release. The team has to decide on a
case by case basis when to move it to obsolete.

*Obsolete *This stereotype indicates that the entity should not be used in
new implementation and that attempts should be made to remove it from
existing implementation. The entity should be kept in the model for at
least one further release. The team has to decide on a case by case basis
when to remove it from the model

The correct transition in the state machine is from "Deprecated" to
"Obsolete" then after one release the attribute actually gets deleted from
the model. You don't deprecate an attribute and delete it in the same
release.

One issue is that we are not currently capturing the Lifecycle stereotypes
in the model ("support" is not it) at all. We might want to consider adding
this.

-Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Request for last call for comment on WAN service proposal

[jessie jewitt]

Hi DENG Hui-
Do you want the comments on the wiki page or via email. Sorry, it
wasn't clear to me.
-Jessie

On Wed, Apr 25, 2018 at 10:57 PM, denghui (L)  wrote:

> Hello all
>
>
>
> Per service call discussion yesterday, this is 2 weeks call for comment on
> WAN service proposal
>
> https://wiki.onap.org/display/DW/WanService
>
>
>
> the discussion minutes and slides for related discussions and calls are
> documented here
>
> https://wiki.onap.org/pages/viewpage.action?pageId=28381459
>
>
>
> Thanks,
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] ONAP Modeling Guidelines

[jessie jewitt]

 If you have any questions or comments regarding MEF's use of modeling
guidelines, or modeling techniques, please let me know and I will
communicate your request to the MEF committee chairs and the CTO.
-Jessie

On Wed, Apr 4, 2018 at 3:15 PM, John Strassner <straz...@gmail.com> wrote:

> Actually, the MEF is NOT using these guidelines anymore, mainly due to the
> errors with respect to UML interpretation and the restrictions placed on
> what UML artifacts can be used in a model.
>
> On Wed, Apr 4, 2018 at 2:50 PM, jessie jewitt <jessie.jewitt@
> oamtechnologies.com> wrote:
>
>> You are correct that it is not an "industry standard" like an IEEE spec.
>> It is an informal agreement by industry players to use the same UML
>> Modeling Guidelines. The ONF, ETSI, and MEF use these guidelines, even
>> though you personally may choose not to do so.
>>
>>
>> On Wed, Apr 4, 2018 at 1:42 PM, John Strassner <straz...@gmail.com>
>> wrote:
>>
>>> I'm sorry, but IISOMI is NOT an "industry standard". It is an "informal
>>> agreement" that has some consensus among some parts of the industry.
>>>
>>> In fact, it contains a number of incorrect conclusions about what UML is
>>> and is not, and greatly limits the power of using UML constructs.
>>>
>>> John
>>>
>>> On Wed, Apr 4, 2018 at 12:07 PM, jessie jewitt <
>>> jessie.jew...@oamtechnologies.com> wrote:
>>>
>>>> Hello Hui and Lingli-
>>>>  I've noticed that the modeling guidelines defined here:
>>>> https://wiki.onap.org/pages/viewpage.action?pageId=16003072
>>>>
>>>> do not specify that we should be following the industry defined UML
>>>> Modeling Guidelines (IISOMI 514) and Papyrus Guidelines (IISOMI 515)
>>>> defined here:
>>>> https://wiki.onap.org/pages/viewpage.action?pageId=20874416
>>>>
>>>> As a result, there are ONAP IM models being developed that are not in
>>>> conformance with industry standard guidelines. (For example, some of the
>>>> Service IM class attributes do not conform to using lower camel case).
>>>>
>>>> If these IISOMI Guidelines have not been "accepted" as ONAP Guidelines,
>>>> I'd like to propose an agenda item to discuss this at the next modeling
>>>> subcommittee meeting.
>>>>
>>>> Thank you,
>>>> Jessie
>>>>
>>>> ___
>>>> onap-discuss mailing list
>>>> onap-discuss@lists.onap.org
>>>> https://lists.onap.org/mailman/listinfo/onap-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>> regards,
>>> John
>>>
>>
>>
>
>
> --
> regards,
> John
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] ONAP Modeling Guidelines

[jessie jewitt]

You are correct that it is not an "industry standard" like an IEEE spec. It
is an informal agreement by industry players to use the same UML Modeling
Guidelines. The ONF, ETSI, and MEF use these guidelines, even though you
personally may choose not to do so.


On Wed, Apr 4, 2018 at 1:42 PM, John Strassner <straz...@gmail.com> wrote:

> I'm sorry, but IISOMI is NOT an "industry standard". It is an "informal
> agreement" that has some consensus among some parts of the industry.
>
> In fact, it contains a number of incorrect conclusions about what UML is
> and is not, and greatly limits the power of using UML constructs.
>
> John
>
> On Wed, Apr 4, 2018 at 12:07 PM, jessie jewitt <jessie.jewitt@
> oamtechnologies.com> wrote:
>
>> Hello Hui and Lingli-
>>  I've noticed that the modeling guidelines defined here:
>> https://wiki.onap.org/pages/viewpage.action?pageId=16003072
>>
>> do not specify that we should be following the industry defined UML
>> Modeling Guidelines (IISOMI 514) and Papyrus Guidelines (IISOMI 515)
>> defined here:
>> https://wiki.onap.org/pages/viewpage.action?pageId=20874416
>>
>> As a result, there are ONAP IM models being developed that are not in
>> conformance with industry standard guidelines. (For example, some of the
>> Service IM class attributes do not conform to using lower camel case).
>>
>> If these IISOMI Guidelines have not been "accepted" as ONAP Guidelines,
>> I'd like to propose an agenda item to discuss this at the next modeling
>> subcommittee meeting.
>>
>> Thank you,
>> Jessie
>>
>> ___
>> onap-discuss mailing list
>> onap-discuss@lists.onap.org
>> https://lists.onap.org/mailman/listinfo/onap-discuss
>>
>>
>
>
> --
> regards,
> John
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] ONAP Modeling Guidelines

[jessie jewitt]

Hello Hui and Lingli-
 I've noticed that the modeling guidelines defined here:
https://wiki.onap.org/pages/viewpage.action?pageId=16003072

do not specify that we should be following the industry defined UML
Modeling Guidelines (IISOMI 514) and Papyrus Guidelines (IISOMI 515)
defined here:
https://wiki.onap.org/pages/viewpage.action?pageId=20874416

As a result, there are ONAP IM models being developed that are not in
conformance with industry standard guidelines. (For example, some of the
Service IM class attributes do not conform to using lower camel case).

If these IISOMI Guidelines have not been "accepted" as ONAP Guidelines, I'd
like to propose an agenda item to discuss this at the next modeling
subcommittee meeting.

Thank you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [multicloud] Last Call for Feedback of MultiVIM Metrics for VES Requirement

[jessie jewitt]

This is a long email chain. Could you please provide a link to the document
that is supposed to be reviewed and for which we should provide feedback?
Thank you,
Jessie

On Wed, Mar 14, 2018 at 12:14 PM, HU, BIN  wrote:

> Hello my fellow colleagues in MultiVIM project,
>
>
>
> Following our great discussion on February 26th, and follow up email on
> Feb 27th for feedback of MultiVIM metrics in VES requirement, this is the
> last call for feedback.
>
>
>
> Please provide any feedback in terms of MultiVIM metrics for VES
> Requirement. VES team intends to publish official requirement next week.
>
>
>
> Because this is the last call for feedback, and prior communication has
> been made for reasonable times. Lacking of feedback means that MultiVIM
> project team agrees to official VES requirement that will be published next
> week.
>
>
>
> Thank you everyone.
>
> Bin
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *GUPTA, ALOK
> *Sent:* Tuesday, February 27, 2018 10:07 AM
> *To:* aasm...@redhat.com; bj@intel.com; tony.b.mcma...@intel.com;
> emma.l.fo...@intel.com; scott.mansfi...@ericsson.com;
> mario.rodrig...@arm.com; aput...@redhat.com; calin.gher...@intel.com;
> SULLIVAN, BRYAN L ;
> romanx.korynkev...@intel.com; manish.ja...@cavium.com;
> pavan.gu...@calsoftinc.com; damien.po...@intel.com; kand...@us.ibm.com;
> wesley.campb...@intel.com; Javier Arauz ;
> ning@intel.com; ab...@redhat.com; tarasx.chor...@intel.com;
> ola.liljed...@arm.com; raghuveer.re...@intel.com;
> yangya...@chinamobile.com; serkant.ulude...@argela.com.tr;
> krishna.j.mur...@intel.com; opnfv-tech-disc...@lists.opnfv.org;
> andrew.duig...@intel.com; Srinivas Chaganti ;
> MORTON JR., AL 
> *Subject:* Re: [opnfv-tech-discuss] Updated invitation: [barometer]
> Weekly Call @ Weekly from 12pm to 1pm on Tuesday (EDT) (
> opnfv-tech-disc...@lists.opnfv.org)
>
>
>
> Security Advisory:* This Message Originated Outside of AT ***
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
> *Team:*
>
>
>
> Please find enclosed a presentation from ONAP mulit-vim project requesting
> feedback on the metrics we should include in the main body. Please help
> provide feedback on following:
>
> -  Please see chart 5 with metrics categories currently in VES
> shown on the Left column. The list from Right column includes metrics that
> could be included with VES frame work. Please provide feedback, the ones
> that you would like me to include in VES mfvs domain.
>
> -  ON pages 7 thru 10 we define metrics that is VES and delta
> metrics detail that is currently not in VES. Please review the embedded
> excel file on pg 5 and the pg 7 thru 10 and advice if you would like me to
> expand the metrics category.
>
> Please send me feedback soon, so I can update VES Requirements and provide
> you a draft copy for approval.
>
>
>
> Regards,
>
>
>
> Alok Gupta
>
> 732-420-7007 <(732)%20420-7007>
>
> MT B2 3D30
>
> ag1...@att.com
>
>
>
>
>
> -Original Appointment-
> *From:* aasm...@redhat.com [mailto:aasm...@redhat.com ]
>
> *Sent:* Tuesday, October 24, 2017 10:51 AM
> *To:* aasm...@redhat.com; aasm...@redhat.com; bj@intel.com;
> tony.b.mcma...@intel.com; emma.l.fo...@intel.com;
> scott.mansfi...@ericsson.com; mario.rodrig...@arm.com; aput...@redhat.com;
> calin.gher...@intel.com; SULLIVAN, BRYAN L; romanx.korynkev...@intel.com;
> manish.ja...@cavium.com; pavan.gu...@calsoftinc.com;
> damien.po...@intel.com; kand...@us.ibm.com; wesley.campb...@intel.com;
> Javier Arauz; ning@intel.com; ab...@redhat.com;
> tarasx.chor...@intel.com; ola.liljed...@arm.com; raghuveer.re...@intel.com;
> yangya...@chinamobile.com; serkant.ulude...@argela.com.tr;
> krishna.j.mur...@intel.com; opnfv-tech-disc...@lists.opnfv.org;
> andrew.duig...@intel.com; Srinivas Chaganti; MORTON JR., AL; GUPTA, ALOK
> *Subject:* [opnfv-tech-discuss] Updated invitation: [barometer] Weekly
> Call @ Weekly from 12pm to 1pm on Tuesday (EDT) (opnfv-tech-discuss@lists.
> opnfv.org)
> *When:* Tuesday, February 27, 2018 12:00 PM-1:00 PM America/New_York.
> *Where:* https://global.gotomeeting.com/join/819733085
> 
>
>
>
>
>
> *This event has been changed.*
>
> *more details »*
> 

Re: [onap-discuss] [modeling] ONAP R2 IM to DM design

[jessie jewitt]

Hello-
I don't remember this being an action out of the modelling committee
meeting yesterday. How does it compare to the action item from another
meeting that Alex, Thinh, Anatoly and myself took to work on the IM to DM
model mapping, and the mappings that have already been proposed (and
commented on) here:

https://wiki.onap.org/pages/viewpage.action?pageId=25436710

Could you please clarify.
Thank you,
Jessie

On Thu, Mar 8, 2018 at 4:46 AM, denghui (L)  wrote:

> Hello all
>
>
>
> As agreed in modeling subcommittee meeting, we need to update the onap
> types of the data model to reflect the agreements reached in information
> model.
>
>
>
> It’s huge work to achieve the goal, in order to accelerate, 7 separate
> tasks have been created based on the current IM. We encourage interested
> people to volunteer to take the lead for particular task.
>
>
>
> The tasks including:
>
> 1. VDU: https://jira.onap.org/browse/MODELING-67
>
> 2. HPA: https://jira.onap.org/browse/MODELING-68
>
> 3. CP: https://jira.onap.org/browse/MODELING-69
>
> 4. DeploymentFlavor: https://jira.onap.org/browse/MODELING-70
>
> 5. VL: https://jira.onap.org/browse/MODELING-71
>
> 6. VNFD: https://jira.onap.org/browse/MODELING-72
>
> 7. monitor: https://jira.onap.org/browse/MODELING-73
>
>
>
> It’s expected that the lead would help provide tosca definitions on the
> contribution page (https://wiki.onap.org/display/DW/Data+Model+align+
> with+TOSCA+NFV+Profile) and
>
> help implement related logic in SDC, APPC/VFC projects.
>
>
>
> Thanks a lot
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Resource TOSCA Data model

[jessie jewitt]

I have my doubts as to whether SOL001 and the TOSCA Simple Profile NFV  it
references actually supports HPA. Attributes such vduCpuRequirements and
vduMemRequirements are not in tosca.datatypes.nfv.VirtualCpu and
tosca.datatypes.nfv.VirtualMemory as specified in SOL001. I believe the
mapping done at

https://wiki.onap.org/pages/viewpage.action?pageId=25436710

shows the HPA attributes as being mapped, but at least the ones mentioned
above are not.

-Jessie

On Wed, Mar 7, 2018 at 12:24 AM, denghui (L) <denghu...@huawei.com> wrote:

> Hi Michela
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Michela Bevilacqua
> *Sent:* Wednesday, March 7, 2018 1:09 AM
> *To:* onap-discuss@lists.onap.org
> *Subject:* Re: [onap-discuss] [modeling] Resource TOSCA Data model
>
>
>
> Hi,
>
> I share some questions about Resource TOSCA data model as follow up of the
> today´s ONAP  modeling subcommittee meeting
>
>
>
> 1)  Assuming the discussion we had today during the ONAP modeling
> subcommittee about OASIS TOSCA NFV or SOL001 is limited to the VNF
> onboarding model. What is the TOSCA data model used by SDC to generate the
> VNF and service descriptors to be shared with the ONAP run time component ?
>
> == >  this is not correct, for R2 it cover everwhere, there is a proposal
> talking about R3 model which will cover onboarding, but it needs further
> discussion
>
>
>
> 2)  Assuming the discussion we had today during the ONAP modeling
> subcommittee about OASIS TOSCA NFV or SOL001 is limited to the VNF
> onboarding model.  I expect that the VNF onboarding model needs
> implementation only in SDC.
>
>   == > no
>
>
>
> 3)  Assuming OASIS TOSCA NFV profile (v004) is a subset of ETSI
> SOL001 without features as HPA and monitoring parameters, if OASIS TOSCA
> NFV profile will be preferred for VNF onboarding model, will SOL001 used to
> introduce HPA and Monitoring parameters or …. ?
>
>== > ONAP TOSCA NFV profile will include HPA.
>
>
>
> 4)  If OASIS TOSCA NFV profile will be preferred for in R2, do we
> expect to move to SOL001 in R3 ? IN other word, are we only delaying SOL001
> support of 1 release or …?
>
>
>
>   == > no decision yet, will be discussed during R3. Maybe ONAP and ETSI
> NFV board level relationship also related.
>
>
>
> Thanks
>
>
>
> DENG Hui
>
>
>
>
>
> BR
>
> Michela
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org <onap-discuss-boun...@lists.onap.org>] *On Behalf Of 
> *Nguyenphu,
> Thinh (Nokia - US/Irving)
> *Sent:* den 5 mars 2018 22:14
> *To:* jessie jewitt <jessie.jew...@oamtechnologies.com>;
> onap-discuss@lists.onap.org
> *Subject:* Re: [onap-discuss] [modeling] Data model mapping using SOL001
>
>
>
> Hi Jessie,
>
>
>
> Your summary below shows there are a lot of inconsistency of TOSCA types
> naming convention with IFA011.  I fully acknowledge it. SOL WG is in the
> process of cleaning it up with these guidelines:
>
>- SOL001 Type naming convention is UpperCamelCase.
>- SOL001 properties naming convention is lowercase_underscored or
>snake_case.
>- SOL001 shall not include postfixes of “d”, “D”, “Desc”, “Descr” of
>type or properties names.
>- SOL001 shall not include prefixes of “vnf” of properties names, like
>vnfdid, vnfProvider, vnfProductName, vnfSoftwareVersion, 
> vnfdVersion,vnfProductInfoName,
>vnfProductinfoDescription.
>
>
>
> The inconsistence issues should be resolved with the next version of
> SOL001 (v0.6.0).
>
>
>
> Meanwhile, I have created a wiki page to show all of the ONAP R2 Resource
> IM attributes (clean version wiki page) map to SOL001 (TOSCA model) data
> model, https://wiki.onap.org/pages/viewpage.action?pageId=25436710.  (see
> SOL001 Mapping column).  The mapping table shows that all of ONAP Resource
> IM attributes are mapped into TOSCA types with detail.  Except for any of
> new attributes (“orange” highlighted text) are not yet defined.
>
>
>
> Perhaps, I can introduce this page at Modeling sub_committee on Tuesday
> call.
>
>
>
> Thinh
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org <onap-discuss-boun...@lists.onap.org>] *On Behalf Of *jessie
> jewitt
> *Sent:* Friday, March 02, 2018 1:20 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] [modeling] Data model mapping using SOL001
>
>
>
> This message is particularly directed to Anat

Re: [onap-discuss] 答复: [modeling] Identifiers in R2 IM descriptors

[jessie jewitt]

Hi Shitao-
 I'm not talking about the data model. I'm talking about the info
model, and all the datatypes that got transformed into classes, like
VirtualMemoryDesc.
-Jessie

On Tue, Mar 6, 2018 at 5:44 PM, Lishitao <lishi...@huawei.com> wrote:

> Hi Jessie
>
>
>
> There is a descriptor_id defined in  tosca.nodes.nfv.VNF node type. But
> for same data types, the identifiers are not needed, because they directly
> defined in the specific nodes.
>
> For example, in tosca.datatypes.nfv.VduProfile, there is no vudId,
> because Vduprofile will be a property contained in the Vdu.compute node.
>
>
>
> Regards
>
> shitao
>
> *发件人:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *代表 *jessie jewitt
> *发送时间:* 2018年3月7日 1:57
> *收件人:* onap-discuss@lists.onap.org
> *主题:* [onap-discuss] [modeling] Identifiers in R2 IM descriptors
>
>
>
> As I'm unable to attend the early discussions regarding the R2 IM model, I
> hope you will please take my feedback into consideration.
>
>
>
> The ETSI descriptors (classes) that we map into R2 IM descriptor classes
> all have identifiers, i.e. VNFDesc (vnfdId), VDUDesc (vduId), etc.
>
>
>
> The ETSI datatypes that we map into R2 descriptor classes DON'T have id's,
> as they are originally datatypes, i.e. VirtualCPUDesc, VirtualMemoryDesc,
> LogicalNodeDesc, etc.
>
>
>
> Descriptors are a type of "resource specification", and as such they ALL
> should have id's, particularly if you want to retrieve them via a Resource
> Catalog NBI.
>
>
>
> I would therefore propose one of the following solutions:
>
>
>
> 1. Have a "ResourceSpecification" abstract base class that contains "id",
> and remove identifiers from the descriptor classes, which inherit from that
> base class.
>
>
>
> 2. Add identifiers to all the ETSI datatypes that we mapped to descriptor
> classes, such as mentioned above.
>
>
>
> Could this please be put on an agenda for discussion.
>
> Thank-you,
>
> Jessie
>
>
>
>
>
>
>
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling]

[jessie jewitt]

The results of the modeling tool poll regarding GitHub taken here:
https://wiki.onap.org/display/DW/Modeling+Tool+Poll

Are 14 people approve the use of GitHub. Nobody is opposed.
So we will proceed with the use of GitHub.

-Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Support for HPA in SOL001 mapping

[jessie jewitt]

I'm not seeing the support in the SOL001 spec for all the HPA related
attributes in the IM that we are specifying here:
https://wiki.onap.org/pages/viewpage.action?pageId=25436710

For example, in our VirtualCpuDesc class there is an attribute
vduCpuRequirements that says gets mapped to  tosca.datatypes.nfv.VirtualCpu

When I look at the definition in SOL001 regarding
tosca.datatypes.nfv.VirtualCpu
it says:

" tosca.datatypes.nfv.VirtualCpu shall be modelled as defined in
TOSCA-Simple-Profile-NFV-v1.0"

When I go look at the TOSCA Simple NFV Profile, this datatype has the
following attributes:

Name

Required

Type

Constraints

Description

cpu_architecture

no

string



CPU architecture type. Examples are x86, ARM.

num_virtual_cpu

yes

integer



Number of virtual CPU’s

virtual_cpu_clock

no

scalar-unit.frequency



Minimum virtual CPU clock rate

virtual_cpu_oversubscription_policy

no

string



CPU core oversubscription policy

virtual_cpu_pinning

no

tosca.datatypes.nfv.VirtualCpuPinning



The virtual CPU pinning configuration for the virtualized compute resource.

There is NO vduCpuRequirements.
What they mapped was the VirtualCpu class and NOT the VirtualCpuDesc class.

The same holds true for our VirtualMemoryDesc which has
vduMemoryRequirements that says is mapped to
tosca.datatypes.nfv.VirtualMemory

This datatype in the TOSCA Simple Profile does NOT contain
vduMemoryRequirements.

-Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Identifiers in R2 IM descriptors

[jessie jewitt]

As I'm unable to attend the early discussions regarding the R2 IM model, I
hope you will please take my feedback into consideration.

The ETSI descriptors (classes) that we map into R2 IM descriptor classes
all have identifiers, i.e. VNFDesc (vnfdId), VDUDesc (vduId), etc.

The ETSI datatypes that we map into R2 descriptor classes DON'T have id's,
as they are originally datatypes, i.e. VirtualCPUDesc, VirtualMemoryDesc,
LogicalNodeDesc, etc.

Descriptors are a type of "resource specification", and as such they ALL
should have id's, particularly if you want to retrieve them via a Resource
Catalog NBI.

I would therefore propose one of the following solutions:

1. Have a "ResourceSpecification" abstract base class that contains "id",
and remove identifiers from the descriptor classes, which inherit from that
base class.

2. Add identifiers to all the ETSI datatypes that we mapped to descriptor
classes, such as mentioned above.

Could this please be put on an agenda for discussion.
Thank-you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Data model mapping using SOL001

[jessie jewitt]

Thanks Thinh for your response.
I think it is more of an issue than just naming conventions, and that we
can't just take the SOL001 mappings "as defined":

1. You are saying that SOL001 shall not include postfixes of "d","D",
"Desc", etc. So, why in one case they have "VNF", and another
"VnfVirtualLinkDesc". Is the "VNF" mapping a "Vnf" or a "Vnfd"? They really
should be EXPLICIT in the IFA elements they are mapping, and not just say
they are leaving off this important postfix.

2. All of our IM classes are "descriptors". SOL001 sometimes maps
descriptors to "nodes" (VNF, VDU, Cpd...), sometimes to "capabilities"
(VirtualCompute... did they mean this as a descriptor or a resource?), and
other times to "datatypes" (VirtualCpu, VirtualMemory,LogicalNode...).
Don't we want them all to be "nodes"?

3. Regarding the mapping of "datatypes" mentioned above, I assume they did
this because those entities are datatypes in the IFA model and not
"descriptor" classes as we've made them in the ONAP model. We are not being
consistent in our mapping. If we mean them to be descriptors, they should
be "nodes" as well.

-Jessie

On Mon, Mar 5, 2018 at 1:13 PM, Nguyenphu, Thinh (Nokia - US/Irving) <
thinh.nguyen...@nokia.com> wrote:

> Hi Jessie,
>
>
>
> Your summary below shows there are a lot of inconsistency of TOSCA types
> naming convention with IFA011.  I fully acknowledge it. SOL WG is in the
> process of cleaning it up with these guidelines:
>
>- SOL001 Type naming convention is UpperCamelCase.
>- SOL001 properties naming convention is lowercase_underscored or
>snake_case.
>- SOL001 shall not include postfixes of “d”, “D”, “Desc”, “Descr” of
>type or properties names.
>- SOL001 shall not include prefixes of “vnf” of properties names, like
>vnfdid, vnfProvider, vnfProductName, vnfSoftwareVersion, 
> vnfdVersion,vnfProductInfoName,
>vnfProductinfoDescription.
>
>
>
> The inconsistence issues should be resolved with the next version of
> SOL001 (v0.6.0).
>
>
>
> Meanwhile, I have created a wiki page to show all of the ONAP R2 Resource
> IM attributes (clean version wiki page) map to SOL001 (TOSCA model) data
> model, https://wiki.onap.org/pages/viewpage.action?pageId=25436710.  (see
> SOL001 Mapping column).  The mapping table shows that all of ONAP Resource
> IM attributes are mapped into TOSCA types with detail.  Except for any of
> new attributes (“orange” highlighted text) are not yet defined.
>
>
>
> Perhaps, I can introduce this page at Modeling sub_committee on Tuesday
> call.
>
>
>
> Thinh
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *jessie jewitt
> *Sent:* Friday, March 02, 2018 1:20 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] [modeling] Data model mapping using SOL001
>
>
>
> This message is particularly directed to Anatoly, Alex, and Thinh, as we
> have an action item to map ONAP IM to DM. If one of you could respond, I'd
> appreciate it.
>
>
>
> My understanding is that SOL001 is mapping the VNFD model to TOSCA. They
> indicate they are mapping the  ETSI NFV elements listed below into TOSCA
> types (page 12).
>
>
>
> I'm not clear why they chose the elements they did, as they don't all
> correspond to the VNFD model which is defined in the ETSI
> "VnfTemplateModule" of the model.
>
>
>
> Also, the actual ETSI elements named do not correspond to exactly what is
> defined in the model (they probably just got sloppy, but they should pay
> attention to detail).
>
>
>
> Here's the list of the currently defined elements that they map
>
> 1. VNF   -   Shouldn't this be Vnfd? The Vnf is defined in the VnfModule
> of the model. Also, the element is called Vnf and not VNF.
>
> 2. VDU   -   OK, but it should be Vdu, not VDU.
>
> 3. Cpd  -Maybe ok? It is defined in the CommonTemplateModule as an
> abstract class. You don't instantiate abstract classes, so you will never
> have an instance. Do you have TOSCA types that represent abstract classes?
> Also, they don't map other abstract classes such as VirtualLinkDesc, so why
> map this one?
>
> 4. VduCpd  - OK. This would contain all the attributes in Cpd, so again
> I'm not sure why you need  Cpd.
>
> 5. VnfVirtualLinkDesc - OK
>
> 6. VnfExtCpd - OK
>
> 7. Virtual Storage - Shouldn't this be VirtualStorageDesc?
>
> 8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to
> distinguish it from the VirtualCompute class.
>
> 9. Software Image -  Sh

[onap-discuss] [modeling] SOL001 DM mapping

[jessie jewitt]

This is a resend, as I didn't see the message show up in the modeling
discussion.
My apology if you have already received it.
==
This message is particularly directed to Anatoly, Alex, and Thinh, as we
have an action item to map ONAP IM to DM. If one of you could respond, I'd
appreciate it.

My understanding is that SOL001 is mapping the VNFD model to TOSCA. They
indicate they are mapping the  ETSI NFV elements listed below into TOSCA
types (page 12).

I'm not clear why they chose the elements they did, as they don't all
correspond to the VNFD model which is defined in the ETSI
"VnfTemplateModule" of the model.

Also, the actual ETSI elements named do not correspond to exactly what is
defined in the model (they probably just got sloppy, but they should pay
attention to detail).

Here's the list of the currently defined elements that they map
1. VNF   -   Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of
the model. Also, the element is called Vnf and not VNF.
2. VDU   -   OK, but it should be Vdu, not VDU.
3. Cpd  -Maybe ok? It is defined in the CommonTemplateModule as an
abstract class. You don't instantiate abstract classes, so you will never
have an instance. Do you have TOSCA types that represent abstract classes?
Also, they don't map other abstract classes such as VirtualLinkDesc, so why
map this one?
4. VduCpd  - OK. This would contain all the attributes in Cpd, so again I'm
not sure why you need  Cpd.
5. VnfVirtualLinkDesc - OK
6. VnfExtCpd - OK
7. Virtual Storage - Shouldn't this be VirtualStorageDesc?
8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to
distinguish it from the VirtualCompute class.
9. Software Image -  Shouldn't this be SwImageDesc? Particularly to
distinguish it from SwImage.
10. Deployment Flavour - Shouldn't this be VnfDf?
11. Scaling Aspect - They should at least give the correct element name of
ScalingAspect.
12. Element Group - I assume they mean VnfdElementGroup? They should use
the correct name.
13. Instantiation Level -  OK, but they should give the correct name
InstantiationLevel.

The names used in the Tosca types should be an exact reflection of the ETSI
NFV element names as defined above. This is not always the case. For
example, they use "VirtualCompute" instead of "VirtualComputeDesc". As we
made changes in ONAP to ETSI class names, are we considering  making
changes to TOSCA type names to ensure adherence to the actual element
names. Or do we want to change them to match ONAP names? For example,
should  tosca.nodes.nfv.Cpd be tosca.nodes.nfv.CPDesc?

Also, they don't appear to map the all the classes that are defined in the
VNFD model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc.
Why?

Thank you for your help,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Data model mapping using SOL001

[jessie jewitt]

This message is particularly directed to Anatoly, Alex, and Thinh, as we
have an action item to map ONAP IM to DM. If one of you could respond, I'd
appreciate it.

My understanding is that SOL001 is mapping the VNFD model to TOSCA. They
indicate they are mapping the  ETSI NFV elements listed below into TOSCA
types (page 12).

I'm not clear why they chose the elements they did, as they don't all
correspond to the VNFD model which is defined in the ETSI
"VnfTemplateModule" of the model.

Also, the actual ETSI elements named do not correspond to exactly what is
defined in the model (they probably just got sloppy, but they should pay
attention to detail).

Here's the list of the currently defined elements that they map
1. VNF   -   Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of
the model. Also, the element is called Vnf and not VNF.
2. VDU   -   OK, but it should be Vdu, not VDU.
3. Cpd  -Maybe ok? It is defined in the CommonTemplateModule as an
abstract class. You don't instantiate abstract classes, so you will never
have an instance. Do you have TOSCA types that represent abstract classes?
Also, they don't map other abstract classes such as VirtualLinkDesc, so why
map this one?
4. VduCpd  - OK. This would contain all the attributes in Cpd, so again I'm
not sure why you need  Cpd.
5. VnfVirtualLinkDesc - OK
6. VnfExtCpd - OK
7. Virtual Storage - Shouldn't this be VirtualStorageDesc?
8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to
distinguish it from the VirtualCompute class.
9. Software Image -  Shouldn't this be SwImageDesc? Particularly to
distinguish it from SwImage.
10. Deployment Flavour - Shouldn't this be VnfDf?
11. Scaling Aspect - They should at least give the correct element name of
ScalingAspect.
12. Element Group - I assume they mean VnfdElementGroup? They should use
the correct name.
13. Instantiation Level -  OK, but they should give the correct name
InstantiationLevel.

The names used in the Tosca types should be an exact reflection of the ETSI
NFV element names as defined above. This is not always the case. For
example, they use "VirtualCompute" instead of "VirtualComputeDesc". As we
made changes in ONAP to ETSI class names, are we considering  making
changes to TOSCA type names to ensure adherence to the actual element
names. Or do we want to change them to match ONAP names? For example,
should  tosca.nodes.nfv.Cpd be tosca.nodes.nfv.CPDesc?

Also, they don't appear to map the all the classes that are defined in the
VNFD model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc.
Why?

Thank you for your help,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] R2 IM Class diagram

[jessie jewitt]

Hello-
   I'm looking for the class diagram that corresponds to the classes
defined here:
https://wiki.onap.org/display/DW/Design+Time+Model+Clean+Version

One would think it would be the diagram that is on the ONAP R2+ Resource IM
Clean Version wiki page:
https://wiki.onap.org/pages/viewpage.action?pageId=16004636

but it appears to be the diagram defined here in the discussion pages:
https://wiki.onap.org/display/DW/VNF+Desciptor

Whoever is responsible for this, could you make sure the diagram for R2 IM
classes is in the correct location. It's hard to just look at the class
descriptions without the associated class diagram.

Thank you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Comparison of R2 proposed IM classes and IFA011

[jessie jewitt]

Hi-
I'm trying to understand how the IM model proposed for R2 compares to
IFA011.

When I look on this wiki:
https://wiki.onap.org/display/DW/Resource+IM+Discussion+Based+on+IFA011

it looks like the IFA011 model was reviewed and decisions were made. For
example, in the VNFD, one decision was to rename vnfProductName to Name. It
is marked as "AGREED".

However, when I look at the R2 class VNFD, the attribute is still called
"vnfProductName".

Should I be ignoring the decisions made on the wiki above?
Is there another place that shows the differences between the R2 classes
and IFA011.

Thanks for your help,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] GitHub poll

[jessie jewitt]

This is a reminder that the poll regarding use of GitHub with Papyrus will
close tomorrow. Here is the link to the poll:

https://wiki.onap.org/display/DW/Modeling+Tool+Poll

Thank you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [modeling] Liaison to ETSI

[jessie jewitt]

In our modeling meeting last week we discussed making a formal contribution
to ETSI. Does ONAP have an official liaison relationship to ETSI? If so, is
there a process we follow for making contributions?
Thanks,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [Modeling] Poll for use of GitHub

[jessie jewitt]

 Please vote on the poll regarding the use of GitHub for versioning of
Papyrus models. It is located at:
https://wiki.onap.org/display/DW/Modeling+Tool+Poll

The poll closes on 2/28/18.

Thank you,
Jessie
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss