Hi Noel,
|Do remember that the _provision_ of the mapping is a different |issue from the |_delegation_ of the mapping - in DNS terms, the latter is |having an entry in |.COM which points to company X's nameserver, and the former is |company X's |nameserver providing A records (etc) for www.X_company.com. Understood completely. | > the new site can provide their own mapping service and |not aggregate, | > impacting the scalability of the mapping. | |I don't understand this point (perhaps because I'm assuming |that the mappings |will be provided by a hierarchical delegation system like CONS)? Simply this: if an IPv4 site with a swamp prefix wants to participate in ALT, what happens? If they choose not to renumber, what happens? Please also consider the transition plan while you're at it. | > The analogy of having a group of providers supporting |.com is a good | > one. If that could be worked out, that could conceivably |create an open | > market for mapping services. However, please note that |such a market | > would have to be created for each and every mapping |aggregate. Unlike | > TLDs, I suspect that we will need more top levels. How |many aggregates | > do we forsee? 1000? Frankly, I'm skeptical that we will |be able to | > create this market. | |Your concern at the end of that seems to be assuming that each |provider will |be servicing only one top-level aggregate. I don't see any reason the |providers wouldn't serve many/most top-level aggregates - i.e. |we might have |3 providers, each of which can provide many (most?/all?) mappings. Fair, you can trivially support more than one prefix. To continue the analogy, this would seem to have many of the same properties as the root nameservers in DNS. |(The exact details here are left unstated, there's something |of a design |decision tree: a) if every provider does not have the entire |set, then you |have to either i) ask them all in parallel, or ii) accept |delays on some |lookups if you have to fail over to a secondary; or b) you |mandate that all |providers carry all mappings, although some providers could be |'secondary'; |i.e. they don't get the mapping directly from the client, but |from one of the |other providers - i.e. they listen to each other and pick up |mapping they |don't have. I don't think there are any insoluble technical |problems here, |we just have to make sure we design a system which can support |the business |relationships we require as well as the usual well-understood technical |ones such as security, robustness, etc.) Again, I'm less concerned about the technical side of things than I am about vendor lock vs. the cost of renumbering. It would seem that to prevent vendor lock, there must be a broad market of mapping providers. And to avoid renumbering the identifier prefix must be portable across those mapping providers. In short, it seems like we have to have a situation directly analogous to what we have today with the DFZ full of swamp prefixes. We have a number of 'DFZ' mapping providers advertising mapping for 0/0 and delegating the entire swamp. Again, this feels like we haven't solved the problem, we've just pushed it up a layer. Regards, Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
