RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

My  apologies.

Hal

> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, November 14, 2014 11:10 AM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> It will be cool to see a XACML project at Apache, especially one that
> looks certain to be the main open source implementation. One minor
> correction:
> 
> > Colm MacCárthaigh
> 
> You have the wrong Apache Colm there :-)
> 
> Colm (O hEigeartaigh)
> 
> On Fri, Nov 14, 2014 at 1:55 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> 
> > I was not questioning whether to initiate discussion. That was what I
> > was trying to do.
> >
> > I was asking how to go about it.
> >
> > Thanks for the comments, they are noted.
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > Sent: Thursday, November 13, 2014 8:59 PM
> > > To: general@incubator.apache.org
> > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > >
> > > I think so.
> > >
> > > There's a few things that you want to iron out first, before people
> > > start voting on this.
> > >
> > > - 3 is generally the "minimum" number of mentors.
> > > - I can't find a "Paul Freemantle" on the apache committers list.
> > > There's a Paul Fremantle, minor spelling difference.
> > > - You may want to review this section to get a better understanding
> > > of the
> > > goals: http://incubator.apache.org/guides/proposal.html#formulating
> > >
> > > the Discuss option just helps everyone look at your proposal a
> > > little bit better and determine if there's any gotchas.  For
> > > example, I'm surprised to see a new incubator project using SVN.
> > >
> > > - Can you list out your issue tracking preference (should probably
> > > be JIRA unless you need something else)
> > > - Please also explicitly list the mailing lists your want.
> > >
> > > John
> > >
> > > On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart
> > > <ha...@oracle.com>
> > > wrote:
> > >
> > > > So you want me to repost the proposal with the Subject changed to
> > > > start with "[DISCUSS]"? Or should I simply reference the wiki
> page?
> > > >
> > > > Hal
> > > >
> > > > > -----Original Message-----
> > > > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > > > Sent: Thursday, November 13, 2014 5:03 PM
> > > > > To: general@incubator.apache.org
> > > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > > > >
> > > > > Hal,
> > > > >
> > > > > Per customs, would you mind if we cancel this and start with a
> > > > > [DISCUSS] thread about OpenAZ?  It's unclear if you meant this
> > > > > to
> > > be
> > > > > a vote or something.
> > > > >
> > > > > John
> > > > >
> > > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart
> > > > > <ha...@oracle.com>
> > > > > wrote:
> > > > >
> > > > > > Abstract
> > > > > >
> > > > > > OpenAz is a project to create tools and libraries to enable
> > > > > > the development of Attribute-based Access Control (ABAC)
> > > > > > Systems in a variety of languages. In general the work is at
> > > > > > least consistent with or actually conformant to the OASIS
> XACML Standard.
> > > > > >
> > > > > > Proposal
> > > > > >
> > > > > > Generally the work falls into two categories: ready to use
> > > > > > tools
> > > > > which
> > > > > > implement standardized or well understood components of an
> > > > > > ABAC
> > > > > system
> > > > > > and design proposals and proof of concept code relating to
> > > > > > less well understood or experimental aspects of the problem.
> > > > > >
> > > > > > Much of the work to date has revolved around defining
> > > > > > interfaces enabling a PEP to request an access control
> decision from a PDP.
> > > > > > The XACML standard defines an abstract request format in xml
> > > > > > and protocol wire formats in xaml and json, but it does not
> > > > > > specify programmatic
> > > > > interfaces in any language.
> > > > > > The standard says that the use of XML (or JSON) is not
> > > > > > required only the semantics equivalent.
> > > > > >
> > > > > > The first Interface, AzAPI is modeled closely on the XACML
> > > defined
> > > > > > interface, expressed in Java. One of the goals was to support
> > > > > > calls
> > > > > to
> > > > > > both a PDP local to the same process and a PDP in a remote
> > > server.
> > > > > > AzAPI includes the interface, reference code to handle things
> > > like
> > > > > the
> > > > > > many supported datatypes in XACML and glue code to mate it to
> > > > > > the
> > > > > open
> > > > > > source Sun XACML implementation.
> > > > > >
> > > > > > Because of the dependence on Sun XACML (which is XACML 2.0)
> > > > > > the interface was missing some XACML 3.0 features. More
> > > > > > recently this was corrected and
> > > > > > WSo2 has mated it to their XACML 3.0 PDP. Some work was done
> > > > > > by the JPMC team to support calling a remote PDP. WSo2 is
> also
> > > > > > pursuing this
> > > > > capability.
> > > > > >
> > > > > > A second, higher level interface, PEPAPI was also defined.
> > > > > > PEPAPI is more intended for application developers with
> little
> > > > > > knowledge of XACML. It allows Java objects which contain
> > > > > > attribute information to
> > > > > be passed in.
> > > > > > Conversion methods, called mappers extract information from
> > > > > > the objects and present it in the format expected by XACML.
> > > > > > Some implementers have chosen to implement PEPAPI directly
> > > > > > against their
> > > > > PDP, omitting the use of AzAPI.
> > > > > > Naomaru Itoi defined a C++ interface which closely matches
> the
> > > > > > Java
> > > > > one.
> > > > > >
> > > > > > Examples of more speculative work include: proposals for
> > > > > > registration and dispatch of Obligation and Advice handlers,
> a
> > > > > > scheme called AMF
> > > > > to
> > > > > > tell PIPs how to retrieve attributes and PIP code to
> implement
> > > it,
> > > > > > discussion of PoC code to demonstrate the use of XACML
> > > > > > policies
> > > to
> > > > > > drive OAuth interations and a proposal to use XACML policies
> > > > > > to
> > > > > express OAuth scope.
> > > > > >
> > > > > > AT&T has recently contributed their extensive XACML framework
> > > > > > to the project.
> > > > > >
> > > > > > The AT&T framework represents the entire XACML 3.0 object set
> > > > > > as
> > > a
> > > > > > collection of Java interfaces and standard implementations of
> > > > > > those interfaces.  The AT&T PDP engine is built on top of
> this
> > > > > > framework
> > > > > and
> > > > > > represents a complete implementation of a XACML 3.0 PDP,
> > > including
> > > > > all
> > > > > > of the multi-decision profiles. In addition, the framework
> > > > > > also contains an implementation of the OASIS XACML 3.0
> RESTful
> > > > > > API
> > > v1.0
> > > > > and
> > > > > > XACML JSON Profile v1.0 WD 14. The PEP API includes
> annotation
> > > > > > functionality, allowing application developers to simply
> > > > > > annotate a Java class to provide attributes for a request.
> The
> > > > > > annotation
> > > > > support
> > > > > > removes the need for application developers to learn much of
> > > > > > the
> > > API.
> > > > > >
> > > > > > The AT&T framework also includes interfaces and
> > > > > > implementations
> > > to
> > > > > > standardize development of PIP engines that are used by the
> > > > > > AT&T PDP implementation, and can be used by other
> > > > > > implementations
> > > built
> > > > > > on top of the AT&T framework. The framework also includes
> > > > > > interfaces and implementations for a PAP distributed cloud
> > > > > > infrastructure of PDP nodes that includes support for policy
> > > > > > distribution and pip configurations. This PAP infrastructure
> > > > > > includes a web application administrative console that
> > > > > > contains a XACML 3.0 policy editor, attribute dictionary
> > > > > > support, and management of PDP RESTful node instances. In
> > > > > > addition, there are tools available for policy
> > > > > simulation.
> > > > > >
> > > > > > Background
> > > > > >
> > > > > > Access Control is in some ways the most basic IT Security
> > > service.
> > > > > > It consists of making a decision about whether a particular
> > > > > > request should be allowed and enforcing that decision. Aside
> > > > > > from schemes
> > > > > like
> > > > > > permission bits and Access Control Lists (ACLs) the most
> > > > > > common way access control is implemented is as code in a
> > > > > > server or application which typically intertwines access
> > > > > > control logic with business logic, User interface and other
> > > > > > software. This makes it difficult to understand, modify,
> > > > > > analyze or even locate the security policy. The primary
> > > > > > challenge of Access Control is striking the right balance
> > > > > > between powerful expression and
> > > intelligibility to human beings.
> > > > > >
> > > > > > The OASIS XACML Standard exemplifies Attribute-Based Access
> > > > > > Control (ABAC). In ABAC, the Policy Decision Point (PDP) is
> > > > > > isolated from other components. The Policy Enforcement Point
> > > (PEP)
> > > > > > must be located so as to be able to enforce the decision,
> > > > > > typically near the
> > > > > resource.
> > > > > > The PEP first asks the PDP if access should be allowed and
> > > > > > provides data, in the form of Attributes, to be used as input
> > > > > > to the policies
> > > > > held by the PDP.
> > > > > >
> > > > > > In addition to responding permit or deny, XACML allows a
> > > > > > policy
> > > to
> > > > > > emit Obligations or Advice, which direct the PEP to do
> certain
> > > > > things,
> > > > > > such logging the access or failure or promising to get rid of
> > > > > > the
> > > > > data
> > > > > > after 30 days.
> > > > > >
> > > > > > Attributes are identified as being in a certain category
> which
> > > > > > represents one element in the proposed access. For example
> > > > > > attributes may be associated with the resource being
> accessed,
> > > the
> > > > > > action being taken or the environment, .e.g. date/time.
> > > Attributes
> > > > > > may also be associated with any or several types of Subjects,
> > > > > > which represent the active parties to the access, such as the
> > > > > > requester, intermediaries, the recipient (if different), the
> > > > > > codebase, the machine executing the
> > > > > code.
> > > > > >
> > > > > > Attributes may be provided by the PEP and usually at least a
> > > > > > few are, but Attributes may also added by other components of
> > > > > > the system. It
> > > > > is
> > > > > > also possible for a PDP to add attributes in the middle of
> > > > > > policy
> > > > > evaluation.
> > > > > > All of these obtain Attributes from the Policy Information
> > > > > > Point
> > > > > (PIP).
> > > > > >
> > > > > > The Policy Administration Point (PAP) creates policies and
> > > manages
> > > > > > then through their life cycles and generally the entire
> > > > > infrastructure.
> > > > > >
> > > > > > The XACML language is essentially a set of expressions which
> > > > > > evaluate to a Boolean. If true the policy is said to be
> > > > > > applicable. The Policy contains permit or deny and may
> include
> > > > > > Permissions and or Advice. If policies disagree we resolve
> the
> > > conflict with combining algorithms.
> > > > > > XACML provides some standard ones and you can implement your
> own.
> > > > > > Mostly they are common sense like drop non-applicable
> polices.
> > > > > > A commonly used algorithm is default deny. Deny overrides
> permit.
> > > > > >
> > > > > > Rationale
> > > > > >
> > > > > > Access Control may be the most basic security service, but
> for
> > > the
> > > > > > most part it remains primitive in practice. While other
> > > > > > services like message protection and authentication have seen
> > > > > > many
> > > advances
> > > > > > in recent years and decades, deployed access control systems
> > > > > > are opaque, difficult to us and harder to manage. Most
> > > > > > organizations claim that they have security policies, protect
> > > > > > privacy and accurately report financial results, but in
> > > > > > practice they have no real way of discovering whether their
> > > > > > systems actually behave the way they are
> > > > > alleged to do.
> > > > > >
> > > > > > Just the foreground problems relating to deploying practical
> > > > > > ABAC systems make a formidable list. If only the PDP knows
> > > > > > what the policies are, how do we make sure it gets the
> > > > > > attributes it needs to evaluate policies? How can we name
> > > > > > organize, register and dispatch Obligations and Advice,
> > > > > > allowing handlers to be provided by the
> > > > > system
> > > > > > and added by users? How can the XACML
> > > > > > 3.0 feature of being able to create your own attribute
> > > > > > categories
> > > > > best
> > > > > > be supported by the infrastructure and utilized by users?
> What
> > > are
> > > > > the
> > > > > > best ways to create and test policies? What tools will best
> > > > > > help us analyze the effects of the policies in force?
> > > > > >
> > > > > > However, new requirements are rapidly being introduced and
> > > > > > need
> > > to
> > > > > > be
> > > > > met.
> > > > > > Privacy requirements continue to increase in complexity and
> > > scope.
> > > > > > Data which moves around, such as documents, need to be
> protected.
> > > > > > We need secure ways to delegate authority without undermining
> > > > > > the integrity of the access control system. New applications,
> > > business
> > > > > and
> > > > > > social relationships are driving the need for new policy and
> > > > > delegation capabilities.
> > > > > >
> > > > > > We believe that the way to meet these challenges is to get
> > > > > > more
> > > > > people
> > > > > > actively engaged in using what is currently available so they
> > > > > > can understand its limitations and make it better. We need to
> > > > > > make it far easier to get a basic access control
> > > > > > infrastructure up and
> > > running.
> > > > > We
> > > > > > need more people who are familiar with XACML the way many
> > > > > > people are familiar with SQL. If as some people say, XACML is
> > > > > > the assembly language of access control, we need the real
> > > > > > world experience with it that will lead us to the useful
> > > > > > abstractions that can be implemented in higher level
> languages
> > > > > > and other
> > > tools.
> > > > > >
> > > > > > Initial Goals
> > > > > >
> > > > > > Work is currently underway to extend the PEPAPI and increase
> > > > > > its flexibility. Since it does not directly correspond to any
> > > standard
> > > > > the
> > > > > > way AzAPI does, it is necessary to struggle with the issues
> of
> > > > > > what
> > > > > to
> > > > > > expose and what to hide from consumers of the API.
> > > > > >
> > > > > > Other work in progress involves the architecture of
> > > > > > Obligations and Advice. There is also an effort to develop a
> > > > > > remote client which can easily be dropped into any Java
> > > > > > environment and make decision
> > > > > requests
> > > > > > of any commercial or open source XACML PDP.
> > > > > >
> > > > > > The contribution of AT&T's framework creates a need to
> > > > > > integrate the prior work with it. Most of the focus will be
> on
> > > > > > AzAPI and
> > > the
> > > > > > corresponding AT&T API, which do largely the same thing. The
> > > > > > result
> > > > > is
> > > > > > likely to be a synthesis, since each has features the other
> > > lacks.
> > > > > > Then PEPAPI will need to be integrated with the new API. The
> > > > > > AT&T PDP and PAP will be incorporated as is. There has been
> > > > > > some parallel work done in the area of PIPs. Work will be
> > > > > > required to understand how to
> > > > > proceed here.
> > > > > >
> > > > > > Current Status
> > > > > >
> > > > > >        Meritocracy
> > > > > >
> > > > > > The project was started by Prateek Mishra, Rich Levinson and
> > > > > > Hal Lockhart in 2010. Rich Levinson wrote most of the AzAPI
> > > > > > and
> > > PEPAPI
> > > > > > code. Naomaru Itoi defined the C++ version of the PEPAPI. In
> > > > > > 2013 Duanhua Tu and Ajith Nair contributed code both using
> and
> > > > > > extending AzAPI and PEPAPI and incorporating PIPs using the
> > > > > > AMF
> > > as
> > > > > > originally proposed by Hal Lockhart. In
> > > > > > 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated
> > > > > > AzAPI to include all XACML 3.0 features. In 2014 Pam Dragosh
> > > > > > and Chris Rath contributed the XACML infrastructure they had
> > > > > > developed at
> > > AT&T.
> > > > > >
> > > > > > During most of its history the project has been very small
> and
> > > has
> > > > > > made decisions by informal consensus. Major design issues
> have
> > > > > > been decided by open debate. Minor issues and experimental
> > > > > > proposals have been openly welcomed. Several of the
> > > > > > participants have a background
> > > > > in
> > > > > > open consensus-based standards making.
> > > > > >
> > > > > > In addition to the mailing list, the project has regular
> phone
> > > > > > calls every other Thursday.
> > > > > >
> > > > > >        Community
> > > > > >
> > > > > > The original focus of the project was to attract developers
> of
> > > > > > XACML products, either individuals or corporations, and to
> > > > > > build alignment among vendors on a common API that could
> > > > > > simplify technical integration for their customers.  As
> OpenAz
> > > > > > has
> > > matured,
> > > > > > our
> > > > > community
> > > > > > has grown to include application developers working to adopt
> > > > > > and
> > > > > deploy XACML in their
> > > > > > applications.   So, for example, contributions reflect what
> > > > > individual
> > > > > > developers have learned in vertical industries such as
> > > > > > financial services, healthcare, and computing and
> > > > > > communications services, and our APIs and internal component
> > > > > > architecture have evolved to reflect
> > > > > a
> > > > > > strong practical understanding of what it takes to deploy
> > > > > > XACML applications in a large organization.
> > > > > >
> > > > > >        Core Developers
> > > > > >
> > > > > > The following developers have written most of the code to
> date.
> > > > > >
> > > > > > Pam Dragosh <pdragosh at research dot att dot com> Rich
> > > > > > Levinson
> > > <
> > > > > > rich.levinson at oracle dot com> Ajith Nair
> <ajithkumar.r.nair
> > > > > > at jpmchase dot com> Chris Rath <car at research dot att dot
> > > > > > com>
> > > > > Duanhua
> > > > > > Tu <duanhua.tu at jpmchase dot com>
> > > > > >
> > > > > > The following people made other significant technical
> > > contributions.
> > > > > >
> > > > > > David Laurence <david.c.laurance at jpmorgan dot com> Hal
> > > Lockhart
> > > > > > <hal.lockhart at oracle dot com> Prateek Mishra
> prateek.mishra
> > > > > > at oracle dot com>
> > > > > >
> > > > > >
> > > > > >        Alignment
> > > > > >
> > > > > > It has always been a goal to make OpenAz an Apache project.
> > > > > > The
> > > > > Apache
> > > > > > license was used for all contributions. We believe the
> project
> > > has
> > > > > now
> > > > > > reached a critical size in terms of developers, organizations
> > > > > > and contributed code to make it appropriate to make a
> proposal
> > > > > > to the
> > > > > Incubator.
> > > > > >
> > > > > > Known Risks
> > > > > >
> > > > > >        Orphaned Projects
> > > > > >
> > > > > > Given the small size of the project, there is a risk of the
> > > > > > project being orphaned. There seems to be strong interest in
> > > > > > the use of our tools, which should markedly increase with the
> > > > > > contribution of the AT&T code. "Where can I get an open
> source
> > > > > > PDP?" and "where can I get an open source policy editor?" are
> > > > > > frequent questions on XACML
> > > > > mailing lists.
> > > > > >
> > > > > >        Inexperience with Open Source
> > > > > >
> > > > > > While few of the developers have extensive experience with
> > > > > > open source, a number of us have long experience in standards
> > > > > > making
> > > in
> > > > > > open consensus-based environments. For example the XACML TC
> > > > > > has operated since
> > > > > > 2001 based on consensus building, with few, if any votes
> which
> > > > > > were not unanimous. The main challenge to the project will be
> > > > > > managing the process with more participants and a more formal
> > > process.
> > > > > >
> > > > > >        Homogeneous Developers
> > > > > >
> > > > > > Currently all the contributors are employees either of
> > > > > > companies offering an XACML product or large end users
> > > > > > deploying XACML technology for internal use. The positive
> > > > > > aspect is that they are all highly experienced senior
> > > > > > developers used to operating in a disciplined environment.
> The
> > > > > > disadvantage is that the focus to date has mostly been
> > > > > > problems that arise in large scale environments
> > > > > typified by the infrastructure of large corporations.
> > > > > >
> > > > > >        Reliance on Salaried Developers
> > > > > >
> > > > > > All current committers are salaried developers. However the
> > > > > > organizations they work for have a long term commitment to
> the
> > > > > > technology. We hope that in the Apache foundation we will be
> > > > > > able to attract new developers to help us address the many
> > > > > > fascinating unsolved technological problems associated with
> deploying ABAC.
> > > > > >
> > > > > >        Relationship with other Apache Projects
> > > > > >
> > > > > > As far as we can determine, no existing Apache project
> > > > > > overlaps with OpenAz in its goals of the technology developed
> so far.
> > > > > > However, beyond the immediate project goals there are many
> > > > > > potential opportunities for integration with existing Apache
> > > > > > projects. Shiro, Turbine and WSS4J are Java frameworks which
> > > could
> > > > > > incorporate XACML
> > > > > as
> > > > > > the policy language using OpenAz components. Manifold CF,
> Qpid
> > > and
> > > > > > Archiva already have hooks to incorporate external access
> > > > > > control
> > > > > systems.
> > > > > >
> > > > > >
> > > > > >        An Excessive Fascination with the Apache Brand
> > > > > >
> > > > > > We hope that becoming an Apache project will not only attract
> > > > > > new participants to OpenAz, but will draw attention to the
> > > > > > neglected
> > > > > field
> > > > > > of access control. As previously stated it has always been
> our
> > > > > > goal
> > > > > to
> > > > > > join Apache, the only question was when the time was ripe.
> > > > > >
> > > > > > Documentation
> > > > > >
> > > > > > The OpenAz web site is:
> > > > > >
> > > > > > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> > > > > >
> > > > > > Java docs can be found here:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > >
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/do
> > > > > c/
> > > > > > index.html
> > > > > >
> > > > > >
> > > > > > Initial Source
> > > > > >
> > > > > > The AzAPI, PEPAPI and other related code can be found on
> > > sourceforge:
> > > > > >
> > > > > > http://openaz.svn.sourceforge.net/viewvc/openaz/
> > > > > >
> > > > > >
> > > > > > AT&T's framework can be found on github:
> > > > > >
> > > > > > https://github.com/att/XACML
> > > > > >
> > > > > >
> > > > > > Source and Intellectual Property Submission Plan
> > > > > >
> > > > > > TBD
> > > > > >
> > > > > > External Dependencies
> > > > > >
> > > > > > There aren't any we are aware of. The AT&T software is
> > > > > > available
> > > > > under
> > > > > > the MIT license, but that seems to be permissible under
> Apache
> > > rules.
> > > > > >
> > > > > > Cryptography
> > > > > >
> > > > > > OpenAz does not provide any cryptographic capabilities. The
> > > > > > XACML Standard does specify some uses of cryptography
> directly, e.g.
> > > > > digital
> > > > > > signatures over policies and others by implication, e.g.
> > > > > > authentication via cryptography.
> > > > > >
> > > > > > Required Resources
> > > > > >
> > > > > >        Mailing lists
> > > > > >
> > > > > > The standard lists should be sufficient at the current time.
> > > > > >
> > > > > >        Subversion Directory
> > > > > >
> > > > > > We propose: https://svn.apache.org/repos/asf/incubator/openaz
> > > > > >
> > > > > >        Issue Tracking
> > > > > >
> > > > > > TBD
> > > > > >
> > > > > > Initial Committers
> > > > > >
> > > > > > Rich Levinson
> > > > > > Hal Lockhart
> > > > > > Prateek Mishra
> > > > > > David Laurance
> > > > > > Duanhua Tu
> > > > > > Ajith Nair
> > > > > > Srijith Nair
> > > > > > Pam Dragosh
> > > > > > Chris Rath
> > > > > >
> > > > > >
> > > > > > Affiliations
> > > > > >
> > > > > > Rich Levinson, Hal Lockhart and Prateek Mishra work for
> Oracle.
> > > > > > David Laurance, Duanhua Tu and Ajith Nair work for JP
> > > > > > Morgan-Chase. Srijith Nair works for Axiomatics. Pam Dragosh
> > > > > > and
> > > Chris Rath work for AT&T.
> > > > > >
> > > > > > Sponsors
> > > > > >
> > > > > >        Champion
> > > > > > Paul Freemantle
> > > > > >
> > > > > >        Nominated Mentors
> > > > > > Emmanuel Lécharny
> > > > > > Colm MacCárthaigh
> > > > > >
> > > > > >        Sponsoring Entity
> > > > > > The Sponsoring Entity will be the Incubator.
> > > > > >
> > > > > > -------------------------------------------------------------
> -
> > > > > > ---
> > > -
> > > > > > --- To unsubscribe, e-mail:
> > > > > > general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-
> > > help@incubator.apache.org
> > > > > >
> > > > > >
> > > >
> > > > -----------------------------------------------------------------
> -
> > > > --- To unsubscribe, e-mail:
> > > > general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-
> help@incubator.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> 
> 
> --
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org