Subject: [PEPPERMINT] Question about charter

From: Cullen Jennings <[email-masked]>
Date: Sat, 3 Feb 2007 10:36:06 -0800

I have received some input about Peppermint but I have not received  
much about the overlap with speermint. If you think we need to form a  
WG to do this work, please let me know why and particularly why you  
think that speermint is not the right place to do at least the  
requirements phase of this work. We are really short on time so  
please let me know in the next 5 days (by end of 7th).

Keep in mind that the RAI agenda is very full and to run a BOF, it  
will steel time from another WG.

Thanks, Cullen

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Feb 2007 12:55:29 -0500

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Saturday, February 03, 2007 1:36 PM
> To: [email-masked]
> Cc: Jon Peterson
> Subject: [PEPPERMINT] Question about charter
> 
> 

Cullen,

My observation: the problem that PEPPERMINT is trying to address is a
different problem than the one SPEERMINT is chartered to work on.
PEPPERMINT is focused on a provisioning problem, not "real-time session
routing architectures and their associated use cases" (quote taken from
the SPEERMINT charter).  If the provreg working group were still around
I could see this topic being more closely aligned with the expertise
found in that working group.

Getting to the point: I would strongly support the idea of scheduling
this BOF if at all possible, even if it means thinking about doing it in
the applications area.  I don't know what Lisa and Ted think about that
idea.  It might be worth talking to them if it hasn't come up already.

-Scott-

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 5 Feb 2007 20:03:59 +0200

> From: Hollenbeck, Scott [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 7:55 PM
> To: Cullen Jennings; [email-masked]
> Cc: Jon Peterson
> Subject: RE: [PEPPERMINT] Question about charter
> 
> > requirements phase of this work. We are really short on 
> time so please 
> > let me know in the next 5 days (by end of 7th).
> > 
> My observation: the problem that PEPPERMINT is trying to 
> address is a different problem than the one SPEERMINT is 
> chartered to work on.
> PEPPERMINT is focused on a provisioning problem, not 
> "real-time session routing architectures and their associated 
> use cases" (quote taken from the SPEERMINT charter).  If the 
> provreg working group were still around I could see this 
> topic being more closely aligned with the expertise found in 
> that working group.
> 
> Getting to the point: I would strongly support the idea of 
> scheduling this BOF if at all possible, even if it means 
> thinking about doing it in the applications area.  I don't 
> know what Lisa and Ted think about that idea.  It might be 
> worth talking to them if it hasn't come up already.
> 
> -Scott-
> 

I would respectfully disagree. 

Such an approach would mean that for each problem that we identified in
the IETF we would start two working groups. One would be focused on
solving the problem itself, and the second on provisioning the entities
related to the solution of the problem. But what about alarms and
notifications related to the respective problem space? And what about
performance monitoring? A third and a fourth WG? 

I would say that it makes much more sense for a WG to extend its charter
and include related provisioning issues (and other operational aspects)
even if this happens at a later phase, after the basic architecture and
protocol aspects have been defined. Of course, if broader generic tools
or protocols could be considered to solve the provisioning problem they
could be considered. Actually in the case of peppermint there are some
discussions in the netconf WG about suggesting to look at netconf as one
of the possible solutions. 

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Feb 2007 13:26:03 -0500

> I would respectfully disagree.

Obviously I support what Scott is saying here. From my observations the
issues on speermint and peppermint are orthogonal to each other as Scott
observes.

The issues of provisioning data necessary to support realtime session
routing can be delt with separately and should be.

There are very serious "go to market issues" that service providers and
registry operators need to address ASAP. And I might add that could include
edge systems such as PBX's where an enterprise wants the support of a
service provider in global dial plan management and routing where the PBX is
trunking its session traffic directly into a service providers network over
IP trunks vs TCM.

I would encourage the rest of the list to chime in ASAP so the AD can have
fuller picture of all of the issues involved here.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Feb 2007 13:51:57 -0500

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 1:04 PM
> To: Hollenbeck, Scott; Cullen Jennings; [email-masked]
> Cc: Jon Peterson

> performance monitoring? A third and a fourth WG? 

The appropriate splits don't necessarily fit a formula.  That's why we
have discussions like this.

I don't see a problem with creating new working groups if they are
properly focused on a specific, manageable problem and they have a well
defined timetable for either solving the problem or going home.  I will
agree, though, that we haven't done that very well.  On the other hand,
we have experience with working groups that have lived far beyond their
expected lifespan as they've refocused, rechartered, and sometimes
floundered because no one wanted to put them out of their misery.
That's not necessarily a good thing.

-Scott-

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Feb 2007 14:00:49 -0500

> of the possible solutions.

Dan,

It took me sometime to figure out what you are talking about.  I  
think we are talking about provisioning in two different contexts.   
This is not about provisioning local routes in an SBC or some other  
bit of network gear under the control of the one doing the  
provisioning.  This is about provisioning phone numbers (I've  
generalized it to "identities", but in essence phone numbers) to a  
central authority.  It is much more akin to the EPP work than NETCONF.

I did surf over to the NETCONF working group and took a gander at the  
drafts.  For us to use NETCONF in this, we would still need to define  
the data model.  To me, NETCONF looks like an XML-based RPC  
mechanism, similar to XML-RPC or SOAP.  What am I missing that makes  
it a natural fit here?

-andy

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 6 Feb 2007 21:11:15 +0200

AndyN,
 
I am copying one of the NETCONF chairs (another Andy). 
 
I do not believe that you are missing anything at high level, but there
are two ways of filling in the gap that you have identified. Defining a
data model, or defining NETCONF verbs specific to provisioning phone
numbers ("identities"). There is an ongoing discussion in NETCONF
nowadays about what is the 'better' way ahead to make NETCONF
appropriate for applications like peppermint. I agree that NETCONF as
defined today may not be today the natural fit, but they need to learn
how to fill that gap in order to become useful in applications like
peppermint. 
 
Dan

  _____  

	From: Andrew Newton [mailto:[email-masked]] 
	Sent: Tuesday, February 06, 2007 9:01 PM
	To: Romascanu, Dan (Dan)
	Cc: Hollenbeck, Scott; Cullen Jennings; [email-masked]; Jon
Peterson
	Subject: Re: [PEPPERMINT] Question about charter

		Such an approach would mean that for each problem that
we identified in

		the IETF we would start two working groups. One would be
focused on

		solving the problem itself, and the second on
provisioning the entities

		related to the solution of the problem. But what about
alarms and

		notifications related to the respective problem space?
And what about

		

		I would say that it makes much more sense for a WG to
extend its charter

		and include related provisioning issues (and other
operational aspects)

		even if this happens at a later phase, after the basic
architecture and

		protocol aspects have been defined. Of course, if
broader generic tools

		or protocols could be considered to solve the
provisioning problem they

		could be considered. Actually in the case of peppermint
there are some

		discussions in the netconf WG about suggesting to look
at netconf as one

	Dan,

	It took me sometime to figure out what you are talking about.  I
think we are talking about provisioning in two different contexts.  This
is not about provisioning local routes in an SBC or some other bit of
network gear under the control of the one doing the provisioning.  This
is about provisioning phone numbers (I've generalized it to
"identities", but in essence phone numbers) to a central authority.  It
is much more akin to the EPP work than NETCONF.

	I did surf over to the NETCONF working group and took a gander
at the drafts.  For us to use NETCONF in this, we would still need to
define the data model.  To me, NETCONF looks like an XML-based RPC
mechanism, similar to XML-RPC or SOAP.  What am I missing that makes it
a natural fit here?

	-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Feb 2007 14:33:55 -0500

On Feb 3, 2007, at 1:36 PM, Cullen Jennings wrote:

> much about the overlap with speermint. If you think we need to form  
> a WG to do this work, please let me know why and particularly why  
> you think that speermint is not the right place to do at least the  

Cullen,

The difference between the two efforts is quite clear, I believe.   
SPEERMINT deals with media and signaling flow between peering  
entities.  The issues in that group have been about codecs, SIP  
headers, etc..  PEPPERMINT is about provisioning DIDs to a  
centralized authority and the caching of that data.  There is another  
big difference.  SPEERMINT is chartered to only do BCP work.  
PEPPERMINT will almost certainly require protocol work.

With regard to your question of "at least" doing the requirements  
work in SPEERMINT, this assumes that once that is done we would have  
to find another working group or go through the BoF process all over  
again to find a home for the protocol work.  That is a lot of heavy  
and slow process and seems unnecessary.  A much better approach,  
which I've seen quite often in the IETF, is to allow the separate  
working groups consult with each other.

Thanks for taking the time to come up to speed on these issues and to  
discuss your concerns with us.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Feb 2007 15:04:09 -0500

On Feb 6, 2007, at 2:11 PM, Romascanu, Dan ((Dan)) wrote:

> I do not believe that you are missing anything at high level, but  
> there are two ways of filling in the gap that you have identified.  
> Defining a data model, or defining NETCONF verbs specific to  
> provisioning phone numbers ("identities"). There is an ongoing  
> discussion in NETCONF nowadays about what is the 'better' way ahead  
> to make NETCONF appropriate for applications like peppermint. I  
> agree that NETCONF as defined today may not be today the natural  
> fit, but they need to learn how to fill that gap in order to become  
> useful in applications like peppermint.

I'm certainly willing to listen, but I have to be honest -- there is  
a lot I see in NETCONF that does not seem pleasing.  For starters,  
the three different bindings: one to SOAP, one to BEEP, and the one  
to SSH.  On top of that, the binding on top of SOAP seems redundant.   
Why not just use SOAP's own RPC mechanism if you are gonna use SOAP?

But this identifies one of the main differences between SPEERMINT and  
PEPPERMINT.  SPEERMINT is about SIP optimizations.  PEPPERMINT is  
about defining the use of another protocol (i.e. EPP, SOAP/HTTP,  
NETCONF) for provisioning.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Feb 2007 20:10:25 -0500

On Feb 6, 2007, at 6:27 PM, Andy Bierman wrote:

> Only the SSH transport mapping is mandatory in NETCONF.
> The SOAP and SSH mappings may not stay around if they don't get used.
> I'm not saying PEPPERMINT should use NETCONF.  You may decide
> that it is overkill, due to NE-specific details like non-volatile  
> storage and
> the different 'write models' (write target is the 'candidate' or
> the 'running' config), or the document-oriented operations like
> edit-config or copy-config.
>
> If you don't use any NETCONF features except the RPC mechanism,
> then you might as well use whatever RPC you want, such as the
> one defined for SOAP/HTTP.

Thanks.  That makes a lot of sense.

-andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Feb 2007 15:27:04 -0800

Andrew Newton wrote:
>> discussion in NETCONF nowadays about what is the 'better' way ahead to 
>> make NETCONF appropriate for applications like peppermint. I agree 
>> that NETCONF as defined today may not be today the natural fit, but 
>> they need to learn how to fill that gap in order to become useful in 
>> applications like peppermint.
> 
> I'm certainly willing to listen, but I have to be honest -- there is a 
> lot I see in NETCONF that does not seem pleasing.  For starters, the 
> three different bindings: one to SOAP, one to BEEP, and the one to SSH.  
> On top of that, the binding on top of SOAP seems redundant.  Why not 
> just use SOAP's own RPC mechanism if you are gonna use SOAP?
> 
> PEPPERMINT.  SPEERMINT is about SIP optimizations.  PEPPERMINT is about 
> defining the use of another protocol (i.e. EPP, SOAP/HTTP, NETCONF) for 
> provisioning.
> 

that it is overkill, due to NE-specific details like non-volatile storage and

> -andy

Andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Feb 2007 21:17:07 +0100

Hi Cullen,

sorry for my late response.

I read through the problem statement draft 
<draft-newton-peppermint-problem-statement-00.txt> and I also reviewed 
all SPEERMINT drafts (for their previous interim meeting).

My impression is that there is no overlap between PEPPERMINT and 
SPEERMINT. There also seems to be a problem that needs to be solved. I 
also got this impression from reading the problem statement draft (which 
is short and precise) but also from talking with others having more 
expertise in this area.

It is a separate question where the work should be done. It is a 
"management" (=Area Director) decision which working group should do 
what type of work.
I am personally in favor of more working groups with a smaller scope 
since working group chairs can be more focused on specific tasks in 
order to push them forward. When I looked at the discussions on the 
SPEERMINT mailing list, as a sort of indicator for the WG progress, then 
I am not sure it is a good idea to add new work to SPEERMINT (about 3 
mails in 2 months when the PEPPERMINT stuff is not considered).

Ciao
Hannes

Cullen Jennings wrote:
> requirements phase of this work. We are really short on time so please