Subject: [PEPPERMINT] Proposed Updated Charter

From: "Daryl Malas" <[email-masked]>
Date: Mon, 31 Mar 2008 14:10:20 -0600

All,

I was asked to re-write the charter using agreed upon SPEERMINT WG
defined terms.  I also added/changed a few minor suggested details.  The
update is below:

------------------------------------------
Existing charter:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has
done significant work on data exchanges among various network elements.

ENUM is specifically chartered to develop protocols that involve the
translation of E.164 numbers to URI's.
 
SPEERMINT has been chartered to develop best current practices among
real-time application service providers and how such services
interconnect across administrative boundaries.

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data
should be structured provisioned and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be service providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various Client User Agents and Registries or
bilateral or multilateral Registry to Registry.  Data exchanges could
include bulk data as well as real time updates. Typical data include
mappings of phone numbers to URIs, policies surrounding admission to
various points of network interconnection and various types of trunk
data.  In addition, there is a specific need for redistribution of such
Registry data to various types of network databases.  

The working group will draw upon expert advice and ongoing consultation
from the ENUM, SPEERMINT and PROVREG working groups. The working group
may also reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.
-------------------------------------
New revision:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
peering among SIP Service Providers (SSPs), entities that provide
session services utilizing SIP signaling to their customers. In
addition, the IETF has done significant work on data exchanges among
various network elements. The following working groups' work provides
the underlying context for much of the intended work within this
charter:

ENUM, which is specifically chartered to develop protocols that involve
the translation of E.164 numbers to URIs.
 
SPEERMINT, which has been chartered to develop requirements and best
current practices among real-time application SSPs and how such services
may interconnect across administrative boundaries.  This work will
provide details of how Session Establishment Data (SED) is collected and
what this data is comprised of, the use of this data to properly
identify an optimal path to the destination user agent (UA), and the
secure manners in which this and the SIP session data is exchanged
between all of the peering functions.  It is also recognizes peering
relationships become more complex as multiple peers are added to a
common relationship, these complex aspects and requirements of multiple,
yet common peering relationships are defined with the contexts of a
peering Federation.

The PEPPERMINT working group is chartered to define what data needs to
be exchanged among Multimedia administrative domains, and how that data
should be structured, provisioned, and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be any type of SSP, such as recognized telephony carriers,
enterprises, end-user groups, and Federations.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various bilateral or multilateral client User
Agents and related Registries.  Data exchanges could include bulk data
and/or real time updates. Typical data includes mappings of phone
numbers to URIs, policies surrounding admission to various points of
network interconnection, and various types of interconnect data.  In
addition, there is a specific need for the exchange of such data between
the Registry and various types of network databases (e.g. Local Number
Portability (LNP), Calling Name (CNAM), etc.).  

The working group will draw upon expert advice and on-going consultation
from the ENUM and SPEERMINT  working groups, and also the XML
Directorate. The working group will consider the reuse of elements of
RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.

---------------------------------------

Thanks...--Daryl

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

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 31 Mar 2008 16:28:08 -0400

Excellent ...

I don't think we need to specifically call out LNP and CNAM, "Network
databases" is sufficient.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 31 Mar 2008 16:33:40 -0400

What do you think about goals and milestones?

PROPOSED GOALS AND MILESTONES

Requirements for Session Establishment Data (SED) data exchanges.
Sept 08  ??

Provisioning of Session Establishment Data (SED) registries.
Nov 08

Provisioning of Localized Session Establishment Data (SED) caches.
Feb 09 

Something like this?

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Daryl Malas
>  Sent: Monday, March 31, 2008 4:10 PM
>  To: [email-masked]
>  Subject: [PEPPERMINT] Proposed Updated Charter
>  
>  All,
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 31 Mar 2008 20:31:16 -0500

Hello,

As I stated in the meeting, reference to enterprise/PBXs should be
removed. If you think it should remain please give examples of the
provisioned information?

Thanks,

Martin

-----Original Message-----

All,

 

 

Thanks...--Daryl

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Mar 2008 22:17:55 -0400

His proposed replacement text is only the second half of his email, which doesn't use the term "PBX" (thankfully).  It does use the term "enterprises", but does not define the scope of that, nor does it imply any and all enterprises would be involved or how (which I think it's good to keep undefined).

Examples would be an Enterprise using something out of PEPPERMINT itself to provision its own proxies/databases, for example with what service provider to use for what routes, or what SBE's to use to reach that service provider.  Or a service provider might exchange some information with the Enterprise, or vice-versa, for similar information.  The "enterprises" could be large corporations; or perhaps a service provider's own internal employee system, or their consumer voip service might be considered a separate, enterprise-type, from their other voip services/networks.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DOLLY, MARTIN C, ATTLABS
> Sent: Monday, March 31, 2008 9:31 PM
> To: Daryl Malas; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
>
> Hello,
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 31 Mar 2008 22:25:47 -0400

You are correct we did agree that for the time being this potential
application was out of scope for the charter, or is it?

I believe there was consensus that the first order charter would deal
principally with SSP to Registry and Registry to localized cached servers.
Is that your understanding as well?

So If I understand this correctly your problem is with ..

In line ..

Please indicate what part of the text is objectionable etc or propose
alternative text. 

In other words is a enterprise a SSP? Inquiring minds want to know. :-) 

>  enterprises, end-user groups, and Federations.
^^^^^^^^^^^^^^^^^^^^^

Here..????

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Mar 2008 23:01:11 -0400

Hey Daryl,
Looks pretty good!
Minor comments inline...

> Behalf Of Daryl Malas

There are some grammatical errors in the last sentence above.  I think you want to say: "It is also recognized that peering relationships become more complex as multiple peers are added to a common relationship; these complex aspects and requirements are defined within the contexts of a peering Federation."

Having said that, I'm not actually sure I agree with it.  Just because I peer with Foo, and Foo peers with Bar, does not mean I and Bar are in a common Federation nor have a common relationship, except for that we're both peers of Foo.  In other words I'm not convinced all relationships are transitive.  Take, for example, an SSP X in Israel peering with SSP Y in Egypt, who peers with SSP Z in Iran.

> be exchanged among Multimedia administrative domains, and how that data

Maybe change it to "SIP Multimedia administrative domains..."?

> Agents and related Registries.

I'm not sure I understand why the term "client User Agents" is used?  A Proxy is not a User Agent, and neither is an ENUM server, for example.   Or do you just mean it's a User Agent with respect to being the Agent of the data exchange?

> Data exchanges could include bulk data

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 1 Apr 2008 06:08:19 -0500

Hadriel,

I do not agree with your example, yet. Can you be a little more
specific, as to what information  peppermint would provide here?

Thanks,

Martin 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 10:18 PM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

His proposed replacement text is only the second half of his email,
which doesn't use the term "PBX" (thankfully).  It does use the term
"enterprises", but does not define the scope of that, nor does it imply
any and all enterprises would be involved or how (which I think it's
good to keep undefined).

Examples would be an Enterprise using something out of PEPPERMINT itself
to provision its own proxies/databases, for example with what service
provider to use for what routes, or what SBE's to use to reach that
service provider.  Or a service provider might exchange some information
with the Enterprise, or vice-versa, for similar information.  The
"enterprises" could be large corporations; or perhaps a service
provider's own internal employee system, or their consumer voip service
might be considered a separate, enterprise-type, from their other voip
services/networks.

-hadriel

> From: [email-masked] [mailto:[email-masked]]
On

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 09:01:11 -0600

Hello Martin,

I feel it is appropriate to include enterprises within the context of an
SSP.  Per the definition of an SSP, an enterprise provides SIP services
to its customers (employees), in much the same an operator would.  This
is the intention within the charter update below.

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

Thanks,

Martin

-----Original Message-----

All,

 

 

Thanks...--Daryl

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 09:08:54 -0600

Hadriel,

This was the intention.

Thanks,

Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 8:18 PM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

-hadriel

> On Behalf Of DOLLY, MARTIN C, ATTLABS
> defined terms.  I also added/changed a few minor suggested details.  
> The update is below:
>
> The IETF has been working on various aspects of session-based 
> Multimedia Interconnection among administrative domains. In addition, 
> the IETF has done significant work on data exchanges among various
network elements.

> data.  In addition, there is a specific need for redistribution of 
> such Registry data to various types of network databases.
>
> The working group will draw upon expert advice and ongoing 
> consultation from the ENUM, SPEERMINT and PROVREG working groups. The 
> working group may also reuse elements of RFC 4114, if possible.
>
> The IETF has been working on various aspects of session-based 
> Multimedia peering among SIP Service Providers (SSPs), entities that 
> provide session services utilizing SIP signaling to their customers. 
> In addition, the IETF has done significant work on data exchanges 
> among various network elements. The following working groups' work 
> provides the underlying context for much of the intended work within 
> this
> charter:
>
> ENUM, which is specifically chartered to develop protocols that 
> involve the translation of E.164 numbers to URIs.
>
> current practices among real-time application SSPs and how such 
> services may interconnect across administrative boundaries.  This work

> will provide details of how Session Establishment Data (SED) is 
> collected and what this data is comprised of, the use of this data to 
> properly identify an optimal path to the destination user agent (UA), 
> and the secure manners in which this and the SIP session data is 
> exchanged between all of the peering functions.  It is also recognizes

> peering relationships become more complex as multiple peers are added 
> to a common relationship, these complex aspects and requirements of 
> multiple, yet common peering relationships are defined with the 
> contexts of a peering Federation.
>

> be exchanged among Multimedia administrative domains, and how that 
> data should be structured, provisioned, and propagated. These 
> protocols would be outside the normal scope of establishing various 
> forms of a SIP session. These administrative domains are of any 
> practical size and could be any type of SSP, such as recognized 
> telephony carriers, enterprises, end-user groups, and Federations.
>

> addition, there is a specific need for the exchange of such data 
> between the Registry and various types of network databases (e.g. 
> Local Number Portability (LNP), Calling Name (CNAM), etc.).
>
> The working group will draw upon expert advice and on-going 
> consultation from the ENUM and SPEERMINT  working groups, and also the

> XML Directorate. The working group will consider the reuse of elements

> of RFC 4114, if possible.
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 1 Apr 2008 10:13:10 -0500

Daryl,

I view AT&T differently depending on whether I am accessing them
intranet versus as an AT&T customer, so I do not see them as being the
same. In the intranet case, it is the AT&T IT department that controls
everything, which is different than when I am a customer of AT&T.

Martin 

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 11:01 AM
To: DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello Martin,

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

Thanks,

Martin

-----Original Message-----

All,

 

 

Thanks...--Daryl

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 09:14:11 -0600

Richard,

Enterprise peering is within the scope of SPEERMINT, and I think they
should be considered within the general term of SIP Service Provider.

"A SIP Service Provider (or SSP) is an entity that provides session
   services utilizing SIP signaling to its customers."

IMHO, based on the above excerpt from the Terminology draft definition
of an SSP, I do not see why an enterprise cannot be considered within
this definition.  Their customers are their employees, whom they are
providing session services to.

--Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Monday, March 31, 2008 8:26 PM
To: 'DOLLY, MARTIN C, ATTLABS'; [email-masked]
Subject: Re: [PEPPERMINT] Proposed Updated Charter

I believe there was consensus that the first order charter would deal
principally with SSP to Registry and Registry to localized cached
servers.
Is that your understanding as well?

In line ..

> services  may interconnect across administrative boundaries.  This 
> work will  provide details of how Session Establishment Data (SED) is 
> collected  and  what this data is comprised of, the use of this data 
> to properly  identify an optimal path to the destination user agent 
> (UA), and the  secure manners in which this and the SIP session data 
> is exchanged  between all of the peering functions.  It is also 
> recognizes peering  relationships become more complex as multiple 
> peers are added to a  common relationship, these complex aspects and 
> requirements of  multiple,  yet common peering relationships are 
> defined with the contexts of a  peering Federation.
>  
>  The PEPPERMINT working group is chartered to define what data needs 
> to  be exchanged among Multimedia administrative domains, and how that

^^^^^^^^^^^^^^^^^^^^^

Here..????

> consultation  from the ENUM and SPEERMINT  working groups, and also 
> the XML  Directorate. The working group will consider the reuse of 
> elements of  RFC 4114, if possible.
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 1 Apr 2008 11:14:19 -0400

I completely agree with Hadriel and believe that an enterprise most
certainly is one example of a SSP.  An enterprise would logically like
to dictate to the world how others should send multimedia sessions to
it.  For instance, they may want to dictate that all SIP communications
for its SIP administrative domain traverse another SSP (like L3, Global
Crossing, Comcast, etc) - maybe to perform some form of Signaling or
Media message handling like handling security certificates - and in
doing so would provision the SBEs of the L3, GC, Comcast as the
"Next-hop" the world should use to communicate with them.  This seems
very logical and empowering to the enterprise.

It should also be noted that enterprises are specifically called out and
included in SPEERMINT work.

Adam

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DOLLY, 
> MARTIN C, ATTLABS
> Sent: Tuesday, April 01, 2008 7:08 AM
> To: Hadriel Kaplan; Daryl Malas; [email-masked]
> I do not agree with your example, yet. Can you be a little 
> more specific, as to what information  peppermint would provide here?
> 
> Thanks,
> 
> Martin 
> 
> His proposed replacement text is only the second half of his 
> email, which doesn't use the term "PBX" (thankfully).  It 
> does use the term "enterprises", but does not define the 
> scope of that, nor does it imply any and all enterprises 
> would be involved or how (which I think it's good to keep undefined).
> 
> Examples would be an Enterprise using something out of 
> PEPPERMINT itself to provision its own proxies/databases, for 
> example with what service provider to use for what routes, or 
> what SBE's to use to reach that service provider.  Or a 
> service provider might exchange some information with the 
> Enterprise, or vice-versa, for similar information.  The 
> "enterprises" could be large corporations; or perhaps a 
> service provider's own internal employee system, or their 
> consumer voip service might be considered a separate, 
> enterprise-type, from their other voip services/networks.
> 
> -hadriel
> 
> The
> Multimedia
> such
> consultation
> Multimedia
> involve
> services
> data
> between
> consultation

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 11:20:14 -0400

Imagine a big enterprise, having multiple branch offices, lots of user agents and proxies/servers/whatever.  They may want calls within a branch to stay in the branch, calls between certain branches to go over the public Internet, calls between other branches to use leased lines or VPNs, calls between other branches to use the PSTN or ESN-type TDM network, etc.  So they could potentially use an outcome of PEPPERMINT to dynamically provision their servers/proxies in the various branches with such routing data, and make changes as employees or groups are added or move branches.

OR another example is suppose this big enterprise connects to multiple service providers or federations, perhaps different ones for different branches - the providers or federations can dynamically inform the enterprise or its branches of which ingress points can be used for what routes, with potentially some other attributes yet to be defined.  That way as the provider/federation adds or removes ingress points or routes, it can do so in a more automated fashion.

I think, but I'm not sure, that including enterprises in the charter does not mean to say any of those things would happen, or that PEPPERMINT would actually define such uses explicitly/separately, or that they have to give special consideration to such - just that it's within the scope of the WG's purview to do so.  Is that correct?

-hadriel

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 09:24:03 -0600

Comments in-line... 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 9:01 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hey Daryl,
Looks pretty good!
Minor comments inline...

> contexts of a peering Federation.

There are some grammatical errors in the last sentence above.  I think
you want to say: "It is also recognized that peering relationships
become more complex as multiple peers are added to a common
relationship; these complex aspects and requirements are defined within
the contexts of a peering Federation."

[DM] Agreed...I will fix this.

Having said that, I'm not actually sure I agree with it.  Just because I
peer with Foo, and Foo peers with Bar, does not mean I and Bar are in a
common Federation nor have a common relationship, except for that we're
both peers of Foo.  In other words I'm not convinced all relationships
are transitive.  Take, for example, an SSP X in Israel peering with SSP
Y in Egypt, who peers with SSP Z in Iran.

[DM] Okay, I am not sure how you read "indirect" peering into that
sentence.  Also, just because you are a member of a federation does not
suddenly give you a "golden key" to peer with everyone within it.  The
point of the sentence is to indicate there are potential complexities to
be considered within PEPPERMINT when peers are in multilateral
relationships.  It should not be PEPPERMINT to determine what those
architectural complexities are.  These are discussed, documented, and
determined within SPEERMINT; however, based on these complexities,
PEPPERMINT will need to take into consideration the provisioning of data
within a Federation.  It will be, potentially, different than a single
bi-lateral peering arrangement.

[DM] I would rather suggest "SIP-enabled Multimedia administrative
domains..."

> should be structured, provisioned, and propagated. These protocols 
> would be outside the normal scope of establishing various forms of a 
> SIP session. These administrative domains are of any practical size 
> and could be any type of SSP, such as recognized telephony carriers, 

I'm not sure I understand why the term "client User Agents" is used?  A
Proxy is not a User Agent, and neither is an ENUM server, for example.
Or do you just mean it's a User Agent with respect to being the Agent of
the data exchange?

[DM] I would suggest "client User Agents" is changed to "SIP User
Agents", but a proxy would not be provisioned within an ENUM server as
an end-point.   A B2BUA, otherwise known as a UA to SIP, would be.

> Data exchanges could include bulk data and/or real time updates. 
> Typical data includes mappings of phone numbers to URIs, policies 
> surrounding admission to various points of network interconnection, 
> and various types of interconnect data.  In addition, there is a 
> specific need for the exchange of such data between the Registry and 
> various types of network databases (e.g. Local Number Portability 
> (LNP), Calling Name (CNAM), etc.).
>

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 09:28:11 -0600

Hadriel,

I agree it should be within the scope to consider an enterprise's use of
the outcome of PEPPERMINT, but it is not PEPPERMINT's job to determine
the formation of enterprises within varying peering architectures.  At
best, this would be done within SPEERMINT, and some architectures and
peering considerations for enterprises are already documented within
SPEERMINT artifacts.

--Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 9:20 AM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Imagine a big enterprise, having multiple branch offices, lots of user
agents and proxies/servers/whatever.  They may want calls within a
branch to stay in the branch, calls between certain branches to go over
the public Internet, calls between other branches to use leased lines or
VPNs, calls between other branches to use the PSTN or ESN-type TDM
network, etc.  So they could potentially use an outcome of PEPPERMINT to
dynamically provision their servers/proxies in the various branches with
such routing data, and make changes as employees or groups are added or
move branches.

OR another example is suppose this big enterprise connects to multiple
service providers or federations, perhaps different ones for different
branches - the providers or federations can dynamically inform the
enterprise or its branches of which ingress points can be used for what
routes, with potentially some other attributes yet to be defined.  That
way as the provider/federation adds or removes ingress points or routes,
it can do so in a more automated fashion.

I think, but I'm not sure, that including enterprises in the charter
does not mean to say any of those things would happen, or that
PEPPERMINT would actually define such uses explicitly/separately, or
that they have to give special consideration to such - just that it's
within the scope of the WG's purview to do so.  Is that correct?

-hadriel

> "enterprises", but does not define the scope of that, nor does it 
> imply any and all enterprises would be involved or how (which I think 
> it's good to keep undefined).
>
> Examples would be an Enterprise using something out of PEPPERMINT 
> itself to provision its own proxies/databases, for example with what 
> service provider to use for what routes, or what SBE's to use to reach

> that service provider.  Or a service provider might exchange some 
> information with the Enterprise, or vice-versa, for similar 
> information.  The "enterprises" could be large corporations; or 
> perhaps a service provider's own internal employee system, or their 
> consumer voip service might be considered a separate, enterprise-type,

> from their other voip services/networks.
>
> -hadriel
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 1 Apr 2008 18:02:28 +0200

Just to note that the reason that this text appeared in the first place
was in response to a question I asked about the size of systems to be
addressed. 

The smaller the systems that this becomes appropriate for, the more we
move into enterprise land, and out of that of the big public network
operators (although this is a generalisation as there are many
enterprise networks bigger that some public networks).

So it is range of system size I want to see represented in the text if
we are really stuck on terminology. 

Regards

Keith

> Sent: Tuesday, April 01, 2008 12:08 PM
> [mailto:[email-masked]]
> On
> [mailto:[email-masked]]
> > On Behalf Of Daryl Malas
> would

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 1 Apr 2008 10:12:45 -0600

Martin,

I do not disagree with your perspective; however, my point is the
defined processes should not be different.  If the processes are not
different (or perhaps have 1 additional "dip switch"), then I still
think it can be encompassed within an SSP.

--Daryl

-----Original Message-----
Sent: Tuesday, April 01, 2008 9:13 AM

Daryl,

Martin 

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Tuesday, April 01, 2008 11:01 AM
To: DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello Martin,

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

Thanks,

Martin

-----Original Message-----

All,

 

 

Thanks...--Daryl