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 <yang...@huawei.com> 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) <yang...@huawei.com>
> *Cc:* 郭楚怡 <guoch...@chinamobile.com>; onap-discuss <
> onap-discuss@lists.onap.org>; denglingli <denglin...@chinamobile.com>;
> zhang.maopeng1 <zhang.maope...@zte.com.cn>; 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) <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]
> *Sent:* Wednesday, August 22, 2018 1:38 PM
> *To:* jessie.jewitt <jessie.jew...@oamtechnologies.com>
> *Cc:* onap-discuss <onap-discuss@lists.onap.org>; yangxu (H) <
> yang...@huawei.com>; denglingli <denglin...@chinamobile.com>;
> zhang.maopeng1 <zhang.maope...@zte.com.cn>; 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 <jessie.jew...@oamtechnologies.com>
> *收件人：*"yangxu (H)" <yang...@huawei.com>
> *抄 送: *"onap-discuss@lists.onap.org" <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) <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 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 <onap-discuss@lists.onap.org>
> *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 (#12045): https://lists.onap.org/g/onap-discuss/message/12045
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]
-=-=-=-=-=-=-=-=-=-=-=-
