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

[David Schwartz <[e-mail]>]

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
> [phone]
>
> _______________________________________________
> PEPPERMINT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/peppermint

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