Subject: [CDNi] CDNI Metadata Interface

From: Kevin J Ma <[email-masked]>
Date: Fri, 7 Oct 2011 01:21:20 -0400

Hi all,

  Just uploaded a new I-D with a proposed metadata model and API:

    http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt

  The model takes a rather generic approach to metadata representation
  to support opaque metadata and addresses some of the security issues
  associated with metadata retrieval.  Comments welcome.

thanx.

--  Kevin J. Ma

---

From: HeXiaoyan <[email-masked]>
Date: Tue, 11 Oct 2011 17:27:46 +0800

Hi Kevin,
Some quick questions and comments on this draft,
>The Metadata objects are each associated with a URI within the Domain and
accessible through any of the Hostnames...  
- Could you further explain or give an example how a metadata is accessed by
a Hostname within the Domain? And a further question is how the data model
works if a metadata is only associated with a specific Hostname within one
Doman?

- The relationship between Agent objects and Metadata objects is a
one-to-one relationship, does this mean one agent can only access one
Metadata within one Domain?

> The association of each Metadata to an Agent allows different Agents to
retrieve different Metadata values for a given URI in the given Domain.  
- Don't understand why each Metadata object needs to be bind with an Agent
explicitly, IMO, whether to return different value to different Agents is an
inside process of the upCDN, what downCDN needs to do is just transmit its
identifier to the upCDN when retrieve a Metadata. 

- Which entity is responsible for creating the Agent objects within one
Domain? Does the CP can 'see' the downCDNs and creates corresponding Agent
objects and other CDNs on the way just transmitted it or each upCDN located
in the cascaded path creates a Agent object for each its downCDN?

Thanks.
Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin J Ma
Sent: Friday, October 07, 2011 1:21 PM
To: [email-masked]
Subject: [CDNi] CDNI Metadata Interface

Hi all,

thanx.

--  Kevin J. Ma

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Oct 2011 11:29:31 -0400

Hi Susan,

  thanx for the comments, responses inline:

> From: HeXiaoyan [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 5:28 AM
> To: Kevin J Ma; [email-masked]
> Subject: RE: [CDNi] CDNI Metadata Interface
> 
> Hi Kevin,

I was assuming that metadata would be valid for all hostnames.  If a hostname
needed separate metadata, a new domain would be required.  I was thinking of
hostname as a first level restriction.  My implementation does something along
the lines of the following (where hostname is checked before metadata lookup):

  domain = get_param_from_query_string(getenv("QUERY_STRING"), "domain")
  if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain))
    return error
  metadata = db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"),
                                                 domain, getenv("REMOTE_USER"))
  xml = generate_xml_for_metadata(metadata)
  return xml

> Metadata within one Domain?

That is a typo in the doc, good catch, thanx!  It should be one to many.
Each metadata must be associated with a single agent, but an agent can be
associated with multiple metadata.  Agent-1 could have metadatas A, B, and
C, while agent-2 could have a separate value for metadatas A and B, and also
have its own metadata D (that agent-1 does not have access to)

> identifier to the upCDN when retrieve a Metadata.

I think the fact that a uCDN would want/need to give out different values to
different dCDNs requires that there be a way to represent and store that
information.  Having it explicitly in the model, i think, simplifies the
implementation and guarantees that all implementation give this issue proper
consideration.

> in the cascaded path creates a Agent object for each its downCDN?

This is a good question.  Different agents would need to be create by different
entities, as you mention.  I would expect each CDN to create agents to represent
those (outside that CDN) who need access to the metadata interface.

thanx!

--  Kevin J. Ma

---

From: HeXiaoyan <[email-masked]>
Date: Fri, 14 Oct 2011 17:35:10 +0800

Hi Kevin,
Thanks for the response. Some further concern,
- I don't quite understand the restriction that require metadata of all
hostnames in one Domain have same value. The case exist that for a specific
metadata different hostnames often have different value. Compare with
creating multiple Domains with less hostname sharing the same metadata, I
think link metadata to hostname not Domain is more simpler.

-I interpret the role of the Agent object is to identify entities
communicated (correct me if I'm wrong), other interfaces in CDNI e.g.
Logging interface needs such an parameter as well, a universal solution for
that would be good, do you think the Agent object introduced in your draft
could also be applicable for other interfaces? 

Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 11:30 PM
To: HeXiaoyan; [email-masked]
Subject: RE: [CDNi] CDNI Metadata Interface

Hi Susan,

> works if a metadata is only associated with a specific Hostname within one

I was assuming that metadata would be valid for all hostnames.  If a
hostname
needed separate metadata, a new domain would be required.  I was thinking of
hostname as a first level restriction.  My implementation does something
along
the lines of the following (where hostname is checked before metadata
lookup):

                                                 domain,
getenv("REMOTE_USER"))

> in the cascaded path creates a Agent object for each its downCDN?

This is a good question.  Different agents would need to be create by
different
entities, as you mention.  I would expect each CDN to create agents to
represent
those (outside that CDN) who need access to the metadata interface.

thanx!

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 14 Oct 2011 10:25:38 -0400

Hi Susan,

  responses inline:

> Sent: Friday, October 14, 2011 5:35 AM

>From a conceptual perspective, it could be argued that the domain
object is extraneous.  As an implementation detail, however, the
multi-table joins, imo, were simplified by having a central object
to define the domain, so I added one.  From an operator perspective,
having a way to group multiple hostnames also seems useful, even
though, in the degenerate case, you could just have one hostname per
domain.  If there is a concensus view that the domain is unnecessary,
it could be removed.

> could also be applicable for other interfaces?

I agree that the other interfaces (control/logging) will require some
type of authentication and security.  The agent concept could certainly
be extended to other interfaces, and I agree that it would be good to
have the same solution for all interfaces

thanx.

--  Kevin J. Ma

> > - Could you further explain or give an example how a metadata is
> accessed
> > by
> > explicitly, IMO, whether to return different value to different Agents
> is
> > an

---

From: HeXiaoyan <[email-masked]>
Date: Mon, 17 Oct 2011 15:14:08 +0800

Hi Kevin,
I share the view that the concept of Domain is useful, my suggestion is
linking metadata to Hostname and keep the Domain,
i.e. something like the figure below. Benefit is metadata associated with
one custormer can be grouped even different
Hostnames belong the Domain has different metadata value.

  +----------+
 |        | 1
 | Agent   +---------------------------+
 |        |                |
 +----+-----+                  |
      | 1..*                |
      |                    |
      | 1                   | 1
  +----+-----+             +----+-----+
 |         |          |          |
 | Domain  |          |  Metadata |
 |         |          |          |
  +----+-----+             +-----+----+
      | 1                   |
      |                     |
      | 1..*                 |
  +----+-----+                 |
 |         |    1   0..*     |
 | Hostname +----------------------------+
 |         |
  +----------+

Thanks.

Best Regards
Xiaoyan(Susan) He
-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 10:26 PM
To: HeXiaoyan; [email-masked]
Subject: RE: [CDNi] CDNI Metadata Interface

Hi Susan,

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 17 Oct 2011 14:26:14 -0400

Hi Susan,

  ok, I think I understand now.  In writing the draft, I was not sure if 
  this would be a typical use case.  Adding the one-to-many relationship
  between the hostname and metadata tables would cause duplicate entries
  in the metadata table (one per hostname)?  One alternative would be to
  use a many-to-many relationship instead, though verification of domain
  constraints on creation becomes more complex.  In general, if we think
  that this flexibility is required, I have no issue with making changes
  to the model, however, if it is unlikely to be used, I would favor the
  simpler approach.

  Is a one-to-many relationship between the hostname and metadata tables
  that much better than removing the hostname table completely (and just
  adding a hostname field to the domain, i.e., the degenerate case where
  each domain only has one hostname)?  That is essentially what it would
  be doing?
  
thanx.

--  Kevin J. Ma

> Sent: Monday, October 17, 2011 3:14 AM
> > needed separate metadata, a new domain would be required.  I was
> thinking
> > of
> > I think the fact that a uCDN would want/need to give out different
> values
> > to

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 17 Oct 2011 12:42:33 -0700

Hello Kevin,

[with Individual hat on]

A first set of high level questions:

* directionality of metadata creation/retrieval/removal/update mechanism:
Could you clarify which of the above operation you see possibly happening in which direction?
For example, regarding update/removal, do you see:
	*a)  the POST possibly being issued towards the uCDN to update/remove some metadata in the uCDN repository?
	*b) the POST possibly being issued by the uCDN towards the dCDN to update/remove some metadata in the dCDN repository (after some out-of-date metadata had been retrieved by dCDN from uCDN).
For example, regarding retrieval, clearly we want the dCDN to issue a GET towards the uCDN to acquire metadata. Now do you see that the GET could possibly be also issued by the uCDN to check metadata stored by the dCDN?

* in your CDNI metadata model, a "domain" is directly associated with a set of "hostnames". So this assumes that the same set of unmodified hostnames is used unmodified everywhere in all the potential dCDNs. That can be the case in some deployment, but that may not always be the case. For example, when HTTP redirection is used across CDNs, an upstream CDN may want to modify (possibly hide) the actual content provider hostnames (and possibly part of the URI path) when redirecting to a dCDN (I believe this is mentioned in the framework). 
Would you consider modifying your proposed CDNI model to allow for the fact that a domain may be "referenced" differently by some dCDNs than by the uCDN?
I think it means:
	* the concept of "hostnames" should be made more flexible so it matches not just on hostnames but on pattern match over hostname/path. Let's call this "resource sets".
	* "resource sets" should be dependent on "Agents". So perhaps it shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN" basis.
Would that work for you?

* in section 3.3.3, you have a couple of examples showing "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"?

Cheers

Francois

---

From: HeXiaoyan <[email-masked]>
Date: Tue, 18 Oct 2011 17:27:26 +0800

Kevin,
> Adding the one-to-many relationship
> in the metadata table (one per hostname)?
Sorry, after reading the draft again, I have to say my intention was that
the relationship between the Hostname and Metadata object should be a
one-to-zero or one-to-one relation like the figure below. All metadata
associated with one hostname or one url prefix which at least containing a
hostname should be grouped in one Metadata object (i.e. explicitly define
all the properties of each hostname in one Metadata object). I think this is
more straight-forward and consistent with the existing today CDN metadata
model.  Is it possible for you to consider modifying your proposal on this?

   +----------+
  |        | 1
  |         |    1   0..1     |

When reading through the examples in section 3.3.3, I found no agent id/name
is conveyed in the metadata retrieval message, I remember we discussed that
for different agent the upCDN may response with different value of a
metadata, would you double check that?
Thanks.

Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 2:26 AM
To: HeXiaoyan; [email-masked]
Subject: RE: [CDNi] CDNI Metadata Interface

Hi Susan,

  
thanx.

--  Kevin J. Ma

---

From: HeXiaoyan <[email-masked]>
Date: Tue, 18 Oct 2011 17:44:26 +0800

Hi Francois,

>     * the concept of "hostnames" should be made more flexible so it
matches not just on hostnames but on pattern match over hostname/path. Let's
call this "resource sets".

       * "resource sets" should be dependent on "Agents". So perhaps it
shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN"
basis.

Are you proposing remove the "hostname" object or keep it and adding
"resource sets" to "Metadata"?

I think the "hostname" object should be kept as sometimes the customer would
possibly deploy a enforcement policy associated to a hostname , e.g. for
hostname associated with  a set of web pages, CP may prefer DNS routing as
HTTP redirection will cause cookie issues among others. Keeping hostname
level can provide cp with this flexibility.  

Best Regards

Xiaoyan(Susan) He

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, October 18, 2011 3:43 AM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] CDNI Metadata Interface

Hello Kevin,

[with Individual hat on]

Could you clarify which of the above operation you see possibly happening in
which direction?

       *a)  the POST possibly being issued towards the uCDN to update/remove
some metadata in the uCDN repository?

       *b) the POST possibly being issued by the uCDN towards the dCDN to
update/remove some metadata in the dCDN repository (after some out-of-date
metadata had been retrieved by dCDN from uCDN).

For example, regarding retrieval, clearly we want the dCDN to issue a GET
towards the uCDN to acquire metadata. Now do you see that the GET could
possibly be also issued by the uCDN to check metadata stored by the dCDN?

* in your CDNI metadata model, a "domain" is directly associated with a set
of "hostnames". So this assumes that the same set of unmodified hostnames is
used unmodified everywhere in all the potential dCDNs. That can be the case
in some deployment, but that may not always be the case. For example, when
HTTP redirection is used across CDNs, an upstream CDN may want to modify
(possibly hide) the actual content provider hostnames (and possibly part of
the URI path) when redirecting to a dCDN (I believe this is mentioned in the
framework). 

Would you consider modifying your proposed CDNI model to allow for the fact
that a domain may be "referenced" differently by some dCDNs than by the
uCDN?

I think it means:

       * the concept of "hostnames" should be made more flexible so it
matches not just on hostnames but on pattern match over hostname/path. Let's
call this "resource sets".

       * "resource sets" should be dependent on "Agents". So perhaps it
shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN"
basis.

Would that work for you?

* in section 3.3.3, you have a couple of examples showing "/CDNI/MI/domain".
Should those not say "/CDNI/MI/metadata"?

Cheers

Francois

 

Hi all,

thanx.

--  Kevin J. Ma

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Oct 2011 07:00:50 -0700

Hi,

On 18 Oct 2011, at 02:44, HeXiaoyan wrote:

> Are you proposing remove the “hostname” object or keep it and adding “resource sets” to “Metadata”?

I was proposing that we have a single object but just make it more flexible. In some cases, it will be identifying hostnames, but it some case it may identify some more granular set of resources (eg. a hostname + part of the URI path).

> I think the “hostname” object should be kept as sometimes the customer would possibly deploy a enforcement policy associated to a hostname , e.g. for hostname associated with  a set of web pages, CP may prefer DNS routing as HTTP redirection will cause cookie issues among others. Keeping hostname level can provide cp with this flexibility.  

I agree we want to be able to do that in certain situations.

Cheers

Francois

>  
> Best Regards
> Xiaoyan(Susan) He
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 18 Oct 2011 10:26:35 -0400

Hi Francois,

  comments inline:

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Monday, October 17, 2011 3:43 PM
> To: Kevin J Ma
> Cc: Francois Le Faucheur; [email-masked]
> 	*a)  the POST possibly being issued towards the uCDN to
> update/remove some metadata in the uCDN repository?

I think POSTs make the most sense going from upstream to downstream.
The agent was intended to moderate this, since any given pair of CDNs
could be both a uCDN and a dCDN for each other in different domains.

I see no reason why GETs could not go in both directions.  I can see a
case where upstream entities would want to verify downstream entities.

> * in your CDNI metadata model, a "domain" is directly associated with a
> set of "hostnames". So this assumes that the same set of unmodified
> hostnames is used unmodified everywhere in all the potential dCDNs. That
> can be the case in some deployment, but that may not always be the case.
> For example, when HTTP redirection is used across CDNs, an upstream CDN
> may want to modify (possibly hide) the actual content provider hostnames
> (and possibly part of the URI path) when redirecting to a dCDN (I believe
> this is mentioned in the framework).

I was thinking (though it is not noted in the document) that hostname
lists could be different in different dCDNs.  What is not entirely
clear to me is how metadata would get set across cascaded CDNs,
i.e., if the CP contracts CDN-A, and CDN-A makes a deal with CDN-B,
and CDN-B makes a deal with CDN-C, does the CP or CDN-A know about
CDN-C and is the CP or CDN-A responsible configuring metadata on
CDN-C?  Or, is CDN metadata only configured by the most immediate
uCDN (or the CP), i.e., only CDN-B (or the CP) will know the values of
metadata in CDN-C?

> Would you consider modifying your proposed CDNI model to allow for the
> fact that a domain may be "referenced" differently by some dCDNs than by
> the uCDN?
> I think it means:
> matches not just on hostnames but on pattern match over hostname/path.
> Let's call this "resource sets".
> shoudl be folded inside your "Metadata" so it can be defined on a per
> "dCDN" basis.
> Would that work for you?

Would the goal be to use the entire hostname/uri as a single combined
key?  I do not have a problem with merging them if we think that it
would be useful.

> * in section 3.3.3, you have a couple of examples showing
> "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"?

Yep.  Those are cut and paste errors, good catch!  I will fix those.

thanx!

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 18 Oct 2011 10:27:40 -0400

Hi Susan,

  inline:

> Sent: Tuesday, October 18, 2011 5:27 AM

Francois had a similar comment.  One resolution would be to move the hostname
into the metadata object and use it as part of the URI lookup?  Would that
make more sense?

In the examples, I used HTTP basic auth, so the agent name/password is
encoded in the Authorization header.

thanx.

--  Kevin J. Ma

> > > creating multiple Domains with less hostname sharing the same
> metadata,
> > I
> > > Logging interface needs such an parameter as well, a universal
> solution
> > > for
> > > > >The Metadata objects are each associated with a URI within the
> Domain
> > > and
> > > > works if a metadata is only associated with a specific Hostname
> within
> > > one
> > > > Doman?
> > >
> > >   metadata =
> db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"),
> > >                                                  domain,
> > > getenv("REMOTE_USER"))
> > > C, while agent-2 could have a separate value for metadatas A and B,
> and
> > > also
> > > > > The association of each Metadata to an Agent allows different
> Agents
> > > to
> > > > inside process of the upCDN, what downCDN needs to do is just
> transmit
> > > its

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 19 Oct 2011 09:01:33 -0700

Hi again,

Thanks for the responses. See embedded below:

> could be both a uCDN and a dCDN for each other in different domains.

Do we agree POST would normally be dis-allowed in dCDN-uCDN direction (regardless of whether this is "enforced" by the Agent or something else)?

Regarding the use of POST for metadata creation, are you proposing it so it is used by the uCDN to "create" metadata in the dCDN (ie to pre-populate metadata in the dCDN) or are you proposing it so it is used by say a CP to "create" the metadata in the uCDN that will then be "pulled" by dCDN?
(for metadata pre-positioning in dCDN, I had been thinking more of an approach where the uCDN would issue a trigger instructing the dCDN to GET the corresponding metadata)

> case where upstream entities would want to verify downstream entities.

Agreed.

In any case, I would suggest that you discuss/document directionality in upcoming versions, possibly though some table capturing all the possible cases.

> uCDN (or the CP), i.e., only CDN-B (or the CP) will know the values of

In my opinion, everything would typically operate as a chain, because the typical relationships between entities will be as a chain:
CP knows CDN-A, CDN-A knows CDN-B, CDN-B knows CDN-C.
So:
	* CDN-A would be responsible for crafting the metadata that will be pulled by CDN-B. CDN-A may elect to allow CP to directly populate (some/all) these metadata (so it does correctly reflect its policy).
	* CDN-B would then be responsible for crafting the metadata that will be pulled by CDN-C. CDN-B may elect to allow CDN-A to directly populate (some/all) these metadata (so it does correctly reflect its policy).
	* etc.

In any case, do you agree with the idea of having the hostname/resource-sets be tied to the Agent (so they can be different on a per CDN basis)?

> key?  I do not have a problem with merging them if we think that it

I do think it is useful to associate to a domain something that is more flexible than hostname. For example, a hostname+beginning-of-path.
In some cases, it will just be hostnames. In some cases, it will be finer-grain

Thanks

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 20 Oct 2011 01:53:43 -0400

Hi Francois,

  responses inline:

> Sent: Wednesday, October 19, 2011 12:02 PM
> To: Kevin J Ma
> Do we agree POST would normally be dis-allowed in dCDN-uCDN direction
> (regardless of whether this is "enforced" by the Agent or something else)?

I agree with that.

> Regarding the use of POST for metadata creation, are you proposing it so
> it is used by the uCDN to "create" metadata in the dCDN (ie to pre-
> populate metadata in the dCDN) or are you proposing it so it is used by
> say a CP to "create" the metadata in the uCDN that will then be "pulled"
> by dCDN?
> (for metadata pre-positioning in dCDN, I had been thinking more of an
> approach where the uCDN would issue a trigger instructing the dCDN to GET
> the corresponding metadata)

Primarily, I added the create/modify APIs because it seems odd to have
a retrieval API with no way for the metadata to have been populated
initially.  It could be used by the local CDN to populate its own
local metadatabase, by CPs to populate uCDN metadatabases, or by
uCDNs to populate dCDN metadatabases.

> In any case, I would suggest that you discuss/document directionality in
> upcoming versions, possibly though some table capturing all the possible
> cases.

Can do.

> In my opinion, everything would typically operate as a chain, because the
> typical relationships between entities will be as a chain:
>     * CDN-A would be responsible for crafting the metadata that will be
> pulled by CDN-B. CDN-A may elect to allow CP to directly populate
> (some/all) these metadata (so it does correctly reflect its policy).
>     * CDN-B would then be responsible for crafting the metadata that
> will be pulled by CDN-C. CDN-B may elect to allow CDN-A to directly
> populate (some/all) these metadata (so it does correctly reflect its
> policy).
>     * etc.
>
> In any case, do you agree with the idea of having the hostname/resource-
> sets be tied to the Agent (so they can be different on a per CDN basis)?

I agree with this as well.

> I do think it is useful to associate to a domain something that is more
> flexible than hostname. For example, a hostname+beginning-of-path.

Understood.

thanx.

--  Kevin J. Ma

> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient
> (or authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Cisco Systems France, Société à responsabiité limitée, Rue Camille
> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
> Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de
> la publication: Jean-Luc Michel Givone.
>