[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


_______________________________________________
PEPPERMINT mailing list
PEPPERMINT at ietf.org
https://www.ietf.org/mailman/listinfo/peppermint