Subject: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt

From: [email-masked]
Date: Mon, 7 Jul 2008 10:00:02 -0700 (PDT)

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

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 7 Jul 2008 15:04:27 -0400

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 8 Jul 2008 15:55:38 -0600

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
> 
> This draft is a work item of the Data for Reachability of
> Inter/tra-NetworK SIP Working Group of the IETF.
> 
>

---

From: David Schwartz <[email-masked]>
Date: Thu, 31 Jul 2008 03:51:29 +0100

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

inline...

> 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.
> 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.
> type of NP info employed in the PSTN. Some more general terminology

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