Since this looks like the beginning of a new thread on this discussion, it's only fair the Subject: header gets changed.... On Jun 6, 2005, at 22:00, Edward Lewis wrote:

What I find interesting is the trade-off of:

The gain in packet compression by using similar names plus the operational advantage of streamlining the names

vs

The gain by spreading name server names under other TLDs plus the logging convenience of only needing one PTR record per address

Ed, I'm not sure I understand the second part of your trade-off. The benefits of better label compression and streamlined names seem clear enough. Spreading name server names under other TLDs appears unwise: there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I note Neustar doesn't spread the TLD NS RRsets for .biz and .us like that. :-) And as for reverse lookups, I doubt anybody or anything cares about what name (singular) should be returned for the address of some TLD server. The operator of that server will care of course, but why would anyone or anything else even need to care?

1) Compression to insert more name servers or more glue records into a response is an advantage that I think is becoming outdated.

With EDNS0 out there, I tend to agree. But there are lots of name servers deployed that don't and won't support EDNS0. And even if EDNS0 was ubiquitous, I'd prefer to see NS RRsets use a clean set of target names. It's prettier. And it reduces the protocol overheads: fewer CPU cycles encoding/decoding DNS packets as well as saving precious bytes we're going to need for DNSSEC RRtypes. :-) Even with EDNS0. :-(

3) I would think that having servers listed under other TLDs (as we are looking at a ccTLD here) would be a good thing. Just for the fact that we are spreading the servers about (in DNS, not just topology). In addition, these servers don't count against the glue space hit in the response.

Could you please expand on this Ed? There are things I simply do not understand here. What's gained by spreading the hostnames for 8 (say) name servers for some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed for these names not "count against the glue space hit" in a referral?

4) Multiple name per address is one of those topics that gets bashed back and forth. At times we find it distasteful to have multiple PTR records in a set, for instance, this makes traceroutes and logs list potentially "wrong" names. Other times we are reminded that it is perfectly natural to allow more than one PTR record in a set. Maybe this is a "it's good for servers but not good for routers" situation.

Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to see how this matters. Is there a name server implementation that does reverse lookups of the IP addresses in a referral, compares them with the hostnames in the NS RRset and gets upset if there's a mismatch?

The part of the trade-off I haven't addressed is:

The gain by using unique name server names for each delegation

vs

The need for extra IP addresses in light of a one name per address policy

This confuses me too Ed. AFAICT there is no one name per address policy. Even if this was the case for TLD delegations, we'd still only be talking about wasting around 4000 IPv4 addresses, assuming each TLD has around 20 NS records. There are plenty of far more blatant examples of wasteful usage of IPv4 address space: the /8s that Stanford and MIT have for instance.

Nevertheless, what I've debated above doesn't seem to be the point of the document. It seems the document is presenting discomfort with the response.

I'm not sure that's right either. I read Olivier's document as an abridged history of what happened and where things stand today. People are of course welcome to interpret that document in whatever way best suits their standpoint. The questions about transparency and process at IANA remain unanswered though Doug has promised to respond to them. It looks like these questions won't go away until they are answered. IMO, it would be better to see them answered here instead of in a more formal setting such as an ICANN meeting.

Bill & all, On 07 Jun, bmanning@vacation.karoshi.com wrote: | > of wasteful usage of IPv4 address space: the /8s that Stanford and MIT | > have for instance. | | er... MIT & MERIT... stanford returned theirs years ago... | | now if i understood Ed, both he and you are tangentially | arguing for in-baliwick glue. why was this considered such | bad practice last decade, but now seems to be not only | prefered but the only choice for right-thinking people? ==> I don't think anybody expressed the "in-baliwick glue" as "the only choice for right-thinking people" nor do I think that anybody was trying to show people how to "right-think" about NS's naming for a TLD delegation... The name compression technique which maybe was considered as "a bad practice" a decade ago has become more popular for the last 3-5 years. Btw I don't think this technique is "outdated" today as Ed said since the alternative he mentioned (Anycast) is not widely deployed yet by TLDs (only a few TLDs are anycast today and still some political and technical issues to be solved... Just think for instance at IPv6 allocation policy which does't allow yet TLDs in the RIPE region to get an "unfiltered" block... Yes I know, a new proposal is underway to be adopted by the RIPE address-policy wg...). IMHO, the name compression popularity relies on two facts today: - it addresses and mitigates new technical issues which didn't use to occurr frequently a decade ago, such as riskk of glue dropping due to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So compression may save a large amount of bytes which may be transformed in a new NS deployment (icluding its A/AAAA glues); - TLDs which are not yet deploying DNS anycast are endeavouring to get a suitable level of redundancy and load distribution among their deployed NS's. As the number of deployed NS's grows, it becomes very practical and interesting to have a naming plan easing the readability and consequently the operation of name service... Hence, it is seen by a number of TLDs today that name compression is a good and workable technique, in the absence of a better technique (yet to be easily deployable)... Cheers, Mohsen.

At 10:20 +0200 6/7/05, Mohsen Souissi wrote:

years. Btw I don't think this technique is "outdated" today as Ed said since the alternative he mentioned (Anycast) is not widely deployed yet by TLDs (only a few TLDs are anycast today and still some political and technical issues to be solved... Just think for instance at IPv6 allocation policy which does't allow yet TLDs in the RIPE region to get an "unfiltered" block... Yes I know, a new proposal is underway to be adopted by the RIPE address-policy wg...). IMHO, the name compression popularity relies on two facts today:

I would say the concerns are outdated as far as protocol considerations, but I do agree that there are some bureaucratic road blocks that it still helps you get around. My answer to that though is to remove the bureaucratic road blocks.

- it addresses and mitigates new technical issues which didn't use to occurr frequently a decade ago, such as riskk of glue dropping due to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So compression may save a large amount of bytes which may be transformed in a new NS deployment (icluding its A/AAAA glues);

One AAAA record, with a compressed owner name would need, what 12+128/8=28 bytes. If all of the nameservers were named [a-f].nic.fr, then you would need to compress 4 name servers names for each additional AAAA record you could squeeze in. (That's 4 label compressions saving the "nic.fr." portion.) An RRSIG is, for .fr as signer name, going to need 12+22+1024/8 (assuming RSA 1024). That's about 40 name compressions needed. Now, I suppose that the savings calculation I am presenting isn't completely accurate and am willing to go back and do a more realistic calculation for a particular TLD and proposed naming system to see if the numbers are right. The point I am trying to make is that name compression savings pale in comparison to the size of the records we are looking to add. (Note, for DNSSEC, EDNS0 is required...further muddying the debate.)

- TLDs which are not yet deploying DNS anycast are endeavouring to get a suitable level of redundancy and load distribution among their deployed NS's. As the number of deployed NS's grows, it becomes very practical and interesting to have a naming plan easing the readability and consequently the operation of name service...

I'll yield to the point that (learning) anycast is a challenge in operations. But in the long run, it will be more powerful than trying to shave bytes here and there.

Hence, it is seen by a number of TLDs today that name compression is a good and workable technique, in the absence of a better technique (yet to be easily deployable)...

"Today" yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

At 0:50 +0000 6/7/05, bmanning@vacation.karoshi.com wrote:

...

of wasteful usage of IPv4 address space: the /8s that Stanford and MIT have for instance.

er... MIT & MERIT... stanford returned theirs years ago...

now if i understood Ed, both he and you are tangentially arguing for in-baliwick glue. why was this considered such bad practice last decade, but now seems to be not only prefered but the only choice for right-thinking people?

Perhaps looking at the workings of the tools we have today. I don't understand why glue in the reverse map is considered any more of a hit than glue in the forward tree. It is one less issue in the reverse map, but it has cost us by requiring crutches placed in the forward tree. The crutch I refer to I have written about in many places - the crutch is the hybrid "cache response/referral" you get in response, for example to this query: dig @f.gtld-servers.com figwort.arin.net a (Meant as an example only. Look at the flags, no RA, no AA, but ANCOUNT > 0 and the rest of the message looks like a referral.) This crutch will have to be removed for DNSSEC (or DNSSEC will have to bend around it). When the crutch is removed, antique name servers will start to fall over. Perhaps the above is worded too strongly, I mean it as a potential reason why there is a call for in-bailiwick glue. And maybe RFC 2181's introduction of credibility as a means to stop cache poisoning plays a role, as well as BIND's search for the authoritative addresses of name servers in spite of having the glue addresses. BTW - This presentation at NANOG 33 gives another angle on this. http://www.nanog.org/mtg-0501/minda.html I believe that the similar presentations have been made at IETF$last and RIPE50. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

At 15:47 +0000 6/7/05, bmanning@vacation.karoshi.com wrote:

just for grins... how would DNSSEC "bend" around this supporting girder (or crutch if you prefer).

Having to know not to give up when seeing an unsigned answer coming from a cache, treating this as a referral message and not a bogus message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

At 15:55 +0000 6/7/05, bmanning@vacation.karoshi.com wrote:

On Tue, Jun 07, 2005 at 11:50:39AM -0400, Edward Lewis wrote:

...

At 15:47 +0000 6/7/05, bmanning@vacation.karoshi.com wrote:

...

just for grins... how would DNSSEC "bend" around this supporting girder (or crutch if you prefer).

Having to know not to give up when seeing an unsigned answer coming from a cache, treating this as a referral message and not a bogus

so... get back the unsigned rrset (glue) - then treat as a referal & attempt to validate down its delegation chain...???

A validator would need to know to do this. Look at the reply to the dig I suggested. Is it a reply? Is it a referral? If I recall correctly, BIND treats it as a reply and ceases the iteration, caching the answer as a less credible piece of data than had the AA bit been turned on. My point is, if the resolver sees this and judges it to be a reply, instead of tossing it and trying the query again the resolver needs to slip this into the "it's a referral" queue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

Jim Reid wrote:

Ed, I'm not sure I understand the second part of your trade-off. The benefits of better label compression and streamlined names seem clear

well, I do understand "better label copmpression" but I don't understand "streamlined names". What's the real benefit of those?

there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I

It comes back to the question for what reason the ROOT applies a wide glue policy as opposed to a narrow one which many TLDs do.

about what name (singular) should be returned for the address of some TLD server. The operator of that server will care of course, but why would anyone or anything else even need to care?

We know that multiple PTRs are protocolly correct but don't work well in practice, i.e. they give intermittent results. That's also about consistency and setting examples.

was ubiquitous, I'd prefer to see NS RRsets use a clean set of target names. It's prettier. And it reduces the protocol overheads: fewer CPU

"prettier"? Name servers are objects in the DNS which are pointed at due to their special function. Just using their names as "aliases" to some address misses the point. Why not get rid of these domain names in the NS RDATA and point to IP addresses directly (sounds familiar, eh)?

name servers for some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed for these names not "count against the glue space hit" in a referral?

All "glue" is equal, but some "glue" is more equal than other. And yes, it's additional info, not "glue".

see how this matters. Is there a name server implementation that does reverse lookups of the IP addresses in a referral, compares them with the hostnames in the NS RRset and gets upset if there's a mismatch?

There might be actual operators to confuse.

This confuses me too Ed. AFAICT there is no one name per address policy. Even if this was the case for TLD delegations, we'd still only be talking about wasting around 4000 IPv4 addresses, assuming each TLD

So, why would all this new wisdom only apply to TLDs? -Peter

At 11:13 +0100 6/7/05, Jim Reid wrote:

Because that was the initial context of the discussion! There appeared to be a policy at IANA of one hostname per IP address in the root zone. It's clearly unworkable to insist on there being exactly one hostname for an IP address. There should of course be one PTR record per IP address, but that's an entirely different discussion.

I don't see the discussions as different. The rationale for the one address per name I once ran into was because they had to limit PTRs to one per address. If you allow multiple names to one address, what do you put in the PTR record that will yield meaningful results in logs? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

On Tue, Jun 07, 2005 at 05:49:12PM +0100, Jim Reid wrote:

...

If you allow multiple names to one address, what do you put in the PTR record that will yield meaningful results in logs?

Well I personally make sure PTR records always return the canonical name of the host and nothing else, no matter how many A or AAAA records exist for that IP address.

for "fun" - some folks rotate the various canonical names that exist for any given A or AAAA or (for difficult types) A6 records that exist. and Jim, you confuse me. posit: twinkle.little.bat. AAAA 3ffe::dead:beef muffet.satona.tuffit. aaaa 3ffe::dead:beef PDC.e164.arpa. AAAA 3ffe::dead:beef which is THE canonical lable for the address 3ffe::dead:beef ?? --bill

Jim Reid wrote:

...

to their special function. Just using their names as "aliases" to some address misses the point.

Please explain what point is being missed Peter. The ability to have these "aliases" is valuable. For example, when I renamed the *host*

i didn't contest that. However, this is kinda "bit fiddling" and uses naming by function instead of by object. Had that been the intent there would be no need for names in the RDATA of an NS RR. IP addresses would be fine (well, the versioning became difficult, but anyway).

that was the master server for rfc1035.com I didn't have to change the delegation. This pointed at ns0.rfc1035.com which was and is an A record for the zone's master server. Name service for the zone remained at the same IP address but the name of the box providing that service changed.

[...]

...

So, why would all this new wisdom only apply to TLDs?

Because that was the initial context of the discussion! There appeared

This does not provide for a justification for such restriction. Your example above is for an SLD, not a TLD, by the way. So, I'm still not convinced that this "new scheme" is really a good or well scaling recommendation.

to be a policy at IANA of one hostname per IP address in the root zone. It's clearly unworkable to insist on there being exactly one hostname

Yes, but it doesn't mean one has to recommend to the contrary. -Peter

Edward Lewis wrote:

...

well, I do understand "better label copmpression" but I don't understand "streamlined names". What's the real benefit of those?

Name the 13 root servers. Now lookup the servers for (say) .ba and try to memorize them. Come back in an hour and name them.

hmm, I tried. I could remember A-M.root-servers.net but missed two of BA's servers. However, the only address I could recall was ns.ripe.net's, because it is so "pretty". Now, wouldn't that call for beautifying addresses? Seriously, a side effect of those efficienmt naming schemes is information hiding.

Why not point to IP addresses? For flexibility. When I want to renumber a name server, there's no need to update the parent's NS copy of my set. (Kinda like the DNSSEC need for the DS record.)

So, Jim tells me that he likes to have dedicated names so he doesn't have to change the delegation once the server's name changes and you argue that renumbering is easier if just names are used (instead of IP adresses or, to the same extent, per-zone server names and their necessary glue records). I guess we can't have both. I'm with you. -Peter

There are quite a few message to respond in the thread, I'll stick to questions indicating that my comments need clarification... At 0:45 +0100 6/7/05, Jim Reid wrote:

On Jun 6, 2005, at 22:00, Edward Lewis wrote:

...

What I find interesting is the trade-off of:

The gain in packet compression by using similar names plus the operational advantage of streamlining the names

vs

The gain by spreading name server names under other TLDs plus the logging convenience of only needing one PTR record per address

Ed, I'm not sure I understand the second part of your trade-off. The benefits of better label compression and streamlined names seem clear enough. Spreading name server names under other TLDs appears unwise: there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I note Neustar doesn't spread the TLD NS RRsets for .biz and .us like that. :-) And as for reverse lookups, I doubt anybody or anything cares about what name (singular) should be returned for the address of some TLD server. The operator of that server will care of course, but why would anyone or anything else even need to care?

Let's say my TLD is "tld", that my two options for name server sets are {a.nic.tld, b.nic.tld} and {a.nic.example, b.nic.tld}, and the query is for "www.jim.tld A". With option 1, if the query goes to the root and the iterative resolver is BIND, the queries for the addresses of a.nic.tld and b.nic.tld will follow. If there is a problem with the tld zone, and perhaps the glue at the root isn't completely right, we will have problems. With option 2, a problem with the tld zone isn't an issue if the copy of the zone on a.nic.example is in good enough condition. In summary, by using a different TLD, there's one more place to get the address of a name server. It could be that the fault that makes this a true advantage has almost no chance of happening in isolation. My supposition that spreading name servers among domains is based on watching how BIND does its resolution (via packet sniffing). I don't have access to other (popular) implementations to see how they go about their business. As you descend the tree, it's clearer than spreading name servers among domains (even different tlds) has a benefit. Because there are more moving parts as you descend the tree, there's more chance something goes wrong, so you want to build in resiliency. I can see that in the case of TLDs, there really aren't many options in case of a some failures. And, as far as what I call glue space savings isn't seen in the root zone as all name servers are in the root domain. Given that BIND chases the authoritative version of the glue it receives, and that there are a lot of BIND name servers (if not a majority), I think there's a gain in spreading the name servers over different TLDs. NeuStar's name servers are all in the same TLD. Internally, well, we just haven't seen a justification for trying "something new." It's like this, it works as is, its an industry norm, and tinkering with operational systems should not be taken lightly. I'd say that I have a hunch that there is a gain to mixing name servers over TLDs, and this is based on my thoughts about how enterprises should think. Hunches are not always right. (Recall I'm writing as an individual, not a company representative.) As far as reverse lookups - I think there are a lot of folks who do care. I've seen the issue more with routing discussions, traceroute is often cited as a tool that cares what it sees in the PTR record. Security analysis too - they rely on logging data.

...

1) Compression to insert more name servers or more glue records into a response is an advantage that I think is becoming outdated.

With EDNS0 out there, I tend to agree. But there are lots of name servers deployed that don't and won't support EDNS0. And even if EDNS0 was ubiquitous, I'd prefer to see NS RRsets use a clean set of target names. It's prettier. And it reduces the protocol overheads: fewer CPU cycles encoding/decoding DNS packets as well as saving precious bytes we're going to need for DNSSEC RRtypes. :-) Even with EDNS0. :-(

I wasn't even considering EDNS0. I was thinking anycast. EDNS0 is good, but some non-DNS security devices still don't understand it. That needs fixing, and is out of scope for the thread and wg. I don't see how CPU cycles are reduced by using "a clean set" of names. A label pointer reference is the same, regardless of where it goes.

...

3) I would think that having servers listed under other TLDs (as we are looking at a ccTLD here) would be a good thing. Just for the fact that we are spreading the servers about (in DNS, not just topology). In addition, these servers don't count against the glue space hit in the response.

Could you please expand on this Ed? There are things I simply do not understand here. What's gained by spreading the hostnames for 8 (say) name servers for some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed for these names not "count against the glue space hit" in a referral?

Going back to my fictional tld above and the two options, here is what the root can minimally send back: option 1 answer: authority: tld NS a.nic.tld tld NS b.nic.tld additional: a.nic.tld A 1.1.1.1 b.nic.tld AAAA ::1 option 2 answer: authority: tld NS a.nic.example tld NS b.nic.tld additional: b.nic.tld AAAA ::1 The reason I say these are minimal is that any query for the records in the additional section would wind up with the same answer. In option 2, the next query to the root would be for "a.nic.example A" (and AAAA) from a BIND resolver. The response to that would be a referral to the example TLD servers. In option 2, the out-of-baliwick server does not count the needed glue. Of course, in reality, the root server is probably responding with it, as the server is under the root domain. Perhaps I am seeing a gain that is possible, but is not realized in practice because of the tools we are using and are used to.

Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to see how this matters. Is there a name server implementation that does reverse lookups of the IP addresses in a referral, compares them with the hostnames in the NS RRset and gets upset if there's a mismatch?

I thought that the main problem was that IANA wasn't permitting multiple hosts to point to one IP address. Back in prehistoric times, this restriction was also in place in .com and .net. I ran into this - and the technical glitch that caused the restriction was that the registry software couldn't support multiple PTRs in a set. My supposition was that this might have been the cause of concern with IANA - I can't imagine any other reason to be concerned. Besides (potentially) faulty registry software, the main reason why multiple PTR records in a set are denigrated by some is that application software generally assumes a host has only one name. (I think multiple PTRs are fine, I'm just relating the arguments levied against them.) My experience with one dynamically updating DHCP server would treat the forward and reverse differently. When it created a lease with a vanity name, it would add the vanity name to the forward, supplementing what was already there. When updating the reverse, it deleted all previous records and out in the PTR with the vanity name. This is an application problem, not a DNS one. The only time that the reverse of a name server has ever been called out is in some DNS checking packages. I don't know why it's an issue, but DNS set ups were graded on that.

...

The part of the trade-off I haven't addressed is:

The gain by using unique name server names for each delegation

vs

The need for extra IP addresses in light of a one name per address policy

This confuses me too Ed. AFAICT there is no one name per address policy. Even if this was the case for TLD delegations, we'd still only be talking about wasting around 4000 IPv4 addresses, assuming each TLD has around 20 NS records. There are plenty of far more blatant examples of wasteful usage of IPv4 address space: the /8s that Stanford and MIT have for instance.

During the RIPE NCC presentation in the WG at RIPE 50, I thought the criticism was that the slave server names using unique addresses was considered wasteful and ironic that an RIR was doing this. I thought that this was proposed in response to the "problems" with IANA as described in the draft. It could be that my wires are crossed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

At 11:00 +0100 6/10/05, Niall O'Reilly wrote:

Spreading name servers among domains _may_ give resiliency; it _certainly_ adds complexity and expands the repertoire of potential failure modes. There are more places where things can go wrong. If there are (perhaps hidden) interdependencies between these places, the overall impact of one particular thing going wrong may be far greater than expected. It all depends on having a strategy for placing your servers in well-managed parts both of the DNS tree and of the network topology.

Of course, we all take care to have a strategy we can stand over, and to review it regularly! 8-)

Yeah, there are more places for potential failures, but it's not like the extra failures that are realized will harm because, well, it's like a parallel circuit and not a serial circuit. You only need to find one (working) name server's address to get the data you need, you don't need to find all of them. As far as complexity - is it all that more complex than the alternative of "placing your servers in well-managed parts?" You do have more places to register host information (glue) and that is more complex. But what is the complexity of determining the "well-managed parts?" ;) I think this is coming down to a realization of "fate sharing." If all of a domain's name servers share the same fate - like all being on the same physical subnet or maybe tied to the same security association (like VPN) - than naming them consistently is no loss. OTOH, if the fates are diverse, like choosing two unrelated organizations to run slave servers for you, then tying the names together is the "fate-sharing" element that reduces the benefit of the diversity in slave servers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

On 10 Jun 2005, at 16:05, Edward Lewis wrote:

is it all that more complex than the alternative

It's a tradeoff, and the full picture is likely more elusive than one expects. It's not just about the technical components, but about organizational structure and such "layer 9" stuff. /Niall

On 10 Jun 2005, at 16:05, Edward Lewis wrote:

is it all that more complex than the alternative

It's a tradeoff, and the full picture is likely more elusive than one expects. It's not just about the technical components, but about organizational structure and such "layer 9" stuff. /Niall