Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt
From: David Schwartz <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Thu, 31 Jul 2008 03:51:29 +0100
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

Hi Penn - sorry for VERY late response on this :(

inline...

On Jul 7, 2008, at 8:04 PM, PFAUTZ, PENN L, ATTCORP wrote:

> Some initial comments re this draft:
> 1. Section 3.1 Index/Key Data states that "for lookup information  
> about
> the most specific prefix will be returned." While this might be
> desirable in some cases, I could image others where a larger set of
> records might be desired. It also seems out of scope for DRINKS  
> since it
> speaks to retrieval rather than provisioning.

DS: Technically you are right. This is simply introduced to extract  
necessary information that may need to be provided to accommodate this  
retrieval.
>
> 2. I'm troubled by the "first hop" "last hop" provider terminology in
> Section 3.2. The way it is used in this section seems to imply that
> there is some VSP closer to the end user than the VSP assigned the
> number prefix. This *might* be under some circumstances, e.g., where a
> non-facilities based provider obtains its numbers through wholesale,  
> but
> is not the most general case. If multiple VSP records are allowed then
> it would seem some means of identifying which is which is required.

DS: So now that I have thoroughly re-read all the drafts that are  
being presented tomorrow I am more convinced that this is correct.  
There is very little discussion about transit providers. The  
discussion that does exist (Debbie started going in the right  
direction on this, and the espp folks addressed this to some extent in  
a response to Otmar)  centers around a transit provider being able to  
"use the system as well" to provision his stuff. Problem is, in most  
cases, its not "as well" but "in addition" necessitating conflict  
resolution provisioning data (which I did not see anyone define). This  
differentiation between "next hop" and "last hop" is meant to  
highlight this distinction.
>
> 3. w/r/t number portability info (Section 3.2) carrier code is only  
> one
> type of NP info employed in the PSTN. Some more general terminology
> should be employed.

DS: Absolutely. In fact I am somewhat guilty as well of the common  
north american tilt on most of these documents. But your question only  
highlights in my mind the SCREAMING NEED for a terminology draft in  
DRINKS. Many of the things described in all documents are being  
referred to by proprietary names leading to mass confusion. Daryl -  
Please help !!!
>
> 4. Section 4 states that routing information is out of scope of the
> registry provisioning problem. I'm not sure I agree.
> In some arrangements routing information might well be expected to  
> come
> from a Registry and so need to be provisioned. I believe a number of
> existing private registries provide routing information today. The
> information *might* be relatively dynamic but it might not. Perhaps I
> misunderstand how the term "routing information" is intended here.

DS: Here too I agree with you and in fact, Hadriel has an interesting  
draft on this. This doc was unfortunately not updated sufficiently by  
me prior to this IETF due to severe lack of time to work on this. We  
should discuss tomorrow. Thanks for comments.
>
>
>
> Penn Pfautz
> AT&T National Access Management
> +1-732-420-4962
>
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 14 Jul 2008 13:19:01 -0400
Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-protocol-02.txt
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, July 14, 2008 12:45 PM
To: [email-masked]
Subject: I-D Action:draft-mule-peppermint-espp-protocol-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : A Provisioning Protocol for ENUM-SIP Addressing
Servers
	Author(s)       : K. Cartwright, et al.
	Filename        : draft-mule-peppermint-espp-protocol-02.txt
	Pages           : 121
	Date            : 2008-07-14

This document defines a provisioning protocol for ENUM-SIP addressing
servers.
An ENUM-SIP addressing server is a host that acts as Lookup Function in
session peering to determine the target domain of a given SIP request and it
may also act as a Location Routing Function to develop the location of the
SIP signaling entity in that target domain.
This protocol allows SIP service providers to provision and manage session
establishment data used by SIP network elements to route SIP sessions to the
target destinations which may be served by the SIP service provider's own
internal network or by a session peering partner.  The data provisioned into
an ENUM-SIP addressing server is queried by SIP entities using ENUM or SIP.

This version of the protocol integrates comments received on the IETF
peppermint and drinks mailing lists before July 2008.  This document is an
Internet-Draft and the protocol it describes is subject to technical changes
that may make this version incompatible with future versions defined in
Internet-Drafts.  It is expected that the authors will continue to update
this protocol based on the drinks working group requirements on the session
establishment data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-02.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 14 Jul 2008 13:04:16 -0400
Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-requirements-01.txt
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, July 14, 2008 12:15 PM
To: [email-masked]
Subject: I-D Action:draft-mule-peppermint-espp-requirements-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Provisioning Protocol Requirements for ENUM-SIP
Addressing Servers
	Author(s)       : T. Creighton, J. Mule
	Filename        : draft-mule-peppermint-espp-requirements-01.txt
	Pages           : 18
	Date            : 2008-07-14

This document presents use cases and protocol requirements for provisioning
ENUM-SIP addressing servers.  The provisioned data is used by the addressing
server to return session establishment data for SIP entities to route SIP
requests to the target destinations.
An ENUM-SIP addressing server acts as a Lookup Function in session peering
to determine the target domain of a given SIP request.  It may also act as a
Location Routing Function to develop the location of the SIP signaling
entity in the target domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements-
01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

Date: Thu, 10 Jul 2008 11:35:36 -0700
To: "Jean-Francois Mule" <[email-masked]>
From: Edward Lewis <[email-masked]>
Cc: [email-masked], [email-masked], Edward Lewis <[email-masked]>
Subject: Re: [PEPPERMINT] Comparison of Requirements Documents
Sender: [email-masked]

At 15:33 -0600 7/8/08, Jean-Francois Mule wrote:
>>  From: [email-masked] [mailto:peppermint-
>>  [email-masked]] On Behalf Of Edward Lewis
>>  Sent: Monday, June 30, 2008 1:08 PM

>>  topics that included in both and where the two requirements had
>>  different emphasis.  I don't think there is any outright
>>  contradiction between the two.
>
>I'm not sure what you meant by "different emphasis".

"Different emphasis" refers to what is documented.  For example, ESPP 
emphasizes file operations, the consolidated has a requirement that 
emphasizes individual transactions.  Different emphasis is not 
different direction, not a conflict, but is a reflection (also) of 
what was chosen to be placed in the document.

Neither requirement documents is all encompassing at this point, 
although the ESPP document is more mature and has an implementation 
to back it.

>The ESPP protocol requirements were modeled after the NETCONF ones (at
>least in terms of the document outline).

That's not in the references of the ESPP document.

>No.  It should be possible to use a file-based mechanism to provision a
>large amount of data for sunrise use cases.  If you look at ESPP
>closely, the concept of operations based on transactional records does
>exist.

Section 4.2 is "File", 4.1 is "Connection" but starts "The protocol MUST
support a file-based, bulk delivery mechanism".  Not to say ESPP does 
not do interactive - I don't see it in the requirements, at least not 
highlighted.

Recall that the context here is the requirement document, not the 
protocol (document).

>>  this,
>>  as well as a hard coded limit on the size limit.)
>
>Implementations prevail.  We came to the conclusion that to be testable,
>those requirements better be bound in terms of how big of a file sent
>via SCP a server must be able to accept and process.  It also gives an
>indication to sysadmins and operators for where they should not go in
>file sizes.  The idea is to split the files into multiples after a
>certain limit.
>I see nothing wrong with that, quite the contrary when you start to look
>at code.

My experience with hard limits is in the DNS protocol, as well as the 
address space in IPv6.  In DNS there was a 512 byte limit in UDP 
message segments with no nod towards expandability until EDNS0 came 
along.  The installed base of pre-EDNS0 code made the transition 
difficult.  With IPv6, one of the things that could have made 
coexistence with IPv4 possible was to allow the address field to be 
variable length, or at least special case in a short address of 32 
bits.  Generalizing from these cases, hard limits in specs trigger 
flags in me - even if there is merit in the limit as stated.

>>  ESPP describes designing an efficient protocol, i.e., being able to
>>  apply one set of data to many numbers.  (But when I boiled the
>>  requirements down, I didn't see this idea - maybe it was in the
>>  protocol.)
>
>Can you elaborate and quote text so we (authors of ESPP) can provide
>more context.

For example, the consolidated specs mention the "\1" shorthand.  (On 
the other hand, ESPP strives to not be tied to NAPTR as consolidated 
assumes.)  What is not in the ESPP requirements is any requirement 
that syntax of the updates accommodate rules/profiles/macros, call 
them what you will.  Again, let me stress - I'm not saying ESPP lacks 
this, it's just not something I saw in the document.

>ESPP goes into details about how each object in the DB is identified
>with eID and oIDs, something Kent went over in a thread with Bob Walter
>some time ago.

The reason I cited the documents I commented on was to say "this is 
what I am talking about."  I hope that the result of 'the thread you 
cite' makes it's way into the next document cycle.

>>  Consolidated explicitly mentions numbers being reassigned and the
>>  impact of that on database entries and responses.
>
>What is the requirement on the protocol here (as opposed to the
>operational aspects of number reassignments)?

For example, the dip requirements (and:
>>  Consolidated requires dip indications, temporal validity, number
>>  "ownership" and other ancillary data.
)

>>  It's obvious that the two teams that developed the documents had
>>  different emphasis on what to include in a list or requirements.
>
>Based on the above, this is not obvious to me.

E.g., you mention that ESPP does interactive operations, not just 
file based, and that file based is for sunrise.  This wasn't made 
apparent in the requirement document.  In the Consolidated document, 
we did include more about interactive operations.

That doesn't mean one (emphasis) is better than the other.  It's just 
a measure of what is chosen to be put into words.

>>  Even with the ESPP requirements document being rather mature (as
>>  well as being accompanied by a protocol specification), there is a need
>>  to combine the two documents.
>
>That I agree with.

All's well that ends well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

From: Ted Lemon <[email-masked]>
To: Jean-Francois Mule <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 8 Jul 2008 14:18:09 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] Data model for "reachability data"	and	naming/terminology for group of addresses
Sender: [email-masked]

> I believe so.  Would folks prefer Destination Group then?

As a relative neophyte, it's more obvious to me what "Destination Group" means than what "Service Area" means.   So I think it's somewhat preferable, although there's nothing fundamentally wrong with "Service Area."   I think it's because "Destination Group" implies logical locality, whereas "Service Area" implies physical locality.

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

Content-class: urn:content-classes:message
Date: Wed, 9 Jul 2008 11:27:32 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 13, Issue 8
Sender: [email-masked]

Fwiw, I like the term "Destination Group" as one to supplant what ESPP
had labeled as a "Service Area".  And the way that "Destination Group"
is described by Ray tracks with the way that, I believe, ESPP defines
and uses "Service Areas".

Ken 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, July 08, 2008 5:14 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 13, Issue 8

Send PEPPERMINT mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/peppermint
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of PEPPERMINT digest..."

Today's Topics:

   1. Re:  Data model for "reachability data"	and
      naming/terminology for group of addresses (Jean-Francois Mule)

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

Message: 1
Date: Tue, 8 Jul 2008 15:13:53 -0600
From: "Jean-Francois Mule" <[email-masked]>
Subject: Re: [PEPPERMINT] Data model for "reachability data"	and
	naming/terminology for group of addresses
To: <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Ray,

   Thank you for the comments and sorry for the delay in responding.
More inline.

Jean-Francois.

Ray wrote:
> Can you elaborate on what a "Service Area" / "Address Group"
> actually is?
It is basically a way to logically group user addresses that can be
   - reached via a given Signaling path Border Element (SBE),
   - reached via a domain from which SIP servers can be located (a la
rfc3263)
Folks often picture this by saying it is a group of users reachable via
a common (SIP) 'route'.

> In the UK for our Central Numbering Database we've developed a concept

> of a "Destination Group" - that being all those numbers (or
> destinations)
> which are supposed to be routed identically.  Is that the same thing?
I believe so.  Would folks prefer Destination Group then?

> Note however that this does not mean that every originating carrier 
> has to route them to the same place as every other carrier.
> 
> For example if Carrier A (a terminating carrier) has:
> 
>   DG1 = (a, b)
>   DG2 = (c, d)
> 
> then originating Carrier B routes destinations in DG1 to a particular 
> interconnect, and routes DG2 to some other interconnect.  However 
> Carrier C might have completely different interconnects with Carrier 
> A.
> 
> In the UK model the actual interconnect addresses are private 
> information bilaterally agreed between carriers.
> 
> kind regards,
> 
> Ray

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

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

End of PEPPERMINT Digest, Vol 13, Issue 8
*****************************************
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 8 Jul 2008 16:38:31 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Data model for "reachability data"	andnaming/terminology for group of addresses
Sender: [email-masked]

Ted wrote:
> As a relative neophyte, it's more obvious to me what "Destination
> Group" means than what "Service Area" means.   So I think it's
> somewhat preferable, although there's nothing fundamentally wrong
> with "Service Area."   I think it's because "Destination Group"
> implies logical locality, whereas "Service Area" implies physical
> locality.

Yes. 
I would also note that this "Destination Group" is close to what Debbie
Guyton in draft-guyton-drinks-registry-data-00.txt calls a "Dial Code to
Destinations" for logical groupings of dial codes.
 
Jean-Francois.
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 8 Jul 2008 15:55:38 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt
Sender: [email-masked]

The online diff tool shows that 6 lines have changed between
draft-schwartz-peppermint-problem-statement-00.txt and
draft-ietf-drinks-cons-rqts-00.txt:
6 lines... And if you remove the ID name change, the change in dates and
a semi column lost somewhere, it comes down to zero change have exactly
6 lines.

I thought we had a BoF in Philly and that some wg discussions happen
between then and now.

No other comments.
Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Monday, July 07, 2008 11:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action:draft-ietf-drinks-cons-rqts-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Data for Reachability of
> Inter/tra-NetworK SIP Working Group of the IETF.
> 
> 
> 	Title           : Consolidated Provisioning Problem Statement
> 	Author(s)       : D. Schwartz, et al.
> 	Filename        : draft-ietf-drinks-cons-rqts-00.txt
> 	Pages           : 12
> 	Date            : 2008-07-07
> 
> This document describes the type of data provisioned among Voice
> Service Providers and underscores the need for clearly defined
> structures and interfaces to facilitate this provisioning.  This
> work
> is in support of the service provider peering as defined by the
> SPEERMINT WG.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-drinks-cons-rqts-
> 00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 8 Jul 2008 15:33:21 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Comparison of Requirements Documents
Sender: [email-masked]

Ed,

  See inline.

Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of Edward Lewis
> Sent: Monday, June 30, 2008 1:08 PM
> To: [email-masked]; [email-masked]
> Subject: [PEPPERMINT] Comparison of Requirements Documents
> 
> I've been taking a look at two requirements documents, the ESPP
> Requirements and the Consolidated Provisioning Statement.  I
> realize
> (or have been told) that a new set of ESPP documents is coming out,
> so I'll avoid getting into specifics.  The goal is to have a
> "Unified" (we've already used "Consolidated") requirements document
> for the WG.
> 
> BTW, the documents I'm comparing are these:
> http://tools.ietf.org/html/draft-mule-peppermint-espp-requirements-
> 00
> http://tools.ietf.org/html/draft-schwartz-peppermint-consolidated-
> provisioning-problem-statement-00
> 
> This comparison list is not very detailed, I wanted to identify the
> topics that included in both and where the two requirements had
> different emphasis.  I don't think there is any outright
> contradiction between the two.

I'm not sure what you meant by "different emphasis".  

> Both documents describe a protocol running over SOAP/XML, WDSL, TLS
> and HTTP and being easily integrated into the current provisioning
> systems.
The ESPP protocol requirements were modeled after the NETCONF ones (at
least in terms of the document outline).

> Both recognize that there a telephone number (E164) to URI mapping
> happening, with NAPTR as a major vehicle (but not sole vehicle).
> 
> Both mention a need to make the transactions auditable, including
> logs.
> 
> Consolidated mentions multiple kinds of sources of data, ESPP
> refers
> to multiple clients.  This could be interpreted as an equivalent
> statement.
> 
> ESPP explicitly states that operation is based on files (as opposed
> to records).  (I'd question the file name requirements based on

No.  It should be possible to use a file-based mechanism to provision a
large amount of data for sunrise use cases.  If you look at ESPP
closely, the concept of operations based on transactional records does
exist.

> this,
> as well as a hard coded limit on the size limit.)
Implementations prevail.  We came to the conclusion that to be testable,
those requirements better be bound in terms of how big of a file sent
via SCP a server must be able to accept and process.  It also gives an
indication to sysadmins and operators for where they should not go in
file sizes.  The idea is to split the files into multiples after a
certain limit.
I see nothing wrong with that, quite the contrary when you start to look
at code.

> ESPP describes designing an efficient protocol, i.e., being able to
> apply one set of data to many numbers.  (But when I boiled the
> requirements down, I didn't see this idea - maybe it was in the
> protocol.)
Can you elaborate and quote text so we (authors of ESPP) can provide
more context.

> ESPP has a specific data model in mind (which is being discussed in
> recent mail), and a capacity of the order of the size of the PSTN
> number range(s).

Again, the purpose of those things is just to give a number to give
implementers an idea of the scale and performance requirements.

> 
> ESPP includes some protocol maintenance stuff (versioning numbers).
> 
> Consolidated has requirements on the database being addressable
> (any element).
ESPP goes into details about how each object in the DB is identified
with eID and oIDs, something Kent went over in a thread with Bob Walter
some time ago.

> Consolidated explicitly includes prefixs (for ranges) and min/max
> lengths.
ESPP has TN ranges and LRNs which we agreed should be changed to prefix
to make it more generally applicable.

> Consolidated explicitly mentions numbers being reassigned and the
> impact of that on database entries and responses.
What is the requirement on the protocol here (as opposed to the
operational aspects of number reassignments)?

> Consolidated requires dip indications, temporal validity, number
> "ownership" and other ancillary data.
> 
> Consolidated requires a catchall record, a \1 shorthand.
> 
> Consolidated has requirements on the transport as being end-to-end
> only (no caching) and having flow control.

> 
> It's obvious that the two teams that developed the documents had
> different emphasis on what to include in a list or requirements.

Based on the above, this is not obvious to me.

> Even with the ESPP requirements document being rather mature (as
> well
> as being accompanied by a protocol specification), there is a need
> to
> combine the two documents.  
That I agree with.

> I don't believe that the result will be
> radically different from either, just more complete.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-
> Edward Lewis                                                +1-571-
> 434-5468
> NeuStar
> 
> Never confuse activity with progress.  Activity pays more.
> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-
> Edward Lewis                                                +1-571-
> 434-5468
> NeuStar
> 
> Never confuse activity with progress.  Activity pays more.
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 8 Jul 2008 15:13:53 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Data model for "reachability data" and	naming/terminology for group of addresses
Sender: [email-masked]

Ray,

   Thank you for the comments and sorry for the delay in responding.
More inline.

Jean-Francois.

Ray wrote:
> Can you elaborate on what a "Service Area" / "Address Group"
> actually is?
It is basically a way to logically group user addresses that can be
   - reached via a given Signaling path Border Element (SBE),
   - reached via a domain from which SIP servers can be located (a la
rfc3263)
Folks often picture this by saying it is a group of users reachable via
a common (SIP) 'route'.

> In the UK for our Central Numbering Database we've developed a
> concept of
> a "Destination Group" - that being all those numbers (or
> destinations)
> which are supposed to be routed identically.  Is that the same
> thing?
I believe so.  Would folks prefer Destination Group then?

> Note however that this does not mean that every originating carrier
> has to
> route them to the same place as every other carrier.
> 
> For example if Carrier A (a terminating carrier) has:
> 
>   DG1 = (a, b)
>   DG2 = (c, d)
> 
> then originating Carrier B routes destinations in DG1 to a
> particular
> interconnect, and routes DG2 to some other interconnect.  However
> Carrier
> C might have completely different interconnects with Carrier A.
> 
> In the UK model the actual interconnect addresses are private
> information
> bilaterally agreed between carriers.
> 
> kind regards,
> 
> Ray

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

Content-class: urn:content-classes:message
Date: Mon, 7 Jul 2008 15:04:27 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt
Sender: [email-masked]

 Some initial comments re this draft:
1. Section 3.1 Index/Key Data states that "for lookup information about
the most specific prefix will be returned." While this might be
desirable in some cases, I could image others where a larger set of
records might be desired. It also seems out of scope for DRINKS since it
speaks to retrieval rather than provisioning.
2. I'm troubled by the "first hop" "last hop" provider terminology in
Section 3.2. The way it is used in this section seems to imply that
there is some VSP closer to the end user than the VSP assigned the
number prefix. This *might* be under some circumstances, e.g., where a
non-facilities based provider obtains its numbers through wholesale, but
is not the most general case. If multiple VSP records are allowed then
it would seem some means of identifying which is which is required.
3. w/r/t number portability info (Section 3.2) carrier code is only one
type of NP info employed in the PSTN. Some more general terminology
should be employed.
4. Section 4 states that routing information is out of scope of the
registry provisioning problem. I'm not sure I agree.
In some arrangements routing information might well be expected to come
from a Registry and so need to be provisioned. I believe a number of
existing private registries provide routing information today. The
information *might* be relatively dynamic but it might not. Perhaps I
misunderstand how the term "routing information" is intended here.

Penn Pfautz
AT&T National Access Management
+1-732-420-4962

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

From: [email-masked]
To: [email-masked]
Date: Mon,  7 Jul 2008 10:00:02 -0700 (PDT)
Cc: [email-masked]
Subject: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF.

	Title           : Consolidated Provisioning Problem Statement
	Author(s)       : D. Schwartz, et al.
	Filename        : draft-ietf-drinks-cons-rqts-00.txt
	Pages           : 12
	Date            : 2008-07-07

This document describes the type of data provisioned among Voice
Service Providers and underscores the need for clearly defined
structures and interfaces to facilitate this provisioning.  This work
is in support of the service provider peering as defined by the
SPEERMINT WG.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-drinks-cons-rqts-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-drinks-cons-rqts-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

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

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

--NextPart--

From: David Schwartz <[email-masked]>
To: "Richard Shockey" <[email-masked]>
Date: Sat, 5 Jul 2008 21:08:08 +0300
Cc: [email-masked], [email-masked]
Subject: Re: [PEPPERMINT] [drinks] FW: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt
Sender: [email-masked]

Can anyone provide me a link to the Session Location Routing Protocol  
(SLRP) Overview document mentioned in the informative references?

Thanks,

D.

On Jul 4, 2008, at 9:21 PM, Richard Shockey wrote:

> New agenda item...
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked] 
> ]
> On Behalf Of [email-masked]
> Sent: Friday, July 04, 2008 11:30 AM
> To: [email-masked]
> Subject: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Location Routing Function Requirements
> 	Author(s)       : H. Kaplan
> 	Filename        : draft-kaplan-drinks-lrf-requirements-00.txt
> 	Pages           : 7
> 	Date            : 2008-07-04
>
> This document describes the requirements for a Location Routing  
> Function
> Protocol, for inter and intra-domain SIP session routing.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-drinks-lrf-requirements-00 
> .
> txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> <ATT02226.txt>_______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Fri, 4 Jul 2008 14:21:48 -0400
Cc: [email-masked]
Subject: [PEPPERMINT] FW: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0A3F_01C8DDE1.61908360
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

New agenda item...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, July 04, 2008 11:30 AM
To: [email-masked]
Subject: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Location Routing Function Requirements
	Author(s)       : H. Kaplan
	Filename        : draft-kaplan-drinks-lrf-requirements-00.txt
	Pages           : 7
	Date            : 2008-07-04

This document describes the requirements for a Location Routing Function
Protocol, for inter and intra-domain SIP session routing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-drinks-lrf-requirements-00.
txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_0A3F_01C8DDE1.61908360
Content-Type: Message/External-body;
	name="draft-kaplan-drinks-lrf-requirements-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-kaplan-drinks-lrf-requirements-00.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

------=_NextPart_000_0A3F_01C8DDE1.61908360
Content-Type: text/plain;
	name="ATT02226.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT02226.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

------=_NextPart_000_0A3F_01C8DDE1.61908360--

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 3 Jul 2008 13:19:41 -0400
Cc: [email-masked]
Subject: [PEPPERMINT] FIRST cut at DRINKS agenda.
Sender: [email-masked]

IETF 72 DRINKS Agenda

Data for Reachability of Inter/tra-NetworK SIP (drinks)

Chair(s):

Richard Shockey [email-masked]

Alexander Mayrhofer <[email-masked]> 

WG Secretary 

TBD ..

RAI Director(s):

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

RAI Area Advisor:
Jon Peterson [email-masked]

Agenda Bashing. 

1.	Discussion of Consolidated Requirements Documents.
2.	Revised ESPP documents 
3.	Contribution from Debbie Guyton Telcordia ..

********************************************

Approved DRINKS WG Charter :

The IETF has been working on various aspects of SIP-enabled Multimedia
administrative domains among SIP Service Providers (SSP's). SSP's are
entities that provide session services utilizing SIP signaling to their
customers. In addition, the IETF has done significant work on data exchanges
among various network elements.

The ENUM and SPEERMINT working groups provide the underlying context for
much of the intended work that the DRINKS working group will undertake.

The ENUM working group is specifically chartered to develop protocols that
involve the translation of E.164 numbers to URIs. While the SPEERMINT
working group has been chartered to develop requirements and best current
practices among real-time application SSPs and to describe how such services
may best interconnect across administrative boundaries.

Specifically, DRINKS will provide details of how Session Establishment Data
(SED) is collected, what comprises SED, how SED should be used to properly
identify an optimal path to a destination SIP user agent (UA), either
internally or externally to the SSP. For the initial iteration of this
charter, the SED data is assumed to be fields that might be provisioned for
ENUM, with limited exceptions. If the working group would like to work on
data types unrelated to ENUM registries and databases, the WG will
recharter. In addition DRINKS will ensure that the SED and the SIP session
data securely exchanged between the peering functions.

Typical SED data might include:

+ Routes
- Destination SIP/SIPS/TEL URI Egress and Ingress Routes
- Relevant route names, identifiers, and services
- Attributes affecting route selection
- PSTN database information

+ Targets
- Individual, ranges, or groups of user-agent identifiers
- Target aggregation entities (e.g. service areas) and target-to-aggregate
associations

+ Treatment Profiles
- Priority
- Location

Potential SED Data types not in scope will be session rating or other
billing or pricing information between SSP's.

It is also recognized that peering relationships become more complex as
multiple peers are added to a common relationship; these complex aspects and
requirements are defined within the contexts of a peering Federation.

The DRINKS working group is chartered with a scope that is orthogonal to
SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build
from the work of SPEERMINT and ENUM to identify and define the data
structures and data exchange protocol(s) among SIP based Multimedia
administrative domains.

These administrative domains may be of any practical size and could be any
type of SSP, such as recognized telephony carriers, enterprises, end-user
groups, or Federations. Data exchanges among these administrative domains
may be bi-lateral or multi-lateral in nature, and could include bulk updates
and/or more granular real-time updates.

Administrative domains may exchange data directly between each other or
might use an external registry to aggregate data from multiple
administrative domains or multiple data providers into a single view.

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

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

GOALS AND MILESTONES

Nov 08 - WGLC for Requirements for Session Establishment Data (SED) data
exchanges (Proposed Standard).

Dec 08 - IESG Submission for Requirements for Session Establishment Data
(SED) data exchanges.

Jan 09 - WGLC for Exchanging of Session Establishment Data (SED) from data
providers to registries or between bi/multi-lateral partners (Proposed
standard).

Feb 09 IESG Submission for Exchanging of Session Establishment Data (SED)
from data providers to registries or between bi/multi-lateral partners.

Mar 09 - WGLC for Exchange of Session Establishment Data (SED) from
registries to Location Routing Function databases (Proposed Status).

Apr 09 - IESG Submission for Exchange of Session Establishment Data (SED)
from registries to Location Routing Function databases.

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://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: "'IETF ENUM WG'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 3 Jul 2008 13:16:36 -0400
Subject: [PEPPERMINT] REMINDER ... Internet DRAFT cut off dates...
Sender: [email-masked]

July 7, Monday - Internet Draft Cut-off for initial document (-00)
submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission
Tool.
July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT
(24:00 UTC/GMT), upload using IETF ID Submission Tool.

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://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Sat, 28 Jun 2008 18:06:10 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] test test test
Sender: [email-masked]

>  -----Original Message-----
>  From: Richard Shockey [mailto:[email-masked]]
>  Sent: Friday, June 27, 2008 12:51 PM
>  To: [email-masked]'
>  Cc: [email-masked]'
>  Subject: test test test
>  
>  This is a test of the new list please ignore.
>  
>  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://www.ietf.org/mailman/listinfo/peppermint