Subject: Re: [Supa] review of draft-klyus-supa-proposition-02

From: "Jun Bi" <[email-masked]>
Date: Fri, 10 Jul 2015 14:17:30 +0800

Hi All,

The attached figure might help to show the position of SUPA in the
architecture from network operation and management’s point of view. 

Best Regards,

Jun Bi

发件人: Supa [mailto:[email-masked]] 代表 Dacheng Zhang
发送时间: 2015年7月10日 11:25
收件人: John Strassner; [email-masked] <mailto:[email-masked]> 
主题: Re: [Supa] review of draft-klyus-supa-proposition-02

Thanks for your reply. I agree that maybe it’s not easy to exact locate
SUPA, however it will be very helpful for audience to understand easily with
what  Juergen said “A figure showing one possible way how the function can
be implemented and applied may be more suitable for the applicability
document.” 

Anyway， it is just my humble opinion…^_^

发件人: Supa <[email-masked] <mailto:[email-masked]> > on
behalf of John Strassner <[email-masked]
<mailto:[email-masked]> >
日期: 2015年7月9日 星期四 上午7:03
至: dacheng de <[email-masked] <mailto:dacheng.zdc@alibaba-inc.
com> >, "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
主题: Re: [Supa] review of draft-klyus-supa-proposition-02

Hi Dacheng,

please see inline.

regards,

John

John Strassner, Ph.D.

CTO, Software Laboratory, CRD

Futurewei Technologies

US R&D Center

2330 Central Expressway
Building A, office A2-2143

Santa Clara, California   95050

  Office:  +1.408.330.4923

  Email:   [email-masked]
<mailto:[email-masked]> 

From: Supa [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Wednesday, July 08, 2015 2:19 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Supa] review of draft-klyus-supa-proposition-02

Hi all,

I just got a chance to read the new version of proposition, and it seems to
me the there are three main changes (@ authors, correct me if I was wrong
^_^) :

<jcs> That's correct </jcs>

1. two more paragraphs were added into problem statement which explained
policy management

<jcs> Not quite. Basically, the second and third paragraphs in the Problem
Statement (1.1) were moved from the Proposed Solution (1.2) section and
slightly changed to conform to presenting this as a problem, not as a
solution. This was in response to several people on the list that thought
that a one sentence problem statement was much too short. </jcs>

2. a whole new figure with process information(IMHO, a little complicated)
replaced the old ones which are more easy to understand.

<jcs> The new figure was primarily in response to the discussions on the
previous figure. For example, Juergen said:

> It is full of 'noise' that is not needed. Why is there

> a 'Service Management' box? What is the 'Service 

> Management Data Model'? What exactly are the 'Network

> Manager / Controller'? More important, where is the

> policy interpreter function that SUPA is about (given

> the charter text)? I was trying to produce a 

> _functional_ drawing.

Juergen was right - we **used** to talk about PBSM (that was the title of
the IETF92 presentation from Fukushima-san and myself, in fact) but that was
eliminated from the charter. Finally, it defines two exemplary interfaces of
how SUPA is used, since most of our discussion has been about that. I
wouldn't call this a "process" figure. See more below.

</jcs>  

3. Some additions and deletions in gap analysis part

For the 2nd change, I have some concerns. In the previous version, I can
easily tell which part belongs to SUPA and where it's located. 

<jcs> I disagree. In -01, where exactly is SUPA? Does it include the
"Service Management Data Model"? Is it part of Service Management (which, by
the way, is not defined in the I-D)? </jcs>         

But now maybe we need more words to explain where in the network/ system
will SUPA be located. 

<jcs> I disagree. I thought we had consensus with Juergen's suggestion that
we **not** explicitly define **where** the translation function is located.
</jcs>

Moreover, using the same square blocks to indicate IETF , SUPA GPIM and
other stuff will be confusing to new readers, as they belong to different
dimension s. 

<jcs> I don't think that the shape of the box is relevant. If it is, then we
need 8 different shapes </jcs>

The authors may think about to simplify this figure and use different shape
of blocks. One new figure telling the exact location of SUPA may also be
needed.

<jcs> See above </jcs>