Subject: FW: [PEPPERMINT] new BoF proposal

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 29 Jan 2007 14:52:55 +0200

Please see the following BOF proposal. 

Should we tell them to have a look at NETCONF? 

Dan

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Sunday, January 28, 2007 8:36 PM
To: [email-masked]
Subject: [PEPPERMINT] new BoF proposal

All,

A tightened up version of the PEPPERMINT BoF proposal has been
formulated.  The major changes since the last version are: 1) some
language has been changed or eliminated that was construed to give
PEPPERMINT a larger scope than intended, and 2) the input documents are
listed.

The text is below.  Comments, questions, and suggestions welcomed.

-andy

Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
INTerconnection.

Mailing Lists:

BOF chairs:

Andrew Newton [[email-masked]]

Richard Shockey [[email-masked]]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

BOF Purpose.

The ENUM and SPEERMINT working groups are working on various aspects of
Multi Media Interconnection. 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
domain boundaries.

It is clear from discussions in both working groups that Multi-Media
Interconnection will require address of record data to be provisioned
among administrative domains outside the normal scope of establishing a
SIP session.

The purpose of the BOF is to determine the need and scope for such data
exchanges, what existing protocols need to be adapted to meet those
needs and the appropriate schema and queries are needed to facilitate
such exchanges.

The IETF has in the past done significant work on data exchanges among
various administrative entities. In particular the PROVREG working group
developed various schema and query mechanisms to facilitate the exchange
of data among domain name registries and registrars.

The ENUM Working group has adapted PROVREG working group protocols to
develop RFC 4114, which facilitates the provisioning of ENUM data in the
DNS tree.  However, there has been little adoption of RFC 4114, and many
in the operator community require both data models and protocol features
not found in RFC 4114.

The proposed PEPPERMINT working group will build upon the knowledge
gained from those efforts, and the intent of this proposed working group
is to find a provisioning solution for peering as defined by SPEERMINT.
The final work
product(s) from this working group will be based upon XML.   
Additionally,
bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or
HTTP/SOAP.

Proposed Deliverables:

1) Requirements for SPEERMINT data exchange.
2) Provisioning of SPEERMINT data registries.
3) Provisioning of SPEERMINT/ENUM data caches.

Input Documents:

1) PEPPERMINT Problem Statement
draft-newton-peppermint-problem-statement-00.txt

2) E.164 Number Provisioning Requirements - Data Set Requirements
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

3) ENUM Registry Interface Requirements
draft-lewis-peppermint-enum-reg-if-00.txt

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Jan 2007 15:13:54 +0100

Hi Dan,

I don't understand enough about the requirements for PEPPERMINT to say 
whether NETCONF is appropriate.  For high volume provisioning perhaps 
there are better alternatives (for instance, radius and diameter come to 
mind).  Then again, for low volume device configuration, we'd be right 
in NETCONF's ballpark.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jan 2007 10:05:19 -0800

> mind).  Then again, for low volume device configuration, we'd be right 

I sort of disagree.
The volume of changes (i.e., performance issues) can be addressed
in the implementation.

I don't know enough about PEPPERMINT either, but IMO NETCONF
could be used very effectively for provisioning, with some
specialized RPC methods (for performance and ease of use)
and a multi-user locking mechanism.

The protocol already supports arbitrary new RPC methods,
but the 'partial lock' feature is still TBD of course.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Jan 2007 13:45:45 -0500

You should only point them at NETCONF if we are prepared to help them 
define a data model that actually works with NETCONF, instead of the 
working groups perpetual arguments about what a data model might look 
like, or why we won't define a data model, or ...
A way of encapsulating CLI (which is all that NETCONF has so far 
managed to provide) does not solve the problem at all.

Yours,
Joel M. Halpern

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jan 2007 11:50:05 -0800

Joel M. Halpern wrote:
> A way of encapsulating CLI (which is all that NETCONF has so far managed 
> to provide) does not solve the problem at all.

I'm not writing off NETCONF a month after the RFCs are published.
I expect early NE implementations to be "wide and shallow" mappings
from proprietary CLI to proprietary encapsulated CLI.  More interesting
implementations will follow later.

IMO, the real issue is whether any WG in question can agree on
the information model and operational model for a particular feature.
If you can get that far, then many different protocols and encodings
will work.  We have very few standards for configuration because
vendors have not agreed on very many common 'knobs', let alone common
operational procedures.

The overhead of sessions, configuration databases, and other NETCONF-centric
details may be reason enough to create something new, but even NE provisioning
apps today have to integrate with CLI-based configuration management.
The non-volatile config file on the device usually needs to be updated,
regardless of the API.  NETCONF is designed to work with this type of device.

Andy

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 29 Jan 2007 21:59:01 +0200

Andy,

NETCONF was designed to solve real-life problems. Here is a real-life
problem. Are we ready to go and say 'look at NETCONF'  as to a possible
solution? Are you or somebody willing to go to the peppermint BOF
(assuming it is approved) and explain this? 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Monday, January 29, 2007 9:50 PM
> To: Joel M. Halpern
> Cc: Netconf (E-mail)
> Subject: Re: FW: [PEPPERMINT] new BoF proposal
> 
> Joel M. Halpern wrote:
> I expect early NE implementations to be "wide and shallow" 
> mappings from proprietary CLI to proprietary encapsulated 
> CLI.  More interesting implementations will follow later.
> 
> IMO, the real issue is whether any WG in question can agree 
> on the information model and operational model for a 
> particular feature.
> If you can get that far, then many different protocols and 
> encodings will work.  We have very few standards for 
> configuration because vendors have not agreed on very many 
> common 'knobs', let alone common operational procedures.
> 
> The overhead of sessions, configuration databases, and other 
> NETCONF-centric details may be reason enough to create 
> something new, but even NE provisioning apps today have to 
> integrate with CLI-based configuration management.
> The non-volatile config file on the device usually needs to 
> be updated, regardless of the API.  NETCONF is designed to 
> work with this type of device.
> 
> > 
> > Yours,
> > Joel M. Halpern
> 
> Andy
> 
> --
> to unsubscribe send a message to [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jan 2007 13:13:48 -0800

> (assuming it is approved) and explain this? 

I will go to the BOF and try to read and understand the drafts.
If I think NETCONF applies, I'll suggest it.

Andy

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 30 Jan 2007 08:17:48 +0200

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 11:14 PM
> To: Romascanu, Dan (Dan)
> Cc: Joel M. Halpern; Netconf (E-mail)
> > problem. Are we ready to go and say 'look at NETCONF'  as to a 
> > possible solution? Are you or somebody willing to go to the 
> peppermint 
> > BOF (assuming it is approved) and explain this?
> 

Sounds good. I will send them a comment in the meantime asking for
NETCONF to be included in the list of technologies to look at, so that
maybe some will look at it from their perspective, or at least it does
not sound totally unknown to everybody there. 

Dan