RE: [Mavs] Additional comments to the requirements draft

Christian, some more thoughts...

1. I strongly encourage the co-authorship of this document by one or
more SP representatives.  Agreed.

2. Some of the terminology is rather confusing: e.g. I think the notion
of "MNE operator" is highly arguable, because I don't think there will
be such a meta-organization. Rather, I would replace this notion by "a
community of (VPN) service providers that use and operate the (entwork)
resources of a MNE facility to deploy and exploit a VPN service
offering".  The original white paper from which this draft was derived,
looked at a number of individual MNE use cases. Each use case was
described from the perspective of an individual service provider and the
business requirement that they needed to meet, i.e. integration,
wholesale, retail, etc. For each use case there was an MNE. Each MNE was
the set of carriers and interconnects that the service provider used to
fulfil their business need. Importantly, each MNE was used solely for
the purposes of the service providers business use case. So in this
context, the service provider became *the* MNE operator, because the MNE
was used solely for its business purposes. This was a use case-based
approach to understanding the requirements of an MNE.

Of course, that is one way of looking at things. Another way might be
for the MNE to be a superset of interconnected carriers and
interconnects. The MNE, in this case, serves the business needs of many
service providers; the MNE will serve many use cases; each use case
would utilise a subset of the MNE to meet a particular business
objective. This, I think, is more akin to your view of the MNE as
community - so long as that community can include carriers as well as
non-carriers like VNOs, SIs, NIs, etc. In this scenario, there clearly
would not be *an* MNE operator, but I think it remains important to
retain the concept that there are entities that are using their
respective subsets of the MNE community for their individual use
case/business needs. This way we have a concept - a handle - that will
enable us to properly understand the requirements of each use case
within the MNE. We just need a name for the entity.

-Dave