Subject: RE: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF
From: "Hollenbeck, Scott" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, <[email-masked]>
Cc: Alexander Mayrhofer <[email-masked]>
Date: Tue, 11 Dec 2007 15:25:43 -0500
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

One correction on the five EPP RFCs I described (excluding 4114):
they're not "progressing towards draft standards", they *are* draft
standards.

-Scott-

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 3:23 PM
> To: [email-masked]
> Cc: 'Alexander Mayrhofer'
> Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF
> 
> 
> Alexander graciously took some notes and I've added some 
> recollections .. if there are any additional comments or 
> notes to be included let me know.
> 
> ##############
> 
> 
> IETF 70 PEPPERMINT BOF Minutes
> 
> Thursday December 6, 2007
> 
> Chair(s):
> 
> Richard Shockey <[email-masked]> Tom Creighton  
> <[email-masked]>
> 
> 
> RAI Director(s):
> 
> Jon Peterson [email-masked]
> Cullen Jennings [email-masked]
> 
> Chair estimates appx 200 in attendence
> 
> Shockey Chair: Reminder - this is BoF, not a WG
> 
> The purpose of the BOF is to discuss the problem, not define 
> the solution.
> The purpose of this hour to see whether there is a problem, 
> and if yes, whether we want to address that in the IETF
> 
> How many people read the proposed charter? (about half of 
> them in the room)
> 
> Reminder that some of the issues here were part of RFC 4114 
> in the ENUM working group for provisioning.
> 
> 
> PRESENTATIONS:
> 
> David Schwartz - Peering relationships
> 
> 
> Filename	: draft-schwartz-speermint-provisioning-problem-00.txt 
> 
> Bilateral interconnection models evolving into federation scenarios. 
> 
> 3 kinds of interfaces identified on the provisioning side. 
> Currently everybody currently rolls his own.
> 
> 1) provisioning the registry
> 2) provisioning "down" to local registry (like currently ftp)
> 3) registry to registry
> 
> Why do we need PEPPERMINT?
> 
> Operators want to use more than one registry. 
> 
> Richard: that's not carrier only, right? This could be used 
> for various network elements like PBX's?
> 
> David: No, any network element could do that.
> 
> Provisioning data like national LNPs, non-LNPs, etc.
> 
> Changed from "among admin domains" to "within admin domains" 
> in richard's statement.
> 
> list of various currently used provisioning protocols.
> 
> Rohan Mahy : you forgot FAX!
> 
> 
> Henry Sinnreich: single or many registries?
> David: I don't see a single registry. There will be will be 
> many. We have the sequential nightmare today of provisioning 
> several registries
> 
> PRESENTATIONS:
> 
> Ed Lewis
> 
> Jon Peterson noted that Ed Lewis was the chair of the WG that 
> developed EPP.
> 
> Draft 
> 
> Filename	: draft-lewis-peppermint-enum-reg-if-01.txt
> 
> 
> This document was created as a placeholder for a more formal 
> requirements draft, built from IETF as well as NeuStar 
> internal experience.
> 
> Note section about EPP: obvious alternative, decided against it.
> 
> 
> PRESENTATIONS:
> 
> Scott Hollenbeck
> ================
> 
> Provisioning protocol and tech overview
> 
> EPP documents progressing towards draft standards. 
> 
> EPP developed for the unique needs of the Domain Name Registries
> 
> IMHO 4114 not really usable for the PEPPERMINT problem 
> statement (ENUM extensions for that as well)
> 
> It is fair to look at other options. There are couple of them 
> in the IETF
> context:
> 
> other things: CAPWAP (4565)
> COPS / COPS-PR
> 
> Obviously not what we need
> 
> Provisioning technologies?
> 
> SOAP over HTTP
>  (eg SOAP over BEEP)
> 
> REST (over HTTP)
> 
>  Jonathan Rosenberg : xcap is REST style
> 
> XML-RPC
>  (XML-RPC in BEEP)
> 
> religious debates will drag you down forever
> 
> Korean experiences with 4114
> ============================
> 
> Richard Shockey proxying for Joonhyung Lim 
> 
> .kr infrastructure ENUM trial (+82) using 4114
> 
> outcome: carriers have their own system.
> 
> LawrenceConroy : please not that they did a lot of work on 
> this, don't be unfair :) they provided a lot of toolkits for carriers.
> 
> Richard Shockey: were they looking into a new provisioning 
> protocol for the second trial?
> 
> 
> Lawrence Conroy : yes, this doesn't seem to fit how carriers think.
> 
> Alexander : carriers don't move a single inch. Mobile NP in 
> Austria took 5 years to agree on a Fax style process
> 
> Ted hardie: jabber: andy agrees with alex
> 
> Richard Shockey : andy did an awful lot of work to make this 
> BoF happen
> 
> David: world is changing, they are moving to IP. There are a 
> lot of RFPs out there from carriers
> 
> Alexander: difference "between" and "among" is a scope question
> 
> Richard: please come to the microphone to say whether there 
> is or not a problem
> 
> James: is this defining what data we use, or only on a 
> mechanism we agree on?
> 
> Richard Shockey : 1) what is the bits that move on the wire 
> 2) what data sets. this is a scope question.
> 
> Hadriel Kaplan: between/within very distinct problems. 
> Personally, wants to be "within".
> 
> Richard Shockey: Do the two problems need to be addressed 
> separately? both to be solved?
> 
> Hadriel Kaplan: question whether solving on the short term or 
> not? And title to be changed, too
> 
> David: it's like SNMP - data model. there's a lot more we can do. 
> 
> Tim Dwight: We (Verizon) think there is a problem, yes. 
> 
> Cullen Jennings (individual): there's always a problem about 
> everything.
> Need to narrow scope.
> 
> Dan York: I think that this is important work
> 
> Tim: we'd like to join only a subset of registries, and still 
> resolve all numbers. 
> 
> Tom Creighton: Would you like to speak just one prov. protocol there?
> 
> Tim Dwight: if it's a small set, we're ok with different protocols
> 
> ??: would love to have a standard registry interface
> 
> Jim: query too?
> 
> Richard: downstream provisioning too. there are 2 registries 
> in the US for routing, for example, NPAC and LERG and those 
> are merged into a single view.
> Multiple registries are a given.
> 
> Jason Livingood : agree, there is no query problem. if 
> u/i-ENUM would exist, there would be one place. there is not 
> in real world. provisioning group within a carrier is the 
> hardest to work with.
> 
> Jean-Francois Mule: you assume ENUM, which needs phone 
> numbers for the query interface? What about a mechanism for 
> non-E.164 data? 2) there are other relations within where 
> data exchange needs to happen. 3) bilateral transacitons?
> 
> Richard Shockey: We certainly don't want to exclude bilateral 
> data exchanges
> 
> 
> Tim Dwight: trust & authenticity information? Policy possible 
> with most registries today, too. realizes that policy might 
> extend the scope, but might useful..
> 
> Jon Peterson : Ive eard a couple of people talking they want 
> it? does anybody understand it?
> 
> ( A number of heads start to nod in agreement ) 
> 
> Jon Peterson: Who thinks this is a problem? Who thinks we 
> should work on this? who is willing to personally contribute to this?
> 
> Richard Shockey: A show of hands .. who thinks this is a 
> problem the IETF needs to address? (maybe 1/3 of the 
> attendees raise their hand)
> 
> Richard Shockey: Who thinks that the IETF should NOT work on 
> this problem? ( two hands go up)
> 
> Richard Shockey: How many people would be willing to 
> personally contribute to this process?  ( approximately 30 ?)
> 
> Kenneth: Its not a question of ditching or not ditching the 
> provisioning system, but rather improving it...
> 
> Jon Peterson : Charter should be crisp and clear.
> 
> 
> 
> 
> _______________________________________________
> 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: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 11 Dec 2007 15:23:17 -0500
Cc: 'Alexander Mayrhofer' <[email-masked]>
Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF

Alexander graciously took some notes and I've added some recollections .. if
there are any additional comments or notes to be included let me know.

##############

IETF 70 PEPPERMINT BOF Minutes

Thursday December 6, 2007

Chair(s):

Richard Shockey <[email-masked]>
Tom Creighton  <[email-masked]>

RAI Director(s):

Jon Peterson [email-masked]
Cullen Jennings [email-masked]

Chair estimates appx 200 in attendence

Shockey Chair: Reminder - this is BoF, not a WG

The purpose of the BOF is to discuss the problem, not define the solution.
The purpose of this hour to see whether there is a problem, and if yes,
whether we want to address that in the IETF

How many people read the proposed charter? (about half of them in the room)

Reminder that some of the issues here were part of RFC 4114 in the ENUM
working group for provisioning.

PRESENTATIONS:

David Schwartz - Peering relationships

Filename	: draft-schwartz-speermint-provisioning-problem-00.txt 

Bilateral interconnection models evolving into federation scenarios. 

3 kinds of interfaces identified on the provisioning side. Currently
everybody currently rolls his own.

1) provisioning the registry
2) provisioning "down" to local registry (like currently ftp)
3) registry to registry

Why do we need PEPPERMINT?

Operators want to use more than one registry. 

Richard: that's not carrier only, right? This could be used for various
network elements like PBX's?

David: No, any network element could do that.

Provisioning data like national LNPs, non-LNPs, etc.

Changed from "among admin domains" to "within admin domains" in richard's
statement.

list of various currently used provisioning protocols.

Rohan Mahy : you forgot FAX!

Henry Sinnreich: single or many registries?
David: I don't see a single registry. There will be will be many. We have
the sequential nightmare today of provisioning several registries

PRESENTATIONS:

Ed Lewis

Jon Peterson noted that Ed Lewis was the chair of the WG that developed EPP.

Draft 

Filename	: draft-lewis-peppermint-enum-reg-if-01.txt

This document was created as a placeholder for a more formal requirements
draft, built from IETF as well as NeuStar internal experience.

Note section about EPP: obvious alternative, decided against it.

PRESENTATIONS:

Scott Hollenbeck
========

Provisioning protocol and tech overview

EPP documents progressing towards draft standards. 

EPP developed for the unique needs of the Domain Name Registries

IMHO 4114 not really usable for the PEPPERMINT problem statement (ENUM
extensions for that as well)

It is fair to look at other options. There are couple of them in the IETF
context:

other things: CAPWAP (4565)
COPS / COPS-PR

Obviously not what we need

Provisioning technologies?

SOAP over HTTP
 (eg SOAP over BEEP)

REST (over HTTP)

 Jonathan Rosenberg : xcap is REST style

XML-RPC
 (XML-RPC in BEEP)

religious debates will drag you down forever

Korean experiences with 4114
==============

Richard Shockey proxying for Joonhyung Lim 

.kr infrastructure ENUM trial (+82) using 4114

outcome: carriers have their own system.

LawrenceConroy : please not that they did a lot of work on this, don't be
unfair :) they provided a lot of toolkits for carriers.

Richard Shockey: were they looking into a new provisioning protocol for the
second trial?

Lawrence Conroy : yes, this doesn't seem to fit how carriers think.

Alexander : carriers don't move a single inch. Mobile NP in Austria took 5
years to agree on a Fax style process

Ted hardie: jabber: andy agrees with alex

Richard Shockey : andy did an awful lot of work to make this BoF happen

David: world is changing, they are moving to IP. There are a lot of RFPs out
there from carriers

Alexander: difference "between" and "among" is a scope question

Richard: please come to the microphone to say whether there is or not a
problem

James: is this defining what data we use, or only on a mechanism we agree
on?

Richard Shockey : 1) what is the bits that move on the wire 2) what data
sets. this is a scope question.

Hadriel Kaplan: between/within very distinct problems. Personally, wants to
be "within".

Richard Shockey: Do the two problems need to be addressed separately? both
to be solved?

Hadriel Kaplan: question whether solving on the short term or not? And title
to be changed, too

David: it's like SNMP - data model. there's a lot more we can do. 

Tim Dwight: We (Verizon) think there is a problem, yes. 

Cullen Jennings (individual): there's always a problem about everything.
Need to narrow scope.

Dan York: I think that this is important work

Tim: we'd like to join only a subset of registries, and still resolve all
numbers. 

Tom Creighton: Would you like to speak just one prov. protocol there?

Tim Dwight: if it's a small set, we're ok with different protocols

??: would love to have a standard registry interface

Jim: query too?

Richard: downstream provisioning too. there are 2 registries in the US for
routing, for example, NPAC and LERG and those are merged into a single view.
Multiple registries are a given.

Jason Livingood : agree, there is no query problem. if u/i-ENUM would exist,
there would be one place. there is not in real world. provisioning group
within a carrier is the hardest to work with.

Jean-Francois Mule: you assume ENUM, which needs phone numbers for the query
interface? What about a mechanism for non-E.164 data? 2) there are other
relations within where data exchange needs
to happen. 3) bilateral transacitons?

Richard Shockey: We certainly don't want to exclude bilateral data exchanges

Tim Dwight: trust & authenticity information? Policy possible with most
registries today, too. realizes that policy might extend the scope, but
might useful..

Jon Peterson : Ive eard a couple of people talking they want it? does
anybody understand it?

( A number of heads start to nod in agreement ) 

Jon Peterson: Who thinks this is a problem? Who thinks we should work on
this? who is willing to personally contribute to this?

Richard Shockey: A show of hands .. who thinks this is a problem the IETF
needs to address? (maybe 1/3 of the attendees raise their hand)

Richard Shockey: Who thinks that the IETF should NOT work on this problem? (
two hands go up)

Richard Shockey: How many people would be willing to personally contribute
to this process?  ( approximately 30 ?)

Kenneth: Its not a question of ditching or not ditching the provisioning
system, but rather improving it...

Jon Peterson : Charter should be crisp and clear.

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] Few thoughts for tomorrow.
Date: Thu, 6 Dec 2007 16:05:30 -0500
To: <[email-masked]>
Cc: 

My typo:

This...
b. Problem Statement that defines the overall problems that SPEERMINT
must solve
Should have read like this...
b. Problem Statement that defines the overall problems that PAPPERMINT
must solve

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 1:06 PM
To: Cartwright, Kenneth; [email-masked]
Subject: RE: [PEPPERMINT] Few thoughts for tomorrow.

Thanks for your note. Its precisely this kind of support we need.

>  -----Original Message-----
>  From: Cartwright, Kenneth [mailto:[email-masked]]
>  Sent: Thursday, December 06, 2007 3:36 AM
>  To: [email-masked]
>  Subject: [PEPPERMINT] Few thoughts for tomorrow.
>  
>  Tom, Richard, et.al.
>  
>  Not surprisingly, since this is in early stages, the four good docs
>  that
>  exist so far (two problem statements, Newton and Schwartz, the
>  requirements doc, Lewis, and the data set doc Schwartz) are good and
>  valuable but are also disjoint in their perspectives, terminology,
and
>  the presumed underlying architecture.  A suggestion to help rectify
>  this
>  is to follow the approach applied by the SPEERMINT group, which
seemed
>  very effective to me.  That would be the following:
>  
>  1) Create a block diagram like the one in SPEERMINT that illustrated
>  the
>  initial document set that will be produced (one doc per block), the
>  dependency flow from the first doc(s) on down.  This creates a clear
>  picture for everyone on the documents that will be produced in what
>  order and for what reason.
>  2) Imho the docs that we need are:
>      a. Architecture Document, that creates a clear picture and
>  responsibilities of the logical components within the provisioning
>  flow.
>  This probably should include the Registry(s), the Addressing Server
>  Master(s), and, optionally, the Addressing Server Slaves/Replicas.
>  This
>  document will also create a common terminology set for the logical
>  aspects of the architecture that can then be used in the problem
>  statement and the requirements doc(s).
>      b. Problem Statement that defines the overall problems that
>  SPEERMINT must solve relative to the logical components identified in
>  the Architecture Document, without delving into specific data items
or
>  solution schemes.  The Newton document was a good start at this,
imho,
>  as it clearly laid out the high level problem statement to define an
>  API/protocol between the VSP and the Registry, and between the
>  Registry
>  and the addressing servers.  The Schwatz document is also good,  Id
>  does
>  however seem to mash the logical entity of the Registry and the ENUM
>  Addressing Server in together (assuming I interpreted the document
>  correctly).  The Schwartz document moves past the higher level
Problem
>  Statement and directly into Data Model items that, imho, are more
>  appropriate for a requirements document.  But it is certainly a good
>  document as well.
>      c. Requirements Document that defines the data elements/objects
>  that
>  must provisionable (is that a word) via the interfaces identified in
>  the
>  Problem Statement, the operations that must be supported for this
data
>  elements/objects, the performance and scalability requirements,
>  security
>  requirements, etc.  But it is also important that this document not
>  attempt to specify the solution.  I see in the current requirements
>  document that there is a lot of "solution" (e.g. use zone files, or
>  use
>  SOAP) in there but not enough requirements details.  But it is a good
>  start.
>      d. Also, in one of these documents we need to make sure all the
>  terminology is defined and kept consistent, but we may not need a
>  separate doc for that.
>  3) Lastly, in the BOF notification you asked if some can volunteer to
>  work on these documents.  I'm volunteering to do so.  I can be a
>  reviewer of all of these documents and also co-author them as
>  necessary.
>  
>  Ken
>  
>  _______________________________________________
>  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: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 6 Dec 2007 13:12:39 -0500
Cc: 
Subject: [PEPPERMINT] PEPPERMINT MEETING MATERIALS for this afternoon

https://datatracker.ietf.org/meeting/70/materials.html

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
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

From: "Richard Shockey" <[email-masked]>
To: "'Cartwright, Kenneth'" <[email-masked]>, <[email-masked]>
Subject: RE: [PEPPERMINT] Few thoughts for tomorrow.
Date: Thu, 6 Dec 2007 13:06:17 -0500
Cc: 

Thanks for your note. Its precisely this kind of support we need.

>  -----Original Message-----
>  From: Cartwright, Kenneth [mailto:[email-masked]]
>  Sent: Thursday, December 06, 2007 3:36 AM
>  To: [email-masked]
>  Subject: [PEPPERMINT] Few thoughts for tomorrow.
>  
>  Tom, Richard, et.al.
>  
>  Not surprisingly, since this is in early stages, the four good docs
>  that
>  exist so far (two problem statements, Newton and Schwartz, the
>  requirements doc, Lewis, and the data set doc Schwartz) are good and
>  valuable but are also disjoint in their perspectives, terminology, and
>  the presumed underlying architecture.  A suggestion to help rectify
>  this
>  is to follow the approach applied by the SPEERMINT group, which seemed
>  very effective to me.  That would be the following:
>  
>  1) Create a block diagram like the one in SPEERMINT that illustrated
>  the
>  initial document set that will be produced (one doc per block), the
>  dependency flow from the first doc(s) on down.  This creates a clear
>  picture for everyone on the documents that will be produced in what
>  order and for what reason.
>  2) Imho the docs that we need are:
>      a. Architecture Document, that creates a clear picture and
>  responsibilities of the logical components within the provisioning
>  flow.
>  This probably should include the Registry(s), the Addressing Server
>  Master(s), and, optionally, the Addressing Server Slaves/Replicas.
>  This
>  document will also create a common terminology set for the logical
>  aspects of the architecture that can then be used in the problem
>  statement and the requirements doc(s).
>      b. Problem Statement that defines the overall problems that
>  SPEERMINT must solve relative to the logical components identified in
>  the Architecture Document, without delving into specific data items or
>  solution schemes.  The Newton document was a good start at this, imho,
>  as it clearly laid out the high level problem statement to define an
>  API/protocol between the VSP and the Registry, and between the
>  Registry
>  and the addressing servers.  The Schwatz document is also good,  Id
>  does
>  however seem to mash the logical entity of the Registry and the ENUM
>  Addressing Server in together (assuming I interpreted the document
>  correctly).  The Schwartz document moves past the higher level Problem
>  Statement and directly into Data Model items that, imho, are more
>  appropriate for a requirements document.  But it is certainly a good
>  document as well.
>      c. Requirements Document that defines the data elements/objects
>  that
>  must provisionable (is that a word) via the interfaces identified in
>  the
>  Problem Statement, the operations that must be supported for this data
>  elements/objects, the performance and scalability requirements,
>  security
>  requirements, etc.  But it is also important that this document not
>  attempt to specify the solution.  I see in the current requirements
>  document that there is a lot of "solution" (e.g. use zone files, or
>  use
>  SOAP) in there but not enough requirements details.  But it is a good
>  start.
>      d. Also, in one of these documents we need to make sure all the
>  terminology is defined and kept consistent, but we may not need a
>  separate doc for that.
>  3) Lastly, in the BOF notification you asked if some can volunteer to
>  work on these documents.  I'm volunteering to do so.  I can be a
>  reviewer of all of these documents and also co-author them as
>  necessary.
>  
>  Ken
>  
>  _______________________________________________
>  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: [PEPPERMINT] Few thoughts for tomorrow.
Date: Thu, 6 Dec 2007 03:36:20 -0500
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Cc: 

Tom, Richard, et.al.

Not surprisingly, since this is in early stages, the four good docs that
exist so far (two problem statements, Newton and Schwartz, the
requirements doc, Lewis, and the data set doc Schwartz) are good and
valuable but are also disjoint in their perspectives, terminology, and
the presumed underlying architecture.  A suggestion to help rectify this
is to follow the approach applied by the SPEERMINT group, which seemed
very effective to me.  That would be the following:

1) Create a block diagram like the one in SPEERMINT that illustrated the
initial document set that will be produced (one doc per block), the
dependency flow from the first doc(s) on down.  This creates a clear
picture for everyone on the documents that will be produced in what
order and for what reason.
2) Imho the docs that we need are:
    a. Architecture Document, that creates a clear picture and
responsibilities of the logical components within the provisioning flow.
This probably should include the Registry(s), the Addressing Server
Master(s), and, optionally, the Addressing Server Slaves/Replicas.  This
document will also create a common terminology set for the logical
aspects of the architecture that can then be used in the problem
statement and the requirements doc(s).
    b. Problem Statement that defines the overall problems that
SPEERMINT must solve relative to the logical components identified in
the Architecture Document, without delving into specific data items or
solution schemes.  The Newton document was a good start at this, imho,
as it clearly laid out the high level problem statement to define an
API/protocol between the VSP and the Registry, and between the Registry
and the addressing servers.  The Schwatz document is also good,  Id does
however seem to mash the logical entity of the Registry and the ENUM
Addressing Server in together (assuming I interpreted the document
correctly).  The Schwartz document moves past the higher level Problem
Statement and directly into Data Model items that, imho, are more
appropriate for a requirements document.  But it is certainly a good
document as well.
    c. Requirements Document that defines the data elements/objects that
must provisionable (is that a word) via the interfaces identified in the
Problem Statement, the operations that must be supported for this data
elements/objects, the performance and scalability requirements, security
requirements, etc.  But it is also important that this document not
attempt to specify the solution.  I see in the current requirements
document that there is a lot of "solution" (e.g. use zone files, or use
SOAP) in there but not enough requirements details.  But it is a good
start.
    d. Also, in one of these documents we need to make sure all the
terminology is defined and kept consistent, but we may not need a
separate doc for that.
3) Lastly, in the BOF notification you asked if some can volunteer to
work on these documents.  I'm volunteering to do so.  I can be a
reviewer of all of these documents and also co-author them as necessary.

Ken

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Wed, 5 Dec 2007 16:24:46 -0500
Subject: [PEPPERMINT] If you have slides for the BOF tommrrow please send them to me ASAP.

So I can get them posted on the IETF web site etc.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
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