Subject: [PEPPERMINT] There will not be a Official BOF on PEPPERMINT at IETF Prague
From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 12 Feb 2007 12:45:16 -0500
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

The IESG has decided not to hold a BOF on PEPPERMINT "at this time".

There are many reasons for this, principally scheduling, which is rather
complex this cycle.

This action does not imply that our problem statement is bad or that there
is not a clear indication that there are folks who want to move forward on
the work.

We all know this work is important and needs to get done.

This list will remain open.

What I'm going to try and do is see if I can get a room in Prague for an
unofficial BOF so we can collectively discuss what the next steps are before
Chicago and we resubmit a BOF plan and agenda.

Certainly one of the things we should do before Chicago is refine the
current Requirements proposals into something more well defined and
coherent.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
Skype:"rshockey101"
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

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

Date: Wed, 07 Feb 2007 21:17:07 +0100
From: Hannes Tschofenig <[email-masked]>
To: Cullen Jennings <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Cc: [email-masked], Jon Peterson <[email-masked]>

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:
>
> 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

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

Date: Tue, 06 Feb 2007 15:27:04 -0800
From: Andy Bierman <[email-masked]>
To: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Cc: Cullen Jennings <[email-masked]>, [email-masked], Jon Peterson <[email-masked]>

Andrew Newton wrote:
> 
> 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.
> 

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.

> -andy
> 
> 

Andy

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 20:10:25 -0500
To: Andy Bierman <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, [email-masked], Jon Peterson <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--===============1233486927==
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-1508-1170810601-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-1508-1170810601-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit

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
--=_zeke.ecotroph.net-1508-1170810601-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; -kht=
ml-line-break: after-white-space; "><BR><DIV><DIV>On Feb 6, 2007, at 6:27=
 PM, Andy Bierman wrote:</DIV><BR class=3D"Apple-interchange-newline"><BL=
OCKQUOTE type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT=
 face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Only the =
SSH transport mapping is mandatory in NETCONF.</FONT></P> <P style=3D"mar=
gin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D=
"font: 12.0px Helvetica">The SOAP and SSH mappings may not stay around if=
 they don't get used.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.=
0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"=
>I'm not saying PEPPERMINT should use NETCONF.<SPAN class=3D"Apple-conver=
ted-space">=A0 </SPAN>You may decide</FONT></P> <P style=3D"margin: 0.0px=
 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12=
.0px Helvetica">that it is overkill, due to NE-specific details like non-=
volatile storage and</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0=
px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">=
the different 'write models' (write target is the 'candidate' or</FONT></=
P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">the 'running' config), or the=
 document-oriented operations like</FONT></P> <P style=3D"margin: 0.0px 0=
.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0=
px Helvetica">edit-config or copy-config.</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR>=
</P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica=
" size=3D"3" style=3D"font: 12.0px Helvetica">If you don't use any NETCON=
F features except the RPC mechanism,</FONT></P> <P style=3D"margin: 0.0px=
 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12=
.0px Helvetica">then you might as well use whatever RPC you want, such as=
 the</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D=
"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">one defined for S=
OAP/HTTP.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>Thanks.=A0 That makes a =
lot of sense.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>=
-andy</DIV></BODY></HTML>
--=_zeke.ecotroph.net-1508-1170810601-0001-2--

--===============1233486927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1233486927==--

From: "Richard Shockey" <[email-masked]>
To: "'Cullen Jennings'" <[email-masked]>, "'Creighton, Tom'" <[email-masked]>
Subject: RE: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 16:44:55 -0500
Cc: [email-masked], 'Jon Peterson' <[email-masked]>
Reply-To: [email-masked]

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2007 4:07 PM
> To: Creighton, Tom
> Cc: [email-masked]; Jon Peterson
> Subject: Re: [PEPPERMINT] Question about charter
> 
> 
> Just one note that I had told Andy but should have sent to the list.
> 
> I've been thinking about the requirements and the solution to the
> requirements somewhat separately. It seem very likely to me that RAI
> folks have know the right stuff to write the requirements. It is less
> obvious to me where a solution to the requirements should be done or
> if there might already be most of a solution in some existing work.

I certainly agree with the thrust that the requirements need to come out of
RAI people. But as to where the work should be done is rather irrelevant to
most of us. I certainly see a great deal of expertise coming out of APPS for
instance. The most important thing is to get started since there are real
"time to market" issues.

> 
> 
> On Feb 6, 2007, at 12:30 PM, Creighton, Tom wrote:
> 
> > All:
> >
> > I fully agree with Andy's comments and would like to add that
> > asking the
> > SPEERMINT working group to re-charter in order to accommodate this
> > additional work would be a time consuming process and, in my
> > opinion, an
> > unneeded distraction for SPEERMINT.  I like Andy's "get in, get done,
> > and get out" approach to this proposed working group and believe that
> > this should be fairly easy to accomplish.  I cannot stress enough that
> > there is an immediate need by service providers and registry operators
> > for an open, standards-based, non-EPP interface for exchanging data.
> >
> > Regards,
> >
> > Tom
> >
> >> -----Original Message-----
> >> From: Andrew Newton [mailto:[email-masked]]
> >> Sent: Tuesday, February 06, 2007 14:34
> >> To: Cullen Jennings
> >> Cc: [email-masked]; Jon Peterson
> >> Subject: Re: [PEPPERMINT] Question about charter
> >>
> >>
> >> On Feb 3, 2007, at 1:36 PM, Cullen Jennings wrote:
> >>
> >>> 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).
> >>
> >> 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
> >>
> >> _______________________________________________
> >> PEPPERMINT mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/peppermint
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

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

From: Cullen Jennings <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 13:06:47 -0800
To: "Creighton, Tom" <[email-masked]>
Cc: [email-masked], Jon Peterson <[email-masked]>

Just one note that I had told Andy but should have sent to the list.

I've been thinking about the requirements and the solution to the  
requirements somewhat separately. It seem very likely to me that RAI  
folks have know the right stuff to write the requirements. It is less  
obvious to me where a solution to the requirements should be done or  
if there might already be most of a solution in some existing work.

On Feb 6, 2007, at 12:30 PM, Creighton, Tom wrote:

> All:
>
> I fully agree with Andy's comments and would like to add that  
> asking the
> SPEERMINT working group to re-charter in order to accommodate this
> additional work would be a time consuming process and, in my  
> opinion, an
> unneeded distraction for SPEERMINT.  I like Andy's "get in, get done,
> and get out" approach to this proposed working group and believe that
> this should be fairly easy to accomplish.  I cannot stress enough that
> there is an immediate need by service providers and registry operators
> for an open, standards-based, non-EPP interface for exchanging data.
>
> Regards,
>
> Tom
>
>> -----Original Message-----
>> From: Andrew Newton [mailto:[email-masked]]
>> Sent: Tuesday, February 06, 2007 14:34
>> To: Cullen Jennings
>> Cc: [email-masked]; Jon Peterson
>> Subject: Re: [PEPPERMINT] Question about charter
>>
>>
>> On Feb 3, 2007, at 1:36 PM, Cullen Jennings wrote:
>>
>>> 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).
>>
>> 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
>>
>> _______________________________________________
>> PEPPERMINT mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/peppermint

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 15:30:54 -0500
From: "Creighton, Tom" <[email-masked]>
To: "Andrew Newton" <[email-masked]>, "Cullen Jennings" <[email-masked]>
Cc: [email-masked], Jon Peterson <[email-masked]>

All:

I fully agree with Andy's comments and would like to add that asking the
SPEERMINT working group to re-charter in order to accommodate this
additional work would be a time consuming process and, in my opinion, an
unneeded distraction for SPEERMINT.  I like Andy's "get in, get done,
and get out" approach to this proposed working group and believe that
this should be fairly easy to accomplish.  I cannot stress enough that
there is an immediate need by service providers and registry operators
for an open, standards-based, non-EPP interface for exchanging data.

Regards,

Tom   =20

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2007 14:34
> To: Cullen Jennings
> Cc: [email-masked]; Jon Peterson
> Subject: Re: [PEPPERMINT] Question about charter
>=20
>=20
> On Feb 3, 2007, at 1:36 PM, Cullen Jennings wrote:
>=20
> > 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).
>=20
> Cullen,
>=20
> 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.
>=20
> 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.
>=20
> Thanks for taking the time to come up to speed on these issues and to
> discuss your concerns with us.
>=20
> -andy
>=20
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 15:04:09 -0500
To: "Romascanu, Dan ((Dan))" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, Andy Bierman <[email-masked]>, [email-masked], Jon Peterson <[email-masked]>

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

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 14:33:55 -0500
To: Cullen Jennings <[email-masked]>
Cc: [email-masked], Jon Peterson <[email-masked]>

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

> 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).

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

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

content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 21:11:15 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Andrew Newton" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, Andy Bierman <[email-masked]>, [email-masked], Jon Peterson <[email-masked]>

This is a multi-part message in MIME format.

--===============0854962698==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C74A22.92C53AE9"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C74A22.92C53AE9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

AndyN,
=20
I am copying one of the NETCONF chairs (another Andy).=20
=20
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.=20
=20
Dan
=20
=20
=20
=20

  _____ =20

	From: Andrew Newton [mailto:[email-masked]]=20
	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
=09
=09

	On Feb 5, 2007, at 1:03 PM, Romascanu, Dan ((Dan)) wrote:

		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?=20

	=09
	=09

		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.=20

	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

------_=_NextPart_001_01C74A22.92C53AE9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; khtml-nbsp-mode: space; =
khtml-line-break: after-white-space">
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007>AndyN,</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007>I am copying one of the NETCONF chairs =
(another Andy).=20
</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007>I do not believe that you are missing =
anything at high=20
level, but there are two ways of filling in the gap that you have =
identified.=20
Defining a data model, or defining NETCONF verbs specific to =
provisioning phone=20
numbers ("identities"). There is an ongoing discussion in NETCONF =
nowadays about=20
what is the 'better' way ahead to make NETCONF appropriate for =
applications like=20
peppermint. I agree that NETCONF as defined today may not be today the =
natural=20
fit, but they need to learn how to fill that gap in order to become =
useful in=20
applications like peppermint. </SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007>Dan</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D230500519-06022007></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Andrew Newton =
[mailto:[email-masked]]=20
  <BR><B>Sent:</B> Tuesday, February 06, 2007 9:01 PM<BR><B>To:</B> =
Romascanu,=20
  Dan (Dan)<BR><B>Cc:</B> Hollenbeck, Scott; Cullen Jennings;=20
  [email-masked]; Jon Peterson<BR><B>Subject:</B> Re: [PEPPERMINT] =
Question=20
  about charter<BR></FONT><BR></DIV>
  <DIV></DIV><BR>
  <DIV>
  <DIV>On Feb 5, 2007, at 1:03 PM, Romascanu, Dan ((Dan)) =
wrote:</DIV><BR=20
  class=3DApple-interchange-newline>
  <BLOCKQUOTE type=3D"cite">
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>Such an approach would mean that for each problem that we =
identified=20
    in</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>the IETF we would start two working groups. One would be =
focused=20
    on</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>solving the problem itself, and the second on provisioning =
the=20
    entities</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>related to the solution of the problem. But what about =
alarms=20
    and</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>notifications related to the respective problem space? And =
what=20
    about</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>performance monitoring? A third and a fourth WG?<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN></FONT></P>
    <P style=3D"MIN-HEIGHT: 14px; MARGIN: 0px; FONT: 12px =
Helvetica"><BR></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>I would say that it makes much more sense for a WG to =
extend its=20
    charter</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>and include related provisioning issues (and other =
operational=20
    aspects)</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>even if this happens at a later phase, after the basic =
architecture=20
    and</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>protocol aspects have been defined. Of course, if broader =
generic=20
    tools</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>or protocols could be considered to solve the provisioning =
problem=20
    they</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>could be considered. Actually in the case of peppermint =
there are=20
    some</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>discussions in the netconf WG about suggesting to look at =
netconf as=20
    one</FONT></P>
    <P style=3D"MARGIN: 0px"><FONT style=3D"FONT: 12px Helvetica" =
face=3DHelvetica=20
    size=3D3>of the possible solutions.<SPAN=20
    =
class=3DApple-converted-space>&nbsp;</SPAN></FONT></P></BLOCKQUOTE></DIV>=
<BR>
  <DIV>Dan,</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>It took me sometime to figure out what you are talking =
about.&nbsp; I=20
  think we are talking about provisioning in two different =
contexts.&nbsp; This=20
  is not about provisioning local routes in an SBC or some other bit of =
network=20
  gear under the control of the one doing the provisioning.&nbsp; This =
is about=20
  provisioning phone numbers (I've generalized it to "identities", but =
in=20
  essence phone numbers) to a central authority.&nbsp; It is much more =
akin to=20
  the EPP work than NETCONF.</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>I did surf over to the NETCONF working group and took a gander at =
the=20
  drafts.&nbsp; For us to use NETCONF in this, we would still need to =
define the=20
  data model.&nbsp; To me, NETCONF looks like an XML-based RPC =
mechanism,=20
  similar to XML-RPC or SOAP.&nbsp; What am I missing that makes it a =
natural=20
  fit here?</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>-andy</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C74A22.92C53AE9--

--===============0854962698==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0854962698==--

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] Question about charter
Date: Tue, 6 Feb 2007 14:00:49 -0500
To: "Romascanu, Dan ((Dan))" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, [email-masked], Jon Peterson <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--===============0222428561==
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-4101-1170788414-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-4101-1170788414-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit

On Feb 5, 2007, at 1:03 PM, Romascanu, Dan ((Dan)) wrote:

> 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,

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
--=_zeke.ecotroph.net-4101-1170788414-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; -kht=
ml-line-break: after-white-space; "><BR><DIV><DIV>On Feb 5, 2007, at 1:03=
 PM, Romascanu, Dan ((Dan)) wrote:</DIV><BR class=3D"Apple-interchange-ne=
wline"><BLOCKQUOTE type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0px 0.=
0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"=
>Such an approach would mean that for each problem that we identified in<=
/FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Hel=
vetica" size=3D"3" style=3D"font: 12.0px Helvetica">the IETF we would sta=
rt two working groups. One would be focused on</FONT></P> <P style=3D"mar=
gin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D=
"font: 12.0px Helvetica">solving the problem itself, and the second on pr=
ovisioning the entities</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetic=
a">related to the solution of the problem. But what about alarms and</FON=
T></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helveti=
ca" size=3D"3" style=3D"font: 12.0px Helvetica">notifications related to =
the respective problem space? And what about</FONT></P> <P style=3D"margi=
n: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"=
font: 12.0px Helvetica">performance monitoring? A third and a fourth WG?<=
SPAN class=3D"Apple-converted-space">=A0</SPAN></FONT></P> <P style=3D"ma=
rgin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px=
"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Hel=
vetica" size=3D"3" style=3D"font: 12.0px Helvetica">I would say that it m=
akes much more sense for a WG to extend its charter</FONT></P> <P style=3D=
"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" sty=
le=3D"font: 12.0px Helvetica">and include related provisioning issues (an=
d other operational aspects)</FONT></P> <P style=3D"margin: 0.0px 0.0px 0=
.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Hel=
vetica">even if this happens at a later phase, after the basic architectu=
re and</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=
=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">protocol aspec=
ts have been defined. Of course, if broader generic tools</FONT></P> <P s=
tyle=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D=
"3" style=3D"font: 12.0px Helvetica">or protocols could be considered to =
solve the provisioning problem they</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.=
0px Helvetica">could be considered. Actually in the case of peppermint th=
ere are some</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FON=
T face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">discussi=
ons in the netconf WG about suggesting to look at netconf as one</FONT></=
P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">of the possible solutions.<SP=
AN class=3D"Apple-converted-space">=A0</SPAN></FONT></P> </BLOCKQUOTE></D=
IV><BR><DIV>Dan,</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><D=
IV>It took me sometime to figure out what you are talking about.=A0 I thi=
nk we are talking about provisioning in two different contexts.=A0 This i=
s not about provisioning local routes in an SBC or some other bit of netw=
ork gear under the control of the one doing the provisioning.=A0 This is =
about provisioning phone numbers (I've generalized it to "identities", bu=
t in essence phone numbers) to a central authority.=A0 It is much more ak=
in to the EPP work than NETCONF.</DIV><DIV><BR class=3D"khtml-block-place=
holder"></DIV><DIV>I did surf over to the NETCONF working group and took =
a gander at the drafts.=A0 For us to use NETCONF in this, we would still =
need to define the data model.=A0 To me, NETCONF looks like an XML-based =
RPC mechanism, similar to XML-RPC or SOAP.=A0 What am I missing that make=
s it a natural fit here?</DIV><DIV><BR class=3D"khtml-block-placeholder">=
</DIV><DIV>-andy</DIV></BODY></HTML>
--=_zeke.ecotroph.net-4101-1170788414-0001-2--

--===============0222428561==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0222428561==--

Content-class: urn:content-classes:message
Date: Tue, 6 Feb 2007 11:34:56 -0500
From: "Chauhan, Sanjeev" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] RE: PEPPERMINT Digest, Vol 2, Issue 6

>=20
> Today's Topics:
>=20
>    1. RE:  Question about charter (Hollenbeck, Scott)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Mon, 5 Feb 2007 13:51:57 -0500
> From: "Hollenbeck, Scott" <[email-masked]>
> Subject: RE: [PEPPERMINT] Question about charter
> To: "Romascanu, Dan \(Dan\)" <[email-masked]>,	"Cullen=20
> Jennings"
> 	<[email-masked]>, <[email-masked]>
> Cc: Jon Peterson <[email-masked]>
> Message-ID:
> =09
> <[email-masked]
d.vrsn.com>
> =09
> Content-Type: text/plain;	charset=3D"us-ascii"
>=20
> > -----Original Message-----
> > 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
> > Subject: RE: [PEPPERMINT] Question about charter
>=20
> > Such an approach would mean that for each problem that we=20
> identified=20
> > in the IETF we would start two working groups. One would be=20
> focused on=20
> > solving the problem itself, and the second on provisioning the=20
> > entities related to the solution of the problem. But what=20
> about alarms=20
> > and notifications related to the respective problem space? And what=20
> > about performance monitoring? A third and a fourth WG?
>=20
> The appropriate splits don't necessarily fit a formula. =20
> That's why we have discussions like this.
>=20
> I don't see a problem with creating new working groups if=20
> they are properly focused on a specific, manageable problem=20
> and they have a well defined timetable for either solving the=20
> problem or going home.  I will agree, though, that we haven't=20
> done that very well.  On the other hand, we have experience=20
> with working groups that have lived far beyond their expected=20
> lifespan as they've refocused, rechartered, and sometimes=20
> floundered because no one wanted to put them out of their misery.
> That's not necessarily a good thing.
>=20
> -Scott-
>=20
>=20

imho - provisioning and session routing (or resolution in dns terms) are
major interfaces to the system and need to defined. the two interfaces
though related have different requirements and are addressing different
needs and audiences. imo separate WG will be allow individual teams to
focus on the task at hand.=20

on a related note - while i agree database synchronization is an
interesting challenge, i don't think this problem is related to the
provisioning issue - defining the provisioning interface imho is a
higher priority for this group.=20
-sanjeev

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Question about charter
Date: Mon, 5 Feb 2007 13:51:57 -0500
From: "Hollenbeck, Scott" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Cullen Jennings" <[email-masked]>, <[email-masked]>
Cc: Jon Peterson <[email-masked]>

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]=20
> Sent: Monday, February 05, 2007 1:04 PM
> To: Hollenbeck, Scott; Cullen Jennings; [email-masked]
> Cc: Jon Peterson
> Subject: RE: [PEPPERMINT] Question about charter

> Such an approach would mean that for each problem that we=20
> identified in
> the IETF we would start two working groups. One would be focused on
> solving the problem itself, and the second on provisioning=20
> 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?=20

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-

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

From: "Richard Shockey" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Hollenbeck, Scott'" <[email-masked]>, "'Cullen Jennings'" <[email-masked]>, <[email-masked]>
Subject: RE: [PEPPERMINT] Question about charter
Date: Mon, 5 Feb 2007 13:26:03 -0500
Cc: 'Jon Peterson' <[email-masked]>
Reply-To: [email-masked]

> >
> > 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-
> >
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/peppermint
> 
> 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.

> 
> 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
> 
> >
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

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

content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Question about charter
Date: Mon, 5 Feb 2007 20:03:59 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "Cullen Jennings" <[email-masked]>, <[email-masked]>
Cc: Jon Peterson <[email-masked]>

=20
=20

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]=20
> Sent: Monday, February 05, 2007 7:55 PM
> To: Cullen Jennings; [email-masked]
> Cc: Jon Peterson
> Subject: RE: [PEPPERMINT] Question about charter
>=20
> > -----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
> >=20
> >=20
> > I have received some input about Peppermint but I have not received=20
> > much about the overlap with speermint. If you think we need=20
> to form a=20
> > WG to do this work, please let me know why and particularly why you=20
> > think that speermint is not the right place to do at least the=20
> > requirements phase of this work. We are really short on=20
> time so please=20
> > let me know in the next 5 days (by end of 7th).
> >=20
> > Keep in mind that the RAI agenda is very full and to run a BOF, it=20
> > will steel time from another WG.
>=20
> Cullen,
>=20
> My observation: the problem that PEPPERMINT is trying to=20
> address is a different problem than the one SPEERMINT is=20
> chartered to work on.
> PEPPERMINT is focused on a provisioning problem, not=20
> "real-time session routing architectures and their associated=20
> use cases" (quote taken from the SPEERMINT charter).  If the=20
> provreg working group were still around I could see this=20
> topic being more closely aligned with the expertise found in=20
> that working group.
>=20
> Getting to the point: I would strongly support the idea of=20
> scheduling this BOF if at all possible, even if it means=20
> thinking about doing it in the applications area.  I don't=20
> know what Lisa and Ted think about that idea.  It might be=20
> worth talking to them if it hasn't come up already.
>=20
> -Scott-
>=20
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

I would respectfully disagree.=20

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?=20

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.=20

Dan

>=20

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Question about charter
Date: Mon, 5 Feb 2007 12:55:29 -0500
From: "Hollenbeck, Scott" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>, <[email-masked]>
Cc: Jon Peterson <[email-masked]>

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]=20
> Sent: Saturday, February 03, 2007 1:36 PM
> To: [email-masked]
> Cc: Jon Peterson
> Subject: [PEPPERMINT] Question about charter
>=20
>=20
> I have received some input about Peppermint but I have not received =20
> much about the overlap with speermint. If you think we need=20
> to form a =20
> WG to do this work, please let me know why and particularly why you =20
> think that speermint is not the right place to do at least the =20
> requirements phase of this work. We are really short on time so =20
> please let me know in the next 5 days (by end of 7th).
>=20
> Keep in mind that the RAI agenda is very full and to run a BOF, it =20
> will steel time from another WG.

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-

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

From: Cullen Jennings <[email-masked]>
Date: Sat, 3 Feb 2007 10:36:06 -0800
To: [email-masked]
Cc: Jon Peterson <[email-masked]>
Subject: [PEPPERMINT] Question about charter

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: Cullen Jennings <[email-masked]>
Date: Fri, 2 Feb 2007 18:16:39 -0800
To: [email-masked]
Cc: 
Subject: [PEPPERMINT] Peppermint

I spent a long time with Andrew on the phone today and provide him  
with more details.

Jon still needs to make a decision about this BOF and conversations  
are still on going. I expect to have an answer in 5-10 days. If I had  
to guess, I would say things are sliding towards a decline.

Cullen

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