Subject: Re: [alto] WG chair review of draft-ietf-alto-deployments-14

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 9 May 2016 22:56:42 +0200

Hi Vijay,
all,

I started integrating Vijay's comments into the document.
While most of the proposed changes make the language more readable and
beautiful, some also slightly change the meaning of the statements, so
we need to consider what/how to change.

please see below.

On Thu, Apr 28, 2016 at 01:06:30PM -0500, Vijay K. Gurbani wrote:
> Folks: I have (as a WG chair) reviewed the latest deployment draft,
> draft-ietf-alto-deployments-14.  My review is below.  I have also shared
> the proto-writeup of this document on the list [1].
> 
> [1] https://www.ietf.org/mail-archive/web/alto/current/msg03039.html
> 
> Please go through my review and decide which of the comments you want to
> incorporate in version -15.  As soon as I see version -15 on the list, I
> will move the document out of the WG.
> 
> Thanks for all of your hard work.  This is an excellent document that is
> full of pertinent information related to ALTO.
> 
> The comments below are in document order form, starting from Section 1.
> 
> General comments:
> 
> - There is this idea that an ALTO client is running in a resource directory.
>   I find that a bit obtuse, and that may be just me.  What does it
> mean for an
>   ALTO client to run in a resource directory?  As far as I can tell, a
>   resource directory in ALTO is the canonical IRD defined in
> rfc7285. So what
>   does it mean to say that an ALTO client is running in a resource
> directory?
> 
>   Either I am missing something or we need to define what running in a
>   resource directory means for this document.
> 

I added to 2.1.1:

   This document uses the term "Resource Directory" as defined in
   [RFC5693], i.e., to denote an entity that is logically separate from
   the resource consumer and that assists the resource consumer to
   identify a set of resource providers (e.g., a tracker in a peer-to-
   peer application).  This term and its meaning is not to be confused
   with the "Information Resource Directory (IRD)" defined as a part of
   the ALTO protocol [RFC7285], i.e., a list of available information
   resources offered by a specific ALTO service and the URIs at which
   each can be accessed.  For the remainder of this document, the term
   Resource Directory is to be interpreted as defined in [RFC5693].

> - S1: My suggestion would be to rewrite the first sentence as follows for
>   conciseness and brevity:
>   "Many Internet applications access resources that are available as
> several
>   equivalent replicas on different hosts."
> 
> - S1, paragraph 1: s/a desired resource./the desired resource./

I'd prefer to keep these sentence as is - they are from RFC 6708.
I think we didn't do it really wrong back then, and the value of
recognition seems to me higher than some slight optimizations.

> - S1, paragraph 2: s/from whom the queries are performed./who initiaties the
>   queries./

changed.

> - S2.1.1, paragraph 1: s/In the following/Below/

changed.
 
> - S2.1.1, bullet item 1: What does it mean to say that an ALTO service gives
>   guidance to a "resource directory"?  I can see what it means when
> the ALTO
>   service gives guidance to a "resource consumer", but not sure how to
>   intrepret giving guidance to a resource directory.  Perhaps you
> meant to say
>   that the ALTO services "gives guidance to a resource consumer and
> provides a
>   resource directory about ..."?
> 
>   The last context I have of a "resource directory" is that of the
> definition
>   of an IRD in the ALTO protocol.  Have things changed since then?
> 
> - S2.1.1, bullet 2: s/to the queries to the/to satisfy the queries about a
>   particular/
> 
> - S2.1.1, bullet 3: I am still confused about embedding the ALTO client in
>   "the resource directory".  What does this mean?

these three bullets are copied verbatim from RFC 5693 and I am reluctant
to change the wording.  

One way forward could be to add to each bullet some sentences that
explain how the rather generic definitions from RFC 5693 map to the
specific protocol in RFC 7285.  Or would that change be too big
at this stage of the publication process?

> - S2.1.1, last paragraph: s/An ALTO service may be/A particular ALTO service
>   may be/

changed.

> - S2.1.1, last paragraph: s/one ALTO servers./one ALTO server./

changed.

> - S2.1.2, first paragraph: s/at various entities in a network deployment./at
>   various places in a deployed network./
> 
> - S2.1.2, first paragraph: You say that "The first differentiation...",
>   however, I don't see a "second differentiation".  Thus, the qualifier
>   "first" is redundant.  Also see next comment.
> 
> - S2.1.2, first paragraph: Saying that "host that runs the
> application", while
>   technically correct, allows a lot of ambiguity.  Which "application"?
>   Perhaps better to rewrite the first paragraph as:
>   The ALTO server and ALTO clients can be situated at various places in a
>   deployed network.  An ALTO client may be located on the actual host that
>   executes an application that requires ALTO (Figure 2); alternatively, the
>   ALTO client could be located on a resource directory as shown in
> Figure 3.

What about:

 <t>The ALTO server and ALTO clients may be situated at various
 places in a network topology. An important differentiation is
 whether the ALTO client is located on the host that is the endpoint
 of the data transmissions to be optimized with ALTO (see
 <xref target="fig.tracker_less"/>), or whether the ALTO client is
 located on a resource directory, which assists peers or clients in
 finding other peers or servers, respectively, but does not directly take
 part in the data transmission (see <xref target="fig.tracker"/>).</t>

> 
> - S2.2.1, second paragraph: "4. Resource consumer (using the ALTO
> guidance)".
>   Here, what context does the phrase "using the ALTO guidance"
> impart? Does
>   not the ALTO client also uses the ALTO guidance?  Is the guidance
> provided
>   to a resource consumer different than the one provided to a
> client? Where
>   have you made the distinction between an ALTO client and a resource
>   consumer?  Later on in S3.2.2 you make a distinction by qualifyin an
>   application as a resource consumer; perhaps you can make this
> distinction up
>   front.

See my thought on the terminology above ... When we combine the
terminology definitions of RFC 5693 with the ALTO core specification
RFC 7285, the outcome would IMO be:

An ALTO client is basically a HTTP client library, a JSON parser
library, and some data structures, which does not need guidance itself.
It is linked into the resource consumer (i.e., for example the specific
BitTorrent client process running on your computer), because the latter
needs the guidance.

> 
> - S2.2.1, fifth paragraph: s/As explained in [RFC5693], from this follows
>   that at least three different kinds of entities can operate an ALTO
>   server:/At least three different autonomous entities can operate an
>   ALTO server [RFC5693]:/

Though this sounds better, I am not sure whether it has the same
meaning.

"three different autonomous entities" sounds to me more like
"<name of ISP company #1>, <name of ISP company #2>, and 
<name of ISP company #3>".  But we want to discus "one layer above":
three kinds of, or maybe better "three types of", like "the ISPs, the
other companies, and the people".

> - S2.2.1, fifth paragraph, item 2: s/Topology information could also be
>   collected by entities separate from network operators but that may
>   either have collected network information or have arrangements/Topology
>   information can also be collected by entities distinct than the network
>   operator who use public sources to collect network information or have
>   arrangements/

What about:

 <t>Third parties. Topology information could also be
 collected by companies or organizations that are distinct
 from the network operators, yet have arranged certain
 legal agreements with one or more network operators,
 regarding access to their topology information and/or
 doing measurements in their networks.
 Examples of such entities could be Content
 Delivery Network (CDN) operators or companies specialized
 on offering ALTO services on behalf of ISPs. </t>

> - S2.2.1, sixth paragraph, item 1: s/network, or not/network.

Is the resulting sentence really a full sentence?

The deployment of ALTO can
differ depending on whether ALTO client and ALTO server
are operated within the same organization and/or network.

> - S2.2.1, sixth paragraph, item 1: s/a lot of constraints,/a number of
>   constraints/

changed.

> 
> - S2.2.1, sixth paragraph, item 2: s/clients, e.g., after/clients
> only after/

that would change the example to the only case.
another example could be an internal network.

> 
> - S.2.2.1, last paragraph: s/if no ALTO servers can be found/in the
> absence of
>   any ALTO server,/

the old wording also covers the case that there are ALTO servers around,
but the discovery mechanism fails.

> - S2.2.2, first paragraph, item 1: s/the client does not have to reveal/the
>   server does not have to reveal/

NACK. That is correct as is.

> - S2.2.2, first paragraph, item 2: s/can be realized/is realized/

In ALTO, this approach can be realized by the Endpoint Cost Service
and other related services.

(e.g. the endpoint property service, the PID property service, ...)

> - S2.2.2, third paragraph: "For the client, approach 1...".  Here, the
>   advantage is not that the "operational information" stays within
> the client,
>   but rather the client's "query string" remains private.  The
> server is not
>   privy to the computation that the client is doing on the maps.
> 
>   So, I would suggest that the text be reworded as follows:
>   s/all operational information stays within the client and is not revealed
>   to the provider of the server./the queries the client initiates remain
>   private to the client./

The queries the client initiates WILL be visible to the server.
That's how protocols work :)
But it will be only a "give me the map".  

It will not contain the IP addresses under consideration for retrieving
some specific content from.

> - S2.2.3, item 1: What is an example of "metric" (single "metric" guidance)?
>   You may want to provide one.

An ALTO client only obtains guidance regarding a single metric
+(e.g., "routingcost")
from a single ALTO service,

> 
> - S2.2.3, item 1: s/REST- ful protocol/REST-ful protocol/

can't find that in the text. it is already REST-ful without a space after
the dash. Can you please check again?

> - S2.2.3, item 1: "an ALTO service can use known methods to balance the load
>   between different server instances ..."  Here, load balancing is
> not done by
>   the ALTO service as much as it is done by the ALTO server
> provider's network
>   infrastructure.  Plus, what are these "known methods", some sort of a
>   reference may help.
> 
>   Perhaps this substitution text may help (replaces the last two
> sentences of
>   item 1):
>   Load balancing in ALTO can be accomplished by known methods,
> including, but
>   not limited to assigned unique REST-ful URIs to different service
>   instances.

 Since the ALTO protocol is an HTTP-based, REST-ful protocol, 
 the operator of an ALTO may use well-known techniques for
 serving large web sites, such as load balancers, in order
 to serve a large number of ALTO queries.
 The ALTO protocol also supports the use of
 different URIs for different ALTO features and thereby
 the distribution of the service onto several servers.</t>

> 
> - S2.2.3, item 2: s/determine what provided information may indeed be
>   useful./interpret the received information accordingly./

changed

> 
> - S2.2.3, last paragraph: s/not towards NREN/not destined towards NREN/

I don't like that whole paragraph. My proposal is:

 <t>In this setting, all destinations that can be reached 
 via the NREN are preferred in the rating of the university's 
 ALTO server.  In contrast, all traffic that is not
 routed via the NREN will be handled by the commercial upstream ISP
 and is in general less preferred due to the associated costs.
 Yet, there may be significant differences between various
 destinations reached via the ISP.
 Therefore, the ALTO server at the university may
 also include the guidance given by the ISP ALTO server
 in its replies to the ALTO clients. This is an example for
 cascaded ALTO servers.</t>

> 
> - S3.1.1, first paragraph: Insofar as you want to make a distinction
> on an NSP
>   and an ISP, the distinction should be that while NSPs provide network
>   connectivity and routing in the network they manage, they must
> depend on an
>   ISP to connect them to the Internet.  Thus, an ISP may be an NSP but the
>   reverse is not true.  I don't know whether you want to make this
> distinction
>   or not, but thought I'd point it out.

There are different definitons of NSP around.  Another common one would
be a "wholesale ISP" or what is usually called a Tier-1 carrier. 

Or something like the IT department of a company, which does not only
provide bare Internet Connectivity, but also, say, file storage on
"network drives", etc.

I think the best thing to do would be to go through the whole section
and replace all occurences of ISP and NSP by network operator.

> - S3.1.1, item 3: s/smaller link bandwidth/low link bandwidth/

lower ...  changed.

> 
> - S3.1.2, last paragraph: s/possible or even not be desirable/possible, or
>   even desirable/

I think this should read

it may not be possible or not even desirable to ...

> 
> - S3.1.3, last paragraph: s/ALTO is not/That said, it must be
> understood that
>   ALTO is not a general purpose/

changed.

> - S3.1.4, first paragraph: s/may have the desire/may seek to/

is "seek" not much more about actually doing something, as opposed to a
more subtle "desire" to do something, if there was anything that could
be done?

>   Same paragraph: s/own//

changed.

>   Same paragraph: I would suggest rewriting the last sentence ("One reason
>   ... of the Internet") as follows:
>   One reason could be that the wireless network or the mobile hosts are not
>   engineered for direct peer-to-peer communications between mobile
> hosts, and
>   therefore, it makes sense for peers to fetch content from remote peers in
>   other parts of the Internet.

 One reason could be that the wireless network or the mobile hosts 
 were not designed for direct peer-to-peer communications between
 mobile hosts, and therefore, it makes sense for peers to fetch 
 content from remote peers in other parts of the Internet.  </t>

> - S3.1.4, last paragraph: s/it may require that the ALTO server can
>   distinguish/it may require the ALTO server to distinguish/

changed

> 
>   Same sentence: s/, e.g.,//

changed

> 
> - S3.1.5, first paragraph: s/, e.g.,//

why? "exposing network performance information" is only one thing 
an alto server can do.

> 
> - S3.2.1, first paragraph: s/ALTO, such as network and cost maps./ALTO to
>   create network and cost maps./

why make from the "such as" example the only result?

> - S3.2.1, last paragrah: s/abstracted view/abstract view/

changed.

> 
> - S3.2.2, first paragraph: s/abstracted view/abstract view/

changed.
> 
> - S3.2.2, first paragraph: s/present endpoints/endpoints/

s/present endpoints/existing endpoints/

> 
> - S3.2.2, below Figure 8, second bullet item: s/link state/link-state/
>   (for consistency with how it is written in the preceeding text).

changed

> 
> - S3.2.4, second paragraph: s/interpreted, e.g., whether/interpreted, i.e.,
>   whether/

changed

> 
> - S3.2.4, first bullet under "Distance-related rating criteria:"
>   s/values, and the ALTO client will not be informed about the
> nature of the
>   information./values.

why?

this sentence has two aspects:
- the server is free to chose how to compute the values, and
- the server does not even have to tell the client how he did it

both are important

> 
>   Next sentence: s/this kind of information/topological distances/

One way to determine relative topological distance may be counting AS hops,
but ...

> - S3.2.4, last bullet of the section: s/bandwidth, e.g., of
> cable/bandwidth of
>   cable/

changed

> 
> - S3.3.3, second paragraph: s/a larger number/a large number/
changed

> 
> - S3.5.1, paragraph 3, right above Figure 9: s/define: C1<C2/define C1<C2/
changed

> 
> - S3.5.3, first paragraph: The key point here is that the cellular wireless
>   bandwidth is a constrained resource, normal wireless (IEEE 802.11)
> is not as
>   much constrained as the cellular data network.  My suggestion would be to
>   simply s/wireless bandwidth/cellular wireless bandwidth/

not sure why we need the distinction between 802.11 and cellular here.
both are less preferred than wireline.

we could do a four-tier example:
    preference(true wireline clients) >
    preference(wifi clients behind access points hooked up to the wireline
        internet access by the paying customers) >
    preference(wifi clients at access points operated by the ISP) >
    preference(cellular clients)

but this goes way beyond what we need.

> 
> - S3.5.3, Figure 13: For the sake of completeness and symmetry, you should
>   specify the costs for the links that joins (PID 3, PID 1), as well as the
>   text that makes it costly for peers in PID 3 to get content from
> PID 1, but
>   not as costly to get content from PID 2.

Who contributed this example?  Hans?  Can you do that?

> 
> - S3.6.1, paragraph right above Figure 15: s/boundaries.  It is
>   running/boundaries; it is running/

changed.

> 
> - S3.6.1, Figure 15: What would be good is if the link weights in
> this figure
>   were also reflected in Figure 14.  That way, later on when one is
>   interpreting the hopcount cost map (Figure 20), it is easy to see
> that the
>   path weight between R1->R3->R4->R9 is 40.

Who contributed this example?  Hans?  Can you do that?

> 
> - S3.6.4, third paragraph: s/certain pair the corresponding field/certain
>   pair, the corresponding field/

changed

> 
> - S3.6.4, last paragraph: s/"default" PID is sort of virtual
> PID/"default" PID
>   is, in a sense, a virtual PID/

changed

> 
> - S4.1.1, first paragraph: s/in the application/of the user/
>   (Rationale: QoE is a subjective metric, an application is not a sentient
>   thing that can measure QoE.  A human user is.)

I'd prefer to keep it as it is.

it is after "improve performance or Quality of Experience"

"in the application" may refer to "performance or Quality of Experience" 
(the first one not being something "of the user"),
or to "improve" (as the process of improving takes part in
the application layer, e.g. re-shaping the overlay, as opposed to asking
for more ressources from underlying layers).

>   Same paragraph: s/is assumed to be the/is an/

It was an assumption at that time, and probably still is. 

> - S4.1.1, second paragraph: s/without or with/with or without/

changed

> 
> - S4.1.1, last paragraph: s/usually only/only/

changed
> 
>   Same paragraph: s/is supposed to yield/should yield/

changed
> 
> - S4.1.2, first paragraph: s/outside the networks of the
> ISPs/external to the
>   ISPs/

changed
> 
> - S4.1.2, third paragraph: s/BitTorent/BitTorrent/

changed
> 
> - S4.1.2, discussion under Figure 22: The key point here is that the ALTO
>   client embedded in the tracker sends only local peers to the
> querying peer.
>   The ALTO client figures out who these local peers are by discovering and
>   communicating with the ALTO server responsible for the querying peer.
> 
>   This needs to be stated more explicitly, otherwise the message is lost to
>   someone who is not a practitioner in this field.  I would suggest
> re-writing
>   the paragraph under Figure 22 as follows:
> 
>   An alternative deployment scenario for a tracker-based system is
> depicted in
>   Figure 22.  When the tracker receives a request from a querying peer, it
>   first discovers the ALTO server responsible for the querying peer.  This
>   discovery can be done using [RFC7286] [I-D.kiesel-alto-xdom-disc].
> The ALTO
>   client subsequently sends to the querying peer only those peers that are
>   preferred by the ALTO server responsible for the querying peer.
> The peers
>   do not query the ALTO servers themselves.  This gives the peers a better
>   initial selection of candidates, but does not consider peers
> learned through
>   direct peer-to-peer knowledge exchange.

changed.

> 
> - S4.1.2, paragraph under Figure 23: s/server, other than/server other than/

changed.
> 
>   Same paragraph: s/by talking to the ISP's tracker./by talking to
> the ISP's
>   tracker, which in turn communicates with the ALTO server using the ALTO
>   protocol./

changed.

The next sentence does not make sense to me.

        However, the
        peers would have still chance the contact other trackers,
        deployed by entities other than the peer's ISP.</t>

Maybe

        It should be noted that the peers are still allowed 
        to contact other trackers operated by entities other than the 
        peer's ISP, but in this case they cannot benefit from ALTO
        guidance.</t>

> 
> - S7.1, second paragraph: s/is not always clear/may not be apparent/

changed.
> 
> - S7.4, in the "Sorting" paragraph: s/change to sorting/change the sorting/

changed.
> 
>   Same section: You should finish the section by stating that: "Faking ALTO
>   guidance, while a real possibility, can be mitigated by using an
>   authenticated and encrypted transport between the server and the
> requesting
>   peer.  In terms of the ALTO protocol, the https:// scheme provides
> such an
>   encrypted and authenticated stream."

I combined that with the sentence we already had:

 <t>The ALTO protocol protects the authenticity and integrity 
 of ALTO information while in transit
 by leveraging the authenticity and integrity protection mechanisms 
 in TLS (see Section 8.3.5 of <xref target="RFC7285"/>).
 It has not yet been investigated how wrong ALTO
 guidance given by an autheticated ALTO server can impact the operation
 of the network and the applications.</t>

> - S9: s/discusses/has enumerated and discussed/

changed.

but: do we need a "Conclusion" section at all? It seems less common to RFCs.

> <End of review>

Thanks!

Sebastian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 10 May 2016 16:56:36 -0500

On 05/09/2016 03:56 PM, Sebastian Kiesel wrote:
> please see below. [...]

Sebastian: I will get back to you early next week with resolution to the
questions you have on my review.

Thanks for a close read.  I believe we should be able to converge next
week and get the document out of the WG.

More then.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 May 2016 16:51:59 -0500

> I started integrating Vijay's comments into the document.

Sebastian: Thank you for taking your time to do this.  Below, I
only provide feedback on issues that we need to further resolve.
Consider all other issues not listed below to be resolved as reflected
in the diff that you attached (which was very helpful).

A couple of places in your feedback you noted that some input from
Hans may be needed.  Can you please drive this to completion soon?  If
Hans does not have the bandwidth, we will simply go with what we have
for those sections.

More inline.

> these three bullets are copied verbatim from RFC 5693 and I am reluctant

I believe my suggested revisions to bullet 2 adds minor clarifications
to the grammar of rfc5693.  (I am fine with wordings of bullets 1 and 3,
so those are off the discussion here.)  Now, reluctance to change the
wording in bullet 2 simply because it is copied from rfc5693 may be
justifiable if whoever read this I-D knew rfc5693 inside-out.  In the
absence of such a case, I will contend that any clarity we add to the
specifications, however late, is always better.

That said, I will leave it to your sound judgment on what to do.  I
will certainly not be offended if you decided not to include this
change, so no worries.

> BitTorrent client process running on your computer), because the latter

OK, so this is good.  How about imparting this definition in the I-D,
something like the following:

OLD: (S2.2.1)
   An ALTO deployment involves four kinds of entities:

    1.  Source of topological information

    2.  ALTO server

    3.  ALTO client

    4.  Resource consumer (using the ALTO guidance)

NEW: (S2.2.1)
An ALTO deployment involves four kinds of entities:

    1.  Source of topological information

    2.  ALTO server

    3.  ALTO client

    4.  Resource consumer (using the ALTO guidance)
    (We differentiate between an ALTO client and a Resource Consumer
     as follows: an ALTO client will be composed of software implementing
     a HTTP client library, a JSON parser library and some data
     structures representing the ALTO maps.  This library will be
     linked in to a Resource Consumer, which could be thought of as
     the process executing on a host communicating with an ALTO
     server.)

> are operated within the same organization and/or network.

Good point, perhaps best to leave it as is.

> another example could be an internal network.

OK, leave it as is.

> but the discovery mechanism fails.

OK, leave as is.

> NACK. That is correct as is.

OK.

> (e.g. the endpoint property service, the PID property service, ...)

OK.

> the dash. Can you please check again?

My bad, not sure where I got that from.  Never mind.

> and replace all occurences of ISP and NSP by network operator.

I will leave it to you to decide whether to do this or not.

> why? "exposing network performance information" is only one thing

OK, leave as is.

> - the server does not even have to tell the client how he did it

OK, in that case, I would suggest
s/nature of the information./nature of the computation./

This makes it more direct that there are two aspects as you point
out above.

> but this goes way beyond what we need.

We don't need to do a four-tier example, but clearly you will agree that
the characteristics of the cellular bandwidth (of the kind provided by
an operator) are much different than those of WiFi bandwidth.  The
resources in the former are scarcer than those in the latter.  All this
said, I re-read the portion in question and perhaps the best thing to
do is to just leave it as is.  So, much ado about nothing :-)

> Who contributed this example?  Hans?  Can you do that?

Will need to close this soon.  Can you please drive this to completion
with Hans?

> Who contributed this example?  Hans?  Can you do that?

Will need to close this soon.  Can you please drive this to completion
with Hans?

- vijay

---

From: Hans Seidel <[email-masked]>
Date: Mon, 23 May 2016 09:12:31 +0200

Vijay, Sebastian,
all,

Since most of the issues are already addressed I have only a few comments.

Details inline.

>     the process executing on a host communicating with an ALTO

This is a good clarification but now we have two consecutive parentheses.
Do we really need the clarification that the resource consumer is the one
using the guidance here? I think it is better to include this in the 
previous
section.

-S2.1.1, third bullet under "ALTO CLlient"
     s/in the resource consumer and/or in the resource directory./
        in the resource consumer and/or in the resource directory which are
        using the ALTO guidance.

> This makes it more direct that there are two aspects as you point

Agree.
> Will need to close this soon.  Can you please drive this to completion

This section is not from me but I took the liberty to modify it. Details
in the attached file.

> Will need to close this soon.  Can you please drive this to completion

It is a good idea and modified the figure accordingly. Details in the 
attached file.

Hans

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 May 2016 08:11:29 -0500

> Since most of the issues are already addressed I have only a few comments.

Hans: Awesome!  Thanks for taking care of this.  I think we are really
close to getting this out.

Sebastian, please release -15 at your earliest and we can move ahead
with that version.

Thanks all for seeing this through.

Cheers,

- vijay