Hi John, Thanks for taking the time to review the draft and post your thoughts.
On 20/07/11 7:00 AM, "John Kristoff" <j...@cymru.com> wrote: >> 1) Use cases? who wants this. > > I'll assume that you're looking for more use cases beyond those you had > envisioned when deciding to write it up. Otherwise, this is a solution > looking for a problem. > Actually the use cases existed, I didn't divulge them at the time as I didn't have the blessing of those who expressed their desires. At the time I only had authority in my own desires to promote. > In the draft it is suggested there may be a use case for this > information by Network Providers, Content Providers, Security > Providers, Geo-Location (GEO) IP services and Research. I'll consider > those cases below. There may be geopolitical reasons for this as > well. DNS resolver operators may be interested in this like they are > with the draft-vandergaast-edns-client-ip proposal. One of the main > themes of my critique however will be that routing data does not > reliably associate itself to geo-location. Why do you think that? from watching routing tables I see that there really isn't that much AS churn. This leads me to think people really don't move their routers, or routes that often unless doing some level of mobility or targeted anycast. > > The title has: > > "first class geographical location statements" > > The abstract has: > > "first class informational statements pertaining to the geographical > attributes" > > The introduction has: > > "first class informational attestations pertaining to the > geographical attributes" > > Some consistency is needed, but perhaps I'm confused because I don't > know what "first class" means in this context and I couldn't find it in > the references. noted. will fix. > > Instead of "validatable" I'd say "verifiable". > > In section 2, the specification suggests network providers can > configure geoloc attributes for the benefit of content providers. > This reasoning assumes cooperation between network and content > providers. That may be assuming too much. Fair observation. > > It is not clear from the draft if the anycast operators will benefit > from publishing geoloc information or if receiving it from other network > operators is of value. Either could be potentially useful. I will clarify. > > As a general comment, IP addresses are inherently virtual and all > attempts to tie them to a physical geographic location will be > imperfect. All sorts of mobility, tunneling, subnetting and ephemeral > address issues are not likely to go away. This leads me to believe > that this work will be doomed from the start with some strict control > on what goes into the system, something that the Internet community is > not inherently good at mandating. I think there are a number of ways that information can be populated and maintained. The first, as you clearly state, is through some mandated model. I'm not a fan of creating oligopolies, so that hints at a model more closely related to crowd sourcing. Do keep in mind that the HELD service is separated from the RPKI, so HELD service operators might find better ways to authoritatively represent the location of use of prefixes and ASNs. > > In my opinion, having done some security work, it's not clear this > would add much if any value for security providers unless it was widely > implemented and implemented in a uniform manner. Neither seems likely > unless it was followed up with some more stringent requirements from > entities in charge of allocating the numbers. Interesting observation. > > This geoloc information may also compete or duplicate that provided when > the numbers are allocated and assigned. That may or may not be helpful. I think some clarifiying words are needed that highlight that the geoloc information is where the resources are put into 'use' versus the location of the ISO code location of the company that they were allocated to as we see in whois. > > As has already been mentioned, this effort is not aligned to the > goals of the charter for sidr. Yes, acknowledged. > Adding more features to a system is > tempting, but this is probably not the place or time for it. Indeed it is tempting, A global hierarchy of well formed, well maintained information about use of ASNs and Prefixes.. Without wanting to turn it into the quagmire of whois some level of extension would be desirable. > This is > trying to address a current operational problem by bolting on a new > feature to a new system in hopes of addressing current problems with > future solutions. And I think that hits the nail on the head. The RPKI work really is yet to show maturity. > I empathize with the motivation and would be > potentially interested in such a feature, but I recommend other tactics > and venues for this sort of effort. > I'll drop you a note off list. Although I'm considering reclassifying this draft as experimental. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
